►
From YouTube: CasperLabs Community Call
Description
Engineering update, Roadmap update, Solidity support plan
A
A
All
right,
so
the
team
is
welcome
to
the
status
call.
We
are
pleased
that
we
released
node
0.20
last
week,
the
team-
this
is
a
long
time
coming.
This
had
a
lot
of
work
around
contract
headers,
which
basically
allowed
the
creation
of
multiple
entry
points
for
smart
contract.
This
is
kind
of
table
stakes
right,
like
you
need
to
be
able
to
specify
how
your
contracts
can
be
called
in
an
intuitive
and
easy
way.
A
And
we
deployed
the
code
to
the
test
net
cut.
The
packages
deployed
the
code
to
the
test
net.
We
are
troubleshooting
a
problem
in
testnet
right
now.
It
has
to
do
mainly
with
clarity
and
or
the
clients
it
has
to
do
with
the
multi-key
functionality.
So
the
team
is
actively
troubleshooting
that
issue
right
now.
If
you
attempted
to
do,
deploy
and
hit
a
snag,
that's
what
that
is,
we'll
probably
figure
it
out.
A
We
have
an
idea,
we're
chasing
down
the
problem
and
I
suspect
it
might
be
around
the
python
client,
which
is
what
clarity
uses,
so
it
has
to
do
with
the
multiple
key
types
right.
We
supported
added
support
for
ethereum
key
types
as
well
as
sec,
p256r1
and
our
ed25519
keys
and
in
the
process
of
hashing
those
keys.
There's
something
went
sideways
on
that,
so
we're
working
on
it
should
have
a
fix
out
shortly,
we'll
cut
whatever
packages
we
need
to
do
and
update
whatever
documentation.
We
need
to
do
to
get
that
working.
A
We
are
going
to
launch
the
test
net
for
the
beta
portion
of
the
program,
we're
going
to
try
to
target
this
week
for
that,
I'm
in
touch
with
validators
over
this.
So
if
you
want
to
participate
in
the
test
net
go
through
the
process
and
sign
up,
you
can
find
the
instructions
on
github
under
you
know,
connecting
your
node
to
the
test
net
sign
up,
get
your
node
provisioned
shoot
me
a
an
email
or
a
dm,
and
let
me
know
your
note
is
ready.
We
will
check
your
queer,
we'll
query
your
status
endpoint.
A
If
your
status
endpoint
looks
good
like
you've,
synced
up
your
node
and
you
are
synced
up
with
the
current
test
net,
then
we'll
go
ahead
and
include
your
public
key
in
the
genesis
block.
When
you
bounce
the
network,
there
are
limited
number
of
seats
available
for
right
now,
we'll
be
opening
up
more
slots
in
about
four
weeks,
we're
going
to
be
spinning
up
an
experimental
network
for
the
rust
node.
That's
going
to
be
a
lot
of
fun,
we're
going
to
be
looking
for
validators
that
really
want
to
hack
and
work
closely
with
us.
A
It's
going
to
be
a
lot
of
work
working
with
the
rust
node,
but
again
there
are
incentives
to
do
so.
We've
got
lots
of
incentives
as
part
of
the
test
net
program,
so
we
would
be
happy
to
welcome
validators
that
want
to
work
closely
with
us
and
hack
on
that
rust
node
for
us,
so
we're
getting
ready
to
set
up
the
preliminary
five
node
network
in
lrts
this
week,
and
this
is
basically
accepting
gossip,
deploys
and
support
some
basic
queries.
We've
got
the
chain
spec
implemented.
A
The
intention
is
that
the
rust
chain
spec
will
work
exactly
the
same
as
the
scala
chain.
Spec-
and
you
know
in
this
this
network
that
validators
can
join
at
genesis.
Only
so
same
thing.
We've
got
going
right
now.
A
So
highway
we're
working
on
the
test
framework
and
then
they
want
to
do
a
test,
driven
development,
type
of
scenario,
basically
mechanism,
so
they're
working
a
lot
on
the
test
framework
right
now
and
they've
got
the
quorum
size
calculation
in
place
for
senior
edge
senior
edges
your
what
you
call
your
block
rewards
and
we've
also
got
we're
laying
down
the
pipeline
pipe
for
auto
adjustment.
A
So
the
first
round
of
the
node,
the
rust
node,
is
going
to
be
significantly
more
feature
complete
than
the
current
scala
node
right
and
we're
doing
this
because
bringing
everything
together
is,
you
know,
going
to
give
us
a
very
feature
complete
network,
and
this
is
in
preparation
for
delta
test
net.
The
delta
test
net
will
use
the
rust
node
we're
also
doing
the
final
work
of
the
bonding
auctions.
This
is
how
validators
will
join
the
validator
pool.
A
There
will
be
this
notion
of
a
bonding
auction,
it'll
be
an
open
auction
and
basically
validators
will
submit
the
amount
they
intend
to
bond,
so
they
can
join
into
the
network,
and
this
will
also
include
delegated
stake
from
users.
So
the
intention
is
that
there'll
be
full
user
participation
based
on
who
you're
going
to
bond
your
net.
Your
your
token,
with.
A
We
need
to
get
our
metrics
going
for
network
metrics,
so
we're
going
to
actually
look
at
some
contract,
runtime
metrics.
I
actually
want
to
know
how
many
deploys
we
have
in
the
global
state
like
how
many
deploys
we're
processing
how
many
stored
contracts
we
have.
There
are
questions
we
want
to
know
have
answers
to
around.
What's
going
on
in
the
internal
run
time,
and
those
are
the
metrics
that
ashoka's
talking
about
here,
who
implemented
the
auction
within
within
the
rust
node,
and
then
we've
got
to
document
the
node
api.
A
The
contract
runtime
is
feature
complete.
Ashok
is
not
on
this
call.
I
don't
see
him
okay,
so
I
just
talked
with
ed
today,
hot
off
the
presses.
We
are
going
to
be
adding
some
additional
features
into
the
contract.
Runtime,
we'll
probably
start
those
in
august.
A
The
work
is
really
really
it's
really
cool
and
exciting.
So
I
think
I
can
talk
about
this,
because
this
is
something
that
we
want
to
do
so
one
of
the
things
in
the
contract
runtime.
We
have
right
now
we
have
two
separate
notions.
We
have
this
notion
of
account
and
we
have
this
notion
of
contract
and
what
we're
going
to
do
is
we're
actually
going
to
simplify
the
notion
we're
going
to
we're
going
to
remove
this
separation
right.
A
So
what
we're
going
to
do
is
basically
say:
accounts
are
a
type
of
contract,
and
this
is
a
very
natural
evolution
of
the
contract
run
time.
It's
not
going
to
really
change
the
you
know.
At
present
we
have
a
good
idea
of
what
the
design
will
look
like.
It's
not
really
going
to
change
how
the
system
will
work.
I
mean
change
the
semantics
of
contracts
right,
so
you'll
still
have.
The
notion
of
this
account.
A
A
You
know
what
it
is
we're
building
and
why
it's
important
is
I
I
came
to
realize
that
all
software
needs
to
be
governed.
All
software
today
is
governed.
I
worked
at
avalaire
sales
tax,
those
of
you
that
know
about
me.
You
know
that
I
worked
at
this
company
and
this
company
does
a
lot
of
compliance
work
for
businesses
right
and
so
when
we
would
publish
a
sales
tax
update.
A
Each
of
those
tax
rates
had
implications
the
company
in
the
tune
of
millions
and
millions
of
dollars
right,
if
I'm
like
doing
grocery
store
sales,
and
I
sell
millions
of
dollars
worth
of
soda
every
month
in
a
particular
state,
and
the
state
puts
out
a
compliance
update
that
changes
the
tax
rate
for
soda.
If
that
tax
rate
is
wrong,
my
company
faces
millions
of
dollars
of
liability,
because
that
calculation
is
incorrect,
and
so
internally
at
avalara
there
was
a
very
tight
governance
process
that
we
had
around.
Releasing
those
those
updates.
A
Those
are
what
we
call
statutory
updates
and
their
content
team
had
a
rece.
You
know
team
of
lawyers
that
would
put
out
that
research
every
month
and
there
was
a
very
clear
and
tight
set
of
rules
around
how
the
research
was
performed.
What
kind
of
backup
we
had
for
each
of
the
research,
how
we
cited
that
back
up
how
the
research
was
conducted?
Who
made
the
changes?
A
We
had
to
go
through
very
stringent
ssae
audits
to
make
sure
that
the
that
only
the
person's
authorized
to
make
those
updates
made
the
updates,
the
software
that
all
had
to
be
traced
through
very
very
strict,
had
to
be
very
transparent,
because
our
customers
wanted
to
actually
see
the
backup
for
that
research.
A
It's
very
similar
right
and
that
had
this
revelation
that
well,
what
we've
actually
built
is
a
governance
tool
for
software
for
the
blockchain
on
the
blockchain
on
chain
right,
so
software,
any
software
updates
needs
to
be
closely
governed.
It
needs
to
be
transparent,
it
needs
to
go
on
chain,
it
needs
to
be
secure
and
that's
what
we've
built
at
casper
labs.
We
have
built
tooling
at
the
protocol
level
that
enables
the
governance
of
software
updates.
A
It
allows
for
software
to
be
updated
and
it
allows
for
the
software
to
be
updated
and
governed
on
chain,
and
this
is
really
important.
The
more
I
think
about
this,
the
more
important
it
becomes,
and
so
one
of
the
changes
that
we're
going
to
implement
is
we're
going
to
provide
the
ability
for
contracts
to
change
the
upgrades
and
updates
of
contracts
to
be
governed
with
things
like
multi-signature
right.
A
So,
if
I
want
to
push
out
a
contract
upgrade,
I
can
specify
a
certain
number
of
individuals
that
have
signatory
rights
to
govern
that
contract
and
upgrade
that
contract
right,
and
this
goes
much
much
be
much
beyond
the
weighted
keys
right.
So
those
of
you
that
know
features
about
casper
labs.
You
know
that
we
support
account
delegation.
We
support
weighted
key
management.
We
support
you,
know
n
multi
signature
right,
so
you
can
do
a
multi
signature
with
weights
and
you
can
also
separate
permissions.
A
You
know
the
assignment
of
permissions
from
the
actions
on
account
such
as
deployments,
and
this
change
in
the
execution
engine
in
the
contract
run.
Time
will
basically
provide
the
same
functionality
for
contracts,
and
so
what
that
means
is
when
I
want
to
push
an
update
to
a
contract,
I
can
actually
wrap
that
in
a
multi-signature
piece
of
functionality,
and
so
then,
because
accounts
will
also
be
contracts.
A
So
if
you
imagine
any
of
these
contracts
that
lock
up
token
in
d5,
these
contracts
can
now
stake
those
tokens
with
validators
and
they
don't
necessarily
need
to
run
a
validating
node.
To
do
this,
they
can
just
delegate
their
stake
to
validators.
Now
it's
not
clear
to
me
if
they
have
to
delegate
the
purse
to
a
single
validator
or
if
they
can
spread
it
across
multiple
validators.
A
We
still
have
to
figure
that
out,
but
I
think
this
is
pretty
revolutionary
because
it
enables
what
it
will
give
greater
yields
to
d5
contracts,
but
also
it
enables
d5
contracts
to
basically
have
a
source
of
revenue
right
that
they
can
use
and
fund
their
operations.
A
They
don't
right
now
they
do
that
by
introducing
their
own
token,
but
now
they
would
basically
be
able
to
even
do
that
within
the
native
clx
token
or
the
native
casper
token.
So
this
is
something
that
I
just
talked
to
ed
about
today.
We
believe
we'll
take
the
work
on
in
september.
A
There's
a
lot
of
work
to
get
done,
so
the
team
is
very,
very
commit,
like
there's
a
lot
of
commitment
right,
a
lot
of
work
committed,
and
so
everybody
is
really
really
head
down,
but
ed
is
quite
confident
that
he
thinks
we
can
get
this
done
in
the
september
time
frame.
We
would
want
to
do
it
when
we
crack
open
the
execution
engine
to
do
all
the
proof
of
stake.
Changes
right.
This
would
go
along
with
the
proof-of-stake
changes.
A
A
When
I
do
I'm
going
to
be
doing
a
talk
at
the
d5
conference
with
draper
golden
horn
and
I'll
be
talking
about
it
in
a
private
press
release,
so
I'm
working
on
my
d5
slides
for
that
right
now,
we're
working
with
validators
getting
ready
for
the
beta
test
net
launch
those
of
you
that
signed
up
look
for
an
email
from
me.
If
you
don't
get
an
email
from
me
ping
me.
A
Let
me
know
I'm
managing
this
manually,
I'm
looking
to
put
this
into
a
tool,
so
I
can
manage
this
more
holistically
and
comprehensively
and
there
are
a
limited
number
of
slots.
So
if
you
don't
get
in
in
this
round,
don't
be
disheartened,
we'll
be
opening
up
more
slots
later
and
also
we
have
incentives
for
adapt
development.
We
have
a
lot
of
tooling
to
build
around
the
ecosystem,
so
there's
great
opportunities
for
you
to
participate
in
the
test
net
by
building
something
to
and
and
basically
putting
some
pressure
under.
A
A
We
also
have
a
dsl
that
we've
released
that
will
make
smart
contract
authoring
a
lot
simpler.
The
dapp
developer
guide
has
been
updated
with
information
on
how
to
use
the
dsl.
The
solidity
transpiler
also
uses
the
dsl
as
well,
so
you
generate
an
account
that
gives
you
the
dsl.
The
dsl
really
gives
you
the
contract
header
functionality.
It
makes
it
very
very
easy
to
implement
contract
headers.
A
We
put
our
specification
on
each
research
for
the
auto
price
stability.
We
want
to
contribute
to
ethereum
research.
We
see
ourselves
as
being
born
from
ethereum
research
and
giving
back
is
something
we
like
to
do
so.
That's
something
that
o'neire
posted
to
eth
research
go
check
that
out.
I
have
the
link
for
that.
Perhaps
I
should
put
that
in
here.
Let
me
do
that
right
now,.
B
A
We've
also
got
alternative
auction
slot
number
adjustment
mechanisms,
so
this
is
about
how
we
slowly
increase
the
number
of
auction
slots.
One
thing
I
don't
think
we
want
to
do
is
we
don't
think
we
ever
want
to
decrease
it?
If
anything,
the
auction
slot
size
would
stay
the
same
but
never
go
down.
A
A
I'm
also
open
to
having
hands-on
sessions
with
validators
this
wednesday
at
ten
o'clock
and
four
o'clock
pacific.
If
you
want
that
time
shoot
me
a
dm
and
discord
or
in
or
just
shoot
a
note
in
discord
or
in
telegram,
and
let
me
know
that
you're
interested
and
we
can
make
that
happen.
A
A
The
reason
for
that
is
we're
going
to
go
into
our
delta
test
net
in
about
the
october
time
frame
september
october
time
frame
we're
going
to
be
doing
a
preliminary
network
with
the
validators
in
august
september,
as
I've
indicated
we're
going
to
peel
off
some
of
the
validators
in
the
program
and
have
them
start
working
with
the
rust
node.
We
believe
we're
going
to
need
at
least
five
to
six
months
with
that
rust
node
to
make
sure
it's
stable,
we're
going
to
want
to
attack
it.
A
We're
going
to
want
to
do
we're
going
to
do
performance
testing
there's
a
lot
of
work
to
that
needs
to
go
in.
I
talked
about
the
node,
I'm
sorry,
the
rust
smart
contract
work
right
now
to
support
defy
and
better
governance
of
contracts.
We
also
want
to
implement
check
pointing
and
passing
of
state
to
peers.
This
is,
this
is
a
big.
This
is
a
big
piece
of
functionality
here
when
we
talk
about
passing
state
to
peers.
A
This
means,
if
you
want
to
join
the
network,
you
can
join
the
network
from
the
latest
checkpoint
versus
having
to
start
from
genesis.
Anybody,
that's
kind
of
had
to
spin
up
a
full
node
understands
what
it
means
to
run
through
all
the
events
from
genesis
to
get
synced
up.
But
what
we're
going
to
do
is
give
you
a
fast
path
to
that
and
that's
basically
like
you
could
have
support
for
a
light,
node
right
and-
and
we
think
it's
pretty
essential
to
have
that
at
main
net
launch.
A
So
this
is
what
we're
looking
at
we're.
Definitely
looking
at
q4
2020
for
mainnet
launch
any
questions.
I
see
some
things
in
the
chat
here.
Marco
had
a
question
about
the
work.
Does
an
impact
launch?
I
don't
believe
it
impacts
launch.
It
is
more
work.
A
B
Yeah,
sorry,
if
I
missed
the
meta
you,
you
were
talking
about
your
experience
in
the
past
and
how
important
it
is
to
have
a
a
compliance
system
involved,
and
then
you
transition
that
into
what
what's
happening
in
casper.
In
this
context,
I
didn't
quite
follow
that.
Is
there
any
documentation
on
that.
A
Yeah,
so
there's
not
documentation
on
that.
So
my
thinking
I
was,
I
was
kind
of
just
you
know-
free
range
thinking
here
about
it
right.
So
from
my
perspective,
I
believe
that
all
software
updates
are
governed
in
some
manner
or
another
in
any
company
in
any
company
that
that
has
software
as
a
main
product.
All
product
releases
are
governed
right,
there's
a
very
strict
governance
process
for
any
product
release
in
a
in
a
company.
The
difference
is
it's
centralized
right,
there's
centralized
processes.
A
Sometimes
these
product
decisions
go
up
to
the
board
level
if
they're
a
big
pivot
that
the
company's
making.
But
my
point
is
that
all
software
products
are
governed.
I
talked
about
you
know
my
experience
at
avalara,
where
they
had
to
be
governed
and
transparent,
because
customers
had
a
very,
very
strong
economic
stake
in
the
outcome
of
those
right.
There
was
real
economic
penalties
in
terms
of
their
compliance
and
internally
at
avalara
we
had
a
very
tight
governance
process
and
it
was
it
was.
A
It
was
not
elegant
right,
but
there
was
a
process
right.
So
there
was
a
mechanism
by
which
these
things
are
governed.
When
I
dovetail
that
into
casper,
what
we
want
to
do
at
the
protocol
level
is
provide
the
necessary
tooling
such
that
those
apis
and
those
features
at
the
protocol
level
can
be
used
by
a
adapt
developer,
a
company
organization
to
build
on-chain
governance
for
their
contracts
right.
So
when
I
upgrade
a
contract,
there's
a
way
for
me,
even
as
a
stakeholder
to
observe
who
signed,
who
authorized
the
upgrade
of
that
contract.
A
What
what
did
the
upgrade?
Look
like?
It's,
it's
separate
from
the
entire
piece,
that's
upstream
from
that
right.
So
the
upstream
pieces
are
your
entire
improvement
proposal
process
and
how
that
all
happens,
but
you
could
theoretically
even
do
those
on
chain
if
you
wanted
to
because
we
have
tools
like
you
know,
weighted
keys
and
multi-signature,
where
you
can
build
a
very
rich
governance
process
using
the
tools
using
the
blockchain
tools.
Does
that
make
sense.
B
A
Yeah,
of
course,
yeah,
but
from
my
perspective
I
had
this
insight
a
long
time
ago.
You
know
very
early
on
when
we
were
developing
the
roadmap
and
the
the
feature
the
core
feature
set
for
for
the
casper
protocol,
and
this
was
the
intuition
that
I
always
had
that
you
have
to
provide
tooling
for
the
governance
of
on-chain
contracts
right
all
of
the
contract
code.
A
All
software
is
governed
and
that
we
have
to
include
the
tooling
and
the
capability
for
adapt
developers
to
really
govern
their
on-chain
code
because
they're
it
and
it
has
to
work
very
seamlessly
with
all
the
off
chain
code
that
goes
into
right.
There's,
like
tens
of
billions
of
dollars
worth
of
software
that
runs
and
powers
the
world.
Today,
it's
not
realistic
to
expect
that
this
is
all
going
to
be
rewritten
in
a
day.
It'll
it'll
happen
incrementally
and
through
that
process.