►
From YouTube: Beyond blockchain: PARSEC, bringing consensus to the next level with Rust Pierre Chevalier
Description
Rust programmer and leader of the Routing team at Maidsafe, Pierre Chevalier participated in the invention of PARSEC: a next generation consensus protocol and is now overseeing its development in the open, in Rust.
Invented in 2018, PARSEC is a revolutionary algorithm that has the potential to disrupt the blockchain by offering a scalable, mathematically proven alternative for trustless consensus. It is open-source and written in rust. Co-inventor Pierre will blow your socks off by explaining its ins and outs.
A
Hi
everyone
so
I'm,
Pierre,
Chevalier
I
work
for
made
safe,
I've,
been
working
here
for
a
bit
under
a
year
and
since
I've
joined
I've
been
working
on
parsec,
which
is
our
consensus.
Protocol
I
was
involved
in
the
since
the
early
stages
of
design
and
now
I'm
leading
the
team,
that's
developing
it
and
bring
it
to
production.
So
today
that's
what
my
talk
is
going
to
be
about.
A
So
the
title
of
this
talk
is
beyond
blockchain
Pathak,
bringing
consensus
to
the
next
level
with
rust
and
because
I'm
lazy,
the
plan
is
going
to
be
tackle
each
section
of
the
title
one
by
one.
So
why
do
I
say
be
on
blockchain?
What
do
I
mean?
Well,
no
we're
in
late
2018,
so
I'm
guessing
that
everyone
has
heard
of
blockchain,
and
maybe
some
of
the
connotations
it
has
are
not
very
good
anymore.
Maybe
when
I
say
blockchain,
you
think
it's
a
buzzword.
A
There
are
lots
of
negative
connotations
that
have
risen
in
the
last
few
years,
but
I'd
like
for
you
to
remember
what
you
thought
of
blockchain
when
you
discovered
the
concept
like,
for
instance,
when
you
first
read
the
Bitcoin
white
paper
whenever
that
was
and
when
I
think
of
blockchain
I.
Remember
that
on
the
basis
it
was
one
simple
and
elegant
idea
that
could
be
expressed
in
only
a
short
white
paper.
Only
nine
pages,
mostly
plain
English,
barely
any
maths
pictures
in
there.
A
In
the
nine
pages,
and
with
that
white
paper,
we
had
a
way
to
remove
the
need
for
trust
in
money
in
the
issuance
of
currency
and
in
validating
transactions,
and
so
that
idea
was
extremely
powerful.
It
it
allowed
us
from
system.
While
you
need
it,
if
you
wanted
to
send
cash
electronically
to
trust
some
third
party,
then
you
could
just
have
two
people
on
other
sides
of
the
planet.
Don't
know
the
piece
of
software,
it
runs
some
protocol
and
the
exchange
money
and
it's
nobody's
business.
A
So
for
that
reason,
blockchain
became
kind
of
a
breaking
change
in
in
society
and
that's
why?
Then
there
has
been
all
the
success
and
all
the
negative
consequences
of
the
success
as
well,
and
so
the
big
idea
behind
blockchain,
of
course,
was
the
proof
of
work
which
acts
partly
as
a
consensus
mechanism.
So
it's
sort
of
the
double
span
problem
with
proof
of
work.
You
can
know
that
someone
is
not
spending
the
same
money
twice
and
another
aspect
of
proof
of
work.
Is
that
it's
a
civil
mechanism?
A
So
if
you
want
to
do
anything
malicious
on
a
blockchain,
if
you
try
to
spawn
a
hundred
thousand
a
million
fake
identities,
it
doesn't
change
anything
because
you
need
the
harsh
right
to
control
over
half
the
half
rate
of
the
network,
so
that
was
kind
of
the
the
big
innovation.
Now,
why
am
I?
Even
speaking
about
blockchain?
A
A
For
instance,
if
you,
if
you
want
to
request
data
from
the
network,
you
need
some
way
to
get
that
data
back,
but
without
the
trust
in
a
server,
and
so
that
first
comes
in
the
form
of
a
number
of
servers,
cooperating
together,
reaching
consensus,
and
what
you
rely
on
is
that
a
fraction
of
these
computers
is
honest.
A
big
enough
fraction
is
honest,
so
yeah
the
safe
Network
were
trying
to
build
a
network
for
humans
based
on
human
values
such
as
respecting
your
privacy
and
network.
A
That's
built
in
collaboration
so
made
safe
is
currently
the
company
that's
working
on
the
project,
but
it's
also
open
source
and
we
invite
everyone
to
participate
in
building
this
thing
as
well.
If
it
succeeds
it
kind
of
bigger
than
a
company
or
an
individual,
so
yeah,
the
safe
network
has
many
parts
to
it.
One
part
is
actually
called
cross
connections
in
rust,
which
is
a
bit
similar
to
Olympia
to
P.
That
Pierre
gave
a
talk
about
before,
but
anyway.
A
So
if
you
want
to
learn
about
all
these
parts
of
the
safe
network,
I'd
recommend
you
check
out
our
website
safe,
Network,
the
tech
and
from
knowing
I'm
gonna,
be
focusing
on
parsec
in
this
talk,
so
parsec
is
a
consensus
protocol.
So
I'll
just
give
you
a
one-liner
about
the
consensus
protocol.
You've
got
a
number
of
computers
that
see
things
happening
and
they
need
to
decide
on
the
order
in
which
they
happen.
A
So
everyone
could
propose
an
order,
but
because
of
latency
and
stuff
they
could
see
things
genuinely
in
different
ways
and
then
it's
Byzantine
fault
or
event.
If
it
is
resilient
to
malicious
actors
trying
to
break
the
protocol,
while
one
s
not
the
trying
to
agree
on
the
next
value
so
for
all
uses
in
the
safe
Network,
we
needed
a
consensus
protocol
that
was
asynchronous
because
we
want
to
do.
We
want
to
do
internet
scale
thing
so
you'd
have
no
guarantee
about
latency.
In
any
case,
you
could
have
all
kinds
of
weird
things.
A
So
if
you
rely
on
timing,
you
are
likely
to
introduce
security
vulnerabilities
for
later.
We
wanted
something:
that's
scalable
again
internet
scale,
so
something
that's
permissionless.
So
on
one
hand
it
means
being
resilient
to
malice
and
on
another
hand
it
means
being
able
to
accommodate
nodes
joining
and
leaving
the
section
of
the
network,
while
consensus
is
happening.
A
Of
course
we
wanted
it
to
be
open
source
because
the
entire
safe
network,
the
entire
stack,
is
a
number
of
open
source
modules
and
that's
why
it's
intended
and
we
wanted
it
to
be
simple,
not
only
because
of
maths
no
BISM,
although
that's
a
part
of
it,
but
also
because
simplicity
in
an
algorithm
means
security,
because
it
means
that
other
people
can
review
the
algorithm
and
they
can
convince
themselves.
It's
correct
and
you
don't
have
to
like
have
some
kind
of
weird
loopholes
in
the
middle.
A
So
now
I'll
explain
how
parsec
works,
but
first
I'll
give
you
the
recipe
ahead
of
time
so
recipe.
First,
you
use
gossip.
Then
you
build
a
directed
acyclic
graph
of
your
basic
communications.
Then
we'll
define
the
concept
of
an
observer
and,
with
this
concept
of
an
observer,
you
can
reduce
the
problem
of
general
Valentine
fault-tolerant
protocol
to
a
simpler
problem,
I'm
not
going
to
tell
you
which
simpler
problem
yet
because,
as
you
can
just
leave
the
room
and
speaking
to
know
what
so
first
gossip
gossip
is
a
way
of
communicating
in
a
network.
A
That's
both
efficient
and
resilient.
So
I
will
give
you
two
examples
of
what
what's
an
efficient
way,
what's
a
resilient
way
and
then
sure
why
gossip
is
a
good
middle
ground,
so
an
efficient
way
to
communicate
between
nodes.
Is
everyone
sits
in
a
circle?
Everyone
communicates
data
to
the
node
on
the
right
until
everyone
has
seen
the
data
and
the
cost
of
this
is
n
communications
to
share
a
message
between
n
nodes,
so
that's
very
efficient.
A
However,
if
any
node
stops
playing
ball,
the
message
will
be
lost,
so
it's
absolutely
not
resilient
a
way
to
communicate
information
in
a
network.
That's
resilient
is
broadcast
so
that
n
nodes
all
send
all
the
information
they
know
to
everyone.
But
then
the
cost
of
propagating
a
message
between
n
nodes
is
N.
A
Squared
which
is
not
efficient,
so
gossip
is
a
middle
ground
where
nodes
just
send
data
randomly
to
a
node
every
now
and
then,
and
it
turns
out
with
that
randomness
the
the
property
you
get
is
messages
get
propagated
in
n
log
n,
like
n
being
the
number
of
nodes
and
on
another
hand,
you're
very
resilient,
because
malicious
nodes
don't
know
who
to
hinder
or
like
who
to
target.
If
they
want
to
stop
you
communicating
and
so
statistically,
it
will
always
make
its
way
through
anyway.
They
cannot
just
stop
everyone.
At
the
same
time,.
A
Okay,
so
so
in
PASOK
the
nodes
communicate
through
gossip
and
that
allows
them
to
build
an
a
gossip
graph.
So
that's
a
directed
acyclic
graph
that
records
the
communications
that
happened
in
the
network
and
then
two
to
reach
agreement
on
the
next
value.
The
question
is
going
to
be
from
looking
at
what
I
see
of
the
gossip
graph.
What's
the
next
value
and
if
I
do
this,
I
want
for
everyone
else
to
see
the
same
thing
so
gossip
graph.
A
Let's
take
an
example,
because
it's
easier
to
visualize
than
explained
in
the
abstract:
we've
got
four
nodes
here:
called
Alice,
Bob,
Carol
and
Dave,
and
when
things
happen
in
the
network,
nodes
will
create
an
event,
a
gossip
event
to
record
that
something
happened.
So
an
example
of
this
is
another.
Node
wants
to
join
these
four
nodes
and
issues.
A
A
message
and
say:
Bob
sees
this
message,
and
so
he
records
that
in
creating
a
gossip
event
that
says,
okay,
say
everyone's
to
join
the
party
and
then
like,
because
it's
gossip,
someone
will
randomly
pick
someone
else
to
communicate
here.
Bob
picks
Carol
and
when
Carol
receives
this
communication,
so
Bob
sends
her
his
what
he
knows
of
the
bottom
graph
at
the
moment,
and
she
creates
a
gossip
event
that
has
the
hush
of
what
he
sent
her
and
the
hush
of
her
oldest
event
and
say
no,
maybe
Bob
picks
Alice.
A
Maybe
Alice
speaks
Bob
again
and
you
can
communicate
like
this
randomly
and
build
a
bit
of
a
graph.
So
this
is
just
big
enough
to
show
a
few
concepts
and
defend
the
concept
of
observer.
So
I'm
gonna
stop
here
just
for
explaining
concepts
in
the
next
few
slides
I'm,
giving
a
name
to
the
gossip
events,
so
I'm
naming
them
from
the
initial
of
the
node
and
then
0
1
2,
going
up
in
the
graph,
so
the
oldest
one
is
a
0.
0
does
run
by
Alice,
for
instance.
A
So
no
we
want
to
defend
the
concept
of
observer
because
you'll
see
that
it
allows
to
simplify
the
problem
of
a
BFG
or
Besant
and
forth
around
protocol
and
we'll
start
by
defining
the
concept
of
seeing
so
well.
The
very
simplest
way
possible,
and
so
seeing
is
a
relationship
between
to
gossip
events
and
the
very
simplest
way.
A
gossip
event
can
see
another
gossip
event.
A
If
is
if
the
other
gossip
event
is
itself,
so
each
gossip
event
sees
itself
and
then
the
next
simplest
way
is
if
the
other
gossip
event
is
a
self
parent
or
another
parent.
So,
for
instance,
here
a1
C
is
C
0,
because
C
0
is
the
other
parent
of
a
1.
So
the
other
parent
is
the
del
diagonal
relationships
in
this
graph
and
then
it's
transitive.
B
A
Events
that
have
the
same
self
parent-
and
this
is
malicious
behavior,
so
it
it
should
not
happen
by
Honus
nodes,
but
it
can
happen
because
we're
in
Byzantine
setting
and
so
the
definition
of
seeing
changes
in
in
this
case,
just
a
little
side
note,
all
the
nodes
are
signed
cryptographically
by
the
authors,
so
that
you
cannot
pretend
that
someone
else
did
a
fork.
If
you
do
a
fork,
you
are
signing
both
sides
of
the
fog,
so
it
can
be
proven
that
you're
misbehaving,
so
you'll
be
taken
care
of
later.
A
But
still
the
protocol
must
handle
this.
So
if
we
take
the
event
d1,
it
sees
the
event
c1
Prime
in
this
fork,
because
a
way
to
see
it
is
that
D
1
cannot
be
aware
of
the
other
side
of
the
fork.
So
it's
just
the
normal
rules.
But
if
an
event
can
let's
say
see
both
sides
of
a
fork,
then
it
doesn't
see
any
event
created
by
the
author
of
the
fog.
A
So
the
event
detail
here
doesn't
see
c1
or
c1,
prime
or
c2
or
any
event
created
by
Carroll,
because
it's
kind
of
aware
that
there
is
a
fog.
So
the
reason
we
define
seeing
like
this
is
that
it
reduces
the
power
of
a
malicious
individual
by
forking.
Now
all
they
can
do
by
forking
is
undo
a
bit
of
the
past,
whereas
if
you
don't
have
these
kind
of
rules,
they
can
just
pretend
that
all
kinds
of
history
happened
and
confuse
everyone.
A
A
I,
don't
know
if
I've
précised
it,
but
the
fault
tolerance
of
PASOK
is
1/3
of
the
nodes
or
less
than
1/3
of
the
nodes
can
be
malicious
at
the
same
time
in
one
network
and
that's
actually
proven
it's
been
proven
for
decades
to
be
the
best
theoretical,
Besant
and
resilience
consensus
protocol
can
have
so.
The
super
majority
being
2/3
is
related
to
this
1/3,
but
it's
got
two
properties.
One
is
that
super
majority
always
contains
a
majority
of
harness
nodes,
and
two
super
majorities
always
have
a
whole
nest
node
in
common.
A
So
this
is
going
to
be
useful
for
the
next
concept,
which
is
strongly
seeing
so
we've
seen
that
scene
allows
malicious
nodes
to
undo
the
history
in
the
future.
Strongly
thing
is
a
step
towards
removing
this
problem,
so
the
definition
false
from
leasing
battle
for
18
examples,
because
it's
easier
is
an
event
say:
X
strongly
sees
an
event
Y
if
it
can
see
events
created
by
a
super
majority
of
nodes
that
can
see
about
Y.
A
But
let's
look
at
an
example,
so
I
claim
that
a1
strongly
sees
b0
and
the
reason
is
that
a
one
sees,
for
instance,
a
zero,
that's
created
by
Alice
B,
zero,
that's
created
by
Bob
and
C
zero,
that's
created
by
Karl
and
all
of
these
see
V
zero,
and
these
are
three
out
of
four,
which
is
over
two
thirds.
So
it's
a
supermajority,
so
a1
strongly
sees
b0,
giving
you
one
different
example.
A
Just
to
so
say,
d1
strongly
sees
a
zero
and
if
you
see
in
this
case,
d1
can
see
events
created
by
all
of
the
nodes,
which
is
definitely
more
than
2/3,
that
CD
0.
So
a
0.
Sorry
so
d1
strongly
sees
a
0
and
just
to
really
drive
the
point
home
an
example
where
strong
leasing
does
not
happen.
A
2
does
not
strongly
see
a
0,
and
the
reason
is
that
a
2
only
sees
events
created
by
Alice
and
Bob,
which
is
half
the
network
which
is
less
than
2/3.
A
So
the
reason
we
bother
them
define
this
strongly
saying
is
because
if
we
get
this
nice
property,
if
an
event,
X
strongly
sees
an
event
y,
no
other
event
can
strongly
see
an
event
by
wise
creator.
That's
on
another
branch
of
a
fork,
so
this
kind
of
solves
the
problem
with
undoing
history
in
the
future
and
I've
been
promising
to
defend
the
concept
of
observers,
we're
almost
there
but
first
interesting
event.
So
we
want
to
reach
consensus
on
something
some
data
which
were
really,
and
this
data
is
going
to
be
contained
in
the
graph.
A
One
of
the
interesting
events
proposed
for
the
next
and
say
this
is
the
next
and
when
you
do
this,
you
need
to
be
sure
that
other
knots
do
this,
so
I've
been
showing
you
this
versa
graph
from
God's
eye.
But
you
need
to
realize
that
each
node
has
their
own
version
of
the
gossip
graph
that
could
be
completely
out
of
sync
by
I:
don't
know
generations
and
generations
of
gossip
events
and
so
yeah.
They
don't
have
this
good
view.
They
don't
all
have
the
same
gossip
graph.
A
So
now
the
concept
of
observers
which
have
been
touting
so
the
technical
definition,
is
gossip
event
that
strongly
sees
interesting
gossip
events
proposed
by
your
super
majority
of
nodes
and
because
it
can
be
a
bit
abstract,
I'm,
gonna
image
again
so
you've
already
seen
that
a
two
does
not
strongly
see
a
zero.
So
in
this
example,
I'm
saying
that
a
0
B,
0,
C,
0
and
D
0
are
all
interesting
events
and
we're
looking
for
is
a
to
an
observer
or
not.
A
Okay,
so
a
to
strongly
sees
B
0.
You
can
just
see
that,
like
the
the
blue
path
covers
all
the
not
be
too
strongly
CC
0
and
B
too
strongly
C's,
DS
0
so
bit.
Who
strongly
sees
three
of
the
four
interesting
events
and
that's
the
super
majority,
so
that
makes
the
event
a
to
an
observer
and
know
we
are
able
to
do
something
nice.
With
this
definition
of
observer,
you
can
see
the
fact
that
the
observer
strongly
sees
a
specific
interesting
event
as
a
vote
of
confidence.
A
This
interesting
event
no
interesting
event
on
a
fork
of
this
one
will
be
strongly
seen
by
anyone.
So
what
this
says
is
basically
that
at
the
time
of
event,
a
to
Alice
knows
that
V
0,
C,
0
and
G
0
will
eventually
be
strongly
seen
by
other
nodes,
but
it
doesn't
know
for
a
0,
and
then
you
can
use
this
as
the
input
to
Mehta
election.
So
the
meta
election,
it's
going
to
be
some
kind
of
vote
between
the
members
of
the
section
where
each
observer
is
going
to
answer.
A
A
So
there
are
as
many
meta
elections
as
there
are
nodes,
and
so
the
answer
to
this
question
is
a
binary
value,
is
yes
or
no,
and
it
turns
out
the
Green
on
the
binary
value
is
simpler
than
agreeing
on
arbitrary
data
on
the
order
of
a
literary
data
and
that's
called
a
binary
value
consensus
and
in
fact,
it's
so
much
simpler
that
there
is
actually
a
pretty
nice
way
to
do
it.
That
was
already
in
the
literature
for
a
few
years,
and
this
way
is
it's.
A
This
white
paper
signature
free,
asynchronous
Byzantine
consensus
with
less
than
a
third
of
40
nodes
and
complexity,
N
squared
so
now,
if
you've
been
following
the
complexity,
N
squared
must
make
you
a
bit
uncomfortable,
but
the
the
describe
the
binary
consensus
protocol
in
a
context
of
broadcast.
So
what
we
did
is
simply
take
the
same
fundamentals
and
fold
them
to
the
context
of
gossip,
and
so
then
you
can
get
nodes
to
agree
on
which
nodes
should
be
considered
for
the
next
interesting
event
and
then
tiebreaking.
A
A
So
so
we
used
this
solution
for
binary
agreement
with
an
adaptation
of
moving
it
to
gossip
and
another
adaptation,
which
is
that
this
paper
was
not
so
simple
because
of
one
step
called
the
common
coin
and
the
common
coin
is
a
primitive.
Basically,
it's
like
all
the
nodes,
flip
coin
and
the
outcome
is
random
and
unpredictable,
but
they
all
get
the
same
one
and
turns
out
that's
not
an
easy
construct
to
make.
You
need
something
like
distributed
key
generations
and
then
it
becomes
expensive
to
add
nodes
to
the
network.
A
So
anyway,
it's
just
not
that
simple.
So
we
used
an
idea
from
a
paper
from
Silvio
McCauley
from
Al
Gore
and
called
Byzantine
agreement
material,
which
was
released
actually
just
before
palace
act
like
we
saw
this
and
we
were
looking
at.
How
do
we
do
a
good
common
coin
and
we
were
like
okay.
This
is
better,
so
we
we've
got
a
concrete
cone
instead
of
the
common
coin
and
with
these
components
the
problem
of
consensus
protocol
is
solved
for
us
and
the
properties
we
get
is
asynchronous
ish.
A
So
the
real
definition
of
a
synchronous
is
that
the
adversary
can
convert
the
order
of
delivery
of
any
message
in
the
network
and
that's
so
strong,
and
so
that
shouldn't
affect
liveness.
So
it
means
the
protocol
should
still
always
give
a
result,
and
there
is
one
step
in
our
protocol
that
is
not
theoretically
asynchronous
and
that's
the
way
we
defined
a
concrete
coin.
Although
caveat,
we
think
we
can
fix
that.
A
We
are
just
currently
focused
on
implementing
the
white
paper,
we've
written
and
then
we'll
go
back
into
it
and
try
to
fix
it
and
other
caveat.
We
think
that
the
way
we
defined
our
concrete
coin
is
sufficiently
asynchronous
in
practice
for
the
four
purposes.
But
of
course
we
are
going
to
have
to
test
that
if
we
don't
find
a
truly
asynchronous
academically
solution.
A
A
Well,
first
made
safe
switched
to
rust
in
2015
when
it
became
stable,
so
we
used
to
have
stuff
in
C++,
but
really
we
want
speed
and
security,
and
in
C++
you
can
get
speed,
it's
not
too
hard,
but
to
get
security
you
need
to
work
really
really
hard.
So
with
rust,
we
just
got
the
try
factor,
that's
advertised
speed,
security,
concurrency
and
so
that's
the
same
reason
most
projects
piecrust.
A
That
does
amazing
tools
and,
in
fact,
we're
such
fans
of
the
way
the
Ross
community
works
at
made
safe
that
we've
even
adapted
the
request
for
comments
process
from
worst
to
the
same
network,
so
that
all
community
can
help
us
design
or
network
in
the
same
way,
and
with
one
of
the
reasons
the
community
in
rust
is
so
welcoming.
Is
that
it's
an
active
effort?
A
If
you
check
the
code
of
conduct
the
very
first
bullet
point
in
their
face,
we
are
committed
to
providing
a
friendly,
safe
and
welcoming
environment
for
all,
regardless
of
level
of
experience
and
other
characteristics,
and
that's
exactly
how
we
feel
at
made
safe,
in
fact,
with
the
safe
network,
which
is
secured
access
for
everyone.
We
want
to
provide
security
for
everyone,
and
that
means
not
only
people
who
are
able
to
do
encryption
and
be
smart
with
how
they
use
the
internet.
A
So
this
awesome
community
builds
awesome
tools
and
it's
really
nice
that
I'm
doing
this
talk
now
after
the
6th
of
December,
because
you
can
just
rest
up
component,
add
key
Pyrrhus
format
and
RLS
without
preview,
without
using
somewhere
nightly
like
we
used
to
have
to,
and
basically
in
a
few
words
Clippy
gives
you
like,
the
community.
Reviewing
your
code
live
while
you're
writing.
It.
Russ
format
means
that
when
you
check
any
code
in
any
crate,
you
can
not
be
ticked
by
the
weather
in
turn.
A
Dark
road,
because
you're
just
used
to
this
format,
style
and
the
rest
language
server
means
that
the
VM
versus
Emacs
war
is
over
because
everyone
won
everyone
can
have
the
nice
tools.
Whatever
your
text,
editor
is
so
love
2018,
if
you're
not
using
Clippy
and
res
format,
to
fail
your
CI.
Do
it
it's
really
nice.
It
just
removes
worries
so
now.
To
finish
this
talk,
I'm
gonna,
so
a
few
ways
that
the
rest
echo
system
helps
us
achieve
security,
security
and
then
performance.
A
We
do
testing
for
parsec,
which
I
think
are
pretty
cool,
and
so,
if
you,
if
you
want
to
look
into
the
ways
it's
pretty
nice,
so
as
I've
just
kind
of
described
parsec,
you
may
have
seen
that
we
like
to
think
of
things
in
terms
of
graphs
and
a
good
way
to
visualize
graph
graphs
is
in
the
dot
format
so
that
you
can
generate
images
like
this
from
it.
So,
with
the
dot
format,
you
can
express
relationship.
A
For
instance,
here
you
say
there
is
a
relationship
between
a
0
and
a
1
which
is
like
a
0
is
a
self
front
of
a
1,
and
you
can
then
generate
this
image
that
just
gives
you
the
graph
of
what
happened
in
the
network.
So
we
have
our
code
output,
this
graph,
where
in
some
cases,
for
instance,
when
running
tests
or
when
running
the
example-
and
we
can
then
pass
these
graphs
from
dot
format
back
into
the
data
structures
were
used
to
and
for
that
we
use
pong.
A
It's
not
the
only
one,
but
it's
a
parser
framework
which
makes
you
able
to
pass
this
kind
of
non
quite
standard
thing.
It's
not
JSON.
Is
it
dot
graph
in
a
pretty
concise
way,
and
so
that
allows
us
to
write
tests
like
this
functional
test,
where
we
can
say
pass
this
dot
file
that
I
may
have
generated
and
then
tweaked
a
few
things
then
construct
a
parsec
which
is
all
main
data
structure
and
check
that
some
invariants
on
this
parsec
hold,
and
you
can
also
do
password
dot
graph
and
then
have
that's
going
to
be.
A
My
starting
point:
have
some
nodes
communicate
check
that
the
invariants
hold,
have
some
models
communicate
check
that
the
invariants
hold
etc?
So
that's
a
great
way.
If
you
have
one
scenario
that
you
think
might
break
your
code,
you
just
basically
it's
easy
to
sketch
it
in
dot
graph
and
write
a
test
this
way,
but
we
can
go
one
level
more
powerful
by
being
more
generic
and
adding
some
random.
So
we
have
integration
tests
that
function
on
the
circuit,
testing
basis,
where
we
described
ourselves
a
way
to
represent
a
path
back
graph.
A
So,
for
instance,
you
don't
have
to
say
a
0,
then
a
1,
then
a
2
and
a
specific
order
of
events.
You
can
just
say:
I
want
to
start
with
two
nodes.
So
in
this
case,
I'm
constructing
schedule,
options,
janessa
size,
two
and
place
to
add
8.
So
that's
like
I'm,
starting
with
two
nodes
and
I
want
to
add,
add
8
nodes
to
this
network,
and
these
can
be
generated
in
many
ways.
There
are
many
ways
to
go
see
if
it's
random,
so
it
can
show.
A
Don't
know
four
in
ten.
Whatever
you
could
add
any
number
of
nodes
and
the
property
testing
framework
will
try
to
generate
for
you,
the
the
problem,
that's
the
most
likely
to
find
a
bug
in
your
code.
So
it's
going
to
try
to
run
the
most
complex
problem
it
can
think
of,
and
if
that
breaks
it
will
then
dial
back
all
the
ways
it
has
and
try
to
find
the
smallest
way
to
break
your
test
based
on
this.
So
that's
something
actually
learnt
about
at
the
Russ
fest
in
Paris
and
we
were
like.
A
Ok,
we
want
this.
It's
really
really
cool.
It's
not
that
hard
to
do.
You
just
need
to
have
this
kind
of
declarative
way
of
specifying
your
problems
and
then
it's
a
bit
of
boilerplate,
but
it's
not
too
bad
and
turns
out.
This
first
doesn't
catch
many
bugs
because
most
of
the
bugs
are
caught
before
at
the
sub
testing
level
if
they
haven't
been
caught
at
the
functional
testing.
A
But
since
we
created
this
a
few
months
ago,
it
got
two
bugs
and
these
bugs
had
made
it
through
thousands
of
iterations
of
sock
testing
and
so
for
these
two
bugs
it's
definitely
worth
the
Ricoh.
It
took
us
to
set
it
up,
because
these
are
the
bugs
that
you
never
catch
and
end
up
in
production,
so
I
would
strongly
recommend
playing
with
protests
if
you're
so
inclined.
A
So
these.
So
basically
with
these
between,
like
the
compiler
Clippy
and
the
different
ways
you
can
test
with
rust,
you
can
have
even
more
security
than
what
you
get
by
default
with
just
the
compiler
and
another
aspect.
Of
course,
rust
school
stuff
is
performance,
and
how
do
you
get
performance?
You
don't
just
write
good
and
it's
fast.
You
need
to
measure,
see
where
the
bottlenecks
and
fix
them
and
the
it's
cool
that
inversed
like
in
other
languages.
A
You
basically
just
run
carbon
bench
and
it
generates
these
little
statistical
things
for
you,
for
instance,
this
particular
fix
made
of
40
percent
improvement
on
that
particular
benchmark
and
that's
something
that
was
actually
pushed
to
PASOK
last
week.
I
just
got
the
latest
instance
of
that
because
currently
we
are
deep
s
amazing
awkward.
So
that's
it.
For
me
thanks
very
much.
C
B
A
A
How
can
I
join
and
everyone
will
create
an
interesting
event
that
says:
okay,
this
mod
want
to
join
so
at
the
end
like
at
the
time,
each
of
them
it
could
be
a
different
time,
but
at
the
time
say,
Alice
realizes
that
Eric
wants
to
join
the
network.
Then,
from
her
point
of
view,
eric
is
a
valid
voter
from
that
point
forward
and
same
for
not
living.
A
B
A
Well,
okay,
so
the
part
about
seeing
and
strongly
seeing
is
similar
with
hash
graph
and
the
idea
of
being
wedged
on
a
gossip
graph,
let's
say
of
a
graph
of
a
directed
acyclic
graph
of
cosecant
occations.
But
after
that,
it's
different.
Everything
is
different,
so
I
don't
remember
exactly
how
they
do
it,
but
they
have
witnesses
and
famous
witnesses,
and
the
entire
thing
about
this
is
is
different.
Well,
so
what
we
do
is
basically
reduce
the
problem
to
binary
agreement.
A
A
Well,
okay,
I,
don't!
But
basically
there
is
a
part
in
the
white
paper
where
they
say
all
and
if
you-
and
this
is
not
theoretically
asynchronous,
but
you
can
just
use
a
common
coin
and
that
kind
of
shady
because
just
use
a
common
coin
is
actually
not
easy.
And
if
you
don't
do
that,
you
are
not
quite
a
synchronous.
So,
with
our
concrete
coin,
we
will
step
closer
to
being
fully
asynchronous
or
they
are
not
fully
there.
Yet.