►
From YouTube: Eth2.0 Call #33 [2020/2/6]
Description
A
A
A
A
Ongoing
audit
from
lease
authority
the
I
believe
the
intention
is
to
release
an
initial
report
kind
of
for
internal
review.
It
might
be
tomorrow,
it
might
be
monday.
From
my
understanding.
I
haven't
found
anything
crazy,
but
some
recommendations
on
networking,
spec
and
some
other
little
things
so
we'll
share
that
soon.
The
intention
from
there
is
to.
A
A
A
A
I
know
that
you're
using
much
more
sophisticated
algorithms
than
the
the
spec
provides
now,
and
I
I
wonder
if
there
is
any
value
to
these
unit
tests
and
whether
you
have
like
kind
of
the
interface
to
actually
be
able
to
test
them
so
specifically
like
testing
on
attestation.
Testing
on
block
testing.
That
kind
of
stuff
and
kind
of
the
internal
results
of
that
is.
B
C
Yeah,
so
the
proto-array,
the
version
of
photo
array,
doesn't
work
for
the
present
f2
as
we
have.
It
was
like
for
a
previous
previous
version.
Before
all
the
bounce
attack
stuff
I'd
be
interested,
I
would
definitely
be
interested
to
test
the
stuff
about
you
know
like
should
update
genesis.
She
should
update
the
justified
state.
C
I
think
that
stuff
is
like
sufficiently
complex,
especially
if
you
try
to
start
to
to
optimize
it
to
avoid
reading
states
from
the
disk
it'd
be
nice
to
test
that
right,
but
I
think
that
we'll
probably
find
that
most
clients
don't
actually
do
block
processing
inside
their
fork.
Choice
like
it
does
in
the
spec,
so
I
think,
like
on
one
hand,
it'd
be
really
nice
to
be
able
to
test.
All
that
should
should.
C
A
D
C
Guess
I
guess
the
tricky
part?
Sorry
sorry,
I
guess
the
tricky
part
would
be
to
like,
with
with
those
tests
that
involve
like
actually
having
like
a
full
chain
of
blocks
with
with
all
these
attestations,
instead
of
like
smaller
unit
tests.
Just
be,
I
guess,
get
tricky
to
actually
come
up
with
valid
scenarios
like
you
need
to
get
most
all
the
validators
to
you
know,
to
test
and
and
and
swap
things
and
stuff
like
that
yeah.
I
guess
that's
that's
the
only
problem
with
that.
One.
A
C
G
C
Yeah,
thank
you,
sir.
I
appreciate
it
they
so
I've
looked
at
my
ones.
Obviously,
and
I've
also
looked
at
mikhail's
ones.
Sorry,
if
I
didn't
I'm
just
on
the
michael
and
other
people
involved
and
the
ones
that
I
have
are
very
much
like
they're,
very
simple,
as
in
like
here's,
a
bunch
of
hashes,
here's
some
photos
on
the
hashes
and
then
now,
where
is
the
head?
C
So
they
skip
a
lot
of
that
like
they
don't
actually
have
like
full
blocks
and
they
don't
go
through
all
of
this
sort
of
stuff.
So
they're
they're
like
on
that
side,
where
they're
not
they
don't
they
wouldn't
work
at
all
with
the
current
like
spec
implementation,
but
they
are
actually
really
easy
to
just
generate
like
pathological
scenarios,
where
things
are
weird.
A
D
D
Anton
is
working
on
our
version
of
protos
backing
binary
miracle
tree
to
improve
our
hashing
performance
thanks
to
ben
our
10.1
bls
implementation
is
ready
to
go.
Adrian
is
working
on
general
stability
and
stability
of
the
code
base
and
having
furniture
and
work
on
following
each
one
chain.
Three
deposits
at
a
distance
behind.
So
that's
where
we're
at.
D
I
think
the
first
issue,
although
like
if
the
metadata
is
online
she'll,
probably
be
better
at
answering
it.
I
think
the
first
issue
was
that,
like
we
had
a
different
understanding
of
the
beacon
blocks
by
range
request
with
prism,
but
I
think
we
already
like
adapted
to
what
they
have
like
like
what
their
unders,
what
their
understanding
was,
and
I
think
that
was
just
like
getting
blocks
up
to
like
getting
blocks
up
to
like
the
specified
slot
versus
like
the
counting
skip
slots
or
not.
Was.
D
A
I
D
I
F
F
I
F
B
B
B
We
updated
our
ssd
parser
to
better
handle
the
malformatted
ssc
and
we
started
about
a
month
ago,
a
sink
refactoring
and
it's
currently
90
done.
On
the
testing
side.
We
are
running
out
10.1
spec,
bugs
we
also
fixed
the
fuzzing
bag.
That
was
highlighted
by
the
become
first
team,
and
we
are
also
re-enabling
tests
that
we
disabled
during
the
10-point
10.x
transitions
and
that
we
forgot
to
re-enable
and
otherwise
we
are
currently
hiring.
So
we
hired
a
new
nimbus
dev.
We
are
still
looking
for
junior
developers
and
the
tech
writer.
A
K
Some
more
work
on
the
beacon,
node,
developer,
client,
apis
progress
on
disk
b5,
more
progress
on
our
ethernet
integration,
a
big
one!
Is
we
finally
merged
our
port
of
pilot
b2p
to
trio
which
again
is
working
towards
concurrency
stability,
which
is
kind
of
a
python
detail
and
yeah,
just
general
spec
updates
to
version
10
1
and
that's
pretty
much.
It.
A
L
L
We've
all
found
some
like
strange.
We
found
some
loose
ends
in
the
typescript
types.
I
guess
we're
using
some
apis
that
not
many
people
use
so
we're
getting
some
pushing.
Some
of
that
upstream,
we
started
passing
the
0.9.4
spec
tests,
but
we
still
have
some
work
to
do
to
update
our
fork
choice,
but
there's
no
test
for
that.
So
not
not!
Yet.
I
guess
we've
done
some
research
into
updating
our
bls
implementation.
L
I
guess
so
we're
using
harumi's
library.
I
think
he
just
put
out
a
release
that
maybe
brings
him
in
line
with
the
new
spec.
So
we
can
take
a
look
at
that
in
the
next
few
days
and
we've
been
upgrading
our
lip
gtp
implementation
to
this
new
async
version
and
we're
taking
the
time
to
like
go
through
and
add
all
the
typescript
typings
that
aren't
there,
because
it's
written
in
javascript
and
we're
hoping
to
push
a
lot
of
that
upstream
as
well.
A
G
Oh,
hey
guys,
terence
here,
just
a
few
test
net
related
updates,
so
we
performed
the
first
volunteer
exit
for
the
test
net.
The
actual
object
was
successfully
going
through
the
innovation
block,
so
that's
pretty
cool
to
see
and
we
do
have
validators
slashing
protection.
It's
not
running
with
a
validator,
it's
just
a
db,
so
we're
working
towards
including
validator
slashing
object
in
the
block
as
well,
and
then
a
bunch
of
few
are
micro
optimizations,
so
we're
using
a
new
costume
state
structure.
G
So
since
golen
doesn't
have
immutability
over
a
fully
copy
of
the
object
so
for
state
copies,
we
share
references
with
the
parent
object
instead
of
copy
or
read.
So
that's
a
lot
less
easy
on
the
memory
side
of
things
and
then
a
little
bit
just
more
testing
on
the
array
for
choice.
It's
working
really
great!
G
C
C
We
are
in
the
final
stages
of
hiring
some
additional
developers,
thanks
to
everyone
that
applied
for
that
we
had
more
than
20
applicants,
which
was
great
to
see
lots
of
interest.
We
re-architected
some
of
our
concurrency
logs
to
get
some
better
stability
and
to
be
a
little
bit
less
invasive
or
heavy-handed.
C
We
did
some
more
work
on
the
network
upgrade
adrian
did
so
by
the
next
call.
We
expect
to
have
upgrade
our
network
stack
to
include
noise,
snappy
compression
and
the
native
attestation
medication
strategy,
we're
passing
the
version
10.1
tests,
I'm
hoping
to
merge
into
master
this
week,
just
dealing
with
some
kind
of
wider
code
based
things
we're
in
the
process
of
starting
100k
validated
test
net.
C
That's
because
rust
doesn't
have
a
compacting
garbage
collector,
so
we
built
an
abstraction
to
allow
storing
these
multiple,
smaller
lists
in
just
one
big
allocation.
This.
This
worked
well
reduced.
Our
memory
usage
by
more
than
half
didn't
really
affect
performance,
but
then
we
managed
to
move
some
allocations
from
the
heap
onto
the
stack
and
managed
to
shave
70
off
our
100k
state
hashing
times,
which
is
really
good.
That's
it
from
us.
I
L
Suggestions
from
that.
I
mean,
except
just
that
that
that
this
is
something
that
and
if,
if
we
won't
like,
if
we
want
to
do
it,
it's
worth
trying
to
start
I'm
starting
to
think
about
earlier
and
the
specific
way
in
which
we
would
handle
those
things
also
depends
a
lot
on
kind
of
some
like
specific
choices
in
terms
of
how
we
end
up
doing
things
like
things
like
execute
execution,
environments
and
data
inclusion,
for
example.
L
The
next
thing
I'm
trying
to
think
through
was
basically,
if
there's
backwards,
compatible
ways
to
introduce
ways
to
kind
of
detect
edge
cases.
So,
basically,
where
an
attacker
tries
to
sensor
blocks
for
just
long
enough
that
they
get
the
network,
thinks
they're
the
that
they're
censoring
and
the
other
part
of
the
of
the
network
doesn't
take
because
they're,
censoring
and
there's
some.
H
L
I
guess
one
kind
of
decision
points
that
I
can
realizing
that
we'll
have
at
some
point
is
basically
figuring
out
exactly
how
we
would
end
up
treat
treating
successful
51
attacks.
So
this
would
basically
be
cases
where
some
fraudulent
block
with
bad
ex
with
bad
execution
or
where
potentially
bad
data
gets
and
gets
included,
and
then
like
would
the
inside
would
the
chain
have
to
be
reverted
or
with
the
support
treated
in
some
other
way?
L
Basically,
but
that's
still
kind
of
a
long,
a
longer
term
concern
at
this
point,
yeah
so
short
term
amount
of
planning
to
probably
do
when
you
do
any
research
at
some
point
post
at
some
point
of
just
kind
of
the
basic
the
basic
techniques
for
basically
another
another
round
of
51
attack,
deduction
and
prevention.
That's
a
bit
more
kind
of
abstraction,
longer
term.
M
M
M
An
eth
one
overview
covers
pow
evm
scaling,
blockchain
basics.
We
have
an
e2
overview
which
goes
into
pos,
speak
and
change,
shards
ees
the
rollout
phases.
Then
we
have
a
proof
of
state
chapter.
It
goes
into
core
concepts:
basic
operations
for
choice,
long-range
attacks,
cast
breath
of
g
week
subjectivity.
M
Then
we
have
the
building
blocks,
which
is
bls,
randolph,
sse
committee's
deposit
contract,
shuffling
and
then
beacon
chain
chapter
which
starts
going
into
validator
lifecycle,
duties
structure.
All
of
that,
and
so
this
has
been
quilt-
has
been
giving
feedback
and
kelvin's
been
iterating
pretty
quickly.
Ben
edgington
has
also
been
involved
so
ben's,
I
know
separately,
been
doing
a
work
on
annotating
the
spec
and
he's
also
helping
edit
edit.
M
I
think
we're
generally
shooting
for
the
initial
release
around
two
to
three
months
from
now
and
and
then
it
would
be
actively
iterated
on
to
where
we
will.
You
know,
go
ahead
and
then
add
phase
one
into
book,
phase
two
and
then
further
pieces.
So
as
this
becomes
more
complete,
we'll
start
getting
feedback
from
from
more
people
and
making
this
more
wide
open.
So
just
fyi,
that's
that's
been
in
that's
been
in
the
works.
M
One
thing
that's
been
interesting
to
us
is
so
we've
realized
that
there
are
some,
I
guess,
higher
level
questions
in
phase
two
that
we
generally
need
to
situate,
so
you've
been
brainstorming
with
e-wasm,
it's
in
the
e32
research
team.
On
some
of
these
questions,
and
so
over
the
last
week,
we've
mainly
been
working
on
mario's
writing
things
up,
showing
how
everything
end-to-end
state
providers
to
state
access,
ee
communication
e
upgrade
great
ability
everything
how
they
kind
of
overlap
to
try
and
produce.
M
You
know
general
plan
a
and
plan
b,
and
so
we
can
all
kind
of
make
a
decision
on
final
scope
and
direction.
So
that's
that's
been
a
pretty
big
effort.
One
thing
this.
This
is
super
interesting,
so
the
original,
so
the
state
provider
post
that
and
scar
and
sam
did
originally
went
deep
on
this
discussion.
M
Maybe
maybe
we
took
too
skeptical
of
a
view
on
that,
and
so
we're
diving
into
an
exploration
here
and
in
fact
have
realized
how
moving
towards
a
static
state
access
model
can
bring
a
lot
of
benefits.
So
one
is,
we
could
get
synchronous
communication
with
between
ees.
It
simplifies
the
state
provider
network
drastically
and
a
lot
of
things
that
are
interesting
like
it
actually
works
more.
M
It
seems
to
work
more
towards
the
kind
of
ownership
borrowing
model
from
that
that
you
would
like
kind
of
see
in
something
like
patterns
of
rust
as
an
example
and
so
diving
into
this
analysis.
The
first
thing
we've
done
is
sam.
Wilson
has
extended
the
solidity
compiler
into
yule,
so
we've
added
taint
analysis,
so
we're
actually
able
to
run
taint
analysis
on
current
contracts
in
ease
one
and
we're
able
to
see
which
contracts
are
using
dynamic
state
access.
This
is
pretty
cool.
This
is
working.
M
M
If
we
do
push
towards
a
static
state
axis
model,
then
ultimately,
we
need
to
provide
tooling
for
developers
if
they're
writing
a
contract
and
solidity,
for
example,
or
viper
that
warns
them
if
they're
using
dynamic
state
patterns-
and
so
this
is
in
in
order
to
like
do
this.
Realistically,
this
taint
analysis
we
we
would
actually
need
to
add
to
the
tooling,
and
so
this
is
pretty
cool,
so
we're
showing
a
lot
of
promise
here.
M
Onscar
has
been
analyzing
contracts
by
hand,
so
he
started
with
uniswap
and
so
he's
kind
of
put
the
scenario
of
what
would
uniswap
look
like
if
we
move
that
to
a
static
state
access
model,
and
it
seems
like
we're
able
to
accomplish
that
with
my
inner
some
minor
changes.
So
that's.
This
is
just
the
beginning,
we're
also
looking
at
a
on-chain
cue
based
deck,
some
of
the
patterns
around
that
and
then
we'll
also
want
to
start
looking
at
other
patterns,
that
of
other
major
contracts
in
each
one.
M
Right
now.
So
that's
this
is
in
progress,
and
I
think
this
will
be
really
interesting.
We're
excited
to
kind
of
share
results
around
that
on
the
other
side
of
things.
So
we've
been
talking
in
these
calls
about
suite
of
tools
around
e
development
simulating
shards.
So
this
continues
to
move
forward.
Greg
has
been
working
on
the
simulator
and
he's
been
updating
internals
to
match
the
phase,
one
spec
that
has
been
in
progress
and
so
now
he's
building
an
sdk
around
the
actual
simulation
server.
M
And
so
again,
if
you
look
at
our
quilt
repos,
you
can
see
these
things
in
progress
right
now.
We've
started
gotten
it
to
where
there's
a
library
to
create
common
e
project
template.
So
this
includes
like
the
e-source,
the
wrapper,
stubs
and
test
stubs,
and
so
the
goal
is
that
this
is
like
a
unified
workflow
for
developing
and
then
deploying
it
to
the
simulator
and
then
running
the
tests
on
it.
So
part
of
this
suite
is
plugging
in
different
modules
and
libraries.
M
These
are
different,
like
libraries,
that
that
would
pre-exist
in
ee
you
might
want
to
use.
You
know
particular
tri,
very
proof
back
end
or
for
or
different
memory
back
ends.
So
matt
continues
to
work
on
that
he's
and
creating
generic
interfaces
to
create
these
multiple
proofs
on
the
fly.
So
that's
been
moving
forward
quite
well
yeah.
So
these
are
all
the
updates
from
quilt.
We've
been
staying,
productive
and
trying
to
stay
heads
down.
If
you
haven't
heard
as
much
from
us.
A
A
N
N
but
yeah,
so
that
that's
that's
happening.
Can
I
can
I
just
say,
as
an
aside
there's
a
slot
for
eth2.
That's
opened
up
at
consensus.
2020
puja
has
gotten
that
for
us,
and
so
if
there
are
people
interesting
in
participating
like
consensus,
not
with
the
y
with
the
you,
the
conference
that
they
have
in
new
york
in
may,
and
so
they
want
to
kind
of
like
get
more
technical
anyway.
So
I
put
some
stuff
in
the
sharding
getter.
If
you're
interested
thanks
joseph.
O
Just
a
quick
note,
so
proto
started
this
kind
of
write-up
about
client
implementation
that
I'm
trying
to
help
him
with
this.
So
I
have
been
trying
to
fill
up
some
of
the
more
general
content
on
different
topics.
This
week
I
was
working
on
the
bootstrapping
for
networking
and
leave
perfect
here
so
yeah.
We
expect
to
have
our
first
complete
draft
by
the
time
of
its
barcelona,
which
is
in
the
middle
of
may
and
so
yeah.
O
I
tried
to
provide
them
because
it's
easier
to
continue
to
help
contributing
when
there
is
already
some
kind
of
initial
test
and
starting
from
scratch
so
yeah.
I
just
want
to
invite
all
the
clients
developers
to
to
contribute
to
the
write-up.
You
can
find
the
link
in
the
education
channel
in
the
discord,
and
I
will
probably
read
also.
A
Moving
on
network
stuff,
we
did
have
a
network
call
about
a
week
ago.
There
are
some
limited
notes
up
from
that.
There
were
a
couple
of
pr's
that
have
come
derivative
of
that
and
in
general,
in
the
networking,
there's
kind
of
continued
refinement
of
network
spec,
some
added
conditions
to
validation,
conditions
to
gossip
subchannels,
to
reduce
some
of
the
dos
vectors,
and
I
do
expect
a
few
things
to
come
out
the
next
few
days
from
the
lease
authority
audit.
A
Given
when
that
lease
authority
audit
will
be
released.
I
think
we'll
do
a
call
not
next
week,
but
the
following
to
dig
deeper
into
any
pending
issues.
Anything
else
that
we
want
to
kind
of
knock
out
before
some
final
release
before
the
next
release
from
audits
and
ongoing
things
are
there.
So
we
will
have
a
lot
of
time.
Talk
during
that
call.
As
usual,
there's
a
lot
of
pr's
to
also
discuss
some
some
ongoing
things,
but
since
we're
all
here,
are
there
any
networking
related
items
that
people
want
to
discuss.
A
A
This
can
also
be
general
questions.
I
know
some
people
are
working
through
sync
and
other
items.
The
first
time,
like
we
discussed
blocked
by
range
request,
any
any
questions.
People
have
about
the
spec
any
anything
like
that,
because
they're
all
kind
of
in
a
different
range
on
where
they
are
tackling
that
so
there's
some
good
knowledge
to
share.
J
Yeah,
that's
pretty
much
it
so
if
people
have
the
compression
kind
of
already
set
up,
it's
it'll
be
interesting
to
have
a
look
at
the
vr
and
put
your
two
cents
in
but
yeah.
Fundamentally,
it's
it's
pretty
much
deciding
which
kind
of
snappy,
whether
we're
using
the
frame
or
just
block
compression,
and
if
we're
using
the
frame
compression,
we
might
have
to
do
a
modification
in
there
like
the
rpc
header,
which
is
pretty
much
what
the
er
is
about
but
yeah.
I
guess
just
have
a
look
at
it.
J
J
A
A
J
A
A
H
I
have
really
bad
connection
here,
we'll
see
if
you
can
hear
I'm
reviewing
the
document
that
you
just
updated
with
the
list.
So
we
didn't
move
that
much
forward,
but
we
we
have
many
of
the
things
that
you
are
discussing
from
other
work.
We've
done
so
we
you
have
all
the
snappy
compression.
This
is
that
we
started
networking.
We
have
vls
but
haven't
updated.
H
Yet
for
the
latest
spec
of
dls,
we
started
some
initial
work
on
discovery,
five,
but
I
think
only
next
week
or
next
two
weeks,
we'll
start
to
look
further
at
updating
the
spec
to
the
zero
10
and
then
I
hope
will
be.
I
mean
the
plan
for
now
is
probably
end
of
february
or
maybe
march,
to
have
s-net
and
then
start
to
think
about
connecting
to
the
multi-client
test
nets.
B
A
A
A
A
A
A
There
is
a
chat
in
we
have
a
conferences,
chat
section
with
a
few
conferences
in
the
discord
now,
there's
ethember,
svc
and
hcc,
so
we
can
use
that
for
just
general
discussion.
We
should
certainly
hang
out
grab
a
bite
I'll
try
to.
I
know
I
got
a
tally,
there's
like
a
handful
of
people,
who's
showing
up
but
I'll
pop
in
there
and
see
if
we
can
order
something.