►
From YouTube: CasperLabs Community Call
Description
Engineering update, Delgator UX, How Casper is different from Ethereum, why CasperLabs is launching a separate blockchain
A
Good
morning,
good
afternoon,
good
evening,
everyone,
wherever
you're
coming
to
us
from
my
name,
is
metta
parlikar,
I'm
the
cto
of
casper
labs,
and
today
I'm
going
to
provide
our
engineering
update,
like
we
do
every
tuesday
morning
at
this
time,
9
a.m,
pacific
daylight
time
or
pacific
time.
Let's
just
say,
pacific
time
and
we
are
live
streaming
on
youtube,
so
you
can
absolutely
catch
us
on
youtube
and
this
call
is
open.
The
community
managers
know
what
the
timings
are.
We
posted
our
telegram
channel
and
our
discord.
A
So
if
you
want
to
join
the
call
and
ask
me
anything,
you
certainly
are
welcome
to
do
that
as
well.
Just
join
the
zoom
call,
so
today
I'm
going
to
provide
an
engineering
update
and
then
we've
got
some
exciting
updates
to
share
around
our
improvement
processes
and
things
that
are
coming
up
with
respect
to
our
test
nets.
So,
and
I'm
going
to
talk
about
a
community
topic
which
is
going
to
be
the
use
cases
around
d5
and
what's
possible
on
the
casper
network.
A
So
we'll
talk
about
that
as
well,
so
we're
in
our
third
weekly
sprint
of
the
fifth
release
cycle.
His
focus
is
to
deliver
transaction
fee,
transaction
fees
and
security
features
slashing
so
we're
implementing
the
economics
portion
of
the
blockchain.
A
This
work
is
happening
in
the
rust
client
in
the
rust
node
and
we
will
be
open
sourcing
that
repo
I'm
planning
for
this
week
so
this
week.
Folks
can't
see
that,
because
it's
still
private,
but
we
have
a
brand
new
repository
here
that
is
specifically
for
the
rust
node.
This
is
a
pure
rust
implementation
of
the
casper
labs
node.
A
I
can
show
you
guys
a
little
bit
about
you
know
the
amount
of
work
that's
been
going
on,
so
we've
been
working
on
this
for
since
about
mid
april
you'll
see
the
first
commits
coming
in
here
in
may,
and
so
we
are
pretty
excited
about
the
work
that
we've
been
doing
there
and
we're
going
to
be
making
this
public
this
week
with
our
release.
So
that's
that's
some
good
news
about
rust.
A
So
let's
talk
about
what
we're
focused
on
here,
so
this
rust
node
we're
getting
ready
to
set
up
a
long
running
test
with
20
nodes
in
the
rust
network,
peer
them
up
and
start
pounding
on
them
start
sending
them
some
traffic
and
some
load
to
see
how
they
exchange
messages
to
try
to
ferret
out
some
bugs
before
we
turn
this
rust
network,
or
this
rust
node
over
to
some
of
our
validators,
so
I'll,
be
opening
up
the
the
beta
test
net
for
more
participation
and
we're
going
to
be
peeling
off
some
of
the
folks
that
have
been
working
with
us,
for
you
know,
through
the
alpha
time
frame,
to
start
running
some
of
these
nodes
here,
and
the
purpose
of
this
is
to
really
try
to
flush
out
any
issues
before
we
do
our
delta
test
net.
A
We
want
to
get
as
much
time
with
this
code
with
the
validators
as
possible,
so
we're
ready
for
mainnet
with
the
rust
node,
so
highway
focus
is
improving
error
handling.
So
this
is
around
production,
hardening
and
production
readiness
for
the
consensus
component
on
the
node
rust
side.
This
is
where
a
majority
of
the
work
is
happening.
A
We've
got
the
client
api
and
then
nodejoin
rejoin.
This
means,
if
you
have
an
intermediate
liveness
fault,
you
stop
your
node,
for
whatever
reason
you
drop
some
messages.
You
fall
out
of
sync
you're,
able
to
sync
back
up.
That's
what
nodejoin
rejoin
means:
we're
unifying
storage
for
validators
and
genesis
validators
with
active
bids.
A
I
think
I
need
some
information
on
this.
Is
this
around
basically
bonding
of
new
validators
and.
B
This
is
actually
this
is
like
an
implementation
detail.
It's
not.
I
wouldn't
really
call
it
a
feature.
It
doesn't
actually
change
anything
about
what
we
were
doing
so
far.
I
believe.
A
A
B
So
well
the
ways
that
I
wrote
the
spec.
Initially
there
were
basically
two
data
structures.
One
of
them
holding
you
know,
found
invalidators
other
one
holding
new
bidders
and
they
believe
that
mikael
just
wanted
to
unify
everything
into
a
single
data
structure
and
it
doesn't
change
any
of
the
business
logic.
A
C
C
Actually,
you
know
we,
we
use
a
pool
based
method,
because
a
number
of
delegators
can
go
up
to
like
really
really
large
numbers
for
a
single
validator,
but
we
can't
do
the
same
like
we
will
basically
iterate
over
every
validator
and
for
every
validator.
We
will
use
this
pool
based
distribution
right.
It
doesn't.
C
C
So
since
a
validator
can,
can
you
know
be
like
not
receive
any
rewards,
like
some
values
receive
rewards
some
do
not
if
they
don't
send
messages.
C
For
that
reason,
we
can't
just
pro
rata,
distribute
to
every
validator
that
prevents
us
from
just
every
like
distributing
everyone
by
their
stake,
so
we
can't
use
the
full
base
method
for
regardless
of
their
you
know,
type
in
the
system.
C
A
Yeah
got
it:
okay,
beta
test
net
monitoring
yep,
so
we
do
plan
on
bouncing
the
network
in
the
next
week
or
so
to
we're
working
on
getting
some
fixes.
A
A
We
are
building
a
self-hosted
blog
on
casperlabs.io.
The
new
url
will
be
blog.casperlabs.io.
What
you're
looking
at
right
now
on
the
public
website
is
just
an
extension
of
medium,
and
so
we
want
to
do
more
than
that.
We
really
want
to
have
you
know
our
self-hosted
blog
site,
where
our
engineers
can
also
write
articles,
because
I
think
they
have
a
lot
of
cool
things
to
say
so.
You
know
not
the
least
of
which
is
owner
and
alex
that
have
done
a
lot
of
work
around
the
economics
piece.
A
So
that's
that's
part
of
it
like
we
talked
about
the
python
client
and
then
we've
got
a
new
version
of
the
casper
lab
signer
that
we're
going
to
release
and
then
to
verify.
So
this
input
data
is
actually
the
contract
arguments.
A
A
A
A
Contract
runtime
is
mostly
feature
complete.
We
actually
have
just
approved
a
tranche
of
work
on
the
contract
runtime,
and
this
tranche
of
work
is
going
to
be
account
and
contract
unification.
Right
now,
within
the
contract
runtime
we
have
a
separate
notion
of
accounts
and
contracts.
We
will
be
unifying
this,
wherein
the
only
thing
that
the
contract
runtime
cares
about
is
accounts.
I'm
sorry
contracts
and
accounts
will
be
a
representation
of
a
contract.
A
A
A
Very,
very
cool:
we
welcome
george
otterson
to
the
team
he's
going
to
be
working
on
ecosystem
as
a
dap,
developer
and
web
developer.
We're
super
excited
about
that.
We
are
planning
on
cutting
a
few
offers
this
week.
I
hope
to
some
new
engineers,
so
we
are
hiring
so
if
you're
interested
in
working
on
the
project
as
part
of
a
core
team,
the
bar
is
very
high,
but
we
welcome
you
to
apply
there's
a
jobs
link
at
the
bottom
of
our
website.
A
It's
a
little
nondescript,
but
you
are
welcome
to
apply
and
go
through
the
interview
process.
So
o'neill's
going
to
talk
a
little
bit
about
our
casper
enhancement
process,
a
proposal
process,
and
we
should,
I
don't
know
why
we
were
going
to
call
them
clips,
which
is
casper
labs
improvement.
Proposals
on
clips
is
kind
of
nice,
but
instead
of
seps,
maybe
we
can
rename
it
later
on
as
an
improvement
as
an
improvement
for
review.
A
So
do
you
want
to
talk
about
that
on
or
briefly
I
know,
malika
has
also
some
things
she
could
we'll
say
about
that.
C
Yeah,
so
we
we
actually
last
week
we
finally
formalized
the
this
rfc
internal
rfc
process
to
migrate,
our
this,
like
a
design
process
from
confluence
to
confluence
jira,
they
all
suck
real
times,
use
git.
Sorry,
it's
opinionated,
but
you
know,
and
this
whole
design
process.
C
It's
it's,
I
think
much
better
already
when
we
have
when
we
have
the
process
on
github,
I
can.
I
can
talk
about
like
what
is
what
kind
of
design
process
we
are
already
doing
on
github
and
what's
not
in
the
scope
of
cps.
Yet
I
can
share
my
screen.
C
So
like
what
is
that?
What
is
an
rfc?
First
of
all,
it
is
just
a
process
initially
started
at
the
earlier
like
start
of
the
internet
by
by
a
committee
called
internet
engineering
task
force,
and
they
were
actually
you
know.
C
Creating
these
documents
to
you
know
outline
new
technical
improvements
to
or
certain
protocols
they
were
really
varied,
and
basically
they
want
to
initiate
discussion
and
somehow
capture
the
development
of
new
protocols
for
the
internet,
and
this
is
a
ideal
ideal
process
for
open
source
projects
which
makes
it
ideal
for
hours
I'll
just
give
some
examples.
This
is
python.
Python
has
their
own
version,
if
you
just
for
our
viewers,
they're
called
peps
for
python
enhancement
proposal.
C
So
generally,
the
first
rfc
outlines
how
how
the
rfcs
themselves
should
be
proposed
and
how
they're
accepted
amended
or
rejected.
Why
that
why?
That
would
happen?
It's
there
are
various
flavors,
depending
on
the
context.
They
were
also
starting
to
to
be
used
in
open
source
projects,
so
sorry
crypto
currency
projects,
so
this
is
rust,
which
we
based
hours
on,
I
think
also
near
base
their
rfc
process
on
rust.
C
This
is
ethereum.
Ethereum
has
been
also
doing
eips
from
the
very
very
beginning
for
ethereum
improvement
proposal.
If
you
know
they
were
also
having
like
disagreements
on
how
to
name
it.
Probably
so
that's
why
you
have
erc
for
supposedly
for
ethereum
requests
for
comments,
but
then
they
decide
to
have
like
a
single
one
called
eip
and
then
make
erc
a
sub
category
of
like
type
of
eip.
You
could
have
so
the
most
famous
is
erc20
and
that's
where
erc20
comes
from
and
now
all
like
things
like
token
standards
are
called
ercs.
C
For
that
reason,
bitcoin
has
bips
so
bitcoin
improvement
proposal.
Similarly
and
yeah
I
haven't
really
interacted
with
bitcoins,
except
for
one,
that's
really
to
see
generation
other
other
than
that.
Bitcoin
is
not
really
has
that
much
of
an
engagement
as
a
theory,
but
right
now
they're,
I
think
much
more
more
developers
in
ethereum
than
bitcoin.
C
So
let's
go
into
ours.
This
is
the
the
repo
casper
lab
cps,
so
the
most
important
thing
we
just
put
this
out
as
a
way
to
share
documents,
ideas,
technical
ideas
outline
them.
This
is
not
this
does
not
yet
capture
governance
or
like
decisions
that
could
create
contention
between
different
stakeholders
of
the
network.
So
this
is
just
like
a
log
of
our
decision
making,
and
for
that
reason
we
don't
have.
C
We
don't
have
like
an
eip
eip
like
eips,
have
different
processes
they
can
make
for
them
to
be
implemented.
They
have
to
be
accepted
by
the
chord
as
so
ethereum,
for
that
reason
has
to
define
chord,
as
has
to
like
define
different
levels
of
like
different
steps
when
an
eip
is
proposed
and
being
considered-
and
you
know
like
status
terms-
I
was
just
talking
about
these,
so
the
core
dev
has
an
power
on
whether
this
feature
will
be
a
part
of
ethereum
or
not
so
to
be
clear,
cep
is
not
like
that.
C
Yet
so
we
haven't,
we
haven't
really
charted
out
that
part
of
our
journey.
Yet
this
is
what
malika
is
working
on
on
governance,
but
for
now,
cps
are
just
for
like
sharing
and
sharing
information
and
ideas
and
building
on
them
actually
commenting
on
them.
Brainstorming
I'll
just
give
an
example.
C
So
if
you
want
to
at
this
point,
if
you
want
to
create
a
cpcp,
it
is
really
if
you
want
to,
if
you,
if
you
look
at
our
code
base
and
if
you
have
an
idea
on
how
something
should
be
improved,
you
can
just
follow
this
process.
You
can
create
you
just
fork.
The
repo,
then
work
start
create
your
own
branch
for
your
id.
C
C
If
you
know
ei
ethereum
like
like
eip
numbers
like
eip
1559,
we
would
rather
not
not
deplete
the
small
numbers,
because
eip
1022
or
like
these.
These
are
really
not
a
good
way
to
address
a
certain
change
in
the
protocol.
C
So
you
don't
have
to
open
a
pool
request.
You
can
just
interact
with
us
and
ask
if
it's
you
know,
if
you
think
it's
it's
good
or
not,
you
can
send
us
a
rendered
version.
Let
me
give
an
example.
So
the
first
ci
so
first
cp
was
about
how
cp
works.
The
second
one
is
how
we
serialize
our
data,
so
we
consider
different
different
options.
C
C
C
Now
it
works,
so
our
cvs
are
markdown
files.
We
want,
we
want
developers
to
to
have
it
easiest
way
to
contribute
to
our
code
base.
For
a
reason
we
chose
markdown,
it's
the
easiest
format
there
is,
you
can
write
code
code
blocks,
you
can
insert
images,
you
can
highlight
certain
parts.
Comment.
C
Sorry
quote
insert
quotations,
and
here
I
basically
introduced
how
how
the
on
a
lower
and
higher
level
how
the
adjustment
process
would
work
and
some
introduce
some
sorry
accounted
for
some
corner
cases.
C
You
can
see
that
people
have
reviewed
it
and
requested
changes,
and
basically
it's
it's
ongoing.
So
before
this
was
in
confluence,
it
was
closed.
Now,
now
it's
better
in
this
spirit
of
spirit
of
an
open
source
project.
You
can
see
you
can
see
how
we
developed
casper
and
how
so
the
the
the
technical
details
if
you're
interested
in
finding
out
about
it,
you
can
directly
use
this
repo
there's
also
another
one
called
casper
lab
specs,
so
cps
are
more
like
sharing
and
discussing,
and
this
is
a
reference.
C
Oh,
this
is
still
private.
So
we
will
make
this
public
at
some
point
and
then
you
will
be
able
to
see
like
the
reference
for
implementing
a
client
for
casper.
C
A
Sounds
good,
I
don't
have
any
questions,
I'm
happy
to
see
us
moving
towards
public
github.
That's
great
fabulous
and
I
noticed
we've
already
got
a
cep
from
ledger
leap
which
is
terrific.
C
A
Yep
yep,
that's
good
stuff,
so
I'm
going
to
talk
a
little
bit
about
what
the
community
wanted
to
know
about.
So
let
me
just
pause
here
for
a
second
and
get
my
notes.
A
Sorry
ethereum
has
d
phi
tazos
has
stos.
What?
U
case?
Will
you
be
targeting
when
you
launch
the
network
so
we're
a
general
purpose,
compute
platform
right
and
so
by
that
extension,
we're
not
going
to
target
any
specific,
singular
use
case?
What
I
would
say
is
that
the
casper
labs
you
know
company
as
a
large
in
terms
of
the
product
that
we've
built
our
expertise
as
a
development
team,
our
strengths
and
what
we've
built
into
the
casper
protocol
is.
A
A
We
see
it
being
more
like
10
or
15
percent
on
chain
right,
there's
a
portion
in
an
application
workflow
that
would
benefit
from
deeper
trust,
more
verified,
more,
you
know,
being
verifiably
true,
and
what
we're
building
is
a
system
that
will
enable
you
know,
applications
or
companies
to
leverage
this
trust
layer
in
their
existing
systems
in
their
existing
applications.
So
or
you
know
so,
take
a
look
at
a
company
that
may
have
already
found
product
market
fit
they've
built
a
system.
A
They've
got
product
market
fit,
and
now
they
find
an
opportunity
here
to
leverage
blockchain
technology
as
a
way
to
give
themselves
a
competitive
advantage,
incrementally
improve
what
it
is
they've
already
built
in
a
manner
that
it's
it's
meaningful
and
important
enough,
that
they
could
charge
more
for
their
service
or
acquire
more
customers,
because
there's
greater
verifiability,
there's
greater
trust,
there's
greater
certainty
around
what's
being
reported
in
the
system
right
and
that's
what
I
see-
blockchain
really
shining
in
right.
A
And
so,
if
you
look
at
a
lot
of
the
private
implementations,
that's
what's
being
used
for
right
now
and
the
reason
they've
gone
with
a
lot
of
private
implementations
is
because
they
have
greater
control
over
contracts
and
transactions.
And
you
know
immutability
is,
is
a
challenge.
Forks
are
a
challenge,
so
all
of
these
things
become
hard
for
businesses.
To
really
re
depend
on
this
technology
to
build
a
business
on.
A
A
Adapting
to
customer
needs,
adapting
to
business
conditions
and
climate
and
what's
what's
required
out
there
and
that's
what
we've
built
is
you
know
you
get
the
benefit
of
immutable
transactions
for
a
given
version
of
your
contract,
but
you
also
have
the
ability
to
version
your
contract
and
and
update
it
and
upgrade
it
through
a
governance
process.
That's
all
on
chain,
if
you
so
desire.
A
So
that's
that's.
Those
are
the
use
cases
that
we
see
there.
They're
purposely
non-specific
because
you
know
having
that
flexibility
is
what's
really
important
right.
So
we
have
a
touring
complete
system
with
contracts
and
rust
and
the
reason
we've
chosen
to
build
it.
That
way
is
you
know,
we
believe
in
extending
what
ethereum
has
already
built
right.
So
we're
not
unlike
ethereum,
but
in
a
lot
of
ways.
A
We
are
dissimilar
to
ethereum
right,
because
we
believe
that
smart
contracts
can
be
upgraded,
they
should
be
upgraded
and
we
enable
that
explicitly
within
the
system
right,
as
well
as
giving
contract
authors,
great
tools
to
manage
and
control
their
on-chain
code.
So
that's
what
we've
built
those
are.
This
applies
to
d52.
A
I
think
it
does
absolutely
apply
to
d5,
as
you
could
tell,
with
yam
being
able
to
upgrade
your
on-chain
code
is
really
really
important,
being
able
to
test
your
on-chain
code
even
more
important.
I
have
no
doubt
that
if
they
had
built
a
unit
test
suite
for
the
for
the
bug
that
they
found
in
yam,
they
would
have
been
able
to
ferret
that
issue
out
and
our
system
allows
for
that.
A
You
can
build
very
extensive
and
comprehensive
unit
tests
using
our
software
using
our
sdk,
and
that
enables
you
to
ferret
bugs
out,
which
is
hugely
important
for
defy
right.
You
can't
what
are
the
reasons
why
financial
systems
today
are
still
running
on
20
year.
Old
code
is
because
they
know
that
code
is
bug
free,
it's
been
running
for
20
years
right,
it's
been
running
for
a
really
long
time.
This
makes
it
hardened
right
and
they
have
a
lot
more
confidence
in
changing
that
out
is
kind
of
scary.
A
I
can
show
you
guys
an
example
of
if
you
go
to
our
dap
developer
guide
here
on
testing.
You
can
see
here
that
you
can
create.
This
is
a
test
file
for
the
erc20
token
contract
in
the
erc20
tutorial.
These
are
all
assertions
right.
These
are
actual
tests
that
we're
running.
So
if
we
do
the
erc20
token
test
we're
going
to
assert
that
we've
set
up
everything
correctly
in
the
contract
and
everything
is
running
correctly.
A
So
these
assertions
are
a
way
of
testing
your
contract
right
and
then
you
can
run
everything
directly
on
a
local
machine
using
cargo
test
right.
You
can
prepare
the
contract
here
and
you'll
see.
This
is
basically
our
our
testing
form
testing
structure
for
the
sdk
that
enables
the
creation
of
an
entire
test
harness
right.
So
you
build
your
contract
and
then
you
run
your
test,
so
it'll
compile
the
contract,
and
then
it
will
run
the
execution
engine.
Basically,
the
contract
run
time
directly
within
within
the
contract
runtime.
A
You
can
also
set
up
your
context,
which
means
you
can
pre-populate
the
base
or
the
starting
state
right.
So,
even
if
your
contract
is
immutable,
if
your
contract
is
part
of
a
larger
application
stuff
in
your
application
could
change
right
like
your
web
server
could
change
your
the
browser.
Could
change
the
mobile
app.
The
mobile
os
could
change.
It
could
change
the
way
your
input
is
serialized.
A
Well,
if
your
input
is
serialized
in
a
different
way,
that's
going
to
break
your
smart
contract.
How
do
you
know
that
right?
How
do
you
know
your
smart
contract
is
actually
going
to
work
correctly?
If
you
have
a
serialization
change?
Well,
the
way
you
do
that
is
you
actually
build
all
of
your
tests
and
your
base
contract
out
and
and
make
sure
that
it's
going
to
run
the
way
it's
going
to
run
even
in
a
bad
situation
right,
that's
what
testing
is
all
about.
So
here's
an
example
of
setting
up
the
testing
contracts
here.
A
This
is
basically
where
you
set
up.
Oh
I'm
going
to
name
the
token
erc20,
I'm
going
to
create
a
symbol
for
it,
I'm
going
to
define
what
the
decimals
are
and
I'm
going
to
talk
about
what
the
I'm
going
to
set
up.
This
total
supply
right,
I'm
going
to
create
three
basic
accounts.
This
is
me
setting
up
my
test
here.
A
Well,
if
you
can't
have
computers
testing
your
code,
you're,
never
going
to
be
able
to
scale
this
out,
you're
not
going
to
be
able
to
support
hundreds
of
thousands
of
users
with
your
application.
If
you
can't
support
all
their
use
cases
and
build
features
and
address
customer
requests,
all
of
these
things
are
scalability
concerns
right.
Mass
adoption
is
being
able
to
support
masses
of
people
and
in
order
to
do
that.
A
Well,
the
first
and
foremost
thing
you
need
to
be
able
to
do
is
build
and
improve
your
code
without
introducing
new
bugs,
and
this
is
how
you
do
it
right.
This
is
a
very
foundational
thing.
This
is
table
stakes.
I
would
have
never
chosen
a
protocol
or
platform
to
build
on
if
I
couldn't
test
my
code
automatically
using
computers
themselves.