►
From YouTube: Ethereum Core Devs Meeting #67 [2019-08-02]
Description
A
A
A
A
B
B
Last
time
around
we
had
a
decision
to
have
a
list
of
both
tentatively
accepted
eeap's
and
property
accepted,
eats
and
try
to
get
client
implementations
for
all
of
them
and
then,
depending
on
how
far
along
we
would
get
with
those
to
potentially
split
the
stem
bowl
in
the
two
upgrades,
so
one
that
would
be
scheduled.
This
fall
and
another
one
early
next
year.
C
D
Alright
nevermind,
we
have
the
eight
one,
three,
four
four:
we
have
twenty
twenty
eight
and
the
remaining
two
we
are
starting
soon.
We
don't
have
profile
it's
about
adding
the
bindings
for
the
library
us
up
to
go
before
about
it,
laughing
easy
arithmetic.
We
we
are
waiting
here
for
some
decisions.
Whether
this
will
be
coming
in
everything
else
seems
to
be
rather
small.
E
B
B
Okay,
so
the
second
second
part
of
of
this
agenda
item
was
a
last
call
for
any
eeap's
that
want
to
be
considered
for,
like
the
tentatively
accepted
section.
So
in
practice
this
means
you
know
very
unlikely
for
the
October
part
of
the
fork,
if
it's
split
but
possibly
for
the
January
part.
So
anything
that's
already
been
proposed
in
for
assemble,
but
that
that
hasn't
been
accepted.
Yet
so
does
anyone
have
opinions
or
suggestions
here.
G
G
I
can
elaborate
on
why
I
guess
in
some
ways
it
carries
the
torch
for
six
one
five.
There
was
a
call
a
few
months
ago
and
during
the
six
one
five
discussion,
people
ask
for
benchmarks
to
show
what
kind
of
speed
improvements
could
be
expected,
and
so
it
turns
out
huge
speed.
Improvements
are
possible
even
without
introducing
subroutines
and
changing
how
it
jumps
work
and
we
publish
benchmarks
showing
big
speed
ups
that
are
on
the
table
and
so
from
the
awesome
teams
perspective.
G
One
of
the
big
potential
benefits
of
azam
was
the
speed
up.
Well,
it
turns
out
that
you
get
a
fixed
speed
up
if
you
just
optimize,
maybe
I'm
on
the
client
and
which
will
be
a
lot
easier
and
having
much
sooner
than
integrating
Wow's
them.
So
I
think
its
first
say
that
radius
ting
gas
costs,
as
the
main
priority
of
the
he
wasn't
came,
so
we're
definitely
interested
in
that
one.
C
G
Yep,
that's
a
good
point
and
that's
something
we
want
to
work
on
so
yeah.
Obviously
that
a
new
gas
schedule
would
you
know
we
would
not
won't
have
enough
time
to
propose
propose
that
by
you
know,
for
the
ACE
tabular
part
one,
but
for
the
the
follow-up
I
think
there's
plenty
of
time
to
propose
that
and
I
mean
once
you
have
the
scud
once
you
have
the
the
new
gas
cost
table,
then
the
implementation
is,
you
know,
is
fairly
trivial,
with
the
exception
of
versioning.
G
I
F
B
Yeah
there
was
that
comment
and
Alex
left
a
comment
also
around
potentially
having
so
first
comment
around
having
like
team
attic,
hard
Forks.
If
you
want
and-
and
the
second
comment
was
about
Istanbul
saying
you
might
be
nice
to
focus
on
on
gas
repricing,
because
we
already
have
1108
1884
as
tentatively
accepted,
it
might
make
sense
to
oh
and
and
2028,
it
might
make
sense
to
also
consider
2045,
which
was
I
believe
the
one
just
discussed
2046
and
2200
I
thought
they
just
have
like
this
focused
around
around
gas
cost
changes
so
weird.
B
C
So
11
on
I
was
on
the
list
is
rejected,
withdrawn
and
those
this
list
for
the
rejected
withdrawn
was
they
didn't,
have
a
reference
implementation
two
weeks
ago,
so
they
were
declared
out
of
scope
for
Istanbul
the
same
with
the
the
one
about
the
fee
market
change,
because
there
is
no
prototype.
All
there
is
is
still
designs
going
on
with
it.
On
that
doesn't
mean
it's
dead
in
general,
work
should
progress.
H
Yes
and
I
I
would
say
that
that
fits
with
talking
about
the
October
hard
work.
There
is
a
conversation,
I
think
that's
worth
having
when
thinking
about
a
January
or
February
other
hard
fork,
specifically,
if
we're
talking
about
having
rebalancing
and
repricing
really
come
together
within
these
two
forks,
because
we
just
we
just
released
today,
a
a
like
a
full
implementation,
I'm
trying
to
remember
the
word
implementation
study
of
what
it
would
take
to
do.
1559
and
up
we
can
I
can
go
into
that
woman.
It's
time
to
talk
about
that.
G
C
B
C
A
A
H
No
and
for
me
that
for
those
kind
of
guests
costs
or
ones
we're
talking
about
gas
cost,
that's
like
the
what
should
be
the
barrier
for
them
to
being
moved
from
tentatively
accepted
to
actually
getting
in
I
guess
is
the
changes
are
small,
but
instead
of
having
a
lot
of
work
around
limits,
implementations
and
testing,
there
should
be
a
lot
of
work
about
investigating
the
effects
of
the
gas
changes.
Well,.
A
G
I
mean
there
there
is
a
pretty
good
benchmark
system,
a
couple
of
them
actually
the
one
for
pricing
pre
compiles
and
both
when
we're
done
by
Marcus
Wendy,
but
where
it
gets
complicated.
With
this
2020
46
I
mean
the
the
benchmark
scripts
they'll
benchmark
the
pre
compiles
themselves,
but
not
really
considering
calling
them
from
other
contracts,
but
it
doesn't
seem
like
at
the
whole
point.
The
the
IP
explains
that
it's
just
reducing
the
cost
back
from
you
know
when
it
was
raised.
G
G
D
Generally
think
that
just
analyzing
the
existing
contracts
when
bringing
gas
down-
maybe
it's
not
the
most
important,
think
in
a
way
that
we
could
this
way
explore
any
security
issues
like
we
cut
in
with
1283,
but
performance,
wise
I
think
we
should
be
much
more
worried
about
bringing
the
gas
much
down
and
then
someone
posting
the
contract
that
would
spin
the
EVM
the
same
thing
and
if
it's
underpriced
it
can
close.
The
trouble
is
in
the
past.
A
Yeah
so
I
mean
I
mean
I'm,
just
security
focused
generally
speaking,
so
I
completely
agree
with
what
you're
saying
in
terms
of
what
the
engineering
exercise
should
be,
but
the
approval
process
should
include
I
mean
we
should
be
able
to
literally
analyze
all
the
existing
contracts
on
chain
and
say
that
this
isn't
going
to
cause
any
of
them
to
become
a
Doss
factor.
I
I'm
not
trying
to
make
extra
work
for
people.
It
just
seems,
like
we've
already
run
into
this
problem
once
and
it's
in
something.
A
That's
like
very
well
understood
to
be
a
hard,
but
just
a
hard
thing
to
into
it.
So
I
feel
like
since,
when
you
spend
so
much
time
again,
I
think
it's
important
to
fix
the
gap.
You
know
to
improve
gas,
and
so
we're
gonna
spend
a
lot
of
time
doing
it.
So
why
not?
Just
you
know,
run
some
tests
to
make
that
process.
You
know
formalize
some
tests
to
make
that
process
better.
C
G
B
So
this
meeting
was
the
last
one
to
move
to
tentatively
accepted
and
I
think
even
that
it's
probably
probably
means
more,
the
second
part
of
Istanbul
if
it's
broken
down
than
the
first
one,
and
so
that's
just
why
I
was
asking,
because
if
there's
some
we
need
we'd
like
to
have
in,
we
probably
should
discuss
them
today
and
and
try
to
get
consensus
on
them
rather
than
waiting
a
few
more
weeks
there
to
do
that.
I.
H
Would
support
them
in
with
the
with
the
as
conditions
that
you
had
said
where
the
tentatively
most
of
the
ones
that
are
intended
ly
executive
have
some
kind
of
implementation
that
is
tricky
to
test
and
gas
ones
have
their
own
specific.
One
and
I
feel
that
is
totally
fair
to
to
put
them
in
that
category,
because
if
they
don't
get
it
done
in
the
next
a
little
bit
then
their
first
route,
but
they
can
at
least
be
in
attendance,
fully
accepted
and
not
in
the
out
of
bucket.
B
B
D
B
Okay,
yes,
yes,
so
you're
working
from
the
meta
EEP
I
was
just
looking
at
the
agenda
and
the
comments
that
people
have
in
there
we
can.
We
can
definitely
go
through
the
list
of
proposed
because
it's
pretty
small
and
the
only
one-
that's
yeah,
not
in
that
and
was
rejected
as
the
1559,
which
James
mentioned
earlier,
on
the
call
that
he'd
still
like
to
discuss
given
their
the
report
from
today.
B
C
C
F
Don't
know
how
how
I
feel
about
accepting
it
or
like
doing
it
without
discount
versioning,
because,
as
and
reposted,
he
already
wrote
a
test
that
breaks
that
would
be
broken
with
the
multi
by
top
code.
I
mean
Pavel
suggests.
Just
can
the
current?
Could
the
current
contracts
to
see
if
this
would
affect
any,
but
still,
even
if
you
don't
affect
any
at
the
moment
or
if
you
can
get
like
confirmation
that
most
contracts
wouldn't
be
affected?
G
B
I
I,
don't
recall
much
discussion
on
the
core
dev
Scala
ballot,
either
at
the
very
least
kind
of
in
the
in
the
past
handful
of
of
calls
does
anyone
feel
strongly
that
this
should
be
in
for
Istanbul
and,
if
not,
should
we
just
reject
it
from
Istanbul
and
and
leave
it
as
a
consideration
for
another
upgrade?
If
anyone
comes
on
a
future
call
and
and
and
advocates
for
it,
I.
C
B
B
D
Mean
my
second
day,
marty
swenders
mentioned
risks
with
this
one
from
the
last
call
or
like
to
close
ago,
but
I
would
like
to
see
some
work
on
it
because
it's
long
outstanding,
so
I
would
like
to
see
it
in
tentatively
accepted
and
some
further
discussion
discussion
on
it,
but
I'm
not
strongly
favoring.
It.
B
C
D
Yes,
this
will
be
important
and
also
what
marketing
mentioned
is
the
question
of
whether
we
look
at
it
only
from
the
EVM
perspective,
but
also
from
outside
of
EVM
perspective,
because
it
affects
how
we
define
what
the
transaction
is
constructed
properly
or
not
in
the
same
for
probably
a
few
other
items
within
the
domain,
like
probably
non-block
headers.
But
this
is
the
idea
right.
So
do
we
only
change
the
way
we
look
at
gasoline,
it's
in
a
VM
inside
or
when
we
and
deserialize
and
accept
or
are
out
P
or
not.
C
C
C
D
B
C
B
Okay,
so
I
guess
yeah
just
for
the
record.
It's
worth
stating
again,
all
these
gas
cost
ones
we're
moving
into
tentatively
accepted
still
would
require.
You
know
a
lot
more.
Benchmarking
done
to
be
to
be
considered
to
be
shipped
on
a
hard
fork,
but
hopefully
having
them
and
having
your
final
list
helps
us
focus
the
discussion
and
and
and
give
the
team's
championing
those
the
sort
of
signal
that
they
need
to
work
on
those
benchmarks
and
then
now
that
we're
over
with
this
list
James
do
you
want
to
talk
about
1559?
B
H
So
we
had
Matt
slipper,
do
a
implementation
study
of
1559
and
further
go
into
specifically
I
we're
in
the
goth
codebase
and
what
changes
would
need
to
be
made
in
order
to
implement
it
and
he
recommended
a
2/4
process
as
one
of
the
updates
one
introducing
the
transaction
fee
change
and
then
also
so
both
transactions.
So
both
transaction
types
exist
at
the
same
time
and
then
a
transition
function
that
will
make
it
so
over
ty.
H
C
So
1702
is
clearly-defined
would
have
rules
applied
to
the
current
contract
address
in
the
version
of
the
contract.
This
would
propose
a
different
scheme
where
any
gas
prices
would
not
be
tied
to
the
contract
version
of
the
executing
code,
but
to
the
transaction
originating
the
call,
no
matter
how
far
down
the
stack.
C
1702,
the
version
is
applied
to
the
current
contract
message
frame,
whatever
contract
message
creamer
in
so
when
I
was
implementing
it
in
Pantheon.
The
gas
price
changes
would
only
affect
you
know.
If
we
version
the
gas
price
changes,
it
would
only
affect
the
contract
version,
but
I
want
to
make
sure
if
I'm
hearing
this
correctly,
that
this
would
propose
not
that
strategy,
but
a
different
strategy,
which
is
the
gas
cost
changes,
don't
matter
about
what
current
contract
were
in.
It's
about
the
transaction
that
initiated
all
the
calls.
C
A
So
I
mean
this
is
sort
of
I
guess
anticipates.
You
know
my
previous
comments
anticipated
these
sorts
of
discussions
right
when
we're
having
all
these
things
that
are
messing
around
with
the
gas
cost
there
they're
gonna,
you
know
it's
not
clear
what
the
interference
is.
Gonna,
be
right.
So
for
I
wasn't
aware
of
1702
when
I
proposed
his
sort
of
changes
and
I
think
it's
just
a
matter
of
when
1702
gets
in.
If
1702
gets
in
before
1559,
then
it
would
apply
to
you
know
the
old
transaction
types
and
the
new
transaction
types.
A
C
I
think
it
did
because
we
haven't
decided,
what's
gonna,
be
assigned
to
any
track
any
versions,
it's
so.
Here's
notes
who's
kind
of
on
the
bubble,
because
transactions
of
versions
are
falling
out
of
favor
son.
Sixteen
six
fifteen
has
been
withdrawn
by
the
authors,
so
we
could
just
let
this
win
and
have
something
to
figure
it
out
when
it's
ready
to
come
back
in
the
scene.
A
Yeah
I
mean
I
think
in
terms
of
timing,
I
I
hope
you
know
part
of
the
reason
we
took
our
time
and
got
this
proposal
written
and
have
been
talking
to
people
who
were
running
simulations.
I've
talked
to
a
number
of
teams
that
do
simulations
I'm
continuing
to
talk
to
teams
that
do
simulations
is
because
this
transition
having
to
transaction
types
on
the
network
at
the
same
time
as
pretty
intense
but
I,
can't
figure
out.
Another
I
mean
to
me
it's
just
the
parsimonious
way
of
allowing
you
know
we're
changing
how
transactions
work.
A
So
every
piece
of
software
that
interacts
with
the
system
is
either
reading
or
writing
transactions.
So
we
can't
we
can't
just
get
rid
of
them
right.
So
so
the
reason
we're
taking
our
time
is
to
make
sure
that
we
actually
have
sufficient
testing
in
place
and
obviously
that
testing
those
testing
frameworks.
Those
harnesses
what-have-you
could
be
reused
in
these
cases
where
we
have
potentially
interfering
the
IPS
Ori
IPS
that
you
know
we
want
to
test
them
all
together.
A
Right
I
mean
we're,
we're
gonna,
have
to
be
taking
Forks
of
death
and
then
and
then
running
those
Forks
of
death
in
and
running
in
simulation,
and
so
I
think
that
that
should
just
be
a
part
of
the
process.
You
know
once
we've
done
that.
Obviously
you
know
moving
forward.
All
the
IPS
could
use
that
process.
D
I
have
mixed
feelings
here,
so
there
are
a
few
things.
First
of
all,
the
specification
doesn't
define
clearly
of
dis
split
into
two
stages
on
the
second
thing
is,
it
was
already
rejected,
so
I'm
kind
of
unwilling
to
have
some
some
kind
of
situation
when
we
reject
something
and
resurrect,
and
it
opens-
opens
the
door
for
others
to.
A
C
Think
that
was
when
we
proposed
part
2.
That
was
that
the
other
asaji
would
still
be
going
on,
whether
it's
in
April
or
July,
and
things
that
are
rejected
are
still
in
asaji,
Oh
still
eligible
for
that
I
think.
The
original
idea
for
the
2
part
was
just
to
have
the
biggest
ones
and
not
have
it
collect
everything
which
would
have
been
the
EC
generic
contracts
and
Prague
pal
coming
in
January,
because
those
those
require
a
bit
more
client
implementation,
time
and
testing
effort
and
the
smaller
ones
were
consisting
mostly
of
gas
cost
changes.
C
We
could
get
reference
tests
together,
much
easier
for
proposed
hard
fork
of
the
test
net
beginning
in
September,
so
I
think
that's
what
was
the
original
idea
of
it
and
I
do
sympathise.
If
we're
going
to
keep
the
trains
running
on
time,
we
need
to
set
deadlines
when
the
cabin
door
closes
the
planes
on
its
way.
If
you're
not
in
you
know,
talk
to
your
travel
agent
yet,
and
you
took
it.
H
C
What
if,
instead
of
applying
a
different
gas
schedule
on
each
version
of
the
transaction,
what
if
there
is
a
multiplier
that
the
old
ones
cost
1.1
as
much
and
they
cost
1.2
as
much
up
until
it
cost
2
times
as
much
or
five
times
as
much
from
the
gas
to
get
away
multiplier?
Because
was
that
approach
considered
or
or
was
the
schedule
approach
found
spare
to
that
for
something.
A
I
mean
we
didn't
really
think
about
adding
an
artificial
multiplier
to
make
gas
more
expensive
again.
That
seems
to
me
to
be
less
parsimonious.
I
mean
where
here's,
how
I'm
looking
at
the
conversation
right
now
and
apologies
because
I
admit
I'm,
not
I'm,
not
participating
all
the
time,
but
if,
if,
if
collectively,
we
agree
that
1559
is
important,
which
I
don't
know
how
people
feel
about
that
then,
and
we
agree
that
we
need
to
have
an
incentive,
ization
mechanism
to
have
people
move
to
1559,
which
I
think
is
something
that
we
can.
A
A
Then
we
have
to
come
up
with
this,
not
other
method
that
is
probably
going
to
be
more
complicated,
so
it
I
just
it
just
seems
no
matter
what
we
you
know
by
by
partitioning
the
the
changes.
That
seems
to
me
to
be
the
most
parsimonious
solution,
I'm,
totally
open
to
doing
other
things
that
add
to
me
more
complexity
and
I'm
open
to
suggestions,
I'm
fine,
if
it's,
if
you
know,
if
the
EIP
wasn't
ready,
it
wasn't
ready.
I'm,
not
I'm,
not
upset
about
that
either,
but
I'm,
not
in
any
particular
rush.
C
A
plug-in
to
different
schedules
based
on
how
the
transactions
put
in
the
system,
I
think
is,
is
more
difficult
than
the
transactions
executed.
Looking
up
on
a
table
and
applying
a
multiplier
to
the
gas
cost.
I
think
that
one
is
much
less
of
an
impact
on
the
code,
then
using
multiple
schedules
and
using
multiple
schedules,
I
think
provides
unneeded
complexity.
I
mean
it
is
one
way
to
incentivize
it,
but
I
think
the
cost
is
higher
than
we
expect.
D
I'm
think
we
should
make
a
strong
statement
that
we
generally
would
like
to
see
1559
as
the
as
a
moving
forward
for
the
entire
network.
But
I
would
like
to
keep
discussing
in
in
separation
from
under
Yves
and
say
it
should
have
its
own
way
of
incentivization
and
not
not
be
delivered
by
other
gas
cause
changes.
G
G
A
That's
yes,
but
that
incentive
is
at
the
user
level,
not
at
the
developer
level
right.
So
someone
has
to
actually
write
the
patches
to
the
changes.
Oh
yeah
and
they're
not
incentivized
to
do
that.
If
they
you
know
if
their
transactions
get
through,
if
they
don't
push
a
patch
and
their
transactions
just
work,
then
they're
gonna
wait
till
the
last
minute
you
might
as
well
just
do
a
hard
switch
right.
A
H
D
D
A
F
A
B
B
H
B
C
So,
looking
at
the
github
there's
three
arguments
for
that,
it
hasn't
been
submitted,
filings
a
draft
which
can
be
fixed
really
relatively
easily.
It's
based
on
1706,
which
is
not
still
a
draft.
It's
actually
replacing
1706,
so
really
1706
be
withdrawn.
But
the
most
substantive
argument
is
about
two
things
relating
to
alternative
fixes
for
1283
my
take
on
it
as
a
remor
so
far
down
the
process
that
we
know,
there's
there's
so
many
ways
we
could
fix
this.
C
C
Yeah
the
best
one
to
defend
it
because
he's
got
the
most
details
on
it.
I
seem
to
recall
that
the
second
argument
about
that
one
of
the
arguments
about
why
don't
we
just
give
a
bigger
refund
later
was
withdrawn
last
week.
One
of
these
arguments,
I
think,
was
withdrawn.
If
way
has
better
memory
about
it,
but
I'm
not
me
personally,
I'm,
not
seeing
anything
that
says
that
except
propose
a
solution
is
not
objectively
false.
You
know
we're
picking
colors
but
I
shed
at
this
point,
but
if
it's
objectively
wrong,
we
should
fix
it.
G
C
B
Tentatively
accepted
I
feel
like
for
what
the
consensus
was
for.
All
of
the
tentatively
accepted
ones
was.
If
we
can
get
the
implementation,
then
soon
enough
that
we
can
hard
for
it
to
test
that's
still
on
September.
Fourth,
then
it
it
makes
sense
to
to
have
that
be
far
as
the
October
fork
and
realistically
I
guess.
That
means
you
know
if
the
clients
have
not
implemented
it
by
the
next
call,
then
it's
probably
not
making
it
to
October,
because
the
next
call
is
mid-august
and
we'll
have
one
that'll
be
late.
B
D
I
would
be
in
favor
of
changing
this
requirement
from
Darice
they're.
All
clients
are
implementing
it
too.
Just
there
are
tests
like
tests
available
and
it
serum
tests
that
can
cover
pretty
Korea
P.
If
there
are
tests,
then
we
don't
have
to
have
all
of
the
clients
implementing
it
straight
away.
Nothing
I
mean
if
you
say
like
in
two
weeks:
even
we
can
have
the
tests
and
the
clients
follow-up,
so
get
in
party
will
be
important
and
if
they
are
there
and
if
we
have
tests
it's
enough.
B
Yeah
the
reason
I
was
I
was
focusing
on
client.
Implementation
is
because
the
call
two
weeks
from
now
will
basically
be
two
and
a
half
weeks
before
the
test
net,
hard
work
and,
and
from
last
call
it
seemed
like
pretty
much
the
minimum
time
you
would
want
between
like
releasing
your
new
version
and
actually
forking
the
network.
H
B
There
there
wasn't
like
a
final
consensus
on
either
of
those
I
think
way.
Last
time
had
an
objection
with
January
saying
maybe
February
would
be
better,
so
say
that
part
two
would
be
sometime
q1,
and
then
there
was
discussion
about
whether
or
not
the
next
update
should
be
in
April
or
a
bit
farther
so
like
around
July.
B
C
G
B
D
Yeah
my
mention
was
more
about.
We
say
that
it's
enough
to
have
reference
implementation,
why
I
wouldn't
like
to
have
situation
when
you
have
one
reference
implementation
and
is
considered
to
be
enough
for
inclusion
in
the
artwork,
because
the
testing
is
much
Gordon
for
other
clients,
usually
than
just
a
reference
implementation,
because
testing
has
to
be
in
the
end
based
on
a
reference
implementation.
So
it's
a
bit
more
of
a
strong
requirement.
C
So
I
don't
see
Dimitri
on
the
call
to
speak
to
this,
but
one
of
the
things
that
he's
been
writing
is
a
tool
called
retest
death
and
what
it
does
is
it
takes
the
reference
tests
and
instead
of
expecting
applying
to
read
the
jason,
I'm
an
expected
client
to
expose
json-rpc
ports.
So
in
theory
you
can
stand
up
right
now
a
left
and
get
both
support
it.
You
could
right
to
represent
against
Alec
their
gif
and
have
the
fillers
figure
it
out
from
there.
Pantheon
should
be
coming
in
about
a
week
or
two.
C
So
from
that
you
can
write
your
reference
tests
for
wherever
your
reference
implementation
is
and
I
think
it's
on.
Hopefully,
it's
going
to
show
up
on
parity
shortly.
That
would
be
great
if
it
could
and
Trinity
will
be
agreed
at
two.
But
this
is
a
tool
that
you
know
we
don't
have
to
be
a
let
hackers
to
figure
out
how
to
make
the
filler
work.
We
can
follow
the
instructions
that
Dimitri's
left
online
to
write
the
reference
test.
C
So
I
think
that
is
something
that
you
know
as
developers
and
authors
of
these
noob's,
that
we
should.
You
know
for
the
next
community.
Hard
work.
I
personally
want
to
apply
it
on
the
hard
rule,
and
not
only
do
you
have
to
have
a
reference
implantation.
You
need
to
have
test
cases
ideally
test
cases
in
the
form
of
reference
of
reference
tests
and
for
the
gas
changes.
These
are
like
the
ideal
tests,
because
there
is
no
easy
things
that
says
trivial'.
C
The
test
is
like
great:
let's
test
it
in
a
reference
method,
so
it's
something
we
could
throw
against
other
clients
to
make
sure
that
they
have
the
same
logic
as
they're.
Writing
it
so
I.
You
know
we
definitely
should
I,
don't
know
who's
up,
for
it.
Just
write
some
of
these
reference
tests
for
these
changes
that
we
think
should
be
going
in.
If
it's
your
eat,
you
know
find
the
docs
that
Dimitri
wrote
and
spit
it
up
against
get
or
how
that
that's
for
your
reference
limitation
is.
D
Yes,
what
we,
what
we
see
is
that
all
the
eaves
proposers
are
very
happy
to
implement
as
much
as
they
can,
but
very
often
they
obey
start,
because
they
have
to
wait
for
some
of
the
client
developers
to
deliver
the
implementation
for
them.
If
we
deliver
a
good
set
of
tools
and
retest
s,
something
amazing,
something
that
we
really
need,
and
then
there
is
a
bigger
chance
that
they
eat
will
be
produced
in
a
more
holistic
way,
the
one
that
will
allow
us
to
introduce
something
without
really
worrying
whether
it
can
be
implemented
or
not.
C
Yeah
cuz
Demetri
earlier
today
on
the
git
er
said.
So
if
an
ape
is
accepted,
I
see
the
proposal
is
test
section.
The
question
is
how
obligated
to
provide
the
test
for
the
eat.
There
will
be
many
Eve's
and
only
one
testing
team.
Here's
an
example.
Kind
of
test
might
be
needed
for
the
new
opcode
and
you
may
link
to
something
in
the
aleph
repo.
C
B
I
J
Thanks
very
much
you
know
like
describe
it
very
well:
well,
it
actually
supports
get
right
now
and
the
state
tests,
so
you
could
run
and
you
could
generate
the
state
tests
using
the
get
version.
A
let's
is
not
stable
and
the
blockchain
test
generation
is
not
supported.
Yet
so
I
guess
for
blockchain
test
I
will
have
to
use
a
left
test
it.
This
is
the
one
I
used
all
the
time
and
the
state
test
could
be
generated.
J
The
difference
between
those
group
of
tears
that
option
tests
could
contain
many
blocks
and
many
transactions
and
some
malicious
blogs
and
state
tests
is
a
basic
form
of
tests
with
one
transaction.
So
it
could
easily
be
converted
into
simple
block
chain
test
with
one
block
and
one
transaction,
and
this
test
run
by
hive.
J
J
See
it's
it's
enough
to
create
a
simple
one
transaction
test.
These
changes
that
include
like
you
Europe,
could
include
the
change
and
you
could
test
it
with
one
transaction.
It
should
be
enough,
so
majority
of
the
test
cases
could
be
implemented
by
this
one
transaction
change.
So
it's
not
that's
very
critical,
that's
function
test
unless
you're
supported
mother,
but
like
it's
going
to
be
implemented
soon,.
B
D
One
thing
is
that,
even
if
we
assume
that
all
the
eat
champions
generate
the
test,
I
would
love
to
say
some
like
central
law
has
green
light
from
the
testing
team
from
from
Dmitriy
to
say
that
the
test
coverage
for
the
given
eaves
is
is
enough,
like
they
still
some
overseeing
process,
and
generally,
we
should
focus
now
on
testing,
since
we
have
the
least
of
accepted
tentatively
accepted
ifs,
the
testing
should
be
just
our
focus
now
and
we
should
clearly
state
okay.
We
transition
to
testing
stage
now.
D
B
J
J
K
G
Well,
one
thing
has
been
the
first
testing
team
has
been
working
on
for
a
while
is
generating
code
coverage
reports
in
particular,
guess
and
parity.
So
this
would
show
the
code
coverage
of
both
the
state
test,
suite
and
and
they
was
testing
corpus
and
where
any
gaps
are
or
and
so
forth.
So
it
would
be
nice
if
that
could
be
published
on
the
kind
of
dashboard
and
I
assume
another
priority
will
be
to
get
hive
tests
up
and
running
again,
because
that
seems
to
be
don't
for
maintenance
right
now,
where
I
mean
it's
up,
but.
D
J
B
Okay,
so
I
guess
just
to
summarize
this
we're
saying
if
champions
should
should
should
own
generating
the
reference
test
for
the
reaps,
but
we
should
also
have
the
testing
team
kind
of
as
a
central
point.
You
know
looking
at
everything,
yin
and
green
lining
it,
and
we
should
try
to
get
the
hive
team
on
the
next
call
to
discuss
this
in
more
detail.
Does
that
make
sense.
B
B
B
B
And
we
didn't
have
any
outstanding
action
items
and
then
the
call
before
that,
because
we
didn't
get
to
reviewing
stuff
on
a
previous
call,
we
had
again
a
lot
of
eeap's
accepted
in
terms
of
the
decision,
so
no
need
to
go
back
over
these.
The
actions
required
were
reviewing
1283
1706.
This
seems
to
be
happening,
and
we
touched
on
that
earlier
around
around
the
2,200
discussion.
B
B
A
Well,
I
mean
we
already
covered
it,
but
just
for
completeness
there's
a
document
up
at
eath
magicians,
I'm
an
existing
thread.
I
don't
know
where
we
put
the
links
for
the
for
these
meetings,
but
there's
a
link
in
the
fourth
magician
and
each
magicians
with
with
the
proposal
that
that,
like
james
already
said
that
basically
covers
how
we
would
actually
write
the
code.
I'm
still
I
have
sort
of
a
first
pass
analysis
of
the
impact.
A
A
Yeah
I
mean
that
I
don't
feel
comfortable.
You
know
sort
of
unanimously
making
that
decision,
so
I
think
you
know
we
just
need
to
open
it
up
to
the
community
and
have
a
conversation
I'm
open
to
just
the
next
fork.
Whatever
that
plan
is
I,
don't
think
we
need
to
plan
a
fork
just
for
that
change,
I
think
whatever
Forks
go
in.
It
would
be
good
to
just
sort
of
get
into
a
cadence
and
and
follow
along
decades.
So.
A
K
I
just
wanted
to
clarify.
There
was
a
question
earlier
and
recall
that,
or
some
somebody
said
that
they
didn't
start
working
on
on
some
EAPs,
because
they
were
only
tentatively
accepted
and
some
decisions
had
to
be
made
so
to
clarify
the
tentatively
accepted
he
keeps
our
like.
They
must
be
implemented,
they
are
going
in
either
in
in
October
or
in
in
January.
B
So
my
understanding,
especially
with
the
ones
we've
added
today,
is
the
clients
should
begin
the
implementation,
but
some
of
them
still
have
like
outstanding
issues.
Whether
this
is
like
for
the
gas
cost,
the
benchmarks
for
prog
pal
there
was
the
audit,
so
clients
should
start
on
the
implementation,
but
I,
don't
think
we're
ready
to
assume
it'll
get
included
in
an
upgrade
for
sure.
If
the
sort
of
outstanding
issues
with
these
eeap's
don't
don't
get
resolved,
does
that
make
sense.
K
D
I
think
for
tentatively
accepted
deities.
We
know
exactly.
There
are
some
actions
required
so
for
profile.
We
need
audit
for
1962.
We
waiting
for
day
for
the
review
of
a
correctness
of
its
right
I've,
seen
some
discussions
on
awkward
deaths
for
some
others.
We
wait
only
for
benchmarks
or
because
repricing
and
I
think
that
Saints
really.
This
is
just
reactions
that
are
needed.
G
So
my
understanding
is
that
the
ones
that
are
currently
in
tentatively
accepted
would
still
need
to
move
to
accepted,
and
that
would
start
happening
either
after
testing
activation
or
after
main,
that
you
know
the
October
quark,
the
main
network
happens,
then
that's
when
the
discussion
begins
to
remove
VIPs
from
the
tentatively
accepted
list
up
to
the
accepted
list.
That's
what
how
I
would
expect
it
to
go.
H
And
the
big
the
big
question
there
is,
if
it's
part
of
the
October
or
the
January
1,
and
then
that
will
be
kind
of
decided
by
those
things
and
I
think
it's
also
important
to
say
just
for
people
who
are
listening
to
this
from
the
outside.
That
saying
that
it's
in
now
doesn't
mean
that
there
isn't
going
to
be
something
that
comes
up
through
testing
that
didn't
that
we
have
to
kick
an
EIP
out
due
to
something
we
don't
understand
yet.
H
B
Yeah
I
I
will
+1
that
James,
and
one
thing
I'd
maybe
like
to
propose,
is
having
the
next
call.
So
the
mid-august
one
be
the
last
call
for
something
to
go
from
the
tentatively
accepted
accepted
list
so
where
it's
basically
the
last
chance
for
something
to
be
included
in
the
october
fork,
which
anyway,
is
just
timewise,
it
kind
of
is,
but
maybe
that's
a
way
we
can
better
sort
of
discriminate
between
the
two
forks
is
moving
whatever's
tentatively
accepted
to
accept
them.
H
D
Yeah,
I
think
the
strong
message
for
the
community.
These
are
aps,
and
these
are
the
actions
that
we
are
expecting
from
both
champions
and
community
to
deliver
as
benchmarking
testing
and
pointing
out
any
vulnerabilities
security,
wise
and
the
clear
message
as
well.
What
we
rejected
is
not
coming
back,
so
people
know
that
there
is
ten
or
eleven
a
piece
as
we
see
on
the
list
that
they
clearly
considered
for
istanbul,
and
this
is
what
we
are
focusing
on
now.