►
From YouTube: Eth2.0 Implementers Call #6 [11/15/2018]
Description
A
A
A
Okay,
thank
you.
Everyone!
It's
been
okay,
they
can
hear
us
Ohio.
We
had
conned,
we
had
awesome
gone
there.
We
have
the
key
to
a
workshop
day,
which
I
think
went
really
well
and
we
can
talk
about
that.
A
little
bit
gonna
get
to
it.
First,
you
know
clients
these
days,
but
let's
go
through
quickly.
What's
been
going
on
with
the
clients
that
are
with
ones
and
we'll
go
from
there
who
wants
to
get
started.
B
Why
not?
We
can
start
with
lighthouse,
so
we've
been
regaining
momentum
at
the
Devlin
we've
been
focusing
on
onboarding
expanding
the
team,
as
it
was
always
got.
Alex
Stokes
who's
joined.
It
was
a
contributor
to
Kasbah,
really
smart
guy
really
excited
to
have
them
around.
We've
been
working
on
Rustler
p2p,
we're
gonna
start
focusing
on
state
transition.
What
the
biggest
change
we're
gonna
be
for
choice
and
one
of
our
security
guys
is
being
working
to
point.
The
AFL
fuzzing
library
at
RSS
said
implementation,
so
we
can
see
if
we
can
break
it.
C
D
We've
been
finished
with
other
stations
and
now
working
on
Els
and
finality
regarding
Bayliss.
We
decided
to
start
from
Milagro
to
evaluate
it
and
decide
on
whether
it's
not
whether
it's
sufficient
for
us
at
the
moment
or
not,
and
maybe
do
some
experiments
and
some
tries
to
implement
together
custom
implementation
of
VLS.
E
F
E
F
G
F
A
H
H
It's
by
this
stupidity,
employee,
let's
call
her
goomy
and
then
we're
implementing
like
no
wrapper
for
POS
12,
really
one
so
I
also
want
to
make
people
aware
of
the
hub
repo.
He
has
been
really
great,
yes,
Python,
but
he
has
Python
bindings
as
well
and
where
we
have
them
somewhat
under
the
p2p,
and
we
have
implemented
a
good
note.
So
right
now
we're
working
on
testing
on
that.
And
then
we
plan
to
work
on
the
relay
mode
nets
and
that's
pretty
much
it.
What.
A
I
So
in
the
in
coming
weeks,
I
will
I
will
isolate
the
Trinity
client
presentation
with
Danny
and
I
can
write
a
bounty
call
for
the
simple
serialize
in
Python
implementation,
which
will
made
it
to
be
a
more
production
version,
and
the
third
thing
is
that
sorting
out
the
version
of
the
spec
for
the
Trinity
test
net
a
for
you
hope
that
could
be
used
in
the
end
of
this
year.
Yeah,
that's
I,
don't
say,
updates.
Thank
you.
Cool.
J
Yeah,
remember
sorry
about
that.
So
I'll
just
give
a
brief
update.
There's
a
couple
of
things
going
on
from
the
side.
One
is
that
we're
hoping
to
contribute
a
little
bit
more
to
the
easy-to-understand
explaining
guides.
We
started
a
repository
where
we'll
be
publishing
a
few
tutorials
one
is
already
our
on
validators
there's
another
one
coming
up
on
on
the
beacon
chain
and
so
on,
and
we
encourage
everybody
to
join
us
in
in
those
reviews.
There's
a
repo
posted
I'll
put
a
link
in
chat
later
on
other
than
that.
J
We've
been
focusing
on
the
light
client
working
groups
investigating
how
to
approach
that
clients
secure
fashion
while
while
gaining
some
of
the
while
learning
some
of
the
lessons
from
East
1.0.
So
there's
a
working
group
for
that
going,
as
well
as
the
testing
group,
which
is
making
progress
so
likewise,
there's
a
channel
for
discussing
testing.
K
So
after
that's
gone,
we've
been
refocusing
and
regrouping
the
project,
so
internally
there's
been
more
interest
since
people
have
been
asking
about
it.
So
this
weekend
we're
gonna
be
holding
another
internal
hackathon
to
have
people
work
on
it.
We're
going
to
focus
more
on
turning
our
implementation
to
more
of
a
like
client
and
have
it
plug
in
with
the
current
dev
tools
for
the
a
theorem
JavaScript
ecosystem,
and
that's
that's
it
in
terms
of
an
update,
cool.
L
G
G
A
A
A
Now
that
we've
unified
the
states
and
made
a
few
other
changes,
we
expect
it
to
be
really
solidifying
in
the
neck
in
the
coming
weeks
as
we
work
through
just
more
of
the
minor
details,
bug
fixes,
etc.
The
phase
1
document
is
still
definitely
up
for
lots
of
changes.
We
just
kind
of
have
the
bones
in
place,
but
if
you
want
to
check
it
out,
the
phase
one
is
the
adding
of
the
data
change
the
shark
tanks.
So
if
you
want
to
check
that
out
and
start
internalizing,
it
you're
contributing.
Please
take
a
look.
A
A
Cool
next
thing
on
the
agenda
so
working
group
follow-up,
we
had
a
working
group
like
workshop,
meet
up
the
day
before
DEFCON.
It
was
generally
pretty
productive
and
there
was
decent
amount
of
Education
some
decent
progress
and
I.
Think
Justin
Justin
might
have
some
updates
for
us
soon,
but
working
groups.
A
O
O
O
We've
got
a
call
lined
up
next
week
with
Hudson
and
a
number
of
people
on
the
order
of
7
or
8
people
who
have
expressed
interest
in
helping
out
with
that
role
and
we're
hopeful
that
we'll
be
able
to
recruit
one
or
more
of
them
in
the
near
term
and
Danny
I.
Think
you
said
that
that's
probably
not
gonna
be
a
thing
for
the
2.0
roadmap
for
the
time
being,
but
we
are
moving
forward
with
it
for
the
1x
roadmap
yeah.
A
O
A
Quick
update
from
Justin
he's
been
Claudia
had
on
his
PDF
ran
in
his
research.
The
estimate
is
down
from
20
to
30
million
to
less
than
20
million
initial
discussions
with
tezo's
on
collaborating.
It
just
seems
like
more
and
more
teams
are
realizing
that
this
is
a
pretty
viable
use
case,
and
so
people
are
interested
in
collaborating
on
the
research
and
the
production.
A
You
could
go
down
that
path,
I'm
going
to
not
dig
into
this
security
research,
but
he
has
no
taste
of
security
research
little
and
he's
gonna
do
an
heath,
research
post
on
a
deep
dive
on
the
various
cryptographic
Hardware
assumptions.
Oh,
he
talked
to
me
a
little
about
this
there's
an
effective,
a
max
where
a
max,
which
is
the
assumed
attacker
advantage.
A
A
A
A
It
could
talk
to
multiple
nodes
and
it
could
one
node
could
sync
shards
three:
five
and
six
another
note
sink:
shards,
ten
and
eleven,
depending
on
the
architecture
there.
So
yes,
the
shards
live
and
the
same
client
node
software
as
the
beacon
node,
because
it
just
inherently
makes
sense.
But
if
we
designed
the
API
appropriately,
the
validator
software
could
talk
to
multiple
peek
to
our
notes
and
tell
each
one
which
shards
to
sync.
A
B
A
J
A
I,
a
hundred
percent
of
granulars
I
think
that
one
distinct
goal
that
I
have
is
to
define
an
API
and
such
that
a
piece
of
validator
software
can
be
cleanly
pulled
out
of
a
node,
or
at
least
a
cot,
a
node
that
does
implement
this
interface.
Not
that
maybe
nimbus
would
need
to
if
Nimbus
is
targeting
like
embedded
software
and
maybe
isn't
even
targeting
validators
but
I
want.
A
Imagine
a
node,
often
my
ship,
with
a
bout,
a
built-in
validation
to
suffer,
but
the
we
want
to
keep
the
separations
clean
such
that
somebody
else
can
write
a
different
validation
piece
of
software,
so
we
can
have
kind
of
diverse
setups
and
people
can
write
pooling
software
easily
and
everything
rather
than
having
them
super
tightly
coupled,
and
this
is
kind
of
akin
to
the
the
RPC
methods
in
eath
eath-
one,
oh
and
not,
although
it
would
be
best
if
everyone
did
conform
to
those
standards.
Not
everyone
performs
the
exact
standards.
N
A
N
One
of
the
outcome
of
the
dos
attacks
group
was
having
things
in
spec
is
good,
and
maybe
we
should
have
like
implementer
breast
practice,
so
a
kind
of
manual
that
says
that
this
is
implementation
detail.
But
this
is
what
we
recommend
and
if
you
deviate
from
that,
have
a
good
reason
like
a
MIDI
devices,
or
things
like
this.
A
Yeah
I
think
that's
reasonable
for
a
lot
of
it
and
in
terms
of
internal
architecture.
I,
don't
think
I
know
so.
I
want
to
go
down
the
road,
but
I,
understand
in
terms
of
DOS
attack.
Analysis
like
the
order
in
which
you
process
things
and
strategies
you're,
throwing
out
blocks,
I
think
that
those
should
definitely
be
in
like
a
common
repository
and
source
of
knowledge.
H
A
Right
I
kind
of
follow,
Piper's
philosophy
on
that
and
that
I
don't
think
that
a
node
should
really
be
managing
keys
and
that
the
layer
outside
should
should
definitely
but
in
terms
of
best
practices,
of
how
the
client
should
it's
a
great
question.
There's
all
sorts
of
interesting
things
that
you
can
do
in
terms
of
you
know
embedding
keys
and
secure
piece
of
hardware
and
things
like
that,
but
I,
yeah
I
agree.
It's
reasonable
to
cite
best
practices.
There
are
at
least
the
the
options
there.
P
P
A
Good
question
Justin
says
yes:
in
with
yes,
you
definitely
need
a
store.
A
copy
of
the
data
with
respect
to
the
separation
of
concerns,
I
believe
that
the
client,
the
validator
client,
rather
than
the
node,
should
be
responsible
for
this,
because
the
idea
would
be
that
if
you
turned
your
validator
client
off
and
swapped
out
a
different
node
underneath
the
hood,
its
evaluator
client
should
know
everything
it
needs
to
run
with
this
new
node
soft
memory.
A
So
if
it
needed
to
know
that
extra
storage
then
route,
then
it
needs
to
store
with
the
validator
rather
than
in
the
know.
Justin
says
they
can
rely
on
external
storage,
but
they
that
would
also
be
taking
on
counterparty
this,
but
in
general
yachts
anything
that
the
validator
needs
to
do
to
continue
to
do
their
job.
Like
remember
what
messages
they've
signed,
remember
this
storage,
the
the
storage
that
they've
proven
they
have
custody
of
that-
would
all
live.
A
J
B
B
A
A
F
It's
at
the
limit.
It
depends
of
a
number
of
shards
that
you
add
on
a
single
computer,
so
it's
very
at
the
limit
in
terms
of
and
for.
If
you
use
the
tree
based
logic,
then
you
need
to
be
identified
as
a
participant
in
the
aggregation
protocol.
You
can
be
participating
without
telling
where
the
aggregation
come
from
and
where
you
can't
you
don't
have
to
say
wherever
signature
come
from,
but
you
have
to
be
identified
as
a
participant,
I.
F
F
F
F
I
think
that
your
validator
is
likely
to
be
quite
difficult,
whatever
protocol,
because,
for
example,
if
someone
listen
to
the
network,
you
will
discover
who
is
going
to
validate
on
a
shop,
because
a
note
will
appear
at
the
certain
points
from
the
projection
that
we
did.
We
had
to
anot
class,
including
fraud
validators.
So
it
means
that
under
sounds
must
of
a
note
will
be
validated
anyway,
so
I
believe
a
trying
to
ID,
but
your
validator
is
it's
going
to
be
difficult
in
practice.
Q
B
Yeah,
at
least
we
can
try
and
make
it
difficult
right,
like
it's
probably
very
in
the
present
f.
You
can
pretty
much
pinpoint
where
transactions
came
from,
so
we're
always
gonna
be
open
to
that
kind
of
attack.
But
really
maybe
it
would
be
nice
if
we
didn't
have
like
some
easy
to
find
table
of
who
is
a
validator
because
they're
aggregating,
so
I
guess
we'll
just
do
the
best
we
can.
P
A
We
don't
need
to
go
through
this
all
today,
but
I
just
wanted
to
point
it
out.
That's
Raul
and
Kevin
defines
really
the
the
minimal
lip
Pizza
P
implementation.
As
it
came
to
my
attention.
Let
p2p
is
a
ton
of
stuff
and
you
get
to
pick
and
choose
what
makes
sense
for
you.
So
this
isn't
an
effort
to
help
people
who
are
beginning
to
work
on
the
p2p
implementations
to
narrow
the
scope
of
what
they
actually
need
to
work
on
and
I'm.
Sure.
A
A
B
In
the
issue,
I'm,
not
I
can
see
like
how
it
might
make
catching
foster
by
getting
rid
of
the
length
bite.
Somebody
made
a
point
kale
in
there
about
that.
We
don't
actually
use
the
length
fights
in
in
the
tree.
Hashing
I
didn't
implemented
it
yet
so
I
think
that's
something
I'm
overlooking
but
I'm,
not
personally
I'm,
not
I'm,
not
convinced,
without
seeing
like
some
sort
of
benchmarks
or
data
that
it
is
actually
a
problem.
So
I
know
the
spec
is
we're
trying
to
avoid
like
this
crazy,
optimization
and
trying
to
lean
towards
it.
B
A
I
agree
with
that
I
guess:
I
want
to
attack
this
question
and
twofold.
One
does
SSC
not
serve
our,
not
serve
our
purposes
for
the
protocol
serialization,
and
should
we
be
looking
into
an
alternative
and
then
to
what
should
that
alternative
be
I,
don't
particularly
want
to
take
on
the
complexity.
I
know
some
people
really
like
protobuf
I,
don't
particularly
want
to
bring
in
a
third
party
serialization
algorithm.
A
A
B
J
Yeah
I
would
add.
I
would
add
that,
with
reassessing
we've
already
separated
out
the
consensus
part,
which
is
a
good
thing,
I
think
elected
to
be
developed
separately
and
later
on.
If
we
find
that
there's
sufficient,
whatever
we
come
up
with,
is
sufficiently
similar,
then,
and
they
can
be
rejoined
as
well,
but
attacking
the
problem
and
making
the
best
like
not
not
doing
too
many
trade-offs
to
reach
like
a
single
pore
solution
is
a
better
approach
in
my
deal
in
my
world.
G
C
N
A
Okay,
maybe
I'll
digest
what
the
original
position
was
and
put
it
into
the
new
issue
you
can
discuss
there.
Okay.
Well,
then
not
ready
to
make
any
sweeping
changes
on
that
I.
Think
SS.
Ed
is
a
good
place
to
continue
forward
on,
but
open
to
optimizations
or
alternatives,
depending
on
what
we
uncover
in
conversation,
great.
B
A
I'm
surprised,
my
calls
only
dropped
once
manner.
That's
terrible!
You,
okay,
big
verse,
little
Indian!
We
don't
need
to
have
this
debate,
but
yosik
just
wanted
to
point
out
that
there
are
potentially
some
benefits
to
move
to
a
little
Indian
instead
of
paying
it
in,
and
do
you
want
to
speak
to
that?
Just
briefly,
engage
the
temperature
awesome.
J
Yeah,
it's
mostly
it's
again,
it's
small
ideas,
not
too
much
time
to
talk
about
it,
but
Hardware.
Today.
Basically,
all
the
commodity
hardware
uses
little-endian
modern
serialization
formats
like
Patterson
and
those
tend
to
favor
little-endian.
For
this
reason,
because
then
you
can
you're
just
better
mechanically
aligned
with
the
software
and
the
hardware.
J
I
guess:
there's
a
consistency
argument
for
using
beginning
and
on
Network
protocols
for
historical
reasons
and
yeah,
just
having
to
write
the
Indian
this
code
by
using
big
Indian
forces
you
to
write
the
end
in
this
code
on
all
those
platforms
that
use
Little,
Indians
I.
Guess
that
sound,
there's
a
correctness
argument
to
be
had
there,
but
it's
pretty
weak,
so
I
can
write
up
a
proposal
if
nobody's
against
it
and
then
like
clearly
against
it
and
just
by
citroen
I.
A
Okay,
general
spec
discussion,
like
I,
said
the
game
is
call.
We
we've
been
talking
about
these
phases,
phase,
zero
phase,
1
phase
2
phase
whatever,
and
now
we're
gonna
move
we're
moving
towards
having
a
clear
delineation
in
the
spec
of
sluice
babies
and
the
idea
is
that
a
face
and
just
dependent
upon
all
the
phases
less
than
them,
and
that
all
the
phases
less
than
n
can
be
built
without
having
to
think
about
base
right
now.
A
We've
unified
the
state
into
a
simple
state
route,
because
we're
using
this
tree,
hashing
algorithm
such
that
most
when
per
block
changes
happen.
Most
of
the
state
doesn't
change,
and
so
most
of
the
tree
hash
will
not
have
to
be
hashed
on
an
effort
for
simplicity
and
also
allows
us
to
serve
components
of
the
tree
easily
to
the
light
clients.
A
A
A
A
N
Have
something
Danny
yeah
in
the
FIM
magician
forum?
So
there
is
a
first
M
which
is
biggest
free
and
open
source
software
conference,
it's
on
February
2
and
they
submitted
a
request
for
a
dev
room
and
we
will
have
a
blockchain
and
the
sun's
realization,
they've,
room,
I,
guess
so:
no
decentralized
internet
and
privacy.
So
I
guess
we
could
have
at
least
people
at
the
Nimbus
team
will
be
there
initially
for
name.
But
we
can
add
others
from
e
2.0
as
well
and
I.
A
N
N
So
basically,
every
room
is
organized
by
someone
and
you
can
do
lightning
talks
like
talk
about
something
for
10
minutes
like
this
is
a
big
country.
This
is
a
video
for
or
something
and
the
organizer
I
don't
know
who
it
is
for
the
Broad
Channel.
But
but
the
deadline
is
in
15
days
for
various
talks
proposal.
A
A
A
No,
okay,
great!
Thank
you!
Everyone
for
coming
appreciate
it
being
a
little
shorter
I'm
in
Tokyo
and
it's
good
night.
We
will
I,
don't
think,
there's
anything
conflicting
with
meeting
in
two
weeks
that
will
be
finally
after
American,
Thanksgiving
great,
be
in
the
get
er
on
the
repos,
etc
and
sexual
soon.