►
From YouTube: Community Call, Casper Highway Protocol
Description
On this weeks community call we discuss the Casper Highway Protocol
Read more about the Casper Highway Protocol here
https://blog.casperlabs.io/the-casper-highway-consensus-protocol-january-26-2021-community-call/
Join our Telegram
https://t.me/casperlabs
Follow us on Twitter
https://twitter.com/meetCasperLabs
A
C
Hi
everyone
welcome
to
today's
community
call.
My
name
is
joe
davis.
I'm
the
community
lead
for
casper
labs
on
today's
call,
we'll
be
talking
about
the
casper
highway
protocol,
which
powers
the
casper
network,
we're
joined
in
today's
call
by
meda
and
andreas
from
casper
labs,
and
also
adamgo
gogol
from
cardinal
cryptography,
we'll
also
be
doing
a
q
a
at
the
end
of
this
call.
So
please
drop
any
questions
you
have
in
the
youtube
comments
on
discord
or
on
telegram
and
I'll
round
them
up
thanks
for
joining
everyone
and
passing
it
off
to
you,
meadow.
C
A
Okay,
great
we're
experiencing
some
technical
difficulties;
apologies
trying
to
get
this
all
sorted
out
correctly.
So
thank
you
joe
for
that
warm
welcome,
and
today
I'm
very
excited
to
introduce
members
of
our
research
team.
Here,
andreas
fackler
and
adam
guggle.
I
am
mehra
parlikar,
the
cto
and
one
of
the
co-founders
of
casper
labs
and
thanks
for
joining
the
community
call
today.
So,
let's
start
off
with
andreas
andreas,
would
you
like
to
do
a
quick
intro
and
tell
us
a
little
bit
about
yourself.
D
A
A
Nice,
well,
I
I
tell
you
when,
when
I
saw
your
cv,
I
was
really
excited
about.
You
know
having
the
opportunity
to
work
with
you
and
I'm
so
glad
you're
part
of
the
project,
so
welcome
and
thanks
for
being
here
today,
so
the
community
can
get
to
know
you
a
little
bit
better
adam.
How
about
you
tell
us
a
little
bit
about
yourself.
B
A
Excellent,
well,
I'm
excited
to
be
working
with
cardinal
cryptography.
You
know
it's
a
really
funny
story
how
we
wound
up
having
a
partnership,
if
you
don't
mind
I'll,
tell
the
story
a
little
bit,
I
think
andreas
was
you
know
seminal
to
that
too.
So,
when
we
were
writing
the
highway
protocol,
andreas
and
dr
kane
would
literally
be
on
the
calls
dreaming
up.
You
know
new
new
and
novel
attacks
and
when
they
discovered
the
first
equivocation
bomb
attack,
they
went
and
naturally
did
some
research
papers
out
there
and
they
found
the
aleph
protocol.
B
A
D
The
fork
bomb
is
a
particular
pattern
of
such
messages
that
basically
forces
validators
to
download
a
ton
of
messages
that
could
grow
into
terabytes
and
it's
basically
a
resource
exhaustion
attack
that
would
well
at
least
cause
a
liveness
failure
and
yeah.
The
lf
protocol
is
also
based
on
this
diag
notion
and
yeah,
and
the
alf
paper
there.
They
presented
a
solution
for
that
that
also
inspired
what
we
did
in
the
end
and
highway.
D
I've
actually
done
another
one
in,
I
think
end
of
2018
and
yeah.
I
felt
like
the
trailer,
but
review
was
very
in
depth,
given
the
relatively
short
time
that
it
that
it
took
them,
so
they
they
really
looked
into
into
a
lot
of
details.
Specifically,
I
mean,
as
we
asked
them
to
into
the
core
protocol
itself
and
yeah,
I'm
glad
that
they
didn't
find
any
catastrophic
problems.
D
Basically,
what
what
like?
They
pointed
out
a
few
things
that
we
already
had
had
thought
about
ourselves,
but
hadn't
addressed
yet
like
rate
limiting
against
spam
attacks
and
actually
implementing
what
we
had
designed
as
the
fork
bomb
protection
which,
at
the
at
the
time,
was
still
a
work
in
progress
but
yeah.
D
B
B
So
in
the
traditional
bfd
protocols,
usually
people
claim
that
once
adversaries
have
a
power
stronger
than
33
percent
of
the
nodes,
nothing
can
be
done,
and
this
is
a
very
subtle
thing
about
the
model
people
are
usually
working
with
and
what
casper
is
is
bringing
to.
The
story
is
that
it
brings
the
very,
I
would
say,
natural
intuitions,
from
from
the
bitcoin
and
from
proof
of
work
world
where
additional
blocks
which
are
building
up
before
upon
the
old
one,
are
adding
to
the
security
to
the
old
block.
B
This
is
something
which
is
not
present
at
all
in
in
normal
vfd
protocols.
This
is
something
we
you
know
what
both
highway
and
casper
are
are
very
good
at.
So
this
I
don't
know
cumulative
security
I'd
say
so
so
obviously
the
spirit
I
I
would
say
was
present
in
original
casper
and
it
is
evolved
in
its
evolved
version,
is
in
highway.
A
Right
and-
and
you
know,
the
ethereum
foundation
is
also
working
on
a
flavor
of
casper
themselves,
which
is
gasper.
If
I
recall
correctly,
and
this
protocol,
it
doesn't
have
the
flexibility
that
highway
does
right.
So
there's
a
recent
paper
that
came
out
that
basically
goes
after
this
vulnerability
in
gaspar
right.
So
can
we
talk
a
little
bit
about
like
some
of
the
flexibility
in
highway
and
how
that's
important,
and
how
does
this
make
it
special.
B
Okay,
so
what
we
usually
formally
call
the
flexibility
is
that
you
can
have
different
finality
thresholds
in
highway.
So,
for
example,
if
a
lot
of
nodes
are
either
malicious
or
or
they
perhaps
crashed
for
some
reason,
and
only
for
example,
sixty
percent
of
nodes
are
up
or
or
or
something
like
that,
the
protocol
is
able
to
still
carry
on,
and
do
this
little
bit
of
finality
that
it's
able
to
do
with
this
with
this
number
of
nodes.
This
is
something
which
traditional
protocols
are
not
able
to
do
at
all.
B
They
just
they
just
store.
So
this
is
the
kind
of
flexibility,
so,
even
during
moderately
big
attack,
we
are
able
to
finalize
the
block,
although
slightly
weaker,
I
mean
yeah
to
slightly
smaller
extent.
This
is
the
notion
of
flexibility
and
it's
I
know
I
I
like
to
to
draw
an
intuition
here
that
it's
somehow
similar
to
bitcoin
or
somehow
similar
to
the
traditional
fork
where
during
big
attack,
you
may
have
some
branches,
but
still
the
main
branch
will
will
win.
B
B
Mean
so
this
is
a
very,
very
specific
timing,
attack
and
similar
attacks.
I
think
have
been
found
on
on
many
other
protocols.
I'm
not
sure
how
feasible
is
such
an
attacking
practice,
although
for
sure
what
it
shows
is
that
there
is
some
there
are
some
parts
lacking
in
in
the
proof
of
of
gospel
security.
I
don't
know
andreas
if
you
can
add
into
into
the
topic.
D
D
A
Yeah,
you
know
what's
interesting
a
lot
of
the
proof.
Some
of
the
recent
proof
of
stake
protocols
that
have
come
out
use,
probabilistic
finality
or
statistical
finality,
and
one
of
the
things
I
like
about
casper
you
know
highway
protocol
specifically,
is
that
the
stake
has
to
participate
in
consensus
in
order
to
get
rewarded
right.
So
you
don't.
If
you
don't,
participate
in
finalizing
a
block
in
in
the
highway
protocol
and
what
we've
implemented
you
don't
get,
you
don't
get
any
rewards
and
by
participating
and
finalizing
a
block,
your
stake
has
to
take
what
we
call.
A
You
know
that
equivocation
risk
or
basically
be
securing
that
block,
and
it's
not
probabilistic
like
some
of
the
more
recent
protocols
that
we've
seen
come
out
for
proof
of
stake,
where
it
really
does
kind
of
you
know,
sacrifice
security
for
speed
right.
We
decided
that
we
were
going
to
put
security
first
and
foremost.
So
I'm
very
pleased
in
that
regard
that
we
can
provide
those
kind
of
guarantees
to
customers.
A
What
about
you
know
the
cbc
portion,
which
you
know
the
cbc
casper,
which
is
correct
by
construction?
Can
you
both
share
your
opinions
on
what
cbc
means?
Andrea,
specifically,
you
know,
and
and
how
did
how
do
you
feel
we
did
in
terms
of
you
know,
upholding
the
spirit
of
cbc
when
you
talk
about
cbc
casper.
D
Oh
okay,
so
I
think
I
think
in
in
the
term
cbc
casper.
It
specifically
means
that
if
you
follow,
if
you
follow
these
rules-
and
your
protocol
matches
this,
this
pattern
that's
specified
in
that
paper,
then
you
can
apply
those
theorems
to
it
and
you
can
apply
this
particular
flexible
finality
notion
and
this
particular
way
of
detecting
that
things
are
finalized.
D
D
But
of
course
it
depends
on
much
more
than
just
the
network
speed
and
what
bandwidth
you
have.
It
also
depends
on
whether
the
recipient
is
currently
overwhelmed
with
messages
and
how
fast
the
recipient
can
process
messages,
and
things
like
that,
and
partly
when
already
when,
for
for
the
paper
itself
and
and
also
for
the
for
the
implementation.
We
gave
a
lot
of
thoughts
to
to
those
details
and
you
know
it's
it's
to
make
sure
the
the
math
matches
the
reality.
A
Yeah,
that's
really
what
I
was
trying
to
drive
to
is
that
you
know
the
cbc
is
the
correct
by
construction,
which
means
that
you
start
with
a
really
solid
set
of
proofs
right
where
and
where
you
have
checked
your
assumptions
and
you're,
basically
looking
at
the
formalism
first
right,
so
it's
form
formalism.
First,
then
implementation
right.
So
you
ensure
that
the
construction
is
correct,
because
you
have
actually
created
a
blueprint
and
based
founded
in
mathematics
before
going
and
constructing
code
and
pretty
pleased
that
that's
that's
the
way
we
decided
to
do
it
right.
A
We
we
had
our
formal
proofs
in
place
first
and
we
felt
good
about
those
before
we
started
constructing
our
code.
So
I
think
all
in
all,
it
shows
in
the
trailer
bits
audit
that
we
were.
You
know
we
were
able
to
follow
the
cbc
process
and
it
did
pay
off
in
the
final
analysis.
So
thank
you
both
for
joining
today
we
have
some
questions
coming
in
from
the
community
which
I'm
going
to
answer
now
and
then
I'll
do
the
development
update.
A
A
You
know
governed
communities
to
manage
those
contracts
centrally
on
on
the
blockchain
itself
at
layer
one.
So
we
provide
advanced
features
that
enable
the
governance
of
software,
be
it
by
a
decentralized
community
or
by
centralized
authority.
So
what
does
that
mean?
It
means
you
can
have
advanced
multi-signature
capabilities
that
can
basically
become
a
governance
protocol
for
signatures
in
of
itself,
separate
from
a
governance
token,
to
enable
the
upgrade
of
contracts
on
the
blockchain.
A
You
can
also
build
a
central
finance
application
where,
if
you
need
to
manage
users
and
whitelist
addresses,
you
can
do
that
within
your
protocols.
You
can
upgrade
your
protocols
on
chain,
so
we
really
support
the
management.
You
support,
features
that
enable
decentralized
protocols
to
be
managed
very
well
with
the
security
of
a
public
blockchain.
So
we
provide
this
very
secure
public
compute
infrastructure,
but
we
enable
contract
authors
to
manage
their
application
centrally
if
you
want
to
build
cfi
or
even
defy
applications.
A
So,
for
example,
if
you
really
trust
the
maker,
dow
governance
process
and,
let's
say
maker-
was
to
run
on
casper,
they
could
provide
a
protocol
upgrade
and
you
wouldn't
need
to
re-lock
your
tokens
in
or
pay
contract
fees.
You
know
transaction
fees
to
relock
your
tokens
into
the
protocol
in
the
event
of
an
upgrade
because
they
could
just
upgrade
the
internal
state
for
you
and
we
do
trust
a
lot
of
authorities
today,
but
there's
not
as
much
transparency.
So
all
of
this
would
happen
at
the
layer.
A
A
So
the
next
question
is
what
would
casper
like
to
work
on
first
product
when
mainnet
goes
live
with
stable
coins?
So
those
of
you
that
have
been
following
us
in
the
community
know
we're
doing
a
patent
management
solution
with
ipwe.
We
signed
our
mou
with
them
a
few
months
ago
and
we
are
already
well
under
underway
with
implementation
they're
replacing
their
hyper
ledger
portions
of
their
hyperledger
implementation
with
casper
and
they're
choosing
to
do
this
because
they
want
real
smart
contracts.
A
This
will
provide
a
public
repository
of
all
patents
registered
on
the
blockchain.
So
it's
a
very
exciting
use
case
and
the
reason
ipv
has
chosen
us
is
because
they
really
like
the
flexibility
that
we
can
provide
to
them
in
terms
of
managing
their
on-chain
code,
as
well
as
the
developer
experience
of
being
able
to
integrate
continuous
integration
and
continuous
deployment
with
their
smart
contracts,
in
addition
to
real
smart
contracting
functionality.
A
A
They
are
a
governance
protocol
for
both
companies
and
decentralized
applications
or
dows
and
matisse
will
be
leveraging
a
lot
of
the
governance
features
that
casper
has
to
offer.
We
have
many
more
protocols
that
are,
we
are
in
final
stages
with
mous
and
we
will
be
providing
those
updates,
so
stay
tuned
and
you'll
learn
about
a
lot
more
protocols
that
are
that
are
choosing
to
go,
live
on
casper.
A
How
many
tps
per
seconds
can
cspr
handle?
Well.
This
is
a
difficult
question
for
us
to
answer
and
the
reason
why
is
that
casper
is
flexible,
as
we
talked
about
here,
so
the
round
lengths
do
adapt
according
to
network
conditions,
and
so
the
round
lengths
really
have
to
do
with
block
times.
We
know
that
we're
going
to
reserve
about
a
thousand
transactions
in
a
block
for
wasm
lists
or
token
transfers,
and
then
some
number
of
actually
wasn't
based
deploys
per
block.
A
You
know
to
determine
what
the
block
time
is
going
to
be
and
and
the
protocol
will
slow
down
and
speed
up
depending
on
how
quickly
it
reaches
the
minimum
quorum
for
finality
right,
and
so
you
got
to
finalize
one
round
before
the
next
leader
can
propose
a
block
and
that's
the
way
highway
works
today.
Now
I
know,
andreas
has
got
quite
a
few
feature.
Backlog
features
in
his
backlog
for
improving
the
performance
of
of
highway,
but
you
know
we're
going
to
be
working.
A
Those
in
in
future
protocol
upgrades
the
last
one
is:
why
do
you
call
it
e3do
when
there's
no
d5
apps
currently
built
or
incorporated
into
casper
labs?
Besides
the
only
one
which
the
cto
has
an
advisor,
which
is
metis
dao,
but
no
other
really
apps
building
are
building
on
casper.
Well,
there's
a
few
reasons
for
this
number
one:
we're
not
live
yet
right.
Number:
two,
we
do
have
an
interesting.
What
I
want
to
call
is
going
to
be
transparent.
Here
is
our
license.
That
license
will
likely
possibly
transition.
A
That's
why
we
refer
to
ourselves
as
e3.0,
because
the
e3.0
roadmap
very
specifically
calls
for
ewasm
and
a
pure
cbc
implementation.
Pure
proof
of
stake.
The
eth
2.0
roadmap
includes
proof
of
work.
The
casper
friendly
finality
gadget
is
an
overlay
on
top
of
a
proof
of
work
chain.
Now
we
know
that
the
2.0
beacon
chain,
which
is
part
of
phase
phase
0
of
eth
2.0,
is
live,
but
there's
still
phases
1
and
2
that
are
required
in
order
to
really
realize
the
vision
of
ethereum
2.0.
So
this
is
the
reason
why
we
call
ourselves.
A
E3.0
is
really
because
the
roadmap
associated
with
e3.0
is
what
casper
is
building
and
it's
true.
We
don't
have
a
lot
of
defy
apps
building
on
us
right
now,
but
they
are
speaking
with
us
and
I
think
a
lot
of
the
d5
protocols
are
waiting
to
see
how
we
do
at
mainnet.
This
is
a
very
reasonable
thing
for
them
to
do.
I
would
fully
expect
that
there
will
be
some
time
before
we
start
seeing
defy
apps
move
over
to
casper.
They
should
rightly
wait
to
see
how
our
protocol
performs
in
production.
A
I
would
do
the
same
thing,
so
no
ill
will
there
at
all.
We
continue
to
make
progress
with
strategic
protocols
that
want
to
work
with
us
and
you'll
be
hearing
about
those
announcements.
Over
the
next
few
weeks
I
heard
ethereum
creators
launching
casper
labs
right.
We
did
have
a
research
relationship
with
vlad
zamfir.
A
A
A
A
Okay,
great
thanks.
This
release
will
be
bring
about
protocol
upgrades
performance
and
hardening
improvements
and
we're
also
going
to
complete
the
integration
with
our
custody
provider
during
this
release
cycle
and
the
delta
test
net
is
currently
down.
We
apologize
for
that.
We
ran
into
some
real
issues
with
joining
and
the
new
networking
layers,
so
we
swapped
out
the
prototype
small
network
component
with
lib
p2p,
and
we
ran
into
a
really
terrible
snag
with
a
configuration
of
that
networking
and
discovered
a
major
liveness
fault,
and
so
what
basically
happened
was.
A
A
Both
you
know
from
the
networking
side,
as
well
as
just
end-to-end
integration
testing.
So
the
team
is
really
taking
a
step
back
we're
going
to
do
a
lot
of
protocol
testing
and
we're
also
going
to
really
harden
our
joining
processes.
So
it
will
not
be
possible
for
people
to
join
from
anywhere
else
except
their
own
node.
This
is
going
to
force
them
to
really
get
their
nodes
synchronized
before
they
send
a
bonding
request
right.
A
So
we
also
are
building
in
the
validator
ejection
piece,
so
you
really
can't
join
the
protocol
and
then
immediately
have
a
liveness
fault
right,
and
so
these
are
some
details
around
the
practicality
right,
the
pragmatism
that
has
to
go
into
a
protocol
and
making
sure
that
it
stays
up
and
and
active
right.
So
these
are
a
few
of
the
features
that
we're
working.
So
we
plan
on
resuming
on
february
1st
and
there's
my
incomplete
status,
so
we're
working
on
performance
and
hardening
work
and
production
engineering
against
the
protocols.
A
It's
production
engineering,
where
you
push
the
protocol
until
it
falls
over,
and
then
you
make
sure
that
you
have
your
monitoring
and
logging
in
place
so
that
you
can
detect
these
failures.
Implementation
evict
non-participating
validators.
This
is
the
liveness
faults.
I
was
talking
about
we're
actually
doing
working
on
some
fast
sinking
and
fast
joining
work
and
we're
going
to
provide
an
ability
to
actually
pause.
A
If
too
much
stake
is
offline
and
what
that
means
is
right
now,
validators
will
continue
to
send
summit
messages
or
finalization
messages,
but
what
we're
going
to
ask
them
to
do
is
actually
detect.
If
the
network
is
paused
and
not
continue
sending
messages,
because
then
what
happens?
Is
the
protocol
state
just
keeps
growing
right
without
hearing
from
the
validators
we
really
need
to
hear
from
which
are
the
ones
that
have
gone
offline?
A
A
A
We're
doing
some
design
work
around
the
block
header.
This
is
really
around
formalizing.
What
goes
into
the
block
header
versus
what
goes
into
the
block
body,
and
I
think
we're
just
going
to
kind
of
cleave
away
and
separate
those
concerns
so
that
we
don't
have
you
know
an
excessively
bloated
header
or
the
wrong
information
in
the
body
versus
a
header
on
the
node
rust
side,
we're
replacing
the
prototype
gossiper
component
with
the
lib
p2p
gossiping.
When
is
this
going
to
drop
peel?
A
E
A
This
is
going
to
be
used
in
protocol
upgrades,
but
it's
also
going
to
make
it
really
easy
for
us
to
join
for
new
validating
nodes
to
join,
and
the
idea
is
eventually
we're
going
to
be
pruning
away.
The
global
state
so
you'll
be
able
to
join
from
a
trusted
hash,
and
you
won't
have
to
sink
directly
from
genesis,
and
this
will
make
it
both
easy
and
affordable
and
sustainable
for
the
blockchain
to
run
for
a
long
longer,
duration
of
time
and
implementing
upgrades
and
casper
node.
A
So
the
idea
is
that
we
will
have
an
upgrade
bootstrapper
that
will
run
as
a
separate
application
that
will
basically
enable
the
upgrading
of
the
node
itself
and
each
upgrade
will
have
its
own
version
of
the
bootstrapper.
Basically,
the
upgrader
or
launcher,
I
think
we'll
call
it.
The
casper
launcher
is
the
name
we're
calling
it,
and
so,
if
there's
a
migration
that
needs
to
happen,
the
migration
will
actually
happen
via
this
upgrade.
A
You
know
this
launcher
this
casper
node
launcher
testing
sre
will
be
supporting
test
net
and
we're
going
to
be
using
elastic
kubernetes
clusters
for
the
testing
that
we've
been
referring
to
and
then
we're
also
supporting
s-test
development
for
node
rotation
of
nodes
in
a
remote
aws
cluster.
So
this
is
really
more
about
nodes
joining
and
rejoining
and
trying
to
replicate
what
actually
happens
in
the
production.
You
know
test
net
system
ecosystem,
we're
working
on
the
multi-sig
and
key
management,
tutorials
and
upgradeable
contracts.
A
I
believe
I've
got
some
review
commits
before
that.
Tutorial
is
ready,
but
that
tutorial
will
be
ready
very
shortly
and
then
we're
actually
creating
an
example.
Script
to
claim
delegated
rewards
for
the
javascript
sdk,
so
those
that
want
to
build
any
kind
of
integrations
using
the
js
sdk
for
delegation
you'll
be
able
to
see
that
live.
E
A
A
Matches
up,
george,
okay,
very
good
contract,
runtime
and
economics
research,
so
contract
runtime
is
building
the
vesting
schedule
for
vft
holders
for
those
that
participated
in
the
private
sale
as
you're.
Well
aware,
your
tokens
are
locked
for
90
days
and
then
they
release
the
tokens
release
over
a
duration
of
90
days
linearly
over
a
week
at
a
time,
and
so
that
needs
to
be
built
into
the
contract,
runtime
and
they're
going
to
not
be
building
it
in
the
runtime
itself,
but
in
the
auction
contract.
A
If
I
understand
correctly-
and
we
are
back
porting-
the
work
that
we
did
in
the
rust
api
and
that
enabled
the
javascript
work
into
the
assembly
script
contract
api-
so
those
that
want
to
build.
You
know
a
custody
solution
using
assembly
script
not
recommended,
but
it
should
be
possible
to
do
and
we're
also
going
to
be
using
account
main
purse
instead
of
user
supplied
purses
in
the
auction
methods.
A
So
we're
going
to
be
moving
away
from
the
purse
model
to
just
the
main
account
address
for
the
purposes
of
token
transfers,
because
we
find
that
this
is
what
people
are
used
to
doing.
So.
We're
going
to
be
basically
decommissioning,
you
know
the
apis
around
purses,
specifically
and
then
later
at
some
future
date,
we're
actually
going
to
rip
purses
out
all
together
from
the
model.
We
just
didn't
find
that
there
was
much
adoption.
It's
creating
a
lot
more
confusion
from
customers.