►
From YouTube: Ethereum Core Devs Meeting #88 [2020-05-29]
Description
A
B
C
C
C
C
C
Thank
you,
so
we've
had
the
eligible
for
conclusion,
has
been
the
step.
I,
think
it
just
kind
of
gives
people
some
context,
so
we're
looking
at
separating
the
EIP
standardization
process
and
the
network
upgrade
process,
and
we
already
have
this
natural
step,
which
is
efi
as
part
of
the
first
part
of
the
network
upgrade
process,
and
this
we
buy.
C
It's
really
important
the
community
realizes
that
these
are
meant
for
integration
testing
between
clients,
not
for
deploying
your
dev
code
or
testing
your
things
on
production.
There
are
other
test
nets
that
are
that
can
be
used
for
that
like
this,
will
it
will
be
nuked?
Is
the
disclaimer
I
put
a
very
large
one
up
there,
and
so
the
current
specification
for
that
is
EIP
to
537,
which
is
the
BLS
curve.
Bls
pre-compile,
and
I
marked
that
that
is
in
a
that.
Eip
is
in
the
state
that
the
clients
need
to
get
to
that
point.
C
We
have
decided
not
to
include
it
based
on
some
feedback
from
the
open,
aetherium
team,
at
least
not
and
when
I
say
not
include
I
mean
not
have
it
be
part
of
this
specification
as
soon
as
there
are
as
a
version
of
it.
That
makes
sense
it
can.
The
ephemeral
testing
can
be
dip,
can
be
redeployed
and
it
isn't
saying
anything
about
whether
it
will
anything
about
maintenance
to
be
Tripoli
clear
and
then
this
is
a
way.
C
I've
been
tracking,
getting
ready
for
it,
and
this
is
kind
of
a
subversion
of
the
like
the
proverbial
in
the
IP
that
the
birth
of
the
spreadsheet
that
puja
put
together
so
clients
signalling
their
intention.
Then
they
agree
on
the
specification
which
that
hasn't
happened
yet
because
we're
still
looking
to
finalize
it's
2,
3,
1,
5
and
then
after
they're
merged
and
clients
have
merged
those
changes.
Then
we
can
roll
out
the
testament
that
syncs,
all
of
them.
E
E
Yeah,
that's
bigger,
I.
Think
the
first
case
is
that
I've
been
recently
our
named
Berlin
and
I
mean
they
they
can
be
regenerated,
but
pleased
and
I
think
we
should
regenerate
them
to
Yolo
b1,
but
yeah
I
just
wanted
to
say
preemptively
that
trying
should
not
merge
activate
all
these
things
under
the
name
Berlin
in
my
opinion,
but
under
Joel
obi-wan.
E
So
what
I
can
see
as
a
problem
if,
if
we
start
putting
out
things
which
says
they
are
Berlin
and
our
Berlin
activatable
and
someone
updates
to
that
client
today
and
doesn't
do
anything
for
another
six
months
and
then
we
roll
up
the
real
Berlin
and
he
sits
with
an
old
client
that
hey
it
has
pretty
and
already
way.
I
don't
have
to
do
anything.
Then
we
might
buy
meat.
The
problem,
okay,
that
makes
sense
yeah.
C
A
E
So,
let's
call
it:
the
original
2015
has
been
changed
regarding
the
gas
cost
and
I
have
a
currently
open
PR
to
change
the
gas
costs
a
bit
and
I
think
everyone
I
think
it's
been
given
a
general
thumbs
up.
I
haven't
really
heard
from
open
ethereum
on
this
recent
change,
but
now
that
B
sue
at
least
has
approved
it
and
updated
the
tests
accordingly.
E
But
if
I
can
just
get
a
thump
up,
I
would
merge
that
and
on
the
other.
So
the
other
part
of
the
subroutine
is
whether
or
not
to
apply
the
restrictions
proposed,
oxic
and
right
a
snare
and
people
that
discussion
is
told
it's
the
longer,
but
for
the
test
net
I
think
we
agreed
to
use
the
non-restricted
subroutine
proposal
from
Greg
right,
yeah
yeah,
but
if,
if
just
if
we
just
if
I'm
just
gonna
go
ahead,
like
I
will
take
the
merge
button
on
this
and
I
think
we're
finalized.
D
D
C
C
C
F
F
Go
with
that
now,
so
what
I
mean
is
currently
the
three
up
codes?
Have
the
three
instructions
have
enough
code
like
B
to
b5
b7,
or
something
like
that
and
there's
a
suggestion
to
get
user
linor
opcode
space
somewhere
else,
so
the
opcode
here
means
textual
and
byte,
which
is
on
the
bite.
The
instruction
is
steep.
What
at
bite
is
doing
I.
G
F
It
does
today
extend
that
so
far
we
every
single
opcode
we
have
is
leaner.
We
don't
have
like
gaps,
random
gaps
mostly,
but
this
this
would
open
just
like
a
new
page
in
the
in
the
opcode
table,
with
the
gaps
in
between
the
only
only
real
effect
I
can
see
is
it
goes
back
to
what
is
the
goal
of
the
test?
It
is
the
goal
of
this
test
net
for
only
for
clients
to
to
interact
with
each
other
and
I've
like
a
place
where
people
can
try
to
break
it.
H
G
Okay,
but
I,
don't
think
that
the
whole
whole
issue
here.
So
if
the
original
issue
is
that
we
don't
want
to
leave
a
gap
and
just
change
this
back,
so
that
there's
no
gap
and
done
I
mean
I,
don't
think
anybody
cares
about
the
OP
code.
So
if
there's
even
a
slight
reason
why
you
would
want
to
change
it
just
change
it.
E
C
G
So
forget
that
PR
is
a
bit
hanging
in
the
air
so
about
two
weeks
ago.
We
we
started
just
really
heavily
testing
it.
We
doing
it
Martin
and
Mary
started,
passing
it
and
well
the
bomber
side
of
it
is
that
I
personally
found
at
least
three
concerns
issues
on
the
crusher,
Martin
and
Marcus
found
some
Crashers.
They
also
found
a
consensus
issue
in
the
assembly
code,
where
they,
just
essentially
the
PR
ships
ago
implementation
and
two
variations
of
assembly,
implementations
and
the
assembly
codes
did
not
match.
G
I
mean
there
were
some
carry
issues
or
for
certain
inputs
they
just
produce
different
outputs
and
we're
talking
about
14th
lines
of
assembly
code
and,
while
the
author
of
the
PR
iterated
a
bit,
but
essentially
what
you
guys
need
to
know
is
that
so
Martin
and
Maurice
found
an
issue
in
assembly
code.
The
response
was
that
here
I.
Let's
just
add
these
ten
lines
of
assembly
code
because
whoops
we
forgot
about
a
carry
then
later
Maurice
was
asking.
Why
is
this
algorithm
so
complicated?
The
response
was
yeah.
G
Well,
maybe
we
can
just
cut
this
algorithm
out
and
that
we
can
get
rid
of
four-fifths
of
the
assembly
code
and
then,
on
top
of
all
of
this
on
Monday,
the
PR
was
updated
and
old.
Existing
assembly
code
was
deleted
and
we
just
got
fourteen
thousand
lines
of
brand-new
assembly
code.
So
at
this
point,
I
honestly
cannot
imagine
how
anyone
would
expect
us
to
actually
merge
this
and
fork
this
into
a
life.
That's
not
one
essentially
denied.
We
almost
got
it
and
replaced
four
days
ago.
I
I
think,
two
weeks
ago,
I
made
amends
on
get
your
chat
sets.
If
you
have
any
doubts
about
assembly
code
itself-
and
you
don't
want
to
check
it,
then
just
there
is
a
pure
go
implementation.
You
can
ask
you
just
use
this
one
and
always
decorated
its
feed
center,
the
window
or
gas
prices
which
were
proposed
in
SAP,
recompile
and
I.
Think
no
one
ever
thought
about
it
and
try
to
make
this
decision.
I
G
Problem
is
not
with
the
assembly.
The
problem
is
that
the
problem
is
that
we
found
issues
in
the
assembly,
so
the
problem
is
that
the
PR
wasn't
fast
against
it
own
itself.
So
the
our
mania
problems
is
that
we're
rushing
into
it's
fine
to
have
assembly,
but
it
is
not
really
fine
to
rush
into
a
fork
when,
when
the
implementation
itself
wasn't
properly
vetted,
so
that's
that's
mostly
my
concern,
but
maybe
market.
You
had
some
other
thoughts
because
they
were
the
one
that
we
buzzing.
There's
something
I.
E
E
We
will
also
need
to
replicate
the
benchmarking
and
make
sure
that
the
goaline,
the
gas
implementation
pure
goal
and
based
on
the
gas
schedules
I
mean
it
theoretically,
doesn't
stop
us
from
merging
something
for
the
test
that
but
I
think
we're
kind
of
skeptical
of
going
live
with
anything.
This
one
highlight
that
going
live
with
anything
on
a
near-term
future.
Oh.
I
Well,
first
of
all,
as
far
as
I
know,
Maurice
has
eaten
has
kind
of
fix.
The
problem
was
linking
out
the
go
rapper
for
Rast
library,
which
actually
could
allow
to
differentially
tests,
library
against
library
without
client
integration.
Of
course,
if
we
assume
that
openness
here
iam
would
include
my
PR
in
terms
of
integration,
when
I
was
doing
quasi
testing
myself
well,
I
did
it
against
the
assembly,
which
is
like
which
didn't
have
problems
and
crashes,
and
they
don't
have
any
divergences
with
rust
implementation.
I
E
I
Actually
don't
know:
what's
your
strategy
on
building
is
a
father
so
far.
My
observations
were
that
if
initial
corpus
is
kind
of
seeded
with
test
vectors
from
kind
of
consider
related
tests
from
my
repository,
then
more
or
less
I
didn't
see
that
father
has
ever
found
new
branches,
it's
more
or
less
means
that
cannot
test
any
further
for
for
kind
of
plain
errors
and
crashes
in
other
branches
of
code
and
actually
making
the
inputs
or
which
I
up
really.
Well
it
it's
not
that
hard
and
I
think
I
have
it
written
already
turn.
I
E
I
C
G
C
G
G
G
A
I
I
E
C
A
D
J
Yeah
I'm
gonna
call
that's
for
the
BLS
will
be
probably
working
on
me
this
weekend,
so
I'm
thinking
of
two
things.
First
of
all,
I'll
check
if
it's
possible
to
just
do
it
with
the
harami
codes
that
we
have
now
or
is
it
actually
introducing
some
additional
operations
that
are
only
possible
with
the
with
the
PRS
from
all
X
and
then
we'll
just
write
the
wrapper
for
C,
sharp
and
and
I'll
try
to
provide
it
to
the
get
in
to
do
some
fuzzing
together.
But
I
can
do
any
promises
for
this
weekend.
A
Perfect
next
up,
we
have
EFI
review
for
the
EIP
2046
in
the
IP
2565
I
copy
pasted
these
from
the
last
agenda,
but
I
think
you
addressed
earlier
James
that
at
least
for
2565,
that's
something
where
it
wasn't
because
of
an
something
with
open,
aetherium
we're
not
going
to
go
forward
with
that
on.
This
Fork
is
that,
is
that
what
you
mentioned,
or.
C
A
G
A
I
This
this
approach
was
included
in
his
results,
which
he
also
published
for
repricing
of
specific
free
compiles
and
else's
a
chat
function
in
EVM
itself,
more
or
less
work
justly
presents
what
is
a
first
of
all.
What
is
the
performance
right
now
in
at
the
current
state
of
clients
of
go
of
gas
and
openness?
You
and
second,
the
pricing
formulas
are
more
complicated
in
a
sense
that
they
no
longer
always
operate
on
sums
like
price
per
hashing
of
32
bytes
of
the
input.
I
Now
pricing
depends
on
internal
structure,
for
example,
the
hash
functions
which
accept
input
by
blocks,
which
are
not
always
equal
to
certain
two
bytes,
so
kind
of
different
ranges
of
input.
Lengths
will
result
into
the
same
price
for
kind
of
actual
computation
spent
on
evaluating
their
hash
function
like,
for
example,
4kj
function.
The
in
boot
lengths
must
be
chunked
into
136
bytes
and
like
no
so
we're
caching
like
zero
and
the
country
bytes
that
we've
seen
from
purpose
of
actual
time
spent
on
computation.
I
All
this
is
reflected
in
formulas
LC,
because
the
call
cost
was
reduced
to
zero.
It
also
would
require
to
increase
the
price
of
PM,
add
and
multiply.
Every
compiles,
being
multiplied
is
kind
of
negligible
change
and
be,
and
ads
should
be
pumped
like
I
think
twice
and
something,
but
it
still
would
result
in
the
net
costs
which
much
smaller,
which
are
smaller
for
end-users
Mullis.
This
is
just
a
proposal
to
get
the
pricing
interline
with
actual
performance
and
efficiency.
A
I
Oxy
kind
of
asked
to
removes
the
direct
proposal
to
reduce
precompile
call
cost
to
zero
from
to
666.
That's
why
I
at
least
2046
mod
X
and
another
one.
We
should
remember
by
number,
which
assigns
first
I,
think
thousand
and
twenty
for
the
numbers
of
address
fest
and
space
to
bring
compiles,
but
more
or
less,
though
so
logically
kind
of
come
all
together.
I
If
we,
if
one
reduces
a
call
to
break,
compile
to
zero
or
maybe
not
some
nonzero
number,
then
it's
necessary
to
check
that
all
pricing
is
not
affected
by
this
and
there
are
no
internal
compensation
in
pricing.
Or
is
this
fact
that's
why
mod
X
pre
pricing
is
also
tend
to
freak
fired
and
for
all
other
pre
compiles.
I
A
F
Yeah,
it
was
so
I,
don't
don't
remember
now,
but
it's
it's
in
the
discussion,
the
link
to
the
the
previous
or
could
have
call
probably
a
month
or
two
ago
when
we
discussed
this
last
and
I.
Think
during
that
call.
So
this
is
what
I
commented
on
to
666
and
during
that
call
we
agreed
that
the
the
actual
number
proposed
in
24:46
is
not
the
final
number.
F
It
was
to
be
determined
through
I,
guess,
benchmarking
and
in
that
awkward
call
if
I
felt,
if
we
were
on
the
opinion
that
it
would
make
sense
to
extend
2046
but
like
the
final
proposed
number
and
introduced
the
restrictions
for
the
BN
precompile,
and
we
also
suggested
to
you
to
maybe
do
the
other
repricing
set.
Radley
and
I
think
it
would
be
better
just
to
have
like
a
more
focused
call
regarding
this
and
not
all
cadets.
A
C
Can
do
that?
Okay,
there's
people
who
are
interested
and
messaged
me
and
I
can
I
have
made
a
theory
MPM
calendar,
so
this
would
be
something
I
would
add
to
it,
and
I
can
add.
Whoever
would
like
to
be
invited
to
the
call
to
beyond
the
list
before
that
and
then
I
X
Eclipse
figure
out.
When
would
be
a
good
time
after
this
call
sounds
good.
Okay,.
H
So,
just
a
quick
update
two
weeks
ago,
when
we
came
in,
we
had
to
pass
forward
for
the
repricing.
One
was
simple:
parameter:
change
and
updating
the
open,
aetherium
library
and
the
other
one
was
a
slightly
more
complicated
pricing
formula
and
not
changing
the
open,
aetherium
library.
What
we've
decided
to
go
with
is
the
the
pricing
formula
change,
so
we
did
work
with
artem
on
the
open,
aetherium
team
to
see
if
we
could
put
in
a
different
library.
Unfortunately,
there
was
some
compilation
problems
on
windows
with
that
library,
so
we
won't
be
going
that
route.
H
So
at
this
point
in
artem
has
has
implemented
a
draft
PR
for
the
pricing
formula
change.
I
am
in
the
of
revising
the
EIP
to
reflect
what
you
know
the
specifics
of
exactly
what
the
new
pricing
formula
change
should
be,
and
then
the
next
step,
once
that's
done,
I,
can
share
that
with
the
the
guest
team,
and
hopefully
we
can
get
a
draft
PR
there.
So
I
think
we've
got
the
path
forward.
A
A
K
A
couple
of
deaths
from
the
increment,
of
course
it
was
yesterday,
so
first
is
about
the
PR
about
removing
the
block,
size
and
transaction
size
writers
from
this
it.
So
the
plan
was
to
create
a
separate
IP
for
the
writers,
and
then
we
would
have
to
decide
if
we
want
to
make
that
dependency
for
the
1559
or
not.
So
this
is
the
first
update,
so
I
don't
know
if
we
can
merge
the
PR
about
removing
the
writers
or
not,
basically,
I
don't
know
if
you
want
to
start
testing
it
with
our
result,
the
writers.
K
K
Ccip
is
designed
with
the
transition
phase
in
it.
So
what
if
we,
if
you
want
to
start
directly
with
with
it,
1559
rules
on
the
consortium
network,
for
example,
or
so
yeah,
we
discussed
about
simulation
versus
test
net.
So
we
have
some
discussion
with
a
yin
yang
from
recognized
and
barnaby
about
simulation.
So
what
would
be
the
best
path
to
test
the
CIP?
K
Do
we
want
to
deploy
some
test
net
and
and
play
with
real
users,
or
do
we
want
to
implement
some
agent
simulators
and
last
about
stages
about
the
escalator
chip
approach,
which
is
a
narrative
of
the
zip
or
also
we?
We
talk
about
the
possibility
of
combining
them
so
yeah.
This
is
also
topic.
We
we
have
to
discuss
yeah,
that's
it.
A
A
E
E
Leave
it
aside
so
yeah
last
one
is
pretty
trivial
suggestion
from
me
and
actually
can
Powell
and
I
think
a
couple
of
people
have
been
touched
touching
the
same
idea.
We
should
place
then
limit
on
the
size
of
any
code.
We
chose
not
limit
to
be
twice.
The
size
will
be
the
variable
code
size
and
a
reasoning
being
twofold,
one
that
init
code
can
be
used
to
attack,
jump
test
analysis
and
it
passed
thing
down
historically
in
2017
and.
E
Even
if
yeah
so
there's
also
one
more
possible
future
motivation
for
this
if
we
implement
subroutines,
which
are
restricted,
because
if
we
do
so
than
the
jump
test,
analysis
become
a
bit
more
complicated
and
thus
it
becomes
even
trickier
for
clients
to
do
to
protect
themselves
against
attacks
of
this
kind.
So,
regardless,
if
we
go
that
route
or
not,
this
would
be
a
good
thing
to
have
it's
my
take
on.
A
A
L
So
medicine
from
the
theorem
counters,
the
IP
IP
group,
as
working
on
a
on
a
survey
getting
stakeholder
feedback
just
a
reason
on
why?
How
so
the
IP
IP
group
is
for
the
EAP
improvement
process,
improvement
hum
implies
change
changed
another
posit.
The
way
this
can
be
done
through
their
moving
towards
something
or
moving
away
from
something
so
moving
towards
a
goal.
Setting
moving
away
is
problem-solving.
L
So
a
way
to
do
this
is
we
decided
to
go
with
problem-solving
way
to
start
solving
problems
is
to
first
identify
them
and
to
get
that
from
a
community
is
can
be
done
through
a
survey.
So
we
asked
mostly
emotional
questions.
What's
your
biggest
frustration
and
what
should
be
its
fear
with
current
EAP
process,
frustrations
are
a
good
signal
to
see
current
problems
and
fears
are
good
signal
to
see
problems
that
people
first
see
so
the
results
of
that
survey.
We
always
has
a
few
other
questions
such
as.
L
L
As
far
as
the
results
found
for
the
fears
and
frustrations
they
fit
in
three
categories
which
we
can
make
into
a
roadmap
for
the
next
few
steps.
Those
categories
are
formalizing
decision,
making
increasing
clarity
in
the
process
and
within
the
specifications
and
increasing
the
capacity
to
push
a
ipsec
completion,
so
will
most
likely
automatically
be
in
that
order,
decision-making,
clarity
and
then
increasing
capacity.
L
So,
currently
our
career
discussions
I've
been
around
decision
making,
namely
how
can
we
separate
the
EAP
process
in
the
Hartford
quinary
coordination
process
to
make
both
those
processes
more
clear?
Also,
how
can
we
make
decision-making
more
independent?
Why,
of
course,
so
how
can
we
make
this
is
making
asynchronous
from
the
live?
Calls
that
we
have
every
two
weeks?
A
C
A
A
Okay,
the
last
item
review
previous
decisions
made
and
any
action
items
taken.
So
we
have
the
notes
here,
thanks
to
Brent
and
Jim
for
doing
the
notes.
Decisions
made
eighty-seven
point
one
from
last
time
is
that
both
AIP
23
15
and
25
37,
so
subroutines
and
the
BLS
curve
have
been
accepted
into
Berlin.
The
ephemeral
Berlin
test
net
named
Yolo
to
test
these
Berlin
di
peas
is
going
to
be
created.
A
Eighty-Seven
two
point:
one
twenty
three
fifteen,
twenty
five,
thirty
seven
and
2565
might
be
included
in
Yolo
I.
Think
is
what
the
note
is
describing
they're
looking
at
it
a
little
bit
closer
I,
don't
know
if
2565
is
gonna
be
going
in
necessarily
anymore.
That's
still
pending
some
stuff,
so
that
decision
item
needs
to
be
clarified
a
bit
further.
That's
eighty
seven
point,
two
point
one
so
87.3
2046
is
pending
results
from
an
open,
aetherium
benchmark.
That's
been
somewhat
updated
today,
I'd.
A
Resolved
okay,
eighty-seven
point
for
simple
subroutines
from
the
EVM
for
the
EVM.
Twenty
fifteen
has
some
outstanding
specification
issues
get
resolved
by
Tuesday,
with
a
call
that
also
got
resolved
and
there's
next
steps
on
that
87.5.
The
last
decision
made
from
the
last
notes
the
BLS
curve
operations.
Eip
25:37,
is
going
to
have
a
pre
compile
listed
by
Alex
blasts
off
by
early
next
week.
To
make
it
final
Alex
did
you
include
the
pre
compiled
list
into
the
BLS
curve
operation
EIP.
A
Okay,
cool
actions
required
there's
seven
of
these
eighty-seven
point,
one
a
decision
required
on
looking
at
the
smart
contract
code
for
simple
subroutines
that
was
addressed
by
the
meeting.
A
six
point:
two
that's
from
two
meetings
ago,
completed
last
week,
James
to
reach
out
to
Alexi
for
Merkel
ization
and
simple
subroutines.
A
A
C
A
A
F
A
Great
then,
that's
resolved
okay.
So
that's
all
the
decisions.
From
last
time,
I'm
gonna
go
over
the
decisions
to
be
referenced
on
the
notes,
this
time
we're
not
decisions
but
I,
guess
action,
items
and
I'll
mention
if
it's
a
decision
as
well,
so
continuing
to
update
the
ephemeral
test,
net,
yellow
meta,
hypee
and
Berlin
EIP
is
a
continuing
action
item
that
James
is
going
to
handle.
A
James
Hancock
will
follow
up
with
open
etherium
acts,
ik
and
Martin
to
discuss
AIP
2315,
simple
subroutines
after
this
call
to
merge
changes
boom,
I,
don't
know
if
I,
don't
think,
that's
the
one.
That
requires
a
call.
That's
the
other!
That's
the
next
thing,
I'm
talking
gonna
talk
about
and
then
James
to
coordinate
with
axe,
ik
and
interested
parties
on
a
precompiled
gas
cost
changes
call
sometime
in
the
near
future
and
then
finally,
the
last
item
Kelly
to
continue
working
with
open
aetherium
team
for
the
EIP
2565
repricing
of
mod
exp
pre-compile.
C
D
A
E
A
F
A
A
D
A
E
C
C
So
we
we've
been
talking
about
updating
statuses
for
the
IP
sanitization
process
and
having
final
being
I,
get
that
a
specification
is
in
the
final
state
and
that
that
and
then
having
that
be
separate
as
to
if
that
is
to
be
included
or
not.
So
this
might
actually
be
a
good
test
case
for
that,
where
we
could
make
the
EIP
this
version
of
it
final
just
so
it
can.
K
A
No
problem,
okay,
and
thanks
for
that
update,
yeah
these
these
charts
are
nice.
We
had
really
good
conversations
about
them
last
the
IP
IP
meeting
and
have
some
notes
for
the
video
for
those
interested
who
want
to
go
to
the
etherium
cat,
herders
github
to
the
e
IP
IP
repo
we
have,
and
also
on
our
youtube
channel.
We
have
the
video.