►
From YouTube: Running Hyperledger Sawtooth in Production
Description
Duncan Johnston-watt & Kevin O'Donnell, Blockchain Technology Partners
In this talk we provide a brief overview of Hyperledger Sawtooth and our rationale for focusing on this framework. We discuss the challenges of running Sawtooth in production and the benefits of standardizing on Kubernetes as the underlying container orchestration platform. We then introduce blockchain management platform https://blockchaintp.com/sextant/ that delivers one-click deployment of enterprise-grade Hyperledger Sawtooth networks running on Kubernetes in the cloud. We explain how Sextant utilizes a Sawtooth distribution built, tested and maintained by us. We wrap with a demo of Sextant and call to action to get involved and try this out for yourself on https://aws.amazon.com/marketplace/pp/B07KDRYTY5
----
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
Hi
good
morning,
we'll
get
started
I'm
sure
people
are
going
to
drift
in
because
it's
that
kind
of
event,
but
I
don't
want
to
make
you
guys
late
for
the
next
thing
so
and
we'll
upload
these
slides
onto
the
on
to
the
schedule
website.
Right
after
the
talk,
so
we
can
add
attach
a
presentation
to
the
to
the
item
so
welcome
to
the
first
of
the
breakout
sessions
of
day
two.
A
So
my
name
is
Duncan
Johnston,
maude
I'm,
the
co-founder
and
CEO
of
blockchain
technology
partners
and
I
have
with
me
Kevin
Kevin's,
our
co-founder
and
chief
strategist,
so
brains,
brawn,
well,
maybe
not
brawn,
but
anyway.
So
what
we
wants
to
talk
about
and
I
think
it's
quite
topical
is
the
really
you
know
the
considerations,
the
issues,
the
challenges
of
running
in
this
case
hyper
laser
sources.
A
It's
going
to
be
high
level
and
it's
basically
a
sample
of
some
of
the
slides
that
Dan
Middleton
put
together,
going
all
the
way
back
to
when
hyper
ledger.
Sorties
was,
in
fact
lon
just
ins
of
as
1.0
in
in
february
of
this
year,
but
it's
important
I
think
for
us
to
not
just
tell
you
a
little
bit
about
this.
A
What
we
think
of
some
of
the
benefits,
but
also
cover
the
architecture,
at
least
at
a
high
level,
and
also
what
it
means
to
develop
applications,
because
one
of
the
things
that
I
think
it's
important
to
understand
is
all
of
the
blockchain
frameworks
within
the
hydrologic
community.
Our
middleware
century
and
a
middleware
as
any
of
us
would
would
appreciate,
is,
is
not
something
that
is
in
and
of
itself
useful.
It's
really
how
you
apply
it.
A
What
you
do
with
it
is
the
applications
that
you
build
on
it
that
really
make
it
interesting
so
we'll
cover
that.
But
we'll
talk
about
that,
then
what
I'll
do
is
hand
over
to
Kevin
he's
really
going
to
get
into
the
detail
of
you
know
what
are
the
considerations
you
need
to
think
about
in
terms
of
a
production
deployment
of
in
this
case
sorties,
but
as
I
say,
it
can
be
applied
to
other
frameworks
and
then
looking
in
a
little
more
detail
at
what
we've
been
doing
practically
speaking,
to
develop
a
blockchain
management
platform.
A
That's
because
I
think
this
session
is
is
all
being
captured
somehow
anyway,
so
come
to
the
introduction.
So
our
vision,
if
you
will,
is
very
simple,
we
want
to
make
it
as
easy
as
possible
for
people
to
actually
utilize
blockchain
in
this
case
sources.
So
in
other
words,
let's
get
rid
of
all
the
all
the
issues
take
all
the
issues
off
the
table
so
that
you
can
actually
become
productive.
You
can
innovate,
you
can
develop
applications
and
therefore
realize
the
real
benefits,
and
so
that's
not
exclusive
to
blockchain.
A
That
is
a
standard
approach,
create
the
right
level
of
abstraction,
give
people
the
tools.
The
ability
in
essence
provide
the
platform
so
that
you,
if
you're
a
developer,
do
not
have
to
deal
with
that.
So
so
that's
essentially
the
the
goal
here.
Our
mission,
our
vision
in
life,
is,
let's
make
it
as
easy
as
possible,
remove
as
much
of
the
friction
as
possible,
so
that
you
can
actually
get
on
and
do
something
useful
and
interesting
with
in
this
case,
sorties.
A
We
as
a
company
small
company,
need
to
be
very
focused,
so
what
is
it
we're
doing?
We're
providing
something
called
sextant?
So
sextant
is
a
blockchain
management
platform.
We'll
show
you
that
later
it
takes,
as
it's
starting
point
to
I,
think
really
important
starting
points
not
just
sorties
from
within
the
hi
pleasure
family,
but
kubernetes
from
within
the
cloud
native
computing
foundation.
A
You
know
we
can't,
even
if
Brian
wanted
to
mandate
that
kubernetes
should
be
the
runtime,
but
it's
already
clear
that
a
lot
of
projects
and
this
workshops
tomorrow
and
Saturday
that
are
also
looking
into
this
in
detail
that
that
is
essentially,
you
know
the
the
direction
of
travel
for
the
hyper
layer
community,
and
why
is
that
good?
Well,
because
CN
CF
is
another
collaborative
project
within
the
Linux
Foundation.
So
you
know
you
get
the
best
of
both
worlds.
We
get
the
best
of
blockchain
for
enterprise.
A
Now
we
get
the
best
of
of
really
orchestration
and
container
based
orchestration,
and
you
know
these
projects
have
have
tremendous
provenance.
Provenance
is
something
we
talk
about
a
great
deal
in
terms
of
blockchain.
The
provenance
is
also
important
in
terms
of
where
things
come
from
and
and
Google
contributed
and
I
use.
The
word
contributed:
nobody
gives
software
to
a
foundation,
they
always
contribute.
It's
always
under
a
license.
So
I
mean
to
really
bear
in
mind.
A
We've
done
that
I've
done
that
the
past
was
a
company
contributed
something
that
became
Apache
Brooklyn,
but
the
idea
is
what
you're
doing
is
you're
licensing
its
use
under
very
specific
circumstances.
You're,
therefore,
ensuring
that
you
know
any
IP
or
any
patent
infringement
is
you're
exonerated
from,
but
it's
only
in
the
context
of
how
you
use
that
software.
You
can't
hack
it
and
then
put
your
name
on
it.
A
So
that
means
by
the
way
you
do
not
have
to
listen
to
me
drone
on,
because
you
can
just
go
experiment
with
this
stuff
and
we'll
put
some
lists
of
resources
at
the
end
of
this
session,
and
then
finally,
we
want
to
work
with
you
on
interesting
projects.
So
you
know,
whilst
fundamentally
were
a
platform
company.
We
also
think
there's
tremendous
values
we
had
integrating
or
cooperating
with
or
co-creating
with
with
people.
Why?
A
Because
we
get
tremendous
feedback
that
way,
and
hopefully
we
can
impart
some
of
our
learning,
some
of
our
knowledge
and
then
finally,
I
guess
we're
old,
timers.
Well,
I
am
anyway,
but
when
I
say
well
long-standing
members
of
the
Linux
Foundation.
This
goes
back
to
my
previous
company,
so
we
were
an
early
member
of
the
hyper
ledger.
Community
is
when
I
was
a
cloud
soft
and
we
renewed
our
vows
in
March
this
year
when,
when
watching
technology,
Pradas
partners
started
to
get
going
and
then
a
little
bit
later
on
in
the
year.
A
So
around
sort
of
September
timeframe
we
signed
up
for
CN
CF,
so
so
fully
paid-up
members
of
both,
we
think
is
important
to
you,
know,
be
a
member
and
contribute
and
collaborate
and
work
with
the
communities,
and
it
is
both
communities,
so
think
of
Linux,
as
you
know,
really
providing
that
sort
of
safe
harbor
for
a
number
of
collaborative
projects.
Forty
plus,
at
this
point,
some
of
them
obviously
about
Linux
itself
like
what
Emotiv
Linux,
but
many
many
others
besides,
including
of
course
CN,
CF
and
and
hyper
ledger.
A
The
value
add
the
the
the
from
our
point
of
view
of
sorts
is
so
number
one,
and
hopefully,
if
you
were
in
the
keynote-
and
you
heard
Dan
speak
about
this
in
terms
of
the
work
of
the
performance
and
scalability
working
group,
the
scalability,
the
arity
the
size.
The
dimension
of
the
network
is
incredibly
important
and
we
think
that
sawtooth
is
very
modular,
very
scalable
and
by
the
way,
that's
because
it's
very
simple,
it's
very
elegantly
designed
it's.
It's
got
a
small
number
of
moving
parts.
A
In
addition,
there
is
a
clear
separation
between
what's
happening
within
the
network
layer,
so
this
is
really
the
the
network
of
validators
and
what's
happening
at
the
application
tier,
so
the
transaction
processes
and
I'll
get
into
that
in
the
primer
in
a
second,
but
that
clear
separation
is
hugely
hugely
important.
Why?
If
you're
a
developer-
and
we've
proven
this
by
the
way
running
workshops
over
the
last
few
weeks,
if
you're
a
developer,
you
can
bring
to
the
party.
All
of
that
experience,
you
have
around
client-server,
architectures,
asynchronous
messaging
and
so
on
and
so
forth.
A
All
of
that
applies
you're,
not
having
to
rewire
your
brains
and
somehow
develop
applications
in
a
different
way.
You
have
to
think
carefully,
but
hopefully
you
always
thought
carefully,
not
just
because
you're
using
a
blockchain
about
how
you
know
how
to
have
a
best
represent
state,
in
particular
another
cool
thing,
and
this
has
really
come
to
the
fore
with
the
the
launch
of
1.1.
A
Is
this
notion
of
pluggable
consensus
and
consensus
itself
as
being
configuration
a
setting
on
the
blockchain
that
can
actually
be
changed
or
tuned,
so
the
pluggable
consensus
means
that
you've
got
everything
from
dev
mode
if
you're,
just
using
a
single
validator
through
the
poet
poet,
SGX
raft
pbft,
and
there
will
be
others
as
we
go
forwards
and
really
that's
very
important
as
you
look
at
not
the
blockchain,
but
your
particular
blockchain
Network
how
you're
applying
it?
What
is
the
purpose?
A
What
is
the
application
that
you're
trying
to
implement
or
set
of
services
you're
trying
to
implement
that
will
command?
How
and
who's
involve?
All
of
those
things
will
influence
the
shape
of
the
consensus
and
other
decisions
that
you
take.
And
finally,
and
again
this
is
again
the
Hyperlight
you're
looking
out
with
its
own
community
and
saying
we
need
to
support
other
standards.
A
So
this
is
supporting
solidity
through
the
borough
EVM
and
it's
also
supporting
wisdom
through
something
called
sawtooth
Sabre,
which
is
a
part
of
the
sorties
sort
of
project,
and
there
was
a
a
brief
advert
for
project
Voldemort
or
whatever
it's
going
to
be
called
when
people
can
agree
on
the
name
which
normally
takes
longer
than
actually
writing
the
code.
It
would
seem,
but
this
this
supply
chain
building
blocks
thing,
that's
being
brought
in
as
cause.
A
You
know
certain
amount
of
controversy
or
controversy,
but
but
the
general
idea
is,
let's
start
to
show
how
one
can
build
on
these
blockchain
networks.
And
so
it's
the
building
blocks
the
the
components
that
could
make
up
a
supply
chain.
And
if
you
look
at
that
they're
using
the
web
assembly
integration,
so
so
that
that
ability
to
bring
again
existing
experience
to
bear
solidity.
A
If
you've
worked
in
the
etherium
and
working
with
remix
and
truffle
by
the
way
I
had
to
practice
in
front
of
a
mirror
saying
truffle
without
smirking,
because
the
names
of
these
things
just
cracks
me
up
but
am
I've
failed.
But
anyway,
moving
swiftly
on
I
said
it
was
simple.
I
said
it
was
highly
modular.
This
is
as
complicated
as
it
gets,
and
this
is
straight
out
the
documentation.
A
So
what
do
I
have
when
I
sort
of
unpack
or
peer
below
the
surface
of
a
of
a
sorties
Network
I
have
validators
so
think
of
a
validator
as
a
peer
in
the
network.
They're
all
talking
they're
talking
using
0
mq,
so
another
big
plus
using
a
standard
messaging
transport.
So
not
something.
We
went
off
and
wrote
ourselves,
but
this
is
all
this
is
all
to
do
with
how,
in
a
good,
open
source,
sort
of
ethos
or
mindset,
you
bring
together
other
components
that
have
proven
their
value
over
time.
A
So
the
network
of
validators
talk
themselves.
They
maintain
the
global
state
and
ultimately,
the
blockchain
itself
across
all
of
those
nodes.
That's
the
network
layer
pure
and
simple.
It's
just
a
bunch
of
validators,
all
all
communicating,
and
they
do
one
other
thing
which
is
really
important.
When
transactions
come
through
from
clients
and
go
through
the
REST
API,
it's
the
job
of
the
validator
to
route
those
or
route,
depending
on
which
side
of
the
pond.
You
are
those
those
transactions
to
the
right
transaction
processor
to
the
right
transaction
family.
A
So
this
is
a
really
nice
way
of
actually
segmenting
the
world.
Tepees
transaction
processes
allow
you
to
divide
and
conquer
and
actually
partition.
You
know
the
workload
across
across
a
sawtooth
Network.
So
that's
it.
That
pattern
is
repeated
everywhere
everywhere
you
go,
you
can,
you
know,
look
look
at
every
node.
Every
node
will
have
a
validator
and
a
set
of
transaction
processors
that
are
permissioned
or
allowed
to
be
actually
connected
to
the
network
and
the
way
you
personalize
or
the
way
you
yeah
personalized
I,
like
the
word
personalized.
A
The
way
you
you
you,
you
personalize,
a
sorties
Network
is
the
set
of
teepees
themselves,
so
there's
some
standard
ones
that
come
out
of
the
box,
but
in
general
this
is
where
you
start
to
add
value
and
differentiate,
because
now
you're
running
ATP,
that's
doing
a
specific
business
process,
and
so
on
so
the
primary
here
we
go
again
in
the
same
way
that
the
architecture
is
really
simple.
So
is
the
mental
model.
A
I
can
get
this
okay,
there
are
clients
they
talk
to
serve
as
they're
called
transaction
processes,
but
it's
client-server,
the
validator
is,
is
essentially
handling
the
the
routing
mechanism.
Also,
if
you
drill
down
at
the
network
layer,
the
validators
plural
are
handling
the
global
state
and
that's
the
state
of
the
world
as
it
is
now
and
then
the
history
of
the
world.
So
those
are
the
two
things
if
you're
not
familiar
with
this.
These
are
the
two
key
takeaways
there
is
the
state
of
the
world
and
then
there's
the
history
of
the
world.
A
So
that's
what
you
need
to
know
about
blockchain,
it's
essentially
you're.
Looking
after
both
go
down
or
or
scratch
below
the
surface,
a
little
more
and
we're
all
were
doing
is
fleshing
out
this
story
that
now,
in
order
to
talk
to
the
the
underlying
blockchain
network,
go
through
a
rest
service.
That's
all
that
slide
says
moving
swiftly
on
now
we're
just
opening
up.
A
If
you
like,
the
the
box,
that's
called
the
validator
or
the
sort
whose
host
being
all
of
this,
but
the
validator
itself
is
as
I'm
saying,
managing
the
global
state
and
the
history
of
the
world
and
doing
that
in
conjunction
with
in
in
coordination
with
all
of
the
other
validators,
which
are,
you
know,
shown
their
bottom
left
as
you
look
at
it.
I
think
yes,
okay,
not
the
other
left.
A
Then
the
the
final
thing-
and
this
is
this-
is
hugely
important,
as
I
said
earlier,
this
notion
of
being
how
to
plug
in
your
consensus,
algorithm
and
and
actually
be
able
to
then
specify
that
you've
done
that
so
the
settings
TP,
which
Kevin
will
probably
touch
on
a
bit,
it
won't
get
into
the
the
guts
of
what
we're
doing,
deploying
deploying
one
of
these
networks.
It's
one
of
the
standard
transaction
processes.
A
So
finally,
three
slides
on
what
it
means
to
develop
an
application.
It's
the
same
old
same
old.
It
really
is.
It's
what
transactions
can
I
initiate
as
a
client,
so
in
the
case
of
tic-tac-toe,
which
is
a
great
demo
by
the
way
and
we'll
be
demoing
that
this
afternoon
in
more
detail
in
one
of
the
demos
theater
sessions
but
tic-tac-toe
noughts
and
crosses
what
can
you
do?
You
can
create
a
game
you
can
actually
play,
make
a
move.
Yeah,
it's
very
simple.
A
The
transactions
that
you're
allowed
to
do
are
very
there's
a
very
small
number
of
those,
so
those
transactions
represent
the
interaction
between
the
client
and
the
server
transaction
processor
and
then
that
it's
really
the
only
other
bit
to
think
about
is
you
know.
The
rules
of
the
game
are
here
in
the
case
of
tic-tac-toe,
and
the
data
model
is
really
you
working
out.
What
do
I
need
to
store
on
chain
and
what
can
I?
You
know,
store
retrieved
from
other
sources,
so
please
do
not
think
everything
has
to
be
stored
on
chain.
A
A
Because
the
term
is
I
guess
out
there
like
block
chains
out
there
like
Hoover
Dyson.
If
you
know
what
I'm
talking
about
yeah
people
have
got
smart
contracts
and
the
canonical,
if
you
will
definition,
certainly
in
my
head,
is
something
like
you
know:
er
C,
20
standard
smart
contract,
but
you
know
the
analogy
analogy
or
is
between
a
TP
and
quote
a
smart
contract,
so
think
of
them
as
roughly,
but
better
still,
just
think
of
them
as
handling
a
piece
of
business
logic
that
self-contained
that
can
be
captured
with
a
semantics.
A
That's
really
the
the
set
of
allowed
transactions,
the
set
of
queries
on
the
state
and
so
on
and
so
forth,
and
the
bit
I
skipped
over
because
we've
cut
out
a
number
of
these
slides.
These
TPS
can
be
written
in
a
language
of
your
choice
and
that's
the
same
message.
I
guess
you
would
get
from
fabric.
It's
like
you
choose
what
makes
sense
for
you
and
usually
SDK
to
actually
help
you
interact
and
the
interaction
is
super
simple.
A
If
I'm
a
TP,
it's
like
hey
hi,
it's
me
and
it's
the
validator
that
decides
whether
or
not
I'm
allowed
to
join
this
network
and
if
so,
fine
I'm
now
connected
and
then
and
then
again,
super
simple
API
when,
when
it's
the
turn
of
the
validator
to
pass
something
over
to
me
to
process
I'm,
now
the
CP,
it's
like
go
figure,
there's
no
notion
or
knowledge
of
the
payload
at
the
level
of
the
network
and
that's
really
important.
So
basically,
it's
here's
a
thing:
here's
a
blob
deal
with
it.
A
Everything
from
simple
comma-separated
values
to
you
know
Jason
to
really
it's
up
to
you
doesn't
matter
it's
an
address
in
a
tree
that
has
some
state
there
and
it's
only
the
teepee.
That
knows
what
that
state
really
really
means,
so
I
think
that's
kind
of
it
in
terms
of
the
overview.
The
high
level
I'd
now
like
to
hand
over
to
Kevin
to
really
talk
through
at
the
hard
core.
What
we're
doing
Kevin.
B
Okay,
so
I'll
ask
one
question
or
a
couple
questions
actually,
but
does
anybody
in
here
actually
do
Production,
Engineering
or
work
or
know
anybody?
Does
that
one?
Okay?
So
thank
you
for
being
here.
Congratulations
on
being
let
out
of
the
box.
Like
me,
the
does
anybody
else
do
DevOps.
Let's
say:
okay,
that's
a
little
better!
How
many
of
you
are
really
DevOps
and
you're?
Just
really
developed,
okay,
see,
there's
an
honest
man,
so
the
important
thing
is
actually
Production
Engineering
and
dealing
with
the
stuff
is
a
really
dismal
science.
B
And
if
you
work
in
it,
it's
actually
very
grim.
I
used
to
work
in
a
company
for
a
while.
We
me
and
my
colleague
at
the
time
used
to
call
her.
The
ruiners
of
Dreams
is
because
startup
companies
would
come
in
and
then
we
immediately
ripped
apart
everything
that's
going
wrong
with
it,
because
your
job
is
actually
to
figure
out
what's
going
wrong
and
what
could
possibly
go
wrong
and
remove
some
of
the
risk.
B
So
what
I'm
gonna
do
today
is
spend
a
little
time
talking
about
what
the
real
production
considerations
and
things
need
to
be
worked
out
and
done.
Some
of
which
we've
done
already
in
sextant,
some
of
which
are
general
concerns
and
need
to
be
open,
but
are
the
things
that
need
to
be
concerned
with
when
you're
working
with
these
blockchains
in
the
sort
of
gray
zone
between
public
and
private?
B
That's
the
real
heavy
spot
for
things
like
sawtooth
I
am
also
going
to
be
talking
about
salty
and
specific
obvious,
specifically,
obviously,
because
hey
that's,
why
we're
here
so
in
broad-
and
there
are
other
concerns
that
go
on
with
during
production
management
stuff
in
designing
systems
for
real
production.
But
these
are
the
the
big
four
actually,
the
last
one
is
is
particularly
blockchains,
but
you
minimize
the
family
remote.
B
The
third
one
is
often
missed
off,
which
is
that,
when
problems
happen,
the
resolutions
have
to
be
simple,
so
that
recovery
can
happen
quickly
and
so
that,
when
they're
done
in
a
crisis
situation,
they
need
to
be
very
clear,
and
very
few
mistakes
are
the
number
of
situations
where
complicated
systems
like
conventional
databases,
the
recovery
itself
actually
goes
wrong
and
destroys.
Data
is
really
quite
surprising.
It.
It's
also
destroys
dreams.
B
The
last
one
is
to
deal
with
varied
environments
and
what
we
mean
there
is
that,
in
the
target
situations
for
block
chains,
you
are
not
ideally
and
if
you're,
addressing
the
situations
that
block
chains
address
you're,
not
dealing
with
a
single
network.
You
are
gonna,
get
at
least
some
part
going
across
it
into
some
other
part
of
physical
networks
or
other
part
of
organization
management.
Some
are
part
of
control
and
you
have
to
deal
with
that
heterogeneity
in
the
network.
B
We
want
to
Duncan
mention
it.
One
of
the
reasons
we
like
sawtooth
is
actually
that
the
software
itself
is
homogeneous.
So
you,
when
you
deal
with
the
things
about
heterogeneity
in
the
network
itself,
you
can
just
deal
with
that.
Without
having
to
deal
with
okay,
what
parts
of
sawtooth
do
I
put
here?
What
parts
of
sawtooth
do
I
put
there
so
I
realize
quite
a
few
of
you
only
just
got
a
quick
overview
of
sawtooth,
but
these
are
kind
of
the
key
points
kind
of
suspected.
That
might
be
the
case.
First,
one
is
sawtooth.
B
Networks
are
images.
The
validators
themselves
are
not
pets,
they're
everything's
the
same
everything
is
expendable.
Ultimately,
in
the
network,
as
long
as
the
network
as
a
whole
is
staying
up.
That
actually
means
that,
if
you're
running
in
a
production
scenario,
you
should
never
be
doing
like
what
people
often
do
with
the
theorem,
which
is
run
up
a
single
node
that
that's
what's
operating.
B
You
should
actually
be
running
multiples,
because
it
is
your
responsibility
to
maintain
that
part
of
the
network,
and
you
don't
really
have
the
luxury
of
what
you
have
in
the
public
chains
of
there
being
thousands
of
other
nodes
out
there.
There
might
be
if
you're
lucky
enough
to
run
a
larger
sawtooth
Network,
but
chances
are
you
need
to
have
local
access
to
more
than
one.
B
The
other
thing
is
that
the
running
of
the
node
itself
is
often
taken
as
it's
all
up
and
running,
but
really
a
given
validator
you're
sitting
in
an
environment
where
it's
not
necessarily
the
case
that
validator,
for
whatever
reason,
networks,
problems
with
consensus
or
bad
actors
you're
not
necessarily
got
the
current
state
of
the
blockchain.
You
also
are
perhaps
behind
you:
may
not
your
cell
feet
processing
transactions,
so
you
need
more
than
just
the
processes
running
in
terms
of
section.
B
What
we
do
under
kubernetes
is
we
have
a
series
of
liveness
probes
that
actually
ensure
that
every
single
validator
is
independently
able
to
actually
submit
transactions
and
see
them
out
on
the
other
side,
so
everything's
punched,
in
which
flip
over
to
a
little
bit
of
that,
the
other
thing
is
an
implication
of
is
whatever
your
management
solution
needs
to
be.
On
top
of
the
Sawtooth
network
writ
large,
you
can't
assume
that
you
have
control
over
every
node
on
the
network,
direct
control,
the
network.
B
So
if
your
bank,
a
or
organization
a
you,
have
just
a
piece
of
it,
but
that
needs
to
be
simple,
and
it
also
needs
to
be
interacting
with
on
some
regards
some
communication
with
the
other
organizations.
So
our
one
of
our
principal
reasons
for
using
kubernetes
actually
is
to
address
both
treating
the
validators
as
pets,
running
the
liveness
probes
and
keeping
getting
a
better
understanding
of
the
health
of
the
nodes,
but
also
that
the
clusters
themselves
form
the
domains
of
control
in
terms
of
kubernetes,
but
also
that
chunk
of
the
Sawtooth
network
sort
of
hit.
B
This
again,
the
the
network
is
not
flat.
I
was
debating
whether
to
say
the
world
is
flat
inside
of
a
single
company
or
a
single
organization.
You
can
make
a
lot
of
assumptions
about
well.
The
network
is
going
to
look
this
way,
everything's
going
to
be
even
on
the
Internet.
You
can
also
make
that
the
assumption
that
everything
is
going
to
be
flat
and
everybody
I
can
publish
everything.
B
On
the
same
point
of
view,
the
names
are
fine,
but
when
you're
in
this
middle
grounds,
which
is
where
the
permission
blockchains
really
work
heavily
and
actually
do
their
best
work,
you're
not
gonna,
get
that
situation.
You're
gonna
have
a
mix
of
topologies.
You're
gonna
have
multiple
different
DNS
servers
as
soon
as
you
start
using
something
like
kubernetes.
You
already
have
more
than
one
DNS
service
working,
both
the
public
one
and
the
internal
dieppe
kubernetes
one.
But
you
have
jumps
between
nets.
B
You
don't
necessarily
have
complete
Universal
connectivity
where
every
node
is
going
to
be
able
to
talk
to
every
node.
That's
not
necessarily
the
case
at
any
point
in
time
you
have
problems
with
transient
network
problems
because
you
could
be
spanning
global.
So
you
need
to
be
aware
of
that
in
particular
on
sawtooth.
B
There
is
a
point
where
the
nodes
have
to
advertise
out
what
how
you
contact
with
something
that
and
particularly
NAT
and
NAT,
addresses
in
DNS
action
cars
product,
because
you
do
have
to
contact
the
validator
node
and
configure
it
the
validator
node,
with
the
same
name
that
the
validator
node
is
advertising.
So
you
can't
use
your
own
fake
thing
to
refer
to
it.
So
no
aliasing,
and
that
has
to
do-
is
the
zero
of
queue
actually.
B
This
is
sort
of
the
next
major
thing
which
I
think
sort
of
gets
looked
over
in
block
chains,
mostly
because
everything's
new,
but,
on
the
other
hand,
block
chains,
software
sawtooth
in
particular,
but
darkness
goes
for
all
of
them,
they're,
not
software.
That's
to
last.
For
a
year,
most
of
the
applications
are
intended
to
last
for
extensive
periods
of
time,
which
ultimately
implies.
If
you
did
it
on
a
non
light
sink
of
the
etherium
chain.
That's
a
60
gigabyte
file
that
you
need
to
sync
up
right.
B
If
you
do
the
actual
light
version,
it's
between
6
and
11
depending
I.
Do
it
it's
a
significant
amount
of
data,
so
you
in
practical
terms,
if
you're
running
some
sort
of
non-stop
business
against
these
things,
the
actual
shipment
of
that
amount
of
data
and
trying
to
sync
off
the
overall
network
is
not
a
good
thing
to
deal
with,
because
that's
actually
your
time
of
recovery,
it's
getting
it
affected
so
in
the
ultimate
implication
is
that
is
that
backups
need
to
actually
occur.
B
So
you
can
snap
and
return
to
at
least
at
some
point
in
the
past,
if
only
just
for
recovery
time,
not
necessarily
for
auditing
purposes
and
the
usual
reasons
for
backups.
So
for
us
that
means.
Actually
we
take
a
cloud
first
approach
to
things
like
that,
just
because
we
can
put
it
into
the
backup
policies
in
places
like
AWS
and
actually
just
have
it
snapped
in
and
if
everything
goes
crazy,
we
can
actually
snap
it
up.
B
It's
not
quite
the
same
requirement
in
terms
of
validators,
as
you
would
have
with
a
Oracle
database
and
things
like
that.
It's
actually
just
about
quick
recovery
time
and
trying
to
avoid
that
clean
sink
of
the
data.
If
the
blockchain
is
large,
it's
not
the
giant
backup
and
the
only
way
you
do
it
on
a
database.
There
are
other
mechanisms
and
you
don't
have
quite
the
same
tolerance
of
needing
to
have
up-to-the-second
backups
and
things
like
that
or
point-in-time
recoveries,
because
you
do
have
the
blockchain.
It's
also
important.
Actually
to
think
about.
B
That
is
that,
while
the
block
chains
themselves
are
in
part,
grandiose
transaction
logs
and
therefore
have
a
history
of
everything
because
of
a
couple
things
state
pruning,
you
still
need
to
actually
do
the
snapshot
snapshot
backups.
You
still
need
to
do
everything
like
that,
because
just
having
the
history
of
a
transaction,
it
doesn't
actually
mean
that
you
need
to
know
what
the
things
look
like
at
a
certain
point
in
time.
You
need
to
be
able
to
look
at
what
it's
like
for
various
reasons.
B
What
it'll
look
like
now
not
without
regard
to
what
happened
after
data
retention
is
a
long
time
thing
both
for
there's
in
Sawtooth
1.1,
there's
the
state
pruning
that
happens,
which
is
a
good
feature
to
limit
the
size
of
the
ultimate
large
scale,
to
limit
the
size
of
the
blockchain
data
itself.
It
is
one
part
of
the
solution.
It's
a
good
one,
and
basically
that
just
means
when
there
are
no
longer
any
references,
you
can
set
a
horizon
and
then
eventually
the
data
can
just
be
pruned
out.
B
B
But
sort
of
widening
that
particular
discussion
out
of
while
there
are
a
bunch
of
things
which
there
are
not
necessarily
clear
or
even
publicly
clear
solutions
to
the
major
one.
That's
on
our
mind,
all
the
time
is
how
to
do
deal
with
major
version
upgrades
so
right
now
we're
in
sawtooth
one
and
just
going
by
semantic
versioning.
The
assumption
is
actually
will
be
reasonably
compatible
with
everything
under
the
one
dot.
B
But
if
there
is
ever
a
sawtooth
to
dot,
we
might
have
some
significant
format,
changes
and
things
we
and
we
don't
want
to
stop
it,
and
it's
not
quite
the
same
situation
in
the
non
pure
public
blockchain
world.
We
can
afford
to
actually
have
a
hard
fork
and
split
between
etherium
in
etherion,
classic
we've
actually
got
to
maintain
the
level
of
service.
So
what
do
we
do
about
that?
And
we
also
have
something
we
can't
do
in
the
public
setting.
B
We
can
actually
find
techniques
to
actually
do
a
governed
upgrade
by
all
the
participants
in
the
network.
Potentially
it's
going
to
depend
on
use
case,
but
really
from
the
technical
standpoint.
We've
got
to
work
out.
What's
going
on
whether
that's
simultaneous
networks
and
mirroring
things
like
that,
that
actually
needs
to
be
worked
out,
we're
sort
of
actively
working
on
that
and
trying
to
come
up
with
the
realistic
scenarios
and
what
will
work
so
the
pruning
is
time-based
and
reference
based.
B
There
are
other
reasons
coming
up
for
the
use
cases
inside
of
the
permission,
semi
pot,
semi,
private
and
public
blockchains,
which
you
need
to
be
able
to
prune
data
for
reasons
that
have
nothing
to
do
with
time.
There's
not
really
any
great
techniques
about
that
other
than
refreshing,
the
entire
blockchain
and
stripping
the
data
out
and
kicking
it,
which
is
the
same
as
actually
the
upgrade
techniques.
So
the
big
ones,
obviously,
on
everyone's
mind,
GDP
are
more
important
to
me-
is
actually
the
general
right
to
be
forgotten
with
GDP
ours.
B
So
one
justice
is
largely
time-based
in
a
lot
of
scenarios,
but
right
to
be
forgotten
as
it
doesn't
matter.
So
how
do
you
prune
that
all
the
way,
through
particularly
the
permission
block
chains,
tend
to
take
care
of
information
which
is
much
more
likely
to
be
in
and
covered
by
GDP?
Our
information,
in
terms
of
it's
much
more
sensitive
information
that
wouldn't
be
public
they're,
not
public
records,
I,
have
more
stringent
edata
privacy
requirements
actually
and
after
seeing
dance,
it's
actually
not
the
right
terminology
and
I
thought
it's
actually
confidential
is
more.
B
B
So
there's
some
projects,
like
the
private
data
objects
that
are
going
on
there,
there's
also
the
homomorphic
encryption
of
the
zero
knowledge
cruise,
where
you
can
actually
maintain
it
and
judge
correctness
of
the
transaction
without
actually
knowing
the
content
of
the
transaction
is
the
practical
aspect
of
it.
Those
are
coming
through.
There's
good
developments
coming
in
the
in
the
future.
B
We
can
point
you
to
people
to
talk
about
that
here.
Actually,
the
last
is
key
management,
unlike
fabric
sawtooth,
doesn't
really
have
built
into
it.
A
key
management
system
actually
I
like
that
part
of
it,
because
it
means
we
can
adapt
it
to
whatever
we
need
to
do
inside
of
an
enterprise.
Inside
of
anything,
it's
just
public
private,
key
pairs
that
are
going
on
where
they're
certified.
Where
they're
not.
However,
that
means
there's
a
giant
hole
which
is
actually
how
do
you
securely
distribute
keys
that
are
going
around?
How
do
you
keep
them
safe?
B
The
there
are
a
couple
reasonable
systems
out
there
for
doing
key
management
talking
with
somebody
earlier
earlier
this
week
about
doing
which
I
don't
remember,
who
it
is
over
here,
remind
me
who
you
are
about,
having
a
certificate
authority,
support,
sort
of
be
able
to
do
certificate
authority
inside
of
Sawtooth,
but
without
making
it
an
integral
part
of
it
like
it
is
in
fabric
fabric.
You
need
to
have
it
and
then
be
able
to
trust
keys
issue
from
an
authority,
and
then
that's
fine
and
be
able
to
expend
that
out
the
order
we
got
here.
B
So
in
order
to
look
at
what's
going
on
in
terms
of
how
we
do
it,
I'm
gonna
actually
switch
to
just
sorry
I'm,
not
a
Mac
guy,
so
hey
there
we
go.
This
is
Sexton.
The
thing
I
just
want
to
show
is
the
extent
to
which
done
it.
If
you've
ever
worked
with
trying
to
fire
pretty
much
any
of
the
blockchain
projects
in
kubernetes
or
wherever
it's
a
very
complicated
and
involved
process
in
terms
of
crafting
it
and
seeing
where
things
are
and
I'm
putting
it
out.
B
What
we've
done
here
has
really
just
put
a
front
end
on
oops
on
deploying
a
salty
stuff.
We
have
our
own
code
templates
in
the
background
that,
based
on
the
parameters,
it'll
it'll
spit
it
through
configure
it
as
you
want
and
then
deploy
it
straight
out
into
the
kubernetes
Network
very
quickly.
Thank
you,
shots
the
and
then
links
off
to
the
the
obvious
at
the
moment
obvious.
This
is
the
obvious
management
tools
here.
Kubernetes
dashboard
will
be
extending
stuff
out
more
trying
always
to
keep
rather
than
brand
new
tools.
B
B
The
next
one
is
the
one
that
we
use
inside
of
sawtooth
and
a
couple
of
the
other
projects.
Actually
I'll
explain
something
what's
going
on
here.
This
is
the
graph
on
a
dashboard.
This
is
Salty's
105,
that's
running
here,
but
you
notice.
Actually,
this
I
will
only
fire
this
up.
Just
before
the
presentation.
Sorry,
you
notice
there's
already
blocks
going
through.
That's
actually
our
monitoring
that's
going
on
in
the
background.
So
as
soon
as
you
fire
up
in
in
Sexton,
you
fire
up
a
the
Sawtooth
network.
B
B
So
these
are
fairly
standard,
we're
going
to
be
enhancing
those
to
make
them
elaborate.
We're
also
going
to
be
adding
sawtooth
1.1
as
soon
as
it
goes
through
our
build
verification,
but
that's
the
running
thing:
the
finished
product:
let's
go
over
to
just
what's
involved.
In
doing
this,
we
create
a
actually
we'll
do
the
first
step.
This
is
less
exciting.
B
B
Few
nodes,
not
a
huge
network
and
providing
provide
a
public
key
pair,
but
just
for
convenience.
We
do
this,
we
don't
actually
need
it
because
you
never
actually
need
to
log
into
the
kubernetes
cluster,
and
so
that's
firing
off
and
building
out
a
kubernetes
cluster
on
amazon,
we're
doing
our
usual
cooking
technique,
which
is
going
in
to
a
cake
I've
already
created.
B
This
is
the
more
important
thing
for
us,
which
is
the
beginning
of
the
Sawtooth
configuration
trying
to
limit
it
down
a
very
confusing
set
of
options
and
the
wildering
set
of
options
and
tends
to
be
developer.
Oriented
documentation,
try
to
boil
it
down
to
what
are
actually
the
things
that
need
to
be
discussed
and
decided
when
you're
applying
it.
B
So
the
first
and
most
obvious
one
to
me
is
actually
what
the
name
it
that's
actually
not
so
important
to
the
Sawtooth
network,
but
it's
important
for
general
management
and
then
genesis
whether
or
not
this
is
actually
going
to
be
a
new
network
that
we're
just
starting
from
scratch
or
connecting
to
an
existing
one
so
corresponding
to
that.
If
you
disable
the
genesis,
you
have
to
do
the
external
seeds,
meaning
endpoints
outside
of
the
network,
and
that
goes
back
to
what
I
was
saying
about
the
NAT
and
knowing
where
things
are
dynamic
and
Static
peering.
B
You
can
talk
about
if
you
want
right
now,
we
was
one
down,
oh
five,
so
we
might
just
for
poet
or
the
dev
mode,
and
the
next
1.1
will
be
supporting.
The
other
are
some
of
the
other
consensus
protocols
when
they're
pass
our
build
certification,
the
duty
to
do,
and
then
a
series
of
the
some
of
those
stocky
and
build
stuff.
B
Interestingly,
actually,
we
actually
always
deploy
out
more
than
in
terms
more
than
what's
prompted
here
for
in
terms
of
the
transaction
processors,
because
there's
some
that
we
believe
that
are
universally
useful
one
is
the
Inc
a
because
we
use
it
for
monitoring
at
the
moment.
Probably
more
interesting
is
the
sets
transaction
processor,
which
is
the
sawtooth
aetherium
and
the
our
pcs
that
go
along
with
that.
B
And
I
will
just
fire
this
out
for
a
second,
and
just
so,
you
can
see
it
and
I'll.
Do
the
cooking
thing
again
give
it
a
second
to
refresh,
because
that's
not
the
one
yeah,
and
so
as
it
comes
through
it'll
start
firing,
things
out,
I
think
I
wasn't
really
paying
attention
to
what
I
did
I
do
a
Genesis
there
that's
going
I
did
so
I'm
gonna
switch
over
to
the
finish
one
yeah,
which
is
that
one
right
just
to
talk
a
little
bit
about
and
go
back
to
the
sort
of
production
thing.
B
One
of
the
bigger
things
to
discuss
is
what
happens
with
these.
The
services,
which
is
a
network
endpoints
and
which
ones
are
actually
published
out
to
the
world
which
ones
are
not
most.
Interestingly,
is
probably
the
rest
api
load
balancer
in
the
node
port.
Do
it
both
ways?
That's
actually
every
the
load.
Balancer
is
in
front
of
all
the
on
this
giving
cluster
in
front
of
all
the
rest
api.
So
you
can
bounce
between
it,
which
can
be
convenient
if
you
were
doing
a
relatively
naive
application.
B
However,
there
are
eventual
consistency
problems
because
you
can
bounce
from
validator
validator
out.
It's
not
necessarily
the
case
that
every
validator
sees
the
same
picture
of
the
world.
At
the
same
time,
it's
not
a
synchronous
system,
but
you
need
the
node
port
for
a
different
reason,
because,
even
though
port
needs
to
have
access
to
one,
you
want
to
pick
out
the
opposite
situation
and
do
pick
out
one
validator
and
always
have
at
least
the
consistent
view.
B
That's
gonna
work
out
better
tends
to
be
used
very
heavily
in
financial
services
and
then
finally,
actually
the
more
important
stuff
with
note
port
is
actually
you
need
to
have
the
nope
or
you
need
to
be
able
to
expose
it
because
you
might
be
connecting
to
a
network.
That's
not
under
your
control
and
you
need
to
have
advertisements
of
the
endpoint
and
have
it
be
able
to
connect
it.
B
The
other
two
are
kevanna
has
just
done
up
for
a
load
balancer
for
convenience.
Since
that
isn't
actually
more
than
one
note.
The
other
thing
is
probably
to
note,
even
though
they're
not
pets,
and
usually
when
you
say
things
are
pets
that
means
they're,
stateless
validators
are
not
completely
stateless.
The
state
is
very
recoverable,
but
everything's
in
a
persistent
volume.
A
Well,
sweet
well,
I
think
we're
pretty
much
out
of
time,
so
we
do
have
a
booth
here.
So
if
people
want
to
come
ask
questions,
we've
also
got
a
demo.
Well,
we're
just
gonna
literally
go
through
this
and
play
tic-tac-toe
and
see
if
we
can
beat
the
system
aka
the
blockchain,
which
I
think
there's
a
five.
Sorry,
five,
fifteen
twenty.
If
it's
five
twenty,
then
nobody
will
be
here
so
and
again,
apologies
I!
Think
we've
run
out
of
time.
A
So
you
know
by
all
means,
come
and
ask
us
questions
afterwards,
hope
it
was
useful
and
there
is-
or
there
will
be,
a
a
the
deck
published
as
attached
to
the
schedule,
and
that
will
give
you
a
bunch
of
where
are
we?
Where
are
we
have
been
where
we
are
to
my
tomorrow?
Mister,
okay,
don't
worry
that
was,
will
have
a
set
of
links
to
resources
that
you
may
find
useful,
not
just
to
do
what
we're
doing
but
sort
is
in
general.
Thank
you
very
much.