►
From YouTube: Ethereum Core Devs Meeting #35 [03/23/18]
Description
A
A
A
Let's
see
if
you
refresh
the
agenda,
which
I'll
paste
into
the
chat,
I
just
added
I,
think
I
just
added
testing,
and
that
was
about
it.
But
I.
Anyone
wants
to
look
that
over
let's
see
and
then
anyone
who's
on
a
phone
if
you
could
mute
while,
while
everyone
else
is
talking,
that'd
be
great.
So
the
first
agenda
topic
we're
gonna
go
with
testing
so
Demetri
do
you
have
any
updates
or
anybody
else
in
the
room
on
testing.
B
Hi
ho
hello
continue
developing
this
RPC
Mehta's
is
a
great
test
tool
and
I'm
upgrading
CB
client
and
I
found
out
that
some
of
the
tests
actually
wrong.
Some
of
the
state
tests
and
they're
currently
investigating
what
was
exactly
the
issue
and
refilling
those
broken
tests.
It
is
a
pull
request
to
the
testing
repository
and,
if
you'd
like
actually
I,
would
like
client
developers
to
try
out
those
new
updated
tests.
Maybe
I
am
wrong.
Maybe
my
changes
to
sleepy
client
wrong
or
something
but
I
think
those
tests
were
incorrect.
B
Oh
yeah,
those
issues
that
some
of
the
test
might
not
made
it
to
the
hive
because
older
version
of
test
it
tried
to
construct
transaction
and
in
some
cases
the
transaction
was
throwing
an
exception
and
then
in
the
blockchain
test
out
of
the
state
test,
appeared
to
be
without
any
transaction
at
all.
So
there
are
some
cases
there
which
actually
I'm
just
not
testing
anything.
Just
because
transaction
not
constructed
in
testing,
so
I
fixed
additional.
C
B
Don't
see
the
tank
gonna
push
those
state
tests
in
blockchain
form
to
the
hive
anytime,
soon
I'm,
using
this
retest
tool
now
and
those
tests
generated
via
RPC.
So
both
these
issues
is
other
issues
with
cosa
cuz.
When,
when
I
execute
the
transaction,
we
our
RPC
on
a
client,
it's
it's
somehow
different,
using
the
humanoid
logic,
and
so
sometimes
the
post
date
is
different
like
right
now,
I
I
see
that
is
a
mining.
B
C
D
E
E
It
would
be
a
really
nice
addition
to
that
if
we
could
actually
set
them
up
in
such
a
case
that
they
would
also
cater
for
properly
testing
the
artistic
methods.
Just
because
currently,
there's
no
unified
test
suite
for
our
RPC,
simply
because
it's
really
really
hard
to
set
up
common
common
states
for
the
nodes.
So
I
think
it
would
be
really
nice
to
go
towards
that
direction.
To
we
something
there's
a
in
the
interfaces:
repo,
there's
a
there's,
a
discussion
going
on
I'll
just
paste
it
here.
E
E
This
is
a
sensitive
thing
which
may
or
may
not
be
broken
in
other
clients.
Then,
instead
of
having
to
dig
through
their
source
code
and
either
find
it
or
not
find
it,
it
would
be
really
nice
to
just
I
can
create
quickly
a
test
case
and
just
submit
it
against
all
the
clients
and
have
it
fail
or
not
fail.
E
B
E
Exporting
attacks
by
exporting
it
I
really
meant
that,
for
example,
if
I
create
a
test
case
in
in
GUI
theorem
for
whatever
that
it
would
be
really
sweet
if
I
could
actually
export
that
into
a
text
fixture
and
just
run
it
against
the
others
without
having
to
actually
manually
construct
the
other
one.
The
whole
thing
the
web
interface
would
be
just
something
that
would
be
you'd.
Allow
the
community
to
actually
try
and
reproduce
issues
or
test
issues
against
different
kinds.
E
So
essentially,
my
point
really
with
this
whole
thing
was
that
currently
we
only
have
consensus
tests
for
at
the
IBM
and
the
RPC
itself
in
none
of
the
clients
is
tested
which
usually
ends
up
with
all
the
clients
have
their
own
little
quirks,
and
then
we
have
test
RPC
and
truffle
and
various
other
clients.
Just
Oh.
Constantly
opening
bhakta
cos
that
hey
this
works
differently.
B
E
But
my
point
was
that
so
the
RPC,
the
respect
that
last
time
was
only
for
the
running
consensus
tests,
but
the
thing
that
we
are
discussing
with
Piper
and
Fredrik
would
also
allow
to,
after
you
construct
whatever
test,
whatever
idiom
test,
and
you
run
it,
you
could
actually
have
a
full
RPC
interface
for
it,
where
you
could
actually
pull
the
nose
for
data
and
interact
with
the
old
example.
I
could
ask
the
node
to
trace
the
last
transaction,
that's
possible
with
the
current
consensus
test
mechanism.
E
B
E
But
that's
not
our
point
that
if
we,
if
we
have
to
define
an
API
for
everything,
then
why
not
just
use
anyway
we're
kind
of
going
into
it
into
the
spec
details.
I.
Think
that's
beyond
the
point
of
this
discussion
now
I'll
just
I'll
paste,
the
spec
and
and
everyone
who's
interested
can
can
actually
comment
there.
So
we
kind
of
open
to
suggestion
from
all
the
teams,
because
the
idea
would
be
that
this.
E
A
E
E
A
A
F
Right
so
yeah,
this
is
basically
an
AP
for
to
propose
an
addition
of
an
RPC
method
to
sign
arrays
for
any
kind
of
arbitrary
data,
so
that
the
sign
is
you
I
can
easily
sort
of
the
user
what
they
are
signing,
and
so
they
can
actually
be
sue
of
the
bodies
of
we
are
signing
because,
right
now
they
just
see
us
and
they
don't
know
what
that
is.
At
the
same
time,
we
wanted
to
be
machine
verifiable,
so
the
discussion
has
been
continuing
for
quite
quite
a
long
time
recently.
F
F
F
C
Yeah
I
have
a
comment
and
I
think
it's
very
good
that
these
things
are
being
specified,
but
I
would
have
liked
to
see
some
more
people
in
its
discussion
and
I
reached
out
to
a
couple
of
people,
dance
dancing,
life
meta
mask
and
we
would
have
been
good
if
Nick,
Johnson
or
Leakey
was
here
as
well
to
weigh
in
on
it.
But
I
think
there's
a
at
the
moment.
There
are
huge
issues
with
the
way
that
we
have,
that
the
clients
signs
text,
and
that
is
also
something
that
needs
to
be
sorted
out.
C
F
F
C
An
appoint
one
also
suffers
from
some
of
the
problems
that
our
current
sine
theta
has
that
it
doesn't
say
how
large
the
total
envelope
of
the
messages
and
there's
the
kind
of
malleability.
In
that
the
way
it
works
right
now
we
have
the
number
9x19
etherium
sign
message
and
then
lengthen
and
the
message,
but
we
don't
have
the
total
length,
which
is
a
big
blunder.
A
A
A
Yeah
I
see
this
is
a
candidate
for
potentially
being
accepted
at
some
point
absolutely
and
we
should
at
least
make
it
a
draft
as
a
PR.
So
I'll
make
a
note
to
kind
of
comment
on
that
so
7
1
2
is
a
PR
and
work
on
that.
By
making
a
comment
on
that,
AIP
does
any.
What
does
it?
Other
people
have
comments
on
this.
C
A
No
problem
we'll
put
this
on
great.
So,
let's
see
what's
the
next
agenda,
topic
I
lost
the
tab.
Here
we
are
okay,
VIP
process
updates.
This
also
will
include
the
etherium
magicians,
meaning
that
recently
happened.
So
the
IP
editors
have
been
talking
and
the
first
step
that
we're
taking
in
I
guess
updating
the
EIP
is
in
general,
is
making
a
really
nice
interface,
and
this
is
actually
all
spearheaded
by
Nick.
So
I
should
say
that
out
front.
A
It's
Nick
Johnson
is
making
a
really
cool
Jekel
based
interface,
where,
as
the
IPS
are
submitted,
they
are
automatically
entered
into
a
website,
that's
easier
to
read
and
easier
to
collect
the
data
of
the
e
IPS.
That's
not
released
yet,
but
a
lot
of
PRS
are
going
into
work
on
that
and
to
kind
of
edit
some
of
the
initially
IPS
to
make
their
header
files
structurally
compatible
with
the
Jeckle
hosted
website.
So
that's
looking
really
nice
and
then,
after
that
kind
of
gets
going.
A
We're
gonna,
look
at
re,
redoing
parts
of
e
IP
one
to
make
it
a
little
more
clear,
especially
to
make
a
better
separation
between
standard
track
and
EIA.
Our
C's,
amongst
other
things,
and
some
of
the
stuff
we've
talked
about
in
previous
core
dev
meetings.
On
top
of
all
that
at
the
recent
SCC
conference
about
two
weeks
ago,
in
Paris
there
was
a
group
called
the
fellowship
of
aetherium
magicians
that
met
to
discuss.
A
Some
of
the
issues
were
having
with
a
IPS
and
governance
and
kind
of
aetherium
technical
topics
in
general,
so
lain
if
you
could
just
kind
of
go
over
briefly
some
of
the
stuff
that
came
out
of
that
meeting.
I
know
you
posted,
really
good
notes
on
at
2:00.
So
we
can
have
that
in
the
notes
for
this
meeting
and
posted
to
the
Gator
chat
and
stuff
like
that.
But
if
you
want
to
go
over
that,
that'd
be
great,
hey.
G
Hudson,
definitely
thank
you.
Can
you
guys
hear
me?
Okay,
yes,
awesome
yeah!
So
as
as
you
mentioned,
Hudson
I
took
pretty
thorough
notes
at
that
meeting
and
I
will
repost
that
link
here
and
in
Gator
as
soon
as
I
finished.
Just
give
you
a
really
quick
overview
of
what
sort
of
the
event
looked
like
looked
like
yeah.
G
So
by
way
of
background,
this
is
an
initiative,
the
fellowship
of
ethereal
magicians
that
was
organized
by
Greg,
Colvin
and
Jamie
Pitts
kind
of
spun
up
over
the
past
few
months
or
huge
thanks
to
those
guys
for
making
the
effort
to
do
this
and
get
it
off
the
ground
and
on
the
sidelines,
I
shouldn't
say
the
sidelines.
It
was
actually
a
workshop
at
ECC.
A
couple
of
weeks
ago,
the
first
meeting
of
the
fellowship
was
held.
It
was
a
personally
speaking
a
really
positive
experience.
It
was
a
very,
very
full
room.
G
I,
don't
want
to
put
an
exact
number
on
it,
but
it
was
on
the
order
of
probably
about
a
hundred
people
in
that
room.
It
could
have
been
sixty
or
eighty
many
different
groups
represented
so
from
throughout
the
ecosystem,
which
I
thought
was
really
excellent.
It
was
a
lot
of
kind
of
high-level
meta
discussion
at
this
stage,
given
that
it
was
the
first
meeting
so,
for
example,
Greg
shared
some
stories
of
some
of
his
previous
experiences
participating
in
various
consensus
based
decision-making
processes.
There's
a
lot
of
high-level
conversation
around
the
status
quo.
G
Things
like
how
the
IP
editors
are
chosen
today,
how
the
yaki
review
process
works,
the
hard
fork
process
and,
basically
generally
how
we
can
do
better
on
those
things.
There
was
also
a
lot
of
experiences
shared
with
how
other
groups
do
things
which
I
personally
found
helpful.
So,
for
example,
IETF
the
internet,
Engineering,
Task,
Force,
I,
hope
I
got
that
right
has
some
interesting
processes
that
they
use.
Holacracy
is
another
sort
of
consensus
mechanism
that
some
folks
may
have
heard
of.
G
We
discussed
that
we
discussed
kind
of
the
role
of
the
fellowship
of
ethereal,
magicians
and
and
sort
of
you
know
the
fact
that
it's
technically
focused
body
led
by
developers
and
whether
there's
a
need
for
a
separate
process
or
body
to
discuss
kind
of
the
political
side
of
things.
There
was
some
conversation
around
how
to
get
more
voices
involved
right.
So,
even
though
there
were,
as
I
said,
on
the
order
of
100
people
in
the
room,
obviously
not
everyone
participated,
so
that
was
something
people
agreed
as
important
and
generally
consensus.
G
That
meeting
in
person
is
important
right
that
you
know.
Flame
wars
have
existed
since
the
beginning
of
time
online
and
coming
together
and
meeting
in
person
and
showing
our
faces
a
few
times
a
year
is
a
really
important
process.
Part
of
the
process
of
building
consensus
and
sort
of
the
outcome
of
this
meeting,
which
was
intended
to
be
preliminary,
is
that
there
will
be
a
larger
event.
G
I,
don't
know
called
a
workshop
or
something
which
is
very
likely
to
happen
in
Berlin
around
July
and
there's
a
little
bit
of
a
question
around
how
its
funded
and
whether
you
know
some
organizations
are
going
to
stump
up
some
money
to
help.
People
who
couldn't
otherwise
come
forward
to
attend.
As
I
said,
I
will
share
the
link
for
those
notes
again
here
in
the
zoom
meeting
and
also
in
Gator.
A
H
D
Everyone,
my
name,
is
Raul
Sohn,
introduce
myself
I'm,
part
of
prismatic
labs
and
we're
building
the
first
charting
client
or
again
we're
currently
we're
currently
in
the
typing
charting
workshop
this
past
week,
and
we
will
be
hosting
a
meeting
discussing
our
implementation
for
phase
1
of
sharding
happening
tomorrow
at
11:00
a.m.
GMT,
for
if
anyone
is
interested,
we
have
a
prismatic
lab
skidder
channel,
where
we
will
be,
will
be
discussing
this
information
and
putting
out
a
comprehensive
road
map
of
our
first
development
Sprint's
to
get
it
into
an
example
of
phase
1
working.
D
A
Roll
yeah,
that's
really
exciting
I'm
and
stick
around
because
we're
gonna
be
talking
about
the
type
of
a
meet
up
a
little
bit
and
I
think
that's
what
it
was
called
and
go
over
some
of
the
stuff
people
did
and
sharding
and
things
and
then
I
see
leggy
just
joined.
Is
there
anyone
else
who
has
comments
on
the
etherium
magicians
meeting
or
governance
Epic's
in
general
that
they
want
to
discuss
or
talk
about.
A
I
I
So
the
main
important
thing
for
would
be
for
me
is
that
there's
an
upgrade
path
and
there
is
even
like
the
simpler
thing
that
could
be
done
first,
because
I
was
talking
to,
for
example,
the
guys
who
do
the
music
for
closest.
They
could
do
with
simpler
stuff.
First,
they
channels,
and
that
would
be
like
what
one
line
one
can
can
already
do.
I
Perhaps
you
should
finalize
one
of
the
simpler
ones
first
and
then
that
perhaps
even
use
that
as
a
container
for
seven
one
two
and
they
asked
the
main
question
is:
do
we
need
backward
compatibility
because
at
the
moment
state-of-the-art
it's,
it's
basically
broken.
It's
in
compatibility
old,
signed
data
method
because
of
the
length
field
in
the
middle
of
the
whole
thing
and
were
also
backtracking
in
this
one.
Eap
I
was
doing
there
where
that
came
in
that
this
old
quirk
from
Bitcoin.
That
is
just
an
implementation,
detained
and
survived
and
got
a
bit.
E
Yes,
so
it's
just
rather
minor
note.
It's
also
important
to
know
that
ledger
and
treasure
are
doing
it
differently,
which
means
that
probably
signing
is
really
really
freaky
currently
in
the
ecosystem.
So
I,
don't
I'm,
not
sure
whether
it's
worthwhile
to
try
to
keep
backward
compatibility.
The
interesting
question
that
we
should
not,
however,
forget
is
there
might
be
some
clients
depending
on
it,
which
means
the
only
fair
thing
thing
to
do
is
to
actually
reach
out
to
the
community
and
see
who
depends
on
it
and
make
sure
we
don't
break
anything
yeah.
I
I
At
the
moment,
there's
just
one
prefix
us.
Basically,
it's
just
a
serum
signed
message
like
this
all
prefix
signing,
that's
basically
the
prefix.
That
is
there
that
this
from
another
transaction.
If
it
has
this
prefix,
it
cannot
be
a
normal
transaction.
So,
but
if
you
could
do
different
prefixes,
you
can
do
differentiate
between
different
state
genders
or
different
use
cases,
because
we
will
have
the
same
problem
with
solve
currently
I
think
later
on.
F
C
C
F
A
So
it's
not
impossible
at
this
point
to
get
what
would
be
considered
broad
consensus
and
if
we,
and
if
we
miss
one
it's
I
mean
as
long
as
there
is
consensus
amongst
most
of
them,
I
would
say
that's
good
enough
to
get
the
EIP
approved
and
then
changes
in
the
actual
clients
that
are
then.
You
know
put
in
release,
notes
and
stuff.
A
That's
my
take
on
it.
Other
IP
editors
might
have
a
different
opinion,
but
that's
how
I
see
this
kind
of
moving
forward.
So
what
we'll
do
is
I
put.
This
I
already
have
the
agenda
for
next
meeting
up
on
the
PM
github
repository,
so
I
already
added
this
again,
so
we
can
talk
about
this
in
two
weeks
and
just
see
where
we're
at
so.
We
can
continue
to
get
this
moving.
Any
other
comments
on
this.
A
Okay,
great.
The
next
item
is
actually
metropolis,
but
I
kind
of
want
to
skip
that.
Just
because
I
think
it
would
do
us
I
think
it
would
be
better
to
talk
about
research
updates
and
the
recent
sharding
related
meetings,
because,
with
the
updates
from
there
we'll
be
able
to
better
get
a
sense
of
what
needs
to
potentially
go
into
metropolis
or
even
if
we
don't
get
a
sense
of
that.
We
kind
of
know
where
research
is
at
with
sharding
and
Casper
and
that
kind
of
stuff,
so
Vitalik
sincere,
leading
a
lot
of
these
efforts.
A
If
you
could
explain
kind
of
what
the
recent
meetings
what
they
produced
and
then
we'll
go
with
some
other
people
in
the
room
and
kind
of
get
their
take
on
this
specifically
with
Casper
and
sharding
not
doesn't
have
to
go
into
too
much
detail
about
where
we're
at
our
timelines
or
anything.
But
just
what
you
think
came
out
of
the
meetings.
H
J
Retreat
I
would
say
focus
on
ninety
percent.
On
Casper,
there
was
a
bit
of
a
stir
around
sharding.
There
was
a
bit
of
an
astro
section
because,
like
myself
in
pelada
needed
to
work
well,
there
was
shorting
was
definitely
the
main
theme.
So
we
spent
three
days
talking
about
a
variety
of
I
was
just
sorting
related
topics
going
through
the
charting
phase.
One
specs
are
just
been
published
about
a
week
ago
and.
J
When,
basically
going
through
the
various
details,
like
the
Commodore
proposed
again
James
execution
games
and
some
people
brought
up
like
very
a
sub
issues
with
the
current
protocol,
we
cannot.
We
came
up
with
some
improvements.
We'll
probably
do
another
round
of
thing
of
thinking
about
improvements,
generally
kind
of
got
everyone
and
who
was
there
on
the
same
page,
so
that
included
both
the
kind
of
core
cerium
research
team
and
people
from
parody's
status.
J
J
Otherwise,
godsend
of
whom
I
got
to
know
we
show
there
were
talks
about
like
various
kind
of
theoretical
crypto
economic
issues
to
deal
with
designing
sharding
protocols
talks
about
what
the
roadmap
would
look
like
and
what
the
longer-term
would
look
like.
So
the
basic
roadmap
is
the
multi
stage
approach
where
agent
one
is
basically
an
implementation
of
sharding
that
is
kind
of
rooted
inside
of
the
main
chain
and
where
the
main
chain,
and
where
there
is
no
state
transition
function.
J
J
I
guess
consensus
on
the
data
that
so
like
that
by
itself
is
mainly
useful,
for
you
know
like
things
like
play,
only
ROI
or
like
Twitter,
on
the
blockchain
or
whatever,
then
in
parallel
and
the
likely
to
come
soon
after
that
would
be
stage
2,
where
we
basically
finalized
the
FT
transition
function
and
create
a
way
for
our
clients
to
own
execute
the
state
transition
function
for
an
event
in
charge.
Do
this
sum
depends
on
finalizing
extraction
into
plans
on
finalizing
Wadhams,
and
it
depends
on
finalizing
the
GM.
J
J
H
Sure
so
I
just
maybe
to
add
to
that
a
little
bit
definitely
a
lot
of
really
interesting
discussions.
One
thing
that's
definitely
worth
noting
is
on
the
third
day
we
had
a
big
meet
up
and
that
meet
up
is
actually
recorded,
and
so
anyone
can
check
it
out.
We
did
two
panels,
one
with
a
bunch
of
the
node
implementers
and
then
the
second
one
with
just
a
bunch
of
researchers.
You
know
Vitalik
lab
John
and
Justin,
and
you
know
everybody
and
check
that
out
on
YouTube,
it's
on
all
star
panel
etherium.
A
J
Basically,
the
sharding
spec
is
specifically
designed
so
that
the
charting
rollout
is
like
absolutely
totally
independent
of
what
happens
on
the
main
chain
as
long
as
the
main
chain
continues
to
work
and
provides
the
functionality
of
like
basically
having
bots
and
accepting
transactions.
So
the
Casper
FFG
rollout
will
happen
on
the
main
chain
and
it.
E
J
J
J
J
A
J
It
depends
on
timing,
like
if
timing
has
it
what
if
we
want
to
weaken,
so
we
have
this
rough
list
or
Constantinople
just
be
the
Casper
fork
and
at
the
same
time,
I'm
Alexi.
Whatever
other
things
we
wanted
to
do.
If
we
decide
we
want
to
do
a
couple
of
other
things
faster
and
then
then,
like
you
might
be.
Okay
des
and
I
called
I
can
Staunton
opal
and
then
Casper
can
be
again.
Eli
can
be
called
where
the
next
part
for
it
is
I.
A
See:
okay,
that's
an
important
decision
to
make
and
yeah
I
said:
Byzantium
I
meant
Constantinople
a
second
ago,
okay!
Well,
that's
something
we
can
discuss
a
little
bit
more,
but
before
we
jump
into
that,
does
anybody
else
who
was
at
the
event
or
have
any
comments
about
the
event
like
roll
or
Peter.
D
One
of
the
things
that
we
discussed
was
creating
a
common
loafer,
there's
already
a
starting
repo
in
the
etherium
github,
where
we
plan
on
having
more
structured,
markdown
documents
aligning
everyone
on
maybe
like
the
smart
contract
API,
they
will
use
for
the
charting,
manage
your
contract.
One
of
the
things
that
could
be
useful,
perhaps
if
you
could
mention
vitalik,
was
how
charting
will
be
done
through
the
contract
and
how
that's
different
than
maybe
the
the
the
Casper
contract
and
plans
to
maybe
merge
that
global
validator
set
into
one
in
the
future.
J
Yeah,
so
in
it's
definitely
so
like
it
definitely
has
to
go
to
eventually
some
where's,
the
validator
set
and
merge
all
the
functionality
ISM
into
one.
The
ER
I
guess.
The
general
philosophy
here
so
far
is
basically
that
like
phases
wanted
to
be
of
sharding
and
phase
one
access
for
both
going
to
kind
of
happened
separately
for
in
what
city
and
eastern
and
ease
of
implementation
reasons,
and
so
they
can
both
actually
be
independent
of
each
other
and,
like
you
know,
and
also
being
kind
of
self-contained
and
safer.
D
Cool
yeah,
one
of
the
other
things
I
wanted
to
mention,
is
that
my
team
is
focused
right
now
on
a
local
test
and
implementation
of
phase.
One
sharding
on
basically
a
private
private
appear
in
blockchain,
where
we
will
forego
certain
some
of
the
p2p
considerations.
That's
one
of
the
biggest
unknowns
that
that
all
the
shouting
teams
got
out
of
the
event
that
the
peer-to-peer
networking
for
sharding
is
something
that
we
still
have
to
store
a
long
ways
ahead
figuring
out.
So
we
will.
K
Jump
in
there
this
is
Ben
from
consensus,
so
it
was
great
to
be
at
the
workshops
and
awesome
ideas
discussed
like
rel
and
prismatic
I
think
we
have
a
sort
of
practical
bent
at
consensus.
We're
keen
to
get
on
with
making
implementations
and
rails
identified
some
of
the
critical
points.
So
we
all
need
to
talk
to
one
another.
K
I
think
our
other
concern
would
be
to
try
to
accelerate
some
of
the
timelines
that
were
discussed
during
the
course
of
the
workshop
where
we
came
to
make
this
happen
as
soon
as
possible,
and
that
will
require
a
lot
of
collaboration.
So
we
need
to
set
up
the
mechanisms
to
make
that
happen,
but
yeah
thanks
for
the
invitation,
everybody,
it
was
a.
It
was
a
great
week.
E
If
we
want
to
split
up
between
blockchain
to
100
charts,
then
all
of
a
sudden,
you
don't
really
want
to
talk
to
people
outside
of
your
shard,
or
there
are
certain
nodes
that
will
want
to
talk
to
multiple
shards,
certain
certain
those
that
will
jump
in
between
shots,
and
these
are
really
features
that
the
current
beauty
protocol
does
not
support.
Now
felix
has
been
trying
to
spec
out
I.
E
Think
he's
working
at
least
three
concurrent
the
IPS
on
trying
to
push
forward
in
this
direction,
but
I
think
it's
a
it's
definitely
a
thing
that
we
kind
of
need
to
pay
attention
to
that
charting
will
not
be
possible
without
beautiful
overhaul.
So
that's
it!
We
shouldn't
forget
about
it
and
only
focus
on
their
cousin
sports
who's.
K
A
E
So
people,
when
you
kind
of
have
to
access
data
between
multiple
shots,
that
data
that
might
actually
change
between
or
while
you
are
accessing
it,
then
it
becomes
all
of
a
sudden.
This
distributed
system,
synchronization
problem,
and
we
had
the
really
nice
discussions
in
how
locks
could
work
or
could
blow
up
or
how,
for
example,
really
interesting
challenges
that
what
happens?
For
example,
if
you,
if
you
try
to
obtain
basically
you
to
run
the
transaction,
you
want
something
from
the
other
shard.
E
But
then
your
shard,
all
of
a
sudden
reorganizes,
which
is
a
really
interesting
challenge,
and
we
also
want
to
bit
into
thinking
whether,
for
example,
message-passing
architectural
versus
versus
the
classical
locking
mechanism
would
be
more
appropriate
so
going
towards
queueing
theory
and
is
sequential
communicating
processes
stuff.
Now
we
don't
have
any
concrete
solution,
so
we
are
just
debating
the
upsides
and
downsides.
E
The
reason
I
wanted
to
mention
it
is
that
I
think
this
is
a
hard
problem
to
solve
and
it's
definitely
can
use
a
lot
of
people
in
the
community
thinking
about
them
and
just
bring
up
ideas.
So
if
I
think
we
should.
This
is
something
that
the
community
should
feel
free
to
jump
in
and
try
to
figure
out.
D
Speaking
of
community
interactions
and
other
fruitful
debate
that
came
out
of
this
was
discussion
around
the
Pine
Valley
of
storage
on
the
etherion
blockchain.
We
had
a
lot
of
questions
about
rent
at
the
the
meetup
and
specifically
discussions
about
how
we're
going
to
interact
with
smart
contract
developers
to
understand
their
needs
like
to
get
there
get
there
and
get
their
voices
heard
to
implement
this.
So
I
was
wondering
if
it
Helen
a
little
bit
about
this
discussion.
J
Yeah,
so
basically,
the
idea
that
we
talked
a
lot
about
is
storage
grants,
which
basically
means
that
if
you
have
a
contract,
that
contract
has
to
pay
some
amount
of
PS
per
block
per
byte
in
order
to
in
order
to
stay
alive,
and
the
reasoning
behind
this
is
that,
right
now
there
is
this
imbalance.
We
are,
on
the
one
hand,
creating
like
a
very
short
whipped
contract
is
arguably
a
bit
too
like
it's.
J
Yes,
when
gas
prices
are
very
low
and
as
I
can
and
then
the
gas
token
contract
can
be
called
and
on,
you
didn't
consume
that
so
again,
to
basically
have
it
clear
one
of
its
storage
keys
and
give
you
the
10,000
items
like
unit
gas
refunds,
whatever
the
gas
price
is
much
higher
yeah.
So
basically,
the
holes,
like
the
entire
system,
does
a
bad
job
of,
but
properly
sufficiently,
pricing
contracts,
creation,
making
contract
creation,
pricing,
non-volatile
and
I'm,
making
out
of
correct
them
in
correct
incentives
to
clean
up
storage.
J
You
know
like
right
now,
I,
basically,
no
one
really
cleans
up
storage,
even
even
despite
the
other
than
ten
thousand
yes
and
their
refund.
So
there's
a
pretty
strong
between
all
of
that
and
the
desire
to
I
keep
are
a
small
state
size,
which
is
what
may
be
important
different
one
fastening
things
to
be
viable
in
the
long
term.
There's
some
idea
of
basically
charging
per
bite
in
that
question.
The
contract
origins
and
become
fairly.
J
Like
the
Asian
major
proposal
that
a
lot
of
people
are
in
favor
of
and
when
we
need
so,
there
are
like
some
different
versions
of
this
that
we
discuss
that.
We
discussed.
We
spent
a
lot
of
time
discussing
the
user
experience
issues
so
basically,
look
in
what
way
was
having
to
a
keep
contract
to
like
arm
the
user
experience
I
mean
what
we
could.
L
A
Okay,
great
so
yeah
it
sounds
very
promising.
Everything
seems
to
be
moving
faster
than
anticipated,
so
that's
great
I'm
I'm
on
the
fence
about
asking
about
timelines
only
because
the
meeting
just
happened.
So
what
I
think
I'm
gonna
do
is
not
ask
about
timelines.
So
coin
desk
doesn't
put
out
an
article
saying
we're
gonna
be
done
tomorrow
and
are
done
with
sharding
or
Casper
tomorrow,
and
we'll
talk
about
that.
The
next
time.
A
That's
the
editor
and
another
coin
desk
person:
let's
see
what
I'm
looking
last
at
the
last
meeting
notes,
because
we
talked
about
where'd,
it
go
oh,
so
we
agreed
upon
a
few
things
that
are
gonna
be
in
Constantinople,
particularly
EIP
145
for
bitwise
shifting
and
the
EVM
block.
Hash
refactoring
is
something
that
is
likely
to
happen
because
it's
gonna
help
a
lot
with
some
of
the
things
we
have
coming
up:
that's
EIP,
210
and
then
there's
some
other
ones.
We
are
looking
to
add,
potentially
just
something
that
reduces
gas
cost.
A
If
we
can,
if
we
can
do
that-
and
it
makes
sense
so
we
were
initially
gonna
finalize
things
over
the
next
month
or
so.
But
with
this
recent
meeting,
I
think
that
everyone's
real
anxious
to
get
a
hard
fork
out
and
that's
understandable
from
the
community's
perspective,
I
should
say
the
community
wants
to
get
changes
out
and
for
things
to
get
done,
but
there's
not
that
many
super
radical
changes
happening
in
Constantinople,
currently
without
Kasper
or
sharding,
and
so
from
my
perspective,
I
think.
M
A
We
shouldn't
be
rushing
to
get
a
date
out
for
the
hard
fork,
even
though
we
were
initially
saying
we
were
having
things
like
a
count
abstraction
in
there.
That's
now
delayed.
We
were
thinking,
it
was
gonna,
come
out
in
the
first
half
of
this
year,
I
think
delaying
it's
gonna
be
the
best
bet
or
not
delaying
really.
We
never
set
an
official
date,
but
pushing
it
out
further
sounds
like
a
better
idea.
What
what
is
it?
What's
everyone's
thought
on
that?
Well,.
H
J
I
would
generally
just
say
that,
like
I
think
we
should
try
to
move
the
move
away
from
the
idea
that
not
hard
Forks
are
the
only
thing
to
get
excited
about,
because,
like
at
least
I
personally
feel
like
get
the
impression
that
you
know,
a
community
is
definitely
excited
about
the
big
about
the
big
ones.
But
you
know
if
no
one's
going
are
going
around
and
saying
like
yeah,
you
know
like
yet
you
know
BRR
et
cetera
or
whatever.
The
numbers
are
so
I.
J
J
E
J
E
So,
just
to
save
a
few
concrete
numbers,
so
basically
we
have
some
funnier
BN
256
curve.
We
have
currently
three
operations,
addition
multiplication
and
pairing,
and
we
kind
of
switched
out
our
our
library
or
implementation.
For
these.
The
addition
was
fairly
cheap
so
that
one
got
about
a
2x
improvement.
E
Multiplication
got
20
to
25
X
improvement
in
the
etherium,
so
that's
that's
insanely
fast
and
bearing
is
about
I,
think
4x,
give
or
take
so
about
four
times
faster
than
our
previous
implantations
was
with
the
current
so
I.
The
problem
is
that
these
are
the
raw
benchmarks
which
are
kind
of
I.
Think
here
the
meaningful
thing
would
be
if
we
could
find.
Of
course,
the
pure
to
benchmarking.
E
A
tongue-in-cheek
thing
that
I'm
kind
of
currently
happy
about
is
that
the
BN
250,
basically
that
contract,
so
the
Z
cash
verification
is
currently
about
three
times
faster
into
a
theorem
currently
than
parity,
which
kind
of
I
assumed
and
then
the
same
optimizations
can
be
applied
to
parity
and
get
them
on
par.
With
these
speed,
ups.
A
E
Though
so
it's
still
not
spectacularly
fast
and,
for
example,
a
really
a
really
interesting
thing.
That
I
only
realized
now
while
doing
is
optimized
version.
Is
that
the
curve
that
we
are
using
so
the
official
basic
to
verify?
That
point
is
on
the
curve
or
respects
all
the
requirements
in
the
official
curve.
It
requires
one
less
multiplication
so
essentially
just
parsing
a
content.
A
binary
blob
into
a
curve
point
in
our
curve
is
a
lot
more
expensive
than
in
the
view
show
curve.
E
So
that
was
a
bit
of
a
bummer
when
I
realized
it,
but
there's
nothing.
We
can
do
about
it.
One
potential
thing
that
what
I
was
actually
considering,
but
this
this
should
be
benchmark-
is
that,
for
example,
our
pre
compiles
in
the
elliptic
curve
they
kind
of
so,
for
example,
when
I
did
the
peering
points
when
I
parse
them.
So
every
time
I
want
to
do
an
operation.
A
A
E
A
The
hard
fork
we
would
have
like
if
we
did
a
hard
fork
tomorrow
with
what
we've
agreed
on
it,
would
be
two
things:
I
think
2e
eye,
peas
and
then
potentially
one
more
if
it
would
get
suspect
out
the
rest
of
the
way,
I
think
it's
Vitalik
s--
one
that
isn't
fully
spect
out.
Yet
let
me
look
at
which
one
that
is
real,
quick.
A
J
A
That's
true
so
I
mean
if
we
started
this,
if
we
decided
all
right
we're
doing
these
two
e
IPS
for
a
hard
fork.
You
know
starting
tomorrow
or
something
not
the
hard
for
tomorrow,
but
starting
testing
in
a
month
or
two
like
that,
would
put
a
big
rush
on
them.
Actually,
I
should
I
should
clarify
with
Demetri
Demitri
if
we
were
to
decide
on
doing
a
hard
fork
with
tui
IPs.
With
this
new
testing
framework
you
developed.
A
B
Actually
prefer
to
restore
the
existing
test.
Functionality
is
the
client
and
the
new
testing
tool,
but
if
merely
need
to
you
could
still
use
old
testing
tool
to
create
tests
was
a
new
rules
currently
Yoichi,
adding
new
tests
or
beat
while
shifting
is
that
the
hard
work
you're
talking
about?
Actually,
yes,.
B
A
E
A
A
Alright,
so
we
got
the
last
thing
on
here
is
client
and
research
updates
a
lot
of
clients
who
couldn't
make
it
here
today
to
their
updates
and
the
agenda.
So
if
people
want
to
look
through
that,
I'll
be
going
over
them
as
we
hit
those
clients,
the
first
one
will
go
with
as
parody
so
parody
posted
theirs
as
a
text
update
and
offerees.
Also,
here
a
free
I
know:
y'all
just
had
a
major
release
that
put
some
really
cool
features,
and
do
you
want
to
kind
of
just
go
over
this?
A
O
O
O
Yes,
we
are
about
to
finish
to
outsource
our
actual
user
interface
or
our
wallet
to
a
standalone
attack
on
what
again
some
details
about
some
more
minor
things
like
might
sink
to
spots,
getting
a
command-line
interface.
We
are
completely
overhauling
how
we
deal
with
execute
yeah
factoring
our
engine
for.
O
A
O
A
A
G
Yes,
so
we
did
I
called
that
awasum
University
in
Paris.
It
was
really
really
great.
We
had
we
had
Sergei
from
the
Paradis
team
there
with
us.
We
also
had
folks
from
true--but
who've
been
working
on.
Some
was
some
stuff
and
a
couple
of
other
teams
that
joined
us
for
part
of
the
week
or
so
that
we
were
doing
a
sprint
in
Paris.
G
You
know
we
disgusts.
There
are
definitely
some
differences
between
the
implementations,
so,
for
example,
the
way
we
do
metering
is
a
bit
different.
There's.
A
couple
approaches
here
like
one
is
metering
contracts
at
deploy,
time
versus
metering
them
at
runtime
and
there's
a
trade-off
here
and
one
gives
more
flexibility
around
kind
of
changing
gas
prices
in
the
future.
There's
some
consensus,
sorry
I
should
mention.
We
had
Martin
from
Definity
with
us
as
well
so
kind
of
a
lot
of
the
folks
working
on
on
wasum.
G
The
only
other
thing
I'll
say
on
wasum
today
is
we're
still
definitely
making
progress
moving
forward.
You
know
aiming
to
get
a
waz
I'm
testing
it
up.
On
the
order
of
weeks
from
now,
there
was
some
conversation
between
the
e
azam
team
and
the
folks
in
Taipei
about
the
connection
between
was
demand.
Sharding
I,
don't
know
if
italic
or
anyone
else
wants
to
speak
to
that
or
what
that
wrote
that
might
look
like,
but
it
just
sounds
like
it
hasn't
been
worked
out.
G
J
J
A
J
A
A
E
So
we
don't
really
have
any
too
spectacular
updates.
We
did
basically
I
think
it
was
about
one
and
a
half
months
ago
we
did
a
major
release
and
since
then
they're
kind
of
just
polishing
up
the
stuff
and
just
trying
to
figure
out
what
next
major
feature
we
want
to
add,
which
is
basically
what
I
think.
E
Currently
the
most
painful
point
is
is
during
this
is
the
synchronization
and
we
had
had
a
discussion
about
that
in
Taipei,
along
with
the
party
team
and
Fredrik,
and
we
were
kind
of
thinking
about
somehow
converging
on
on
a
new
synchronization
model,
because
both
fasting
and
warp
sync
are
starting
to
break
down
and
show
different
signs
of
issues,
and
so
currently
I'm
just
playing
around
with
with
a
few
ideas
that
may
or
may
not
work
out.
So
that's
and
Felix
is
also
playing
around
with
a
with
the
discovery
protocol
ideas.
E
Roads
were
playing
around
with
my
client
ideas,
marking
they
get
playing
around
with
the
signer
ideas,
so
I
think.
Currently,
we
just
we
want
to
make
sure
that
any
bug
that
we
find
in
the
industry
in
our
country
get
fixed
and
just
trying
to
pick
a
direction.
That's
that
will
bear
fruit
for
the
next
major
race.
L
Yeah,
so
mostly
it's
like
colorful,
the
work
was
about
to
add
support
for
Aladdin
engine,
and
so
that's
all
of
the
stuff
going
on
around
the
VM
and
EMC
interface
and
the
second
part
done
by
Andre.
It's
mostly
bug
fixing
and
improvements
related
to
database,
peer-to-peer
network
blockchain,
sync
and
yeah.
That's
that's
all!
Yes,
unless
somebody
want
to
add
something
to
that.
A
P
So,
by
fixing
the
issues
I
meant
mostly
the
forcing
because
it
still
has
some
bugs.
We
need
to
really
trying
to
debug
that,
but
we
have
as
well
the
warp
sync
type
of
synchronizations
implemented
as
well.
It
knows
not
to
actually
finished,
but
it
works
already.
So
we
use
parities
work
protocol
for
that
and.
E
A
E
So
it's
a
I
mentioned
it
actually.
I.
Think
I
also
mentioned
it
here
that
I
talked
quite
a
lot
with
Frederick
about
it
in
Taipei,
and
we
discussed
the
various
issues
around
the
fasting
warp
sync
and
they're.
Basically,
both
of
them
are
kind
of
crumbling
under
the
load,
and
we
kind
of
need
something.
That's
more
flexible,
I
mean
both
of
them
can
be
patched,
but
maybe
it
is
better
to
just
figure
out
something
that
can
scale
for
the
next
two
years.
Instead
of
the
next
two
months,
yeah.
A
Great
love
crab
collaboration.
The
next
one
is
harmony,
they're
not
able
to
be
here,
but
they
said
that
they
did
a
release
with
performance
improvements.
1.70
and
1.71
is
the
latest
version.
They
also
have
good
progress
on
Casper
research
and
they're
waiting
for
updates
from
paya
Thap
to
adopt
them
and
set
up
a
test
network
from
scratch,
the
one
that
they
currently
had
fell
apart
last
week
the
cause
was
deposit
or
it
fell
apart
a
week
ago
because
of
deposits
scaling
factor
became
0
is
what
they
said.
A
Okay,
Trinity
the
PI
AVM
one
Webb
3
version,
four
is
nearing
a
stable
release
and
the
first
Trinity
alpha
is
around
the
corner.
There
polishing
up
some
minimal
MVP
with
a
minimal
subset
of
light
clients,
Inc
json-rpc
api,
and
you
can
do
Python
repple
with
a
web
3
instance.
So
that's
pretty
exciting.
E
Quick
question
regarding
Trinity
I'm,
not
just
so
I'm,
not
sure
whether
you
talked
to
them
or
I'm,
not
sure
how
how
well
you
know
how
they're
progressing.
So
it's
a
pity
that
Piper's
not
here
that
rappelled
Python
replicative
caught
my
eye.
Do
you
think
whether
they
are
that
is
going
to
be
shipped
inside
Trinity
or
whether
it
would
be
an
external
to.
E
A
Finally,
turbo
goth
implemented
the
hash
file,
optimization
hashes
of
the
top
5
levels
of
the
state,
hex
tree
and
memory
mapped
file.
It
says:
there's
a
medium
article,
that
kind
of
explains
it
a
little
bit.
That's
linked
on
the
agenda
and
the
test.
Turbo
goth
update,
fixed
a
lot
of
tests,
started
to
fix
the
API
functionality
and
started
the
test.
A
Sync
with
normal
memory
quote
normal
memory
is
4
to
16
gigabytes
and
found
a
lot
of
issues
so
he's
fixing
them
now,
that's
from
alexey,
whether
any
other
updates
Rolla
you
kind
of
gave
an
update
earlier.
But
did
you
have
anything
else
from
prismatic
labs
or
Ben?
Do
you
have
anything
from
Pegasus
that
you
feel
like
mentioning.
D
Sure
so
I
in
the
chat
I
mentioned
the
the
meeting
that
we're
having
where
we're
going
to
be
discussing
our
exact
development
sprint
for
phase
1
charting,
but
my
team
also
I
linked
the
Gator
channel
there
and
you
guys
are
interested.
You
can
join
there
and
track.
Our
updates
will
be
releasing
also
bi-weekly
development
updates
to
be
a
medium
and
our
mailing
list.
That's
on
our
website,
so
you
know
if
anyone
wants
to
know
more.
Just
definitely
PM
me
for
more
information.
That's
that's!
Basically,
it.
K
K
So
we
are
developing
a
full
etherion,
client
services.
This
has
been
mentioned.
We
haven't
made
a
formal
announcement
of
it
yet,
but
it's
no
secret,
and
so
that
will
be
developed
and
open
sourced
and
provided
as
a
consensus,
supported,
client
and
we
fully
magnetic
impossible
and
sharding
is
part
of
that.
So
we're
doing
the
charting
client
alongside
that
as
well
awesome.
M
N
E
Yeah
so
I
sent
my
so,
for
example.
The
reason
why
this
was
brought
up
in
in
the
Inca
theorem
that
going
on
since
forever
ship
with
a
console
and
the
Christian
console
is
kind
of
like
really
really
legacy
based,
so
basically
to
go
if
they
go
JavaScript
interpreter
and
it's
it's
based
on
a
kind
of
a
notes
back,
it
works
fine
as
long
as
you
don't
want
to
do
really
fancy
stuff.
So
as
long
as
you
use
it
as
a
simple
CLI
tool
or
debugging
tool,
it's
fine!
E
But
if
you
want
to
enter
a
fancy
JavaScript
territory,
it's
it's
not
suitable,
and
so
what
we're
kind
of
considering
is
so.
We
don't
really
want
to
grab
the
console,
because
it's
it's
valuable,
debugging
tool,
but
we're
actually
wondering
whether
we
would
we
could
actually
create
a
completely
separate
aetherium
console.
That
is
just
the
JavaScript
console
based
on
low
GS
or
whatever
greatest
latest
and
greatest
to
Larry's
and
the
latest
web
3GS.
E
And
then
people
could
actually
connect
to
going
theorem,
those
or
basically
any
other
node
and
and
have
a
really
nice
way
of
interacting
with
it.
And
since
you
guys
said
that
you're
actually
considering
creating
a
wrapper
for
Python
I
was
actually
wondering
if
you
can
actually
make
a
Python
console
to,
then
it
would
be
really
awesome
to
have
both
the
JavaScript
and
the
Python
console
that
can
attach
to
basically
any
other
node.
N
Yeah,
that
sounds
amazing
I
mean
from
from
our
point
of
view.
It
would
just
take
a
little
bit
of
wiring
code
to
say
you
know
if
your
guess
instance
has
all
the
connection
parameters
you
need.
You
could
start
up.
You
know
a
Python
repple
with
web
3
instruments
already
configured
ready
to
go
I,
don't
think
it
would
be
all
that
much
work
honestly.
E
Ok,
so
I
think
I
just
want
to
pop
this
idea
along
that.
If
so,
for
example,
for
us
it's,
we
don't
really
want
to
drop
the
JavaScript
console
because
everybody
kind
of
got
used
to
that
and
it
doesn't
really
matter.
What
do
we
find
in
a
better
language,
it's
kind
of
just
in
the
community
or
everybody's
used
to
it,
but
I
think
it
would
really
awesome
to
be
able
to
actually
provide
different
or
other
means
to
to
interact
with
nodes.
A
Awesome
I
think
that
was
the
last
client
or
research,
so
Nick
Johnson
joined
Nick.
We
talked
about
di
Pisa,
leer
and
I
briefly
mentioned
your
stuff,
but
not
a
lot
of
detail.
So
if
you
want
to
go
over
any
of
your
updates
to
what
you've
been
working
on
in
the
e
ip's
repo
and
your
Jekyll
stuff
go
right
ahead.
Sure.
M
Yes,
Reformation,
so
I've
been
working
on
some
changes
to
make
it
more
accessible
and
readable
and
indexable,
and
so
on.
I've
converged
with
the
EPS
repo
into
a
Jekyll
site,
which
means
automatically
build
an
HTML
version
from
all
of
the
eats
and
index
them
by
type
II
stations.
You
can
see
a
preview
of
that
on
a
record
top
can
have
dot
io
/
beeps
like
it
on
the
set.
M
M
So
if
you
have
an
outstanding
me,
it
will
need
to
be
adjusted
accordingly
before
submitting
I'm,
also
adding
a
Jekyll
as
very
logical,
Trevor
scripts,
which
will
automatically
Chi
tips
for
validity
on
all
open
requests,
and
that
has
identified
a
couple
of
issues
need
to
be
addressed
in
order
to
fix
bills.
Specifically,
there
are
two
weeks,
one
nine,
eight
and
seven
seven,
eight
that
are
unmerged
reference
to
alleged
heaps.
M
So
if
the
authors
of
those
two
one
may
ashes
for
telex
and
seven
seven
ages,
Felix's
would
be
able
to
work
with
me
on
getting
them
polished
off
and
merged
a
greater
since
they're,
both
referenced
from
either
handful
heaps
or
from
other
ones.
Internally,
and
in
particular,
one
nine
eight
legs,
a
copyright
assignment
which
the
telecom
self
needs
to
add.
M
Nobody
else
can
edit
on
this
behalf,
so
it
would
be
really
good
to
get
those
merged
so
that
we
can
fix
the
build
and
then
to
what
a
net
checking
of
humans
there's,
also
half
a
dozen
teeps
most
the
older
ones
that
are
referenced
from
equine,
there's
examples
of
good
eats,
but
actually
I've
merged
either
and
those
are
less
urgent.
But
it
would
still
be
good
if
anyone
wants
to
go
over.