►
From YouTube: Keynote: Blockchain Consensus Framework
Description
Alexis Gauba, Co-Founder, Mechanism Labs and She(256); R&D, Blockchain at Berkeley; R&D, ThunderCore
Blockchain technology has been gaining popularity in the public, in industry, and in academia. However, these systems are currently limited in their ability to support robust, large-scale applications due to scalability and security challenges. A fundamental step to resolving some of these challenges lies in the consensus layer. As such, both industry and academia are heavily investing in consensus research and development, seeking alternatives to Bitcoin’s Nakamoto consensus. Many of these protocols favor Proof of Stake (PoS) as a Sybil control mechanism to today’s Proof of Work (PoW). This talk presents a systematization of knowledge within these major blockchain protocols, understanding the common challenges and solutions, and providing a formal structure within which to compare them. We break down these protocols by network, adversarial, and economic model, deeply understanding the common challenges of choosing proposers and committees, propagation, and finality.
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #HyperledgerGlobalForum2018 #Blockchain
A
Thanks
for
the
introduction,
I'm
really
excited
to
be
here
today
and
to
be
talking
about
a
framework
with
which
to
look
at
blockchain
consensus
protocols,
and
so
let's
go
ahead
and
get
started,
so
the
first
thing
I
think,
is
to
define
consensus
in
the
blockchain
setting.
So
when
we're
talking
about
consensus
in
the
blockchain
setting
we're
talking
about
distributed
nodes
coming
to
agreement
on
the
state
of
the
ledger
now,
this
is
something
that
everyone
in
this
room
is
pretty
familiar
with,
but
I
think
is
really
one
of
the
crucial
and
fundamental
components
of
this
technology.
A
If
we
want
all
of
these
distributed
nodes
located
around
the
globe
to
be
able
to
talk
to
each
other
to
breach
agreement,
then
we
need
a
consensus
process,
and
so
this
is
one
of
the
fundamental
innovations
behind
this
technology,
and
so
what's
the
consensus
that
we're
probably
almost
familiar
with
today.
Well,
that's
probably
bitcoins
proof
of
work
and
Nakamoto
consensus,
so
I'm
gonna
take
a
second
before
we
continue
to
just
make
the
distinction
between
proof
of
work
and
Nakamoto
consensus.
A
So
when
I'm
talking
about
Nakamoto
consensus,
I'm
talking
about
how
we
actually
decide
how
the
BIC,
which
part
of
the
Bitcoin
blockchain,
is
correct-
and
so
this
is
what
you
probably
have
heard
of
as
the
longest
chain
rule.
So
whichever
chain
is
the
longest
chain
in
a
Bitcoin
blockchain
is
what
we
consider
the
canonical
chain
and
that's
what
I'm
gonna
refer
to
you
as
Nakamoto
consensus.
A
Now,
when
I'm
talking
about
proof
of
work,
I'm
talking
about
a
civil
control
mechanism,
so
I'm
talking
about
a
civil
control
mechanism,
I'm
talking
about,
and
prevention
of,
civil
attacks,
so
in
a
civil
attack,
we
have
all
of
these
different
accounts
that
are
trying
to
maybe
take
down
the
network
in
some
way.
So
it's
my
goal
or
our
goal
as
a
provider
of
consensus,
to
make
sure
that
we
can
prevent
these
kind
of
attacks
and
to
have
some
mechanism
that
allows
us
to
be
robust
to
those.
A
And
so
that's
what
proof
of
work
allows
us
to
do.
It's
incentivizing
me
to
keep
all
of
my
hash
power
in
one
account
to
make
it
more
likely
that
my
block
gets
chosen
to
add
to
the
chain,
but
what's
the
issue
here
we're
trying
to
scale
out
these
blockchain
systems
to
be
able
to
support
lots
of
different
transactions
but
proof-of-work,
while
a
really
good
first
step?
Isn't
the
thing?
That's
gonna
get
us
to
scale:
it's
not
super
energy
efficient.
A
So
we
need
some
sort
of
scalable
civil
control
mechanism
that
still
allows
us
to
have
this
property.
And
so
now
a
lot
of
different
public
Ledger's
are
looking
to
proof
of
stake
as
their
next
civil
control
mechanism
and
in
proof
of
stake.
I'm,
basically
bonding
some
sort
of
amount
of
funds
to
a
network
to
be
a
validator,
so
I
stake
X
amount
of
dollars
and
then
usually
that's
the
amount
of
power
that
I
have
in
this
network.
A
Now
this
is
a
widely
untested
civil
control
mechanism
and
there
may
be
many
others
that
exist,
but
this
is
currently
the
one
that's
most
exciting
to
a
lot
of
people
in
industry
and
academia,
and
so
a
lot
of
the
different
protocols,
especially
in
the
permissionless
setting,
are
looking
at
proof
of
stake,
and
so
most
of
what
I
discussed
today
will
be
in
that
context.
So
I
mentioned
that
there
are
all
of
these
new
consensus
protocols
that
are
coming
out.
A
A
So
the
first
thing
for
us
to
understand
is
the
network
model
and
when
we're
talking
about
the
network
model,
we're
talking
about
how
nodes
pass
different
messages
to
each
other,
and
so
the
strongest
assumption
that
we
can
make
here
is
that
we're
operating
in
the
synchronous
model.
So
in
the
synchronous
model
we
have
a
known
upper
bound
on
message.
A
So
every
single
node
in
the
network
knows
how
long
it'll
take
a
message
to
get
to
them
and
the
reason
that
we
say
that
this
is
the
strongest
strongest
assumption
it's
because
in
this
case,
we're
essentially
saying
that
every
message
is
going
to
get
to
every
other
node.
But
this
isn't
always
practical
to
make.
This
is
something
that
we
can
assume
under
pretty
reliable
communication
channels.
A
But
what,
if
we're
working
over
unreliable
communication
channels,
then
we're
gonna
weaken
that
assumption,
and
so
that's
when
we
have
the
partially
synchronous
model
where
there
is
still
this
upper
bound
on
message
delay,
but
it's
unknown.
So
it
could
be
between
say,
like
2
seconds
to
10
years
and
then
weakening
that
even
further,
we
have
the
asynchronous
case
or
we
have
no
upper
bound
on
message
delay.
So
my
message
could
arrive
instantaneously
or
not
at
all.
A
So
if
I'm
working
in
a
realm,
where
I
have
unreliable
communication
channels,
then
what
I
want
is
to
get
as
close
to
the
asynchronous
model
as
possible.
But
that
said,
reaching
agreement
in
the
asynchronous
case
is
definitely
the
most
difficult.
So
there's
a
large
spectrum
here
and
that's
I-
think
a
theme
that
we'll
see
throughout
these
protocols
is
that
we
often
have
a
spanked
spectrum
from
really
strong
to
really
weak
assumptions
and
it's
important
to
understand
where
your
needs
Ally
on
this
spectrum.
So
the
next
thing
that
we
want
to
consider
is
the
adversarial
model.
A
So
what
kind
of
militia
malicious
actors
are
we
going
to
be
handling
and
there
are
different
types
of
adversaries?
So
we
have
crash
faults,
which
is
when
nodes
will
go
offline
permanently
and
no
matter
what
kind
of
consensus
model
you're.
Building
it's
really
important
to
be
able
to
tolerate
these
crash
faults.
Then
we
have
passive
adversaries
which
are
a
bit
stronger
in
that
they
can
eavesdrop
and
try
to
impersonate
other
nodes
and
then
even
stronger.
A
Then
it's
going
to
be
important
that
your
protocol
is
able
to
handle
these
active
adversaries
so,
along
with
the
different
kinds
of
adversaries,
it's
important
for
us
to
consider
the
timing
of
these
adversaries.
So
how
long
does
it
take
an
adversary
to
actually
corrupt
to
these
nodes?
So
there
are
three
different
types
of
timing
models
that
we'll
discuss
today.
So
the
first
is
the
static
model,
and
this
is
when
nodes
will
say
the
adversarial
node
will
say.
Ok,
this
is
the
set
of
nodes.
I
want
to
corrupt
and
I've
delineated.
A
So
again
we
have
this
spectrum
and,
depending
on
the
types
of
people
you
have
as
validators
in
your
network,
you
want
to
be
able
to
tolerate
different
types
of
adversaries.
So
if
you
have
some
sort
of
situation
where
you
have
a
really
untrust
really
validator
set,
then
you
want
to
make
sure
your
protocol
handles
these
strongly
adaptive
adversaries,
and
then
we
have
the
economic
model
and
when
we're
talking
about
the
economic
model,
we're
talking
about
how
we
incentivize
actors
to
actually
participate
in
consensus.
A
So
if
we
don't
have
different
validators
all
across
the
network
participating
within
your
network,
then
you
don't
get
the
effects
of
decentralized
technology.
So
it's
really
important
that
there
is
some
sort
of
incentive
for
people
to
participate,
and
so
again
this
really
depends
on
the
effect
that
you're
trying
to
achieve.
So,
if
you
have
some
sort
of
very
targeted
use
case
and
a
known
set
of
players,
then
maybe
you
don't
need
an
economic
model.
Maybe
these
people
want
to
participate
because
it's
beneficial
to
all
of
them.
A
Working
on
that
use
case,
but
say
you
have
some
sort
of
large-scale
permissionless
network.
Then
it's
really
important
to
have
some
sort
of
reason
for
different
people
participate,
and
so
this
is
why,
in
Bitcoin
we
have
the
mining
reward
for
people
who
act
as
validators
but,
like
I,
said
earlier,
we're
trying
to
move
away
from
Bitcoin
and
we're
trying
to
move
away
from
proof
of
work.
So
how
does
this
work
in
the
proof
of
State
case?
A
And
this
is
very
much
an
open
question
which
is
of
a
lot
of
interest,
you're,
basically
trying
to
create
these
little
financial
systems
and
build
new
economic
models
to
incentivize
players
to
act
in
these
cases,
and
so
this
brings
again
like
a
whole
set
of
experimental
protocols
and
experimental
questions.
But
it's
something
that's
going
to
prove
to
be
very
important,
and
so
now
that
we've
talked
about
the
network
model,
the
adversarial
model
and
the
economic
model.
A
We
know
what
kind
of
underlying
assumptions
were
making
when
we're
crafting
these
consensus
protocols-
and
the
next
thing
for
us
to
look
at
is
the
general
steps
that
these
algorithms
follow
and
so
usually
follow
this
order.
Where
we'll
start
by
choosing
a
proposer
and
choosing
a
committee
to
decide
what
the
block
is
and
then
verify
the
block.
Then,
once
we've
decided
what
our
block
is
we'll
want
to
propagate
that
to
the
rest
of
the
network,
then
we
want
to
ensure
that
that
block
gets
finalized
and
then
for
many
of
these
protocols.
A
We
also
want
to
be
able
to
handle
churn
so
handle
participants
both
joining
and
leaving
the
network,
and
so
we'll
go
ahead
and
dive
a
little
bit
deeper
into
a
couple
of
those
steps,
and
so
the
first
thing
I
want
to
talk
about
in
that
vein
is
the
security
of
randomness,
and
now
we
might
be
thinking
okay.
Well,
how
does
this
relate
to
anything
I
just
said,
but
the
security
of
randomness
is
actually
directly
tied
to
proposer
and
committee
election.
A
So
let
me
explain
so:
let's
go
back
to
this
example
of
Bitcoin,
something
we're
all
pretty
familiar
with.
So
how
does
the
next
person
get
chosen
to
propose
a
Bitcoin
block
to
the
blockchain?
Well,
that's
whoever
solves
this
random
proof-of-work
puzzle
right.
So
in
this
case,
proof
of
work
weighted
by
the
hash
power
of
any
given
miner
is
the
way
that
we're
generating
randomness,
but
in
the
proof
of
State
case
we
don't
have
this.
A
We
don't
have
this
puzzle
that
miners
are
trying
to
solve,
and
so
we
need
some
other
source
of
randomness,
a
complete
other
algorithm,
to
determine
randomly
who's
going
to
be
our
proposer
and
who's
going
to
be
our
set
of
committee.
Who
will
be
able
to
validate
the
block
that
the
proposer
proposes,
and
so,
when
we're
looking
at
these
random
it's
protocols,
it's
really
important
that
they
follow
this
set
of
properties,
and
so
there
are
three
different
properties
that
are
important
for
us
to
consider.
The
first
is
predictability
so
before
we
get
into
the
properties.
A
Actually,
let
me
describe
a
little
bit
how
these
randomness
functions
work,
so
you
can
just
think
of
it
as
a
function
that
takes
in
an
input
will
call
that
input
the
seed
and
then
it
produces
some
sort
of
output.
So
what
we,
when
we're
talking
about
these
protocols,
we
want
to
make
sure
that
they're
not
predictable,
so
I
don't
want
anyone
to
know
the
output
of
this
randomness
function
ahead
of
time.
A
I
also
don't
want
them
to
be
bias
Abul,
so
I
don't
want
any
group
of
people
to
be
able
to
manipulate
this
output
and
then
I
don't
want
my
seed
to
be
revealed
before
the
current
round.
So
what
that
means
is
say,
we're
running
a
protocol
and
we're
at
round
1,
but
I'm,
a
malicious
actor
and
I
know
the
seed
for
round
10.
Then
I
essentially
know
who
the
proposer
and
who
the
committee
members
are
going
to
be
for
round.
A
10
and
I
can
conduct
some
sort
of
denial
of
service
attack,
so
those
that
proposer
and
those
committee
members
are
offline
at
round
10,
making
them
unable
to
perform
their
function.
So
that's
why
we
don't
want
the
seed
to
be
revealed
before
the
current
round.
So
dealing
with
this
whole
randomness
thing
definitely
adds
a
lot
of
technical
complexity,
and
if
you
know
that
you
have
a
trusted
set
of
validators
in
your
network,
then
maybe
it's
not
as
important
to
you
know,
hit
the
strongest
degree
of
all
these
three
properties.
A
Maybe
it's
okay
for
you
to
have
some
sort
of
deterministic
consensus
protocol,
but
if
you're
trying
to
operate
in
some
sort
of
landscape,
where
you
don't
know
who
these
validators
are
and
you're
not
making
any
assumptions,
then
you
want
to
have
a
really
secure
source
of
randomness.
So
the
next
thing
that
we'll
dive
into
a
little
bit
more
is
finality.
A
So
finality
in
the
blockchain
setting
is
that
the
is
the
affirmation
that
wealth
or
informed
blocks
won't
be
revoked
once
they've
been
committed
to
the
block
and
we'll
go
ahead
and
discuss
two
major
types
of
finality:
probabilistic
finality
and
absolute
finality,
so
probabilistic
finality
is
probably
what
again
we're
most
familiar
with.
This
is
the
type
of
finality
that
exists
in
Bitcoin,
so
say
that
this
is
my
Bitcoin
blockchain
and
I.
A
Have
this
one
long
chain
and
then
a
couple
of
Forks
coming
off
of
this
third
block
and
then
the
block
that
I
care
about
is
the
green
block,
because
that's
the
one
that
has
my
transaction.
So
in
this
case,
because
the
green
block
is
pretty
deep
into
this
chain,
I
can
be
pretty
sure
that
it's
finalized
I
know
that
it'll
take
someone
a
lot
of
money
or
a
lot
of
hash
power
to
build
a
chain
that
goes
that
far,
that
it
can
revoke
the
green
block.
A
Then
we
have
absolute
finality,
and
this
is
the
type
of
finality
that's
followed
by
pbft
based
protocols.
So
this
would
be
protocols
like
tender
mint
if
you're
familiar-
and
in
this
case
we
have
a
leader,
that's
going
to
propose
a
block
and
then
that
leader
is
gonna,
go
ahead
and
send
that
block
to
a
committee
and
it's
the
committee's
job
to
decide
if
that
block
is
valid
or
invalid.
A
So
the
committee
will
all
decide-
and
in
this
case
we
have
a
majority
of
our
committees,
saying
that
this
block
is
valid
great
and
the
specific
threshold
of
the
committee
that
needs
to
decide
whether
the
block
is
valid
or
not.
For
the
whole
protocol
to
consider
the
block
valid
is
different
for
different
protocols.
But
in
this
case
we
have
a
valid
block
and
now
we're
happy
and
our
block
is
immediately
finalized.
A
And
so
that's
the
property
that
absolute
finality
will
give
you
so
to
understand
finality
a
little
bit
better
it'll
be
important
for
us
to
take
a
step
back
and
consider
the
cap
theorem
from
distributed
systems.
So
if
you
haven't
heard
of
it
before
the
cap,
theorem
stands
for
consistency,
availability
and
partition,
tolerance
and
states
that,
in
the
case
of
a
partition,
a
distributed
system
can
only
preserve
either
consistency
or
availability.
So,
let's
explore
this
a
little
bit.
A
A
There's
this
giant
wall
between
nodes
on
either
side
and
now,
let's
say
I'm,
trying
to
send
some
messages
to
this
network,
so
I'm
trying
to
send
a
purple
message
to
one
side
of
the
network
and
a
green
message
to
the
other
side
of
the
network,
but
because
I
want
to
preserve
consistency.
I
would
rather
my
whole
protocol
halt
then
allow
messages
to
either
side
that
would
make
the
protocol
disagree.
So
I
would
want
to
keep
my
state
of
nodes,
all
blue
versus,
allowing
in
this
purple
message
or
the
screen
message.
A
But
if
I
have
an
availability,
preserving
system
that
I
want
my
system
to
continue
operating,
even
if
it
disagrees
with
each
other,
so
this
is
what
I'm
gonna.
Let
that
purple
message
in-
and
this
is
what
I'm
gonna,
let
that
green
message
in
so
now.
How
does
that
relate
to
what
we
were
talking
about
with
absolute
and
probabilistic
finality?
Well,
it
helped
us
understand
a
little
bit
more.
The
nuance
that
these
types
of
finality
provide
us.
A
So,
in
the
absolutely
final
case,
I
have
this
consistency,
property,
so
I
know
that
my
block
is
going
to
be
immediately
finalized,
but
I
also
know
that
my
protocol
is
going
to
halt
in
the
case
of
a
partition
I'm
in
the
probabilistically
final
case.
I
know
that
my
protocol
is
going
to
go
ahead
and
continue,
but
it
might
not
necessarily
agree
with
itself
at
every
single
point
in
time,
and
so
we
see
this
with
Bitcoin,
for
example,
where
we
have
to
wait.
You
know
six
block
confirmations
or
we
can
act
on
our
transaction.
A
So
it's
really
important
to
consider
the
properties
of
what
you're,
building
and
didn't
then
decide
what
kind
of
finality
you
need
for
your
system.
So
if
you
have
some
sort
of
system
where
you
need
it
to
be
highly
available
and
you're,
okay
with
some
inaccuracies,
then
you're,
probably
fine,
building
on
top
of
a
consensus
protocol,
that's
providing
you
probabilistic
finality,
but
if
you're,
okay,
with
a
protocol,
halt
halting
with
achieving
this
consistency,
property,
then
you're
gonna
want
to
build
on
top
of
a
consensus
protocol
that
provides
you
with
this
absolute
finality.
A
So
in
summary,
we've
discussed
the
different
types
of
network
assumptions
that
these
protocols
make.
So
we
have
the
network
model,
the
adversarial
model
and
the
economic
model,
and
then
we
went
through
the
general
algorithm
that
most
of
these
consensus
protocols
follow
so
now
you're,
basically
armed
with
the
toolset
to
go
ahead
and
look
at
any
of
these
consensus
protocols
and
start
to
understand
what
makes
the
most
sense
for
you.
A
So
I
definitely
encourage
you
to
go
ahead
and
apply
this
to
you
know
any
of
the
hyper
ledger:
consensus
models
or
any
other
consensus
models
that
you're
interested
in
to
try
to
figure
out
what
makes
the
most
sense.
If
you'd
like
to
read
more,
there
are
a
couple
of
links
here
which
have
some
more
information
and
I'll
be
around
for
a
little
bit
after.
If
you
have
any
questions
or
want
to
discuss
any
of
this,
thank
you
so
much.