►
From YouTube: Design Patterns for Decentralized Protocols (Avoiding Blockchain Centralization) - Daniel Hardman
Description
Design Patterns for Decentralized Protocols (Avoiding Blockchain Centralization) - Daniel Hardman, Evernym
"Decentralization" is a word we often hear in Hyperledger circles, and we may pat ourselves on the back on the assumption that if we're using blockchain, we must be decentralized. But blockchain can have its own centralization problems. In this talk, we'll explore some Gang-of-Four-style design patterns that are truly decentralized, that you can implement in your own solutions--and we'll also look at antipatterns where blockchain doesn't keep the architecture from centralizing. You'll come away with terminology, diagrams, and examples that will make your decentralization goals easier to achieve, and that will protect you from gotchas.
----
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 #HyperledgerGlobalForum2020 #Blockchain
A
Okay,
welcome
to
this
session.
It's
the
end
of
a
long
day.
You
guys
are
probably
tired,
I
hope
this
will
be
a
light
and
kind
of
fun
session.
Not
a
heavy-duty
one.
I
think
that
it
will
be
relevant
to
anybody,
no
matter
what
your
background
is,
whether
you're
in
the
space
that
I'm
in
which
is
kind
of
a
more
identity,
focused
space
or
you're
in
classic
blockchain,
whether
you're
more
of
a
business
person
or
more
of
a
developer.
I
think
it'll
be
interesting
to
think
about
this
and
I.
A
How
many
of
you
are
familiar
with
a
book
called
the
Gang
of
Four
design
patterns
book
lots
of
you,
okay,
good.
So,
if
you're
familiar
with
that
book,
you'll
have
some
expectations
about
this
session
and
your
expectations,
I
think,
will
be
met
if
you're
not
familiar
with
that
book.
Doesn't
matter
too
much,
but
if
you
are
you'll,
see
and
hear
some
of
the
things
that
I
say
and
you'll
map
it
to
the
your
experiences
that
you've
had
with
that
book
a
little
bit
and
that
will
be
a
good
thing,
I
think,
okay.
A
I
have
been
in
software
long
enough
that
I'm
very
familiar
with
the
way
software
was
built
back
in
not
so
much
the
80s.
That
was
a
little
bit
early
for
me,
but
the
90s
anyway,
and
moving
forward
from
there
and
patterns
of
how
software
was
built.
The
way
software
developers
talked
about
the
architectures
of
of
what
they
were
building,
what
they
thought
about
how
systems
ought
to
work,
and
there
was
a
common
paradigm
that
really
became
a
big
deal.
A
So
these
are
just
three
architecture
diagrams
that
I
went
and
lifted
off
the
internet,
I
just
I,
just
googled
client-server
grab
the
photos
and
circle
the
fact
that
all
of
these
architectures
had
in
common
the
fact
that
you
had
this
magical
thing
in
the
middle.
That
was
a
server
that
did
all
kinds
of
cool
stuff
for
you.
Okay,
so
what's
interesting,
is
I.
Did
a
similar
search
for
blockchain.
A
And
blockchain
has
that
same
characteristic,
the
magical
thing
in
the
center
that
will
do
all
the
stuff
for
you
and
that's
not
necessarily
bad.
There
was
lots
of
good
things
about
client-server
architectures,
but
what's
ironic
about
it
is
that
we
claimed
that
we're
doing
blockchain
because
we
want
to
decentralize.
So
if
we're
seeing
the
same
kinds
of
pictures
show
up
and
we're
seeing
the
same
kinds
of
words,
maybe
we're
avoiding
the
word
centralization.
When
we
talk
about
blockchain,
because
we
were
you
know,
we
wouldn't
want
to.
A
Maybe
it
doesn't
have
the
properties
that
we
think
it
ought
to
have
or
that
we
want
to
be
able
to
claim
for
it,
and
so
I
kind
of
became
tuned
into
this
phenomenon
a
little
bit,
and
this
is
a
diagram
that
I
modified
slightly
from
something
that
I
shared
at
the
last
hyper
ledger:
Global
Forum
in
Switzerland,
it's
my
own
personal
progression
through
arriving
in
the
blockchain
space,
so
when
I
first
showed
up
in
blockchain
land,
this
was
kind
of
how
I
thought
about
the
world.
Wow
blockchain
is
awesome.
A
Why
didn't
I
know
about
this
stuff
before
this
is
so
cool
a
global
source
of
truth?
It
can
store
everything
everywhere
and
oh
cool.
It's
got
the
decentralized
pixie
dust
sprinkle
over
it
too.
So
this
is
just
perfect
and
then
evolved
from
that.
A
little
bit
too
well,
I,
have
to
admit,
there's
some
performance
and
scale
issues
with
blockchain.
A
A
Actually,
some
stuff
never
belongs
on
the
blockchain
and
from
there
I
went
to
well
there's
regulatory
compliance
gdpr
issues,
maybe
that
stuff
should
influence
how
we're
building
stuff
and
from
there
I
realized
that
we
were
actually
having
some
decentralization
fails
in
our
community.
So
that's
what
motivated
me
to
have
this
conversation
and
I
hope
when
you
walk
out
of
this
conversation,
you'll
be
more
sensitized
to
some
of
the
ways
that
we
can
go
wrong.
I'm
not
saying
we
always
do,
but
there's
just
some
ways
that
maybe
we
ought
to
think
about
things.
A
A
little
bit
different
and
noticing
patterns
will
help
okay,
and
we
also
point
out
I'm,
not
the
only
one
talking
about
this
kind
of
phenomenon
and
here's
a
long
list
of
evidence
that
lots
of
other
smart
people
are
talking
about
the
same
kind
of
issue
and
I'm
not
going
to
go
through
all
these.
But
hopefully
some
of
these
are
familiar
to
you
and
you're
nodding
your
head,
saying:
oh
yeah,
I've
heard
people
talking
about
this
or
that
or
the
other
and
all
of
those
are
the
similar
kind
of
an
arc.
A
Well,
we're
going
to
do
everything.
Blockchain
is
perfect.
Well,
maybe
there's
you
know
things
and
and
caveats
and
so
forth.
So
this
brings
me
to
the
question
I
asked
at
the
beginning
about
how
many
people
were
familiar
with
the
Gang
of
Four
book
I.
Don't
know
what
your
experience
you
good.
A
lot
of
other
people
also
raise
their
hand.
A
I,
don't
know
what
your
experience
with
this
book
was,
but
for
me,
I
encountered
this
at
a
point
in
my
arc
as
a
software
developer,
where
I
was
just
ready
to
realize
that
there
were
underlying
patterns
and
I
read
through
the
book
and
I
said
to
myself:
wait
a
minute
I've
been
doing
this
for
years,
and
that
was
kind
of
the
point
of
the
book.
The
book
wasn't
saying:
we're
gonna
reveal
to
you
magic
that
you've
never
realized
before
it
was
we're.
A
Gonna
give
a
name
to
a
particular
thing
that
we
see
happening
over
and
over
and
over
again.
Okay,
so
that's
my
goal
in
decentralized
design
patterns
is
to
say,
I
see
a
certain
thing
happening
over
and
over
again,
let's
as
an
industry,
let's
come
up
with
a
name
for
that
thing,
and
then
we
can
start
talking
about
it
and
having
a
more
disciplined
conversation
and
no
we're
talking
about
the
same
thing
so
a
little
bit
of
a
maybe
this
is
redundant.
A
Maybe
it's
obvious
to
everybody,
but
these
are
the
three
reasons
that
I
think
I
care
about
decentralization.
You
might
add
something
to
the
list
or
subtract
something
from
it,
but
basically
I
think
most
of
us
generally
agree
that
these
are
reasons
why
decentralization
could
be
a
useful
characteristic
and
these
are
related
to
each
other.
A
As
a
matter
of
fact,
in
some
cases
you
could
say
well,
the
performance
benefit
is
just
because
of
the
trust
benefit
or
you
know
or
whatever,
but
I
think
these
are
distinct
enough
and
interesting
enough
to
call
out
as
three
separate
items
we
decentralize,
because
we
want
to
change
trust
characteristics.
We
decentralize
because
we
want
to
change
performance
characteristics
or
because
we
want
to
change
scale
characteristics
if
we're
not
doing
it.
For
one
of
those
three
reasons,
I'd
be
really
interested
to
know
why
we're
doing
it
I
think
mostly
that
covers
it.
A
There
might
be
some
other
corner
cases
too,
but
anyway.
So
let
me
talk
about
some
patterns
now
before
I
go
into
these.
Let
me
point
out
something
that
I
have
seen
several
times:
Jason
who's,
one
of
my
colleagues
that
I
collaborate
with
a
lot
has
pointed
this
out
to
me
several
times,
I've
heard
other
smart
people
mention
it
too,
and
that
is
this.
A
Okay.
So
let
me
talk
first
of
all
about
the
invisible
hand
pattern-
and
these
are
just
names
that
you
know-
I
came
up
with-
maybe
there's
better
names
form
to
invisible
hand.
Of
course,
is
a
phrase
popularized
by
which
economist
Adam
Smith
in
the
1700s-
okay,
so
I'm
really
reaching
back
here,
but
actually
what
Adam
Smith
described
is
an
apt
name
for
this
pattern.
It's
the
notion
that
sometimes
you
can
incent
cooperation
without
central
enforcement.
A
Okay,
it's
not
only
in
Bitcoin
miners
that
the
invisible
hand
pattern
shows
up
how
about
announcing
a
bounty
for
a
bug
or
a
reporting
of
a
vulnerability
you're,
not
actually
controlling
anybody's
behavior.
When
you
do
that,
you're
indirectly
influencing
it,
because
you're
creating
an
incentive
that
that
leads
people
in
a
direction
that
you
want
to
go
and
the
direction
is
responsible
disclosure
of
vulnerabilities,
for
example,
or
whatever.
The
thing
is
that
you're
trying
to
incent
okay
money,
isn't
the
only
way
that
you
create
incentives,
how
about
systems
for
reputation
or
karma.
A
There
have
been
proposals,
specifications
about
how
something
ought
to
work
as
a
standard,
and
there
been
competing
proposals
and
one
of
them
has
a
test
suite
and
one
doesn't
guess
which
one
wins.
Why
does
it
win
because
you
can
show
you
can
you
can
you
can
claim
karma?
You
can
claim
points
you
can
you
can
claim
benefit
by
demonstrating
that
you
can
form
to
a
test
suite
and
there's
no
measurable
way
to
claim
conformance
the
other.
A
If
you
go
down
the
other
route,
you
can
say
well,
I
happen
to
interoperate
with
you
know,
person
one
and
I
can
prove
it,
but
you
can't
say
I
interoperate
across
the
board,
without
a
ridiculous
amount
of
effort,
so
test
Suites
change
incentives
in
an
interesting
way.
Now,
there's
some
opposites
to
this
certification
programs
sometimes
could
be
a
form
of
opposite,
not
always
a
test
suite
and
a
certification
are
not
that
far
apart.
A
It's
just
a
pattern
that
has
certain
characteristics:
okay,
a
little
bit
more
about
the
invisible
hand,
pattern
you're,
making
some
trade-offs.
When
you
use
this
pattern
because
the
hand
is
invisible,
you
are
sometimes
giving
up
some
transparency
and
that,
along
with
that,
there's
a
lack
of
precision
and
predictability.
A
Theoretically,
let's
suppose
that
I
had
the
power
to
circulate
a
rumor
that
the
latest
version
of
the
Bitcoin
mining
software
actually
was
doing
some
kind
of
an
exploit,
and
was
you
know
unreliable
theoretically,
I
could
change
the
incentives
of
a
large
set
of
people
pretty
quickly
and
you
wouldn't
be
able
to
predict
the
effect
and
that's
because
we're,
depending
on
an
invisible
hand,
there's
a
little
bit
less
transparency
than
we
have
with
some
alternative
mechanisms.
So
it's
trade-off
right,
it's
also
possible
or
I'm.
A
Sorry,
it's
also
important
to
note
that
sometimes
it
can
be
hard
to
trade
to
change
an
incentive
once
you
get
it
well
entrenched
people
don't
want
to
give
up
their
incentive-
and
you
say:
hey
I,
think
I'm
gonna
change
the
way,
incentives
work
in
Bitcoin
and
you
end
up
forking
the
community
or
something
because
people
really
don't
want
you
to
change
that.
So
that's
that's
another
trade-off
you're,
making.
A
A
Okay,
if
you
impose
it
who's,
you,
whoever
you
is,
is
centralized.
So
therefore,
you've
given
up
a
bunch
of
the
benefit
I'm
being
a
little
bit
black-and-white
here,
it's
actually
a
little
bit
muddy.
How
you
impose
it
whether
the
community
agreed
to
adopt
it
as
a
consensus
based
choice
or
a
standards
organization,
simply
decreed
it,
but
you
get
the
idea.
You
need
to
be
sensitive
to
whether
or
not
you're,
giving
up
the
benefit
you
think
you're
getting
by
the
way.
You
actually
impose
the
invisible
hand
influence
okay
enough
of
that
pattern.
A
A
A
There
can
be
performance
and
scale
overhead
costs
to
using
this
pattern
and
it
changes
the
trust
dynamics.
A
two-party,
interaction
and
a
three-party
interaction
are
not
quite
the
same
from
a
trust
perspective
that
could
be
not
the
same
in
a
good
way
or
not
the
same
in
a
bad
way,
they're
just
different,
so
you
need
to
understand,
for
example,
there's
different
regulatory
compliance
dynamics
between
two
party
and
three
party
systems.
A
Okay,
some
gotchas
to
be
aware
of
with
this
pattern.
Mediators
that
can
unblind
themselves
could
be
dangerous
and
so
that
there
are
ways
of
doing
a
blind
mediator
where
you
kind
of
depend
on
the
mediator
being
blind
and
there's
ways
of
doing
it,
where
you
don't
have
to
depend
on
the
mediator
being
blind,
because
you
force
them
to
be
blind
and
that's
what
I'm
trying
to
tease
out
there.
You
have
to
recognize
the
different
possibilities.
A
Even
a
blind
mediator
can
skew
the
dynamics
of
interaction.
For
example,
you
could
have
a
service
on
the
internet
that
deliberately
delays
traffic
coming
from
this
part
of
the
world
versus
that
part
of
the
world.
It
may
not
know
much
else,
but
that
may
skew
something
about
the
interaction
and
even
mediators
may
need
to
be
audited
enough
on
that
one.
A
The
sharding
pattern
is
an
interesting
one
and
all
of
our
crypto
experts
out
there
will
nod
their
heads
immediately
at
the
word
sharding,
but
it's
not
just
cryptography
where
sharding
shows
up
as
we
speak.
Super
Tuesday
is
happening
in
the
United
States.
That's
an
election
formalism,
that's
a
form
of
sharding,
so
to
speak,
you're
spreading
input,
duties
across
lots
of
different
parties.
I
didn't
mean
political
parties,
entities
lots
of
different
entities
who
are
all
contributing
to
an
answer.
A
A
The
last
one
I
put
down
is
kind
of
an
interesting
one,
two
keys
when
you
do
a
in
an
in
a
nuclear
missile
silo
the
there's
two
physical
keys
that
have
to
be
turned
to
launch
a
missile
and
they're
deliberately
placed
too
far
apart
for
one
human
being
to
turn
them.
You
can't
get
both
keys
with
with
human
reach
turned
at
the
same
time.
That's
because
they're
trying
to
shard
the
responsibility
they
don't
want
to.
Let
one
person
centralize
the
responsibility
there.
A
So
the
opposite
of
this
pattern.
It
would
be
something
like
sharing
keys,
our
passwords
in
human
government
dictators
or
the
opposite
of
this
kind
of
pattern
having
overly
primly
privileged
sis.
Admins
is
kind
of
an
example
of
the
opposite
of
this
pattern
and
having
backdoors
is
the
opposite
of
this
pattern
because
it
lets
you
short
short
circuit.
The
sharding.
A
Now
sharding
has
some
trade-offs.
One
of
them,
that's
may
be
worth
some
thinking
about,
is
you're,
incurring
a
user
experience
burden
around
the
process
of
reassembling
the
shards
it's
great
to
break
stuff
apart
that
part's
easy
putting
it
back
together
is
hard
I'm,
not
saying
it's
hard
mathematically
or
code-wise
I'm,
saying
it's
hard
from
a
user
experience.
Point
of
view.
How
do
you
help
a
person
understand?
What's
going
on
when
they're
trying
to
assemble
all
these
pieces?
And
how
do
you
do
that
in
a
way
that's
friendly
and
robust
and
resilient
and
so
forth?
A
A
The
other
thing
to
know
about
this
on
the
Gotcha
side
is
when
Yuri
and
I've
seen
a
number
of
architectures
in
our
space
miss
this
particular
point.
When
you
reassemble
the
shards,
somebody
now
can
see
of
you
without
the
shards
and
if
you
don't
then
get
new
shards
in
place.
You
have
essentially
undone
all
of
your
benefit.
So
let
me
explain
if
you
have
five
buddies
that
are
gonna
all
help.
A
You
reassemble
your
identity
and
your
five
buddies
bring
their
pieces,
they
put
them
on
a
table
and
whoever
can
see
the
table
now
doesn't
see
the
shards.
They
see
the
whole
thing
all
together
right
and
once
they've
seen
the
whole
thing
all
together.
They
can't
unsee
that
so
the
only
way
that
you
can
preserve
things
across
an
assembly
is
to
create
new
shards.
Afterwards,
that's
what
I'm
talking
about
there.
A
If
you're,
not
careful
a
loss
of
a
shard
could
be
fatal,
so
you
need
to
set
up
redundancy
and
how
in
your
properties-
and
you
need
to
think
about
collusion
by
the
people
that
hold
a
shard
okay,
this
is
another
one.
That's
super
common
in
our
space
in
the
blockchain
space.
We
use
it
all
the
time,
but
we
don't
see
the
connection
as
a
pattern
very
commonly
I.
A
A
A
A
So
we
know
whether
the
commit
is
the
same
one
that
we
were
thinking
of
the
simple
act
of
checking
digital
signatures,
usually
is
evidence
that
somewhere
there's
a
tamper,
rejection
pattern
that
we're
trying
to
implement
and
surface
not
always
but
usually
checking
signed
binaries
before
we
install
something
anyway.
I
won't
go
through
all
these
exhaustively,
but
the
opposites
of
this
would
be
trusted
services
or
trusted
Oracle's.
So
a
trusted
service,
you're
saying
look
I'm
asking
you
to
do
some
work
and
you'll
just
do
it.
A
For
me,
a
trusted
Oracle
is
I'm,
asking
you
a
question
and
you'll
give
it
back
to
me
either
of
those
is
kind
of
an
example
where
the
tamper
rejection
kind
of
goes
away.
Why
does
it
go
away
because
you're
asking
a
service
which
is
a
central
point
to
do
something
for
you
and
you
just
have
to
trust
that
the
service
did
it
for
you
right?
You
no
longer
can
detect
whether
the
service
itself
is
tampering.
A
You
might
be
able
to
detect
whether
others
can
tamper,
but
you
can't
detect
whether
the
services
and
the
same
thing
for
an
Oracle,
okay,
some
trade-offs
and
gotchas
with
this
pattern,
there's
some
complexity
that
you're
incurring.
Sometimes
when
you
do
the
tamper
proofing,
you
often
make
it
difficult
to
do
harmless
updates
and
those
people
like
Alex,
who
have
been
down
in
the
guts
of
a
distributed,
ledger
or
blockchain
codebase,
really
get
this
at
a
kind
of
an
instinctive
level
like
because
these
things
are
not
going
to.
Let
you
change
anything
without
a
new
transaction.
A
It's
just
you
know
doing
something
simple.
Like
the
other
day,
I
published
some
documentation
and
then
I
found
out
that
I
actually
didn't
put
a
period
at
the
end
of
a
sentence,
not
the
end
of
the
world,
but
since
I'm
picky
I
wanted
to
go
change
that
and
if
I
had
published
that
documentation
to
a
blockchain
doggonit,
the
transaction
that
I
just
said,
everybody
told
everybody
was
the
one
that
had
my
canonical
stuff
in
it.
Now
is
different.
That
could
be
okay,
but
it
can
sometimes
be
a
pain.
A
This
one
about
upstream
and
downstream
tampering
on
the
Gotcha
site,
I'd
like
to
comment
about
for
just
a
minute
side
tree
is
a
very
interesting
project,
sponsored
by
the
decentralized
identity
foundation
that
allows
you
to
offload
a
lot
of
traffic
from
slow
block
chains.
So
what
you
do
is
you
batch
up?
Hundreds
or
thousands
or
millions
of
transaction
requests
on,
let's
say
a
Bitcoin
blockchain
and
you
commit
all
of
those
requests
as
one
transaction.
So,
instead
of
running
a
million
transactions,
you
run
one.
A
The
problem
is
and-
and
of
course
blockchain
I
mean
we're
talking
Bitcoin
here,
it's
tamper,
resistant
and
everything,
but
the
service
that
batches
things
doesn't
have
to
prove
that
it's
doing
anything
right,
and
so,
if,
if
that's
the
case,
then
what
you're
giving
up-
and
this
might
be
a
smart
trade-off-
I'm
not
saying
this
is
a
bad
idea.
I'm
just
trying
to
make
us
conscious
of
it.
What
you're
giving
up
is
the
ability
to
reject
tampering
by
that
particular
service.
A
So,
upstream
of
the
point
where
you
commit
it
to
the
blockchain
or
downstream,
you
can't
detect
it.
Maybe,
but
at
least
at
the
moment
of
the
blockchain,
you
still
can
and
maybe
that's
a
good
trade-off.
Okay,
this
one
is
really
obvious,
but
I've
actually
seen
it
used
in
some
clever
places
that
maybe
aren't
so
obvious
just
having
an
unpredictable
selection.
So
Bitcoin
proof-of-work
is
based
on
this
principle.
The
notion
is,
everybody
needs
to
mine
and
there's
no
way
of
predicting
in
advance.
A
Why
so
that
you
cannot
subvert
the
system
and
and
steal
ownership
of
an
identifier
that
you're
not
supposed
to
so
that's
unpredictable
selection
of
the
value
of
it
did
if
you
could
today,
if
you
go
read
the
documentation
of
how
grids
and
uu
IDs
work,
you'll
see
that
these
are
algorithms,
that
if
you're
used
like
a
UUID
version,
2
or
version
3,
certain
parts
of
the
UUID
are
predictable,
they're
owned
by
a
certain
entity
right.
Your
organization
should
always
use
the
same
values
in
here.
A
Well,
that
predictability
is
giving
up
some
of
this
pattern
and
I
could
be
a
good
trade-off
again
I'm,
just
in
plenum
what
that
Alex
talked
about
in
the
session
right
before
this.
If
you
know
who
the
next
leader
is
going
to
be
in
a
consensus
algorithm,
then
you
can
mount
follow-the-leader
attacks
so
having
a
leader
in
your
consensus,
that's
unpredictable
makes
it
harder
to
follow
to
do
a
follow-the-leader
attack.
A
The
trade-offs
here
are,
you
cannot
optimize,
predictably,
if
the
thing
that
you're
trying
to
optimize
is
deliberately
unpredictable,
and
that
could
be
a
good
trade-off
or
not.
It's
also
difficult
to
audit.
So
an
example
of
that
that
concern
is
if
I,
don't
know
that
this
is
true,
but
if
some
government
were
able
to
take
over
a
massive
percentage
of
the
Bitcoin
miners
in
the
world,
we
wouldn't
have
any
way
to
know
that
they
had
done
so
it
would
look
random
to
the
rest
of
us,
but
it
wouldn't
be
random
to
them.
A
I'll
just
highlight
on
the
gotchas
thing
here:
PR
NGSS,
PR,
Angie's,
pseudo-random,
number
generators
versus
cryptographically,
secure,
random
number
generators
really
are
different
and
if
you
don't
believe
me
go
read
some
of
the
vulnerabilities
that
have
been
reported
in
various
places,
so
this
could
be
a
gotcha
if
you
say
well
we're
randomizing
something,
but
the
randomization
is
based
on
a
weak,
random
number
generator
you're,
probably
not
nearly
as
beneficial
on
this
pattern.
As
you
think,
strategic
gossip
is
another
pattern.
A
A
A
A
So
you
don't
know
whether
you're
working
off
of
complete
information
and
that
could
be
a
bad
thing
or
not
just
depends
on
the
circumstances.
The
other
thing
to
think
about
is
lies
can
be
propagated
by
gossip
too.
So
you
might
want
to
combine
a
gossip
pattern
with
a
tamper
rejection
pattern,
for
example,
so
that
you
know
that
you're
not
propagating
a
lie.
A
One
of
the
trade
offs
you're
making
there
is
latency.
You
can't
just
talk
to
the
other
person
on
demand
and
you
also
might
be
in
a
fragile
state
where
you
don't
have
any
recourse
if
the
brick
wall
gets
knocked
down
by
a
bulldozer
you're
in
trouble.
So
let
me
get
out
of
the
specific
patterns
for
a
minute.
There's
more
patterns,
I
just
picked
six
or
seven.
That
I
thought
were
interesting
to
talk
about
here
and
I.
Just
want
to
ask
for
the
last
segment
of
this
presentation.
A
I
invite
you
to
think
about
some
of
these
thought
questions.
Are
you
really
getting
the
decentralization
benefits
that
you
want
out
of
your
architecture?
If
you
don't
know
what
benefits
you
want,
then
what
what
did
the
Cheshire
Cat
say
in
Alice
in
Wonderland?
If
you
don't
know
where
you're
going,
it
doesn't
really
matter
which
direction
you
go.
A
So
that's
fine,
but
hopefully
you
actually
have
some
intended
benefits,
you're
trying
to
get
out
of
decentralization
and
are
you
getting
them
and
what
pattern
should
you
use
if
you
want
benefit
X
I
know
what
are
the
reasons
to
use
an
observer
pattern
from
the
Gang
of
Four
book.
I
mean
I'm,
not
an
expert
at
it,
but
I
can
give
you
a
couple
anyway
and
I
think
we
ought
to
be
better
as
an
industry
about
saying
well,
there's
a
reason
why
you
should
use
the
sharding
pattern.
A
Here's
the
trade-offs
to
it,
and
this
is
what
you
get
when
you
use
the
sharding
pattern.
It's
a
reproducible
recipe
kind
of
you
plug
in
these
things,
outcome
these
things
and
so
I'm.
Inviting
us
to
think
about
that.
Where
do
particular
patterns
show
up
that
you
hadn't
realized
before,
and
this
is
a
really
interesting
one.
Are
there
some
classic
Gang
of
Four
patterns
that
are
already
decentralized
and
should
there
be
decentralized
versions
of
some
other
patterns
so,
for
example,
just
to
get
you
thinking
there?
A
The
command
pattern
has
some
really
interesting
decentralized
properties,
possibly
depending
on
how
you
implement
it.
I
can
think
of
a
way
to
implement
it,
that's
bad
and
from
a
decentralization
point
of
view,
and
what
is
good,
how
do
particular
patterns
decay
if
they're
not
implemented
right?
Should
you
be
using
I,
just
threw
out
some
examples,
tamp
or
fail
with
your
install
and
configuration?
How
many
of
us
have
block
chains
is
where
we're
touting
all
this
wonderful
properties,
but
the
installation
of
the
block
chain
software
itself
doesn't
require
us
to
check
signatures.
A
Stop
and
think
about
that
for
a
minute
if
somebody
has
a
malicious
version
of
the
blockchain
software,
what
can
they
subvert?
Maybe
nothing.
Maybe
you
don't
care,
but
it's
an
interesting
question
that
I'm
not
sure
we're
thinking
about
very
well
okay.
So
those
are
the
thought
questions
and,
lastly,
I
want
to
leave
you
with
this
I'm
soliciting
input,
because
I
think
that
there
really
ought
to
be
a
book
about
this
and
I'd
love
to
have
people
teach
me
what
you
know
about
this
topic.
A
I
think,
there's
probably
a
large
body
of
knowledge
about
this
topic
out
there
in
this
audience
and
this
general
community
we're
filled
with
smart
people
who
have
lots
of
interesting
experience.
But
we
haven't
approached
the
vocabulary
about
this
in
a
disciplined
way.
To
my
knowledge,
so
I
think,
if
we
did,
it
would
start
becoming
easier.
A
We
would
look
at
a
design
and
we'd
say
everything's
great
about
that,
except
you
just
need
to
you
know
you
just
need
to
shard
this
or
you
just
need
to
have
this,
be
a
tamper
rejection
pattern
so
that
we're
a
little
bit
stronger
on
this
one
dimension.
We
would
start
seeing
those
kinds
of
things
and
the
patterns
would
make
sense
to
us
with
that.
I
think
I'll
go
to
question
mode.
A
You
just
made
jason's
day,
I
love
the
topic
of
protocols
and
I
could
talk
for
hours
about
protocols.
I
agree
with
you
that
protocols
are
super
powerful
and
interesting
as
a
matter
of
fact,
if
I
could
get
a
PhD
in
computer
science,
that's
what
it
would
be
on,
because
in
many
ways
protocols
allow
you
to
take
these
are
kind
of
primitive
ideas
and
to
take
them
and
package
them
at
a
higher
level.
A
The
order
er,
okay,
the
order
are
in
fabric
well
I'm,
not
familiar
with
that
component.
Very
well,
but
I
know
a
little
bit
about
how
that
works
and
what
I
do
know.
I
would
say
yes,
but
somebody
who's,
a
fabric
expert,
could
maybe
say
no
no
you're
off
you're
gonna.
You
know
you're
smoking
dope,
but
I
I,
don't
know
that
I
think
it
does.
A
I
would
expect
for
any
one
of
these
patterns.
We'll
look
around
and
say:
oh
that's
an
example.
That's
an
example.
They're
all
over
the
place,
this
you
know,
there's
nothing
original
here.
It's
it's
calling
out
things.
People
have
already
been
doing,
is
all
I'm
trying
to
do
so.
I'm
sure,
there's
examples
of
lots
of
patterns
in
fabric
and
sawtooth
and
all
the
other
ones.
A
This
is
what
I
meant
when
I
said
that,
depending
on
how
you
do
some
of
these,
it
could
break
either
way.
If
you
can
imagine
a
bounty,
that's
kind
of
offered
by
a
community
collectively
like
there's
some
kind
of
kitty
of
bitcoins
or
something
that
people
can
claim,
or
whatever
that's
kind
of,
on
the
more
decentralized
variant
side.
A
A
Yeah
yeah,
and
so
this
could
not
I
mean
maybe
this
there's
a
better
name
for
this,
and
maybe
if
we
named
it
more
precisely
and
defined
it
more
precisely,
we'd
find
that
the
muddiness
disappears
because
we've
just
defined
it
better.
So
this
is
my
first
attempt
to
name
it
and
the
way
I've
named
it
I
think
it
is
muddy
or
it
could
be.
A
A
Okay,
I
think
we're
about
out
of
time.
I
know
everybody's
tired,
thank
you
for
coming
I'm,
happy
to
hang
out
and
talk
more
if
anybody
wants
to
the
slides
are
uploaded
to
the
conference
agenda,
although,
like
I
said,
I
found
a
error
in
my
slides
while
I
was
presenting,
so
I'll
probably
have
to
have
to
upload
an
update,
but
thank
you
very
much.