►
From YouTube: CasperLabs Community Call
Description
Rewards Distribution presentation & status update.
A
A
Yeah,
we
are
here
in
early
February,
very
exciting
hard
to
believe
that
we're
already
in
the
second
month
of
2020,
enjoy
palindrome
Day
on
Sunday,
with
Super
Bowl
I
hope
folks
had
a
restful
weekend.
I'm
gonna
present
the
engineering
status
and
then
we're
gonna
have
an
update
from
our
economics
team.
A
We're
trying
to
share
something
every
week
around
the
economics
of
the
blockchain
to
help
provide
transparency
and
clarity
as
to
what
we're
building
and
provide
an
opportunity
for
folks
in
the
community
to
ask
us
questions
and
get
involved
in
the
project,
and
so
they
can
have
a
better
understanding
of
what
it
is
we're
building.
We
do
our
weekly
workshops,
every
Thursday
mornings.
Now
at
8
a.m.
Pacific
and
4
p.m.
Pacific,
the
4:00
p.m.
slot
is
to
support
folks
in
Asia.
Hopefully
the
8
a.m.
slot
works
for
folks
in
the
other
time
zones
in
the
world.
A
A
We
expect
to
be
delivering
no
12
on
Feb,
13th
and
I'm
happy
to
report
that
we've
actually
increased
the
scope
of
no
12,
because
I
suspect
that
our
MVP
support
for
assembly
script
is
ahead
of
schedule
by
a
full
cycle,
so
we'll
be
deploying
releasing
preliminary
support
for
assembly
script
in
the
no
12
timeframe
and
that's
super
exciting,
because
we've
got
projects
that
are
waiting
and
folks
that
are
waiting
to
interact
with
the
system
using
assembly
scripts.
So
this
is
super
cool.
A
Our
weekly
workshops
involve
interacting
with
the
public
dev
net.
Those
recordings
are
also
available
on
YouTube
and
on
our
wiki.
You
can
check
us
out
on
discord
to
get
access
to
the
wiki
pages.
They
are
open
in
public
and
you
can
run
through
those
steps
yourself
or
watch
the
videos
associated
with
each
of
the
sessions.
So
our
current
focus
we're
fully
focused
on
getting
ready
for
a
test
net,
which
is
the
end
of
March.
We
have
a
very
aggressive
timeline.
A
No
lie
will
be
done
with
highway,
probably
in
the
second
week
in
March,
and
we're
going
to
be
pushing
full
force
into
test
net
within
those
two
weeks.
So
it's
going
to
be
very,
very
aggressive,
we're
going
to
fail
and
learn
in
the
public
eye.
That's
okay,
I'm,
okay,
with
failing
and
learning
so
probably
the
first
test.
A
That's
going
to
be
a
little
wobbly,
but
I
think
we're
going
to
learn
a
lot
about
how
highway
behaves
as
part
of
this
entire
process,
so
I'm
still
going
to
want
to
push
ahead
and
we're
also
working
on
modeling
out
the
reward
distribution.
These
are
live.
You
know
validators
and
stickers
that
have
big
questions
about
that
and
so
we're
creating
an
actual
model
in
Python.
Around
rewards
distribution.
A
We're
doing
some
interesting
research
on
spam
protection,
you
know
being
able
to
DDoS
a
network
is
a
big
problem
and
the
consensus
guys
are
focused
a
lot
on
trying
to
solve
those
problems
as
well
and
we're,
like
he
said,
preparing
for
a
test
net
lots
of
test
infrastructure
that
we're
spinning
up
lots
of
performance
and
hardening
tests
that
we're
doing
so
on
consensus.
Big
update
here
is
that
we
will
support
some
notion
of
validator
set
rotation
in
the
first
test
net.
A
Originally
I
had
specified
that
it
would
be
a
fixed
validator
set
for
each
block
of
testing.
We
are
going
to
be
able
to
support
validator
set
rotation.
The
UX
is
going
to
be
a
little
strange
and
then
first
go-around,
because
you
can
send
a
bonding
request,
but
you
won't
be
part
of
the
bonded
set
until
the
switch
block,
which
is
switches
from
one
era
to
the
next,
and
so
the
the
user
experience
will
be
a
bit
weird.
A
We're
also
doing
some
work
around
fork,
choice,
rule
and
validation
for
highway.
That's
a
critical
piece
and
we're
also
building
the
Sequoia
simile
simulator
for
the
cazuelas
blockchain.
Why
do
I
get
to
see
the
first
version
of
the
Sequoia
simulator
Ashok?
What
do
you
think
that
that
date
looks
like.
A
A
Great
the
big
news
coming
for
this
next
release
is
all
on
the
smart
contract
development
side.
We
are
building
a
contracts,
development
kit-
this
is
huge,
I
mean
this-
will
enable
a
wide
variety
of
thing
things
you
can
have
an
integrated,
rust,
IDE
workflow.
This
means
that
you
can
create
your
own
project
and
you
will
automatically
have
your
projects
using
the
rust
tool
chain.
You
can
run
your
project
using
a
local
runtime,
so
you
won't
need
a
note
at
all.
A
You
can
also
use
this
local
runtime
to
actually
set
up
continuous
integration
and
continuous
deployment,
so
say,
for
example,
you
know
you
want
to
test
your
contracts
using
a
suite
of
unit
tests.
This
contracts,
development
kit
and
our
rust
tools
will
enable
you
to
do
that.
This
is
super
important,
I
think
for
building
production
systems.
You've
got
to
be
able
to
use
CI,
CD,
and
so
we've
built
something
that
we
use
ourselves
internally,
we're
also
building
out
the
system
contracts
within
the
execution
engine
and
we're
doing
this
for
performance.
A
We
believe
we
can
get
a
massive
performance
boost
by
making
the
execution
engine
specific
to
the
public
cazuelas
blockchain.
This
means
that
we
won't
have
generic
system
contracts
by
special
system
contracts,
a
mint
and
proof
estate
contract
and
the
and
the
payment
code,
I
believe
of
the
three
contracts
that
will
get
baked
into
the
execution
engine.
A
The
standard
payment
code
that
is
contract
authors,
can
still
specify
their
own
custom
payment
code
if
they
wish
we're
integrating
CL
value
all
the
way
into
the
node,
and
this
will
bring
the
CL
types
up
to
the
G
RPC
endpoint.
This
provides
a
very
consistent
flow
of
the
type
system,
all
the
way
through
to
the
end
edges
of
the
system
and
then,
of
course,
support
for
em
assembly
script
based
smart
contracts.
A
This
is
huge:
we'll
have
an
assembly
script
library
that
smart
contracts,
kit,
smart
contract
developers,
can
use
to
build
contracts
in
assembly
script
and
compile
them
down
to
web
assembly.
We're
very
excited
about
this.
This
is
huge
because
a
lot
of
folks
don't
know
rust.
Yet
rust
is
an
up-and-coming
language.
It's
definitely
a
delightful
language
to
contract
in.
A
We've
gotten
feedback
that
our
graph
QL
interface
is
just
delightful
people
love
using
it
and
we're
going
to
be
building
more
relationships
out
there
to
make
it
easier
to
interact
with
the
global
state
and
we've
got
we're
implementing
block
prefetch,
and
this
is
to
make
block
downloading
of
blocks
more
efficient
and
what
this
means,
if
a
block,
if
a
block
is
accessible,
I,
don't
have
to
wait
for
its
ancestors
right.
I
can
start
downloading
children
before
I
have
the
ancestors.
So
they
worked
my
way
back
up
the
tree
to
get
all
the
ancestors.
A
We've
got
to
get
auto
proposed
out
of
our
tests
because
in
highway
there
is
no
notion
that
the
validator
can
propose
whatever
they
want
at
least
right
now,
pushing
forward
that
may
change,
and
then
we've
got
network
simulations
and
a
large
testbed
environment
that
we're
building
ecosystem
big
push
on
ecosystem
and
to
align
with
the
work
we're
doing
in
no.12.
So
we
want
to
get
our
adapt
developer
guide,
set
up
to
help.
Dap
developers
quickly
get
started
with
writing
smart
contracts
and
then
enhancements
to
clarity
which
enhancements
are
we
building
for
clarity,
Ashok.
B
A
We're
rebooting
our
website,
so
there's
a
new
website
that
will
be
coming
here
in
the
next
week
or
so.
Marketing
is
looking
at
final
knits
spit-and-polish
in
the
website
and
we'll
be
launching
that
and
we're
also
up
improving
our
documentation
for
the
smart
contract
examples.
This
week
we
will
be
demoing.
The
ERC
20
example
that
we
have.
We
built
an
e
rc
20
example
out
and
we'll
be
demoing
that
and
showing
people
how
the
ERC
20
smart
contract
works.
It
has
all
the
same
properties
of
the
existing
etherium
prsut
20
we
haven't
implemented
any
custom.
A
Economics,
we're
looking
at
pricing
of
transactions,
so
combined
computation,
storage,
bandwidth,
pricing
and
then
working
on
spam
protection
and
then
again,
like
I,
said
reward
distribution
in
Python.
So
we
can
start
simulating.
What
rewards
actually
looks
like
again
reminder
on
the
weekly
workshops
and
join
us
for
these
calls
and
stream
it
online
I'm
going
to
save
the
page
here
and
Ashok
any
information
on
the
clarity
updates,
yeah.
B
Yeah
yeah,
so
the
main
theme
is
to
improve
user
experience
user
interaction
for
our
validators.
We
are
also
trying
to
try
to
enable
deploys
from
web
browser
the
look
and
feel
we
want
to
improve
of
the
clarity
as
well
say
things
like
you
know,
showing
validated
eros
in
faults
and
validators
number
of
validators
and
bottom
bounds.
A
lot
of
push
on
giving
more
information
to
validate
blocks
proposal
validators,
for
example,
I.
Think
one
of
the
big
thing
that
is
coming
it
is
ability
to
deploy
through
web
browser
yeah.
A
Yeah
definitely
and
then
I
think
as
a
follow-on,
we're
going
to
be
offering
an
in-browser
IDE
to
support
assembly
script
contract
development.
So
you
know
rust
developers
like
very
much
to
use
IDE.
They
have
a
very
different
workflow
and
for
assembly
script.
You'll
want
to
have
a
browser-based
IDE,
so
we're
definitely
to
support
that
as
well
as
deploy.
A
You
know
sending
your
deploys
via
the
browser.
The
other
cool
thing
that
we
have
is
because
we
have
multi
signature
for
deploys.
One
of
the
things
you'll
want
to
do
is
you'll
want
to
be
able
to
receive
deploys
that
need
your
signature
from
within
the
browser
as
well
right
so
users,
if
I
have
deployments
that
I
need
to
sign.
A
Ideally,
they
should
be
able
to
receive
those
deploys
via
a
via
the
browser
or
some
mechanism.
Right
now
we
send
deploys,
you
can
send
deploys
by
emails
actually
to
other
users
to
have
them
apply.
The
signature
so
interesting
way
to
to
send
and
receive
deployments,
be
cool
to
do
that,
both
from
within
the
browser
cool,
Oh,
Nora
Alexander
who's.
Presenting
today.
C
Excellent
alright,
so
there
are
two
major
classes
of
problems
that
you're
trying
to
address
these.
Our
price
and
research.
Currently,
the
first
one
is
I
mean
it's
critical,
but
not
necessarily
very
difficult
to
get
to
solutions.
So
this
is
a
class
of
problems
which
is
of
the
form
you
know,
for
example,
we
have
op
codes.
Is
that
you
know
do
not
exist
in
something
like
a
theory
right
and
we
need
to
assign
the
price
to
it.
C
So,
in
principle
we
can
resolve
that
at
least
provisionally
by
you
know
time
in
you
know
the
computation
and
the
scale
of
the
gas
prices
appropriately.
Similarly,
you
know
we
have,
you
know
problems.
So
this
nature
of
is
storage,
a
related
problem,
viz
incentivizing,
reuse
of
code,
rather
than
submitting
new
code.
So
all
these
are
they're
very
you
know,
applied
problems,
and
while
we
may
not
be
able
to
fight,
you
know
an
absolutely
optimal
solution
to
them.
C
So
the
thing
is
that
it's
really
stay.
You
know
in
my
current
understanding
of
this.
There
is
very
little
actual
modeling
of
this
price
and
problem
in
the
ways
that
you
know,
like
economists
would
model
it.
So
you
know
you
can
read
the
theory
of
blogs
and
the
you
know
things
of
that
nature
and
there's
some
verbal
discussion
of
you
know
trade-offs
of
different
pricing
models.
But
it's
not
really.
You
know,
there's
nothing
concrete,
that
I
have
seen
that
carries
the
south
through
to
the
earth.
C
So
the
fact
that
working
on
has
a
very
simple
goal:
I
want
to
have
a
very
minimal
mathematical
models
that
captures
the
most
essential
features
of
pricing
computation.
You
know
probably
extending
further
into
modeling
storage
and
possibly
bad
week
later,
and
the
setup
here
is
not
too
dissimilar.
Really
to
you
know
some
of
the
models
you
know
you
may
have
seen
in
you
know.
C
You
know
like
second
year
microeconomics
courses
right,
so
you
would
be
starting
with
something
like
a
two
period
models
that
the
features
completely,
not
sir
demand,
and,
on
the
other
side,
the
validator,
whose
objectives
are
basically
aligned
is
those
was
a
platform.
The
elements
of
such
a
model
would
be
some
representation
of
demand,
probably
at
first
the
demand
curve,
although
we
could
possibly
expand
this
to
be
somewhat
more
rich
right,
so
you
could
think
of
demand
comment
from
this
joint
distribution
of
computational
loads.
C
Of
course,
that's
you
know,
that's
more
of
a
you
know
that
Sofia
the
model
would
expect
it.
Something
would
start
with
because
it
would
make
things
rather
complicated.
To
actually
solve
is
the
platform
or
you
know.
The
valid
in
this
case
are
really
are
identical.
Essentially,
special
model
would
be
essentially
represented
by
some
capacity
and
the
sum
per
period,
the
costs
that
they
have
to
cover
and
some
objective
function
and
these
objective
functions.
You
could
think
you
know
it's
something
like
well.
We
could
try
to
maximize
aggregate
user
utility.
C
We
could
try
to
maximize
revenues
so
essentially
act,
as
you
know,
pretends
as
the
validator
is
like
a
monopolist
or
we
could
try
to
minimize
price
variation
between
periods
if
we
allow
price
in
to
actually
vary
between
periods,
instead
of
just
fixing
it.
And,
of
course
there
is
a
pricing
function
itself
in
as
I
said
again,
it
could
be
flexible,
could
be
fixed.
So
would
we
actually
need
to
address
this
model?
C
C
The
second
aspect
is
the
miss
we
addressed.
Is
you
know
the
notion
of
bottlenecks
lower
flows
right,
so
this
may
need
a
slight
extension
to
the
basic
models
they
describe
in
the
sense
that
you
know
we
may
need
to
introduce
some
form
of
discount
and,
for
you
know,
the
users,
because
they
presumably
like
to
have
their
transactions
executed
earlier
rather
than
later,
and
in
a
you
know
more
generally,
what
we
want
to
do
is
this
is
to
mode
allows
impact
of
alternative
pricing
models
on
utility
and
price
volatility
right,
so
we
can
solve
out.
C
You
know,
model
exists
for
all
the
different.
You
know
for
all
these
different
objective
functions.
Right
and
possibly
you
know
either
allowing
price
to
be
flexible
or
not.
Allow
that
will
be
flexible
that
we
can
compare.
You
know
so
well,
four
different
alternatives.
What
is
going
to
be?
You
know,
basically
the
price
variance.
What's
going
to
be
the
aggregate
utility
and
the,
then
you
don't
make
you
more
intelligent
decisions
about
which
price
model
actually
adopt.
Now,
of
course,
the
things
that
I'm
describing
is,
you
know
relatively
basic,
so
we
will
be
looking
at
one
suite.
C
So
without
to
enrich
it
to
his
things,
such
as
you
know,
separate
pricing
for
storage
for
Babbitt
right,
so
we
would
be
pricing.
The
two
resources,
instead
of
one
I,
could
conceivably
extend
it
to
the
fully
dynamic
set
up.
Instead
of
you
know,
just
a
two
period
model-
and
you
know
maybe
even
further
to
you-
know,
model
validator
entry
and
interaction
with
different
validators.
You
could
consider
make
demand
and
some
sense
strategic,
so
they
would
not
merely
arrive
to
the
system's
actions,
but
possibly
times
them
to
you
know,
take
advantage
of
price
variability.
C
A
D
D
Haven't
had
the
chance
to
know
implement
a
lot
of
examples.
Okay,
I
was
just
running
basic,
like
three
validator,
three
validator
configurations
and
copying.
If
what
would
happen,
if
just
one
well
later
want
to
underestimate
his
around
exponent
and
go
like
really
fast
like,
does
he
really
get
punished
or
not
got
it?
I
want
to
add
one
more
thing,
so
you
were
earlier
mentioning
multi-state
transactions
the
way
we
have
deploys
right
right
now
we
don't
have
multi
snake
for
payment
code
right.
D
A
Not
have
multi
sync
for
payment
code.
I
believe
I
believe
that
that
is
something
that
could
theoretically
be
supported,
out-of-the-box.
So
if
the
payment
code
is
happening
from
a
context
that
requires
certain
keys
to
sign
it,
I
don't
know
I've
not
tried
it,
but
I,
don't
underst
in
pet
amis
to
that,
because
I
think
you
can
parameterize
your
payment
code,
the
same
as
you
could
your
session
code.
It's.
D
Not
really
good,
you
like,
like
you,
are
saying:
it's
we're,
building
it
to
be
future
proof
yeah,
and
you
want
to
separate
transaction
sender
from
transaction
deployer,
so
like
people
will
be
able
to
use
that's
like
apps,
without
even
needing
tokens
or
without
having
to
pay
for
gas.
That's
right.
This
is
this
is
something
we.
If
we
get
future
proof
yeah.
A
A
A
Because
I
happen
to
have
this
graph
key
well,
so
the
data
structure
looks
like
this,
so
right
now
we're
looking
at
all
the
contracts
that
might
that
my
key
has
deployed
this.
Is
this
named
keys
right?
This
is
within
the
global
state,
but
here
you
can
see
here
that
you
have
this
associated
keys
data
structure
and
these
associated
keys
are
the
keys
that
are
allowed
to
perform
actions
and
you'll.
A
A
A
Very,
very
flexible,
extremely
flexible,
and
if
I'd
have
to
go
back,
you
know
to
an
older
version
of
the
blockchain
state,
but
I
could
actually
show
you
when
the
key
weights
were
different,
because
you
can
actually
adjust
this
up.
That's
another!
That's
another
clarity!
You
can
actually
adjust
this.
If
I
go
to
explore
here
and
we
go
back
like
maybe
50
blocks,
then
we
pick
this
block
hash
here.
I
bet
you
there.
We
will
see
something
different
in
terms
of
my
account.
A
A
A
And
so
you
see
fewer
contracts
here,
so
I
have
not
yet
deployed
other
contracts
in
this
one
as
well.
So
you
can
see
how
the
global
state
works.
You
can
see
how
might
be
in
this
context
here.
You
can
see
how
different
accounts
behave
differently
here.
So
if
I
put
this
account
in
here,
you
will
not
see
any
contracts
here.
So
here
here
you
go
so
this
account
you'll,
see
here.
A
There's
multiple
keys
and
you'll
see
the
deployment
threshold
and
the
key
management
threshold
is
higher
and
you'll
see
that
this
key
has
a
weight
of
five,
and
this
key
has
a
weight
of
one.
So
that
means
this
key
is
not
authorized
to
perform
actions
on
this
account,
whereas
this
key
is
and
if
we
go
fast
forward
on
the
global
State.
You'll
see
that
I
fix
that.
So
if
we
go
to
the
current
block
height,
which
is
this
here,
you'll
see
that
I
have
since
then
updated
those
keys
using
a
contract.
A
So
here
you'll
see
that
I've
updated
my
deployment
and
key
management
threshold
to
one.
So
now,
both
of
my
keys
work
but
I
still
have
a
heavy
key
and
a
light
key
and
notice
that
this
heavy
key
is
a
completely
different
key.
It's
not
associated
with
this
account
right.
This
is
the
key
you
associate
with
the
account.
This
is
a
different
key
that
I've
authorized,
so
this
key
can
sign,
deploys
and
manage
keys
on
this
account.
A
That's
all
we
have
I,
don't
think
we've
got
any
Q&A
and
we
check
YouTube
real
quickly,
see
if
there's
any
questions,
I
don't
see
any
questions,
so
I
think
we
can
call
it
done.
Thank
you
so
much
everyone
for
joining
and
we'll
talk
to
you
next
week
and
do
join
our
weekly
workshops
as
well.
Cheers
thanks
thanks.