►
From YouTube: CasperLabs Community Call
Description
Rewards Distribution presentation & status update.
A
All
right
good
day,
everyone
welcome
to
the
Casper
Laos
community
call
I'm
gonna
be
presenting
the
engineering
update,
and
then
we
will
have
someone
from
our
economics
team
presenting
our
economics.
We've
been
trying
to
review
economics
during
each
call
and
then,
at
the
end
after
the
economics
call
I'm
gonna,
do
a
overview
of
the
Casper
labs
clarity,
block,
explore
and
review
a
little
bit
about
how
to
get
information
from
the
block
explore
so
without
further
ado,
we'll
just
dive
right
in
into
the
engineering
status.
A
A
A
With
this,
we
will
likely
have
to
bounce
the
test
net
again,
because
we
are
seeing
some
problems
in
the
network
likely
because
the
patch,
while
it
prevents
the
problem
from
happening,
it
doesn't
necessarily
help
invalid
state
right
and
we
haven't
yet
implemented
checkpointing,
where
checkpointing
will
enable
you
to
basically
start
with
a
new
genesis
with
the
current
validator
set
in
the
current
state,
because
that's
not
implemented
as
yet.
We
will
probably
wind
up
bouncing
the
network
when
we
try
to
fix
with
18.2
with
between
18.2
and
19.
This
is
another.
A
A
The
change
in
version
dot
19
will
include
deploy
gossiping.
So
if
you've
interacted
at
all
with
the
network,
you'll
notice
that
the
turnaround
time
time
to
finalization
is
very
slow,
and
the
reason
for
this
is
that
your
transactions,
it
with
one
validator
and
Waits
and
they're
deployed
queues,
and
so
what
we'll
do
is
now.
The
system
will
basically
gossip
all
the
deploys,
and
this
is
table
stakes.
This
is
what
happens
in
Bitcoin
happens
in
aetherium
in
any
network
worth
its
salt.
You've
got
deployed
gossiping.
A
So,
while
you
may
send
your
transaction
to
one
node,
you
get
some
guarantees,
because
it's
gossiped
across
the
network
that
multiple
nodes
will
see
your
deployment
and
the
first
node
able
to
propose.
It
will
propose
it
for
you
right.
So
it's
always
a
race
to
process
the
transaction
for
the
fees,
and
so
we
we've
implemented
something
simple
similar
here.
A
We
are
so
for
those
of
you
not
familiar.
Our
architecture
is
a
scala
and
rust
combination
with
the
node
being
primarily
in
Scala
and
the
execution
engine
being
all
new
rust
code,
and
we've
decided
that
we're
going
to
move
the
entire
architecture
completely
to
rust.
We're
going
to
do
this
bit
by
bit.
The
first
big
milestone
is
to
have
what
we
call
like
a
synchronizer
and
a
reactor
model
and
then
integrate
in
a
rust
implementation.
A
We
have,
we
have
gone
through
and
made
some
major
revisions,
and
so
in
this
architecture,
consensus
will
be
as
pluggable
as
possible,
so
we're
deciding
api's
and
then
designing
agnostic,
arrow
logic
right.
So
we
know
that
almost
all
proof
estate
protocols
need
to
have
some
notion
of
eras.
Eras
are
really
good
for
state
pruning,
for
choice,
pruning
a
fourth
choice:
simplification,
because
you
only
have
to
go
back
to
the
beginning
of
the
era
to
calculate
the
fork.
Choice
rule
right.
A
So
this
is
why
areas
are
really
important
in
in
fork:
choice,
proof
of
steak
and
fork
based
proof
of
sheikhs
proof.
Stick
protocols
on
the
node
rust
side.
We
are
thinking
a
lot
about
how
validators
will
set
up
their
architecture
in
their
system,
and
we
believe
that
validators
will
definitely
optimize
our
architecture
for
the
deterministic
risky
portion,
which
is
the
consensus
forming
logic
versus
the
more
non
deterministic
piece,
which
is
the
servicing
of
queries
and
gossiping
and
block
propagation
piece.
A
So,
if
you
think
about
it,
each
of
the
casper
Labs
nodes
provides
a
graph
QL
service
deploy
gossiping,
as
well
as
the
consensus
piece
which
is
finalization
message.
Justifications
right
and
block
validation
and
block
proposal
activities
associated
with
consensus
present
risk
right.
They
presents
the
risk
of
equivocation
the
risk
of
proposing
an
invalid
block.
These
are
all
flashable
offenses,
and
so
you
know
that
a
validator
I
have
that
has
put
up.
A
A
A
lower
a
lower
power
instance
that
primarily
services,
queries
and
could
potentially
even
accept,
deploys
right
under
the
deploys
would
be
passed
to
the
validating
node,
and
so
what
we're
doing
as
we
do.
This
is
we're
thinking
of
bifurcating,
basically
splitting
off
this
Cal
Scalla
codebase,
which
is
really
like
most
of
Scala
code
bases,
deploy,
gossiping
block,
gossiping,
khadeem,
lea
and
graph
QL
right.
A
Fourth
choice,
validation
and
perform
block
finalization
right.
So
this
would
be
their
consensus
forming
node,
and
so
that's
what
that
means.
When
we
talk
about
the
design
of
the
two
layer
network,
the
validator
network,
also
where
it's
being
proposed
that
it
be
a
closed
loop
network,
this
doesn't
mean
it's
a
permission
protocol
anyone
can
still
bond
and
unbond,
but
once
you
are
bonded,
you
will
be
expected
to
share
your
IP
address
with
the
other
validators
and
join
the
trusted
I.
A
You
know
tcp/ip
network
and
this
helps
eliminate
dos
attacks
and
Sybil
attacks
against
the
validating
nodes.
We
believe
that
the
validators
would
really
want
this
in
our
design.
We're
also
implementing
contract
headers
contract
headers
still
not
ready.
Yet
we've
got
a
lot
of
work
to
do
around
our
example
contracts.
All
of
this
work
is
happening
in
a
branch.
This
will
likely
come
in
release,
dot,
twenty
or
even
dot
21,
when
it's
completely
done,
there's
a
lot
of
documentation.
That
needs
to
happen
a
lot
of
example,
contracts
that
need
to
be
upgraded.
A
We're
going
to
update
the
status
endpoint.
This
is
important
for
the
validators,
with
state
bloat
information,
so
basically,
on
the
the
test
net
got
hit
with
many.
Many
many
account
funding
requests
last
week
and
we
saw
the
state
bloat
a
little
bit.
So
we
definitely
want
to
be
able
to
see
what
the
disk
utilization
of
the
different
validating
those
are.
So
we're
going
to
augment
the
status
endpoint
with
that
information.
It
makes
it
very
easy
for
validators
to
monitor
their
notes
and
yeah
we're
doing
bug,
fixing
and
testing
before
we
deploy
anything
on
test
net.
A
So
we're
following
a
very
rigorous
release.
Get
a
cycle.
Each
of
our
packages
will
go
into
test
for
a
period
of
seven
days
before
they
go
to
production,
so
release
dot.
Nineteen
has
been
in
tests
already,
it's
under
stress,
testing
right
now
and
once
that
release
has
been
determined
to
be
stable
and
solid
as
well
release
it
to
the
validators
contract
run
time.
A
We
are
working
on
optimizing,
the
the
gas
model
internally
and
we're
also
doing
metering
so
we're
getting
ready
to
start
looking
at
what
the
gas
pricing
model
looks
like
and
how
much
transactions
cost,
and
so
for
that.
We
have
two
meter
things
like
network
and
storage
and
bandwidth,
and
so
we're
adding
metering
into
basically
now,
we've
metered
the
opcodes
such
that
we
can
now
start
applying
pricing
and
understanding,
really
figuring
out
how
much
transactions
are
going
to
actually
cost
on
the
network.
Yeah.
C
A
Right,
yep,
testin
sres
focused
on
deploy
gossiping,
and
we
are
also
doing
some
testing
around
token
transfers
per
second,
and
so
that's
some
stress
testing.
We're
doing
I'm
happy
to
report
so
far
that
the
testing
tool
is
what
needs
scaling,
not
the
network.
So
this
is
very
good
news.
We
basically
can't
put
enough
transactions
into
the
system
to
overload
the
network
as
of
yet
so
that's
a
great
sign.
A
We're
looking
at
scaling
out
s
tests
so
that
we
can
create
enough
load
on
the
system
to
meaningfully
put
some
load
on
the
network
on
the
ecosystem,
front
clarity,
where
we've
got
a
migrant
clarity
to
use
contract
headers
and
to
be
able
to
view
different
contract
metadata
in
the
network
and
we're
creating.
Basically,
the
JavaScript
stock.
Is
this
for
the
assembly
script
piece
Ashok?
What
is
the
Kasper
labs?
Gs
stack.
D
D
D
A
Got
it
so
yeah,
so
this
is.
This
is
basically
we're
going
to
provide
a
mechanism
to
send
deployments
and
send
transactions
from
the
browser
directly,
and
this
will
will
demonstrate
this
front-end
JavaScript
in
clarity.
First,
of
course
anyone
is
free
to
use
you
know,
Fork
the
clarity
codebase
and
build
whatever
they
wish,
but
this
will
be
a
great
great
demonstration
of
being
able
to
just
send
from
a
browser
directly
we're
going
to
extract
the
vesting
contract
into
a
separate
repository,
so
people
can
use
this.
A
This
is
an
example
of
how
tokens
can
be
used
to
vest
over
time.
For
those
of
you
that
are
not
aware,
any
tokens
that
are
granted
the
tokens,
even
for
the
private
validator
sale,
will
be
locked
in
a
vesting
contract.
All
the
tokens
as
part
of
the
employee
token
program
at
cazuelas
will
be
locked
in
the
vesting
contract,
so
the
vesting
contract
is
actually
a
really
core
to
the
system,
as
well
as
a
great
demonstration
of
how
you
can
vest
you
know
shares
of
token.
A
You
know
basically
tokenize
and
equity
right
this
concept
of
tokenized
equity
offerings.
You
can
do
that
and
vest
them
in
the
same
way,
something
like
card.
Oh
well,
we're
going
to
be
developing
a
voting
DAP
that
will
be
publicly
available
for
use
in
hackathons,
and
so
we're
going
to
create
that
DAP.
It
basically
creates
a
smart
contract
and
a
front-end
for
that.
A
That
is
something
that
we're
working
on
right
now
and
then
modeling
to
distribute
distribution
effects
of
token
vintages.
So
the
token
vintages
is
the
concept
that
those
of
you
that
stay
bonded
in
the
network
for
a
specified
duration
will
receive
additional
senior
age
rewards
right.
So
there
will
be
a
senior
age
multiplier
for
those
persons
that
bond
and
stay
bonded
to
the
network
for
a
longer
period
of
time,
and
this
is
to
provide
incentives
and
rewards
for
those
that
bond
in
the
network
and
our
long-term
validators
right.
A
New
timings
for
weekly
workshops,
Friday
7
a.m.
Pacific
and
midnight,
so
we've
tried
to
make
it
more
friendly
to
all
those
outside
of
the
west
coast.
So,
if
you're
looking
to
learn
about
smart
contract
development,
join
our
workshops,
Omachi
our
smart
contracts,
developer
and
pure-d
run
those
workshops
you
can
come
in
there
ask
them
anything,
get
help
in
running
your
smart
contracts
and
working
with
your
smart
contracts,
hands
on
so
they're
available
during
those
two
windows
for
you
and
now
I'm
gonna
turn
it
over
to
Alex
to
talk
a
little
bit
about
economics.
E
So
today
we're
actually
in
you
know
previous,
you
know
presentations.
We
have
talked
about
individual
features,
you
know
more
or
less.
You
know
at
the
time
that
we
were
starting
to
work
on
them,
were
you
know,
finish
and
work
on
them
and
so
forth,
but
today
I
actually
want
to
give
a
complete
overview
of
you
know
what
we
ended
up,
having
in
our
planning
documents
up
until
the
release
of
main
net
right.
E
So
well,
you
know,
of
course,
as
everybody
here
knows,
Casper
labs
wants
to
be
a
blockchain
for
builders,
and
in
order
to
be
looking
for
builders,
you
must
have
specific
features
and
processes
that
actually
supports
us
all
right.
So
some
of
these
are
fundamental.
You
know
fundamental
just
who's,
the
you
know
proof
of
stake
model
of
consensus.
Right
I
mean
we
actually
need
to
back.
Certain
assumptions
made
you
know
in
the
distributed
systems
papers
that
we
have
is,
you
know
actual
you
know,
economic
sticks
and
carrots.
E
You
know
we
must
have
in
place
processes
for
suggesting
and
implement
in
you
know
and
discuss
in
time
to
improve
and
processes
for
major
incident
management.
You
know
we
must
put
in
place
these
mechanisms
to
make
sure
that
the
system
stays
transparent
to
its
users
and,
of
course,
also
to
the
validators.
E
You
know
we
must,
you
know,
have
you
know
critical
piece
in
place
to
regulate?
You
know
entry
and
exit
of
validators
from
the
platform,
and
finally,
we
must
ensure,
as
a
you
know,
collective
resources
are
carefully
managed,
so
in
the
subsequent
slides.
You
know
briefly
go
through
what
you
know.
The
discrete
pieces
here
are
its
first
of
all,
for
you
know
the
business
work,
anomic
security
rewards
and
resource
management.
E
We
have
four
discrete
pieces
that
we
are
working
on
the
first
one
is,
of
course
the
centerpiece
was
a
whole
thing,
which
is
senior
age,
which
is
you
know,
the
rewards
that
you
receive.
Of
course,
for
you
know
doing
the
you
know,
validation,
the
consensus
work,
and
here
we
essentially
have
a
complete
design
and
we
also
have
a
simulator,
but
we
are
yet
to
do
large
skills,
seemingly
simulations
that
will
establish
that
you
know
the
current
design
you
know
doesn't
run
into
any.
E
You
know
any
bad.
The
corner
cases,
of
course,
there's
always
a
risk.
You
know,
while
we
try
to
ground
all
of
our
work,
you
know
in
economic
theory
we're
still
you
know
flying.
You
know
a
lot
of
the
time
by
intuition.
Just
because
of
our
you
know,
timelines,
you
know,
hope
you
know,
because
of
you
know
various
changes
in
the
system.
You
know
it's
hard
to
sit
down
and
you
know
work
out
a
complete.
E
You
know
you
know
model
with
economic
equilibrium,
so
we
would
have
to
rely
on
simulations
and
again
the
goal
simulations
to
make
sure
that
you
don't
run
into
any
very
bad.
You
know
corner
cases.
If
you
know
there
is
something
about
the
distribution
of
certain
traits
among
validators.
So
that's
actually
this
is
here.
E
This
is
the
central
piece
was
a
cool
thing,
but
beyond
that
we
have
slash
and
of
course
right
so
this
is,
you
know
where
Spanish
was
from
destabilize
and
consensus
such
as
you
know,
by
clear
occasion
we
have
a
preliminary
design
fort
well
as
a
preliminary
design.
You
know
when
I
say
preliminaries.
This
is
even
before
a
draft
design.
This
is
you
know
what
you're
doing.
Roughly
for
one
particular
case,
which
is
actually
location,
but
you
know
we
may
expand
slash
into
other
cases
and
then,
of
course
that
would
require
you
know
some.
E
You
know
concrete
work
on.
You
know
model
in
it.
You
know
just
you
know,
to
see
what
the
effects
are
likely
to
be,
and,
of
course,
you
know
actually
increment
in
it
in.
Finally,
we
have
transaction
fee
distributions,
you
know
yet
to
be
concrete
ly
designed
I
would
say.
This
is
also
similar
case
to
slash
and
in
that
it
seems
that
most
of
the
alternatives
are
fairly
simple,
but
we
need
to
pick
one
and
make
sure
that
it
doesn't
do
anything
untoward,
and
you
know.
E
Finally,
in
this
rubric
we
have
resource
question
and
price
and
which
will
eventually
secure
us
against
now
service
attacks
and
did
sure
you
know
efficient
allocation
resources
and
the
draft
design
process
is
in
progress
and
in
fact
the
owner
already
mentions
that
you're
collecting
data,
for
it
is
this
exercise
specifically
for
the
resource
cost
in
part
alright.
So
this
is
a
strictly
economic
bit.
Let's
say
you
know,
we
are
also
trying
to
ensure,
as
I
said,
the
platform,
transparency
and
decentralization
as
there
are
several
not
necessarily
closely
related
initiatives
here.
E
The
first
one
being
is
an
open
options
right,
which
will
ensure
orderly
validator
set
rotation
that
is
transparent
to
both
users.
Validate
you
know,
users,
validators
and
outside
actors.
We
have
a
preliminary
design,
but
we
will
likely
need
to
revise
it
somewhat
once
it
actually.
You
know
the
time
comes
to
you
know,
get
to
implementation,
basically,
and
by
the
way
is
this
feature,
I
forgot
to
add
something
here.
E
So
beyond
this
we
have
planned,
for
you
know
designing
some
kind
of
you
know
the
tooling
for
monitoring.
You
know.
Economic
activity
on
the
platform
to
make
sure
is
that
everything
is
proceeding,
as
we
expect,
and
of
course
was.
You
know
assure
our
users
and
validators
that
you
know,
as
the
platform
is
operating
correctly.
E
This
will
probably
sit
on
top
of
something
like
clarity,
and
there
already
did
some
pieces
in
place,
I
think
put
in
by
other
teams,
but
roughly
this
is
still
to
be
designed
and
the
final
piece
for
transparency.
The
centralization
is
a
Fiat
pricing,
which
is
the
feature
I'm
actually
working
on
right
now,
and
this
basically
provides
a
you
know,
hard
prices
for
resource
cues.
E
A
A
E
A
C
E
E
E
That
is
very
strange.
Okay,
but
you
see
it
if
I
do
this.
Yes,
okay,
there's
something
about
how
he
handles
windows
all
right
right
right!
Oh
just!
Do
them
all
right!
So
well,
you
know
I
think
everybody
remembers
when
I
was
going
through
this
one,
so
I
went
through
the
you
know.
All
of
these
ons
economic
security
rewards
and
resource
management,
front
and
I
was
on
this
slide.
In
fact,.
A
E
You
know
we
were
on
Fiat
pricing
and
yeah,
so
obviously,
I
am
currently
designing
this
fiat
pricing
and
theoretically,
a
draft
should
be
done
by
and
where
was
this
victim
middle
of
next
week,
because
in
fact,
I
will
have
a
meeting
with
Jeanne
like
people
on
Wednesday,
and
the
final
bit
of
all
this,
you
know
is:
are
going
to
be
our
processes
for
feedback.
You
know
improvement,
implementation
and
incident
management
right.
So
these
are.
E
These
are
partly
government
dance,
but
what
unites
all
these
three
is
is
they're,
mostly,
you
know
community
oriented
right,
so
the
first
thing
is,
of
course,
RFC
process.
Right
I
mean
we
want
to
enable
community
to
discuss
improvements
and
iterate
upon
suggestions
in
an
orderly
manner.
That
would
ideally
know
for
good
suggestions
eventually
proceed.
You
know
towards
patch
all
right
again,
this
is
to
be
designed,
but
we
were
looking
at
a
number
of
sources,
including
I,
believe
rusts
community
processes.
E
For
this
second
bit,
the
stress
testing,
which
is
want
to
assure
the
platform,
can
manage
unusual
spikes
and
load
in
a
graceful
matter.
One
of
the
ideas
here
is
implement
in
a
formal
process.
For
you
know,
essentially
maybe
you
know
in
a
separate
test,
Network
for
kind
of
a
mass
scale.
Validator
exercises
right,
it
means
so
you
would
you
know
actively,
though
we
would
design
an
attack
and
then
a
leash
it
on
something
like
a
test
network
and
they
see
where
is
the
system
falls
down?
And
ideally
this
would
be
carried
out.
E
You
know
at
some
regular
cadence,
perhaps
I
dunno
like
every
three
months
or
something
like
that.
Right,
obviously
the
say
you
know
the
attacks
that
would
be
designed
could
also
be
you
know,
designed
by
the
community
itself,
possibly
through
some
kind
of
a
you
know,
some
a
secret
process,
so
nobody
has
time
to
prepare
for
it.
So
there
are
a
few
ideas
around
this,
but
there
are
you
know
yet
to
be
designed
and
for
the
final
piece
is,
you
know
really
the
you
know
the
real
incident
management
piece,
which
is
social
consensus.
E
So
as
we
do
research,
you
know
the
doors,
better
proof
of
stake
protocols.
If
you
always
encounter
situations
that
know
I
mean
it's
seems
fairly
obvious
that
it's
a
good
idea
to
have
some
kind
of
a
process
in
place
to
make
sure
that
the
platform
can
continue
to
operate
or
can
resume
operation
after
something,
like
you
know,
stole
the
you
know
stole
consensus
because
of
course
you
know
these
protocols
are
very,
very
difficult
to
model.
So
you
all
you
have
to
be
careful,
and
so
the
social
consensus
bit
is
something
that
you
know.
E
We
would
hope
not
to
use
except
you
know
in
validator
exercises,
but
we
should
have
in
place
just
in
case
right.
So
if
consensus
stalls
or
something
else
happens,
you
know
some
kind
of
a
you
know.
A
tags
at
some
code
changes
global
State
in
an
undesirable
manner.
Then
you
know
we
need
to
be
able
to
invoke.
E
You
know
a
process
that
will
somehow
lead
us
towards
a
fix
in
a
way
that
we
have
you
know
by
and
from
all
stakeholders
so
and
the
well
in
these
three
slides
I
think
I
covered
everything
that
we
current.
We
have
on
our
slate
as
things
that
we
know
should
have
implemented
by
main
net,
and
you
know
in
the
future.
Of
course,
you
know
we'll
be
continuing
to
work
on
other
features
and
improvements
to
these
features.
E
E
A
Now
this
looks
great
yeah
I.
Think,
though,
the
big,
the
big
hard
things
are
going
to
be
stress,
testing
and
social
consensus
right
and
eventually
will
will
come
up
with
an
initial
procedure
for
social
consensus,
but
it's
really
gonna
be
mostly
about
the
tooling
in
the
system
right
to
be
able
to
select
the
last
check,
point
and
restart
the
network
from
the
last
checkpoint,
etc,
etc
in
the
event
of
a
critical
issue,
and
how
that
all
works
same
thing
with
the
the
auctions
too,
so
I
think
we've
got.
A
A
A
To
the
live
feed
off,
okay,
so
I'm
gonna
walk
through
the
clarity
block
or
walk
you
through
the
different
functions
in
the
clarity
block.
As
for
how
I
have
used,
the
block
is
for
to
determine
that
the
network
is
healthy
or
in
some
cases
unhealthy.
So
there's
there's
some
information
that
in
the
user,
interface
of
the
block
is
for
that
may
not
be
obvious,
may
be
it
may
be
obvious.
It
may
not
be
obvious,
so
I'm
just
gonna
quickly,
walk
through
it.
A
So
folks
can
see
so
we'll
start
with
the
left
hand
side.
So
what
would
start
with
a
sign-in?
So
it
is
possible
for
you
to
sign
in
using
oh
I,
hope,
I,
don't
screw
everything
up
now,
okay,
it's
possible
for
you
to
sign
in
using
your
Google
or
your
github
account.
You
can
create
an
account
here
sign
in
and
then
you
can
go
into
account
keys
and
you
can
create
an
account
key
and
in
essence,
what
it
does.
It
creates
a
public/private
key
pair
on
the
casserole.
A
Oz
blockchain
does
not
create
accounts
on
the
node
right,
so
we
recognize
that
there
isn't
a
need
to
create
zero
balance.
Accounts
on
the
blockchain
right,
so
you
can
create
basically
a
public/private
key
pair.
It's
when
you
fund
that
public-private
key
pair
that
the
system
then
creates
the
account
on
the
network
so
right
now.
This
is
the
only
account
that
exists
on
the
blockchain,
because
I've
got
a
balance
right,
I've
used
what
I
have
funded
this
account
and
two
I
created
a
transaction
using
this
account
yesterday.
A
So
two
things
that
have
happened
with
this
account,
which
is
why
it's
got
not
a
you
know:
billion
dollar
moat
balance
on
it,
and
these
are
the
other
accounts
that
I've
created.
These
are
the
public
base.
16
keys,
I
hold
the
private,
a
secure
location
for
these
accounts.
So
as
long
as
I
have
the
private
keys,
I
know,
I
can
use
these
accounts
on
the
network
and
the
name.
So
when
I
create
a
key
and
I
called
it.
My
test
account
the
keys
that
the
system
provides
to
me.
A
Our
name
to
my
test
account
dot
public
key
and
my
test
account
dot
private
Docky,
and
so
that's
how
you
can
locate
your
keys
locally
on
your
system.
They
just
download
onto
your
local
machine
when
you,
when
you
do
this,
the
faucet
will
then
allow
you
to
select
any
one
of
the
accounts
and
then
submit
and
request
a
token
right.
So
if
I
want
to
do
a
funding
transaction,
this
is
the
public
key
and
I
just
hit
request
tokens
and
it
will
deploy
this.
B
A
And
here
you'll
see
that
we've
had
some
challenges
on
the
network.
You'll
see
here,
validators
creating
an
alternate
version
of
history
here,
but
this
this
alternate
version
of
history
doesn't
have
enough
stake
on
it.
So
the
version
of
history-
that's
finalizing,
is
the
one
with
the
green
arrows
right.
So
when
you
look
at
the
clarity
blocking
Spore
gray,
arrows
mean
it's
an
orphaned
block,
it's
not
finalized,
yet
green
arrows
mean
the
transactions
have
indeed
finalized.
A
So
now
what
I
just
did
is
I
clicked
this
hi
ballots,
I,
this
toggle
to
on/off
I've
turned
the
ballots
on
so
the
Castrol
apps
Network
uses
a
combination
of
what
we
call
active
stations
or
ballots
and
blocks
blocks
whole
transactions
at
the
moment,
ballots
or
add
to
stations.
Do
not.
We
have
a
version
of
the
protocol
that
supports
the
creation
of
blocks
as
attestations
as
well.
So
there
isn't
any
reason
why
any
number
of
these
ballots
couldn't
be
blocks
as
well.
A
The
difference
in
that
event,
the
leader
block
right,
will
need
to
download
all
of
the
attestation
and
process
all
the
transactions
that
complete
all
the
same
updates
in
order
to
finalize
they're
in
finalized,
the
last
round
of
blocks
right
and
so
blocks
get
finalized,
based
on
a
combination
of
attestations
and
stake
right,
so
the
system
needs
minimum
two-thirds
stake,
we've
moved
away
from
the
51%
stake
to
two-thirds
stake
because
we
believe
it
provides
more
security
in
the
network
and
more
security.
We
believe
is
always
better
right.
A
So
we
get
a
more
robust,
secure
system
if
we
go
with
two-thirds
stake,
I'm
having
to
finalize
blocks.
So
this
is
an
example
of
a
nice
healthy
network.
You'll
see
the
attestations
are
coming
through
cleanly.
You
can
definitely
see
the
demarcation
of
rounds
here,
so
this
is
around
and
this
is
around
right
and
so
in
each
round
you
see
a
leader
block
when
I
click
on
the
block
I
can
go
ahead
and
learn
a
little
bit
about
the
validator
that
proposed
the
blocks.
The
deploy
count.
A
I
can
see
it's
hash,
its
justification
rank
and
its
M
rank,
so
the
M
rank
means
this
is
block
number
739
in
the
in
the
block
chain
and
the
J
rank
or
the
justification
rank
is
98
65,
okay.
So
this
is
a
block
versus
a
ballot.
So
if
we
select
a
ballot
here,
this
is
a
witness.
The
rule
is
just
a
witness
to
other
blocks
vs.
proposal
all
right.
So
let's
take
a
look
and
see
what's
happening
when
things
kind
of
go
sideways.
A
A
You
can
actually
see
that
we're
starting
to
have
some
problems
right,
and
so
one
of
the
things
that
becomes
really
obvious
quickly
is
that
some
of
the
nodes
in
the
network
are
just
spamming.
Right,
they're
spamming
the
network
with
a
lot
of
attestations
right
now.
This
could
happen
for
a
variety
of
reasons.
A
One
of
the
reasons
is
that
the
node
is
not
able
is
not
receiving
blocks
right
or
something
has
gone
wrong
and
it's
local,
it's
local
view
of
the
dag,
and
so
now
it's
starting
to
send
a
lot
of
artists,
a
shion's,
because
it's
looking
for
a
block
that
it
can
vote
on
the
second
thing
that
could
potentially
happen
that
will
get
you.
This
look
is
that
the
node
is
running
very
fast
right.
A
So
if
you
saw
previously
there's
a
very
specific
cadence
between
the
blocks
right
and
and
you
see
the
justifications
and
a
night-
nice
tight
alignment,
but
if
our
our
system
is
partially
synchronous
right,
so
not
all
the
validators
have
to
run
at
the
same
pace.
Some
validators
can
go.
A
little
can
propose
blocks
and
anta
stations
more
frequently
than
others,
because
they
have
a
higher
bandwidth.
A
They
have
more
processing
power
and
so
because
they
have
more
horsepower,
they
can
participate
in
consensus.
More
frequently
versus
other
nodes
may
want
to
participate
in
consensus
less
frequently,
and
so
you
may
see
in
our
production
network.
Finally,
when
we
have
Auto
adjusting
Route
exponents,
you
may
see
some
validators
that
will
run
a
little
bit
faster
than
others
right,
and
this
will
enable
us
to
have
a
consensus
protocol
that
will
adjust
according
to
network
conditions.
So
if
the
network
suddenly
experiences
a
significant
slowdown,
all
of
the
validator
nodes
will
arguably
slow
down
right.
A
Alright.
So
this
is
how
so
one
of
the
ways
that
we'd
look
at
these
ballots
is.
We
can
see
the
valve
the
the
the
block
ash
and
in
front
information
about
the
validator,
so
we
can
see
the
validators
public
key
here
and
so
tom
and
I
have
a
list
of
validators
and
the,
and
we
know
what
their
public
keys
are.
So
we
can
identify
which
particular
validator
is
having
this
problem.
We
can
also
identify
the
validator
based
on
the
stake
right,
so
we
have
some
information.
A
A
Having
challenges,
we're
also
able
to
query
the
status
endpoint
and
the
status
endpoint
informs
us
what
the
last
finalized
block
was
for
each
of
the
validators
and
whether
the
validators
are
in
sync
right,
and
so
this
is
how
we
can
monitor
using
just
the
just
graph
on
a--
the
health
of
the
network,
not
Cortana.
Sorry,
just
the
block
is
for
the
health
of
the
network
to
see
whether
or
not
that
the
system
is
performing
properly.
A
You'll
notice
that,
despite
these
validators
having
problems,
we're
still
finalizing
blocks
right,
so
you
still
see
that
these
blocks
transactions
are
still
big
process.
Blocks
are
still
being
finalized,
even
though
some
of
the
validators
are
having
problems,
and
so
what
may
happen
in
those
situations?
Is
the
validators
will
restart
their
node
and
try
to
clear
their
stage
or
clear,
whatever
problem
they're
having
internally
and
then
rejoin
the
network?
A
It's
also
possible
to
look
at
blocks
and
see
the
blocks
as
they
get
created.
You
can
take
a
look
at
this
is
a
ballot
versus
an
attestation.
You
can
also
take
a
look
deploys.
I
recently
did
a
deploy
yesterday
from
my
test
account.
So
if
I
want
to
see
all
the
deploys
performed,
here's
my
deploy
hash
it'll,
show
me
how
much
the
deploy
cost
and
what
the
remaining
balance
of
my
count
is.
A
If
there
was
a
failure
result
here,
I
would
get
an
error
message
fact
from
the
glue
from
the
execution
engine,
but
I
didn't
have
any
failures
here
right,
and
so
it
also
show
me
what
other
transactions
happen
to
the
neighborhood
of
my
block
as
well.
I'm,
sorry,
my
deploys
and
then
here,
if
I,
want
to
search
for
a
particular
block
or
deploy
I
can
just
search
for
it
based
on
the
hash
and
connected
peers.
This
shows
me
basically
the
chain
spec
identification
identifier
and
they
host
IP
addresses
for
the
validators.