►
From YouTube: Ethereum Core Devs Meeting #112 [2021-04-30]
Description
A
A
We
spent
some
time
discussing
eip,
3403
and
and
martin
and
vitalik
said
they
had
a
new
proposal
for
it
and
given
this
something
we
really
wanted
to
do
in
london
yeah
we
we
said
we
wanted
to
review
it
prior
to
this
call
and
hopefully
make
a
decision
about
it
today.
So
the
eep
has
actually
been
formally
proposed.
It's
eip,
3529
martin
or
I
don't
think
vitalik-
is
also
going
to
call
it
tweeter.
If
you
want
to
give
a
quick
summary
of
the
eep
before
we
have
comments.
B
B
A
C
E
I
would
try
to
avoid
it
for
london
unless
martinez
generally
suggesting
this
is
needed
for
security
like
for
the
for
just
for
the
sake
of
removing
gas
token.
I
don't
see
the
need
for
that
for
now,
but
if
that's
important
for
security
of
the
gas
gas,
sorry,
the
blood
gas
limit
elasticity
and
this
unpredictable
sizes,
then.
F
G
It
so
I
can't
really
say
how
important
it
is
for
block
electricity
and
how
bad
denial
of
service
issues
could
be
with
the
doubled
capacity.
I
don't
wanna
like
cry
wolf
too
much.
I
do
think
it's
the
concern.
I
am
mainly
familiar
with
death.
Naturally
I
I
mean
I
assume
that
there
would
be
denial
of
service
issues
for
other
clients.
G
I
think
it's
good
to
do
this
in
like
conservative
gesture
but
yeah.
I.
I
also
want
to
basically
say
that
my
personal
main
motivation,
why
I
see
this
as
important
is
because
I
think
it's
good
if
we
get
rid
of
this
gas
token,
because
I
believe
that
gas
tokens
are
used
to
just
mint
a
little
bit
instead
of
picking
some
cheap
transaction
and
this
drives
up
the
transactions.
G
F
G
G
I
D
H
Instead
of
just
including
transactions,
because
there's
always
you
can
always
sell
guest
tokens
later,
so
that's
another
problem
that
you're
essentially
miners
can
just
decide
not
to
include
transactions
but
mint
tokens,
and
this
is
actually
a
self-reinforcing
problem
because
then
block
congestion
just
goes
up
and
that
just
drives
gas
prices
up.
So
it's
actually.
It
is
worthwhile
to
mint
gas
tokens
because
you
it
you
can
extract
more
value
from
the
network
and,
at
the
same
time,
you're
raising
the
gas
prices.
H
Deterministic
blocks
and
having
the
potentially
2x
blocks
is
just
I
mean
it's
hard
to
reason
about
so,
for
example,
if
somebody
were
to
ask,
can
we
raise
the
estimate
and
we
always
have
to
think
about
the
worst
case
scenario,
and
since
refunds
allow
us
2x
the
gas
limit
it
doesn't
make.
I
mean
we
can't
raise
it
to
20
million,
simply
because
that
would
actually.
J
H
H
And
I
guess
last
but
not
least
what
I
wanted
to
mention.
It
was
traffic
at
it,
but
I
I'll
just
go
one
step
forward
further
and
and
see
that
I
think
we've
hinted
at
it
quite
a
bit
over
the
past
years
that
ethereum
network
isn't
that
particularly
safe
from
a
determined
denial
of
service
attack
and
berlin
included
eips
that
made
those
attacks
very
unprobable.
We've
got
included
snapchats,
which
again
made
those
attacks
super
unprobable.
H
We
don't
want
yeah
details
which
we'll
hopefully
do
in
about
two
weeks,
but
in
essence,
we've
been
trying
to
push
towards
making
block
sizes,
deterministic
and
state
access
more
meaningful
for
a
specific
reason,
so
it
wasn't
really
just
randomly
trying
to
to
make
things
you
get
it
so
it's
but
anyway.
So
if
personally,
I
would
really
really
strongly
suggest
we
go
towards
this,
but
we
can
get
you
guys
more
information
in
two
weeks.
E
So
miners
will
no
longer
be
able
to
simply
fill
the
blocks
with
with
gas
minting,
because
they
would
have
to
pay
the
base
fee
and
they
would
generally
raise
the
base
fee.
So
that
would
contribute
to
them
at
their
the
revenue
falling,
probably,
and
also
I'm
not
even
sure
if
there
is
enough
of
the
gas
stored
in
the
gas
tokens
to
provide
any
substantially
long
attack
on
the
on
the
blocks.
D
E
E
Well,
that
was
not
raised
as
a
motivation,
so
far,
so
obviously
for
the
future
implementation.
That
sounds
good,
but
I
think
there'll
be
lots
of
other
cleaning
and
changes
that
will
happen
as
part
of
the
merge
that
we
cannot
really
predict
that
this
particular
change
is
that
it's
might
be
slightly
rushed
for
london
that
this
particular
change
is
the
best
potential
change
taking
to
count
all
the
other
work
on
stateless
ethereum.
D
E
Oh,
no,
it's
it's
slightly
more
towards
neutral,
as
I
said
like,
I
would
listen
if,
if
you,
if
you
think
that
this
is
for
the
security
reasons,
that
definitely
I'll
be
convinced
what
I,
what
I'm
not
convinced
by,
is
that
it's.
If
it's
targeting
the
gas
token,
then
I'm
not
convinced
at
all
that
this
is.
This
is
needed
also
because
of
of
the
base
fee.
E
F
I
D
Yeah,
it
sounds
like
we
don't
have
a
strong
point
of
contention
here
there.
There
is
definitely
a
well
understood
worst
case
denial
of
service
scenario
here,
where
it
is
possible
for
this
to
muck,
with
the
total
amount
of
gas
used
in
a
block,
and
I
don't
think
that
anybody
made
this
specifically
to
get
rid
of
gas
tokens.
It's
more
focused
on
the
effect
the
gas
tokens
can
have
and
then
there's
a
bunch
of
other
beneficial
side
effects.
So
anyways
just
contextualizing
this
discussion.
L
L
B
F
M
I
think
I,
like
piper's
point
about
just
keeping
in
mind
kind
of
the
relative
ranking
of
the
reasons
for
and
against
that
the
primary
one
is
that
might
eclipse
all
the
others
is
just
to
think
about
the
reasoning
of
the
max
block
size,
a
block
cast
limit
and
then
beyond
that.
If
you
know
this
descent
on
that,
then
you
can
kind
of
use
the
others
as
tie
breakers.
N
Yeah,
so
I
was
basically
just
curious
if
like
do,
we
all
expect
that
the
that
that
the
erp
would
have
like
a
significant
impact
on
the
on
the
safe
gas
limit,
or
do
we
or
is?
Is
it
so
unset
like
like
naively
to
me
that
it
seems
like
at
least
to
the
extent
that
we
are
limited
by
peak
throughput
vip
would
allow
for
up
to
like
a
2x
increase
of
the
same
gas
limit,
because
we
would
only
kind
of
like
have
peak
peaks
of
2x
and
not
peaks
of
4x.
N
Potentially,
of
course,
we
might
also
be
limited
by
other
things.
I'm
just
wondering
because
like
to
me,
if
it
really
makes
like
a
big
difference
for
for
the
safe
gas
limit,
I
I
personally
would
be
like
strongly
in
favor
of
it.
But
if
this
is
more
complicated
and
maybe
doesn't
have
any
impact
on
the
guest
limit,
then
so
I
just
basically
be
curious.
If
people
generally
agree
that
it
has
an
impact
on
the
on
the
safe
guest
limit
or
if
there
are
like
some
reasons
why
it
might
not.
A
E
D
D
It's
a
precursor
to
cleaning
the
reason
that
this
eip
was
changed
to
not
fully
remove
them
is
so
that
we
don't
introduce
a
perverse
incentive
for
smart
contractives
to
set
values
to
one
instead
of
zero.
The
intent
is
that
when
we
move
to
state
expiry,
we
fully
remove
refunds,
and
this
was
sort
of
a
compromise
to
make
sure
that
the
smart
contract
developer
incentives
were
correctly
in
line
aligned.
E
If
we
assume
that
it's
the
miners
that
meet
a
lot
of
gas
tokens
nowadays,
then
those
attacks
on
the
block
with
the
double
deck
block
limit
is
not
only
opportunity
costs,
but
because
of
raising
the
base
fee,
their
revenue
will
fall
significantly
after
such
an
attack
because
of
the
basic
growing
the
their
opportunity.
Cost
will
be
huge
in
the
case
of
such
an
attack
and
the
attack
will
should
dissipate
quite
quickly.
That's
my
intuition,
and
it's
very,
very
constant
for
the
attacker.
B
Just
one
way
to
contextualize
this
discussion,
I
think,
is
that,
like
it
feels
like
okay,
so
there's
a
cip,
there's,
maybe
let's
say,
for
example,
a
30
chance
that
the
block
size
barriers
issue
is
important
enough.
That
is
like
really
important
and
maybe
a
70
chance.
It
doesn't
matter
much,
there's
also
a
30
chance
that
getting
rid
of
gas
token
is
something
that's
going
to
be
really
valuable
and,
let's
say,
maybe
a
70.
B
Yes,
it
doesn't
matter
much
and
I
have
not
heard
any
arguments
that
it's
going
to
that
this
could
be
actively
harmful
right.
So
two
30
chances
of
making
a
significant
of
solving
significant
security
issues
is
still
worth
like
the
fair,
fairly
small
number
of
lines
of
code
that
the
cip
contains.
At
least
I.
B
A
H
E
I
mean
you
would
have
to
have
a
significant
storage
to
unlock,
to
to
execute
such
an
attack.
For
a
longer
time
I
mean,
I
see
clearly
there's
massive
support
for
this
one,
so
it's
totally
fine
totally
fine,
the
only
okay,
so
just
to
claim
the
arguments
against
why.
Why
am
I
even
talking
about
it
and
potentially
of
suggesting
not
including
it?
E
There
are
two
two
reasons,
so
I
think
there
will
be
some
additional
phasing
and
testing
efforts
which
may
lead
to
a
potential
delay
of
london,
making
it
a
bit
slightly
just
slightly
harder
fork
to
sorry
network
upgrade
to
introduce,
and
the
second
one
was
that,
like
historically,
the
changes
to
the
gas
calculations
were
like
potentially
risky
for
the
consensus
split,
which
which
I
think
this
is
also
the
kind
of
risk
that
we
want
to
avoid
yeah.
So
these
were
the
only
all
new
arguments
that
I
had
against.
E
E
However,
this
exists
now,
but
here
is
a
statement
that
eap1559,
because
of
block
elasticity,
can
cause
some
damage,
but
it's
also
it's
in
the
in
the
case
of
longer
attack,
it's
resolvable
by
miners,
decreasing
the
boss
sizes,
and
so
sorry
I
won't
be
really
making
more
statements
about
this
one
thanks.
It
really
makes
sense,
also
lots
of
things
that
you
say
here.
O
G
I
I
don't
know
the
burn
rate
of
these.
I
would
like
you
expect
them
to
be
not
minted
anymore,
but
mainly
only
burn
from
when
we
decide
to
go
with
e,
but
I
don't
know
the
burn
rate
and
it's
not
necessarily
still
what
they
will
stay
on
forever.
It
might
be
worthwhile
for
someone
to
just
pay
and
get
rid
of
them.
I
don't
know
that
depends
how
many
there
there
are.
I
think,
marius
checked
into
this
couple.
G
D
A
Got
it
then
the
other?
The
other
argument
that
you
mentioned
thomas
was
around
testing,
so
I
guess
just
two
things
I
would
want
to
check
there
is
you
know
in
terms
of
implementation?
Would
all
client
teams
feel
like
this
is
something
we
can
implement
and
in
terms
of
testing?
You
know
is
this
something
we
think
we
can
test
properly
over
the
coming
weeks
that
you
know
we
feel
comfortable,
including
it
in
london.
G
So
if
I
can
just
speak
quickly
for
testing
we
have
performed
so
we
have
the
test
cases
written
for
good
old,
1283
and
then
for
2200,
which
did
the
nether
gas
changes.
So
we
have
quite
a
lot
of
reference
tests
covering
modifications
to
those
things
and
the
refunds
we
have
particular
fosters
particularly
written
to
try
out
various
combination
of
storage
changes
and
doing
calls
and
source
changes
and
yada
yada,
which
were
written
or
reused
when
we
wanted
to
floss
the
29.99.
G
A
P
A
A
A
F
P
P
Yes,
but
keep
in
mind
that
the
people
who
are
burning
these
are
almost
exclusively
bots
and
the
bots
and
one
inch
users,
and
so
the
one-inch
users
are
kind
of
fairly
stable.
The
bots
come
and
go
in
terms
of
their
volume
based
on
what
opportunities
are
available
and
so
those
days
where
there's
lots
of
cheaper
and
is
usually
because
there's
some
mev
opportunity.
The
bots
are
really
trying
to
leverage
heavily,
and
so
I
don't
know
that
the
the
broader
community
actually
has
much
control
over
the
burn
rate.
P
A
A
H
P
So
I'm
not
convinced
for
that,
because
the
bots
generally
will
always
burn
chi,
because
their
goal
is
to
get
their
for
their
like
high
value
transactions
when
they're
doing
gas
working
with
and
they're
putting
a
gas
price
like
a
thousand.
They
want
that
to
have
the
lowest
gas
possible
and
they're
willing
to
pay
whatever
the
charge
going
rate
is
for
cheat
tokens
for
that
transaction,
like
the
the
cost
doesn't
actually
matter
to
them.
What
matters
is
getting
their
gas
down.
H
N
Yeah,
so
I
just
quickly
wanted
to
ask-
and
this
this
could
be
like,
like
naive
or
anything,
basically,
one
possible
alternative
to
the
ep
that
I
just
will
like
that
seminar.
Just
thought
about
were
was
what,
if,
like
basically
after
1559,
you
don't
have
the
refund
like.
Basically,
the
refunded
gas
still
counts
against
the
block
limit.
So
basically,
like
refunds,
can't
don't
don't
have
any
elasticity
kind
of
properties
anymore.
N
So
say
I
don't
know
you
have
a
transaction
with
200k
a
gas
usage,
but
like
100k
refunds,
then,
instead
of
like
only
counting
400k
block
space,
it
accounts
for
the
full
200k
and
it
has
to
pay
the
the
tip
like
that.
The
tip
part
of
the
transaction
fee
for
the
full
200k
in
order
to
make
minus
indifferent
of
including
it,
but
it
still
gets
like
a
discount
on
the
on
the
base
fee
so
kind
of
like
it
would
only
have
to
pay
like,
in
this
case,
100k
on
the
base
fee.
N
That
would
be
like
just
in
case
like
if
people
are
still
kind
of
like
feeling
like.
Maybe
they
want
to
think
about
this
erp
more
and
only
included
in
the
future
folk
after
this
might
be
like
a
very
simple
change
that
would
kind
of
get
rid
of
the
elasticity
problems,
while
keeping
most
of
the
properties
of
of
refund
savings
intact.
So
I
don't
know
this
that
I
could
be
kind
of
missing
something
here,
but
maybe
this
would
be
like
a
practical
kind
of
interim
solution.
While
we
discussed
like
a
good
long-term
one.
D
B
P
A
And
it's
so
I
guess
another
thing
worth
noting
is
you
know
we
have
this?
We
basically
have
to
make
a
call,
I
think
today,
otherwise
we're
going
to
be
pushing
back
the
london
timeline.
Yes,
there
might
be
another
feature
fork
after
london,
but
we
also
said
on
the
last
call.
If
the
merge
was
ready,
you
know
we
would
do
the
merge
before
this
feature
fork
and
given
that
this
is
a
solution
that
helps
with
the
block
time
consistency,
and
this
is
also
something
we'll
want
for
e2.
A
It
might
actually
be
the
last
chance
we
get
to
make
block
times
a
bit
more
predictable
before
we
have
the
merge
yeah.
So
I
I
guess
just
to
if
this
is
something
you
know
we
need-
and
you
know
like
it's
like
you
said
that
it
solves
like
two
or
possibly
more
30
risks
yeah.
I
would
favor
including
something
today,
because
otherwise
we
we
just
might
skip
the
we
just
might
miss
the
london
deadline,
and
if
we
missed
the
london
deadline,
then
we
might
miss
the
merge.
A
A
A
Okay,
great
so
included,
I
know
yeah.
This
has
been
like
pretty
long
discussion,
but
yeah.
I
think
it
was.
It
was
well
worth
having.
So
thanks
everybody
for
for
your
comments.
It
was
the
biggest
thing
on
the
agenda.
Other
things
should
be
should
be
simpler
to
get
through
so
moving
on
at
the
next
one,
so
just
the
difficulty
bomb
delay.
A
We
agreed
on
the
previous
call
to
have
it
around
december
1st,
but
I
asked
the
e
to
be
modified
and-
and
the
champion
I
think,
is
on
vacation,
so
I
don't
know:
what's
the
best
way
to
go
about
this,
do
we
can
somebody
else
submit
a
pr
to
the
eep?
Should
we
just
have
a
sep
different
difficulty
bomb
eep
that
we
use
that
we
just
that
we
just
set
the
date
to
december
first.
J
A
A
F
F
A
Okay
sounds
good,
so
yeah,
oh
okay.
Let's
do
that
so
james
try
trying
to
get
something
out
by
the
end
of
next
week
and
alex
you
have
a
comment
in
the
chat
about
december,
not
being
too
ambitious.
We
discussed
this
on
the
previous
call
as
well.
The
reason
was
we
expect
to
either
have
the
merge
or
shanghai
ready
before
december.
We
still
don't
know
which
one
will
come
first
and
we
wanted
to
keep
the
bomb
as
a
forcing
function
to
do
that.
Yeah
and
basically
yeah.
A
A
Q
Hi
it's
pablo
here
and
we
agreed.
I
will
try
to
do
the
overview
of
that,
if
that's
fine
with
everyone,
of
course-
and
so
so,
the
bigger
picture
of
that
is
is
ethereum
object,
format
which
is
proposed
as
eip
3540,
and
this
introduces
some
kind
of
container
for
evm
evm
code.
So
it
adds
some
structure
to
the
evm
code.
Q
It's
not
it's,
not
a
sequence
of
bytes,
anymore
and
and
important
things
about
this.
One
is
that
it
starts
with
some
magic
sequence
of
bytes,
which
is
a
prefix
of
this
container
and
the
second
second
field.
There
is
the
version
number,
so
the
first
feature
it
provides
is
is
versioning
of
the
of
the
avm
code.
Q
Q
Q
Q
We
we,
we
discovered
a
way
of
doing
that
in
the
like
the
most
backward
compatible
way
by
doing
the
deployment
of
this
into
hardworks
and
because
we
need
to
come
up
with
this,
this
magic
sequence
of
bytes,
creating
a
eof
prefix
and
in
the
first
hard
work.
What
we
want
to
do
is
the
freeze,
the
first
bite
of
that,
so
no
no
longer
contract,
starting
with
this
bite,
are
allowed
to
be
deployed
after
the
the
first
hard
work
and
the
first
hard
work
is.
Q
Q
Yeah,
so
that's
I,
hopefully
I
more
or
less
explained
the
situation
and
the
the
so
that's.
Why
kind
of
we?
We
we
want
to
include
this
first,
the
first
change
as
soon
as
possible
so
later
deploying
all
the
full
features
that
it's
not
blocked
by
by
some
other
dependencies,
so
the
eip
f-3541,
we
we,
we
think
it's
it's
relatively
simple,
it's
mostly
at
when
you
create
a
contract.
You
need
to
check
if
the
the
code
to
be
deployed
doesn't
start
with
this
special
byte.
Q
Q
B
G
D
D
R
R
O
Alex
you
also
have
your
hand
up
yeah.
I
wanted
to
to
respond
to
the
what
vitalik
said
regarding
localization
and
mercalization
was
actually
considered
and
the
the
currently
proposed
format,
which
is
not
even
proposed
for
london,
but
the
currently
proposed
format
has
headers
in
front,
so
that
would
mean
that
the
first
chunk
would
have
the
headers
and
one
of
the
the
reasons
we
prefer
deploy.
Time.
I
mean
contract
creation,
time,
validation
versus
execution
time.
O
Validation
is
exactly
code
marketization,
because
if
you
would
have
execution
time
validation,
you
would
always
need
to
have
all
the
chunks,
so
that
would
just
render
mercurization
good
morganization
mode.
Regarding
the
the
address
extension
address,
extension
was
actually
one
of
the
the
motivations
to
this.
This
whole
work
with
the
state
expiry
proposal.
O
An
idea
is
that
it
would
be
easy
to
disallow
old
legacy
code
for
new
addresses
all
together.
So
I
think
there's
a
good
inter
interaction
with
these
proposals,
but,
as
it
was
stated,
address,
extension
and
state
expiry
might
might
take
upwards
of
two
years
and
it
would
be
nice
to
to
make
some
progress
on
this
topic.
You
know
before
that.
A
Worries,
I
guess
I'd,
be
curious
to
hear
from
the
different
client
teams.
Like
obviously
you
know,
we
just
barely
got
another
eep
into
london.
I
understand
this
is
a
small
change,
but
it
feels
like
we
are
kind
of
adding
small
change
after
after
small
changes
yeah
I'm
curious.
What
did
the
different
client
teams
feel
with
regards
to
including
this
in
london?
Is
it
small
enough
and
valuable
enough,
and
I
guess
future
proof
enough
that
it's
it's
worth
it.
A
A
G
M
A
I
don't
think
so,
because,
assuming
we
don't
want
to
delay
london,
we
basically
would
need
to
choose
blocks
on
the
next
call,
and
ideally
we
probably
want
to
be
pretty
finalized
in
the
implementations
before
then.
So
I
suspect
we
probably
need
to
tell
people
either
it's
in
today
and
you
have
two
weeks
to
implement
it
or
it's
it's
not
in
unless
we
delay
london,
but
I
think
we've
signaled
pretty
strongly
that
we
don't
want
to
do
that.
G
M
F
The
next
one,
I
think,
the
nuance
there
is
that
for
most
eaps,
the
next
one
means
like
where
the
features
would
happen
would
be.
Oh
we're
just
going
to
move
to
the
next
fork,
but
for
to
do
that.
For
this
one,
we're
actually
pushing
it
two
forks
further,
because
we
still
have
to
have
these
interim
steps.
R
Oh
okay,
the
if
this
doesn't
get
into
london,
then
a
case
could
be
made
later
that
this
is
redundant
with
address
extension
because
address
extension
gives
us
versioning
for
free.
So
I
vote
in
favor
of
getting
it
in
to
london.
Otherwise,
it's
gonna
sort
of
there's
gonna
be
interactions.
I
think
it's
good
anyway,
even
if
there's
redundancy,
it's
good
to
decouple
addresses
from
the
bytecode
and
then
just
have
a
piece
of
bytecode,
you
know
and
know
how
to
execute
it
without
having
an
address.
So
I
think
it's
useful
anyway.
M
R
M
O
P
G
Yes,
so
you
are
yeah.
I
also
recall
all
those
discussions
from
way
back
with
waitang
and
a
lot
of
people
were
trying
to
devise
a
scheme
to
have
both
this
kind
of
opt-in,
validation,
saying
hey,
I
want
to
play
by
these
rules
and
also
these
kind
of
validation
or
certification
rules.
That
meant
that
an
ebm
could
know
that
hey.
G
If
I
run
this
code,
I
don't
have
to
do
any
any
jump
test
analysis
because
the
it's
already
been
validated,
but
we
never
could
get
there
because
we
had
to
modify
the
accounts
in
the
state.
We
should
modify
the
state,
try
we
run
into
problems
with
well.
How
does
this
kind
of
change
if
you
have
this
new
kind
and
you
create
something
else
and
oh
it
becomes
tainted
or
does
it
before
the
same
rules,
old
rules
or
whatever?
G
G
S
A
True
of
every
eep,
though,
to
be
clear,
so
I
think
we're
kind
of
at
this
spot
where
no
matter
what
whatever
is
not
in
london,
yes,
could
be
delayed
another
year
and
we
had
a
similar
conversation
on
the
last
call
about
30
74
and
it
seemed
like
people
were
comfortable
that
you
know
we
can
aim
to
have
another
fork
after
london.
If
the
merge
happens
first,
it
happens
first,
but
yeah.
We
don't
have
the
certainty
and
I
think
that's
just
like
our
situation
right
now,
but
this
kind
of
makes
it
possible.
O
Yeah
a
couple
of
comments
maybe
to
to
greg,
if
I
understand
correctly,
maybe
you
you're
also
concerned
whether
what's
christian's
opinion
on
on
this
and
the
christian
has
been
actually
following
and
interacting
with
this
proposal.
So
he's
fully
aware
of
of
the
proposal
and
there's
an
actual
implementation
in
solidity
and
by
proposal
I
mean
3540,
which
is
not
planned
for
london
and
to
a
comment
to
to
you
micah.
O
A
Proposal
and
there
so
there's
a
comment
also
in
the
chat
I'll
just
highlight
from
asgard
that
the
eep
is
low
risk
because
it
only
reduces
functionality
and
could
always
be
reverted
in
the
future.
If
we
don't
want
it,
so
it
seems
like
people
are
generally
in
favor
like
would
anyone
have,
I
guess,
a
strong
objection
to
putting
it
into
london.
S
G
So
sorry,
if
I'm
jumping
in
so,
I
would
propose
instead,
if
it
seems
like
we
are
leaning
towards
it,
that
we
decide
to
include
it
and
then
at
the
next
meeting,
if
the
opposition
has
grown
stronger,
let's
revisit
that
decision
and
potentially
put
it
out
again,
but
in
the
meantime
I
think
it's
good
to
signal
we're
doing
that.
We
want
to
do
this
and
implementers
should
implement
it,
etc.
A
So
maybe
one
thing
we
can
do
based
on
that
yeah.
So
basically
thomas
has
a
comment
that
the
next
meeting
is
three
days
before
the
client
should
be
locked
for
london.
So
maybe
what
we
can
do
instead
is,
you
know,
make
it
considered
for
inclusion
for
london.
We're
gonna
have
a
conversation
about
like
the
devnets
right
after
this,
so
potentially
added
to
the
next
devnet,
and
if
people
feel
like
in
you
know,
in
the
next
few
weeks
we've
got
it
implemented.
It's
on.
A
You
know
a
devnet
or
close
to
beyond
the
devnet
and
there's
no
objections
that
come
out.
Then
we
officially
move
it
into
the
eep
at
the
to
the
hard
fork,
and
otherwise
we
don't,
but
at
least
we
can
move
forward
with
the
implementations
and
whatnot,
and
I
agree
there's
some
comments
in
the
chats
about
you
know.
The
eep
is
not
even
a
draft.
It's
the
first
time
it's
brought
up
on
core
devs
and
whatnot.
So
there's
some
easiness
about
uneasiness
about
yeah,
including
it
directly.
A
T
May
I
just
comment
something
I
just
joined
specifically
to
to
make
this
comment
about.
The
crp
is
that
this
specific
suggestion
about
banning
the
the
contracts
with
this
particular
starting
code,
we
could
have
presented
it
like
maybe
a
month
ago,
but
the
reason
it
wasn't
presented
a
month
ago
is
specifically
what
people
now
are
criticizing
it
for
is
like,
because
we
don't
know
what
will
come
next,
but
actually
this
whole
month
has
been
spent
by
pavilion
and
access
to
try
to
present
in
these
two
pieces.
There's
a
lot
of
text
there.
T
What
will
happen
next?
Unfortunately,
it
took
some
time,
and
you
know
we
could
have
just
put
in
the
this
very
short
phrase
like
after
the
fork
we
do
this
and
that
it
would
have
been
done
months
ago,
but
you
know,
unfortunately,
this
time
has
been
spent
on
trying
to
flesh
out
what
will
happen
next,
and
you
know
it
unfortunately
got
us
to
this
very
tight
spot.
G
T
Oh
yes,
I'm
pre,
I'm
because
I
I
am
I
am
for
it.
I
think
it's
it's
a
it's
a
it's
a
very,
very
useful
thing
and
of
course
I
am.
I
also
suggested
the
idea
about
the
this
first
step,
because
I
know
it
when
it
gets
through
it's.
Basically,
it's
a
way
to
to
stop
has
to
stop
procrastinating
of
like
what
mike
is
suggesting.
Is
that?
Okay,
let's
figure
out
what
happened
next
and
all
the
details
about
what
happened
next?
T
This
is
what
we
tried
to
do
before
for
years,
in
fact,
and
it
never
worked
because
you
know
we
never
made
the
first
step,
but
this
first
step
is
basically
get
rid
of
all
the
procrastination,
because
when
it's
done,
you
can
figure
out,
and
it's
provable
that
you
can
figure
out
the
way
to
to
work
around
of
anything
that
happens
before
the
fork.
So
in
terms
of
like
who
wants
to
deploy
this
and
that
and
we
can
always
choose
the
magic
which
will
defeat
any
adversary.
A
A
Okay,
I
guess
we'll
go
with
that,
then,
and
that
I
guess
kind
of
brings
us
yeah
to
the
devnet.
So
I
know
there's
been
a
lot
of
work
done
on
alut
in
the
next
sorry
in
the
past
two
weeks.
Does
anyone
want
to
give
like
just
a
quick
summary
of
where
things
are
at
with
that?
I
know
there
was
a
lot
of
discussion
even
this
morning,
prior
to
the
call
yeah
yo
jim.
You
want
to
go.
U
I
found
some
works
and,
as
some
general
comments,
I
think
the
testnet
needs
a
lot
more
attention
because
there
are
only
20
transactions
up
to
the
point
where
I
started
sending
some
things
in
the
next
testnet.
We
also
need
to
prevent
these
precompile
accounts,
because
that
is
not
the
case
for
the
chesnet,
and
I
also
think
that
we
should,
if
you
are
going
to
use
a
click
again,
then
we
should
use
multiple
signus,
because
I
just
noticed
this
afternoon
that
I
cannot
send
access
list
transactions
for
some
reason
or
well.
U
A
T
A
We
should
probably
have
both
in,
I
suspect,
if
we
can't
get
both
in
it's
kind
of
a
signal
that
we
probably
can't
get
both
into
london.
So
I
would
favor
leaving
the
current
one
up
waiting
until
you
know
someone
has
the
two
eips
implemented
and
then
starting
a
new
network
with
all
of
the
eips
that
were
in
the
previous
one
and
the
two
we
we
agreed
today.
G
A
Okay,
so
I
guess
we
can
probably
coordinate
offline
for
the
details
of
that,
but
at
a
high
level,
multiple
signers
pre-funding,
the
pre-compiles
having.
I
think
it
would
be
five
eeps
anyways,
like
whatever
was
in
elude
plus
the
two
today,
the
only
eep
that
would
be
in
london,
but
not
in
the
devnet,
is
the
difficulty
bomb.
One
and
yeah
I
think
light
giant
had
proposed
a
name
for
it
on
the
discord.
So
baikal,
I
think,
was
the
second
fault
line
that
we
had
after
elute.
T
T
A
T
A
So
we
we
we
discussed
it.
I
think
it
was
two
three
calls
ago
and
people
were
strongly
in
favor
of
keeping
it
but
yeah.
If
I
guess
definitely
we
don't
have
time
in
the
next
six
minutes
to
go
over
this,
and
I
guess
if
we
want
to
discuss
it
again
in
the
next
call.
It's
it's
fine,
because
we
it's
like
a
small
technical
change
and
we
don't
need
it
for
the
devnets
yeah.
Does
that
make
sense.
T
A
I
guess
yeah
just
back
to
the
devnet,
so
I
can
put
together
a
spec
today
and
I
guess
I'll
follow
up
so
I'll
post
it.
But
clients
will
need
time
to
implement
these
two
eeps.
So
I
suspect
we
probably
won't
get
it
up
next
week,
but
maybe
the
week
after
that
so
I'll
make
sure
to
follow
up
like
a
week
from
now
to
see
what
the
status
for
the
different
teams
are
and
and-
and
you
know
what
we
can
do
with
regards
to
the
to
starting
the
the.
A
Devnet
and
I
guess
two
more
things
we
had
on
the
agenda-
there
are
kind
of
more
announcements
than
anything
else,
but
next
week,
at
the
same
time,
as
this
meeting
starts,
we
plan
to
have
a
infrastructure
readiness
breakout
room
for
london.
So
there's
been
a
lot
of
talk
on
the
discord
about
having
infrastructure
providers
ready
to
support
london
and,
and
you
know,
having
clients
kind
of
enable
them
with
stuff
like
the
json
rpc,
apis
and
whatnot.
A
So
if
I
guess
you
are
an
infrastructure
provider,
that's
like
affected
by
london,
this
would
be
kind
of
the
right
place
to
show
up
with
your
concerns
or
questions
I'll
post,
the
link
in
the
chat
here.
It's
also
on
the
ethereum
pm,
repo
yeah.
So
just
hopefully
we
can
get
different
yeah
different
teams,
working
yeah
working
on
infrastructure
to
to
be
ready.
We
don't
need,
like
all
of
the
client
devs
to
be
there.
A
K
No,
that
was
the
big
thing
and
I
guess
the
other
component
is
that
similar
to
how
eips
and
clients
readiness
are
tracked.
Typically,
in
that
same
place,
we'll
also
be
tracking.
You
know,
libraries,
tooling
and
other
infrastructure
providers
leading
up
to
the
fork
you
know
for
which
eips
they've
implemented
and
their
general
readiness
I'll
drop
the
link
in
the
chat.
A
Cool
and
I
guess
the
last
quick
announcement
was,
we
discussed
on
the
last
call
potentially
picking
blocks
for
london
today.
That
feels
still
a
bit
premature.
I
guess
given
today's
discussions,
but
if
we
do
want
to
have
a
client
freeze
on
the
next
call,
then
we
we
should
pick
some
blocks
by
then.
So
if
people
want
to
look
at
the
the
dates
and
and
propose
some
blocks
over
the
next
two
weeks,
that
would
be
really
valuable.