►
From YouTube: Eth2.0 Implementers Call #19 [2019/6/13]
Description
A
B
B
We
just
released
new
0-7
the
other
day.
This
is
generally
not
a
crazy
like
major
semi
major
release,
but
because
it
has
breaking
changes,
but
it's
not
a
major
release.
It's
just
kind
of
iterative
so
that,
if
you
do,
if
it
helps
you
follow
along
between
now
and
the
end
of
June,
to
have
something
that
you
can
like
fight
them
to
by
all
means.
B
But
if
you'd
rather
wait
through
the
end
of
June,
do
you
think
the
the
end
of
June
release
is
gonna
be,
and
the
subsequent
minor
fixes
from
there
is
gonna,
be
probably
what
most
people
are
targeting,
so
this
middle
one
is
just
for
your
use.
If
you
want
it
cool,
so
we
will
get
started
with
testing.
The
b07
vectors
are
out
we've.
B
Our
tests
have
become
even
more
inefficient
and
the
Python
on
mainly
due
to
the
tree.
Hashing
so
we're
kind
of
exploring
some
some
of
the
caching
methods
to
speed
that
up,
but
right
now
it's
not
a
major
blocker
mainly
just
makes
generating
the
tests
for
y'all
take
longer,
but
that's
a
isolated
one-time
thing
proto
with
what
else
we're
going
and
testing.
C
B
Cool
I
will
I
messaged
him
outside
Channel.
Maybe
we
can
reconnect.
I
will
update
us,
but
there's
been
much
effort
going
on
the
fuzzing,
primarily
the
fuzzing
of
his
go
specification
and
getting
some
machinery
in
place
to
fuzz
the
Python
spec
implementation
as
well,
and
do
different
suppose
any
things
like
that.
But
proto
will
update
us
if
he
can
reconnect.
B
D
One
thing
which
might
be
is
that
Guido
tried
replacing
1956
with
xx
hash,
so
exits
hash
is
a
non
cryptographic
hash
function,
so
we
couldn't
confuse
it
in
production,
but
it's
much
faster
than
sha-256
and
what
he
found
with
zero
at
ease
that
it
runs
the
fuzzing
about
three
times
faster.
So
it
might
be
worth
having
some
sort
of
a
flag
in
the
client
implementations
to
switch
over
to
xx
hash
so
that
we
can
just
do
three
times
more
fuzzing.
E
Yeah,
hey
guys
so
last
time
we've
talked
I
mentioned
that
we
aligned
on
blog
process
in
epub
process
into
zero
point
search.
So
yesterday
we
just
align
that
with
zero
point,
seven
as
well.
We
also
reemployment
caching
the
way
we
catch
stuff
with
zero
point.
Seven.
Just
last
time
we
had
caching,
everything
was
zero
point
two,
so
we
had
to
read
it
a
lot
of
a
caching
layer,
since
the
shuffling
and
the
way
we
get
meat
is
are
different.
F
F
We
don't
want
to
redo
any
of
the
works
and
for
next
I
think
for
Shatford
workers
right
now
it
will
get
a
more
proper
networking
implementation.
I
know
what
we
have
is
really
simple
floats
up,
which
works,
but
what
we
want
to
do,
probably
in
the
really
short
term,
is
to
reintroduce
the
chef
stress,
subjects,
network
library
and
you've
said
we
get
a
pom
for
networking
communication
layer
for
our
cancel
lunch.
Some
new
test
nurse,
so
this
for
us
great
thanks.
G
C
C
We
have
also
broken
out
our
validator
client
implementation
kind
of
fall
in
line
with
the
lead
of
the
other
clients.
You
know
how
they
made
them
discrete
from
the
beacon
Ginny.
So
that's
good
and
oh
yeah.
Also
Joe
Wright
wrote
a
pretty
cool
article
about
positive
tree
implementation
and
I
should
check
out
I,
think
it's
floating
around
somewhere
on
Twitter,
so
a
bunch
of
y'all
might
have
already
seen
it
and
I
think
I
think
that's
it
much.
B
C
The
other
thing
we're
also
with
harmony
and
and
Raoul
from
protocol
ABS
on
a
minimal
JVM
implementation
of
Lib,
p2p
and
and
then
the
other
thing
is
that
we
released
a
bunch
of
bounties
Joe
loop
and
funded
a
bunch
of
bounties,
because
everyone's
like
wicked
busy.
You
know
for
a
minimal
kind
of
super
simple
network
implementation,
so
that
we
can
test
the
kind
of
consensus
layer
and
the
kind
of
multi
client
a
kind
of
test
net,
and
you
know,
and
that
hopefully
will
free
teams
up.
C
H
B
J
J
J
We've
also
the
past
few
weeks
we
integrated
gossip
sub
and
implemented
the
RPC
protocol
as
it
exists
in
the
spec
right
now.
So
now
have
a
networking
layer
and
we're
also
toying
around
with
pulling
out
pieces
of
our
code
and
rewriting
them
in
assembly
script,
which
is
a
language
that
looks
like
time
script,
but
it
compiles
to
azam
and
we're
starting
with
LM,
with
our
LM
d,
ghost
just
to
try
something
out
and
get
used
to
the
tooling
and
our
next
steps.
J
K
B
L
Yeah,
so
regarding
the
spec,
we
have
to
pay
our
spending
for
0.7
compatibility
and
we
still
have
to
do
more.
For
now
we
sing
the
low-hanging
fruits
we
have
the
backward
sync
integrated,
so
that
means
requesting
all
blocks
up
to
a
point
is
available.
On
the
networking
side
we
have
Libby
2p
integration
in
numbers
and
we
are
currently
working
on
releasing
li
p
2p
based
test
net
instead
of
our
px
that
we
were
using
so
far
and
on
so
this
is
using
the
demon
on
the
leap,
p2p
library,
in
pure
name.
L
M
There's
some
good
ideas
from
prism
that
I
recycle
to
this.
Some
finback
from
the
different
commenters
so
feel
free
to
take
a
look
and
and
get
inspired,
but
there
is
no
conformance
to
this
that
is
required
at
this
point.
So
just
if
you
know
about
that
reports-
and
there
I
am,
if
Dada
matrix
commander.
E
L
C
C
L
C
C
B
C
N
B
O
Just
to
chime
in
real
quick
here
about
the
the
document
that
Terrance
linked
this
week,
I'm
putting
together
a
more
like
for
more
like
the
API
design.
So
this
would
have
you
know
like
batch
request
requesting
things
by
slot
like
it's
still
a
pull
method.
But
this
supports
data
providers
like
Amber
data
or
ether
scan,
or
anybody
who
wants
to
build
some
sort
of
read
access,
consume
data
remotely
you
know
without
having
access
to
the
file
system.
So
it
supports
that
use
case.
C
K
So
there's
two
different
things
here
to
what
many
was
talking
about
is
metrics,
like
the
kind
of
developer,
useful
metrics
for
tracking
how
your
how
your
system
is
performing
and
I
think
that's.
What
Antoine
has
been
working
on
too
is
for
me,
easy
stuff
and
then
I
think
what
Preston
is
talking
about
is
more
of
like
a
it's
more
of
like
an
API
for
the
users
of
the
application.
We've
been
thinking
of
them
as
completely
different
things,
so
the
like
metrics
and
logging,
like
Manny,
was
talking
about
the
push
or
pull
I.
K
I
B
I
I
That
they
bring
so
it's
easy
to
like
think
that
we
should
have
like
you
know,
Bhushan
poll
and
metrics
and
logs
and,
and
you
know,
a
bunch
of
historical
services
and
everybody
should
support
everything.
But
realistically,
looking
at
it
like
the
core
functionality
of
the
client
remains
to
vote
on
blocks.
The
rest
is
kind
of
nice
to
have
fluff.
P
B
I
B
Q
K
Hey,
so
we're
up
to
date
with
spec
zero
point
six
point:
three:
we're
passing
all
the
tests
that
we
haven't
raised:
issues
about
we've
added
some
Prometheus
stuff,
so
we're
running
a
test
nets
and
looking
at
crafts
about
what's
doing
it's
ridiculously
easy
with
the
Prometheus
and
graph
on
it
to
get
to
get
like
a
dashboard
going
so
well
them
to
prison
for
highlighting
that
one
good
lots
of
progress
on
dis,
v5
I,
think
Aaron's
testing.
It
now
not
sure.
K
If
he's
complained,
we've
been
fuzzing
with
our
own
fastening
tools
and
we
found
bugs
and
upstreams,
which
is
really
good.
Kirk
has
been
working
on
metallics
optimized
VLS
signature
scheme
he's
going
well
with
that
I
believe
we
got
the
rest.
Epi
will
will
for
the
validators
motion
to
master
and
wear
stress,
testing
test
nets
with
one
second
block
x
and
in
trying
to
see
see
if
we
can
break
it,
so
we're
finding
bugs
and
we're
fixing
them.
So
it's
good
how.
P
K
One,
the
one
that
we
are
using
now
is
specific
to
lighthouse,
and
it's
kind
of
it's
a
it's
like
kind
of
part
of
our
package
manager
system,
cargo.
We
would
consider
making
it.
Let
me
rephrase
that
the
reason
we
haven't
made
a
generic
is
because
there's
already
efforts
on
a
generic
buzzer,
so
we
figured
that
one
will
be
useful
and
this
one
we're
trying
to
keep
keep
it.
So
it's
I,
don't
know
it.
K
R
A
Gus
has
been
relatively
quiet,
but
I
think
two
are
figuring
out
what
to
do
if
mr.
spanks,
but
about
saying
things
with
the
current
generalized
forcing
efforts
is
it's
primarily
like
spec
focus
or
consensus
focused
its
first
thing,
the
state
machine.
It
doesn't
first
say
your
performance
bottlenecks
like
storage
or
networking,
so
it's
like
mitosis
doing
buildeth
out
in
for
your
specific
implementation.
For
that
part
of
the
of
your
spec,
then
we
can
share
that
consensus.
Forcing.
J
So
the
mean
update
I
have
from
my
side,
is
probably
the
SS
head
portion
stuff
that
I
did
over
the
last
couple
of
weeks.
So
basically
the
I
was
finally
managed
to
get
the
SSD
partials
implemented
in
Python,
and
the
mean
realization
I
got
out
of
that
is
that
it's
just
way
more
complex
at
present
than
it
needs
to
be,
and
the
bulk
of
the
complexity
comes
from
the
fact
that
Merkel
proof
likes
in
dynamically
sized
objects
like
lists
or
dynamically
sides
instead
of
the
like.
And
if
you
remove
that
property.
B
J
Right
I
was
just
walking
up
stairs
I'm
up
the
stairs
now
oh
cool.
Well,
we
can
hear
you
again,
you
said
requiring
lists.
You
have
a
maximum
length
so
basically,
like
you,
basically
think
of
it
as
being
identical
at
the
health
types
in
the
piper
work.
We're
in
Viper
like
you
could
have
a
fixed
length
list
that
has
n
values
or
you
could
have
a
dynamic
length
list.
J
But
if
you
haven't,
did
it
look
like
the
list
yesterday
specify
what
the
maximum
length
is
and
then
the
idea
would
be
that
as
I
said,
serialization
would
not
change
at
all,
except
maybe
at
some
point
later
in
the
future.
We
might
want
to
add
another
sssaid
serialization
type
for
sparse
lists,
but
that's
like
not
something
we
have
to
discuss
today
and
but
for
SS
Zed
hashing.
The
length
of
a
Merkel
branch
would
be
AF
x
value.
So
if,
for
example,
your
list
had
a
maximum
length
of
20,
then
20
gets
around
it
up.
J
32
I,
guess
that's
the
next
power
of
two,
so
the
length
of
a
Merkel
branch
would
always
be
five,
so
there
were
just
always
be
a
thirty-two
item.
Tree
yeah,
regardless
of
what
the
quote
actual
length
of
the
list
is,
and
so
that
way
the
kind
of
morkul
path
needed
to
get
to
the
say.
Third
item
in
the
list
will
just
always
be
a
gloss,
left
right,
right
left
and
it
doesn't
change
depending
on
what
what
there
and,
if
currents,
add
dynamic
size
of
the
less
toast.
B
J
The
only
thing
this
requires
is
that
we'd
have
to
run
through
the
block
and
state
data
structure.
Is
that
for
every
dynamical
assess
take
a
maximum
on
it
for
the
block
data
structure
in
phase
zero?
There's
no
problem
because
we
already
have
a
natural
maximum,
which
is
the
constant
for
the
maximum
number
of
each
objects
type
in
a
block.
The
main,
the
one
thing
in
the
state
that's
currently
dynamic,
as
the
validator
set
and
for
the
validator
said.
J
J
And
so
the
thing
I've
been
thinking
about
myself
as
just
how
to
how
abstract
it
fee
markets
would
work
and
how
like,
basically,
how
the
lot
producers
could
collect
years
in
the
context
of
these
different
execution
of
our
it's
existing.
So
the
main
design
goal
here,
it
has
just
simplified
the
experience
for
a
block
reporter
and
make
it
so.
J
The
block
proposers
can
get
a
fair
amount
of
revenue
without
having
to
personally
understand
55
different
sub
protocols,
and
so
I
came
up
with
this
idea
where
there
would
be
a
standard
for
how
execution
environments
pay
fees
and
they
would
have
issue
receipts
in
a
standardized
format.
And
then,
basically,
the
execution
environment
will
collect
fees
from
transaction
senders.
The
execution
environment
would
issue
a
receipt.
The
execution
environment
would
have
an
account
at
a
standard
execution
environment.
J
J
Another
thing
I
realized.
We
need
to
start
taking
seriously
as
a
kind
of
sub
lot
of
l2
moving
forward
is
light
clients
and
what
up
and
light
client
server
markets
like?
Basically
because
everyone
will
be
a
light
client
in
almost
every
ish
shard,
like
there's
going
to
be
heavy
reliance
on
these
nodes
that
have
data
associated
with
particular
shards
and
that
could
provide
merkel
branches
in
exchange
for
payments
through
a
payment
channel.
J
And
if
you
have
that
architecture,
then
the
light
client
servers
could
also
just
be
the
real
layers
and
these
a
transaction
packaging
really
or
markets.
But
like
the
category
of
node
that
specializes
in
maintaining
stage
for
a
particular
shard.
If
something
that
I
know
needs
to
exist,
something
we
could
Pro,
we
probably
want
to
start
thinking
about
more
and
I
know,
like
some
of
the
developers
like
jolt,
spend
some
time
thinking
about
this
in
the
context
of
each
one.
So
it
might
make
sense
to
interact
more
with
them
to.
J
S
D
D
I
guess
one
thing
which
might
be
worth
sharing
as
well
is
that
this
seems
to
be
rough
consensus
that
we
wouldn't
want
to
launch
phase
2
we've
just
within
a
without
any
execution
engine,
just
just
the
basic
logic,
the
very
thin
layer.
Instead,
we
would
want
to
go
with
a
kind
of
more
controlled
launch
where
we
have
either
f1
and
as
as
an
execution
engine
or
and
the
new
execution
engine
which
has
all
the
goodies
that
we've
been
looking
into
in
researching
for
for
the
last
few
years.
B
Yeah
100%
agreed
on
that,
like
releasing
it
without
anything,
I
think
would
be
silly
for
the
community
spec
perspective,
I'm,
even
interested
in
potentially
launching
with
a
restricted,
like
you
know,
there's
only
one
or
two
execution
engines
at
the
beginning,
so
that
they
can
be.
We
can
work
out
the
kinks
rather
than
having
a
field
day
right.
D
D
So
basically
one
of
the
things
that's
been
merged
and
recently
is
the
removal
of
the
if
to
Genesis
log
from
the
deposit
contract
and
we've
replaced
it
in
a
favor
of
a
custom
function
which
is
kind
of
subjectively
run
client-side
as
it
were,
which
is
both
more
secure
because
it
allows
us
to
better
capture
what
we
want
to
have
as
a
trigger
for
the
for
the
if
to
Genesis
and
also
more
flexible,
so
there's
basically
a
few
requirements
for
Genesis.
We
want
to
make
sure
that
there's
sufficient
if
at
stake.
D
So
if
we
were
to
bake
in
a
you
know
a
a
trigger
in
the
deposit
contract
and
for
some
reason,
we're
not
ready
to
launch,
then
this
gives
us
a
flexibility
to
date,
the
Genesis
trigger
I,
guess
from
a
timing,
perspective,
I'd,
say
we're
still
on
track
for
the
the
phase
zero
spec
freeze
on
on
June
30th.
So
that
might
be.
You
know
a
good
opportunity
idea
at
the
end
of
this
month
to
think
about
new,
realistic
targets
and
I.
D
D
December
holidays,
which
are
generally
quieter
and
it's
it
would
be
the
the
11th
anniversary
of
the
of
the
Bitcoin
Genesis,
and
that
would
give
us
if,
assuming
that
we
do
the
deposit
contract
ceremony
at
Def
Con,
that
would
allow
for
three
months
for
deposits
to
accumulate
to
reach
two
million.
If
and
it
will
allow
for
seven
months
from
today
for
at
least
two
clients
to
reach
production
status,
you
mention.
D
Well,
I
guess
at
the
very
least,
that
we
have
a
a
long
running
cross
client
s
net,
which
has
gone
through
security
or
debt.
That's
gone
through
fuzzing
parts
of
which
have
gone
through
the
form
of
a
vacation
and,
potentially,
you
know,
has
hasn't
suffered
major
major
issues
for
a
healthy
amount
of
time.
I
B
Agree
and
the
I
think
that
launching
the
deposit
contract,
we
should
at
least
have
some
some
target
for
going
to
production,
because
otherwise,
you
know
we're
asking
people
to
put
their
money
into
a
contract,
at
least
if,
if
they
do
it
early
for
sentence,
an
indefinite
amount
of
time,
which,
if
we
do
ask
them
to
put
their
money
in
for
an
end
up
in
amount
of
time,
people
might
not
actually
show
up
and
might
not
have
a
good
read
on
the
participation
levels
that
we
expect.
I.
T
T
B
B
T
B
Yeah
simply
I
could
be
like.
Have
there
been
a
hundred
deposits,
great
I'm
gonna
start,
but
we
can
make
the
logic
more
sophisticated.
We
can
make
it
have
there
been
a
hundred
deposits,
have
there
been
90
full
deposits
and
is
it
the
state
yet
so
we
can
just.
We
can
more
manage
it
locally
and
we
can
be
a
little
more
dynamic
with
it.
If
you
know
if
we
need
to
postpone
things
or
whatever,
so
we
don't
we're
not
beholding
to
whatever
ends
up
being
in
that
contract,
I
think
it.
B
K
B
And
we
can
have
more
sophisticated
logic
right
now,
like
the
calculation
of
full
deposit
is,
doesn't
take
into
account
if
people
send
in
partial
deposits
so
like
if
I
sent
in
16
and
then
16,
it
doesn't
count
as
a
full
deposit,
but
you
could
count
that
locally.
So
you
could
do
a
little
bit
more
sophisticated
things
as
well,
but
Justin
yeah.
D
D
T
B
B
Right
so
when
you're
voting,
you
can
still
call
that
mechanism.
You
also,
but
most
people
will
be
handling
a
tree
locally.
So
it's
a
helper.
It
ends
up
being
a
helper
accessor.
It
gives
you
a
little
bit
more.
Flexibility
like
in
case
say
you
started
running
this
a
year
from
now
as
a
validator.
You
might
use
that
mechanism
and
actually
have
just
a
more
sparse
view
of
the
deposits
locally
instead
of
having
the
entire
tree.
So
it
does.
It
does
provide
some
optionality
but
you're
right.
It's
not
a
hundred
percent
necessary
anyway.
T
T
G
U
We
got
a
quick
update.
There
are
some
good
conversations
about
what
a
token
is
going
to
look
like
on
execution,
environment,
Smith,
2
at
scaling,
aetherium
and
still
thinking
about
different
ideas
there,
but
I
wanted
to
share
an
idea.
I
didn't
get
some
feedback
on
it.
It's
about
removing
the
need
for
like
two
transaction
flows
for
ERC
20s,
so
like
the
basic
idea
is
like
extending
message
value
to
support
arbitrary
tokens
and
so
I've
kind
of
like
a
ridden
up
like
a
short
summary
here.
Annie's
magicians
clothes
that
I'm
going
to
share.
B
U
I
can
tell
it
more
about
it
now,
basically
like
the
idea
like
I
had.
Is
that
essentially
like
sending
a
transaction
to
any
kind
of
contract,
since
it's
already
like
signed
by
you
or
by
your
contract,
wallets
like
you're,
essentially
giving
permission
to
like
Cinetopia?
It's
just
that
right
now,
there's
there's
not
an
ability
of
saying
that
you
want
to
also
send
like
some
VR
seats,
one
here,
some
like
token
other
than
ether
in
one
transaction.
U
It
has
to
be
split
in
two
like
notifying
the
token
contract,
and
so
if
we
can
extend
it
to
where
message
dog
value
is
some
token
contract
address
in
some
amount
of
tokens,
then
we
can
add,
like
some
GI
function
or
opcode.
Essentially
that,
like
doesn't
delegate,
call
to
the
token
contract,
assuming
it
supports,
like
some
generic
interface
that
supports
transfers,
and
so
the
message
I
send
her
after
through
that
delegate,
ball
will
still
be.
B
U
Yeah
so
I
mean
like
the
message
of
value.
That's
gonna
be
kind
of
like
an
ee
concept,
since
it's
not
going
to
be
like
it's
not
going
to
live,
I
think
at
the
protocol
layer,
and
so
if
we
can
just
extend
that
in
that
context
to
be
an
address
and
a
value,
then,
as
long
as
that,
the
transaction
is
introvert
and
the
contract
was
able
to
continue
executing
after
it
like
kind
of
consumes
that
value,
then
the
carga
contract
can
assume
that
it
was
like
it
had
the
valid
transfer
in
it.
B
B
B
Moving
on
the
networking,
Felix
did
say:
sorry
you
could
not
join.
He
has
some
discovery.
B5
updates.
The
government
ation
is
progressing
still
missing.
Integration
for
the
topic
stuff,
but
the
basic
DHT
works,
implement
a
implementation
and
Trinity
and
lighthouse
is
ongoing.
Rust
version
is
pretty
far
along
minor
spec
changes
TBD
and
he
is
currently
negotiating
an
external
protocol.
Audit.
V
Yeah,
it's
Mike
from
would
be
to
be
Raul,
couldn't
make
it
today,
he's
traveling,
so
I,
don't
think
he's
on
I,
don't
think
he's
on
the
call
but
yeah.
Actually
we
have
a
few
quick
updates.
The
last
call
we
did
it
like
three
weeks
ago.
You
know
a
bunch
of
people
on
the
call.
Kinda
gave
us
feedback
about.
V
Let
me
like
some,
you
know:
production
readiness
of
the
implementations
that
the
daemon
wasn't
a
good
enough
test
environments,
and
so
some
really
useful
feedback
and
we've
tried
to
take
action
on
a
lot
of
those
things
that
came
up
so
here's
sort
of
what's
going
on
as
far
as
the
JVM,
the
p2p
I
think,
Johnny
covered
it
like
there's,
there's
nothing
else.
I
really
have
to
add
beyond
what
he
said
at
the
beginning
of
the
call.
V
Well,
actually,
I
had
one
thing:
web
3
lab,
which
is
also
I,
don't
know
if
Connor
anyone
is
on
this
caller
attends,
but
they're
looking
to
get
involved
too.
So
we
may
get
more
firepower
on
on
the
implementation,
but
even
without
that
it
seems
to
be
progressing
pretty
well
on
the
production
readiness
for
live
p2p.
We
followed
up
with
with
the
chain
safe,
specifically
folks,
who
had
worked
odd
on
the
on
jail.
V
It
worked
with
the
Jas,
live
p2p
and
knew
kind
of
what
its
flaws
and
warts
work
and
we're
looking
at
making
a
grant
to
kind
of
fix
up
some
of
those
things.
A
lot
of
them
are
just
documentation
issues
so,
working
on
that,
we
now
have
a
full-time
writer
on
us
working
on
specifications
for
Lupita,
P,
so
I
know
that's
been
a
week,
a
weak
spot
and
then
everyone
who
tries
to
implement
it
is
like
what
you
know.
How
can
I
implement
this
with
that
proper
specification,
and
so
we
have
a.
V
What
else
is
it
gonna
toss
out
there?
Oh,
there
was
a
some
benchmarking
at
the
scaling.
Etherium
event
in
Toronto
were
we're
working
with
white
block
to
try
to
figure
out
basically
to
try
to
iterate
on
those
tests
it.
It's
really
good.
A
good
kind
of
initial
work
had
done,
but
we
think
that
some
of
the
test
results
are
might
be
measuring.
Artifacts
of
the
set
up
more
than
the
gossips
of.
V
B
V
Yeah,
it
is
their
intention
to
move
on
from
SEC
I
owe
to
TLS
it.
The
status
of
TLS,
berries
with
implementations,
I
mean
whether
it's
complete
or
not
various
its
implementation.
So,
like
we
have
a
working
TLS
1.3
in
the
Jo
Lukie
to
be
implementation.
I
do
not
believe
we
have
one
in
Jas,
I
mean
I
could
go
through
all
the
languages,
but
but
the
point
is
not
all
of
them.
Have
it,
and
so
we're
gonna
be
falling
back
on
psych,
I
hope
for
quite
a
while,
like
when
two
clients
connect.
I
Well,
there's
two
two
aspects
to
that
question
right,
one
is
like:
is
it
finalized?
How
Lippe
to
be
over
TLS
should
look
like
from
from,
let's
say
from
spec
perspective
or
from
a
functionality
perspective,
and
then,
obviously
you
know
clients
the
question
there
would
be
do
they
have
something
to
implement
and
the
final
question
is
like:
are
there
any
concerns
that
would
prevent
TLS
from
becoming
the
defect
so
transport
for
Libby
to
be
ones,
implementations
of
Cara,
okay,.
V
Yeah
I
understand
so
I'm,
not
a
TLS
expert
but
as
I'm
gonna
kind
of
go
in
reverse
order.
On
your
last
question,
I
am
NOT
a
tellus
expert,
but
our
our
expert
margin
from
talking
to
him.
As
far
as
I
know,
there
there's
no
reason
why
we
would
not
eventually
go
100%
TLS.
Once
implementations
are
caught
up,
we
don't
know
of
any
theoretical
reason
not
to
do
that.
Then
then
kind
of
winding
back
through
through
your
earlier
questions,
I
started
remind
me
this,
the
second
one,
the
middle
one.
V
I
V
I
think
we're
happy
with
the
go
implementation
and
we
want
to
turn
that
into
a
spec.
That's
my
I
can
follow
up
with
Martin
seaman
who's,
the
RTOS
expert
and
he
implemented
that
I
can
double
check
on
that.
But
as
far
as
I
know
like
he
thinks,
where
we've
reached
a
point
where
we're
satisfied,
there
are
a
few
there's
a
few
issues.
The
rust
rust
LS,
which
is
like
rusts
main
TLS
library,
doesn't
support
self-signed
certificates,
which
we
would
like
to
use
in
some
cases.
V
P
P
V
V
G
V
That's
a
good
question:
basically
we
so
we
want
to
support
something
that
is
an
industry
standard
and
that
TLS
is
the
standard.
Sec
IO
is
like
something
that
we
wrote
on
our
own.
We
do
that
we
are
gonna,
have
a
security
audit
of
it
done,
and
the
people
who
wrote
it
are
quite
knowledgeable
about
cryptography.
But
we
think
that
for
a
lot
of
use
cases,
it
may
be
safer
to
support
TLS
1.3.
We
couldn't
use
TLS
in
the
past
because
prior
to
version
1.3
TLS
didn't
have.
V
Basically
it
required
you
to
have
a
notion
of
a
server
and
a
client,
like
you
had
to
designate
one
side
as
the
server
and
another
as
a
client
that
doesn't
make
sense
in
period
of
here.
1.3
finally
gives
us
a
way
to
to
not
make
that
distinction
so,
but
anyway,
because
1.3
is
something
that's
recent.
Like
this
year,
we
didn't
when
we
were
first
developing
Limpy
2p.
We
couldn't
use
the
older
versions
of
T
lesson,
so
that's
where
sec
io
came
from,
but
is
that.
V
V
I
R
B
I
I
G
I
B
G
We
wrapped
up
the
additional
our
initial
p2p
gossip
subtests.
We
just
had
a
call
with
Mike
and
Raul
and
vaso
I
think
it
was
like
a
couple
days
ago,
so
we're
just
currently
in
the
process
of
like
designing
an
actual
test
phase
like
the
next
test
phases
with
them
I'm
drafting
something
this
week
and
I'll
post
it
up
on
github
and
I
would
like
any
feedback
from
the
community
in
designing
these
tests
and
ensuring
that
the
topology
is
correct.
G
Based
on
you
know
the
consensus
of
the
community
and
yeah
that's
pretty
much
where
we're
at
we're
rewriting
the
client
to
remove
the
daemon,
our
test,
client
and
we
started.
We
started
working
on
a
discovery,
v5
implementation
and
C++,
so
we
can
perform
similar
tests
and
analysis
on
discovery.
V5
we're
doing
that
concurrently.
B
G
Another
thing
that
we
kind
of
may
need
to
discuss
at
some
point,
and
this
is
going
to
kind
of
help
us
move
toward
multi-client
is
like
the
way
that
key
stores
are
implemented
and
like
how
those
key
pairs
are
generated
like
they're,
using
like
pls
like
if
we
can
standardize
how
the
keys
are
stored.
It
doesn't
really
matter
like
how
we
do
it
right
now.
In
my
opinion,
it
just
matters
for
the
sake
of
interoperability
and
using
easy
testing
that
all
the
clients
implement
the
same
kind
of
function.
G
So
we
don't
have
to
write
individual
logic
for
each
specific
client
like
in
prism
that
they
use
the
keystore
from
gas,
but
we
can
really
kind
of
just
use
like
a
flat
Jason
file.
We
don't
really
need
anything
fancy
it's
just
if
we
can
kind
of
standardize
across
clients
how
that
process
occurs,
then
it'll
be
much
easier
for
like
testing
in
future,
like
Interop
efforts.
I
G
It
doesn't
I,
don't,
in
my
opinion,
I,
don't
think
that
it's
like
super
important,
how
we
do
it
it's
just
what's
more
important
at
this
stage
is
just
that
we
can
kind
of
agree
and
standardize
some
sort
of
implementation.
However
basic
it
doesn't
need
to
be
necessarily
for
production
purposes,
but
at
least
for
like
these
initial
R&D
and
like
testing
phases.
N
M
Yeah,
so
we
saw
that
perceived
to
tester
that
maybe
this
much
that
you
can
definitely
have
one
client
generate
all
the
validator
contract
and
all
the
accounts
and
all
that
stuff
into
files.
That
can
be
read
again,
but
it
needs
to
be
compliant
between
the
different
clients
if
you
want
to
move
a
little
faster
and
interrupt
otherwise,
every
client,
its
own
snowflakes
and
we're
gonna
have
to
just
report
also
different
stations
of
Kyel,
the
different
ways
the
key
stores
could
be
created.
G
G
B
Well
agreed:
let's
move
on
from
networking
to
we
have
about
10
minutes
left
spec
discussion.
I
did
want
to
survey
how
people
are
thinking
about
and
searching
for
attestation.
Slashings,
Jim
and
I
were
talking
about
that
and
I
know
that
some
of
you
have
dug
into
it.
So
if
someone
wants
to
just
kind
of
give
us
Leyland
as
they
see
it,
that
might
help.
I
P
I
K
Yeah,
we
are
what
still
came
to
do
some
slashing,
even
though
it's
like
a
bit
of
a
funny
thing
where
you
don't
necessarily
need
it
in
order
to
work.
I
know
Michael
put
some
effort
into
it
when
we
were
doing
operations
pull
so
you
know
trying
to
fill
up
blocks
with
attestations,
and
then
you
know
meeting
these
edge
cases
of
like
oh.
If
we
find
slashing
attestations,
do
we
include
one
of
them
to
include
both
of
them.
B
K
Yeah,
so
that
that's
kind
of
like
a
little
little
tangental
it's
it's
kind
of
like
we
discovered
that
as
a
result
of
dealing
with
the
operations
pull,
we
haven't
put
a
whole
lot
of
effort
into
detecting
slashings
I'm,
not
sure
we
have
a
full
strategy
for
it.
We
definitely
don't
actually
I
part
of
me
is
thinking
about
moving
into
a
separate
process,
but
I'm
also
not
sure
whether
that
really
should
just
just
so
that
it's
not
going
to
chew
up
capacity.
K
B
I,
definitely
you
and
it
should
definitely
be
some
sort
of
like
at
least
asynchronous
or
back
my
background
job,
whether
it's
a
song
processor
or
not.
Just
because
it
could
you,
you
could
probably
spend
all
of
your
time
searching
for
them,
so
you
should
probably
relegate
some
portion
of
time
rather
than
all
of
it,
I.
B
We
don't
necessarily
have
the
state
to
go
and
you
can
verify
the
such
a
station
so
then,
and
that
under
that
consideration,
even
if
it
was
flashable,
we
might
just
like
discard
the
abbe
station
and
under
that
consideration,
it's
probably
fine
in
general,
because
we
finalize
things,
but
it
does
limit
our
ability
to
find
Mewsette
for
these
things.
So
it's
not
a
fully
complete
thought
because
I
was
I,
haven't
fully
thought
the,
but
something
I
think
about
a
little
bit.
Yeah.
K
B
K
We
wanted
to
try
and
incentivize
clients
to
implement
slashing
one
way
to
do
it
might
be
when
we
released.
These
test
notes
is
to
make
a
bunch
of
open-source
tools
that
allow
it
allow
people
to
very
easily
create
malicious
blocks
and
like
I'm,
not
sure
whether
we
want
a
fully
open
source
or
give
them
to
specific
people,
but
like
add
the
ability
for
people
to
cause
chaos
and
then
once
basically,
if,
if
your
client
doesn't
support
it,
then
you
fall
off
line.
Maybe
maybe
that's
the
way
we
incentivize
people,
it's
not
really
protocol
level.
It's.
B
Something
and
something
we
do.
We
do
want
to
have
test
nets
in
which,
like
50
percent
validators,
go
offline
and
we
go
through
an
activity
leak
and
during
those
times
when
I
guess,
your
block
tree
becomes
relatively
large
with
respect
to
your
latest
violence
and
those
are
the
times
that
you'd
be
most
concerned
about
people,
you
know
going
back
to
epochs
and
signing
something
new
and
and
attempting
to
to
mess
with
things
so
like.
We
should
definitely
create
these
scenarios.
I
I'd
also
be
interested
a
little
bit
in
thinking
about
or
really
hearing,
thoughts
on,
slashing
protection
and
they've
been
talk
of
clients
stashing
away.
You
know
data
in
order
to
ensure
that
they
don't
accidentally
cause
a
slash,
shovel
condition
for
for
their
validator
and
what
would
be
others
like
how
much
extra
data
do
we
have
to
store
because
of
that
saying
that
we
voted
for
for
a
branch
that
later
became
unavailable.
B
K
Yeah,
that
was
my
understanding
tool
if
you
like,
if
you
as
long
as
you,
never
vote
in
the
future.
There's
always
this
case
where
you
can
choose
to
just
skip
a
couple
of
duties
and
then
you're
safe
again
by
that,
but
that,
but
if
you
do,
if
you
have,
if
your
clock
screws
up
and
you
vote
in
the
future,
you
got
to
wait
until
that
until
you
say.
B
B
N
B
T
T
We
settled
on
this
one
and
so
a
suit
like
as
soon
as
we
have
kind
of
like
the
check
cut
to
that
place,
I'll
definitely
send
out
RSVPs
it's
difficult
to
send
because
it's
kind
of
like
we
want
eat
like
typically
like
in
the
terms
of
like
only
did
the
workshop
before
you
just
kind
of
advertise
it.
This
is
going
to
be
have
to
be
different.