►
From YouTube: Scalable Byzantine Consensus for Everyone
Description
A virtual meetup hosted by Hyperledger Denver on January 13, 2022. In this session we will hear from Matej Pavlovic regarding MirBFT and its successor, ISS, turn leader-driven protocols into scalable multi-leader ones. The design is general enough to accommodate most leader-driven ordering protocols (BFT or CFT) and make them scale. The research prototype implementation, when applied to 3 different protocols (PBFT, HotStuff, and Raft) at the scale of 128 nodes, shows significant performance improvements (37x, 56x, and 55x, respectively).
More about the MirBFT lab is at: https://github.com/hyperledger-labs/mirbft
More about the meetup is at: https://www.meetup.com/Hyperledger-Denver/events/283055089/
----
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 #HyperledgerMeetup #Blockchain
A
You're
now
live
john
okay,
perfect
thanks
david.
Everyone
welcome
to
the
first
hyperledger
virtual
meetup
of
2022
we're
excited.
You
could
join
us
for
this
great
session
today
and
you
know
2021
was
a
great
year
for
hyperledger
and
the
community,
but
we're
looking
forward
to
another
great
year
in
2022,
and
we're
really
excited
that
everyone
can
join
us
today.
A
He's
the
distributed
systems,
researcher
specializing
in
byzantine
fault,
tolerant,
consensus
protocols,
he
obtained
a
master's
degree
from
vienna
university
and
then
he's
worked
on
the
permission.
Blockchain
solutions
now
he's
joining
protocol
labs
to
work
on
I'm
going
to
have
a
great
presentation
here
about
scalable
consent
from
you
I'll
monitor
the
chat.
Anyone
who
has
any
questions
for
mache
as
we
go
along
here
feel
free
to
post
them
in
the
chat
and
we
can
answer
them
as
we
move
through
the
presentation.
A
B
B
So
I've
been
working
on
this
together
with
marco
and
jason,
my
former
colleagues
from
from
ibm
who,
who
are
everybody
who,
who
are
partly
still
there
partly
anymore,
and
so
let's
jump
right
in
what
maybe
one
more
remark.
If
anybody
has
any
question
I
I
like
to
be
actually
interrupted,
and
if
this
is,
if
this
can
be
interactive,
please
make
it
interactive.
B
If
you
have
something
that
you
want
to
ask
immediately
just
go
ahead
and
shout
because
I
think
in
the
context
where,
where
something
is
explained,
it's
already,
it's
also
better
to
have
the
questions
not
like
at
the
end,
and
then
we
need
to
reload
all
the
context,
all
right.
So,
first
a
little
bit
of
background
and
putting
things
into
into
place
in
terms
of
consensus,
dob,
meaning
total
of
the
broadcast
and
blockchain
and
state
mission
replication
and
how
these
terms
actually
fit
together.
B
So,
let's
start
with
state
machine
replication,
state
machine
application
is
a
concept.
It's
a
it's,
a
method
for
for
replicating
a
service
that
is
usually
online
for
making
it
highly
available
and
and
resilient
defaults.
So
state
machine
replication
is
based
on
having
several
rep
several
replicas,
that
each
has
a
has
a
copy
of
the
whole
service
state
and
they
all
start
with
some
initial
state,
and
we
we
just
let's
go
to
next
slide
yeah
and
then
they
they
apply.
B
Operations
to
this
to
this
state
in
in
some
specific
order,
and
each
operation
that
is
submitted
by
a
client
would
update
the
replica
state
potentially
and
create
some
some
response
that
is
sent
back
to
the
client
and
each
replica
is
appending
these
these
operations
to
like,
like
a
chain
or
one
after
the
other,
and
each
of
each
which
replicates
exactly
in
these
operations.
In
the
same
order
now
the
clients
they
have
to
broadcast
their
operations.
B
To
these
replicas
and
since
the
replicas
need
to
execute
the
operations
in
the
same
ordinate,
they
need
to
be
considering
those
operations
in
the
very
same
order.
So
this
broadcast
by
the
client
of
the
operations
to
the
replicas
needs
to
happen
in
some
total
order.
That
needs
to
be
consistent,
the
cost
across
all
directly,
because
that's
why
it's
total
order
broadcast,
so
the
clients
use
total
order
broadcast
to
distribute
the
operations
to
the
replicas.
B
Now
these
these
operations,
we
can
see
them
as
as
forming
a
chain.
Sometimes
they
call
it
a
log
of
of
of
operations
and
they're
at
each
replica
locally,
they're
executed
one
after
the
other,
and
since
we
require
each
operations
execution
to
be
deterministic,
each
operation
would
produce
exactly
the
same
state
at
each
replica.
B
B
A
B
Is
it
that
does
that
answer
right?
Thank
you.
Yes,
thank
you,
yeah,
perfect,
okay,
so
we
have.
We
have
a.
We
have
a
such
a
chain
of
operations
and
and
these
operations
can
also
be
blocks
of
operations
in
practice.
This
is
really
just
the
mechanism
to
make
it
perform
better.
Instead
of
broadcasting
a
single
operation
at
a
time
we
can,
we
can
say
in
each
operation,
can
be
replaced
by
a
block
of
operation
and
append
it
to
this
chain,
which
makes
this
chain
a
blockchain
right.
B
So
this
is
how
this
is
where
the
term
blockchain
comes
in.
If
we
have
blocks
of
operations
appending
to
each
other
in
such
a
chain,
that's
a
blockchain
now
another
way
to
look
at
it
is
that
each
position
in
this
log,
the
first,
the
second,
the
third
and
so
on,
is
it
needs
to
be
needs
to
be
agreed
upon
by
the
replicas
they
need
to
have.
They
need
to
achieve
consensus
on
what
the
first
operation
is.
B
So
this
is
just
to
just
just
to
give
give
the
like
level
out
the
the
terminology
here
now
most
of
these
things
are
used
interchangeably
very
often
because
they
they
are
either
one
is
the
means
to
achieve
the
other
and
so
on.
So
we
talk
very
often
about
consensus,
but
why
do
we
need
to
have
a
scalable
consensus?
B
And
I
guess
most
of
you
since
you
are
here-
you
already
know
this
so
I'll
skip
faster.
It
is
in
in
private
blockchain
systems,
a
classic
consensus.
Algorithm
is,
is
necessary
to
to
implement
such
a
thing,
for,
for
example,
banking
purposes
or
for
supply
chain
management
or
for
consortia
applications
and
so
on
in
public
blockchain
systems.
Some
some
committees
sometimes
need
to
need
to
execute
such
a
protocol
to
agree
on
on
on
the
order
of
operations
of
on
transactions
and
so
on.
B
Very
often
these
are
tens
or
hundreds
of
mutually
untrusted
participants,
and
this
is
where
our
protocol
comes
in,
and
this
is
where
it
can
be
used.
So
how
do
we
do
this?
How
do
we
approach
scalable
consent?
How
how
do
we
approach
the
problem
of
a
consent,
protocol
that
scales
well
through
modularity
log
segmentation,
duplicate
prevention
and
sensoring
prevention,
so
one
after
the
other?
I
will
actually
talk
in
detail
about
those
so
but
very
quickly.
We
actually
take
any
leaderbase
protocol,
of
which
there's
there
there
have.
B
There
has
been
so
many
already
through
throughout
the
years.
Some
of
them
are
new.
Some
of
them
are
old,
but
they
share
many
commonalities.
There's
many
leader
based
protocols
known
today,
and
what
we
do
is
we
look
at
them
as
just
modules
that
order
some
some
requests
or
some
operations,
and
we
don't
care,
we
don't
care
how
they
do
it.
We
just
take
them
as
black
boxes
and
we
plug
them
in
as
modules.
B
B
B
So
how
we
deal
with
this
is
by
rotation
these
by
rotating
the
assignment
of
these
operations,
to
the
different
leaders
and
and
achieving
that
every
operation
will
eventually
be
attended.
So
this
is
just
an
overview
and
I'll
talk
about
exactly
how
we
do
this.
I
will
do
so.
The
rest
of
this,
the
rest
of
this
presentation,
is
divided
into
parts.
B
One
is
the
theory,
basically
what
I
was
just
talking
about:
that's
slightly
more
in
depth
and
then
in
practice,
how
we
actually
implement
it
and
where
we,
where
we
always
look
for
for
hands
on
approach
of
some
people
who
might
want
to
contribute
and
we're
always
open
to
enthusiasts,
who
would
like
to
put
their
hands
on
it
and
help
implement
this
all
right
so
replicating
along.
So
let's
so
this
this
state,
this,
this
log,
is
what
we
basically
want
to
have
in
the
end.
B
Well,
each
roughly
comes
to
have
a
copy
of
such
a
log,
with
certain
operations
inserted
in
each
replica
initially
starts
with
an
empty
log
of
operations
and
the
one
of
the
classic
approaches
to
to
implement
filling.
This
log
is
using
a
leaderbase
protocol
that
I've
been
talking
about
and
most
of
the
leaderboards
protocols
in
some
way
work
in
three
conceptual
conceptually
three
phases.
B
B
B
The
issue
is
that
that
usually
this,
this
proposed
phase
is,
is
by
far
the
most
expensive
in
terms
of
resources
spent
and
then
the
leader
becomes
the
bottle,
and
so
basically
everybody
all
the
other.
All
the
other
nodes
they're
just
mostly
sitting
there
waiting
for
the
for
the
leader
to
propose
something.
Then
they
quickly
confirm
and
commit,
but
they
don't
have
much
to
do
and
the
leader
is
doing
most
of
the
work
so
so
and
the
leader
is
just
one
and
it
doesn't
so.
This
is
why
many
of
the
protocols
don't
scale.
B
We
don't
care
how
this
is
done.
We
say:
hey
mr
protocol
just
make
sure
that
some
operations
are
our
eventually
committed
and,
and
we
don't
care
so
then
what
we
do
is
we
segment?
The
law,
so
we
take
this
law
and
we
actually
take
part
of
the
log
which
we
call
a
segment
and
we
we
spin
up
one
instance
of
sequence,
broadcast
of
that
leaderbase
protocol.
A
Okay,
then
we
had
another
question
here
from
alan
and
the
question
is:
is
the
commit
phase,
an
eventual
or
strict
consistency
model?
That's
the
first
part
of
the
question
and
then
do
we
assume
that
each
node
as
part
of
the
network
have
the
same
compute
capabilities
as
the
others
and
no
latency
consideration
for
compute
time
mismatch.
B
Yeah,
so
this
actually
is
a
very
interesting
question
and
it's
a
good
point.
So
in
so
first
the
first
part
of
the
question.
Yes,
this
is
strong.
Consistency
I
mean
state
machine
replication
is,
is
a
is
a
method
of
achieving
strong
consistency
among
the
copies
of
the
service,
because
each
operation,
each
two
operations,
are
ordered
with
respect
to
each
other.
B
B
It's
just
that,
maybe
a
leader
that
is
let's
say
slow,
would
would
need
to
have
a
smaller
segment
than
some
other
than
some
other
leader.
That
is,
that
is
faster.
That
has
a
better
network
connection
that
can
handle
more
more
requests
per
second,
so
this
is
definitely
possible
to
to
tune,
but
for
simplicity,
let's,
let's
stick
to
roughly
to
the
assumption
of
a
roughly
the
same
computing
and
communication
resources
per
node,
but
this
yeah.
A
Looks
like
we
had
one
more
question
from
de
and
it's.
How
do
you
avoid
that?
This
protocol
now
are
real
time
constraints
example.
The
leader
processing
segment
secret
six,
requires
that
the
leader
of
set
five
broadcasts,
its
results,
as
it
requires
this
as
input
and
as
new
current
state
to
complete
its
task.
B
Yeah
exactly
so,
that's
that's
a
good
point.
So
the
the
leader
of
well,
the
leader
of
the
first
segment,
let's
say,
hasn't,
hasn't
managed
yet
to
broadcast
what
goes
in
slot
five.
However,
the
leader.
Actually
let
me
let
me
go
a
little
bit
forward.
I'll
show
what
exactly
is
happening.
I
have
it
on
the
slide.
B
So,
basically,
all
these
all
these
segments
and
all
the
instances
of
the
leaderbase
protocols
are
almost
independent.
So
the
the
one
only
cares
about
filling
in
these.
The
second
one
only
cares
about
filling
these
and
so
on
so
and
this
can
go
in
par
everybody
yeah.
This
can
go
in
parallel
and
we
spin
up
these
instances
such
that
each
instance
has
a
different
leader.
B
And
this
leader
doesn't
really
care,
what's
happening
in
this
segment
and
and
this
one
doesn't
care
what
happening
here
and
so
on.
So
that's
why
each
is
proposing
operations
in
parallel,
and
this
can
happen
and
this
and
and
they
independently
of
each
other
and
this
situation.
I
guess
this
is
what
you
were
referring
to
in
the
question
correct
me.
If
I'm
not
correct
me,
if
I'm
wrong
so.
B
B
B
The
other
participants
agree
that
okay
leader
two
crashed
and
we're
just
not
committing
anything
here
and
we're
skipping
those.
So
this
can
happen
and
in
the
end,
everything
will
be
filled,
except
for
these
two
and
but
since
everybody
knows
that
these
are
these
will
never
be
filled
because
the
later
crashed
we
can
just
skip
those
positions
and
execute
the
rest
of
the
operations.
B
Okay.
Now
we
have
a
problem
with
this.
The
problem
with
operation
duplication.
So
what
is
operation
duplication?
We
said
that
these
segments
are
independent
of
each
other,
so
what?
If?
What?
If
leader,
one
and
and
they
prepare
and
they
they
propose
operations
for
their
own
segments,
but
they
don't
really
know
what's
going
on
in
the
other
segments
and
if
a
client
comes
and
wants
to
broadcast
an
operation,
the
client
needs
to
send
it
to
multiple
leaders.
B
Otherwise
he
risks
that
that
the
leader
that
the
client
is
sending
the
operation
to
is
malicious
and
would
never
propose
the
operation.
So
the
client
needs
to
send
the
applica
the
its
operation
to
many
leaders
and
now,
but
since
they
don't
know
about
it,
don't
know
about
each
other,
they
might
happen.
It
might
happen
that
everybody
proposes
the
same
operation
and
like
this,
and
if
this
happens
consistently,
which
in
practice
it
actually
does.
B
B
So
what
does
that
mean?
We
mean
that
means
that
for
each
leader
we
only
allow
a
certain
certain
set
of
operations
to
be
proposed.
We
assign
some
set
of
operations
in
the
first
segment
and
easily.
We
assign
a
different
set
of
operations
to
the
second
one,
and
so
on,
like
this,
the
first
one
can
only
do
a
only
propose
and
fill
its
own
operations
and
the
second
one
as
well
and
so
on.
B
We
call
this
set
a
bucket,
so
every
leader
gets
a
bucket
of
operations
and
it
only
is
allowed
to
propose
these
operations
if
it
happens,
to
propose
some
some
operations
at
some
operation.
That
is
not
in
the
bucket.
Well,
then,
all
the
other
nodes
that
are
supposed
to
confirm
and
commit
these
operations.
They
would
say
no,
no,
I'm
not
I'm
not
committing
this,
because
you're
not
allowed
to
propose
this.
B
Okay,
we
have
a
question.
We
have
a
question.
Your
operations
in
the
chain
don't
have
state
dependencies
on
prior
operations.
I'm
confused
parallel
leaders
appear
to
run
consecutive
operations
in
the
chain
that
depend
on
the
computation
of
the
prior
operation.
Well,
if
they
do
depend,
then
then
the
dependency
would
have
to
be
executed
first,
so
it's
the
it's.
The
client's
responsibility
to
not
submit
two
dependent,
two
operations
that
depend
on
each
other,
because
before
an
operation
is
committed,
it
is
not
ordered.
B
So
if
I'm
a
client
and
I
submit
two
operations
that
depend
on
each
other,
I
still
have
to-
I
still
have
to
count
on
the
fact
that
they
might
be
reordered
in
in
the
final
in
the
final
log.
But
if
some
operation
is
or
is
committed
and
executed-
and
it
has
its
place
in
the
log
since
it's
executed-
I
see
the
result
of
it.
B
So
please,
please,
let
me
know
if
there's,
if
there's
more
explanation
needed
okay,
so
we
have
these
buckets
and
each
each
leader
only
is
allowed
to
propose
operations
from
one
bucket
now.
This
in
turn
creates
another
problem,
namely
operation,
censoring.
So
what
what
does
censoring
mean
so
remember
this,
this
situation,
where
we
had
one
leader
that
was
that
crashed
and
that
couldn't
propose
its
operations?
B
B
So
what
we
do
is
that,
but
is
that
we
call
this
epoch
1,
but
by
the
log
it
continues
right.
The
log
continues
indefinitely
when
new
operations
are
added,
so
we
say
that
another
another
part,
another
section
of
the
log
again
divided
into
four
segments
would
be
the
epoch
two
and
there
will
be.
The
log
will
be
divided
into
a
succession
of
epochs
like
this,
and
each
epoch
is
subdivided
into
segments.
Now
here
comes
the
trick.
B
B
So
so
here
we
see
that
bucket
one
has
been
assigned
to
the
first
segment
in
epoch,
1
and
the
same
bucket
is
assigned
to
the
to
the
fourth
segment
in
epoch.
2.,
I
see
a
question:
if
bucket
rotation
needs
to
happen,
then
then
it's
it
should
be
dynamically
updated
to
exclude
execute
operations.
Yes,
that
is
that
is
definitely
true
and
in
in
fact,
a
bucket
is
just
a
is
basically
an
infinite
subset
of
an
operation.
B
Imagine
here
in
this
case
it's
it's
like
module
or
four,
and
each
operation
has
has
a
class
has
a
bucket,
which
is
a
kind
of
a
class
of
operation
where
it
belongs,
and
it's
it's
not
it's
not
like
a
list
of
operations
that
can
that
can
be
done.
That
can
be
proposed.
It's
really
a
class!
Imagine
that
you
take
the
you
take
the
operation,
you
hash
it
and
you
take
the
last
two
bits
of
that
hash
and
that
assigns
a
bucket.
B
Similar
before
this
introduces
another
real-time
constraint,
you
can
only
switch
switch
epochs
after
all
operations
in
the
previous.
Exactly
that
is
true,
so
we
switch.
We
go
from
one
epoch
to
the
other
one
once
the
once.
The
first
one
is
filled
with
operations
and
thus
clock
synchronization
need
to
be
dealt
with
for
e-book
strategy,
not
necessarily
since
we
know
that
each
segment
separately
is
guaranteed
to
eventually
fill
all
the
slots.
B
Then
we
know
that
this
eventually
will
happen,
and
we
don't
really
in
our
model.
We
don't
really
care
when
this
will
happen
in
practice.
Of
course,
we
do,
and
we
can.
We
can
tune
the
implementation
such
that,
such
that
it's
very
unlikely
to
happen
that
we
would
need
to
wait
for
a
long
time,
but
but
in
theory
we
don't
really
care.
B
B
Okay,
I
see
another
question:
does
clock
synchronization
need
to
be
dealt
with
for
input
surgery
if
a
malicious
leader
does
not
fill
the
bucket
yeah?
Well,
if
a
malicious
leader
does
not
you
mean,
does
not
feel
the
the
slot
in
the
log,
so
if
a
malicious
leader
doesn't
feel
is
locking
the
log
it's
basically,
this
situation,
where
are
we
here?
B
A
A
Although
the
clients
already
announced
that
they
wish
to
to
execute
certain
operation
in
protocols
like
pbft,
there
is
a
mechanism
of
to
to
trigger
to
kick
out
the
malicious
leader
and
and
replace
it
with
another
replica
that
could
propose
the
requests
that
are
waiting
for
too
long.
And
so
do
you
just
remove
this.
A
With
epoch
mechanism,
or
is
there
any
way
that
the
replicas
that
know
within
the
epoch,
1
that
certain
leader
is
already
misbehaving,
doesn't
propose
some
operation
for
too
long?
Although
it's
it's
known
that
some
client
already
long
ago
requested
this
operation
somehow
to
kick
it
out
or
do
some
some
replacement
earlier
on?
Yes,.
B
The
the
slight
issue
with
that
is
is
only
a
performance
related
thing
that
usually,
when
you,
when
you
switch
the
leader
in
one
instance,
that
the
new
leader
in
that
is
probably
already
is
leader
in
some
other
instance,
and
it
would,
it
would
have
to
have
like
double
work,
to
do,
to
do
it
or
to
propose
operations
for
its
own
instance
and
propose
operations.
For
the
other
instance.
B
That's
why
we
just
take
a
shortcut
there
and
say:
okay,
the
new
leader
is
actually
elected,
but
the
only
task
of
the
new
leader
is
to
propose
empty
batches
for
whatever
hasn't
been
proposed
yet
or
for
whatever
has
not
been
committed.
Yet
and
like
this,
the
the
epoch
finishes
and
the
uncommitted
operations
that
that
the
clients
already
announced
they
want
to.
They
want
to
commit.
They
would
be
dealt
with
by
somebody
else
in
the
next
epoch
and
okay.
B
Yes,
after
a
fixed
number
of
operations,
this
can,
of
course
we
can
go
and
try
to
tweak
this
and
dynamically
change
it
and
it's
totally
possible
and
the
implementation
will
actually
support
it.
That,
based
on
whatever
criteria
we
can,
the
system
can
decide
how
long
the
epoch
should
be,
but
for
simplicity.
B
Currently
it's
just
after
a
fixed
number
of
operations
and
what
what
actually
is
already
happening
when,
when,
when
a
leader
crashes,
for
example,
here
if
leader,
two
misbehaves
or
crashes-
and
there
are
some
nil
values
that
appear
in
the
log
in
the
next
epoch-
that
node
will
actually
not
become
leader,
anymore
or
or
on
the
it
will
be
kicked
out
of
the
leader
set
and
then
in
epoch,
2,
for
example.
It
would
only
be
partitioned
into
three
segments,
noting
four,
but
this
is
it.
I
mean
for
simplicity.
B
All
right
and
then
was
this:
your
question
operations
are
not
redistributed
if
a
node
fails
to
perform
those
operations
yeah,
the
client
sends
the
operations
to
multiple
nodes.
So
if
some
leader
fails
to
to
submit
that
to
commit
that
operation,
then
some
other
leader
will
will
succeed
later,
so
that's
basically
the
gist
of
it.
B
Okay,
I'm
glad
that
there
was
actually
interesting
questions
we're
running
slightly
out
of
time,
so
I
need
to
skip
over
some
other
things.
So,
just
to
summarize,
we
have
a.
We
have
a
scalable
consensus
protocol
that
is
based
on
modularity,
namely
by
using
any
leaderbase
protocol
as
a
as
a
module,
and
we
use
multiple
instances
of
it,
one
for
each
segment
of
the
log,
and
this
happens
in
parallel
and
that's
why
that's
why
the
resources
of
each
leader
can
be
used
optimally.
B
B
So
eventually,
each
operation
will
be
assigned
to
a
bucket
with
with
some
leader
that
is
correct,
that
that
will
propose
all
right.
So
that
was
the
theory
and
basically
out
of
time,
so
I'll
just
show
quickly
how
we
implement
this
in
practice-
and
this
is
this-
this
is
a
new
protocol
and
we
just
we're
just
starting
the
effort
of
having
a
really
nice
production,
ready
implementation
of
this
and
the
when,
if
you
are
interested
in
contributing
to
this
or
in
looking
how
it
works
or
using
it.
B
Just
just
drop
me
a
message
on
my
email.
I
think
it
must
be
somewhere.
If
not,
if
not,
I
will.
I
will
supply
that
and-
and
let
me
know
if
you
are
interested
in
actually
looking
in
the
code
and
contributing
or
maybe
even
using,
that
that
protocol
it's
in
an
early
stage
of
development,
it's
a
it's
a
rather
fresh
hyperledger
lab
and
I'm
just
going
to
show
you
in
a
few
slides
the
architecture
of
the
of
the
implementation,
and
just
so
just
so.
B
B
B
B
Even
the
protocol
that
I've
been
describing
now
has
is
actually
a
module
and
it
can
be
switched
for
some
some
first
for
another
one.
Then
there's
a
module
for
sending
and
receiving
messages
of
the
network
and
there's
a
there's
a
right
ahead:
log
module
which
is
crucial
for
situations
where,
for
example,
the
node
wants
to
restart.
B
For
example,
there's
a
message
incoming
that
is
part
of
the
consensus
protocol.
It
goes
in
the
buffer,
then
the
processing
function
says:
oh,
we
have.
We
have
a
message.
We
we
relate
to
the
protocol,
module
the
protocol,
module
processes
it
and
generates.
Let's
say
some
new
messages
that
need
to
be
sent.
They
go
in
the
buffer.
B
B
B
B
Then
the
protocol
module
is
a
actually
has
a
very
simple,
imperfect
interface,
but
it's
actually
probably
the
most
complicated
one,
because
all
the
theory
that
I
was
talking
about
is
actually
implemented
in
this
protocol
module.
It
has
some
protocol
logic,
it
has
some
state
and
all
these
events
that
can
be
submitted,
requests
or
received
messages,
or
some
ticks
of
some
timer
and
so
on,
they're
processed
by
the
module
as
events
and
then
new
events
are
produced
for
other
modules
oops.
B
This
is
this
is
a
typo
in
the
copy
paste
there
in
the
in
the
slide.
Here
is
the
right
right,
headlock
module
I'll
skip
over
this?
It's
not
that
crucial
and
I'm
running
out
of
time,
and
what
is
what
is
also
very
nice
about
this
kind
of
approach
is
that
we
can
have
a
separate
module
that
is
called
the
interceptor
and
all
these
events
that
are
happening
here
can
be
actually
intercepted
and
recorded
and
fed
into
some
debugger
program,
and
the
debugger
program
can
then
analyze
exactly
what
what
happened
inside
the
node.
B
It
can
even
feed
them
feed
those
events
in
the
node-
and
this
is
this-
is
very,
very
nice
for
for
debugging
and
for
showing
what
was
happening
inside,
for
example,
you
you
want
to
run
it,
you
run
it.
You
record
the
modules
and
something
goes
wrong.
You
have
you
have
complete
trace
of
the
system,
and
then
you
can
even
update
your
code
like
increase
the
debug
level
and
so
on,
and
then
feed
those
feed
those
events
back
in
and
see
exactly
step
by
step
what
was
happening.
B
B
You,
when
you
want
to
when
you
want
to
create
when
you
want
to
actually
deploy
some
application
on
each
node,
you
basically
take
the
take
the
mirbsd
library,
you
create
a
new
node.
You
give
it
some
configuration
parameters
like
its
own
numeric
id
and
some
you
tell
it
where
to
write
the
log
messages
and
then
you
tell
it
which
modules
it
should
use
like.
B
Most
of
these
modules
are
planned
to
be,
or
are
already
implemented
by
the
library
itself,
but
the
user
can
replace
them
by
more
fancy
versions
if
they
want
to
the
most
crucial
module
for
the
user.
Is
the
is
the
application?
For
example?
Here
we
have
a
chat
application
so
now
I
only
have
maybe
what's
the
time
yeah.
Maybe
I
have
a
few
minutes
left.
I
show
quickly.
B
B
The
only
relevant
thing
that
I
need
to
that
I
need
to
do
is
implement
the
application
logic
so
here
what
the
application
has
to
do
when,
when
new
messages
are
when
new
requests
arrive-
and
here
we
in
here
we
model
the
chat
as
each
chat
message
is
basically
a
request
to
the
application
to
append
the
new
message
to
the
chat
history.
So
here
we
just
basically
go
through
the
go
through
all
the
requests
in
the
badge
we
just
retrieve
the
data
from
the
from
the
key
value
store,
so
request.
B
Data
is
the
actual
message.
We
construct
a
nicely
formatted
message
that
we
can
print.
We,
we
add
the
message
to
the
history
and
we
and
we
print
the
message,
that's
it.
So
this
is
the
application
logic.
It's
simple.
Now
we
have
the.
We
also
implement
the
function
and
restore
state.
So
I'll
skip
very
fast
over
this.
This
is
basically,
we
just
serialize
everything
in
a
in
a
protobuf
message
and
we
return
the
bytes
and
to
restore
the
state.
If
we,
if
we
lag
behind,
then
we
really
need
to
catch
up
with
the
state.
B
B
We
pass
it
to
the
new
new
node
function
at
the
at
creation
of
the
node,
for
example,
the
the
isis
protocol
is
part
of
the
library.
I
is
the
name
of
the
protocol
that
I
was
describing.
I
should
have
said
that
actually,
and
so
we
just
create
an
instance
of
the
protocol,
it
has
a
well-defined
interface
that
is
in
the
documentation
and
that
you
saw
on
the
slide
and
then
we
just
pass
it
to
the
node.
B
B
B
A
B
A
A
B
A
B
So
there
is
one
one
question:
is
this
compatible
e
g
with
eg
hyperledger
fabric
deployments?
Well,
it
is
not
but
the,
but
it
is
designed
to
be
so
certain.
So
currently,
hyperlogic
fabric
has
an
ordering
service
and
I
think
it
will
it
is.
It
is
a
matter
of
time
when,
when
this
library
will
be
just
pluggable
in
in
hyperledger
fabric,
to
have
a
proper
scalable
bft
support
now
it
is
not
possible
yet
and
also
because
also
because
the
library
itself
is
in
an
early
stage
of
development.
B
B
B
A
B
A
B
B
A
One
presentation:
everyone
should
have
the
email
there
and
I'll
share
the
presentation
with
anyone
who
signed
up
for
the
meetup
as
well,
and
we
look
forward
to
seeing
you
for
our
next
session
that
should
be
coming
up
within
the
next
month.
So
have
a
great
day.
Everyone
and
we'll
talk
to
you
soon.
Thank
you.