►
From YouTube: CasperLabs Community Call
Description
Rewards Distribution presentation & status update.
A
A
A
A
A
Thank
you
for
joining
this
morning,
we've
got
a
great
community
call.
We
are
gonna
talk
about,
of
course,
our
engineering
status
update
and
then
I'm
going
to
turn
it
over
to
own
or
who
is
going
to
walk
us
through
rewards
distribution
in
the
highway
protocol
and
yeah.
So,
let's
just
dive
right
in
right
now
so
Engineering
status
we've
got
node
dot,
twelve,
that
is
planned
for
February
13
2020.
The
team
entered
sprint
28
on
Monday
this
week.
We
also
did
our
sprint
demos,
which
I
will
be
sharing
with
everyone.
A
So
you
can
see
a
deep
dive
on
what
the
team
is.
Building
node,
0.11
it
the
release,
is
being
cut.
Tom
is
building
that
release
out
right
now.
I
expect
to
see
that
drop
in
github
shortly
we'll
be
updating
dev
net
tomorrow
with
the
AI
that
we
will
have
a
weekly
workshop
on
Thursday
at
8
a.m.
and
4:00
p.m.
A
Pacific
time
to
work
with
node
11
I'll
be
resuming
those
weekly
workshops
on
a
weekly
cadence,
as
the
title
indicates,
I'm
asserting
bi-weekly,
and
the
focus
is
going
to
shift
to
a
little
bit
more
to
smart
contract
development,
but
also
helping
validators
get
set
up,
as
we
have
started.
Having
validator
interests
come
through
to
us,
so
we'll
be
helping
on
board
those
validators,
so
you'll
see
expect
to
see
a
good
number
of
sessions
around
getting
started
in
running
the
node
and
working
with
the
node
on
the
team
front.
A
Piatra
do
Becky
I
probably
said
that
wrong
joins
the
team
as
a
project
manager,
ecosystem,
community
and
app
developer.
Ux
reporting
in
to
him
we'll
be
matching
Solinsky.
Our
contract
developer,
hope
our
tech
writer
Zoltan
radix,
who
also
joined
us
as
a
web
developer
and
I
keep
forgetting
the
fourth
person.
There's
one
more
person,
I'm
I,
feel
like
such
a
schmuck
for
not
getting
that
Abner
Abner
Zhang.
Yes,
who
works
on
clarity?
Thank
you
this
because
he's
not
a
new
person.
So
I'm
messing
up
on
that.
Thank
you.
A
So
again,
we've
got
our
dev
net,
we'll
be
updating
that
this
week
with
the
latest
release,
our
focus
is
full
force
on
implementing
production
version
of
highway
with
Araz
and
switch
blocks
and
we're
also
working
on
including
bonding
auctions.
As
part
of
the
bonding
process,
we
are
actually
implementing
assembly
script
in
the
execution
engine
and
we're
actually
getting
documentation
to
support
smart
contract
development.
I'll
talk
more
in
details
about
that
performance,
stabilization
and
ramping
up
of
our
infrastructure
for
testing
in
preparation
for
test
net.
This
is
going
to
required,
larger
and
faster
and
more.
A
You
know
more
broader
based
testing
network
network
level,
testing
versus
integration
or
unit
test
level
testing,
and
then
we're
also
going
to
be
removing
system
contracts.
So
we've
got
this
generic
notion
of
system
contracts
right
now
and
we
found
that
we
can
literally
double
the
performance
of
our
execution
engine
by
moving
those
contracts
fully
into
the
EE,
and
so
we
are
specifying
what
that's
going
to
look
like
and
we'll
probably
implement,
have
Andreas
implement
that
fully
in
the
execution
engine
next
sprint.
So
sprint
29
will
probably
get
that
done.
A
It'll
probably
take
a
couple
of
Sprint's
to
completely
implement
that
on
consensus.
We
are
extending
the
prototype
and
implementing
production
code.
If
you
look
in
github,
you
will
see
those
pull
requests
there
for
eras,
that
a
coach
has
been
building.
That's
the
production
code
for
eras
and
Michael
has
actually
got
a
production.
A
protocol
prototype,
so
Michael
is
kind
of
running
ahead
and
doing
the
prototype
and
work,
and
then
a
coach
is
building
the
production,
implementation
and
then
Matteo
she's
getting
involved
in
that
too.
A
So
that's
kind
of
our
workflow
for
getting
highway
working
in
parallel
with
that
Wojtek
is
building
out
his
simulator.
So
he's
going
to
be
building
a
simulator
that
simulates,
you
know
the
the
different
round
lanes
the
slow
and
fast
validators
playing
around
with
time
right.
So
the
simulator
lets
us
play
around
with
time
and
very
interesting
ways.
A
And
we're
also
working
on
the
equivocation
detector
to
detect
ballot
equivocation.
So
this
is
really
around
you
know
being
able
to
detect
equivocations
in
the
in
the
protocol
and
then
slash
for
them
on
the
execution
engine
very
excited
that
we
are
going
to
be
releasing
a
contract
development
kit.
This
will
enable
developers
to
use
an
IDE.
So
basically
there
will
be
like
a
imagine,
a
rust
project
that
you
can
open
up
and
inside
that
project
you
will
have
an
instance
of
the
execution
engine.
A
All
of
your
you
know,
example:
smart
contracts
that
will
enable
you
to
author
a
smart
contract
and
then
run
it
in
the
e
implement
breakpoints
and
see
how
the
effects
are
in
the
global
State
all
within
an
IDE
type
workflow.
The
team
is
also
building
the
contracts
FFI
to
support
development
in
assembly
script.
A
We
got
a
demo
of
some
of
the
work
they
are
about
70%
of
the
way
through
there's
some
edge
cases
that
they'll
be
implementing
over
the
next
couple
of
Sprint's,
and
we
expect
assembly
script
support
to
drop
in
time
for
the
alpha
test.
Net
super
excited
about
that
and
the
goal
is
that
will
also
have
documentation
to
support
the
contracts.
A
Ff
I
for
assembly
script,
hopefully
by
the
note,
13
timeframe
and
performance
improvements
as
I've
alluded,
eliminating
the
system
contracts
and
implementing
them
in
the
execution
engine
gave
us
about
a
2x
speed
up
with
the
assembly
script
work
we're
actually
going
to
have
assembly
script,
doesn't
give
you
a
good,
strong
type
system,
but
we'll
be
implementing
the
types
so
you'll
get
the
benefit
of
a
type
system
for
assembly
script,
smart
contract
development
on
the
node
front,
we're
doing
stability
and
optimizations
performance,
a
node
we're
adding
more
relationships
to
graph
QL.
This
will
extend.
A
You
know
better.
The
the
information
you
can
derive
from
or
obtain
from
graph
QL
about
the
internal
state
of
your
contracts,
and
then
we've
also
seek
par,
is
basically
key,
sequential
or
parallel
execution
of
contracts.
Within
a
given
block,
so
no
contract,
authors
can
basically
define
if
they
want
their
contracts
to
execute
sequentially
or
parallel.
Obviously,
we
want,
as
many
of
the
contracts
execute
in
parallel
as
possible.
A
great
example
is
a
reservation
system.
A
If
you're
trying
to
sell
tickets,
you
want
multiple
transactions
to
go
through
at
the
same
time
as
long
as
they're,
not
trying
get
the
same
seat
right.
So
this
is
a
feature
of
the
cazuelas
blockchain
that
does
support
concurrent
and
parallel
execution.
Even
at
the
blockchain
level.
On
testin
sre,
we've
got
definite
security.
The
dev
net,
because
it
is
a
public
property
in
the
the
clarity
block
is
for
it
does
frequently
get
attacked
by
friendly
hackers.
A
So
we're
always
upgrading
that
and
making
sure
that
it's
got
the
latest
and
greatest
security
patches,
standing
up
and
initializing
a
test
pad
environment,
optimizing,
CI
and
then
LRT
enhancements.
These
all
are
around
supporting
a
large
scale
testing.
So,
if
you
imagine,
we
now
have
all
of
our
tests
that
are
in
rust.
We
need
to
duplicate
them
and
have
them
an
assembly
script.
We
can't
have
our
CI
take
twice
as
long
so
we're
working
on
parallelizing
that
so
multiple
tests
can
run.
A
At
the
same
time,
this
will
be
a
much
more
efficient
use
of
our
AWS
infrastructure
and
LRT
enhancements
of
support
large
scale
testing.
This
is
really
around
spinning
up
entire
networks
and
deploying
high
speed
transactions
to
the
networks.
So
we
can
really
start
looking
at
the
system
from
a
performance
engineering
perspective,
what
we
refer
to
as
site
reliability,
engineering.
Basically,
you
push
the
system
till
it
falls
over
and
you
take
a
look
at
the
metrics
to
see
what
the
leading
edge
indicator
is.
That
indicates
the
system
is
no
longer
healthy.
A
This
is
really
important
for
all
of
the
node
operators.
Validators
that
are
going
to
be
running
systems,
force
takers,
they're
going
to
want
to
know
that
the
system
is
always
healthy
and
you
know
if
a
system
is
becoming
unhealthy.
What
does
that
look
like?
So
we
are
doing
that
work
internally.
First,
to
make
sure
the
system
is
performing,
it
will
be
partnering
with
our.
You
know.
A
Staking
providers
to
you
know,
stay
service
providers
and
node
operator
services
as
well
to
to
further
this
kind
of
testing
ecosystem
we're
working
on
a
Zeke,
a
stark
example
where
we're
reviewing
and
organizing
technical
documentation,
creating
that
def
developer
documentation
I
got
a
preview
of
it
and
slate.
It
looks
beautiful,
very
excited
about
this
to
provide
a
really
nice
stop
developer,
guide
that
walks
DAP
developers
through
the
advanced
features
of
the
system
and
enhancements
to
clarity.
A
We
continue,
making
our
clarity
Explorer,
easier
and
friendly
to
use
and
provide
more
insights
into
the
network
economics
research,
we're
doing
a
lot
of
work
on.
You
know
spam
protection
delegation
and
centralization
and
decentralization
we're
doing
a
mock
up
for
reward
distribution
in
Python.
So
we
can
understand
how
rewards
are
going
to
work
and
we're
going
to
present
rewards
and
highway.
Today
the
team
is
planning
for
an
off-site
in
San
Diego
in
February
of
2019.
We
chose
San
Diego
because
our
focus
is
consensus
and
we
want
some
time
with
dr.
A
Daniel
Caine,
so
Dan
Caine,
as
you're
well
aware,
is
located
in
San
Diego,
so
the
team
will
be
meeting
with
Daniel
during
the
off-site
to
talk
about
edge
cases
and
what
we
have
learned
as
part
of
highway.
The
goal
is
to
try
to
not
sacrifice
concurrency
and
performance
for
liveness,
but
find
a
good
happy
medium.
We
have
intuitions
around
how
this
is
going
to
work,
but
we
want
to
extend
our
theoretical
research
around
that
as
well.
A
In
addition
to
that
talk
with
Daniel
about
sharding
and
what
Charlotte
consensus
could
potentially
look
like
as
a
fast
follow-on
to
our
main
net
release
with
that
I'm
going
to
call
for
any
questions.
If
there's
any
questions
both
on
the
community
channels
via
discord
or
otherwise,
I
can
pause
for
there
and
then
slowly
turn
it
over
to
own
or
to
present
economics.
So
I'll
just
give
a
quick
pause
for
any
questions,
and
if
there's
no
questions
either
on
YouTube
or
discord,
I
will
turn
it
over
to
own
or.
B
So
we
have
like
form
formulaic
Lee
is
set
set
out
reward
distribution
which
you
can
look
up
by
following
the
link
I
gave
here,
but
like
this
one,
the
second
D
is
just
a
work
in
progress,
so
we
will
eventually
add
to
either
our
like
theoretical
paper
or
the
tech
spec.
So
I
will
just
give
like
an
overview.
Non
technical,
like
semi
technical
overview
to
how
we
were
distribution,
is
gonna,
work
in
highway
and
a
pitfall.
B
B
A
B
B
It
will,
it
will
be
a
block
proposal,
will
get
faster
or
slower,
depending
on
either
supply
and
demand
or
or
the
connectivity
all
connectivity,
and
we
expect
to
see
like
a
an
order
of
magnitude
change
in
a
in
a
given
day.
So
this
is
unlike
Bitcoin
or
a
theorem,
where
you
have
a
block
time
like
10
minutes.
There
is
a
variance
to
that,
but
you
can
expect
roughly
that
all
blocks
are
gonna
like
a
each
block
is
gonna.
B
A
new
blog
will
come
in
the
next
within
the
next
ten
minutes
and
the
what
what
determines
round
lengths
is.
This
parameter
every
validator
sets,
which
is
a
round
exponent
and
in
every
message
you
can
say,
set
your
round
exponent
round
exponent
as
it's
in
the
name.
So
the
round
length
is
easily
calculated
by
2
to
the
power
round
exponent.
If
you
have
radix
point
5,
you
have
your
round
length
is
2
to
the
power
5
32
here.
Are
you
an
example?
B
A
A
B
So
in
this
case
the
first
two
rounds
have
the
round
length,
sorry
for
for
4
milliseconds,
and
this
is
just
an
example
like
we
don't
expect
it
to
be
4
milliseconds,
at
least
at
least
a
few
seconds,
because
that's
the
time
required
to
properly
a
message
to
the
whole
network,
regardless
of
the
technology.
That's
what
the
global
network
infrastructure
allows
us
have.
You
need
at
least
a
few
seconds.
B
So
in
the
second
round,
you
can
see
that
a
the
validator
announces
a
new
round
exponent
3
the
before
before
that
change
is
registered.
The
current
round
must
end.
So
when
it
ends
a
new
round
starts
which
has
a
length
8,
ticks
and
just
to
demonstrate.
I
change
the
round
length
back
to
4,
like
announced
a
new
one
here,
and
for
that
for
that
change
to
happen.
That
round,
which
has
already
started,
must
again
end.
So
as
soon
as
is,
and
it
ends
the
new
round
which
stars
is
again
has
around
length
4.
B
C
B
Length
so
be,
although
be
announced
as
a
new
round
length
here,
which
is
16
the.
So
this
is
wrong.
This
is
the
first
tick.
We
need
to
have
all
these
all
these
rounds
start
and
finish
before.
We
can
start
it
round,
which
is
16
long
16
takes
too
long
so
round
length
changes
can
be
registered
only
at
the
next
tag,
which
is
visible
by
the
new
announced
round
length.
This
is
a
this
is
a
detail
like
this
is
how
our
protocol
works.
B
One
small
detail,
which
I
added
after
meta
warned
me
so
the
round
exponents
are
not
updated
manually,
so
this
is
an
automatic
process
which
is
done
by
the
client
software.
Whenever
we
failed
to
finalize
the
leader
block
before
the
end
of
the
round,
we
increase
increase
our
round
length,
so
this
is
something
directly
detectable
by
each
violators.
Client,
and
this
this
is
I'm,
giving
an
overview.
The
schedule
will
determine
how
their
ores
are
distributed.
That
is
why
I
am
explaining
it
not
because
Baldur's
will
have
to
follow
their
round.
B
B
If
you
have
a
tick
and
if
validators
there
are
a
leaders
whose
round
started
to
tick,
for
example
the
first
one
here,
then
the
assigned
weight
is
equal
to
the
total
weight
of
the
violators
whose
rounds
start
at
the
tick.
So
in
the
first
take
you
have
all
three
I
here:
I
assume
each
have
like
1/3
of
a
stake,
so
they
add
up
to
100%,
but
each
each
is
like
33%
and
2.
B
If
you
see,
if
you
look
at
the
fifth
tick,
then
you
would
see
it
has
66
percent,
because
a
C's
round
doesn't
start
at
50.
Si
si
announcer
round
exponent.
That
is
twice
sorry
one
more
than
a
and
B.
It
has
twice
the
round
length.
So
in
every
two
rounds
the
assigned
weight
is
66%,
so
it's
funded
percent
every
two
rounds
and
in
every
odd
round
so
even
round
it
is
six
or
6%,
and
that
is
that
is
how
we
calculate
assigned
weight.
Let
me
also
explain
what
these
letters
letters
mean.
B
In
our
protocol,
this
is
the
definitions
are
in
the
tech.
Spec
L
stands
for
lambda
message:
R
stands
for
the
lambda
response.
Message
and
post
stands
for
Omega
message,
so
the
lambda
message,
lambda,
is
letter
assigned
I
believe
from
leaders,
so
leader
be
assigned
Greek
letters.
So
it's
the
leaders
message,
which
means
that
the
London
message
contains
the
block.
So
this
is
basically
the
block.
It
means
that
the
first
take
a
is
the
leader.
B
You
know
that
every
tick
is
assigned
a
leader
in
highway
regardless
and
that's
the
let's
make
what
makes
highway
special,
regardless
of
liya.
What
is
going
on
with
lightness
everybody
agrees
on
who
is
the
leader
at
a
given
time.
So
that
is
what
makes
highways
special
and
what?
What
completes
our
limas
proof
so
to
say.
So
here
we
have
leader
leaders
and
the
lambda
message,
which
contains
the
block
and
the
lambda
response
message.
What
it
is
is
the
acknowledgment
the
other
values
in
the
first
round,
which
starts
at
like
tick
number.
B
One,
a
is
the
leader,
B
and
C
are
the
voters,
so
the
leader
sends
a
lambda
message
and
the
voters,
B
and
C,
have
to
send
a
lambda
response
message
in
order
to
acknowledge
that
they
indeed
received
the
block
and
they
they
vote
on
it.
Basically,
so
they
send
along
the
response
message
and
after
some
time
all
of
our
leaders
need
to
send
an
Omega
message.
B
So,
in
other
words,
they
include
the
tips.
So
since
messages
refer
refer
to
each
other,
build
on
each
other,
you
just
have
to
cite
only
the
last
message
from
each
rather
validator
that
you
have
seen
in
this
case
these
Omega
messages
supposedly,
should
each
contain
three
three
hashes
belonging
to
the
three
previous
messages
from
each
validator
they
have
seen.
B
B
Sorry,
if
I
miss
something
up
there,
so
we
want.
We
want
the
assigned
way
it's
an
H
Block
to
me
maximum
one
thing
to
this:
the
small
distinction
assigned
weights
is
I
already
defined
it
too,
that
can
participate
in
a
blog
and
the
participated
blog
equals
or
smaller
than
that
is
the
actual
weight
that
ends
up
participating
in
a
round
or
vlog.
B
The
schedule
allows
us
to
determine
define
in
versus
out-of-round
messages.
So
all
the
messages
that
you
see
in
the
picture
are
it
will
belong
to
the
first
round.
A
is
first
round,
and
these
first
rounds
are
4,
ticks
long.
Where
I
see
this
8
takes
long,
and
you
see
that
a
has
sent
a
lambda
message
and
then
it
has
sent
an
Omega
message
and
all
these
messages
were
sent
in
this
round.
B
So
these
are
in
realm,
a
be
sent
it
out
after
the
round,
and
so,
although
these
messages
belong
to
the
first
round,
they
have
been
sent
it
once
it
like
after
it
ended.
For
that
reason,
they're
considered
out
of
round
and
see
here,
the
like
makes
the
example
so
sees
lambda
responses
in
round,
whereas
this
omega
message
is
out
of
round
so,
and
this
definition
will
be
used
for
to
define
on
time
finalization,
which
is
whether
a
blog
has
been
finalized
on
time.
B
So
this
definition
comes
from
our
paper
so
on
time,
I
define
on
time
finalization
as
Wade
of
the
level
1
level
1
summit
it
sheet
by
so
whether
whether
the
if
a
blog
is
finalized,
a
block
is
finalized
on
time.
Only
if
the
weight
of
the
level
1
summit
achieved
by
in
round
messages
is
greater
than
some
weight
which,
with
a
very
low
fault,
tolerance
threshold
in
this
case
51%,
so.
B
Eventual
finality
is,
if
we
take
all
messages
after
a
long
time
and
look
at
the
total
weight
of
the
level
1
level
1
summit
and
not
just
by
the
assigned
assigned
violators.
So
not
not
just
the
validators
who
were
voting
on
that
blog
in
its
round,
but
validators
who
built
on
that
block,
also
increased
the
part,
the
participating
weight.
So
we
look
at
that
weight.
B
So
if,
after
long
enough
time
all
validators
have
either
voted
on
a
so
have
built
built
a
block
on
a
given
block
or
voted
for
a
block
that
was
built
on
a
given
block
so
on
its
children,
I
mean
when
a
child
blog,
then
we
can
say
all
the
leaders
have
voted
on
it
and
the
weight
is
hundred
percent.
Let
me
give
an
example,
so.
B
B
A
B
B
B
B
B
Therefore
this
is
this
is
good
enough
to
finalize
the
block,
and
this
this
can
be
rewarded.
Well,
in
the
case,
you
have
only
write
the
only
one
validator,
only
ace
and
all
of
its
messages
on
time.
B
didn't
send,
is
lambda
response
and
Omega
message
and
cedar
and
Sana's
Omega
message
on
time.
So
the
level
one
summits
achieved
by
interim
messages,
only
33
percent.
B
So
you
you
don't
reward
this
you
on
reward
this
block,
so
the
block
reward
allocated
for
this
for
the
block
that's
proposed
on
the
first
stick
is
burned
and
let
me
talk
about
reward
allocation
reward
allocation,
so
I
I
said
beforehand.
This
is
not
like
Bitcoin
or
a
theorem
or
any
other
proof
of
work
algorithm.
Where
do
you
have
a
constant
block
reward
for
block
you
have
so
we
have
constant
inflation
or
seen
which
we
don't
like
to
work
inflation,
because
it's
very
vague.
B
So
you
seen
rich
for
the
mechanism
by
which
new
tokens
are
minted,
just
took
to
be
given
to
the
violators
aside
from
transaction
fees,
so
a
constant
amount
is
maintained
through
signage
by
by
constant
amount,
I
mean
it
changes
every
week.
It
depends
on
the
total
supply
of
the
previous
previous
era,
but
at
the
end
of
each
era
we
meant
new
tokens
by
this
formula,
and
then
we
allocate
allocates
a
portion
of
that
era.
B
Using
using
the
schedule,
we
calculate
a
reward
weight
for
each
block
here.
I
put
the
definition
like
the
reward
rate
is
a
function
of
assigned
weights,
which
means
it
depends
on
it.
It's
directly
proportional
to
it,
but
I
don't
want
to
get
and
grow
too
much
too
much
in
the
technical
details.
Basically
like
meter
tokens,
so
the
block
rewards
is
proportional
to
the
corresponding
reward
weights,
which
is
proportional
to
assigned
li.
The
more
evaluators
are
voting
on
a
block
are
the
more
the
more.
B
If
violators
converge
on
a
block
all
of
them,
then
the
reward
block
reward
allocated
for
that
block
is
maximum.
If
all
validate
is
the
the
maximum
reward
that
can
be
given
for
a
block
is
determined
by
the
case
where
you
have
all
the
values
voting
on
about.
If
they
have,
let's
say
all
the
round
exponent
like
10,
then
the
blocks,
the
blocks
where
birthday,
where
they
participate,
will
all
have
the
maximum
block
reward.
B
Moreover,
you
have
a
corollary
if
a
block
is
to
be
allocated,
rewards
assign
weight
must
be
enough
for
a
success,
successful
on-time
finalization,
if
it's
smaller
than
that
like
it
can
by
logic.
It
can't
be
finalized
on
time,
because
51%
is
is
threshold.
So
now
the
leaders
won't
receive
any
rewards
from
that
block.
So
our
understanding
is,
we
will
either
set
the
reward
weight
of
such
a
such
a
block
to
zero
or
allocate
a
reward
will
be
burnt
because
it's,
it
could
never
add
up
to
51%,
since
a
sign
weight
is
smaller
than
that.
B
You
have
this
block
total
block
reward
allocated
for
a
block
right,
and
you
have
this
separate
concepts
of
finality
on
time,
finalization
and
eventual
finality.
So
certain
percentage
of
the
allocator
reward
will
be
portioned
for
OTF
and
the
rest
will
be
portion
for
grant
EF.
We
haven't
decided
on
it,
yet
people
we
will
decide
on
it.
Following
our
like
mock-up,
we
will
try
to
come
up
with
a
reasonable
number.
That's
fierce!
We
want
the
optimum
network
health,
so
we
want
the
best
of
both
worlds
regardless.
B
If
all
validators
act
honestly,
they
will
receive
all
the
rewards.
So
you
have
to
I
believe
you
have
to
percents
in
rich
per
year
and
that
shall
be
like
a
validators
not
yield,
but
that
that
will
be
the
growth
in
the
supply.
So
deals
will
go
much
higher
in
the
beginning,
but
that
will
be
the
maximum
growth
in
the
supply.
B
And
if
everybody
acts
honestly,
it
will
be
2%
if,
if
somebody
is
acting
maliciously
or
somebody
is
not
sending
messages
on
time,
tanda
that
total
growth
will
be
smaller
than
2%,
how
how
the
rewards
are
given
like
what
is
the
conditions
for
receiving
rewards.
So
if
all
TF
fails
both
or
TF
an
EF
rewards
are
burnt,
that
means
the
block
isn't
finalized
on
time,
eventually,
eventually
voting
on
it
eventually.
Building
on
it
is
also
not
rewarded,
but
if
on
time,
finalization
is
successful,
that
all
valid
leaders
become
eligible
to
receive
the
corresponding
eventual
finality
reward.
B
So
I
underlined
all
valid
leaders,
because
the
all
TF
rewards
are
given
to
only
the
assigned
violators.
The
values
whose
round
start
at
that
block
so,
but
for
since,
since
eventual
finality
about,
is
about
all
remaining
values
showing
up
than
the
eventual
finality,
reverse
go-to,
also
the
rest
of
the
world
leaders
and
then
for
for
eventual
final
T.
So
TF
reward
is
binary.
If
you
don't
have
51%
weight,
you
you
burn
it.
If
you
have
more
than
51%,
you
give
the
whole
amount.
This
is
binary,
but
EF
is
more
like
a
sliding
scale.
B
So,
if
you
have
51%
show
up,
then
you
have
to
reward
for
the
remaining
40
49
percent
right
and
this
these
numbers
are
just
like
for
the
demonstration
we
buy.
51%
we
mean
like
with
a
very
low
fault,
tolerance
threshold.
It
could
be
50.1%,
it
could
be
fifty
point
zero
one
percent,
so
you
don't
have
to
take
these
values
at
face
value.
B
The
minimum
is
fifty
percent.
In
our
case,
you
can
just.
This
is
to
understand,
understand
the
model
better,
how
how
we
scale
everything
linearly,
so
the
eventual
finality
was
really
remain
rewarded
for
remaining
49%
and
how
much
they
receive
is
calculated
by
multiplying
the
linearly
the
remaining
the
remaining
ways.
So
you
have
allocated
some
percentage
of
the
block
reward
for
eventual
final
D,
and
you
multiply
it
with
this.
B
Coefficient,
if
know,
if
eventual
find,
if
it's
stays
at
51%,
this
will
equal
zero.
If
it's
hundred
percent,
then
all
of
the
eventual
final
T
rewards
will
be
given
to
the
elevators.
This
is.
This
is
a
very
simple
linear
model,
which
you
know
probe
proportionally
distributes
distributes
the
rewards
at
the
end
of
an
era.