►
From YouTube: Ethereum Core Devs Meeting #98 [2020-10-16]
Description
A
Okay,
so
we're
recording
to
the
cloud
welcome
everyone
to
core
devs
number
98..
I
just
shared
the
agenda
in
the
chat.
There
were
not
too
many
things
on
it,
so
if
there's
anything,
people
want
to
bring
up
during
the
call
we'll
definitely
have
have
some
time
for
it.
I
think.
First
up
we
had
two
new
eips
that
people
wanted
to
discuss.
The
first
is
a
pre
eip
for
the
binary
tri
format.
I
believe
guillaume
was
the
one
who
wanted
to
bring
that
up.
A
B
B
B
One
of
them
is
okay,
so
clearly
the
first
thing
is
that
the
the
tree,
the
tri,
is
a
binary
binary,
try
and
we
also
wanted
to
have
because
apparently
there's
a
lot
of
zero
knowledge
application
to
this,
an
input
where
it's
just
two
32
bytes
like
items
as
an
input
and
one
32
byte
item
as
as
the
output
and
otherwise
another
thing
was
to
get
rid
of
rlp
by
popular
demand.
Everybody
wanted
to
get
rid
of
rlp.
B
I
also
tried
to
get
rid
of
extension
nodes,
but
that
is
clearly
too
yeah
too
difficult,
like
the
the
number
of
hashes
that
need
to
be
done.
If
you
get
rid
of
extension,
nodes
is
just
it's
just
too
big
yeah,
so
pretty
pretty
simple
yeah,
whatever
yeah.
If
you
have
any
comments
or
I'm
I'm
happy
with
with
any
feedback.
C
B
B
B
D
B
An
example,
so
I
don't
have
the
exact
number
I
used
to
have
it,
but
I
lost
my
my
ssd
two
weeks
ago
and
I
need
to
recalculate
everything,
but
it
was
like,
maybe
half
a
second
to
to
just
when
you
had
like
one
thousand
just
one
thousand
leaves
in
the
tree.
It
would
take
like
half
a
second
to
recalculate
everything
on
on
an
average
machine.
D
D
So
what
basically
I'm
saying
is
that
I
need
to
verify
that
the
extension,
the
addition
of
extension
node
is
justified,
because
you
know
we
kind
of
agreed
that
extension
nodes
do
bring
extra
complexity,
and
if
we
can
get
rid
of
them
without
sacrificing
too
much
of
a
performance,
then
it
would
be
good.
But
yeah.
B
Yeah,
I
totally
agree
with
that.
I
mean
there's
so
many
nice
properties
even
for
witnesses,
and
things
like
this,
if
you
don't
include
the
extension
nodes
and
but
yeah
yeah
the
way
I
see
it,
there
were
too
many
two
things
that
really
increased
the
complexity.
There
was
the
extension
notes
and
really
the
all
the
bit
twiddling
about
like
yeah,
that
is
included
in
the
hex
prefix,
especially
and
all
the
the
rlp
you
know
rule.
If,
if
your
rop
is
less
than
32,
then
you
need
to
hash
it.
B
Sorry,
then
you
need
to
include
this
verb
verbatim.
Otherwise,
you
you
have
to
hash
it.
In
my,
in
my
view,
this
is
where
the
complexity
really
explodes,
so
the
extension
node
that
I
would
have
liked
to
to
be
able
to
get
rid
of
them
by
all
means.
If
you
find
a
way
to
to
get
rid
of
them
and
still
keep
the
performance,
I'm
I'm
all
ears.
I
was
not
able
to
to
do
that.
D
Okay,
so
when
you
were,
let's
just
narrow
down
what
what
kind
of
performance
do
we
mean?
Do
we
mean
the
performance
of
constructing
the
tree
or
like
an
entire
tree,
or
do
we
mean
the
performance
of
let's
say
verifying
the
proof
with
a
miracle
proof
yeah
constructing
the
tree,
but
we
do
not
talk
about
verifying
numerical
proof
right.
B
D
D
If
you're,
if
you
don't
have
extension
nodes
that
that
basically
means
that
all
the
merkle
proofs
will
have
the
same
exact
depth
right
even
righteously
yeah,
so
and
even
though
you
could
say
that
the
amount
of
information
you
have
to
carry
in
the
proof
is
still
going
to
be
small,
but
the
amount
of
calculations
that
you
need
to
perform
to
verify.
The
proof
will
be
essentially
constant
and
that
constant
will
be
basically
depth
depending
on
on
these
entire
depths
of
the
like
64
or
whatever.
It's
called
yeah.
D
B
So
if
you,
if
you
look
at
the
pr
somewhere,
there's
a
link,
sorry
not
the
pr.
If
you
look
at
the
the
draft
there's
a
link
to
a
hack
md,
I
did
to
precisely
explain
this
thing
separate
the
miracle
proof
generation
from
the
from
the
try
and
you
could
use
like
extension
nodes
in
the
in
the
witness
in
the
proof
and
then
recalculate
it
one
one
at
a
time,
so
that
can
be
done
but
yeah.
Even
then,
the
production
of
a
block,
in
my
view,
would
take
too
long.
D
Sure,
okay,
cool
yeah,
because
basically
my
approach
to
that
would
be
just
that.
You
know
again
when,
when
you
talk
about
the
calculating
the
the
the
hash
of
the
entire
tree,
I
would
also
again
separate
it
into
two
parts:
the
initial
calculation
and
the
incremental
calculation.
So
you
know,
even
even
if
the
initial
calculation
is
somewhat
slow,
that
could
be
could
be
worth
sacrificing
if
we
can
show
that
the
incremental
calculation
is
still
okay,
yeah.
B
D
So
basically,
I
think
you
can
make
the
incremental
calculation
pretty
much
the
same
as
the
with
the
current
thing,
because
I
think
the
the
times
when
we
really
touch
the
extension
nodes
are
probably
quite
rare.
Statistically.
So
I
think
we
could
work
on
this.
I
think
we
could
actually
solve
this
problem.
D
What
I'm
say,
what
I'm
saying
is
that
let's
say
that
we
could
keep
the
same
physical
model
that
we
have
right
now
in
your
implementation,
for
example,
because
your
implementation
essentially
has
the
the
whatever
embodiment
of
this
extension
mode
right,
which
is
essentially,
but
you
can
still
have
this
embodiment
of
extension
nodes
in
your
physical
but
by
by,
but
by
having
a
logical
model,
without
extension,
so
that,
if
nothing
changed
in
that
in
that
node,
you
don't
need
to
update
it.
So.
E
D
My
hypothesis
is
that
the
number
of
extension
nodes
are
not
that
large
in
practice,
and
we
don't
this
statistically,
we
can
figure
out
how
much
it
is
that
you
know
we're
hitting
extension
mode
and
how
hard
can
you
hit
them
in
the
worst
case
and
then
maybe
that
that
is
not
going
to
be
a
significant.
So
that's
what
I'm
saying.
C
C
D
No,
what
that,
by
hitting
extension
mode,
I
mean
modifying
something
which
is
beyond
the
extension
node
so
like
beyond
meaning
like
closer
to
the
leafs,
because
if
you
don't
modify
anything
which
is
which
is
basically
beyond
the
extension
node,
then
you
don't
need
to
do
anything
with
that
extension
because
you
sort
of
pre-cached
the
the
hash
of
that
sub-tree
yeah.
So
so,
basically,
I
I
do
not
have
this
data
at
hand,
but
how
often
do
we
do
we
hit
that
you
know
the
the
things
beyond
the
extension
nodes.
G
G
B
E
G
With
prefix
in
another
format,
it's
just
a
little
bit
confusing
for
me,
but
it's
not
a
problem.
I
mean.
If
you
make
a
putting
a
domain
separation,
exactly
136
bytes,
then
you
can
make
kind
of
specialized
well,
then
you
can
make
128
specialized
keychuck
256
hashes,
with
their
external
fade
being
non-trivial,
and
then
you
can
use
four
and
then
you
can
hash
four
elements
simultaneously
into
a
single
node
without
increasing
the
actual
hashing
time.
G
G
B
G
H
H
C
I
This
also
might
be
answered
in
the
eip,
and
I
apologize
if
it
is,
is
the
where
the
boundaries
for
the
code
hashing.
Is
that
something
that
is
controllable
by
the
solidity
or
contract
authors
like
function.
Boundaries
seem
like
a
very
obvious
place
that
you'd
want
to
have
your
kodash
boundaries,
or
is
it
just
you
don't
really
get
to
choose
it?
It's
going
to
boundary
where
it
does,
and
you
can't
optimize
for
that
at
all.
F
E
E
D
H
We're
not
taking
any
extra
consideration
for
the
data
section.
The
only
edge
case
that
I
came
came
upon
was
so
at
the
beginning
of
every
chunk.
We
store
the
offset
of
the
first
instruction
in
that
chunk
to
be
able
to
escape
push
data,
and
if
the
data
section
at
the
end
of
the
byte
code
has
something
resembling
push
up
code
and
and
then
the
data
for
that
push
of
code
goes
over
the
the
bytecode
length.
C
D
So
what
we're
trying
to
do
is
that
we're
trying
to
prove
for
as
many
contracts
as
we
can
in
the
which
are
currently
deployed,
whether
they
ever
exhibit
the
behavior
that
they
can
jump
inside
the
push
data,
and
so
so
far.
I
think
we
have
proven
for
97
of
the
contracts
that
were
deployed
that
it
never
can
can
never
happen.
So
the
basically
we're
just
working
on
the
doing
the
proof,
checker
and
stuff
like
this.
D
But
the
idea
behind
this
is
that,
if
we
can,
I
know
for
for
basically
that
most
of
the
programs
which
do
not
specifically
kind
of
want
that,
if
you
compile
them
with
solidity
solidity,
pretty
much
always
generates
the
code
which
never
jumps
into
the
jump
into
the
push
data.
So
you
actually
have
to
craft
the
code
specifically
to
do
that
to
you
know
to
violate
this
rule.
So
the
suggestion
was
there.
D
If
we
do
that,
if
we
figure
out
how
to
put
that
in
then
we
can
even
simplify
the
chunking
rule
that
that
we
don't
even
need
to
include
metadata.
That
means
that,
for
the
contracts
where
we
were
able
to
analyze
them,
we
we
put
the
flag
into
the
account
saying
that
this
we
proved
that,
for
this
account
there
is
no
possibility
of
jumping
to
the
push
data
at
all.
That
means
that
you
can
chunk
them
with
way.
Do
you
want
the
way
you
want
without
even
needing
the
metadata
and
for
those
where
are?
D
F
D
D
So,
but
now
we
are
trying
to
figure
out
how
the
big
the
proof
is
going
to
be
and
how
simple
the
the
proof
checker
is
going
to
end
up,
and
what
I
also
wanted
to
add
is
that
you
know
these
suggestions
about
the
subroutines
and
dynamic
jumps.
We
kind
of
now
see
that
if
we
did
not
have
dynamic
jumps
in
ibm,
then
those
proofs
will
be
pretty
much
trivial,
but
what
what
we
could
do
is
that
we
could
actually
go
into
that
direction
and
essentially
sort
of
back.
D
D
F
E
E
F
Yeah
by
the
way,
speaking
of
other
treeing
approaches,
I
should
also
bring
up
the
something
I
brought
up
once
before,
which
is
the
option
of
using
cade
commitments
in
addition
to
a
merkle
root
for
hashing
a
code.
Basically,
the
arguments
for
arcade
commitments
is
basically
that
you
can
fairly
easily
generate
a
proof
for
an
arbitrary
subset
of
chunks,
regardless
of
where
they're
located,
and
this
proof
would
just
be
a
constant
size,
48
48
bytes,
which
has
the
possibility
of
making
witness
sizes
for
code
like
quite
trivial.
F
C
C
H
Yeah,
so
in
in
the
eip,
we
currently
talk
about
there's
a
segment
for
the
transition
process
and
we
thought
maybe
it's
it's
easiest
to
only
store
the
flat
code
right
now.
So
when
the
when
a
new
contract
is
created,
the
client
mercalizes
it
computes
the
root,
but
then
stores
the
root
and
doesn't
touch
it
again
and
only
stores
the
the
normal
full
bytecode
in
the
database
and
because
of
this,
we
won't
need
to
for
now
change
gas
cost
for
call
and
any
any
other
code
accessing
up
code
and
later
on.
C
K
H
L
So
I
had
a
question
about
chunking
in
the
middle
of
the
push
data,
if
you're
going
to
keep
metadata
anyways
flagging.
If
the
chunk
ends
in
the
push
data,
then
could
you
not
have
not
exactly
fixed
size
chunking
but
chunking
that
takes
that
into
account
and
chunks
at
around
32
bytes,
but
just
at
the
end
of
every
push
data.
F
E
See
the
central
theme
here
that
I've
kind
of
seen
since
the
beginning
is
that
there
are
a
lot
of
little
efficiencies
that
we
could
possibly
add
in
around
the
edges
and
it
seems
like
pretty
much
all
of
them
end
up
not
being
justified
just
due
to
the
minor
savings
that
they
seem
to
provide
and
the
higher
complexity.
They
seem
to
add
not
saying
we
shouldn't
look
at
these
things,
but
that
has
been
kind
of
a
central
theme
along
the
way.
M
M
So
there
started
to
to
appear
quite
a
few
data
contracts
and
anyway,
through
the
the
subroutines
proposal,
martin
and
I
we
tried
to
analyze
contracts
in
the
the
state
and
as
of
that
work,
I
had
an
idea
that
maybe
we
could
do
a
one-self
validation
of
contracts
and
mark
them
in
the
account
if
their
data
were
not
or
to
say
it
more
nicely
whether
they
can
be
executed
or
not.
And
I
wonder
if
that
could
be
just
merged
with
your
work,
because
you're
already
setting
a
flag
and
you
do
analysis.
D
C
D
We
we
weren't
kind
of
interested
in
that
specific
thing
we
just
were
interested
in
whether
they
or
so
we
were
basically
interested
in
building
the
control
flow
graph
and
we
either
so
for
those
for
the
things
that
terminate
straight
away.
The
control
flow
graph
is
very
simple:
it's
just
like
terminate
it's
just
one
node,
so
the
if
they,
if
the
by
by
chance
they
have
a
little
logic,
which
does
something
I
think
in
most
cases,
the
control
flow
graph
is
still
quite
simple.
D
M
So
one
motivation
for
this
is
executable
flag
in
the
country
would
be
that
when
a
new
contract
is
deployed,
it
is
analyzed
whether
it
won't
terminate
immediately
and
if
it
won't
terminate
immediately.
Then
it's
marked
executable,
and
this
is
somewhat
a-
maybe
a
replacement
to
the
evm
versioning
in
the
sense
that
there
always
have
been
concerns
when
a
new
opcode
is
introduced.
M
D
Okay,
I
see,
I
see
what
you
mean
so
so
to
answer
your
question
is
that
I
think
this
is
basically
a
special
case
of
our
analysis,
because
I
said
that
if
we
already
trying
to
figure
out
these
control
flow
graphs
for
anything
that
we
see
and
there
could
be
either
they
could
be
basically
either
we
can
build
the
controlled
photograph
or
we
can't.
I
mean
that
means
that
we
don't
know
like.
D
Maybe
it's
just
super
dynamic,
but
if,
if
you
look
at
this
control
graph-
and
it
could
see
that
it's
clearly
always
failing
because
it
will
be
obvious
from
control
photograph
that
is
always
failing,
then
you
can
mark
it
as
non-executable.
So
I
think
what
we
do
is
basically
a
bit
wider
than
than
what
you're
asking
so
yes,
we
can
do
that.
C
So
you
get
like
segment
one,
and
then
you
can
continue
your
execution,
because
you
got
that
in
memory
and
then
you
can
do
that
again
and
load.
Another
segment
of
whatever
is
data
you
need
to
load,
which
is
cheaper
than
doing
like
x
code
load
index,
one
two
blah
blah
blah,
or
at
least
it's
easier.
I
don't
know
why,
but
that's
the
type
of
data
contract
which
is
actually
executable
but
which
does
contain
like
white
random
data,
although
it
should
not.
I
mean
the
control
flow
graph
should
not
lead
into
that
random
data.
D
So
when
we
do
delegate
call
right
from
the
point
of
your
control
flow
graph
it
it
doesn't
really
matter
what
this
delegate
quote
does
because
it
just
returns
with
either
failure
or
success,
and
we
know
that
the
top
of
the
stack
will
be
just
either
zero
or
one,
and
then
it
does
not
really
affect
the
control
flow
graph.
So
we
can
see
that
our
analysis
will
probably
show
that
this
is
executable.
D
M
Yes
or
maybe
I
have
brought
you
on
the
wrong
track,
because
I
was
just
trying
to
remember
all
the
contexts
and
it's
actually
multiple
different
discussions
and
ideas.
The
data
contract
question
is
just
one.
The
having
invalid
instructions
is
another
one,
but
it
would
be
perhaps
nice
to
discuss
this
and,
and
I
don't
think
that
all
cordes
is
the
best
place
to
discuss
it.
D
Yeah
yeah,
so
because,
because
basically
we
are
we're
doing
this
control
flow
graph
analysis,
not
sim,
not
just
for
the
chord
localization,
but
another
thing
we
would
like
to
use
it
for
is
for
looking
for
data
dependencies
in
the
past
transactions
to
be
able
to
sync
faster.
So
we
want
to
create
the
data
dependency
graph
to
be
able
to
parallelize
the
execution
and
all
these
kind
of
things.
M
D
D
D
One,
I
think
I
don't
don't
need
more
discord
channels.
So
if
there
are
inter
people
who
are
interested
in
the
discussion,
I
think
we
could
self-organize
into
in.
So
if
people
have
time
and
it's
priority
and
we
can
talk
about
it,
because
what
I
don't
want
to
do
is
I
want
to
create
a
discussion
which
is
for
something
which
we're
going
to
do
in
like
one
year
and
at
the
detriment
of
something
we
have
to
do
like
in
the
next
two
months.
A
Okay
sounds
good
and
yeah
we
can
use
just
the
basic
awkwardness
channel
for
that.
So
next,
up
on
the
agenda
was
the
euro
networks,
so
james
shared
kind
of
some
specs
for
both
yolo
v2
and
yellow
v3.
Let
me
just
post
those
in
the
chat.
I
guess.
First
of
all,
it's
probably
just
worth
asking
the
different
kind
teams,
where
they're
at
with
yellow
v2
and
then
maybe
we
can
have
a
just
follow-up
conversation
on
v3
and
the
status
there.
A
D
A
C
N
N
So
as
far
as
reference
test
goes,
it
looks
fairly
solid,
yeah
and
so
basically's
got
all
three
of
the
things
for
yellow
v2
and
we're
ready
to
go
on
it.
As
far
as
the
evm
test
I
updated
on
the
bug,
I
think
it's
because
when
we
use
the
bitcoin
ec
k256
whatever
it
is,
we
do
the
default
randomization
to
prevent
side,
channel
attacks
and
I'm
thinking
that
it's
blocking
on
native
entropy
we've
seen
that
before
as
some
of
our
unit
tests,
so
there's
a
a
special
flag.
N
C
Yeah
just
another
thing
that
might
be
worth
mentioning
is
that,
in
my
opinion,
the
you
know,
2929
gets
huge
coverage
from
the
existing
22
000
tests,
so
we'll
have
to
look
into
if
there's
something
that
is
not
being
covered.
But
you
know,
since
it
changes
pretty
a
long
list
of
actual
normal
op
codes
and
doesn't
introduce
any
new
things.
N
C
C
A
K
O
O
K
P
P
I
Review
means
that
the
spec
is
at
a
point
where
other
people
should
start
looking
at
it.
Draft
is
really
meant
just
for
I'm
working
on
this,
and
maybe
one
other
person
is
looking
at
it,
but
no
one
should
look
at
this
because
it's
not
done
review
means.
We
think
it's
done
as
an
author.
Other
people
should
now
take
their
time
to
look
at
it
pretty
much.
Anything
that
has
made
it
into
this
call
is
probably
should
be
reviewed
by
that
by
now
like
making.
A
Okay,
good
to
know
so
yeah
for
the
authors
of
of
all
the
stuff,
that's
being
discussed
for
the
yellow
networks,
definitely
worth
moving
the
eeps,
and
so
in
terms
of
next
steps
for
yolo
v2,
it
seems
like
geth
and
bazoo
are
going
to
keep
working
on
adding
tests
and
setting
up
the
network.
Then
another
mine
will
probably
join
shortly
after
and
that'll
kind
of
be
it
on
the
last
call
we
discuss
a
potential
yellow
v3,
I'm
not
sure,
that's
worth
you
know.
A
If
discussing
now,
given
we're
still
kind
of
wrapping
up,
yellow
v2
or
I
don't
know
what
do
people
think
the
yellow
v3
was
basically
yellow,
v2
plus
2718
the
type
the
transaction
envelope
and
2930
the
optional
access
lists,
but
it
feels
like
on
the
last
call.
I
don't
know,
people
have
like
different
opinions
about
how
valuable
this
would
be,
whether
or
not
this
list
made
sense.
A
K
Actually,
the
team,
since
you
mentioned,
yellow
v3
and
2565,
is
not
on
the
list.
I
think
then
it
means
that
it's
in
yellow
v2.
So
let
me
add
something
I
was
finally
running
the
benchmarks
in
nethermine
for
2565
and
surprisingly,
for
most
of
the
operations
on
the
modex.
The
previous
gas
pricing
was
better
aligned
with
the
results
that
I've
seen
in
nethermind
and
we're
using
this
like
built-in
library
for
big
integer
exponentiation.
K
A
Q
Sure
yeah,
so
I
think
the
the
quick
update
is
so
it
it
looks
like
bessu
has
now
implemented
and
the
test
vectors
are
matching
what
they're
supposed
to
be
with
the
new
pricing,
so
good
progress
in
that
direction.
As
thomas
mentioned,
you
know
when
he
ran
the
benchmarks
and
we
looked
at
it
with
the
new
pricing.
There
were
some
items
that
were
down.
Q
You
know
in
the
there's
one
I
think
as
low
as
like
seven
or
eight
million
gas
per
second,
so
you
know,
unfortunately,
this
is
another
case
sort
of,
as
we
had
with
open
ethereum,
where
the
native
or
the
standard
modular
exponentiation
library
is,
is
not
as
performant
as
it
could
be.
We're
just
starting
to
look
at
what
that
looks
like
for
net
and
what
alternatives
are.
Q
I
guess
you
know
that
being
said,
you
know,
I
would
be
you
know
personally
interested
in
in.
If
yellow
v3
happens,
you
know
you
know,
we
know
that
there
could
be
a
sort
of
denial
of
service
vector,
given
that
some
of
these
are
down
near
10,
but
I
think
you
know
to
the
extent
that
we
could
test
it
from
a
cross
client
perspective
on
making
everything
you
know
making
sure
everything
works,
assuming
we
can
fix
this.net
performance
problem.
That
would
be.
C
G
Q
This
is
one
of
the
major
things
that
I
think
you
know,
and
maybe
it's
something
that
I'm
could
potentially
spearhead
sort
of
moving
forward.
You
know
on,
I
think
you
know,
as
we
move
forward,
and
these
pre-compiles
are
more
important
right
for
things
like
roll-ups
and
and
are
getting
more
use.
The
gas
repricing
situation
is
not
it's
not
crystal
clear
right.
Q
We've
got
multiple
different
clients,
you
know
what
you
know
is
15
million
gas
per
second,
the
right
you
know
number
like
that's
what
ec
recover
is
on
geth,
it's
as
low
as
15
million
other
folks
are
targeting
30
or
40..
You
know,
there's
no
standard
like
are
we
on
a
four
core
macbook
at
two
gigahertz?
Are
we
on
an
eight
core
at
you
know
five
gigahertz,
so
I
think
one
thing,
at
least
in
my
perspective,
that
would
really
help
on
these
repricing
things.
Q
C
Q
And
I
think
that's
a
that's
a
great
point.
I
mean
you
know
if
you
go
back
and
look
at
some
of
these
other
eips,
you
know
some
target
to
try
and
get
them
on
par
with
ec
recover.
But,
as
I
mentioned
with,
you
know
something
like
death.
That's
closer
to
15
million
gas
per
second,
whereas
you
know
nethermine's
been
targeting
30
or
40..
Well,.
G
G
G
Well,
the
problem
with
non
absolute
values,
as
even
worse,
as
martin
mentioned
they
use
sha-256,
which
is
elsa
as
a
result
of
measurements
for
266
eep,
is
quite
different
on
different
platforms
and
implementations,
and
even
now,
if
we,
if
we
continue
to
use
this
recover
as
something
like
a
baseline,
and
we
assume
that
everyone
uses
t
library.
First
of
all,
you
can
compile
it
differently
to
get
quite
different
performance.
G
E
C
C
If
the
miners
have
decided
it's
50
million
gas,
then
it
doesn't
matter
what
what
we
execute.
It
takes
roughly
the
same
amount
of
time,
whether
it's
a
simple
loop
or
if
it
pre-compiled
or
that's
the
like
goal,
and
if
it
takes
too
long
time,
then
they
will
have
to
lower
the
gas
limit
to
make
it
faster
again
and
as
long
as
we
have
it
balanced,
it's
not
like
someone
can.
C
Some
blocks
will
suddenly
take
a
minute
just
because
hey
someone
used
the
precompiled
to
do
denial
of
service
as
long
as
it's
balanced
on
like
your
everyday
hardware,
whatever
that
is,
so
I
don't.
I
don't
think
we
should
have
this
idealized
reference
hardware,
where
we
yeah,
I
don't.
I
don't
think
that
works
will
work
as
well.
G
Then,
to
use
a
measurement,
because
even
if
we
try
to
do
it
with
the
current
ones
like
there
are
two
options.
One
of
them.
We
measure
each
of
those
and
calculate
some
gas
per
second
constant
based
on
each
of
those,
and
then
we
have
to
ideally
linearly
reprice
each
of
those
up
or
down,
assuming
that
the
initial
formulas
for
gas
are
even
correct
and
they
are
not
for
some
functions.
G
So
at
least
the
baseline
of
some
flexibility
to
35
with
turbo
boost
off
to
get
some,
and
it
was
basically
what
was
done
in
fall.
25266
like
say
that
there
is
a
constant
on
your
computer
benchmark
everything
and
set
a
gas
formula,
and
it
works
forward
perfectly,
but
it
doesn't
work
backward
because
you
cannot
say
that
your
formula
was
correct
in
the
first
place,
especially
if
it's
for
variable
length
inputs.
D
D
We
should
look
at
the
let's
say
that
the
the
reducing
the
cost
of
operation
is
not
the
only
way
to
make
it
relatively
cheaper.
The
other
way
to
make
it
relatively
cheaper
is
to
increase
the
gas
limit,
so
we
should
look
at
it
both
from
both
perspective,
not
just
from
the
sort
of
single
perspective,
yeah.
Q
K
I
mean
since
we're
changing
only
pricing
there's
like
almost
no
benefit
in
doing
the
cross-client
testing.
Everything
will
be
covered,
probably
by
the
consensus
tests.
It's
not
the
particular
type
of
vip
that
benefits
so
much
from
the
cross.
Client
testnet,
it's
no
problem
to
edit,
but
it
sounds
more
like
pushing
into
the
test
net
with
a
hope
that
it
would
be
there
rather
than
just
benefiting
from
from
testing
it.
K
I
think
it's
relatively
easy
one
to
include
an
important
one,
and
I
think
what
we
should
do
and
you
make
it
more
likely
to
be
included,
is
just
suggest
one
library,
senior
signals
plus
library
that
can
be
compiled
and
added,
and
it
should
be
super
simple.
We
don't
use
this
big
integer
library,
the
native
one.
You
never
mind
anywhere
else,
because
for
all
the
32
byte
operations
we
we
have
now
a
separate
uin256
library.
So
this
is
the
only
place
because
here
we
can
have
arbitrary
length
of
numbers.
A
Okay
and
so
yeah
for
yolo
v3.
I
guess
we
had
a
list
last
time
again,
which
had
the
2537
2315
2929,
which
is
yolo
v2
and
then
added
to
that
2718
2930,
given
that,
like
only
geth
and
bass,
you
have
done
yolo,
v2
and
other
clients
are
not
doing
it.
Is
it
worth
having
a
larger,
yellow
v3,
how
the
different
client
teams
feel
about
that?
Is
it
worth?
Are
there
other
things
we
want
to
include
in
it
yeah?
What
are
people's
thoughts
on
that.
K
P
Yeah,
so
one
thing
that
the
presentation
thomas
was
talking
about
it's
about
people
and
we
invite
all
the
client
team
and
people
who
have
any
questions
on
these
particular
proposals
earlier.
We
also
did
an
episode
for
2565.
I'll
share
the
link
in
the
agenda
for
people
to
refer
and
for
the
next
proposal.
D
I
I
For
yellow
v3,
just
as
a
reminder
this-
I
don't
know
if
this
came
up
in
all
corners
or
one
of
the
other
media.
Many
meetings
that
we
now
have
yellow
v3
appears
has
turned
into
pre-berlin,
and
so
I
know
the
original
intent
that
ever
that
we
wanted
for
yolo
was
it's
yolo,
doesn't
matter
what
goes
on
here?
It
doesn't
mean
it's
going
into
berlin,
but
that
has
changed
just
naturally
to
this
is
pre-berlin.
So
if
something
doesn't
make
it
into
yolo
v3,
then
it
sounds
like
it
probably
won't
make
into
berlin.
I
A
A
K
Yeah,
I
think
it's
a
good
example.
Actually
I
believe
that
two
five
six
five
can
make
it
to
berlin
without
participating
in
the
multi-client
test
net.
It's
just
a
matter
of
finding
one
more
library,
not
too
difficult.
We
just
need
to
resolve
this
small
problem
and
testing
should
be
entirely
encompassed
in
the
consensus
test.
A
A
Because
I
know
I
see
james
press
switches
on
the
call-
and
I
know
last
time
around
you
had
some
questions
about.
Was
it
2539
your
other
bls
curve,
I
believe
and
and
the
fact
that
it
was
quite
similar
to
the
one
included
so
yeah?
I
I'm
curious
what
like
from
someone
who's
a
bit
more
like
outside
the
process
than
just
trying
to
get
something
in
what?
What
do
you
think
would
provide
you
with
the
best
outcome.
A
K
A
A
J
Okay,
sorry,
I've
been
holding
my
tongue
through
the
conversation
a
little
bit
and
then
was
muted.
When
I
tried
to
talk
so
I
I
don't
want
to
be
just
someone
like
outside
this
process,
that's
trying
to
get
something
in
I'd
like
to
be
sticking
around
long
term
and
contributing
so
I'm
gonna
speak
against
my
own
interests
a
little
bit
here.
J
It
feels
like
the
every
two
weeks.
We
move
the
goalposts
back
on
yolo,
v2
and
yolo
v3
by
two
more
weeks,
so
we
last
week
decided
that
there
would
be
a
yellow
v3
and
that
its
eip
list
was
set
two
weeks
ago.
Sorry
and
now
we're
kind
of
reopening
that
and
questioning
the
decisions
we
made
two
weeks
ago.
J
I
would
love
to
get
some
kind
of
like
defined
process
around
this,
so
that
issues
like
whether
you
know
me
coming
in
as
an
outsider
with
an
eip
so
that
you
know
like
issues
like
what
eips
get
in
and
what
the
deadlines
for
those
things
are
are
like.
You
know
set,
and
we
can
know
those
in
advance.
So
we
don't
end
up
with
this
kind
of
process
mess
every
two
weeks.
C
A
Yeah,
this
is
kind
of
attention.
I
strongly
agree
on
that
dano
had
put
an
eep
forward.
I
think,
a
year
ago
that
tried
to
address
some
of
that.
The
eip
1872,
where
we
could
kind
of
preset
some
dates
in
the
future,
for
when
we
would
actually
have
the
mainnet
hard
forks
and
that
allows
you
to
you
know,
go
backwards
and
set
deadlines
for
stuff,
and
I
guess
the
reason
why
this
process
would
burn
in
is
maybe
a
bit
flunky
is
it's
the
first
time
we've
tried
these
yellow
networks.
A
We
didn't
have
a
fixed
date
for
burden,
so
I
agree
it
kind
of
leads
to
like
growing
and
reducing
the
scope
and
and
and
kind
of
pushing
things
back.
If
what
people
you
know
care
about,
the
most
is
just
having
things
move
forward
then
yeah.
I
think
it
makes
sense.
We
keep
yellow
v3
as
is,
and
then
maybe
we
have
one
last
like
free
berlin.
A
It
wouldn't
even
need
to
be
a
test
that
I
guess
it
would
just
be
like
running
this
state
test,
so
the
people
feel
like
that
would
be
a
better
approach,
so
we
do
yellow
v2,
which
is
basically
done.
You
know
in
the
next
week
start
implementing,
yellow
v3,
which
I
suspect
will
take
us
another
two-ish
weeks
and
maybe
set
like
a
final
date
for
inclusion
to
berlin
for
stuff,
like
2565,
to
be
resolved.
I
2718
is,
it
is
sorry,
2930
is
depend
on
27.18,
and
there
is
a
very
strong
belief
that
we
should
not
do
2929
unless
we
also
include
29.30,
and
so
there's
also
a
strong
belief
that
we
should
include
29.29,
so
those
three
basically
kind
of
come
together
as
a
package.
Either
we
include
all
three
or
we
don't
include
any
of
them
is
kind
of
the
situation,
and
so.
I
I
Yeah,
the
the
fear
is
for
those
that
haven't
been
following
along
29
30,
we'll
introduce
access
lists
which
will
make
it
so
it
is
possible
to
not
have
your
contract
completely
inaccessible
because
of
2929
gas
repricing,
because
you'll
be
able
to
use
access
list
to
get
those
gas
prices
back
down
to
where
they
were,
if
you
absolutely
need
to,
but
it
is
not
required
by
anyone
to
use
them.
So
the
fear
is,
if
we
do
29.29
without
2930,
then
there
will
be
contracts,
maybe
that
are
completely
inaccessible,
because
it's
no
too
expensive
to
call
them.
K
I
think
the
2929
is
the
only
appeal
at
the
moment
with
enough
of
the
feel
of
urgency
that
that's
why
we
delay
everything
else
just
to
have
29
29
packaged
properly,
and
it
ended
up
being
slightly
more
difficult
that
we
were
planning
as
just
raising
gas
prices.
Now
it's
it's
trying
to
solve
a
few
more
issues
and
it
comes
with
other
things.
K
A
So
this
one
is
already
included,
but
I
think
that
2537,
the
bls
cricopal
was
another
pretty
important
one,
even
though
we
might
not
ship
berlin
prior
to
the
deposit
contract
going
live.
Deposits
into
eq
will
keep
coming,
and
I
think
there's
a
lot
of
value
in
being
able
to
validate
those
deposits
on
chain.
I
Is
are
there
people
who
still
demand
29
30
in
order
for
antoine
go
in?
I
don't
know
if
we
actually
know
that
this
will
break
any
contracts,
there's
just
a
fear
that
it
will-
and
I
personally
I'm
okay
with
breaking
things,
but
I
know
I'm
much
more
aggressive
than
most
people
here.
So
is
that
still
desired?
Do
we
still
demand
29
30?
If
we're
doing
29.
I
R
E
R
C
Yeah,
so
one
thing
that
we
could
do
now
that
I'm
fairly
certain
that
the
implementation
is
in
line
with
specification
since
I've
matched
it
with
visu.
I
can
really
do
the
same
analysis
that
I
did
on
gurley.
That
is,
take
a
couple
of
blocks:
re-run,
the
transactions
on
29
29
rules
and
see
if
they
start
failing
and
if
they
start
failing
see
if
they
also
would
have
failed
if
more
gas
had
been
given
externally,
I'm
sure
I
will
find
a
couple
that
will
still
fail.
C
C
I
D
A
good
ideal
test
we
do
have
the
way
to
do
it
and
it's
you
know,
because
I
do
actually
do
do
the
sports
for
cold
traces
and
at
the
moment
I
think
it
would
run
for
about
two
days
or
something
to
do
something
like
that
yeah.
There
is
a
possibility
to
do
that,
although
I
wanted
to
actually
suggest
the
potential
alternative
to
eip
90
29
29,
because
as
a
lot
of
people
know
that
I'm
still
mildly
opposed
to
that
so
yeah.
D
So
this
filtering
you
need
some
nuances,
but
essentially
it's
the
way
to
do
it
without
changing
the
rules,
although
there
are
still
attacks
that
are
hitting
not
the
absent
data
but
they're
hitting
the
existing
data
but
they're.
These
attacks
are
a
bit
harder
to
mount
and
they're,
probably
not
gonna.
You
know
you
cannot
sustain
them
for
a
long
time,
but
we
are
looking
into
those
as
well.
So
I
still
think
that
the
ip99
2929
is
is
too
complex
for
for
what
it
needs
to.
D
And
actually
I'm
going
to,
we
will
share
because
we're
doing
an
analysis
now
on
different
type
of
filtering
we've.
Basically,
what
we
have
already
done
is
which
works.
So
we've
done
the
bloom
filter,
very
simple
implementation
of
bloom
filter.
With
I
mean
we
took,
let's
say:
half
a
gigabyte
one
filter
and
also
a
quarter
gigabyte
boom
server
with
15
functions,
and
so
with
the
half
a
gig.
So
that's
only
for
accounts,
and
so
the
half
a
gigabyte
boom
filter
is
able
to
protect
perfectly
from
the
from
the.
D
So
basically,
it
has
zero
false
positive.
When
you
try
to
read
the
non-existent
accounts,
if
you
reduce
it
to
let's
say
a
quarter
gigabyte,
then
the
false
positive
rate
is
something
like
0.01
or
something
like
this,
and
then
we're
also
going
to
look
at
two
other
filters
like
cuckoo
filters
and
stuff
like
this,
because
they
allow
deletions.
D
But
generally,
I
think
we
might
be
able
to
find
a
way
to
kind
of
at
least
protect
against
those
attacks
and
move
on
to
the
next
level,
which
is
the
kind
of
more
expensive
attacks.
But
it
could
still
be
executed
and,
as
I
said,
that
it
doesn't
require
the
change
of
rules
and
doesn't
require
this.
Basically,
I
think
the
ip
is
becoming
a
bit
too
complex.
C
D
A
It
so
we
have
basically
two
minutes
to
go
sorry
to
kind
of
jump
in
here.
I'm
not
sure.
What's
like
the
best
next
step
here,
because,
yes,
we
do
have
the
lesser
yellow,
v3
and
yolo
v2,
but
is
it
even
worth
implementing
all
this
stuff?
If
there's
a
high
chance
that
we
don't
end
up
doing
it,
I'm
curious
what
yeah,
what
people
feel
is
like
the
best
next
step
for
29.29
and
then
the
bundle
of
27,
18
and
29
30.?
D
Oh,
no,
that's
not
necessary
because
you're
you
don't
have
to
sink
from
zero
to
to
construct
the
filter.
You
need
to
just
simply
iterate
through
the
state
and
build
the
build
it
initially.
So
that's
that
that
could
be
done
or
you
can
even
like
what
you
can
do
as
well
is
that
you
can
download
the
the
pre
well,
not
pre-made,
but
because,
because
actually
everybody's
balloon
filter
has
to
be
slightly
different.
N
N
Q
A
Okay,
so
I
guess
we
should
probably
also
just
continue
that
conversation
on
the
core
devs
chat.
I
know
this
is
yeah
not
kind
of
a
great
outcome
in
terms
of
clarity
of
process,
but
it
feels
like
it's
it's
probably
worse,
to
push
like
a
yellow
v3
forward.
If
we
don't
have
clarity
on
that,
especially
given
that
the
implementation
on
yellow
v2
is
is
not
fully
done.
Hopefully,
we
can
agree
kind
of
maybe
async
on
what
the
yellow
v3
spec
would
look
like.
Does
that
make
sense
for
everybody.
R
K
E
E
K
K
So
we
need
to
have
a
path
for
them
to
to
if
they
want
to
spend
time
and
provide
the
the
working
prototype.
That
shows
this
is
how
we
can
implement
this
change
and
all
the
clients
to
agree.
So
I
have
a
proposal
for
this
and
and
it's
in
a
way,
it's
iterating
over
two
great
things
that
we
were
discussing
in
the
last
year.
One
was
the
eep
specific
upgrades,
which
is
fine,
but
it
only
gets
much
much
stronger
with
the
ips
specific
testers
that
we
started
introducing
recently
with
eip-1559.
K
I
think,
by
binding
these
two
things
together,
we
can
show
exact
path
for
any
external
teams,
how
they
can
deliver
the
fully
tested,
described
and
analyzed
if
specification
that
can
be
easily
pushed
all
the
way
to
mainnet.
If
everyone
agrees
that
it's
beneficial
for
the
network
for
particular
use
cases
or
an
improvement
and
stop
bundling
things
and
making
them
delay
just
because
some
things
are
not
agreeable,.
J
A
Yeah,
so
maybe
again,
we
won't
resolve
this
three
minutes
over
the
call,
but
james,
if
you
can
share
that
test
net
on
the
core
devs
getter
chat.
That
would
be
great,
so
people
can
have
a
look
at
it.
Yeah
yeah.
Sorry.
I
said
that
this
for
this
gator
chat
still
so
on
the
the
the
discord.
That
would
be
good
and
then
the
other
thing
that
was
on
the
agenda,
which
we
we
can
maybe
very
quickly
cover
is
we
were
talking
on
discord
this
yesterday.
A
I
think
about
the
fact
that
most
clients
seem
to
be
working
on
a
sort
of
flat
database
approach,
so
get
a
snapshot
at
bc.
We
have
bonsai
trees.
Nethermine
is
working
on
on
something
as
well
and
turboget
is
obviously
architected
like
that
from
the
start,
and
because
we're
all
working
on
kind
of
different
flavors
of
it,
it
might
make
sense
to
set
up
a
call
to
just
discuss
that
and
share
notes
on
it.