►
From YouTube: CasperLabs Community Call
Description
Rewards Distribution presentation & status update.
A
A
Good
morning,
everyone
welcome
welcome
to
the
Castro
labs
community
update,
call
today,
I'm
going
to
provide
an
engineering
update
status
of
where
we're
at
Oh
Noor
is
going
to
talk
about
bonding
auctions.
A
little
bit
will
provide
some
information
on
what
we're
thinking
about
how
validators
can
join
the
network
and
that's
something.
A
A
Inclusion,
ok,
all
right
inclusion,
bonds,
I
have
to
be
precise,
with
the
guys
you
know.
So,
let's
get
let's
dive
in
on
our
engineering
status.
So
the
team
started
a
new
release
cycle.
We
will
be
cutting
release.
19
we've
already
cut
it
out
of
github.
We
are
now
testing
it.
It's
it's
currently
in
test
with
sre
for
those
of
you
that
haven't
tuned.
In
recently,
we
did
restructure
the
organization
and
sre
is
taking
a
much
more
front-and-center
role
with
production
readiness
of
the
code.
A
Next
week,
our
new
release,
the
next
four
weeks
we
are
going
to
be
working
on
contract
headers
we're
going
to
upgrade
the
test
met
with
contract
headers,
as
well
as
a
multiple
key
support
and
we're
going
to
bring
token
transfers
host-side,
and
it
is
our
intention
to
run
another
performance
test.
You
ran
an
internal
performance
test
and
we're
continuing
to
fine-tune
the
system.
Today,
I'll
talk
a
little
bit
about
Omega
blocks,
I'm
planning
on
writing.
A
blog
post
about
Omega
blocks.
Omega
blocks
are
super
interesting
and
brings
us
closer
to
the
lower
overhead
numbers.
A
We
really
want
to
see
with
our
cast
for
implementation,
so
I'll
talk
more
about
Omega
blocks
later
in
the
call
all
right
scrolling
down
here,
so
we're
testing,
dot,
90
and
test
net
performance.
Yes,
so
I
can
talk
a
little
bit
about
Omega
blocks
and
Omega
block
is
basically
where,
instead
of
a
ballot,
you
send
a
block
right
and
for
those
of
you
that
are
familiar
with
Casper
Casper.
A
Has
this
notion
of
what
we
call
the
fork
choice
rule
which
is
basically
you
know,
a
set
of
justifications
which
are
pointers
to
other
blocks
or
state
transitions
and
in
the
liveness
proof
or
highway?
Basically,
you
have
this
notion
of
rounds
and
leaders,
and
in
each
round
each
validator
needs
to
show
up
right
and
vote
on
a
block.
It's
required
that
they
be
present
and
by
voting
you
can
look
at
our
you
know
previous
calls
or
nor
presented
the
liveness
throttling
or
liveness
reward
scheme
that
encourages
validators
to
participate
in
finalizing
blocks.
A
Otherwise
they
get
fewer
rewards
right.
So
there's
a
strong
incentive:
if
your
node
goes
offline
and
there's
a
liveness
failure,
you'll
be
you
know,
slashed
or
unbought,
not
slashed,
but
you'll
be
throttled.
You
won't
receive
any
rewards
for
not
participating
in
consensus,
and
so
you
can
vote
either
using
a
ballot,
which
means
you
have
no
transactions
to
process
or
a
block
which
means
you
have.
A
You
know
an
Omega
block
which
is
not
a
non
a
leader
block,
but
still
has
a
state-transition
associated
with
it,
and
this
enables
you
know,
produce
blocks
much
much
more
frequently
and
at
the
end
of
the
round,
all
the
state
transitions
become
finalized
by
the
leader
block,
so
the
leader
would
download
all
the
state
transitions
apply.
Them
propose
his
block
point
to
all
those
Omega
blocks
and
then
everything
would
be
finalized
depending
on
the
amount
of
state.
This
is
provides
a
nice
and
elegant
solution
to
getting
faster
turnaround
times
on
blocks.
A
It
doesn't
help
with
the
validator
that
can't
bring
his
own
transactions
right.
So
we
recognize
that
there
will
be
some
validators
that
will
be
front-end
for
deaf
developers,
where
they're
running
adapt
and
they're
bringing
their
own
transactions,
and
then
there
will
be
validators
that
are
purely
providing
validation,
services
on
the
network
and
those
validators
won't
necessarily
bring
their
own
transactions.
So
the
second
piece
of
this
is
potentially
deployed
gossiping,
which
we've
already
implemented.
A
The
next
booting
of
test
net
will
involve
running
the
test
met
with
deploy
gossiping
and,
in
the
meantime,
sre
is
going
to
be
testing
and
tuning
to
see
what
kind
of
configuration
we
can
have
between
deploy,
gossiping
and
omega
blocks.
So
what
is
the
fine
balance?
Because
we
recognize
that
both
use
cases
are
important
and
again
this
goes
to
how
we're
going
to
fine-tune
the
protocol.
So
we
can
get
the
best
perform
best
and
most
fair
and
equitable
right
platform,
so
validators
that
don't
bring
their
own
transactions
aren't
only
proposing
empty
blocks.
A
They
actually
have
transactions,
they
can
propose
versus
validators
that
are
always
meeting
to
propose.
Transactions
frequently
can
propose
those
during
each
round
as
an
Omega
block
producers.
So
that's
the
basic
idea
between
Omega
blocks
and
leader
blocks
and,
like
we
said,
as
we
are
checking
we're
testing,
deploy,
gossiping
right
now,
that
is
in
SRA
and
we'll
be
deploying
that
to
the
test
net
in
the
next
round.
A
Kurt
focus.
So
for
those
of
you
that
are
not
aware,
we've
kicked
off
a
rust
implementation
of
the
node
software.
We're
doing
this
for
a
variety
of
reasons,
namely
we
want
to
have
an
implementation
that
is
very
clean
and
backed
by
the
specification.
We
found
that
the
Scala
code
a
while
it
got
us
to
market
very
very
quickly.
A
There
were
lots
of
challenges
with
the
multi
multi
language
architecture,
namely
state
pruning
and
upgrades,
will
be
very
challenging
when
you're
having
to
deal
with
the
state
transitions
between
the
Scala
code
base
and
the
rust
code
base
or
the
rust
systems.
We
also
had
a
complicated
storage
model
because
each
instance
needed
their
own
sense
of
storage,
so
we've
kicked
off
a
project
to
basically
rewrite
everything
in
rust.
This
is
really
the
node
pieces
that
we're
rewriting
and
consensus
right,
so
node
and
consensus
and
communication.
A
So
we
have
some
work,
we're
doing
around
contract
headers
and
some
work
around
multi
signature,
algorithms,
not
multi
signature.
This
is
its
not
multi
signature,
a
joke.
You
need
to
update
that
this
is
multi
encryption
right
or
multi.
Crypto
cryptographic
signature
this.
This
looks
like
multi-sig.
It's
actually
not
multi-sig,
so
to
be
clear,
we're
going
to
be
supporting
aetherium
accounts,
as
well
as
our
accounts,
edie,
255,
91
and
secure
Enclave
right.
So
we're
supporting
different
encryption
screen
schemes
in
our
notion
of
account.
Validator
keys
will
still
need
to
be
ed2.
A
We're
implementing
a
basic
networking
component
on
the
rust
side,
their
node
rust
side,
we're
implementing
the
unified
storage
models
and
then
we're
starting
to
figure
out
what
the
relationships
and
data
models
are
between
consensus
and
the
node.
Our
intention
is
to
build
a
system,
a
base
architecture
that
has
pluggable
consensus.
So
if
we
want
to
drop
into
the
consensus
model
in,
we
can
absolutely
do
that
fairly
easily
fairly
easy,
not
super
easily
but
fairly
easily.
C
A
So
we're
working
contract
run
time
is
what
was
used
to
call
the
BM
or
the
execution
engine,
and
so
we
are
again.
This
is
multi
encryption,
algorithm,
key
support
and
then
we're
implementing
contract
headers
are
we
are.
We
are
we're
deprecating.
The
upgrade
contract
for
upgrades
stored
under
you
ref
is
that
correct,
yeah.
A
So,
as
as
a
part
of
contract
headers,
those
of
you
that
are
storing
your
contracts
under
you
ref
as
a
means
to
upgrade
them
contract.
Headers
we'll
simplify
this
significantly.
So
you
won't
need
to
do
that
anymore.
A
show
up
we
will
need.
Can
you
take
a
note
please
to
provide
some
documentation
for
users
on
what
they
will
need
to
do
to
port
their
port
away
from
the
UF's
over
to
contract?
Headers
I
think
I
still
need
that
documentation
on
what
is
the
workflow
of
using
contract
headers.
A
C
A
So
the
multi
key,
the
multi
signature,
they're
multi
encryption
algorithm
key
support
is
a
fairly
giant
change.
The
Python
client
will
need
to
be
updated.
Our
smart
contracts
will
need
to
be
updated.
The
clarity
block
Explorer
will
need
to
be
updated
because
that
creates
accounts
to
support
that.
We
will
also
need
to
update.
A
B
A
C
A
We
Kasper
labs
Jaya
stack,
updates
to
Chrome
extensions
store.
This
is
the
deploy
signing
deploy
for
the
browser.
So
this
is
our
version
of
meta
mask
for
lack
of
a
better
term
right
now
it
points
to
the
test
net,
so
it
uses
deploy
dock
as
well
as
at
I/o.
Is
that
correct,
Ashok?
That's
where
you
deploy
for
the
browser
right
yeah!
You
have
to
do
it
from
within
clarity.
I'm
gonna,
try
to
demo
that
I
knew
I
was
gonna.
A
Do
his
presentation,
I'm
gonna,
see
if
I
can
come
back
here
and
do
it
and
show
you
guys
and
then
we're
gonna
be
curating
a
voting
gap.
We
want
to
support
the
crypto,
chicks
hackathon,
so
we're
gonna
build
this
voting
decentralized
application,
Ashok
I,
believe
you
have
the
information
and
the
documents.
C
A
A
Okay,
good
economics,
research,
we're
updating
the
text
back
in
validator
guide,
actually
want
to
get
the
validator
guy
dropped
into
the
text
box,
so
we
should
probably
start
doing
that.
I
think
it's
reasonably
mature.
Now
we
should
make
sure
that
the
updates
around
the
gossiping,
chattiness
I,
think
tom
has
the
latest
tuna
balls.
You
can
actually
look
at
the
validator
onboarding
documentation,
Ashok
and
the
documentation.
That's
in
there.
We
should
get
that
into
the
validator
guide
and
then
we
can
probably
publish
it
and
get
that
information
into
into
the
tech.
Spec
repo,
okay,.
A
And
we're
narrowing
in
and
our
calculation
of
gas
costs
and
host
functions.
One
of
the
things
I'd
be
really
interested
in
I
was
thinking
about
this
o'nora,
and
this
may
be
an
interesting
thing
for
you
to
think
about
as
a
subsequent
follow-on
topic.
I
noticed
that
and
I
don't
actually
know.
This
is
true,
but
I
think
I'm
right
that
the
majority
of
computation
effort
put
in
a
round
proof-of-work
when
you
look
at
the
CPU,
spend
around
consensus.
Overhead
versus
processing
of
transactions.
A
I
would
be
willing
to
bet,
and-
and
we
should
probably
do
the
analysis
here-
that
a
majority
of
the
computation
in
proof-of-work
is
invested
in
consensus,
which
is
mining.
The
next
nonce
right
I
mean
that's,
really
consensus
right
when
you
go
through
the
process
of
mining
the
next.
Not
so
you
can
propose
a
block,
that's
consensus,
work
you're,
doing
right
and
I
would
be
willing
to
bet
that
is
probably
in
the
order
of
90
to
95
percent
of
the
machines.
Overhead
is
spent.
A
A
The
interesting
thing
is
that
the
rewards
associated
the
overall
economic
incentive
associated
with
the
etherium
actually
maps
out
the
same
way
right,
like
only
three
to
five
percent
of
minor
rewards,
come
from
transaction
fees,
95%
of
it
90
plus
percent
of
it
comes
from
block,
rewards
right,
the
right
and
so
it
maps
over
it
maps
over
pretty.
Well
sorry,
those.
A
Might
be
tangential,
but
but
but
it's
interesting
that
it
models
closely
the
consensus,
overhead
versus
a
transaction
processing
right,
so
the
consensus
overhead
is
probably
90%
of
the
total.
You
know
input
right.
The
total
output
rather
or
effort
on
the
machine.
95%
of
it
is
consensus
overhead
five
percent
of
it
is
probably
transaction
processing.
It
would
be
interesting
to
model
out
how
much
consensus
overhead
our
system
actually
has
right.
So
how
much
of
the
CPU,
because
all
CPU,
how
much
of
the
CPU
do
we
consume
when
we're
running
the
network
with
empty
blocks?
C
A
Actually,
you
would
actually
want
your
feet.
Your
rewards
to
map
to
that
right.
So,
if
our
consensus
overhead
is
like
you
know
it's,
you
know
it's
10%,
then
really
90%
of
the
reward
should
come
from
transaction
fee
processing
right
in
the
long
run,
and
that
gives
us
a
great
baseline,
for
you
know
how
much
transaction
should
cost,
but
I
found
that
very
interesting.
That
kind
of
just
it
would
be
cool
to
do
a
little
bit
of
research
around
that
it
may
be
present.
A
B
A
B
A
We
I
would
be
thrilled
if
we're
wildly
successful,
be
over
the
moon.
If
we're
wildly
successful
and
able
to
saturate
blocks
within
the
first
year,
but
I
don't
think
that's
going
to
be
the
case.
It'd
be
amazing.
We
did
we're
good
and
we're
already
starting
to
do
the
research
work
on
sharding
right,
so
sharding
and
sidechained
research
is
already
underway
because
we
know
we
need
to
prepare
for
how
to
shard
and
scale
out
highway.
Yes,
yep
we're
modeling
some
distribution
effects
of
the
token
vintages
proposal.
Token
vintages
proposal
basically
answers
the
question
of
hey.
A
Why
should
I
bother
being
a
bonded
validator
for
a
long
time
right,
and
our
thinking
is
that
we
want
to?
We
want
the
network
to
preferentially
reward
those
validators
that
have
remained
bonded
for
a
long
time
with
additional
rewards.
So
that's
token
vintages,
fantastic
I'm,
going
to
turn
it
over
to
you
own
or,
and
while
you
do
that,
I'm
gonna
try
to
see
if
I
can
do
a
demo
of
a
deploy
from
the
browser.
So
that's
what
I'm
gonna
go
work
on.
Well,
you
could
do
that.
B
Yeah,
like,
like
I,
said
it's
the
bond.
The
word
bond
here
is
not
used
in
the
context
of
bonding
and
non-bonding.
It's
in
the
it's
used
like
an
IOU,
which
means
like
here.
I
will
present
it
just
in
in
a
bit,
but
validator
can
include
another
validators
transaction
and
then
the
validator
doing
that
so
there
who
gets
his
transaction
included
becomes
somehow
like
indebted
to
the
one
the
validator
who
includes
it.
So
this
is
about
free
gas
without
further
ado.
Let
me
start
so:
let's
assume
a
generic
proof.
B
Proof
of
state
protocol
valid
leaders
take
turns
proposing
blocks.
Number
of
blocks
proposed
by
a
validator
is
directly
proportional
to
his
weight,
which
is
like.
If
Alice
takes
2
to
X
tokens
and
Bob
stakes
to
X
tokens,
then
if
Alice
proposes
y
blocks
in
a
time,
you
would
expect
that
Bob
proposes
to
2y
blocks
per
unit
time,
and
then
that
also
affects
like
block.
B
We
have
this
block
size
limit,
so
blocks
have
at
capacity
roughly
the
same
number
of
transactions,
so
number
of
transactions
included
on
average
is
calculated
by
multiplying
with
weight
simply
so
if
the
network
process
10
million
transactions.
Last
month
and
Alice's
weight
is
5
percent.
You
would
expect
roughly
Alice
to
have
included
like
500k
transactions
last
month.
This
is
basic,
so
coming
to
the
problem
at
hand,
talking
about
transaction
fees,
I'm
going
to
talk
about
this
proposal
gets
all
scheme.
In
this
case,
it's
like
just
like
a
proof-of-work.
C
B
In
in
proof,
over
in
Bitcoin
and
cerium,
the
miner
gets
the
transaction
fees
attached
to
the
transactions,
so
in
proof
of
stake,
let's
assume
we
have
the
same
model,
Alice
signs
some
transactions,
but
doesn't
publish
them.
Instead,
when
it's
her
turn
to
propose
a
block,
she
just
includes
them.
That
means
Alice,
just
paid
the
transaction
fee
to
herself
Alice
just
got
included
a
transaction
without
ever
you
know
paying
for
it.
Just
by
having
stake
some
tokens-
and
here
Alice
can
also
be
adaptive,
Ella
/,
using
payment
code
to
pay
pay
for
her
users.
B
So
given
given
Alice's
weight,
she
would
have
the
right
to
include
weight,
multiplied
by
total
transaction
per
second,
and
if
the
number
of
users
increase
and
she
needs
more
throughput,
she
would
simply
increase
her
weight
by
stating
more
that's
like,
like
as
a
validator
Alice
has
a
quarter
of
of
transactions
that
she
can
get
included
per
unit
time
and,
let's,
let's
talk
about
delegate
errs
because
it's
also
relevant
here
we
have
Dan
had
app
developer.
Dan
also
wants
to
get
free
gas,
but
he
doesn't
want
to
become
a
validator.
B
Here.
Dan
enters
an
agreement
with
Alice
Dan.
It's
an
implicit
agreement.
It's
not
enforced
by
the
protocol
down
we'll
shares
transactions
only
with
Alice.
Then,
when
Alice
includes
them,
she
will
relate
the
transaction
fees
back
to
them,
after,
of
course,
getting
a
commission.
This
is
a
usual
in
delegator
markets
like
if
you're,
if
you
are
getting
some
rewards
by
delegating
there
is
always
a
commission
also
for
transaction
fees
so,
but
but
generally
and
current.
Currently,
in
other
projects,
we
see
this
these
Commission's
to
be
low,
so
Dan
gets
a
highly
discounted
or
free.
B
Yes,
like
you
could
like
nine
nine,
nine
Dan
can
get
92
to
95
percent
or
to
98
percent
of
his
transaction
fees
back
without
becoming
a
validator.
It
depends
on
the
analysis,
commission
rate,
so
it's
not
the
only
way
of
getting
free
guests
just
by
being
a
delegator
and
having
this
sort
of
implicit
agreement
between
but
like
with
the
the
validator
you're
delegating
to
you
can
also
have
free
gas.
So
here
you
see
that
staking
sorry,
a
delegation
converts
effects
into
capex,
like
the
first
step,
is
develop
a
DAP.
B
So
it's
like
so
these
double
entendre
I,
don't
know.
I
just
feel
felt
like
saying
it
I'm,
not
a
native
speaker.
So.
B
So
we
have
a
problem
here,
though,
like
this
is
a
very
good
deal
for
delegate
errs
the
validator
for
the
validator
Alice
has
to
wait
until
it's
her
turn
to
propose
in
order
to
include
transactions
down.
Also,
if
Dan
Boneh
delegated
to
Alice,
then
Dan
has
to
wait
under
this
Alice's
turn
to
propose
so
say:
Alice
has
one
percent
wait.
Alice
can
propose
one
in
every
hundred
blocks.
That
means
time
to
find
out.
The
increase
on
the
100
fall
like
if
it
were.
If
you
had
eight
second
block
times
before
now,
you
have
800.
B
B
So
let
me
let
me
leave
a
note
here.
We
just
said
we
are
considering
Omega
blocks.
Omega
blocks
means
a
validator
can
in
in
her
ballot
messages
in
every
round
include
transactions.
So
that's
kind
of
alleviate
this
problem,
but
yeah,
it
all
depends
on
the
network
parameters.
How
many
transactions
one
can
include.
We
have
possible
solution,
maybe
so,
if
the
letters
get
free,
yes
anyways,
why
not?
Why
not
make
validators
example
of
paying
fees
for
transactions?
B
They
can
just
get
0
a
gas
price,
but
the
problem
is,
then:
there
is
no
incentive
for
a
validator
to
include
another
velvet
ears
transaction,
so
they
could
be
filling
the
same
block
space
with
a
regular
users
paying
transactions.
So
you
wouldn't
see
any
validator
pick
up
a
validator
pick
up
and
other
validators
transactions
because
they
wouldn't
be
incentivized
for
it,
a
solution
I'm
proposing
to
this
our
inclusion
bonds.
This
is
a
sort
of
financial
aid
like
protocol
enforced
financial
agreement
between
validators.
B
C
A
B
Sorry
is
there
was
some
noise
at
my
flat
yeah,
so
it
is
Bob
Stern
yeah,
the
transaction
fee
is
calculated
as
F,
however,
Bob
doesn't
receive
it,
so
normally
the
proposer
gets
it,
but
here
instead,
instead
of
receiving
it,
you
have
an
inclusion
bond
created,
it's
sort
of
an
IOU
and
the
fee
is
locked
inside
it.
So
here
it
means
that
Alice
or
Bob,
the
TX
inclusion
worth
of
F
tokens
and
neither
Alice
or
nor
Bob
can
use
tokens
until
Alice
settles
the
ID
by
including
one
of
Bob's
transactions.
B
So
I
mean
I
outlined
some
possible
scenarios
here,
let's
say
the
IB
sits
for
a
while
then
Bob,
it's
time
for
Bob
to
publish
a
transaction
and
then
Alice
picks
it
up
and
infuse
it.
The
resulting
fee
for
Bob
is
G
tokens
depending
on
the
amount
we
have
three
options:
I
won't
read
them
at
all,
so
it
could
be
either
Bob
spending
less
than
Alice.
Then
the
IB
would
not
be
settled.
B
It
would
have
an
outstanding,
but
you
know
some
of
the
tokens
will
be
returned
to
Alice
if
it's
equal,
if
it's
Bob
spent
the
same
amount
as
Alice
than
the
IB
settled,
it
will
cancel
out.
If
Bob
spends
more
than
Alice,
then
the
existing
I
be
settled
and
a
new
one
is
then
created,
and
here
Bob
owes
Alice
and
inclusion
worth
of
you
know
the
amount,
the
difference
between
the
two
values.
B
This
is
how
it
wealthy
works,
and
it
can
be
so
it
is
opt
in
right.
If
a
validator
is
okay
with
generating
an
IB,
he
can
set
a
flag
in
a
transaction
header.
So
if
one
option
is
like
not
allowed,
proposal
directly
receives
a
resulting
feat.
Then,
if
the
transit,
the
evaluator
may
allow
it,
but
there
is
no
like
most
proposer,
can
choose
to
receive
or
create
an
ID
and
a
transaction
could
be
like
IB
only
when,
if
it's
included,
then
for
sure
there
will
be
an
IV
created.
B
So
you
could
have
all
these
different
options
corresponding
to
different
needs
of
valuators
and
the
leaders
generate
IDs
based
on
their
own
throughput
of
their
own
troop
food
allocation.
So,
like
I'm
I
had
this
throughput
I
had
this
block
space
that
I
can
fill
as
a
validator
and
I
keep
track
of
it
and
others
keep
track
of
mine
everybody's
keeping
track
of
each
other
in
every
every
I.
B
In
fact,
it's
being
done
like
program
app
programmatically,
not
not
manual,
it's
done
by
the
software
and
the
software
you
can
make
the
software
choose
the
optimal
strategy
you
desire
for
you.
So
let's
say,
like
Bob
sees
that
Alice's
outstanding
IDs
are
close
to
her
throughput
allocation.
Then
Bob
chooses
not
to
enter
into
anymore
IVs
with
Alice,
because
and
there's
a
high
chance.
She
will
not
be
able
to
return
the
favor
so
because
alice
is
at
capacity
for
doing
papers.
B
She
wouldn't
be
able
to
do
any
more
favors,
so
let's
not
make
Alice
than
you
fit
more
favors
because
yeah,
it's
pointless,
there's
also
the
another
point.
There
is
a
certain
lag
until
transaction
fees
relate
back
so,
like
you
are
getting
free
gas,
but
you're
not
getting
it
immediately.
You
pay
for
it.
Then
you
have
to
wait.
If
there's
an
IV
I
mean
if
you're,
not
including
it
yourself,
there's
a
lag,
you
have
to
wait
until
the
other
person
relays
it
back
to
you.
B
B
So,
as
a
summary,
I
beez
allow
evaluators
to
keep
an
account
of
inclusion
of
each
other's
transactions.
The
fee
is
locked
up
until
the
favor
is
returned,
the
debtor
has
an
incentive,
or
the
LeSabre
issuer
has
an
incentive
to
include
the
creditors
transaction
or
the
holders
transaction
to
receive
back
the
fee
in
a
functioning
system.
Violators
keep
track
of
IDs
like
they
favor
it's
also.
B
It's
also
not
like
there
could
be
malicious
valuators
and
there
could
be
honest,
evaluators,
honoring
the
agreements
or
not
honoring
the
agreements,
so
you
would
keep
track
and
you
would
favor
the
transactions
of
values
who
I
returned
the
favor
in
the
past.
You
would
refrain
from
including
the
ones
that
they
that
didn't
as
the
last
point,
what
about
inclusion,
bonds
and
delegate
errs?
So
I
beez
functions.
Similarly
with
delegate
errs
that
specifies
Ellis
as
the
issuer
of
the
IB
in
his
transaction
header,
then
bob
includes
Alice's
transaction,
generating
an
ID
between
Alice
and
Bob.
B
B
There's
a
caveat
here
so,
while
interval
leader
agreements
are
enforced
by
the
protocol,
Valliere
delegator
agreements
do
not
have
to
be
I
previously
said
it's
implicit.
So
as
a
delegator,
you
would
want
to
choose
validators
like
bond
route,
evaluators,
who
are
performing
well
for
honest
who
haven't.
You
know,
made
any
made
any
malicious
behavior
in
the
past.
I
tricked
you
into
you,
know
delegating
and
then
not
not
gave
you
your
rewards,
so
Alice
can
track
whether
Dan's
delegation
is
enough
to
cover.
So
this
disagreement
is
implicit.
B
It
gives
enough
freedom,
so
it
it's
also
leaves
the
like
makes
the
protocol
more
free.
The
protocol
does
not
have
to
know
what
happens
between
evaluator
and
delegator
when
it
comes
to
transaction
fees
for
senior
age,
yes,
but
for
transaction
fees.
If
the
protocol
is
proposal
gets
all
if
the
distribution
scheme
is
like
proposal,
yes,
so
then
you
could
have
this
freedom
and
it's
somehow
you
know
there
could
be
there
could
be.
You
could
also
have
it
in
first,
but
it's
a
matter
of
approach,
so
we
would.
B
We
would
weigh
the
different
options
and
then
go
with
the
one
that
makes
most
sense
in
this
case.
I
could
be
a
delegator
like,
but
maybe
I
didn't,
maybe
as
like
I'm
then
and
I
I'm
sending,
but
like
gazillion
transactions
and
my
my
delegation.
My
bond
amount
isn't
enough
to
cover
them.
So
then
else
can
choose
not
to
not
to
relay
the
feedback
to
me,
because
ours
can
just
say
you
haven't
bonded
enough.
B
A
A
Yeah
I
don't
know
if
slideshare.net
is
the
right
place
to
go
where
you
can
easily
see
them
or
if
we
wanted
to
put
them,
you
want
to
put
them
into
google,
google,
external
CL
Drive,
that's
fine
too,
and
put
links
on
they
and
the
governance
page.
Maybe
we
can
go
back
through
and
put
a
repository
of
all
the
presentations
were
able
to
look
at
so
I
tried
to
set
up
the
docker
hack.
Unfortunately,
there's
an
issue
with
the
Python
client.
A
We
deprecated
the
integration
test
and,
as
a
result
of
it,
the
Python
client,
the
integration
test
framework
isn't
working
correctly,
but
there's
an
unrealized
dependency
with
the
hack
docker
and
that's
so
a
shock
I
need
you
to
fix
this
cuz.
The
hack
Dockers
got
to
continue
to
work.
It's
just
way
too
nice
and
easy
to
use.
So
let's
get
it
fixed,
so
the
clarity
browser
we
refer
to
it
pretty
frequently
in
our
documentation.
So
it's
important
that
we
get
it
working,
but
in
the
meantime
what
I
can
do
is
I
can
definitely
show
you
guys.
A
We
can
arrange
for
our
hands
on
a
much
better
demo,
maybe
next
week
or
after
it
releases,
but
right
now
we're
looking
at
the
pull
request,
pull
request,
18:21
that
abner
built
the
Chrome
Web
Store
has
the
Casper
lab
signer
in
there
we're
still
working
on
getting
it
officially
trusted
and
we'll
get
a
logo
in
there.
Ashok
is
working
on
that,
but
basically
it's
a
signing
extension
that
will
reach
into
your
private
key
and
sign
a
deploy,
it'll
work
in
conjunction
with
clarity.
A
A
A
Going
once
going
twice
terrific,
so
we've
got
some
action
items
Ashok.
Let's
get
the
repository
of
the
slide
deck
presentations
that
we've
given
and
put
those
in
our
governance
give
up
in
a
place
where
people
can
get
to
it
and
then
we'll
prepare
a
demo
for
next
week
of
the
deploy.
Signing
yeah
sounds
good
thanks.
Everyone
for
dialing
in
have
a
great
week.