►
From YouTube: Eth2.0 Call #34 [2020/2/27]
Description
A
A
A
A
A
B
Hello,
so
we
have
during
ethan
for
my
continued
work
on
the
networking
ripple.
With
this
thing,
I
hope
to
test
clients
networking
functionalities,
so
it
has
discovered
v5
and
rpc
as
well.
Now
working
like
this
version,
this
is
the
ken's
lighthouse,
so
I'm
still
working
on
testing
if
the
compression
of
rpc
works
well,
it
kind
of
relates
to
the
open
vr.
A
C
Yeah
midi's
not
around,
but
I
can
give
an
update
on
on
the
beacon,
fizz
yeah
cool,
we're
interested
okay
yeah,
so
we
recently
published
a
blog
post,
which
kind
of
gives
a
lot
of
the
progress
update,
which
is
on
a
website,
and
I
can
and
I'll
link
here
after
I
finish
just
giving
an
overview
of
it.
But
I
guess
the
main
points
are
that
we
we
found
an
interesting
bug
which
is
a
deposit
with
with
an
invalid
merkle
proofs
in
nimbus,
which
they
patch
pretty
quickly.
C
C
C
D
A
A
A
E
We
haven't
yet
caught
up
to
chain
head
we're
working
through
performance
and
reliability,
issues
that
are
slowing
us
down,
so
there's
more
work
to
do
but
exciting
that
we
are
downloading
blocks
from
the
live
test.
Net
we've
also
been
doing
some
work
related
to
deposit
processing.
We
should
now
be
correctly
processing,
pre
and
post
genesis
deposits.
E
As
far
as
bottlenecks,
one
issue
that
we
definitely
need
to
address
is
storage,
so
we're
kind
of
using
an
absurd
amount
of
disk
space
right
now
we
haven't
really
started
looking
at
optimizing
this
at
all.
So
if
people
have
ideas
that
would
be
interesting,
we
floated
some
ideas
around
about
maybe
using
a
tri-backed
state
storage
so
that
we're
sort
of
only
storing
diffs
between
states
or
maybe
like
a
state
snapshot
state
snapshot
strategy
where
we
only
store
like
a
few
states
and
basically
rebuild
them
as
needed.
E
F
However,
when
we
do
that,
like
there's
an
issue
of
like
being
able
to
like
miss
a
genesis
block
which
might
have
like
no
deposits
but
an
eth1
timestamp,
so
that's
kind
of
like
an
age
case
that
we've
been
working
on
for
like
the
past
week.
But
like
I'm
curious,
if
any
other
clients
have
like
thought
about
that
scenario
or
like
like
already
fixed
that
and
if
they.
If
anybody
has
fixed
it,
I'd
really
appreciate
it
like
knowing
how
they
did
it.
F
So
basically,
the
issue
is
like
just
like
getting
deposit
events
and
using
deposit
events,
because
otherwise,
like
it's
just
like
really
efficiently
you're,
hitting
like
the
east,
one
node
for
each
block.
After
your
like
contract
deployment,
plug
contract
deployment
block,
basically
and
being
able
to
like
start
like
like
trigger
genesis
on
a
block
that
doesn't
have
any
deposit
events
due
to
its
time.
F
G
F
B
B
You
don't
want
to
store
binary.
Now
it's
on
this
old
time.
What
you
can
do
is
store
the
finalized
state
in
a
flat
manner
and
whenever
you
load
it
into
the
state
converted
to
three
and
then
just
for
the
whole
part
of
the
state,
you
maintain
these
deaths
of
like
tree
and
store
them
as
gifts.
Instead,.
H
E
I
Yeah
so
internally
we're
calling
it
eth2signer
as
a
standalone
signing
as
a
service.
There
is,
if
you
look
at
the
pegasus
eng
github,
there
is
e2
signer
repo,
but
it's
just
started
just
now.
We
haven't
made
a
huge
amount
of
progress
just
yet,
but
it
would
be
good
to
get
some
common
interfaces
on
this
stuff.
If
anyone
else
is
interested.
H
I
H
J
K
I
L
L
L
We
have
created
a
specialized
infrastructure
to
test
finalization
issues,
because
I
talked
about
discovery
that
manifest
as
feminization
issues,
but
also
when
we
have
speed
issues
like
we
have
too
many
nodes
on
the
same
machine.
The
way
we
detect
that
is
by
finalization,
and
we
want
to
know
if
the
finalization
issues
come
from
spec
from
speeds
or
from
networking
on
if1.
A
L
So
for
choice,
both
one
straight
from
the
copy
past
it
from
the
spec
and
one
implementation
from
proto
array,
and
the
idea
is
to
make
it
almost
an
independent
module
so
that
it's
easier
to
fizz
and
in
terms
of
testing,
we
use
the
same
approach
as
lighthouse,
which
is
to
create
some
kind
of
interpreter
that
says:
okay,
push
a
block
at
that
slot.
Push
another
block
at
that
slope,
not
now
run
process
slots
and
then
now
run
the
fork.
A
C
I
I
L
I
I
L
H
Speaking
further
on
the
vls
front,
as
was
mentioned,
there's
that
there's
a
new
pr
on
the
hashtag
repo.
So,
although
we
were
supposed
to
have
finalized
vls,
there
have
been
some
complaints
as
to
the
efficiency
of
this
particular
low
power
devices.
Amongst
a
few
other
things,
so
there's
a
new
pr.
I
can
link
to
it
quickly
open.
It
only
affects
the
hash
to
base
which
is
now
called
hash
to
fields
which
is
the
first
part
of
the
the
hashing
into
the
curve.
H
H
M
H
The
the
quarterly
meetings
aren't
enough
when
it's
officially
standardized
it's
more
just
to
bring
bring
it
out
to
the
public
as
a
point
to
get
get
feedback
on
all
these
these
kinds
of
changes.
So
I
guess
maybe
this
is
the
results
of
the
last
meeting
in
some
weird
roundabout
way,
but
certainly
was
not
the
intention.
H
To
the
extent
that
I
know
it
is
100
stable,
so
there
is
one
minor
caveat
to
that.
Well,
two
caveats:
I
guess
one
is
that
there
are
still
no
test
vectors,
so
I
do
expect
it
to
change
to
add
test
vectors
I've
as
a
part
of
some
of
the
bls
pre-compile
work.
I've
been
doing
lately.
We've
generated
some
some
test
vectors
there,
so
maybe
we
can
we
can
leverage
those.
H
The
other
thing
which
may
change
is
if
officially
the
spec
or
the
draft
expired
or
bls,
because
there
hasn't
been
there
haven't
been
any
changes
to
it
for
over
a
year
now,
so
there
would
have
to
be.
I
think,
a
version
bump,
I'm
not
exactly
familiar
with
with
the
intricacies
of
versioning
under
under
these
standards,
but
there
will
be
a
version
vlog,
but
I
don't
expect
any
changes
on
that
front
at
least
and
then
that
one
I
can
work
from
whatever.
Then
I'm
on
the
horizon.
O
Oh
hey
guys
so
yeah
we
have
a
bunch
of
updates,
so
we
are
working
on
this
slashes
servers,
which
is
to
slash
double
votes,
double
test
and
surround
and
surrounding
a
test.
So
the
latest
progress
on
that
is
that
a
vision
node
was
able
to
detect
was
able
to
detect
a
several
vote
and
then
were
able
to
include
the
slashing
object
in
abroad.
O
So
the
next
thing
to
verify
is
that
the
slashing
actually
happened
and
then
the
validator
gets
ejected,
so
we're
working
on
that
I'm
also
working
on
a
various
day
management
service.
So,
where
that
we
store
hot
state,
aka
post
finalized
state
on
a
per
epo
boundary
interval,
and
then
we
basically
do
playback
on
that
and
then
a
code
state
which
is
before
the
finalized
sharepoint
state
on
on
a
per
user.
O
O
Subnet
subscription
we're
also
working
on
better
on
contrarian
blood
fashion
for
sinking,
and
then
we
also
like
thinking
in
the
back
of
our
head,
how
to
use
less
memory
during
initial
sinking,
and
then
we
also
updated
the
test
away
time
from
one
third
to
basically
right
away
when
he
sees
the
vlog
and
in
terms
of
bottleneck,
I
would
say
our
biggest
bottleneck
today
is
basically
we
subscribe
to
all
the
subnet
for
the
for
the
for
the
committee
id.
So
we
have
a
tons
of
undergraduates
on
aggregated
signature
to
verify.
O
A
A
C
A
O
We
basically
implement
what's
in
the
spread
today,
which
I
believe
it
does
check
this
signature
basically
checking
the
signature
is
the
it's
it's
the
heaviest
part.
So
the
debate
is
whether
you
should
check
the
signature,
whether
that
you
should
check
the
signature
before
you
republicate,
and
I
think
we
do
check
the
signature
today.
D
O
D
O
P
So
we've
got
a
thread
of
that
working.
We
still
only
have
blocks
no,
no
attestations
or
anything
yet
and
still
on
version
like
nine
one
of
the
spec
or
something,
but
we,
but
it's
good
to
have
to
be
able
to
use
that
mothra
library
and
not
have
to
as
far
as
a
quick
leg
up
to
get
that
started
so
yep
next
up,
I
think
we're
gonna,
I'm
gonna,
try
and
update
the
version
to
10.1,
because
I.
E
P
O
P
Okay,
that's
cool,
so
yeah,
I'm
going
to
probably
try
and
go
for
10.1
because
it
seems
have
some
improvements
over
for
the
rest
of
the
development,
but
we've
got
yeah
it'll
be
good
to
try
and
once
I've
got
that
in
there
trying
to
get
it
working
with
interrupt
with
one
of
the
other
clients.
I
know
there's
some
guys
from
tekku
locally
in
brisbane.
So
that's
probably
going
to
be
my
my
target,
but
I'm
happy
to
talk
to
some
other
people
and
try
and
get
some
interrupt
working.
C
C
So
the
things
we've
done
over
the
past
two
weeks
we
raised,
we
raised
a
4k
kind
of
test
net
validated
test
net
for
f
denver,
which
turned
out
to
be
quite
useful.
Some
developers
and
researchers
to
prototype
with
it's
been
running
for
about
93
000
slots
and
we
kind
of
haven't
touched
it's
just
running
smoothly.
We
kind
of
just
had
it
just
as
a
as
a
kind
of
a
test
for
the
denver
hackathon.
C
So
while
steadf
denver,
michael
from
our
team,
met
up
with
proto
and
implemented
the
merkle
tree
based
storage
system
for
validated
field
in
the
beacon
state,
it's
shown
some
pretty
significant
reductions
in
tree
hashing
time,
but
an
increased
increase
during
rewards
and
penalties.
So
we're
still
deciding
whether
to
adopt
the
approach
or
not
throughout
the
throughout
the
client.
C
We
did
a.
We
did
a
project
wide
sweep
of
temporary
heap
allocations
because
we
were
getting
we're
finding
a
whole
heap
of
using
a
ridiculous
amount
of
memory
more
than
what
we
needed.
So
we've
actually
reduced
our
memory
footprint
by
about
half
again
so
since
the
since
the
start
of
the
month
we're
down
to
about
quarter,
then
what
of
what
we
were
originally
using
we're
still
using
a
two
to
four
gigabyte
gigabytes
of
ram
for
a
beacon
node
on
a
100k
validator
test
net.
C
The
reduction
of
heap
allocations
and
memory
usages
also
gave
us
a
30
improvement
in
block
processing
in
time,
which
is
pretty
good.
So
that'll
also
help
our
syncing
speeds
and
we're
in
the
process
of
refactoring
our
bls
library,
so
that
at
compile
time
you
can
choose
to
weather
use
either
the
milagro
or
the
harumi
implementations,
we'll
still
kind
of
go
through
those
to
find
out,
which
is
to
actually
benchmark,
which
is
which
is
faster
in
terms
of
interoperability.
C
So
this
is
interoperability
is
very,
is,
is
kind
of
one
of
our
main
focuses
in
the
in
the
very
near
future.
The
bottlenecks
of
getting
there
is
that
we're
pretty
much
in
the
process
of
upgrading
lighthouse
to
what
we're
calling
kind
of
version
0.2.0,
and
this
is
going
to
have
pretty
much
be
feature
complete
for
for
mainnet
launch.
So
that
means
it'll
include
the
attestation
aggregation
strategy,
noise
and
and
snappy
compression.
C
So
we
pretty
much
have
most
of
that
implemented,
there's
still
a
bit
of
code
to
go,
but
we
probably
need
to
go
into
a
fair
amount
of
testing
before
we
merge
that
to
master.
But
once
we
have
that
merged
into
master,
we
will
be
ready
to
do
interrupt
with
everybody.
We
assume
so
as
soon
as
we
get
that
merged
down
we're
going
to
be
we'll.
C
Have
this
we're
going
to
start
up
like
an
interrupt
test
net,
which
will
be
a
long,
lasting
test
net
that
we
hope
other
clients
can
join,
but
we'll
also
try
and
join
other
clients
test
nets.
So
the
first
thing
is
just
kind
of
finishing
off
the
testing
of
that,
and
I
guess
the
last
thing
is
that
we've
kicked
off
a
process
to
build
a
kind
of
like
a
ui
front,
end
for
our
validator
client
and
that's
currently
in
like
the
research
phase.
A
O
C
So
I
guess
yeah
I
mean
we
have
actual
performance
bottlenecks,
so
this
is
the
ram
that
we've
kind
of
been
targeting.
We,
I
think
we
fixed
and
tracked
down
most
of
all
of
our
deadlocks
in
terms
of
actually
just
getting
to
an
interrupt,
interrupt
test,
net
and
testing
with
other
clients.
It's
it's
just
a
matter
of
finishing
off
the
last
bit
of
code
and
then
thoroughly
testing
it
internally
before
kind
of
releasing
and
testing,
because
we
don't
really
want
to
have
a
test
and
then
realize.
A
C
C
C
Yeah,
so,
as
I
was
saying
on
that
thread,
the
original
plan
was
just
to
so
what
pretty
much
we
when
a
validator
kind
of
subscribes.
We
know
in
advance
when
it
needs
to
subscribe
to
a
to
a
subnet.
So
we
we
we've
given
ourselves
kind
of
like
an
epoch
leeway,
so
we
know
an
epoch
in
advance
when
which
subnet
we
kind
of
need
to
subscribe
to.
C
So
the
initial
plan
is
to
use
this
v5
and
just
kind
of
search
for
random
peers
and
just
try
and
and
when
we'll
only
connect
to
ones
that
have
the
subnet
in
the
in
our
field,
but
failing
that,
if
that's
too
slow
or
if
that
doesn't
give
us
results,
it'll
be
dependent
on
the
number
of
nodes
on
the
network
that
are
validators
versus
the
number
of
nodes
just
sitting
there.
That
aren't
subscribed
to
any
of
the
any
of
the
subnets.
C
So
the
other
solution,
which
is
what
alex
suggested,
is
to
just
crawl
the
dhd,
which
isn't
too
difficult
but
it'll,
be
a
different
kind
of
search
where
we
kind
of
just
ask
all
the
all
the
peers,
all
the
other
peers
that
they
know
about.
That
have
this
particular
field
in
an
enr
and
if
you
specify
return
me
at
least
three
of
them,
then
the
query
hopefully
shouldn't
take
too
long,
definitely
not
at
least
an
epoch.
I
imagine
so
that
that's
the
second
strategy,
if
we
need
it
right.
C
Yeah,
so
if
ryog's
happen,
the
validated
client
will
detect
it
because
it
kind
of
polls
all
the
time
for
its
duties,
and
so
it
will
resend
a
subscription.
So
we
have
like
a
a
service.
That's
looking
after
all
these
subscriptions
on
the
beacon
node,
so
it
will
update
and
realize
that
it
it'll
change
which
which
subnets
it
needs
to
connect
to.
C
So
if
a
re-log
happens,
it'll
kind
of
readjust
itself,
we
may
have
less
time
than
an
epoch
in
some
circumstances
like
if
a
validator
just
connects
and
needs
to,
you
know,
perform
an
attestation
on
the
next
slot.
Well,
in
those
circumstances,
obviously
not
gonna
have
enough
time
to
track
down
peers,
but
in
a
long
running
scenario
we
we
in
principle
should.
A
C
A
M
A
C
C
What
do
you
mean?
Yeah,
I
mean
it'll,
be
statistical
based
on
the
number
of
peers
like
if
you
have
as
long
as
as
long
as
there's
at
least
a
thousand
validators,
then
it
shouldn't
be
too
difficult
to
find
those
thousand
value
days
across
any
subnet
that
you
need,
but
I
guess
we'll
find
that
in
practice,
correct.
F
C
Q
Hello,
so
past
few
weeks,
let's
see
so
we've
upgraded
our
bls
implementation
to
ten
point
x,
release
10.1.
I
guess-
and
we've
cut
a
new
release
of
that
so
based
on
harumi's
implementation
compiled
to
wasm
everything
else
in
our
repo
is
still
on
a
0.9
level.
We
we
have
some
fork
choice,
things
that
we're
still
upgrading
and
our
network
I'd
say
is
probably
our
bottleneck
at
this
point,
so
we're
adding.
Q
So
we
have
a
noise
implementation
that
we're
interopping
with
go
at
the
moment.
I
don't
know
exactly
what
the
status
is,
so
I
don't
want
to
offer
us
up
as
a
testing
partner,
but
that's
in
progress
and
we
have
a
pr
open
for
snappy
compression
and
we're
going
to
begin
working
again
on
disk
v5
we're
about
halfway
through
and
we
had
stopped
work
for
a
while
and
now
we're
gonna
get
back
to
that.
Q
Q
Q
Q
J
J
A
M
I
can
give
a
summary
for
the
football
team
sure
so
we'll
will
is
currently
on
the
plane
as
the
sun's
gone
yeah.
We
basically
spent
last
week
at
sbc
and
had
many
productive
discussions
there
and
synced
up
with
the
other
research
teams
we
struggled
before,
but
before
sbc
we
published
the
eath
research
post
on
on
our
vision
for
phase
two.
If
you
guys
want
to
have
a
look
on
that,
that's
basically
all
of
our
thoughts
around
phase
two.
M
In
our
opinion,
there
are
no
real,
like
blockers
left
for
phase
two,
it's
still
a
huge
design
space,
but
the
approach
that
we
plan
on
on
taking
is
to
just
like
basically
take
like
the
minimal
implementation,
minimal
phase,
two
spec
implementation
that
we
see
and
that's
basically
also
what
proto
has
been
started.
Writing
the
specs
on.
M
They
came
from
the
same
discussions
around
that
there
and
we
want
to
shift
our
focus
for
now
on
like
implementing
that
and
then
with
a
target
of
having
like
a
minimal
like
mvp
version
of
a
phase,
two
implementation
done
so
that
we
can
then
iterate
on
that
and
compare
it
with.
Like
other
more
involved
research.
That's
still
to
be
done
there,
but
but
yeah.
M
Our
next
few
months
will
be
like
mostly
focused
on
getting
this
minimal
face
to
implement
it
and
then
a
few
other
small
updates
sam
and
I
have
been
looking
into
this
whole
question-
around
dynamics
that
access
aesthetic
state
access.
Some
of
you
might
have
heard
of
that.
That's
this
dsasa
topic
account.
Internal
preference
is
the
to
likely
go
with
ssa
for
phase
two.
We
have
been
looking
a
little
bit
into
feasibility
there.
M
I've
I've
been
specifically
looking
at
existing
popular
et1
projects
to
see
like
how
easily
those
like
similar
use
cases
could
be
implemented
in
a
like
ssa
phase,
two
world-
that's
looking
great
so
far,
and
sam
has
been
working
on
for
the
last
few
weeks.
Last
two
weeks,
specifically
like
on
a
a
so-called
like
taint
analysis
tool
for
for
solidity
integration.
M
So
so
the
idea
here
is
to
to
have
have
a
tool
that
it's
basically
doing
like
an
optimization
pass
over
yule
and
it's
checking
contracts
for
dsa.
So
if
we
were
to
go
with
with
like
purely
ssa,
then
we
had.
We
would
have
need
like
developer
tooling,
around
right,
detecting
dsa
and
basically
so
that
would
just
like,
as
any
syntax
check
it
would
just
like
highlight
code
parts
of
your
code
that
would
that
use
dsa
patterns.
So
you
can
correct
that
or
overwrite
the
this
check.
M
H
From
what
we
discussed,
we
couldn't
see
any
major
design
patterns
that
are
that
we
prevent
by
switching
over
to
ssa,
and
certainly
it's
worth
it
for
the
because
the
simplifications
that
can
be
made
but
yeah.
I
just
would
like
to
advise
people
to
just
to
follow
up
to
follow,
what's
happening
here,
because
I
think
it's
an
interesting
design
space
and
it's
important
to
fully
understand
the
decisions.
We're.
A
A
A
D
M
G
A
G
Hello
shower
is
here
I'm
thinking
about
if
well,
we
can
have
something
on
the
march
march
6
and
there's
a
potential
port
on
the
is
to
discord.
China,
the
general
channel,
which
I'm
trying
to
check
the
people's
opinion
of
having
zanzi
on
the
sixth
and
if
you
are
interested
in
and
please
dm
dme
or
just
can
put
if
some
signal
on
the
is
to
discord-
and
I
know
that
the
golly
testnating
they
might
want
to
have
organizing
some
events.
So
the
discussion
is
also
on
discord.