►
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
karlikar,
I
am
the
cto
of
casper
labs,
the
company
building
the
casper
blockchain,
and
today
I'm
going
to
provide
our
first
engineering
status,
update
of
2021
very
exciting
year.
For
us,
we
like
to
call
this
the
year
of
casper.
A
I
will
go
over
what
we're
planning
what's
planned
for
engineering
and
then
the
community
had
a
question
around.
How
is
our
staking
economy
and
governance
designed?
So
that's
what
I'll
try
to
talk
about?
We
also
do
have
a
plan.
There
was
a
request
to
hear
about
the
marketing
plan
for
the
launch
and
I
will
coordinate
with
the
marketing
team
and
get
that
out.
That's
been
a
few
weeks
delayed.
We
know
that
we
have
to
provide
that
update
and
they're
working
on
their
proposals.
A
So
just
so
everyone
knows
that
I
haven't
forgotten
about
it.
It's
just
been
a
little
delayed,
so
we
started
our
fifth
weekly
sprint
of
the
21.01
release
cycle.
We
did
an
extra
sprint
because
of
the
holiday.
I
hope
everyone
had
a
safe
and
wonderful
holiday
season,
so
we've
got
an
extra
sprint
sprint.
9.5
and
21.01
is
the
first
release:
candidate
production
release
version
main
net
release
candidate
of
the
casper
protocol.
A
We
cut
tag
0.40
on
december
30th
and
we
deployed
it
to
the
delta
test
net.
The
test
net
is
currently
offline
because
we
found
a
problem.
There
was
a
problem
in
the
gossiper
and
this
took
down
over
one
third
of
the
network
and,
as
a
result,
consensus
stalled
as
it
as
it
should
stall,
but
we
have
a
fix
in
the
wings.
We
plan
on
restarting
the
test
net
tomorrow,
we'll
be
testing
the
fix
this
afternoon,
wherein
validators
can
rejoin
in
the
current
era.
A
So
if
there's
a
liveness
fault
for
validator,
they
should
be
able
to
rejoin
and
start
voting
again
on
blocks.
So
the
team
has
a
pretty
easy
fix
that
they're
going
to
implement
it's
actually
already
in
implementation.
We
have
to
build
package
test
and
then
push
it
out
tomorrow,
so
highway.
Our
longer
term
design
for
liveness
failures
is
to
disable
bids.
What
we're
doing
is
a
small
quick
fix
to
allow
validators
to
rejoin
in
the
other
era
and
then
we're
also
looking
at
the
block
header.
A
A
You
can
get
back
to
me
on
that
we're
going
to
replace
the
gossiper
component
with
lib
p2p,
which
is
what
ethereum
and
other
large
protocols
use
and
we
are
going
to
these
are
these
are
performance
improvements,
enhancements
and
optimizations.
We're
really
focused
on
now
small
and
incremental
improvements
and
hardening
and
optimizations.
A
That's
really
what
we're
focusing
on
right
now,
test
and
sre,
focusing
a
lot
on
getting
s-tests
to
run
the
test
suite
on
the
test
release
network
and
then
we're
getting
clarity
and
the
event
store
server
set
up
for
the
same
and
then
nctl
and
s-test
support
and
extensions.
This
is
to
actually
further
improve,
nctl
and
s-test.
I
would
actually
like
to
be
able
to
point
s-tests
at
an
existing
network.
I
don't
think
that's
possible
right
now,
but
we
should
be
able
to
do
that.
A
A
A
Ecosystem
we're
doing
a
tutorial
for
multi-sig
and
key
management.
We
do
have
a
video
up
there,
but
we're
going
to
do
a
proper
tutorial
to
go
with
it
as
well
as
updated
contracts
and
make
sure
that
there's
sample
code
that
people
can
use
and
then
we're
also
building
an
example
of
how
to
upgrade
contracts.
So
people
can
have
a
working
example
of
how
our
contract
upgrades
work.
A
We've
got
a
consensus
paper
that
we're
working
on,
I
believe,
alex.
I
saw
you
dropped
that
the
other
day.
So
I'll
definitely
take
a
look
at
this
and
then
we're
going
to.
C
See
this
go
ahead,
so
this
part,
this
particular
item,
is
actually
so.
It's
consensus
paper
and
equal
paper,
harmonization
right
so
because
I
got
to
the
point
in
you
know
writing
I
was
linking
paper
reaction
to
some
notation,
so
I'm
rereading
the
consensus
paper
making
sure
that
you
know
the
notation
we're
using
in
the
econ
paper
is
actually,
you
know
compatible
with
the
one
in
the
consensus
paper.
A
B
Yeah
I
have,
I
have
already
sent
an
email
to
daniel
and
we
also
have
the
latest
version
of
the
highway
paper
in
the
pdf
form
on
our
github.
Now.
A
A
There
it
is
so
january
5th
2021
fantastic,
so
this
is
the
full
paper
we
will
be
submitting
this.
This
is
the
paper
that
was
also
reviewed
by
trail
of
bits.
We
have
the
preamble
and
yeah.
It's
all
ready
to
go,
so
we
plan
on
submitting
this
paper
to
of
conferences
and
archive
daniel
kane
will
be
doing
that
and
very
exciting.
B
A
Oh
okay,
okay,.
A
Yeah
we
would
wind
up
here.
This
is
where
we
would
land
up
so
we're
very
proud
to
report
that
we
will
be
actually
providing
the
trail
of
bits
review,
so
they
will.
They
will
we're
going
to
be
very
transparent,
you'll
notice
that
a
lot
of
these
protocols
do
not
actually
transparently
display
their
findings.
A
A
A
B
Like
you
know,
a
green
light
from
you.
A
A
I
think
we
want
to
do
it
with
the
announcement
contract
run
times,
we're
applying
costs
to
all
host
side
system
contracts,
so
this
means
was
unless
transfer
won't
actually
be
free,
we're
also
getting
rid
of
system
contracts,
so
this
is
really
important
piotr.
I
think
this
is
a
typo
here.
Can
you
update
that
getting
rid
of
the
system
contracts,
so
this
is
really
important
presently,
with
the
casper
protocol.
We
originally
had
this
idea
that
we
would
have
very
even
our
system.
It
would
be
an
extremely
generic
implementation.
A
There
wouldn't
be
anything
when
I
say
generic
very
generalized,
very
fully.
What's
the
word
I
want
to
use
from
a
theoretical
perspective.
The
protocol
itself
would
not
behave.
The
consensus
protocol
wouldn't
behave
any
differently
than
any
other
smart
contract
right
and
most
of
protocols.
Don't
do
this.
Even
ethereum
doesn't
do
this
right,
so
there
are
what
they
call
host
side
functions
that
are
baked
into
the
protocol
itself
right.
So
the
protocol
is
not
generic,
meaning.
A
You
can't
just
take
the
core
technology
and
deploy
a
system
contract
that
changes
the
system
itself,
if
that
makes
sense.
So
when
we
initially
michael's
original
design,
had
a
very
generic
mechanism
in
which
you
could
just
deploy
contracts
and
configure
the
blockchain
with
how
you
wanted
it
to
work,
and
so
these
what
we
called
system
contracts.
So,
if
you
look
inside
the
casper
protocol
today,
you'll
notice
that
there's
a
mint
and
token
contract,
there
is
actually
wasm
files
that
need
to
be
deployed
at
the
time
you
run
the
contract
at
time.
A
You
run
the
blockchain
sorry
now
you
know
when
you
run
your
node
and
what
this
has
done
is
it
has
made
it
very
difficult
for
people
to
build
from
source,
and
so
what
do
I
mean
when
I
say
build
from
source?
Well,
typically,
what
you
want
to
do
a
lot
of
validators
prefer
to
build
their
nodes
directly
from
source,
rather
than
trusting
the
binaries
that
are
delivered
by
say,
casper
labs
or
somebody
would
want
to
do
an
alternate
implementation
in
a
different
language
right,
we're
building
a
rust
client.
A
Somebody
may
want
to
someday
take
the
highway
protocol,
take
the
specification
for
the
virtual
machine
and
build
a
client
and
go
right.
Just
like
ethereum
has
the
guest
client
and
the
original
ethereum
client.
So,
but
in
order
to
do
that,
they
would
need
the
pre-compiled
system
contracts,
the
webassembly,
and
this
doesn't
make
for
a
very
decentralized
system
right.
A
If
you
require
system
contracts
to
be
deployed,
then
you
would
need
those
system
contracts
to
be
trusted
and
pre-built.
Otherwise,
you
will
get
a
genesis,
hash
mismatch,
and
we
don't
want
that
right.
We
want
genesis
to
only
be
determined
by
the
chainspec
dot
tomml
and
the
accounts.csv,
and
those
two
files
will
provide
enough
uniqueness
for
a
genesis,
hash
or
even
a
future
state
hash
in
which
to
restart
the
blockchain.
A
On
governance,
we
do
have
our
cep
process
to
vet
and
accept
important
features
and
changes.
You
can
see
these
at
casperlabs.com.
A
We
encourage
people
that
want
features
in
the
protocol
to
build
enhancement
proposals
here,
how
to
create
a
cep
and
there's
infra
information
here,
and
you
can
also
view
the
14
active
ceps
right
now
that
are
open,
and
so
we
are
more
than
happy
to
accept
ceps
by
outside
persons.
A
And
you'll
see
here
ledger
leap:
you
know
created
a
cep,
et
cetera,
et
cetera,
so
there
are
once
the
cep
is
approved.
Then
it
would
go
into
implementation.
A
So
there's
plenty
of
cps
here
that
need
a
review
and
feedback
from
the
community.
So
please
do
take
a
look.
So
you
can
see
what
the
future
of
the
protocol
looks
like
in
other
exciting
news.
I
do
have
a
date
for
our
mainnet
launch:
it's
not
a
hard
date,
it's
a
window,
but
we
are
looking
at
end
of
february
launch,
and
so
that
is
what
the
team
is
pushing
towards.
A
A
We
have
big
announcements
coming
out
around
the
custody
solution
and
some
of
the
key
strategic
deals
that
we
have
made
very
very
excited
about
this
impending
launch.
We
still
cannot
talk
about
the
sale
of
an
unregistered
security.
We
want
to
remain
compliant
with
the
sec
guidelines,
and
so
once
we
have
completed
our
restructuring
in
preparation
for
public
launch,
that's
when
you
folks
can
expect
to
hear
and
learn
more
about.
What's
coming
up.
A
So
we
need
to
define
on
the
block,
header
and
body.
We
need
to
define
what
information
should
belong
in
the
block
header
and
what
we
should
leave
in
the
block
body.
We'll
transmit
all
data
from
the
header,
so
it
shouldn't
should
not
carry
any
unnecessary
information.
A
It
should
be
needs
to
be
well
thought
out
since
later.
That
would
be
a
hard
fork
right
after
the
block
the
information
in
a
block
changes.
That
would
definitely
be
a
hard
fork
protocol
upgrade
on
the
question
that
the
community
wants
alex
you,
and
I
can
probably
have
an
interesting
discussion
around
this.
How
is
casper's
staking
economy
and
governance
designed?
A
So
I
can
talk
a
little
bit
about
this.
I've
talked
about
this
before
it
came
about
quite
in
an
unexpected
way,
but
we
have
an
interesting
staking
in
governance
mechanism
that
we
believe
will
eventually
evolve
on
the
blockchain
once
it
launches,
and
that
is
that
there's
this
notion
of
the
oh
malika
wrote
an
article
about
this.
A
It's
about
this
alignment
of
incentives
right
the
token
holders
have
one
incentive:
validators
have
another
incentive
and
delegators
have
yet
another
incentive,
right
or
and
or
dap
developers
have
a
different
incentive,
and
the
casper
protocol
has
a
has
a
confluence
of
very
unique
features
that
enable
all
all
representatives
to
have
incentive
based
participation
in
the
protocol.
A
And
how
do?
How
does
this
work?
Well,
it
works
in
an
interesting
way
right
token
holders
if
they
custody
their
own
keys,
and
that
means
they
hold
on
to
their
private
keys
and
do
not
hold
them
on
exchange,
and
I
can't
I
can't
stress
how
important
this
is
right.
Exchanges
really
do
not
do
a
great
job
of
custoding,
your
keys.
A
So
it's
really
really
important
for
you
to
hold
your
assets
with
self-custody
right,
and
that
means
using
hardware
wallets
and
being
really
good
about
holding
onto
your
keys
safely
and
securely
securely
and
accessing
those
keys
to
participate
in
the
blockchain
in
the
following
manners.
Right,
one
staking,
you
want
to
be
able
to
stake
your
own
tokens
with
validators
that
you
trust.
A
So
this
is
going
to
be
a
really
important
thing
for
casper,
because
when
you
stake
your
tokens
with
a
validator,
you
increase
their
stake
in
the
network
and,
in
effect,
you're
kind
of
voting
for
them
right.
Your
vote,
you're,
giving
them
power
in
the
network
to
propose
blocks
and
participate
in
consensus
on
your
behalf.
So
this
is
an
incentive
based
mechanism
by
which
token
holders
can
actively
participate
in
the
protocol
and
in
the
event
of
a
protocol
fork.
A
They
should
token
holders
should
be
carefully
watching
which
validators
have
the
best
performance
and
are
being
responsible
and
actually
participating
in
a
protocol
fork
in
alignment
with
what
you
want
as
a
token
holder.
So
there's
a
very
strong
incentive
for
token
holders
in
the
terms
of
seniorage,
as
well
as
the
delegator
commission
that
the
the
validator
takes
for
people
to
vote
their
tokens
right.
It's
not
like
eos,
where
you're
just
voting
for
a
validator
without
an
incentive
aligned
with
that
here.
A
So
that's
one
thing:
that's
really
important
and
validators
will
have
a
strong
incentive,
because
in
so
doing
they
will
get
more
delegators
and
they'll
get
more
weight
in
the
network,
so
people
will
be
watching
both
validators
and
app
developers
will
be
watching
to
see
which
validators
are
being
really
responsible
in
terms
of
how
they're
participating
in
the
network.
The
second
thing
is:
dapp
developers
can
actually
upgrade
and
select
which
version
of
the
protocol
they're
going
with
in
the
event
of
a
protocol
hard
fork.
A
So
dapps
also
have
a
pretty
good
strong
seat
at
the
table
in
the
event
of
a
protocol.
Hard
fork
makes
it
very
interesting
and,
of
course,
validators
in
the
good
old-fashioned
way.
They
always
have
right,
they
can
choose
which
version
of
the
protocol
they're
going
to
upgrade
to,
and
so
they
will
also
be
watching
to
see
what
their
delegators
are.
A
Looking
for,
where
delegator
money
is
flowing
and
where
dap
how
the
dapps
are
voting
based
on
which
version
of
the
protocol
they
are
choosing
to
upgrade
their
their
software
to
so
it's
a
very
complex
game.
It's
not!
It's
not
really
obvious
to
me
how
this
is
all
going
to
work
out,
but
I
do
know
that
it's
really
important
for
each
of
these
participants
to
have
a
seat
at
the
table
and
to
be
able
to
participate
explicitly
in
in
governance
right
and,
I
believe,
there's
a
medium
article
that
was
written
by
casper
by.
A
You
know
to
have
a
seat
at
the
table
right
and
this
this
gives
this
will
create,
maybe
a
very
complicated
model
for
the
public
chain,
but
I
believe
that
it's
going
to
be
very
comprehensive
in
that
those
those
dapps
that
bring
a
lot
of
users
bring
a
lot
of
transactions
will
have
a
much
stronger
voice
at
the
table.
It
won't
just
be
the
miners
right
and
it
you
know
if,
if
token
holders
hold
on
to
their
tokens,
it
won't
just
be
the
exchanges.
I
can't
emphasize
that
enough.
A
It's
really
really
important
that
users
have,
you,
know,
custody
their
own
keys
and
that's
one
of
the
reasons
why
we
built
the
features
that
will
even
support
something
like
social
recovery
and
we'll
be
working
with
you
know
both
the
the
devdao
and
the
the
community
will
be
encouraging
them
to
build.
You
know
on-chain
social
recovery
tools,
so
people
can
have
a
lot
more
confidence
around
using
self-custody
of
keys
without
their
keys
being
stolen
right.
A
A
A
C
Point
about
you
know
our
very
substantive
mechanisms
that
we
essentially
designed
separately
do
seem
to
come
nicely
together.
As
you
know,
as
you
said,
you
know
sort
of
an
implicit
own
chain
governance
mechanism.
So
what
I'll
try
to
do
is
actually
address
this
in
the
econ
paper
as
well,
because
this
is
something
that
they
can't
really
plant
on
discussion,
but
I
guess
you
know
somebody
will
be
writing
about
the
ecosystem
and
the
incentives
surrounding
that.
This
is
something
I
will
actually
write
about.
A
I
think
that
would
be
excellent
yeah
I
mean
we
talked
about
the
collective
action
problem
and
you
know
I
think
it's
one
of
the
reasons
why
eos
failed
right,
and
this
is
why
you
see
a
lot
of
on-chain
governance
models
right
now
getting
taken
over
by
wales
because
they
just
buy
up
all
the
token
and
they
just
buy
up
all
the
reputation
of
the
network,
and
you
really
want
to
do
something
different
and
here
what
I
really
love
about.
A
The
way
our
governance
model
will
evolve
is
that
the
incentives
are
rooted
in
economics
right.
So
when
you
ground
your
incentives
in
economics,
you
have
a
much
better
chance
of
getting
a
higher
engagement
by
the
community
in
the
long
term.
Right,
because
they're,
strong,
like
it
or
not,
basic
economics,
tells
you,
like
you
know.
Fundamentally,
economic
incentives
are
pretty
pretty
high,
they're,
very,
very
powerful
driver
for
participation
right,
there's,
no
sense
in
denying
that,
so
I'm
very
excited.