►
From YouTube: CasperLabs Community Call
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
coming
to
us
from
my
name,
is
metta
parlikar,
I'm
the
cto
and
one
of
the
co-founders
of
casper,
and
today
I'm
going
to
provide
a
update
to
all
of
you
on
the
status,
the
project
and
what's
up
next
for
us.
So
without
further
ado,
I'm
going
to
go
ahead
and
share
my
screen.
A
All
right
so
we'll
kick
off
the
agenda
with
an
engineering
status
update
on
where
we
are
with
the
project.
What's
up
next
for
us
how
things
are
going,
I
know
that
a
lot
of
folks
are
curious
about
how
we're
making
progress
in
our
current
test
nets.
So
without
further
ado
we'll
get
started.
We
are
in
our
first
weekly
sprint
of
the
20.11
release
cycle.
We
will
be
cutting
our
release
this
week.
Ashok
we're
planning
that
for
later
this
week,
right
we're
getting
ready.
B
Yeah,
usually,
usually,
usually
we
cut
it
on
thursdays,
yep,
that's
not
target
target
date.
A
Yeah
so
plan
to
see
the
new
release
by
the
end
of
the
week
and
once
that
release
is
cut,
we're
going
to
start
working
with
the
charlie
testnet
validators,
with
testing
it
out
and
getting
it
hardened
and
ready.
A
We
are
working
with
about
a
handful
of
validators,
six
or
seven
validators
right
now
that
have
agreed
to
roll
up
their
sleeves
and
put
this
this
little
node
under
you
know
through
its
punches
and
so
that's
the
plan.
A
How
we're
doing
we
saw
a
hiccup
in
the
beta
test
net
and
we've
noticed
two
hiccups
in
the
beta
test
net
and
we're
we've
got
some
logs
from
one
of
the
validators
and
so
we're
going
to
dig
into
that.
I'm
mostly
concerned.
If
there's
some
issues
in
the
you
know,
if
there
were
some
deploys,
that
we
received
that
potentially
created
a
problem
for
the
contract
runtime,
so
we're
re-implementing
a
lot
of
the
scala
code.
A
So
it's
a
little
bit
less
of
a
concern
on
the
scala
code
side,
but
I
am
worried
about
the
contract
runtime,
because
that
is
a
shared
code
base
between
the
two
test
nets.
So
we
want
to
make
sure
that
that's
clear,
so
the
network
is
stable
and
processing
deploys
both
of
the
networks
are
the
we're
at
era
164
of
the
charlie
test
net.
A
I
don't
know
what
error
number
we
are
in
the
beta
test
net
because
we
don't
keep
track
of
that,
but
the
last
finalized
block
is
close
to
100
000,
so
we
did
see
a
blip
in
the
beta
test
net,
but
the
system
did
heal
when
the
net
when
the
validators
were
alerted
and
they
cleaned
up
their
nodes,
they
were
able
to
catch
up
and
resync
up.
So
it
doesn't
look
like
it
was
a
permanent
problem.
There
was
just
some
issue
with
them
voting.
A
They
experienced
a
voting
problem
current
focus
in
highway,
we're
looking
at
implementing
slashing
so
as
we're
well
aware
that
we
will
be
slashing
for
equivocations.
So
if,
if
a
validator
detects
an
equivocation
in
a
previous
era,
we
want
to
slash
for
it
even
in
the
current
era.
So
those
equivocations
that
happen
close
to
a
switch
block
are
the
edge
cases
that
we're
trying
to
deal
with
right
now
and
we
have
a
variety
of
tickets
around
highway
security
right.
A
So
andreas,
like
I
said,
sits
in
his
sits
at
his
desk
all
day
and
cooks
up
brand
new
ways
to
attack
the
network
and
and
how
he
can
find
more
vulnerabilities.
So
he's
got
a
rather
extensive
backlog
of
things
that
he
wants
to
implement
in
the
protocol
to
make
it
secure,
rust
node.
So
we
are
looking
at
the
networking
layer
we're
going
to
look
at
lib.
A
P2P
lib
p2p
has
been
pretty
battle
tested,
but
we're
also
going
to
look
at
a
couple
of
other
rust,
specific
libraries,
so
we'll
probably
wind
up
going
with
lid
p2p
but
frazier's
working
on
on
investigating
that
and
deciding
what
we're
going
to
do
to
upgrade
the
networking
to
look
at
the
off
off
the
shelf.
A
So
whenever
you
want
to
monitor
a
network,
you
want
to
understand
what
is
your
leading
indicator
of
server
health,
so
one
of
them
that
we
noticed
with
the
scala
node
was
obviously
if
the
unprocessed
deploy
count
kept
going
up
and
to
the
right
that
we
knew
that
the
network
was
not
processing
transactions.
So
there
was
some
kind
of
problem.
A
On
the
tested
sre
front,
once
we
get
the
release
candidate,
this
friday,
we're
going
to
start
banging
on
it
pretty
hard
for
a
couple
of
weeks
to
make
sure
it's
a
production
grade
ready
and
then
obviously,
on
the
going
live
front.
Sre
is
going
to
be
working
with
all
the
validators
to
get
them
ready
to
switch
over
from
the
scala
node
to
the
rust
node
and
that's
going
to
have
to
happen
pretty
quickly.
If
you
think
about
it,
probably
in
48
hours
right.
A
So
we
will
have
validators
deprovision
the
scala
network
and
come
up
with
the
rust
network.
So,
from
the
end
user
perspective,
it's
going
to
look
like
a
test
net
bounce,
but
behind
the
ski
scenes
it's
going
to
be
a
completely
new
node.
So
we're
going
to
really
need
to
button
down
the
the
basically
the
installation,
right
and
readiness
process
and
we're
going
to
be
working
on
that
over
the
next
couple
weeks.
A
On
the
s
test
front,
we're
happy
to
welcome
mark
lemoyne
to
the
team
who's
going
to
be
focused
fully
on
s
tests,
we're
going
to
be
implementing
a
workload
generator
for
unbonding
and
bonding,
because
that
will
be
part
of
delta
test
net.
So
it's
going
to
be
a
big
feature
that
we're
going
to
be
testing
via
s-tests,
I'm
assuming
we're
creating
workload.
Generators
for
that
very
excited
to
have
mark
join
us,
yet
another
markup
to
three
marks
now
on
our
team.
A
Are
we
going
by
their
last
name?
Is
it
going
to
be
green,
slade,
lemoine
and
brinkman?
Is
that
what
we're
going
to
do?
I
think
that's
what
we're
going
to
do
on
the
ecosystem
from
creating
the
javascript
sdk
that
is
compatible
with
the
rust
client
apis
and
then
we're
also
building
up
clarity
that
consumes
this
javascript
sdk
and
we're
also
going
to
open
source
and
make
available
this
javascript
sdk.
I
think
it's
pretty
important
and
we're
integrating
more
deeply
the
signer
and
clarity.
A
A
Certainly
don't
want
to
have
that
happen
with
the
signer,
so
we
got
to
make
sure
that
thing
is
really
secure,
we're
implementing
the
event
store.
This
is
basically
a
read,
only
store
of
blockchain
events
rather
than
querying
the
nodes,
because
that
is
non-deterministic
load
against
a
validating
node.
We
don't
want.
We
don't
want
to
put
them
through
that
we're
going
to
separate
the
concerns
and
we're
going
to
basically
the
node's
going
to
emit
events
and
which
you
can
just
read
or
subscribe
to,
and
then
we're
going
to
implement
a
store
for
this.
A
If
you
want
to
read
the
cep
for
the
event
store,
I'm
pretty
sure
it's
up.
I
take
a
look
at
cp,
casper
labs
and
casper
enhancement
proposals
and
you
just
go
look
at
the
pull
requests
here.
I'm
pretty
sure
this
is
this
event
stream?
Why
did
I
think
that
mache
is
creating
one
for
that?
B
A
Maybe
he
just
put
a
image
up
in
slack
and
he
hasn't
written
the
cep
yet
he's
supposed
to
be
writing
the
cep
for
that.
So
you'll
see
what
that
looks
like,
I
believe,
we're
figuring
out
if
it's
going
to
be
rust
or
javascript
in
terms
of
the
language
that's
going
to
back
it
we're
looking
at
the
final
price
link
settings
for
gas
price
and
fiat
alex
you
plan
on
talking
about
that
today.
C
I
I
believe
I
I
give
the
broad
outlines
last
time:
okay,
but
yeah
I
mean
we
evolve
here,
continuing
work
on
that.
Basically
so,
but
there's
not
much,
you
need
to
report
to
zone.
A
Yep
sounds
good.
Yep
contract
run
time,
we're
updating
the
proof
of
state
contract
to
work
with
the
auction
contract.
That
should
be
done
right
ashok.
We
did
that
work
last
week.
A
A
This
is
to
support
validator,
set
rotation
and
bonding
on
bonding.
So
the
if
you
talk
about
like
one
of
the
big
rocks
that
are
part
of
the
next
release,
it's
validator
set
rotation
and
seniorage
right.
So
validators
you
get
a
chance
to
see
what
your
rewards
are
going
to.
Look
like.
A
C
So
the
correct
operation,
for
you,
know
a
situation
where
validator
you
know
is
bonded
right.
For
example,
you
know
found
invalidator
is
bonded
with
them.
Just
never
joins
or
interacts
with
the
network.
Is
that
well
for
a
while?
Basically
they're
going
to
be
sticking
around
missing
their
times
to
produce
blocks
and
receive
zero
reward,
because
they're
just
in
a
continuous
state
of
liveness
failure?
C
But
eventually,
as
people
add,
you
know
more
tokens
to
their
bids
and
in
fact
the
founding
validators
also
unlock
and
it
becomes
possible
for
them
to
lose
their
positions.
Such
validate
will
basically
just
drop
off
of
infiltrate.
They'll
have
a
you
know.
10
years
later,
they'll
have
a
standard
bid,
but
they're
not
going
to
be
doing
it
at
all.
So
you
know
they're
not
going
to
be
a
validator.
In
fact,.
C
No,
but
I
mean
we
would,
but
that
is
contrary
to
their
interest,
because
they're
not
receiving
rewards.
A
Right
right,
but
but
it's
also
like
it's
also-
I
mean
it's
also
a
very
inexpensive
attack
on
the
network
like
there's
literally
no
there's
literally
no
downside.
So
I
wonder
if
we
wouldn't
implement,
I
mean
liveness
is
like
a
throttling
right
because
they
get
no
rewards,
but
they
because
they're
not
voting.
They
are
impacting
the
amount
of
stake.
Arguably,
that
can
vote
on
blocks
right.
C
C
C
C
That
was
like
the
intuitions
that
we
had,
but
I
don't
think
anything
along
those
lines
was
actually
written
into
the
code
like
we
still
need
to
have
like
a
formal
design
for
that.
So
this
is
actually
something
that
yeah.
We
would
need
to
consider.
It's
like
okay.
Well,
what
if
you
have
just
phantom,
you
know
weights
sitting
around,
should
that
you
know
at
what
point
should
you
stop
considering
that
to
be
real
wait
for
these
kind
of
things.
C
Okay,
we
will
okay,
we
will
I'll
try
to
remember
to
do
this
once
we
get
to
working
on.
You
know,
issues
like
issues
like
round
or
two
adjustment,
and
you
know
probably.
A
Just
need
to
create
a
ticket
about
it
and
state
the
problem
in
a
ticket,
and
then
we
can
talk
about
it
yeah.
I
don't
think
we
will
have
this
issue
for
the
first
90
days.
Right
like
this,
isn't
something
we
need
to
adopt
immediately,
but
I
believe
that
it
is
something
we
will
need
to
adopt.
Probably
we'll
need
to
have
some
kind
of
a
strategy,
maybe
after
post
maintenance,
all
right.
C
A
Even
after
mainnet
90
days
after
mainnet,
all
the
validators
will
be
locked
right.
So
most
of
most
of
the
stake
will
be
locked
in
the
auction
contract
for
90
days
post
launch.
So
we
don't
have
to
worry
about
any
potentially
any
liveness
failures
that
we
can,
you
know
quote:
unquote
trust
the
validators,
but
like
later.
A
It
is
if
they
go
offline.
I
know
it
is
you're
not
wrong,
but
I
gotta
believe
that,
in
terms
of
a
malicious
validator,
the
risk
is
a
little
bit
lower,
but
yeah
so
we'll
see
but
yeah.
I
think
that
this
is.
This
is
definitely
something
we
should
take
it
and
talk
about
okay,
yeah,
so
here's
the
design
so
yeah.
We
probably
need
this.
This
is
not
a
cep,
but
at
least
there
should
be
a
cep
with
a
link
to
this,
so
so
we're
keeping
all
the
designs
in
one
spot.
A
Thanks
for
that
I'll
take
a
look,
let's
see
not
doing
any
additional
work
in
the
scala
node.
We
do
want
to
dig
into
why
we
seem
to
have
six
to
ten
nodes
that
suddenly
went
offline.
We
don't
know
if
it
was
a
heap
problem,
a
memory
problem
or
what
we
just
want
to
do-
a
root
cause
analysis
and
see
what
component
was
was
at
fault
there.
So
we
understand
and
learn
from
that.
A
A
I'm
optimistic
that
by
the
end
of
october
we
will
have
a
draft
that
is
a
final
copy.
That's
ready
to
go
to
trail
of
brits
for
security
review,
which
is
planned
mid-november,
so
we're
pushing
real
hard
on
our
timeline
and
we're
working
with
hanzo
to
help
do
a
hardening
of
the
node,
as
well
as
the
good
work
that
mark
lemoyne
is
doing
and
the
srv
team,
so
we're
ready
to
go.
So
that's
that's
the
engineering
update.
A
If
you
have
questions-
and
there
are
things
you
want
to
know
about
the
project-
don't
hesitate
to
ask
on
our
telegram
channel
or
join
us
on
discord.
I'm
also
speaking
at
la
blockchain
summit.
I'm
doing
a
presentation
tomorrow
afternoon,
l.a
blockchain
summit.
You
can
sign
up
for
free,
it's
100
virtual,
so
there's
no
cost
to
attend.
So
you
can
go,
join
that
and
get
some
great
information,
I'm
also
doing
the
great
north
hackathon.
A
I
think
that
is
september
17th,
hosted
by
the
google
dev
group
out
of
my
hometown,
windsor
ontario,
so
super
excited
about
that,
a
friend
of
mine,
that
that
is
an
organizer
in
that
invited
me
to
speak.
So
I
want
to
go
talk
about
blockchain
technology,
so
that'll
be
great
fun,
educate
some
folks
about
what
blockchain
is
we
love?
We
love
doing
that
and
supporting
folks
in
you
know
adopting
blockchain
broadly
from
the
web
to
space.
A
What
are
the
long-term
goals?
How
do
you
see
people
using
the
casperlas
platform
in
the
future
yeah?
So
you
know
I've
talked
a
lot
about
this
right
in
terms
of
what
I
see
our
blockchain
being
used
for.
I
see
blockchain
as
part
of
a
larger
application
architecture
right
and
like
specifically,
when
you
talk
about
a
larger
application
architecture.
A
You
talk
about
something
that
looks
a
lot
like
this.
I
could
actually
share
my
screen.
This
is
something
I
want
to
be
talking
about.
La
blockchain
summit
is
that
you
know
how
are
we
going
beyond
blockchain
and
start
talking
about?
Like
you
know,
our
initial
use
case
of
blockchain
is
a
token
right
and
all
the
different
ways
you
can
use
a
token
and
non-fungible
tokens
defy
tokens,
governance,
tokens,
tokenizing
assets
right,
but
really
it's
been
around
token.
A
A
The
token
is
the
first
logical
implementation
of
of
of
the
trust
layer,
because
you
need
you
know
you
want
to
decentralize
money
right,
but
here
I
am
showing
you
the
an
example
architecture
of
what
we're
building
for
ipv
and
we're
talking
about
building
a
trust
layer
for
who
owns
something
right
and
we're
not
talking
about
tokenizing
patents,
but
really
like
a
chain
of
custody
solution.
That's
on
the
blockchain!
A
So
right
now,
there's
about
five
to
ten
percent
of
all.
Patents
are
sold
by
somebody
that
doesn't
own
them,
and
this
isn't
necessarily
fraud,
although
one
could
argue
fraud,
but
it
also
has
to
do
with.
I
think
I
own
the
patent,
but
I
actually
don't
own
the
patent.
A
So
when
you
talk
about
a
trust
layer,
I
actually
see
blockchain,
ultimately
providing
trust
to
applications,
and
I
think,
in
time
applications
will
need
to
be
very
cognizant
of
how
they
use
this
trust
layer,
because
it
will
be
very
expensive
right.
It
should
be
expensive
because
every
transaction
is
run
a
hundred
to
a
thousand
times.
A
You
know
on
the
blockchain
and
so
having
that
trust
right
so
think
about
how
much
it
costs
to
adjudicate
a
case
right
and
if
you
had
just
had
trust
in
the
data
where
the
confusion
started,
then
that's
really
worth
it
right.
That
becomes
something
that
yeah
I'll
spend
a
good
amount
of
money
to
for
this
trust
layer
right
and
so
that's
where
I
see
blockchain,
ultimately
going
and
really
providing
value,
you're
not
going
to
have
trust
if
it's
not
decentralized
and
permissionless
right.
A
So
that's
why
you
really
need
to
be
able
to
adopt
public
blockchain
for
decentralized
for
applications,
not
even
decentralized
applications.
Right
like
the
rest
of
this
architecture.
You're
looking
at
here
is
very
centralized
right.
It's
just
the
public
smart
contracts,
that's
decentralized
right,
so
the
entire
app
isn't
decentralized
right,
but
the
piece
that
is
decentralized
really
leverages.
This
trust
layer-
and
so
you
know,
when
you
talk
about
decentralized
apps
that
are
fully
implemented
in
the
blockchain.
That's
not
what
I'm
talking
about
here
right,
I'm
not
talking
about
that!
A
I'm
talking
about
applications
that
run
in
the
world
today
with
a
greater
layer
of
trust
and
so
using
this
greater
layer
of
trust.
You
get
more
value,
you're
able
to
extract
more
value
out
of
the
application
or
more
trust
out
of
the
application
by
using
this
smart
contract
layer
and
other
applications
like
that
are
like,
for
example,
did
you
know
that
pharmaceutical
companies
spend
almost
twice
the
amount
of
time
validating
their
data
set
that
for
clinical
trials
and
they
do
collecting
it?
A
They
spend
that
much
time
and
and
just
imagine
if
they
could
trust
that
data
set,
because
it's
all
tracked
by
a
blockchain
technology
in
clinical
trials,
how
much
time
they
could
save
in
terms
of
bringing
those
drugs
to
market
and
the
impact
it
could
have
on
humanity
right
so
like
these
are
the
things
that
I
see
blockchain,
ultimately
providing.
But
again
you
have
to
have
absolute
trust
in
the
data,
and
you
can't
get
that
unless
it's
decentralized
and
permissionless
and
of
course,
there's
the
entire
privacy
bits
right.
It's
it's
it's
bigger
than
a
breadbox
right.
A
This
is
like
I'm.
I'm
just
honing
in
on
a
really
really
small,
a
few,
a
couple
of
use
cases
right,
but
there's
like
a
great
deal
that
the
trust
layer
brings
to
bear
that.
Not
even
you
know
not
even
really
talked
about
here.
So
that's
what
I
see
the
future
of
casper
labs.
That's!
What
we've
built
is
to
enable
this
kind
of
application
development
right
where
you're,
putting
that.
A
That's
that
really
essential
piece
of
data
on
the
public,
blockchain
and
you're,
able
to
maintain
and
manage
that
that
contract
and
look
at
the
canonical
history
of
that
data
set
and
say
yep.
We
can
prove
beyond
a
shadow
of
a
doubt
that
this
transaction
happened.
This
data
was
mutated
in
this
way
through
these.
Through
these,
you
know
through
these
changes.
So
that's
what
I
see
and
our
long-term
goals
right.
So
that's
how
we
see
the
casper
last
platform
being
used.
A
A
If,
if
you
know
d5
authors
see
us
as
a
suitable
blockchain
for
that,
but
then
like
also
it's
a
blockchain
built
for
the
governance
of
applications
on
chain
right.
So
all
software
is
governed
right
and
so
governing
whether
you're
governing
a
d5
protocol
that
locks
value
or
you're
governing
an
application
like
this,
because
it
also
has
value
right.
There's
value
locked
up
in
those
patents,
arguably
potentially
depending
on
the
patents
a
lot
more
than
even
in
d5.
All
of
that
needs
to
be
governed,
and
you
want
to
be
able
to
govern
it.
A
Trust
you
know,
via
this
trust
layer
which
is
known
to
block
as
a
blockchain,
that's
public
and
decentralized.
So
that's
my
spiel
and
what
I
see
in
in
terms
of
the
casper
platform
long
term
in
the
future.
A
Always
open
to
hearing
feedback,
if
you
think
I'm
wrong,
I'm
also
open
to
hearing
that
too.
I'm
definitely
open
to
being
wrong.
I
feel
like
it's
a
unique
niche
that
we've
carved
out
for
ourself,
that
that
sets
us
up
very,
very
well
to
build
a
future-proof
blockchain.
You
know
future
built
on
blockchain
that
will
evolve
and
grow
over
time
thanks
everyone
we're
at
the
bottom
of
the
hour.
A
I
hope
you
enjoyed
the
call
follow
us
on
twitter,
join
the
discord
and
the
telegram,
if
you
want
to
learn
more,
have
a
great
day
cheers
bye.