►
From YouTube: Ethereum Core Devs Meeting #32 [01/26/18]
Description
A
A
All
right,
the
agenda
is
pretty
short
today,
so
we
can.
If
anyone
wants
to
go
and
do
a
lot
of
detail
about
their
stuff
feel
free.
The
first
item
is
going
to
be
testing
updates.
Is
anyone
here
who
can
speak
to
just
updates
on
testing
anything
including
fuzz
testing
or
some
stuff?
Dimitri
usually
does.
B
C
Regarding
Foss
testing
and
the
hype
testing,
we've
had
to
move
all
the
infrastructure
from
a
short
to
AWS
and
getting
it
up
again
and
Guido
has
now
joined
us
on
the
DevOps
side
to
help
run
the
passers
and
maintain
the
new
infrastructure.
So
it
kind
of
yeah
hope
we
go
kind
of
relaunch
the
kasnian
purchase
soon
as
possible.
A
Great
that
sounds
pretty
cool
and
Tim,
and
you
know
Ichi:
do
you
already
have
a
contact
with
each
other?
If
not,
we
can
just
share
that
info
on
get
her.
D
E
D
Email
should
sure
yeah
yeah,
perfect.
A
So
unless
someone
wants
to
start
out
with
a
different
topic,
I
think
we
should
kind
of
discuss
what
EIP
should
go
into
metropolis.
So
then
we
can
get
a
better
idea
or
sorry
into
Constantinople,
so
we
can
get
a
better
idea
of
when
it
will
happen
so
I'm
going
to
the
EIP
page
right
now,
let's
start
with
the
account
abstraction
the
IP
86
right
now,
I
know
Vitalik.
You
had
a
III
search
message
post
about
a
month
ago.
That
you
said
was
getting
some
replies
about
it.
E
Let
me
get
the
link
there,
we
go.
I
got
a
lot
of
replies,
so
this
was
the
concepts
direction,
specifically
in
the
context
of
sharding,
where
there's
less
backwards
compatibility
requirements,
but
like
basically
the
main
proposal
that
people
is
so
far
seems
to
like
the
most
because
involved,
basically
in
all
the
one,
the
pig
ass
off
code.
So
the
idea
here
is
that
there's
in
that
there
would
be
a
new
approach
called
Pig
ass,
which
would
have
two
functions.
E
E
Arose
before
the
pig
a
stop
code
has
been
caught
at
any
point,
then
the
transaction
is
totally
invalid,
but
if
the
top-level
transaction
execution
throws
after
pig
that
he
gets
off
would
have
been
called,
then
the
transaction
is
that
was,
and
the
purpose
of
this
is
basically
that
said
of
any
execution
before
the
pas.
Opcode
is
like
execution
that
should
be
considered
as
kind
of
part
of
a
to
clarification.
So
we
will
include
things
like
signatures
that
are
liquid.
No
nonsense
in
some
cases
might
include
more
things
and
anything
that
comes
after
the
pig.
E
They
would
have
run
the
transaction
execution
for
up
to
that
amount
of
gas
and
if
the
P
gets
off
code
has
been
called,
then
we
know
that
the
transactional
pay
for
itself
and
over
animal
running
folium,
though
included,
but
if
it
has
not
done,
albeit
in
the
transaction,
and
so
this
basically
kind
of
substitutes.
The
distinction
between
like
prevarication
and
full
full
transaction
execution.
But
there
was
another
part
of
discussion
which
has
to
do
with
nonsense
or
in
protocol
nonces
versus
not
in
protocol,
not
having
a
protocol.
E
C
E
Benefits
are
there
okay,
so
number
one
AB
signature
abstraction,
so
you
can
use
whatever
TIG
is
your
scheme?
You
want
number
two
like
replay
protection
abstraction
so,
like
nan
says
you
CXOs,
like
one
particular
example,
is
if
you
have
something
like
let's
say,
like
a
ring
signature
mixer
contract,
then
like
a
ring
signature
mixer
contract
is
going
now.
It
already
has
its
own
replay
protection,
because
the
linkable
ring
signature
mechanism
itself
prevents
you
from
using
the
same
key
to
withdraw
multiple
times.
E
But
if
you
try
to
force
that
kind
of
contract
to
have
nonsense,
then
I'm
like
you're,
going
to
have
a
problem
because
you're,
basically,
if
two
peoples
in
this
transaction
around
the
same
time,
then
if
one
gets
in
the
other
we'll
have
to
update
the
transaction.
It
also
lets
you
do
other
stuff
like
it
lets.
You
potentially
make
preview
occasions
much
more
much
more
complex,
so
one
motivating
use
case
that
I
was
thinking
about
was
like
ICO
is
where,
if
you
have
an
IC
o----,
where
let's
say
there's
a.
E
A
A
E
E
C
C
E
Here
well,
I
actually
did
not
eat
me.
I
did
not
even
be
8061
at
all
before,
but
I
guess.
The
main
difference
between
that
in
this
proposal
is
that
this
proposal
also
has
the
mechanism
where,
if
a
transaction
exits
for
a
guess,
then
it's
invalid.
It
executes
after
it's
valid
and
look
under
coupling
with
a
key
on
abstraction.
G
So
I
would
also
italic.
I
would
also
add
another
restriction,
because
I
can
see
like
this
could
be
used
as
the
attack
vector
so
I
would
add
the
restriction
that,
before
the
pegas
instruction
is
a
code,
you
are
not
allowed
to
access
the
state.
Only
the
local
information
from
the
transaction
that
I
that
I.
E
Basically,
because,
like
there
are
a
lot
of
the
motivating
cases
that
I
think
about
actually
require
you
to
access
the
states
before
in
order
to
do
like
various
checks,
so
one
example
would
be
checking
the
nonce
another
example
as
ICO.
Is
this
ICO
example?
Another
example
is
the
racquetball
thing.
Is
your
case,
like
all
the
interesting
ones
require
you
to
access
the
state
before
they
guess?
E
F
C
C
I
B
A
B
E
J
F
But
there's
there's
a
there's,
someone
signing
John
with
the
transaction
and
someone
else
can
just
post
a
transaction
on
the
blockchain
and
that
person
will
pay
the
gas
that
allows
more
flexibility
where
I
can
sign
a
transaction,
send
it
to
someone
and
that
person
basic
s
transactions
but,
under
my
name,
I
think
my
my
my
might
change
less
things
in
the
VM
and
on
the
on
how
we
expect
contracts
work,
and
it
also
is
similar
to
help
a
lot
of
contracts
are
doing
where
they
just
sign
a
message
and
send
somewhere
off
chain.
I.
F
A
It
got
it
186,
okay,
cool
yeah
and
after
you,
when
you
do
that
comment,
just
put
the
common
in
all
core,
Deb's
and
I.
Think
that
would
be
good,
let's
see
so
that
kind
of
went
over
96
a
little
bit
metallic.
You
said
you
changed
your
opinion
to
where
it's
a
little
bit
more
important
and
that's
and
the
awesome
team
kind
of
feels
the
same
way.
A
F
B
B
J
So
I
think
there
was
like
on
the
way
there
was
like
three
versions
of
the
contract
like
one
was
from
the
Thai,
coordinate
and
I
did
some
change
proposed
some
changes
there
and
then
was
another
one
that
was
a
bit
more
generalized
and
includes
everything
in
some
kind
of
tight
loop.
So
I
don't
remember
exactly,
but
I
think
we
just
have
to
review
that
code
again
at
some
point
and
yeah,
but
it's
just
1
1
1
notice
from
me.
Is
that,
like
that,
centralized
efforts
to
have
this
bytecode
ready,
so
it
doesn't
like
it's.
A
Okay,
understood
yeah,
I
think
that's
good,
ok
and
then.
Lastly,
on
this
I
mean
there
might
be
other
comments,
but
specifically
from
me,
this
EW,
which
one
oh,
the
IP
96
Piper
I,
saw
that
there
was
unmerge
in
the
last
month
where
he
refactored
the
vm
vm
state
and
blocked
of
new
apply
transaction.
Did
you
actually
and
it
referenced
this
AI
p?
Did
you
actually
already
partially
implement
the
CIP.
K
K
K
Yes,
so
we
are
quickly
working
towards
having
a
here
apply
transaction
concept
in
PI
ABM,
essentially
getting
ready
for
statements,
clients
getting
ready
for
being
able
to
run
it
under
that
paradigm,
so
that
is
moving
along
quickly
and
we've
got
a
lot
of
that
into
the
core
library.
Now
we're
kind
of
back
porting,
these
things
from
the
sharding
branch
into
kind
of
our
main
branch
as
they
seem
appropriate.
K
A
Yeah
my
understanding
on
96
is:
there
needs
to
be
more
collaboration.
So
if
some
of
the
people
who
discussed
this
Vitalik
powell,
yo
ichi
others
who've
been
involved
in
the
conversation
for
e
IP
96,
if
you
all
could
start
rehashing
that
a
little
bit
and
getting
a
more
formally
IP
that'll
help
us
the
next
chord
AB,
meaning
okay,
EW
145,
bitwise,
shifting
instructions
in
the
EVM
that
was
Alex
pairs,
Ozzie
and
pebble.
A
J
So
so
the
the
AAP,
it's
it's
ready
and
has
been
marked,
so
it
can
get
an
hour
round
of
peer
reviews
and
we
house
of
have
the
CPP
implementations
ready,
except
we
need
some
some
way
of
configured
the
client
to
actually
include
this
feature
in
the
VM.
So
it
can
either
go
with
the
some
kind
of
fake
constantinople
fork
or
can
be
some
separate
configuration
that
enables
only
this
one
that
that's
that's
the
only
thing
that
hasn't
been
done
yet
and-
and
we
can
start
after
that-
we
can
start
making
tests
and
so
on.
So.
A
J
Don't
show
it
deserves
a
test
net,
but
we
at
least
can
have
a
classic
JSON
test
for
this
case,
and
yes,
so
some
some
if
implementation
would
be
welcome.
If
not,
some
of
us
can
actually
jump
on
and
implement
that
and
in
go
probably
so
shouldn't
be
like
big
deal,
considering
it's
using
only
some
additional
functions
from
from
big
big
number
libraries.
L
A
Okay
sounds
good,
usually
at
least
for
a
ip's
getting
accepted.
There
needs
to
be
a
few
implementations,
but
if
it's
on
its
way,
like
there's
implementations
in
progress
that
can
be
considered
as
well
as
it's
kind
of
how
we've
been
doing
it
as
far
as
I
can,
as
far
as
I
understand,
okay,
so
any
other
comments
on
145.
A
H
L
H
I'm
not
saying
that
the
test
cases
should
cover
all
the
all
the
color
cases
or
two.
It
should
be
two
exhaustive,
but
it
would
really
have
if
there
would
be
at
least
a
handful
of
to
three.
However,
many
test
cases
that
just
kind
of
covers
some
generic
use
cases
so
that
so
that
I
as
an
implementer,
if
I
implement
my
code,
I,
can
actually
check
it
that
it
kind
of
seems
to
work
before
even
getting
to
the
point.
Looking
it
up
and
merging
into
into
master
it's
just
kind
of
nice
feedback
for
for
implantations,
yeah,.
L
J
For
this
case,
I
think
we
can
like
have
like
like
up
to
20.
It
should
be
like
big
deal
to
also
cover
some
negative
cases.
I
mean
it's,
it's
I
think
it's
it's
general
practice
to,
for
example,
having
some
hash
hash
functions.
Example:
tests
included
in
spec.
You
think
that
in
this
case,
that
should
be
should
be
fine
to
have
them
as
a
part
of
specification.
D
A
L
The
way
it
works,
if
you
figure
even
like
a
fourth
name
tentatively
like
Constantinople,
then
we
could
merge
it
in
this
IP,
client
and
test.
It
could
generate
the
test
cases
under
the
Constantinople
for
claim
for,
therefore
the
bitwise
shifting,
but
it
needs
to
have
a
name
in
order
to
generate
the
test.
F
H
A
A
A
A
That's
what
it
was:
we're
gonna
yeah,
basically
look
at
the
EIP
and
add
some
more
detail
and
then
and
then
145
that's
gonna,
go
in
cool.
Are
there
other
AIPS
that
are
not
in
the
deferred
table
that
people
are
interested
in,
including
in
Constantinople
that
they
have
handy?
If
they
don't
we'll
talk
about.
A
E
So
one
of
them
is
that,
if
an
account,
if
it
accounts,
balance,
drops
below
like
twenty
one
thousand
times
that
transaction
gas
price
and
then
the
account
disappears
and
the
other
one
says
that,
if
like,
when
you
create
a
new
account,
the
initial
non
has
to
be
like,
be
like
it.
Instead
of
being
zero,
it's
some
different
number
and
like
that,
basically
just
does
replay
protection
in
the
context
of
accounts
being
able
to
disappear.
Sometimes.
E
A
A
And
then,
additionally,
do
we
want
to
start
doing
somewhat
of
a
timeline
or
kind
of
even
just
like
a
rough
quarter,
one
quarter
two
quarter
three
or
quarter
four
for
Constantinople
guessing
not
P
1,
because
that's
we're
in
the
middle
of
that
right
now.
But
is
this
something
that
could
probably
be
done
by
you
know
q3,
maybe
I
need
anybody
have
an
estimate
or
do
we
need
to
kind
of
flush
out
the
rest
of
the
EIP
s
before
deciding
that.
F
A
Like
the
idea
of
timing,
it
so
where
we
have
like
a
month
to
decide
on
a
ip's,
multiple
months
to
implement
multiple
months
to
test
and
then
release
and
coming
up
with
coming
up
with
some
hard
timelines
on
the
on
those
goals
and
those
milestones.
So
we
should
hopefully,
by
next
meeting,
come
up
with
some
Moree
IPs
and
I.
Think
that
that
will
help
us
start
formulating.
How
much
time
we
have
left.
A
J
So
I
was
working
on
this
test
of
optimization.
I
saw
that
we
have
many
tests
that
you
just
ran
because
of
our
previous
optimization
that
every
test
case
is
being
executed
on
every
fork.
But
now
we
have
another
fork
and
another
four:
can
we
have
like
hundreds
of
tests
being
executed
and
the
most
of
them
are
just
wasting
our
time,
because
example,
static,
old
tests
have
been
executed
on
all
Forks,
but
we
don't
need
to
run
static
old
tests
on
frontier
homestead
and
as
an
as
a
hard
Forks
which
do
not
introduce
this
opcode.
J
What
clients
might
not
need
to
implement
any
changes
actually
because
it
will
just
remove
the
post
some
post
states
from
the
test
and
let's
eat
it's
mostly
for
diet,
Escalus.
So
now
I
plan
to
create
a
test
from
a
test
filler
for
only
those
networks
that
specifies
only
those
networks
means
Forks
networks
and
prongs.
I
specified
an
expect
section
of
the
test
filler.
So
when
you
create
the
test
you
could
specify
on
which
Forks
this
test
will
be
executed.
K
J
J
K
J
A
A
Let
me
see
something
real,
quick,
there's
just
a
comment:
I'm
checking
on
yep,
so
yeah,
that
is
the
correct
decision,
actually
axe.
Academy.
Look
at
the
comment
on
the
agenda
about
the
EIP
145
decision
and
yeah
that
that
that
is
exactly
what
we
came
up
with
need
to
include
a
couple
of
test
cases
and
start
having
clients
implement
if
that
works.
A
Let
me
see
what's
the
next
item
on
the
agenda.
Oh,
so
someone
on
the
agenda
asked
if
we'll
see
short-term
scaling
improvements
with
death
1.8
by
increasing
the
gas
limits
without
having
the
uncle
rate
go
massively
up.
I,
don't
know
if
they
understand
the
correlation
between
gas
limits,
uncle
rate
and
the
client
updates,
but
we'll
probably
just
go
into
client
updates
right
now,
so
that
we
can
get
all
the
updates
from
gath,
including
their
1.8
release.
H
H
And
what
basically,
we
haven't
done
any
two
scientific
measurements.
Yet
so
we
started
on
importing
the
entire
food
chain.
It's
it
shows
it
is
promising.
We
also
started
some
benchmarks,
really
preliminary
brand
benchmarks
on
the
main
net
and
as
far
as
I
can
see
it,
it
reduces
disk
growth
by
about
eighty
percent,
so
that's
kind
of
really
nice.
But
the
answer.
H
The
specific
question
posted
on
github,
whether
this
will
have
on
correct
or
not
so
this
will
not
speed,
go
with
theorem
up,
but
it
will
actually
prevent
it
from
slowing
down
or
at
least
slowing
down
so
too
fast.
So
this
is
a
in
my
opinion.
It
will
be
a
very
welcome
change,
because
then
you
don't
need
to
resync.
So
often,
maybe
just
five
times.
H
Oh
sorry,
one
fifth
of
the
time
and
we're
also,
we
also
have
a
separate
or
request
or
a
proof
of
concept,
experimentation
to
actually
implement
full
garbage
collection
too,
so
that
so
currently
what
we
do
is
that
we
try
to
minimize
the
amount
of
junk
we
write
to
this,
but
we
still
occasionally
have
to
write
to
disk,
to
flush
out
from
memory
and
in
a
follow
of
work.
That's
probably
going
to
be
one
nine.
H
Zero,
we
will
I
really
hope
that
we
can
actually
get
full
garbage
collection
implemented
so
that
even
past
the
junk
that
we
had
to
write
out
to
disk
can
be
cleaned
up
afterwards.
So
that
definitely
won't
come
for
the
next
release,
but
I
would
really
like
to
have
the
next
release
much
much
more
stable
one
and
much
more
usable
one
than
the
previous
ones.
So
that's
mostly
this.
The
scalability
fixes
that
we
were
working
on.
Otherwise
there's
a
ton
of
work
going
in
on
various
fronts
like
client,
networking,
etc.
I
Yes,
yeah,
we
just
released
1.9.
Today
it's
turned
out
to
be
one
of
our
fastest
clients,
so
far,
I
have
gotten
if
we
didn't
expect
that,
so
we
had
a
lot
of
travel,
this
broken
walkthrough
and
database
issues,
but
they
seem
to
be
fixed
or
some
resort.
So
we
are
pretty
satisfied
with
the
current
release
yeah.
So
for
the
future
watering
or
snapshots
it
will
be
hard
to
maintain
on
this
year.
I
Network,
you
choose
a
growing
state
size
and
we
are
currently
at
the
point
where
it
takes
longer
for
a
client
to
generate
a
new
snapshot.
Then
new
blocks
are
mined
in
this
window
between
two
snapshots,
so
the
result
is
that
there
are
not
enough
snapshots
or
not
enough
notes,
serving
snapshots
under
the
network,
our
focus
for
the
next
week's
and
want
us
to
put
water
422,
light,
client,
development
to
and
user
experience
yeah.
I
I
I
A
I
B
A
E
M
There's
all
the
clients
that
already
have
a
Casper
implementation,
but
we
tried
to
test
it
in
Casper,
a
test
network.
We
use
the
directions
from
alpha
Casper
to
snap
instructions
post
made
by
Carl,
but
looks
like
that.
Good
nodes
are
not
work
in
our
something
like
that,
so
I
mean
which
is
who
who's
the
best
contact
or
what
is
the
best
channel
to
ask
about
problems
with
that.
M
J
So
we
have
awasum
vm
integrated,
so
it
can
run.
He
was
a
mother,
yeah
vm
for
smart
contracts.
That's
I
think
the
the
only
thing
I
would
like
to
share
in
terms
of
CPP
node
I
also
released,
if
minor,
if
anyone
is
interested,
its
version
of
the
0.14
and
thanks
for
external
all
external
contributors
that
make
it
happen
with
a
very
nice
community.
Der.
G
G
Think
of
a
memory
to
get
through
that
and
then,
of
course,
after
the
state
clearing
that
the
the
the
state
compresses
again,
unfortunately,
I
didn't
get
to
run
it
very
far,
because
I
need
I
still
need
to
implement
reworks.
So,
but
that's
what
I'm
working
at
the
moment
yeah.
So
my
plan
is
to
just
just
try
to
stabilize
it
and
see
if
it
could
be
actually
made
work
as
a
client.
That's
it.
A
E
So,
on
the
Casper
side,
the
Alpha
Casper
FFG
test
net
has
been
running
for
a
few
weeks
and
don't
eat
the
boy.
The
chief
says
for
that
it
has
not
been
running
q
well,
mainly
because
we
realized
that,
like
pi
etherium,
networking
is
actually
not
good
enough
to
like
quick,
it's
so
key
for
connecting
to
the
Tor
network.
But
it's
not
good
enough
for
me
getting
a
network
all
by
itself
without
other
nodes,
and
so
it's
require
and
ended
up
requiring
quite
a
bit
of
active
maintenance
and
some
firewalls
and
a
couple
other
hacks.
E
They
did
to
get
around
the
fact
that
we're
getting
like
200,
random,
Jeff
and
parity
connections
coming
into
each
node,
the
NGO.
That
said,
the
the
Casper
aspect
of
Casper,
where
it's
where,
if
a
blog
is
final
like
basically
two
conflicting
watch,
should
not
be
possible
to
get
finalized
seems
to
actually
happen.
Running
in
the
network
seems
to
actually
kind
of
have
agreed
all
along
as
to
what
the
finalized
chain
is.
So
that
part
is
totally
convinced
totally
successful.
So
far
is
that
kind
of
on
the
back
on
a
bit
of
a
back
corner.
E
Oh
here
we
are
we're
basically
doing
on
the
shardene
implementation
on
top
of
Pi
EVM,
the
yeah
there's
a
basic
spec
that
is
add
over
here
at
the
this
link
over
here,
which
is
and
updated,
updated,
a
lodge
would
and
it's
theoretically,
I
think
good
enough
as
a
kind
of
full
spec
of
what
meant
of
what
kind
of
minimal
stage
one
charting
is
going
to
look
like,
and
it's
about
and
there's
a
like
shell
way.
I
think
has
a
something
like
a
for
phased
roadmaps
for
I
get
it
forgetting
it.
E
Actually,
we
deployed,
and
it
seems
like
kind
of
part.
One
of
these
one
is
I,
get
getting
miss
something
like
being
already
done
at
the
end.
We
expect
like
the
next
stage,
to
be
finished
after
a
master
a
month
in
a
bit,
so
the
main
problem
we've
been
working
a
lot
on
getting
some
of
the
auxilary
changes,
so
things
like
account.
E
Access
list
account
abstraction
written
into
PI
EVM
and
the
weave
of
it,
and
we've
spent
a
lot
of
time
on
like
on
developing
a
new
binary
tree,
developing
like
what
witness
compression
for
the
binary
tree
right.
The
next
step
will
probably
be
actually
getting
like
getting
the
Steelers
clients.
Logic
was
like
thinking
moving,
but
syncing
blocks
and
witnesses,
so
we're
working
well
and
then
from
there
we're
going
there
and
if
try
to
turn
it
into
AJ.
I
was
a
working
test.
A
E
A
B
She
was
able
to
able
to
notch
my
product
about
the
Byzantium
changes
into
yellow
paper
master,
and
there
are
enthusiastic
contributors
who
we're
fixing
typos
or
adding
internal
hyperlinks
in
the
document.
So
it
is,
they
have
started
adding
hyperlinks
so
that
when
you
click
on
an
unknown
symbol,
you
can
jump
to
the
definition
of
that
scene.
K
It's
not
a
client
update,
but
we
are
approaching
a
stable
v4
of
web
3py,
which
we've
got
some
really
nice
new
stuff
in
there
Jason
Carver
the
lead
dev
on
that
Roda,
a
nice
blog
post
covering
a
number
of
those,
but
some
of
them
are
gas
price
API.
Is
that
mirror
some
of
the
functionality
of
the
eath
gas
station,
which
I
think
a
lot
of
clients
are
either
adopting
and
if
they
aren't,
they
should
look
into
adopting
something
along
those
lines,
because
it
is
a
solid
algorithm
for
doing
gas
price
projections.