►
From YouTube: CasperLabs Community Call
Description
Engineering update, Roadmap update, Solidity support plan
B
A
All
right,
I'm
metta
parlikar,
I'm
the
cto
of
casper
labs
and
I'm
here
to
present
our
update
for
this
week.
It
is
already
july
21st
hard
to
believe
already
well
over
halfway
through
the
year.
It's
been
a
crazy
2020..
I'm
happy
to
have
a
lot
of
folks
on
the
call
today.
So
this
is
kind
of
cool,
usually
it's
myself
and
a
few
folks.
So,
looking
forward
to
interesting
dialogue
today,
gonna
kick
off
with
engineering
status.
I'm
gonna
share
my
screen
and
we'll
dive
right
into
it.
A
All
right,
so
we
are
cutting
release.20.
Today,
I'm
really
excited
about
this
release.
This
release
brings
to
bear
contract
headers,
and
this
rounds
out
the
last
big
chunk
of
functionality.
We
wanted
to
support
for
smart
contract
developers.
It's
really
a
table
stakes
kind
of
feature.
This
brings
the
contracting
interface
basically
up
to
par
with
ethereum
and
other
smart
contracting
interfaces
out
there.
Contract
headers
also
enables
the
contract
upgrades
functionality
that
comes
with
it,
we'll
be
dropping
a
release.
Announcement
probably
later
this
week
or
early
next
week.
A
Monday
is
a
really
good
day
to
drop
these
announcements,
so
we'll
be
announcing
it
publicly.
On
monday,
we're
also
bouncing
the
test
net
tom
just
sent
out
the
new
accounts.csv
and
manifest.toml
for
the
new
genesis.
That'll
start
tomorrow.
A
So
then
the
network
will
be
up
to
you
know
basically
there's
a
compatibility
issue
right,
so
we
can't
release
cargo
crack
casper
labs,
which
is
the
smart
contracting
interfaces
and
the
new
execution
engine
without
updating
the
test
net,
because
we
want
folks
to
have
a
seamless
experience,
so
you
build
your
contracts
using
contract
headers,
and
then
you
can
deploy
them
to
the
test
nets.
So
by
tomorrow
we
should
be
all
up
and
running
and
in
sync,
very
exciting:
release
with
this
release.
A
We're
going
to
be
kicking
off
our
beta
program,
we're
talking
to
a
few
big,
staking
pools
right
now
about
joining
the
beta
and
so
we'll
probably
bounce
this
network
in
another
couple
of
weeks
to
to
basically
increase
the
validator
set
size
right.
We
want
to
increase
the
validator
set
size
to
50
in
this
next
round,
so
I
think
we're
running
at
about
25
validators
right
now,
so
we're
basically
going
to
double
the
validator
set
size.
A
So
those
of
you
that
signed
up
to
be
a
validator
in
the
network
and
didn't
get
a
chance
to
be
a
validator
expect
to
receive
an
email
from
us
informing
you
of
your
participation
in
the
network
in
the
next
three
to
five
days,
and
then
you
should
start
priming
your
notes
and
get
ready
and
we'll
start
getting
ready
to
onboard.
You
should
be
pretty
easy
now
that
the
instructions
are
kind
of
locked
and
loaded.
I've
even
published
those
to
github.
A
A
It's
been
very
stable,
18
days
without
issues
we
bounce
the
network,
really
because
this
is
a
forking
change
and
we
don't
have
protocol
upgrades
working
as
yet
that's
going
to
come
in
later
in
the
project
plan
and
I'll
talk
a
little
bit
about
that.
When
I
discuss
the
roadmap,
we're
getting
we're,
building
the
rust
node
right.
So
for
those
of
you
that
have
been
following
us
closely,
you're
aware
that
we
are,
we
are
architecting
the
node
container,
fully
in
rust.
A
B
A
Yep,
so
we've
got
the
chain
spec
implemented,
so
the
genesis
process
with
the
rust
node
is
going
to
be
exactly
the
same
as
it
is
with
the
scala
node.
We
really
like
this
genesis
process.
It's
been
extremely
smooth,
and
so
we
basically
implemented
that
verbatim
in
rust,
so
the
new
chain
spec,
has
been
implemented
and
validators
can
only
join
at
genesis
right
now.
We
are
still,
we
still
have
to
implement
bonding
and
unbonding.
That's
going
to
happen
later
on
which
I'll
share.
A
When
I
go
over
the
roadmap,
so
current
focus
on
highway,
we're
adding
more
tests
in
the
integration
test
framework
for
highway
core
and
quorum
size
calculation
for
seniorage.
So
this
basically
talks
about
how
many?
If
you
recall,
we
have
a
medium
post
that
goes
over
a
cartel
senior
age
program
that
that
is
part
of
highway,
and
this
is
the
quorum
that
goes
into
finalizing
blocks.
We
talk
about
a
quorum
who
are
the
validators
that
voted
on
a
given
set
of
transactions
to
finalize
them.
This
is
the
quorum.
A
This
is
the
quorum
that
gets
seniorage
for
participating
in
finalizing
that
block
on
the
node
rust
initial
implementation
of
bonding
auctions.
So
the
way
bonding
auctions
are
going
to
work
is
that
we'll
have
a
certain
number
of
slots
that
the
protocol
will
it'll
decentralize
over
time
in
a
manner
similar
to
like
the
bitcoin
algorithm,
where
we'll
eventually
get
to
a
max
validator
set.
But
that
will
happen
over
a
period
of
time
algorithmically.
A
We
don't
really
want
to
be
actively
involved
in
governing
how
many
validator
slots
are
available
in
bonding
auctions,
so
it'll
it'll,
it'll,
probably
decentralize
over
time,
but
there
will
be
some
accommodations
for
the
user
experience
right.
So
we
want
to
get
to
a
nice
consistent
time
to
finalization
or
latency
to
finalization,
and
that
is
basically
inversely
proportional
to
the
number
of
validators
in
the
validator
set
right.
A
So
there's
a
relationship
between
how
how
large
the
validator
set
size
is
and
how
quickly
you
can
finalize
blocks,
and
so
that
is
that's
how
the
bonding
auctions
will
work
implementation
of
vertices
and
deploy
fetcher.
If
I
recall
correctly,
what
are
the
vertices
ashok?
That's.
A
It's
a
non-solid
network,
okay
and
note
on
the
network.
Okay,
we
should
just
call
of
that
so
people
that
are
reading
this
understand
that
it's
basically
a
node,
and
so
this
talks
about
deploy
fetching
is
the
gossiper
deploy
gossiping
or
is
this
something
different.
A
Got
it
okay
and
then
moving
global
state
to
the
storage
component.
Talk
to
me
a
little
bit
about
what
this
is.
I
think
I
need
more
detail
on
this,
so
I
can
read
it
off
more
clearly.
B
Okay,
okay,
so
this
is
basically,
we
actually
made
a
unified
storage
component,
where
we
have
different
types
of
storage
kind
of
combined
in
the
same
architecture.
B
This
is
this
is
moving
currently
that
the
global
state
was
not
moved
as
part
of
that.
So
this
is
this
is
the
remaining
work
of
that
storage
class
bit
of
remaining
work
of
the
storage
component.
A
Got
it
okay,
so
I
can
distill
this
down
for
folks.
So
if
you
recall,
before
we
had
a
scala
and
rust
implementation
right,
so
one
of
the
big
problems
we
discovered
is
that
the
scala
co
based
bone
storage
and
the
rust
code
base
needed
its
own
storage
right
and
the
rust
code
base
was
primarily
the
execution
engine
and
within
it
we
had
what
we
call
the
state
try
and
that's
known
as
the
global
state
right.
That's
the
like
current
state
of
your
contracts,
whereas
the
block
storage
was
the
linear,
blockchain
right
or
the
linear
dag.
A
If
you
want
to
call
it
the
block,
dag
and
so
these
in
the
split
architecture.
These
are
in
two
separate
literally
two
separate
database,
architectures
right
and
so
now
what
we're
doing
is
because
it's
a
single
rust
node.
We
can
basically
combine
these
two
into
a
single
storage
architecture,
and
so
what's
being
described
here
is
we've
already
built
the
deploy
store
and
the
block
store
architecture.
We
have
a
basic
database
architecture
for
those.
A
I
believe
this
is
all
lmdb
rust
unless
I'm
mistaken
ashok
and
what
we're
going
to
be
doing
is
now
we're
going
to
move
the
global
state.
Try
into
this
same
storage
architecture,
so
basically
you'll
have
a
single
database
instance
in
the
node
architecture
and
it'll
have
several
database
tables.
One
of
the
tables
will
be
your
state.
Try
your
global
state
store
and
that'll,
be
the
same
architecture
as
a
state.
A
Try
and
then
the
other
two
databases,
one
will
be
your
deploy,
store
and
another
one
will
be
your
linear
block
store,
if
I'm,
if
I
think
correctly
and
so
right,
and
so
then
you
can
reference
the
single
database
architecture.
This
will
enable
a
lot
of
really
interesting
features
later
on
that
were
not
possible
on
the
scala
code
right.
A
This
is
one
of
the
reasons
like
this
was
a
really
hard
decision
for
me
to
make
you
know
deciding
to
take
on
building
the
rust
implementation,
but
I
saw
like
from
my
experience
that
building
more
interesting
features
later
on
downstream
was
going
to
be
increasingly
increasing,
more
more
more
and
more
difficult
with
the
split
architecture.
So
we
decided
to
take
on
this
tranche
of
work
to
build
a
clean
architecture
in
rust,
documentation
of
the
node
node
api.
A
Okay
sounds
good.
The
scala
node
we're
only
going
to
be
fixing
any
bugs
reported
on
the
test
net
and
then
we'll
be
taking
feature
enhancements
coming
in
from
feature
feedback,
which
is
a
core
goal
of
the
beta
test
net
is
to
get
feedback
on
the
smart
contract
interface
and
those
will
be
implemented
in
the
contract.
A
Test
and
sre,
of
course,
publishing.20.
That's
already
done
and
updating
the
test
net
we're
going
to
restart
with
the
additional
five
validator
validators
and,
of
course
they
are
also
doing
their
lrt
testing
and
rust.
Node
orchestration
right
so
getting
ready
to
have
all
the
lrts
and
test
net
support
for
the
rust
node,
so
they're,
building
all
the
ansible
roles,
etc,
etc.
All
terraform
all
that
stuff
out
for
the
rust
node,
so
we're
ready
to
go
when
the
rust
architecture
is
ready.
A
Of
course,
it's
also
monitoring
all
the
monitoring
infrastructure
needs
to
be
built
as
well
for
the
rust
node,
but
it's
going
to
be
very
similar
to
the
metrics
architecture.
We
have
right
now
in
scala,
so
be
very
similar
ecosystem.
I'm
really
excited
about
this
smart
contract
dsl,
including
a
tutorial.
Yours
truly,
is
writing
all
the
tutorial
documentation,
but
this
rust
con
smart
contract
dsl
is
really
kind
of
sweet.
A
I
actually
have
my
c
line
up
and
running
I'll
show
you
guys
a
c
line.
What
what
it
looks
like
running
with
the
smart
contract
sdk
and
the
basically
the
macros
I'll
show
you
that
and
the
macros
are
the
smart
contract.
Esl
really
simplifies
building
smart
contracts
a
lot
because
it
takes
care
of
all
the
boilerplate
code,
released
the
casper
lab
signer
version
0.03.
What's
in
that,
ashok.
B
Basically,
the
the
key
management
part
which
which
wasn't
there
earlier.
So
that's
what
is
getting
in.
B
C
A
Right
and
we
discovered
ironically
on
macs,
which
I'm
a
mac
user,
the
files
are
stored
as
dot
key
files.
So
whenever
you
tried
to
open
the
file
it
kept
trying
to
open
up
keynote,
gotta
love
that
so
what
we
did
is
now
you
basically
just
specify
file
path.
Is
that
correct?
You
specify
file
path
and
you
just
open
the
file
directly
into
the
signer,
and
so
you
don't
have
to
deal
with
the
key
at
all.
A
You
do
need
to
know
where
the
f,
where
the
file
is
stored,
so
I
trust
that
eventually
it'll
get
to
a
place
where
you
can
generate
your
keys.
Ideally
within
the
signer
itself.
That's
much
more
like
a
meta
mask
type
interface.
We
definitely
want
to
get
to
there
to
where
you
don't
necessarily
need
to
even
do
them
within
clarity
right.
So
it's
just
a
much
more
seamless
experience
and
and
users
don't
have
to
fret
and
fuss
with
the
keys.
So
that's
actually
already
released.
It's
already
in
the
chrome
store.
A
Great
support
for
solidity,
we're
building
a
transpiler
for
the
casper
platform.
I
will
talk
about
this
in
detail.
The
community
has
asked
for
a
detailed,
deep
dive
into
that,
so
we'll
talk
about
that
in
addition
to
roadmap
and
then
implement
all
cl
types
in
clarity
under
deploy
contracts.
So
this
enables
you
to
specify
is
this
for
arguments.
This
is
for
the
arguments
right,
ncl
type,.
B
Yeah
this
is
this,
is
you
know,
result
of
one
of
the
issues
that
you,
if
you
remember,
one
of
the
developers
wanted
to
create
a
contract
and
he
was
struggling
with
fixed
list
versus
a
list
yep.
A
Yep
so
important
thing
to
note
is
that
arguments
can
be
typed
and
with
contract
headers.
You
can
actually,
once
you
specify
the
type
of
your
argument.
You
can
name
the
arguments,
then
you
can
send
the
arguments
in
any
order,
because
now
the
contract
header
functionality,
because
you
can
it
will
allow
you
also
to
specify
multiple
endpoints
into
your
contract.
So
you
can
specify
function,
entry
points
as
well
as
the
main
entry
point
for
your
contract.
You
can
also
specify
not
just
the
argument
types
but
also
the
names.
A
A
A
Yep
economics:
we
continue
to
research,
auto
price
specification
and
we're
going
to
build
that
into
the
econ
paper.
This
is
price
stabilization
and
building
the
simulator.
For
that
our
weekly
workshops
do
join
us.
We
have
more
forward
folks
engaging
on
thursday
and
fridays.
This
is
where
you
can
get
help
on
smart
contract
development
if
you're
building
something
on
the
casperlas,
blockchain
and,
of
course,
the
beta
test
net.
We
do
have
developer
credits
available,
so
you
can
get
rewards
for
building
dapps
and
deploying
them
to
the
beta
test
net.
A
So
do
sign
up
as
adapt
developer.
We
should
make
sure
that
the
signup
form
also
makes
space
for
dap
developers
to
ashok.
So.
A
To
happen,
they
will
still
need
a
pri,
a
public
key,
that's
where
they
will
deploy
their
daps
and
get
their
rewards.
So
the
process
isn't
isn't
that
different,
but
the
outreach
will
be
different
for
them.
A
Welcome
khan
to
the
team
he's
going
to
be
working
on
our
website
and
later
on,
help
on
abner
as
a
full
stack,
smart
contract
developer.
So
welcome
to
the
team
he
actually
reached
out
to
us
on
discord.
So
I
love
it
when
we
find
people
from
the
community
all
right,
I'm
going
to
go
into
I'll
start.
First
with
the
solidity
work
and
then
I'll
go
into
road
map
how's
that
sound.
A
All
right,
so
we
decided
we
got.
We
got
a
request
coming
in
from
some
of
the
community
in
terms
of
looking
at
a
way.
We
could
support
solidity
and
we
sat
back
and
we
took
a
look
and
we
thought
about
where
are
most
of
the
early
adopters
in
blockchain,
and
we
kind
of
had
to
get
zen
about
the
fact
that
a
lot
of
early
adopters
of
blockchain
are
familiar
with
solidity
and
then
we
said
well
we're
not.
A
You
know:
ethereum
applications
on
the
casperlast
blockchain,
and
so
we
came
away
with
a
pretty
cool
way
to
go
and
do
this,
and
so
those
of
you
that
know
a
little
bit
about
you
know
casper
labs
and
what
we
are.
You
know
that
we
were
kind
of
born
out
of
ethereum
research
right,
like
one
of
the
big
pieces
that
came
in
that's
in
been
in
ethereum.
A
Research
has
been
this
idea
of
cbc
casper
right
and
the
consensus
protocol
and
many
of
our
developers
have
been
working
on
cbc,
casper
research
for
a
long
time
right,
and
so
we
like
to
think
of
ourselves
as
a
fast
track
towards
ethereum,
3.0
right
and
so
here
you
can
see
that
you
know.
A
Ethereum
has
been
working
hard
to
get,
get
to
eliminating
proof
of
work
and
going
to
peer-proof
mistake,
but
it's
been
a
slow
process
for
them
right
and-
and
you
know
reasonably
speaking-
I
mean
they
have
how
many
billions
of
dollars
of
value
locked
up
on
the
ethereum
blockchain
it's
non-trivial.
A
They
need
to
proceed
carefully
but
casper,
because
we
have
very
little
value
locked
up
on
our
blockchain.
We
can
afford
to
take
a
little
bit
of
risk
right
and
like
many
many
startups
that
come
in
you're
able
to
move
fast
and
move
fast
and
break
things
is
not
actually
accurate,
we're
not
taking
a
cavalier
approach,
but
we
are
able
to
take
a
cleaner
approach
because
we
don't
have
to
worry
about
a
migration
path
right.
So
you
can
take
a
cleaner
straight
shot
approach
and
try
to
get
to
ethereum
3.0.
A
So
that's
what
this
slide
talks
about.
We
also
talk
a
lot
about.
You
know
how
we
exceed
the
goals
of
a
3m
3.0
faster,
and
we
can
enable
a
seamless
transition
from
ethereum.
If
you
want
to
enable
a
seamless
transition
from
ethereum
right,
we
can
support
webassembly,
smart
contracts
and
solidity.
We
can
support
shards
we're
mathematically,
secure,
including
ddos,
protect
protection,
so
we're
mathematically,
secure
and
live.
We
also
provide
contract,
versioning
and
protocol
versioning
weighted
key
management,
continuous
integration
and
deployment
and
meta
transactions
and
flexible
payment
codes.
A
So
these
are
some
of
the
features
of
cbc
casper
mainnet
right
what
we
are
building,
so
we
have
always
said
that
we
are
going
to
support
multiple
languages
and
web
assembly
is
a
wonderful
tool,
and
that
enables
us
to
do
this,
and
so,
but
one
of
the
other
things
that's
really
important
to
think
about
is
we
want
to
provide
support
for
developers
to
create
contracts
with
the
ecosystem
that
they
want
to
use
right.
So
if
you're
a
rust
developer,
you
can
build
your
contracts
using
the
rust
ecosystem.
A
If
you're
assembly
script
developer,
you
can
build
your
assembly
sip
contracts
using
the
assembly
ecosystem
and,
if
you're
a
solidity
developer,
you
can
build
your
solidity
contracts
using
the
solidity
ecosystem
and
all
you're
having
to
swap
out
as
part
of
those
ecosystems
is
a
compilation
package
right
and
slight
step
away
from
solidity
is
that
we
will
have
a
proprietary,
casper,
rust
transpiler
that
we
are
building
that
will
enable,
but
this
will
enable
solidity
developers
to
use
truffle
if
they
want
to
use
truffle
right.
A
So
we
can
go
to
truffle
and
do
a
truffle
integration
and
drop
our
compilation
target
in
there
and
now
solidity
developers
will
be
able
to
continue
developing
the
salinity
contracts
using
truffle,
but
they'll
just
have
a
different
compilation
target
which
would
be
casper
right,
it'll,
be
the
casper
compilation
target
which
would
build
out
web
assembly.
That's
casper
ready,
so
this
gives
a
very,
very
seamless
experience
for
them.
A
It
was
a
great
initial
prototype
of
what
the
possibilities
were
for
blockchain.
It
gave
us
deterministic
compilation
and
execution
in
a
sandbox
environment
which
set
it
up
for
blockchain.
Since
then,
web
assembly
has
kind
of
come
in
and
swept
in
and
all
on,
your
blockchains
are
now
implementing
webassembly.
A
You
know
polka
dot
near
and,
of
course,
casper
labs
and
our
approach
is
is
to
enable
support
for
the
language
which
is
significantly
more
full-featured
than
the
evm
itself.
But
this
gives
solidity
developers
full
access
to
all
of
the
features
that
casper
lab
has
right.
So
they
get
all
the
account
features.
The
weighted
key
management,
the
deployment
thresholds,
the
key
delegation
they
get
access
to
contract
upgrades
and
they
get
access
to
the
meta
transactions
and
the
touring
complete
payment
code
right.
A
There's
no
contract
compatibility
issues
right
so
once
we
get
the
full
support
for
all
of
solidity.
Arguably,
you
can
upgrade
your
ethereum
contracts
to
use
casper
labs
and
you
won't
see
that
many
contract
compatibility
issues
because
you're
not
talking
about
two
different
execution
contexts
right.
Everything
is
running
in
the
casper
vm,
there's
a
single
virtual
machine
and
an
easier
user
experience
in
the
long
run
right.
So
this
makes
all
of
casper's
features
available
in
salinity.
A
Could
talk
a
little
bit
about
how
we're
doing
this
right?
So
we
are,
we
are
leveraging
solang,
which
is
an
open
source
tool.
It's
going
to
generate
some
ast
and
then
we're
basically
building
a
transpiler
to
convert
that
ast
into
a
casper,
rust,
smart
contract,
and
this
will
use
the
con
the
casper
labs
macros
that
we're
releasing
and
basically
what
happens
is
at
the
end
of
this
you
get
a
rest,
smart
contract,
which
you
can
then
run
with
the
rust
test,
harness
so
and
you
can
put
it
under
ci
cd.
A
So
your
developer
can
experience
continue
working
with
solidity,
but
what
comes
out
on
the
other
end
is
a
rust,
smart
contract
that
they
can
actually
test
and
they
can
actually
use
our
cicd
system
and
our
cicd,
tooling
and
and
test
infrastructure
and
then
deploy
that
rust
contract
to
the
casper
blockchain
using
the
wasm
tooling
right,
and
so
this
is
what
you
get
you
get
this
ethereum
salinity
contract.
You
pass
it
through
the
casper
transpiler
and
you
get
this
casper
contract
and
you'll,
see
here,
casper
lag's
contract
here
and
the
cash
flows
method.
A
These
are
the
new
macros
here,
and
this
is
basically
a
casper
labs
contract
that
uses
casper,
labs,
macros
and
the
casper
headers
contract
headers,
and
then
you
can
actually
debug
and
test
them
on
a
local
machine.
So
I
can
actually
show
you
guys
here.
I
grab
that
screenshot
from
basically
my
machine
here
and
from
my
c
line
here,
which
is
basically
an
ide.
A
This
is
not
a
proprietary
blockchain,
ide
c
line
is
what
you
build.
If
you're,
you
know
you
use
it
if
you're
using
c
plus
plus
it's
what
is
what
our
developers
use
when
they're
actually
building
the
contract
runtime
right,
so
when
they're
building
the
actual
execution
engine
or
even
the
node,
they
use
c
line.
So
here
I
can
actually
run
this
little
blank
contract
and
I
can
hit
run
edit
configurations
and
I'll
just
say
run,
and
it's
actually
running
my
contract
right
now.
A
It
runs
it
through,
and
here
you
can
see,
it's
run
all
this
and
see
this
little
thing
here.
This
is
what
we
call
a
breakpoint,
and
this
is
how
developers
actually
write
code.
They
do
break
points
they
do
watching.
This
will
enable
me
to
actually
investigate
what
is
the
value
inside
this
little
value
here
right.
So
I
can
take
a
look,
and
I
can
do
a
watcher
right
so
here
right
now,
this
code
has
actually
stopped
here,
yeah
and
I'm
able
to
inspect.
A
A
It's
really
easy
to
introduce
bugs
when
you
can't
investigate
how
your
code
is
running
and
if
you
look
at
a
lot
of
the
solidity
ecosystem
right
now,
truffle
and
a
lot
of
these
tools
have
actually
built,
and
they
run
ethereum
nodes
on
the
back
end
to
enable
developers
to
do
this,
because
the
evm
and
the
ethereum
architecture
doesn't
enable
this
right.
Well,
we
built
this
directly
into
our
rust
architecture.
This
is
something
if
you're
writing.
Smart
contracts
in
rust.
A
You'll
get
to
do
this,
but
now
we've
actually
made
this
accessible
to
solidity
developers
right
and
so
it
because
the
methods
map
over
fairly
easy.
I
can
go
ahead
and
explore
and
examine
how
my
contract
is
actually
behaving
as
I'm
running
it
and
you'll
notice.
I'm
not
running
a
casper
labs
node
here
right.
There
is
actually
a
tool
chain
in
here
that
and
a
test
framework
that
actually
runs
the
smart
contract
runtime
directly
on
my
computer,
without
needing
a
node
right.
So
I
can
also
use
this
with
travis.
A
I
can
use
this
with
a
variety
of
what
we
call
continuous
integration
and
continuous
deployment
tools
that
basically
let
my
contract
run
so
anytime.
I
make
a
change
to
my
overall
system
architecture
like
if,
let's
say,
for
example,
I'm
rapidly
building
an
interface
like
a
voting
dap
right
and
I'm
changing
my
inputs,
I'm
changing
my
apis
or
what
my
user
is
doing.
I
want
to
explore
and
examine
what's
going
into
my
smart
contract
on
chain,
even
if
I'm
not
changing
the
contract
on
chain,
I'm
still
changing
the
inputs.
A
A
So
massively
important
for
developers
really
really
important
to
make
building
smart
contracts
feasible
right
and
this
allows
developers
to
rapidly
iterate
and
it's
the
only
way
you
can
keep
up
with
your
competitors
right.
If
you
have
to
debug
your
code
in
a
living
system,
you're
gonna
have
so
many
support
issues.
Your
customers
are
not
going
to
be
happy
right,
so
this
is
the
reality
that
we're
dealing
with
with
customers.
A
So
that's
that's
the
bit
on
how
we're
supporting
solidity.
Smart
contracts,
we're
super
excited
about
this,
I'm
going
to
pull
up
the
road
map
and
I'll
talk
a
little
bit
about
that,
and
if
there
are
questions,
I'm
happy
to
field
questions,
I
can
drop
questions
into
telegram
and
og
will
talk
about
them
here.
If
you
have
questions,
let
me
just
pull
something
up
here:
real
quickly
here
and
I'll.
Show
you
guys
my.
A
So
the
top
here
I
talk
about
what
the
strategic
objective
is,
what
we're
looking
to
do
in
any
given
month
and
how
we
build.
This
is
the
way
I've
always
managed.
You
know
the
kind
of
the
progression
of
the
product
over
time
right.
So
we
keep
a
real
strong
eye
in
terms
of
what
our
strategic
objectives
are
for
the
product
and
then
we
have
our
swim
lanes.
A
We
talk
here
about
each
of
our
functional
areas,
right
so
we're
here
in
july
and
as
I
told
you
for
the
node
russ,
we
wanted
to
get
chain
spec
and
the
genesis
process
done.
We
wanted
to
formalize
the
event
model,
get
the
deployer
gospel,
ready
and
get
production
ready,
and
we
wanted
to
get
to
block
execution,
and
so
I'm
happy
to
report
that
we
got
that
done.
A
We
integrated
the
contract
runtime
into
the
node
architecture,
the
new
rust
node
architecture
and
then
wire
up
the
execution
engine
storage
and
deploy
buffer
into
unified
storage,
and
so
the
last
piece
of
that
is
to
move
the
state
try
out
of
the
ee
container
into
the
node
container
right.
So
now
we've
got
a
unified
storage
story
on
the
ecosystem
front.
A
We
wanted
to
get
we
talk
down
here.
We
want
to
get
gitpod
in
for
browser
contract
development.
I'm
happy
to
report.
I
set
up
the
casper
labs
ecosystem,
github
organization.
It's
going
to
be
a
completely
separate
organization,
we're
going
to
push
all
of
our
example:
smart
contracts
there.
My
goal
eventually
is
to
turn
this
over
to
the
dev
down.
So
we've
got
wolf.
A
Call
here,
who's
the
legal
representative
of
the
dev
dao,
it's
the
independent
entity
that
we're
going
to
have
a
partnership
with
to
help
developer
engagement
and
basically
support
the
rights
of
developers
in
the
blockchain
space
as
an
independent
entity
and
I'll
be
really
I'm
really
excited
about
that
partnership.
A
That's
coming
we'll
have
a
big
announcement
about
that,
but
eventually
they're
going
to
own
all
that
right,
they're
going
to
own
all
of
that
development
work
they're
going
to
own
own,
the
and
basically
could
be
the
face
of
developers
in
the
blockchain
ecosystem
and
blockchain
space,
broadly
contracts,
dsl
and
support
for
solidity
via
solang.
That
work
is
going
on
going
and
adjust
arguments
for
dsl,
so
we'll
basically
be
adding
a
dsl
to
support
the
creation
of
arguments
and
driving
of
arguments
into
smart
contracts.
A
So
on
track
for
everything
that
we
wanted
to
get
done
in
july,
if
not
exceeding
that
and
the
goal,
the
strategic
objective
is
to
increase
app
developer
engagement
right.
So
we
want
to
get
projects
building
on
the
on
the
casper
labs
network
and
we
want
to
get
as
many
large
staking
pools
to
participate
in
the
test
net.
So
that's
the
goal
august.
A
We
want
to
build
a
developer
community
and
conduct
hackathons
and
so
austin's
on
here
we
did
our
initial
hackathon
with
austin
he's
one
of
he's
a
good
friend
of
ours,
and
he
supports
a
lot
of
the
hackathons,
so
we'll
be
working
with
him.
We're
going
to
work
on
getting
the
economics
of
the
chain
and
bonding
auctions
done,
and
you
heard
that
we
started
doing
some
of
the
specification
review
of
that.
That's
in
preparation
for
getting
that
done
in
august
and,
let's,
let's
scroll
up
here
a
little
bit.
A
So
the
goal
is:
is
that
we're
going
to
get
multiple
errors,
adaptive
round
length,
base,
block
switch
box
and
finalize
blocks
done?
And
the
intention
is
by
august
we're
going
to
have
a
node
ready
for
a
a
bunch
of
validators
start
running
that
node
we're
not
going
to
update
we'll,
probably
run
two
networks.
I've
been
thinking
a
lot
about
this,
so
in
the
test
net
program
we
will
likely
have
two
networks.
A
One
will
be
the
rust
node
network
and
the
other
one
will
be
the
scala
node
network,
which
will
be
the
stable
network
and
we'll
so
we'll
have
an
unstable,
rust,
node
network
and
I'll
be
peeling
off
some
of
the
validators
that
are
participating
in
the
test
net
to
go.
Work
on
that
network
with
us
and
that's
coming
in
august,
probably
by
the
end
of
august.
A
We'll
do
that
we're
going
to
have
the
design
for
checkpoints
and
we're
going
to
look
at
transaction
costs
and
metering,
implementation
in
contract
runtime
and
then
building
out
the
bonding
and
unbonding
auctions
and
proof
of
stakes.
So
this
will
be
big
proof
of
stake,
updates
coming
in
august
and
september
by
the
delta
test
net,
we'll
be
basically
decentralizing
kicking
off
the
attack
phase
and
we
will
be
code
complete
on
consensus
is
my
intention,
probably
what
will
be
left
in
terms
of
functionally
complete
with
consensus.
A
So
the
goal
is
for
delta
test
net.
We
want
some
malicious
nodes
on
the
network
as
well,
and
then
we're
going
to
get
checkpoints
implemented
and
protocol
upgrades,
and
then
we
want
to
do
past
state
passing
to
peers
right.
So,
basically,
our
intention
is
to
actually
have
state
pruning
state,
passing
and
checkpoints
implemented
before
we
go
to
mainnet,
and
this
enables
us
to
have
a
stable
node
that
will
not
grow
the
state
into
oblivion
right.
It
is
our
intention
that
every
node
will
in
essence
be
have
the
capability
of
running.
A
You
know
fairly
efficiently
with
a
500
gigabyte
storage
right,
that's
the
gold
so
that
the
state
will
grow
very
very
slowly
over
time
and
you
will
emit
events
to
an
event
cache
like
kafka
or
something
that
will
basically
hold
all
the
events
in
perpetuity
right.
But
the
nodes
themselves
are
only
responsible
for
processing
events,
sending
those
events
to
kafka
and
then
maintaining
what
the
requisite
state
is
in
order
to
keep
the
contracts
that
it's
actively
supporting,
up-to-date
and
correct.
A
Okay,
I
don't
think
I've
got
any
questions
coming
in
from
telegram
either
I'm
going
to
stop
my
screen
share.
Do
we
have
a
quick
economics
update
today
or
we
can?
We
can
forego
that.
A
C
C
All
right,
you
should
be
seeing
the
confluence
page.
Has
this
worked
yep?
I
can
see
it
okay,
fantastic
great,
so
we
are
last
week
we
have
completed
the
first
draft
of
the
validator
entry
spec
or
in
other
words
there
is
a
spec
for
bonding
auctions,
and
we
have.
C
We
have
discussed
the
designs
of
two
things
that
are
relevant
here
in
the
previous
talks.
One
of
them
was,
of
course,
the
auctions
themselves.
Right
I
mean,
I
think
I
have
you
know
talked
about
them
on
multiple
occasions
and
the
other
one
is
actually
delegation
right.
So
the
process
by
which
users
can
delegate
their
tokens
to
to
a
validator
in
order
to
indirectly
participate
in
the
consensus
system.
C
So
this
spec
in
fact
describes
you
know
the
requirements
for
implementing
both
simultaneously
because
they're
closely
related
right.
So-
and
you
know
it
turns
out
that,
of
course,
you
know
the
design
that
you
know
we
had
was
very,
very
simple
at
the
very
least
for
auctions.
Right,
I
mean
it's
the
first
price
auction
you
show
up,
you
know,
and
you
know,
if
you,
if
you're
one
of
the
top
end
bidders,
you
are
going
to
be
a
validator
in
the
next
year.
C
C
This
is
a
description
of
the
logical
option.
Everything
else
is
me
having
to
design
the
infrastructure
that
is
around.
You
know
around
this
auction
right,
I
mean
so
people
entering
as
candidates
into
it,
people
with
drawings,
their
tokens.
C
C
So
in
the
process
of
making
the
stuff
more
specific,
we
have,
you
know,
discovers
needed
to
be
a
little
more
specific
about
some
things
right.
So
one
features
that
we
are
seriously
considering
and
this
was
may
have
been
mentioned
previously.
C
You
know
in
some
discussions
on
here
was
the
concept
of
found
in
validators
right.
C
So
we
want
to
look
in
the
initial
validators
for
a
given
period
of
time,
and
you
know
well,
the
question
is
you
know
it
seems
that
this
should
come
with
some
kind
of
you
know
privilege
to
it
right
and
well
the
simplest
privilege
we're
gonna
afford
them
as
simple
as
this,
you
are
no
matter
how
you
know
someone
else
might
obtain
some
tokens
right
you
for
a
certain
period
of
time,
if
you're
found
in
validator
you're
guaranteed
to
be
a
validatory,
both
required
and
guaranteed
right.
C
So
if
you
have
200
validator
spots
in
the
auction-
and
we
have
50
found
in
validators-
and
only
you
know-
200
minus
50
slots,
so
150
slots
are
actually
going
to
be
contested
in
the
option
right
up
until
the
point
when
these
are
found
in
validators
are
released,
and
at
that
point
you
know
they
are
competing
for
slots
just
like
everybody
else
right.
So
this
is
one
thing
that
had
to
be
clarified
when
we
actually
started
writing
this
down.
C
The
other
things
that
also
give
clarified
is
that
so
is
the
issue
of
how
rewards
are
distributed,
and
we
are
still
you
know,
we
are
still
in
the
process
of
clarifying
exactly
what's.
The
best
thing
here
is
both
from
ux
and
performance
perspective.
So
there's
actually
quite
a
lot
of
disagreement
on
slack
about
it,
but
the
general
idea
is
that
you
know
the
ideal
server
would
actually
prefer.
Instead
of
like
using
the
reward
purse,
we
would
prefer
to
deposit.
C
You
know
your
gains
from
senioric
back
into
your
stake
right
because
it
both
simplifies
the
design.
It
also
encourages
validators
to
hold
on
to
their
rewards
right,
because
you
know,
if
you
withdraw
tokens,
there's
a
waiting
period.
You
know
to
make
sure
that
you
didn't
do
anything
bad
in
case.
You
need
to
slash
you,
so
you
know
this
is
just
a
you
know:
it's
a
small
discouragement
to
just
immediately
withdraw
in
all
your
rewards
right
there.
C
You
just
get
added
to
your
stake
and
again
this
is
a
little
bit
up
in
the
air
right
now
because
we
are
discussing
you
know,
push-based
rewards
versus
pool
based
rewards
and
that
discussion
is
not
even
reflected
in
this
document,
but
again,
that's
part
of
this
process
of
elucidating
how
everything
must
actually
work
when
you
have
to
write
the
code
for
it
right.
So,
let's
see
I
think
another
like
this
is
sort
of
behind
the
scenes,
but
we
started
you
know
the
part
of
the
process.
C
Here
I
mean
I
didn't
intend
to
start
specifying.
He
knows
you
know
the
mint
contract,
but
I
ended
up
having
to
partially
specify
it,
and
the
reason
for
this
is
because
well,
I
need
to
have
a
concrete
idea
of
what
our
purses
and
how
these
processes
are
managed
and
how
these
purses
are
mapped
to
accounts,
and
so
it
ended
up
that
we
needed
to
put
a
few
details.
C
You
know
on
the
bones
for
the
mint
contract,
but
basically
right
now
we
have
an
almo
like
a
specs
that
is
almost
ready
for
implementation.
It's
almost
ready
because
well
reviewers
have
found
some
small
errors
here
and
there,
and
I
have
found
some
big
errors,
or
rather
emissions
here
and
there
right.
So,
for
example,
I
left
myself
a
big
note
here
in
red
right,
so
you
know
it
doesn't
actually
specify
how
you
know.
C
Abundant
delegators
are
to
be
slashed
because
right
now
the
ways
that
I
wrote,
the
spec
as
an
abundant
delegators,
it
doesn't
keep
track
of
whom
did
they
unbond
from
right.
So,
in
order
to
slash
them,
we
need
to
know
which
validators
tokens
and
then
bonding
purse
actually
came
from.
So
that's
something
that
needs
to
be
put
in.
C
C
Everyone
had
actually
a
chance
to
digest
this
so
that
once
people
start
writing
code,
everything
should
be
ironed
out,
but
overall
overall
it
seems
that
we
are
making
fairly
decent
progress,
and
you
know
right
now,
it's
kind
of
a
strange
goal
for
us
to
get
this
implemented
in
this
release
cycle.
So
you
know
maybe
not,
but
depending
on
how
it
goes
right.
C
I
mean
I'm
certainly
going
to
dedicate
a
lot
of
time
in
this
release
cycle
to
supporting
the
developers
to
make
sure
that
we
can
get
this
done
as
quickly
as
possible,
and
I
think
this
will
actually
be
the
first
major
piece
of
you
know
of
our
economic
models
that
actually
gets
implemented.
Unless
you
know
a
gas
price
and
it
gets
implemented
first
they're
kind
of
in
a
race
right
now,
but
that's
basically
the
status
as
of
now
for
economics.
A
That's
great
thanks.
The
yeah,
the
the
economics
of
the
chain
is
just
as
important
as
the
consensus
of
the
change,
so
we've
taken
the
economics
of
the
platform
very
very
seriously,
so
we've
been
thinking
about
it
for
a
long
time.
We
continue
to
think
about
it
right,
so
consensus
is
more
or
less
done,
but
the
economics
piece
is
still.
We
still
churn
on
it
regularly
and
we
have
lots
of
thoughts,
and
I
I
imagine
that
we
will
continue
to
have
to
watch
it
very
closely
even
after
the
network
goes
live.
A
So
it's
also
incredibly
sensitive
too,
because
when
you
start
changing
adjusting
how
much
people
pay
and
or
earn
it's
very
hard
from
a
governance
process
to
make
changes
so
we've
been
we've
been
thinking
a
lot
about
it.
Thank
you
for
that
alex
terrific.
Are
there
any
questions?
You
feel
any
questions
from
attendees.