►
From YouTube: CasperLabs Community Call
Description
Development update, Delta Testnet, Validator Bonding Auction overview.
A
All
right,
good
morning,
good
afternoon,
good
evening,
wherever
you're
coming
to
us
from
my
name,
is
metta
parlikar.
I
am
the
cto
and
one
of
the
co-founders
of
casper
labs
and
today
I
will
provide
an
update
on
engineering
progress
and
then
we
will
have
some
open
topics
to
discuss
that
have
been
proposed
by
the
community.
A
So,
let's
kind
of
dig
into
our
engineering
status
so
execution,
we
are
on
sprint,
8.2
release,
20.12,
really
delivers,
prioritized
bug,
fixes
networking
improvements
and
more
consensus
protocol
security
features.
The
intention
is
by
the
end
of
the
cycle
that
will
support
up
to
100
validator
slots
in
the
bonding
auction.
I'll
talk
a
little
bit
more
about
the
bonding
auction
during
today's
call
and
we're
really
focused
we're
kind
of
bearing
down
on
performance
and
what
we
can
do
in
the
block
proposer
to
push
more
transactions
into
the
blocks.
A
A
A
A
Our
current
focus
is
getting
ready
for
our
security
audit
with
trailer
bits
and
that
involves
getting
the
highway
paper
completely
ready.
Cardinal
cryptography
has
been
working
with
us
to
get
the
paper
really
polished.
While
andreas
focuses
on
building
consensus,
we
have
fourth
bomb
protection
and
defense
against
fork
spam.
These
are
those
two
attacks
that
every
fourth
choice
protocol
is
susceptible
to
and
we're
building
building
defenses
against
that
that
work
is
underway
right
now,
matej
is
doing
that
work.
A
On
the
node
rust
side.
We
are
going
to
be
upgrading
the
small
network
components,
although
the
current
network
seems
to
be
doing
quite
well.
We
we
don't
feel
that
this
code
is
production
grade
yet
so
we're
looking
at
lib
p2p
and
we're
doing
we're
probably
going
to
try
look
at
draw.
You
know
dropping
that
in
and
integrating
that
in
as
a
core
piece
of
the
architecture
we're
actually
looking
at
testing
the
storage
component.
We're
also
still
looking
at
state
pruning,
but
we're
looking
at
different
options.
A
We're
going
to
take
a
pretty
big.
You
know
ambitious
amount
of
work
on
the
state
pruning
piece,
but
we're
going
to
look
at
something.
That's
a
little
bit
more
incremental
and
pragmatic
again
bearing
down
on
optimizations
and
hardening
once
we
have
correctness
taken
care
of
and
replacing
rnp
survey
with
two
bytes
from
bytes.
This
is
our
own
proprietary,
serialization
format.
I
feel
that's
really
important
need
to
get
that
done
before
we
go
to
mainnet.
A
Network
tolerance
monitoring
so
really
making
sure
that
we
can
monitor
the
network
for
problems
such
as
network
partitions
and
dos
attacks.
What
do
those
look
like?
What
do
we
need
to
monitor
for
those
events,
we're
building
an
event
store?
I
will
show
you
folks
the
event
store
in
my
other
terminal
here.
A
It's
not
going
to
show
you
something
immediately,
but
basically,
if
I
scroll
up
here,
you
can
see
the
node
emits
events
as
the
network.
Does
things
completes
things,
so
this
is
a
protoblock
and
then
this
is
a
finalized
block,
and
here
you
see
the
parent
hash,
the
body
hash
and
if
there's
any
deploys
the
deploys
appear
in
here
whoops.
So
here
you'll
see
a
new
block
was
just
added.
A
This
is
a
finalized
block.
This
block
also
doesn't
have
any
deploy.
So
it's
an
empty
block
with
respect
to
the
number
of
deploys
in
here.
If
you
scroll
up
here,
you'll
see
an
example.
This
example
this
here
is
a
deploy.
So
this
is
the
deploy
is
processed.
I
believe
this
is
probably
a
bid
request.
We've
seen
mostly
bitter
requests
here.
You
see
the
time
stamp
for
the
deploy
the
time
to
live
for
the
deploy
the
dependencies
whoops.
A
A
So
this
is
called
the
event
stream
and
we're
going
to
capture
these
events
and
we're
going
to
put
them
in
an
event
store,
and
what
we
will
do,
then
is
we
will
make
it
so
that
all
requests
for
data
from
the
network
are
pushed
to
the
event
store
versus
having
this
non-deterministic
load
coming
to
validators
right
s-tests.
We
are
updating,
monitoring
and
extending
workflow
generators.
This
is
really
to
help
us
bear
down
on
the
testing
that
needs
to
be
done
for
the
network.
A
On
the
ecosystem
front,
we
need
a
brand
new
clarity.
The
current
clarity
is
not
going
to
work
because
it
used
a
lot
of
the
functionality
that
was
part
of
the
scala
node
scala
node
had
graphql
baked
into
it,
which
we
will
not
be
supporting
in
the
node
itself.
The
graphql
interface
will
come
off
of
the
event
store,
so
we're
integrating
the
clarity
code
base
with
the
event
store.
So
we
can
provide
the
same
kind
of
data
that
we
did
with
the
existing
clarity.
A
We
want
to
provide
that
with
the
new
clarity
using
rust,
we're
building
a
javascript
sdk.
We
recognize
this
is
really
important.
We
actually
need
it
for
a
custody
solution
provider,
so
they
they
are
looking
for
a
javascript
sdk,
so
we'll
be
bearing
down
on
that
and
releasing
a
separate
package
for
javascript
development
using
the
casper
client.
A
Block
proposers,
so
we
are
looking
to
support
this
idea
of
how
do
we
know
how
many
transactions
we
can
squeeze
into
a
block
because
we
have
execution
after
consensus.
Presently,
this
is
just
a
number
of
deploys
and
we
really
don't
know
how
much
gas
usage
is
in
each
of
those
deploys
and
so
we're
trying
to
do
something
a
little
bit
better.
So
we
can
kind
of
reliably
understand
how
much
work
is
being
performed
in
any
given
block
right.
So
this
is
a
little
bit
of
a
challenge
and
execution
after
consensus
model.
A
A
Thank
you.
Thank
you
very
much
yeah,
so
I'm
going
to
well
because
I
actually
do
everything
before
I
document
it.
So
it's
a
great
forcing
function
for
me
to
use
the
software
and
I
believe
in
using
the
software
myself,
because
I'm
fairly
picky
on
the
user
experience
right.
So
if
I
can't
do
it,
that
means
it's
way
too
hard,
so
contract
runtime
we're
refactoring
some
of
the
auction
types
to
avoid
synchronizing,
multiple
values
and
we're
doing
some
bug
fixes.
A
We
found
a
bug
in
the
stakes
not
being
reported
correctly
to
the
proof
of
stake
to
consensus
from
the
auction
contract.
So
that's
something
that's
an
interesting
thing
because
the
auction
contract-
it
is
a
system
contract,
but
it's
it's.
So
it
needs
to
communicate
to
the
you
know
the
proof
of
stake
contract,
what
its
status
is
in
terms
of
the
validators
and
their
associated
stakes.
So
henry
just
found
that
bug
yesterday
so
yeah
we're
doing
a
bunch
of
bug,
fixing
and
then
scala
node
we're
not
doing
any
work
on
the
scala
node.
A
B
I'm
still
working
on
the
you
know
the
presentation
for
other
things,
but
we
can
discuss
shortly
what's
common
in
terms
of
gas
pricing
very
very
briefly.
So,
currently,
obviously
our
platform,
you
know,
does
not
really
have
anything
like
market
for
gas.
In
fact
with
currently
we're
just
you
know,
basically
charging
a
fixed,
you
know
a
fixed
amount
per
unit
of
gas
and
that's
under
the
story.
So
of
course,
for
reasons
of
economic
efficiency.
B
This
cannot
really
be
the
case
in
the
long
term.
Of
course,
you
know
people
on
the
school
or
people
watching
the
studio
later
knows
that
we
have
plans
later
on,
to
implement
both
a
link
to
fiat
and
basically
gas
futures,
but
for
the
initial
step,
of
course,
we
need
just
a
basic
functioning
spot
market
for
gas,
and
yesterday
we
more
or
less
decided
on
a
rough
outline
of
how
this
is
going
to
function.
It's
going
to
be
conceptually
fairly
similar
to
ethereum.
B
This
is
the
difference.
Is
that,
instead
of
like
an
ethereum
specifying
your
willingness
to
pay
and
your
gas
limit,
essentially
you're
going
to
be
saying
that
you
are
buying?
You
know
x,
units
of
gas
up
front
and
then
whether
you
burn
it,
you
know
completely
or
not,
that
you
know
that
is
up
to
you
and
your
ability
to
estimate
how
much
gas
your
code
will
burn.
B
A
It's
a
huge
difference
and
I'm
wondering
I
would
actually
assert
that
it's
probably
different
than
almost
all
of
the
protocols
out
there
doing
execution
after
consensus
right
I
mean
we
really
don't
care,
we
don't
actually
know.
What's
in
the
block,
we
just
come
to
consensus
on
the
block
itself
and
not
the
contents
of
the
block
right.
B
B
B
Well,
first
of
all
by
you
know,
making
sure
that
we
have
you
know
of
working
test
net,
where
you
know
you
can
actually
test
your
code
so
that
you
know
you
don't
have
to
deploy
blind.
You
know
onto
the
live
platform
and
conceivably
in
the
future,
either
devdao
or
us
might
be
able
to.
You
know,
provide
some
tooling.
You
know
possibly
based
on
our
test
framework
or
something
like
that
that
will
enable
you
know
sort
of
at
least
some.
A
I
certainly
would
like
that
I
mean
from
my
perspective.
I
would
want
to
definitely
know
at
a
minimum
like
how
you
know
with
with
devops
you
always
test
the
performance
of
your
code
before
you
deploy
anything
to
production.
Right
and
performance
is
also
cost
like.
How
long
does
it
take
to
run
and
how
much
does
it
cost
is,
is
very
much
tied
to
that
right.
So
I
would.
A
I
would
certainly
like
to
see
it
eventually
implemented
inside
the
test
framework,
so
people
can
use
this
in
their
pipelines
and
watch
it
right
as
an
assertion
or
something
that's
costing
x
amount
of
gas
where
it
used
to
cost
y
right
as
an
example
or,
and
now
it's
costing
y
would
use
to
cost
x
to
be
more
accurate.
So
definitely
definitely
that's
important
and
yeah.
So
this
notion
of
the
gas
futures
model
it's
going
to
be
pretty
pervasive.
A
Like
you
know,
the
gas
futures
will
enable
people
to
reserve
space
in
future
blocks
right.
I
think,
up
to
six
months
and
it's
kind
of
like,
if
you
don't
use
it,
you
lose
it
model.
So
we're
definitely
looking
for
people
to
commit
to
processing
transactions
in
a
future
point.
But
the
nice
thing
is:
is
that?
Because
it's
a
future
futures
model,
you
can
actually
get
some
kind
of
guarantees
around
your
price
right,
which
is
what
we
really
promise
to
deliver
to
the
end
user
right
are
those
kinds
of
guarantees.
B
A
A
I
was
going
to
show
what
the
devdao
built,
so
we
can
talk
a
little
bit
about
the
auction,
so
one
of
the
things
that
casper
is
doing
very
differently
is
we
are,
ours
is
a
permissionless
network,
but
the
way
validators
come
and
go
is
through
this
first
price
auction
model
that
we've
built
and
basically
what
it
means
is
validators
prospective
validators
place
a
bid
in
the
auction.
They,
basically
they
compile
a
contract
and
they
place
a
bid
in
there
and
the
bid
is
basically
their
proposed
stake.
A
So
this
is
what
I
propose
I'm
going
to
be.
You
know
for
a
validator.
This
is
how
much
stake
I'm
willing
to
put
up
this
is
not
sorting
the
way
I
want
it
to
sort.
I
think
I
need
to
file
a
bug
there.
We
go
so
right
now,
there's
only
50
entries
in
the
auction,
which
is
interesting.
There
should
be
more
entries
in
the
bids.
A
B
A
B
A
I
think
we
can
definitely
iterate
on
this,
but
so
this
this
notion
of
auction,
so
we
can
actually
look
at
the
auction
contract.
Look
at
the
raw
data
source
here.
So
if
you
look
at
the
raw
data
that
serves
this
thing,
it's
get
auction
info
here.
So
these
are
the
era
validators
here.
So
this
this
information
here
invalid
in
era
237
this
will
be
the
validator
set.
It
maintains
a
three-era
rotating
set
right,
so
it'll
keep
rotating
as
new
eras
are
created,
it'll
create
you
know.
A
If
we
run
this
into
30
minutes,
you'll
see
error,
238
here
and
error.
237
will
move
up
right,
so
the
future
we're
bonding
for
future
era.
230
era.
The
current
era
is
234
right.
So
this
is
the
current
validator
set
here
is
234
okay
and
then
the
future
validators
is
in
235.
So
you
can
actually
look
and
say:
okay,
who
are
the
error
validators
in
234?
A
A
So
if
you
see
these
are
all
the
bids
that
have
been
placed
by
folks
that
are
wanting
to
join
and
you'll
see,
this
is
their
staked
amounts
here,
right
and
so
you'll.
You
may
see
bids
in
here
that
didn't
make
it
into
this
set
here's
right,
so
you
may
not
see.
Oh
you
see
2006
here
so
once
people
start
placing
more
bids
that
may
not
make
it
in
you'll
start
seeing
these
bids
appear
in
this
list
and
they're
just
waiting
for
a
slot
right.
A
A
They
will
see
their
bid
amount
increase
and
to
a
point
where
they
can
eventually
win
a
slot
in
the
auction,
and
we
really
what
we
really
want
to
do
is
we
want
to
have
you
know
this
be
as
decentralized
as
possible
and
we
really
want
to
drive
it.
You
know,
mostly
by
delegators,
you
want
delegators
to
be
able
to
choose
which
validator
they
want
to
stake
their
tokens
with,
and
we
think
this
is
a
really
important
way
for
val.
A
You
know
for
for
token
holders
to
have
a
say
with
which
validators
make
it
into
the
first
price
auction,
and
you
know
the
validators
will
be
rotated
out
pretty
immediately,
depending
on
where
they
get
their
delegated
stake
from
right.
So
the
validator
wants
to
guarantee
that
they're
going
to
be
in
the
auction.
Then
they
really
need
to
bid
a
large
amount
in
the
auction,
so
they
can
stay
in
right
of
their
own
token.
This
doesn't
really
solve
for
the
exchange
problem.
The
best
way
to
solve
for
the
exchange
problem
is
custody.
A
Your
own
keys
right,
like
keep
control
of
your
keys,
do
not
keep
do
not
keep
your
token
on
exchange,
because
the
exchange
can
actually
stake.
Your
token
and
not
give
you
any
money
back
here,
you'll
see,
the
delegation
rate
is
like
the
different
validators
can
set
a
delegation
right
like
this
validator
will
give
you
100
of
rewards.
This
validator
will
give
you
only
10
percent
of
the
rewards
right.
I
think
they
probably
intended
to
do
that
a
little
differently.
A
You
know
status
quo
right
for
people
to
get
really
good
returns
on
their
staking
any
questions
on
that
great
job
on
the
economics
of
the
chain.
At
least
I
can
say
that
right
now
we'll
see
how
it
bears
out,
but
I'm
very
pleased
because
it
took
a
little
over
a
week
to
get
to
50
validators,
so
folks
were
able
to
read
the
documentation
they
got
funded
by
other
community
validators,
so
we
don't
have
a
faucet
in
place.
Yet
so
people
were
able
to.
You
know,
request
funds
from
existing
validators.
A
A
What's
up
next,
for
us
is
we're
going
to
be
doing
the
official
launch
of
delta
test
net
next
week
we're
going
to
be
releasing
a
new
developer
portal,
I'm
recording
some
videos
and
we're
doing
some
cleanup
of
our
documentation.
So
we
can
do
a
nice
big
launch
and
we're
hoping
to
do
a
hackathon
here
with
some
incentives
in
the
november
december
time
frame.
So
lots
of
great
work
happening
so
get
engaged,
find
us
on
discord,
join
the
network.