►
Description
Hedge your Bets: Pluggable Blockchains for Business Continuity - Jon Geater, Jitsuin
Hyperledger is the home of Enterprise DLT, and that means Hyperledger Frameworks need to play well in Enterprise software products and environments. As with any technology component the DLT is just a part of the solution and no more or less important than any other, and the technical components must bend to meet the commercial operators, not the other way around.
During the course of developing Jitsuin Archivist for secure asset lifecycle management the developers discovered that different use cases demand different levels of scalability, flexibility, performance and more from the DLT underlay. The development also brought the true maturity and capabilities of various DLTs to light, presenting significant challenges to development. For all these reasons, and to go to production confidently they needed more than pluggable consensus: they needed pluggable blockchains.
This detailed technical talk will describe experiences of engaging in the HL contributor ecosystem, the commercial imperative to stay flexible with respect to DLTs, and the techniques required to go to production. It will begin with a description of the use case (both business and technical), tell the stories of the main technical findings and comparisons between various frameworks (pure technical, operational, non-functional) and go into detail on the technical implications of each.
It will then move on to outline the architecture of production SaaS system based on blockchain which is able to accommodate andovercome those limitation by easily switching out one DLT for another depending on need.
Finally, a demo will show how the pluggable DLTs appear invisible to the user, and simple to the developer.
----
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
Right
grant,
oh
thanks.
Everybody
for
coming
I
realize
I'm.
The
last
thing
between
you
and
Bryan,
so
I
will
absolutely
try
to
keep
this.
Keep
this
on
time,
noting
that
this
is
the
technical
track.
I,
never
know
how
deeply
technical
to
make
things.
So,
obviously
the
slides
are
not
so,
but
you
stopped
me
and
by
one
as
I
say,
if
you
want
ask
questions,
do
that
and
we
can
we
can
dig
into
whatever
you
actually
want
to
dig
into
and
yeah?
That's
that's!
That's
about
it!
So
kind
of
engineering
heavy!
A
The
last
one
was
more
sort
of
math
consensus.
Heavy.
This
is
born
an
engineering
talk,
but
again
it's
about
the
thing
we've
actually
built.
So
any
detail
you
want
I'd,
probably
know
it
and
we
can
that
we
can
go
down
that
go
down
that
track.
So
why
pluggable
block
chains,
those
of
you
who've,
been
around
hyper
ledger
for
a
while
will
know
that
pluggable
consensus
is
a
big
deal.
It's
a
thing
you
try
to
achieve
and
the
reason
why
you
might
want
to
have
pluggable
consensus
algorithms,
because
different
different
consensus
is
good
for
different
things.
A
I
argue
in
some
cases
for
some
reasons
you
might
have
to
actually
plug
your
entire
framework
if
you're
actually
going
to
be
able
to
build
a
business
right
now
in
this
day
and
age.
Why
is
that?
Well,
yeah
blockchain
concepts,
technology
software,
whatever
does
not
necessarily
play
well
with
others.
Hyper
ledger
is
the
home
of
enterprise
blockchain.
So
it
says
I've
as
the
website
changes
every
now
and
again,
but
fundamentally
it's.
A
8
percent
of
them
are
succeeded
and
that's
pretty
good
startup
rate
for
a
technology
for
business
or
for
a
market
right.
So
if
eight
percent
are
winning
that's
a
great
thing,
but
how
do
we
into
scale
from
there
you've
got
to
make
it
fit
things
that
people
understand
better?
You
know
things
like
the
whole
distributed
decentralized
nature.
Eventual
consistency
is
a
big
deal.
We
we
all
kind
of
know
about
eventual
consistency.
We
know
that
we
can
pick
a
consensus
mechanism
that
is
sort
of
better
or
worse,
at
reaching
finality,
faster
or
or
slower
or
whatever.
A
We
can
build
protocols,
and
we
can
deal
with
the
idea
that
a
transaction
might
be
confirmed
one
minute
and
rollback
the
next,
but
businesses
cannot
deal
with
that
kind
of
thing.
It
doesn't
make
sense.
You
can't
run
your
life,
you
can't
pay
employee
salaries
on
that
kind
of
slightly
quantum
uncertainty,
a
CISO
actually
so
advantageous.
So
great
that
bring
us
a
whole
man
of
opportunity
in
blockchain
type
systems
are
anathema
to
the
way
that
most
software
and
processes
work
in
in
industry.
A
That's
a
really
difficult
thing
for
people
to
get
their
heads
around
just
about
after
35
years
of
dealing
with
this
stuff
and
P
care,
and
so
on.
We
often
see
large
enterprises
having
a
key
management
department,
or
at
least
key
management
specialists
who
work
for
the
IT
department
or
risk
or
the
PKI
guy,
whoever
it
might
be.
A
A
It
worries
if
it
doesn't
fit
the
mold
of
their
processes
and
so
on,
and
so
it's
difficult
to
to
get
through
and
then,
of
course,
is
all
of
the
sort
of
this
idea
of
governance,
something
that
I
think
is
really
important,
and
a
little
bit
neglected
in
in
decentralized
technologies
and
frameworks,
and
things
in
general
is
that
we
kind
of
had
that
hype
cycle
with
the
law.
Two
or
three
years
of
saying
blockchain
is
magic
and
it
brings
trust
automatically
and
everything's
kind
of
perfect.
A
They're
used
to
working
in
a
world
where
they
can
just
kick
them
out
or
they
can
rip
up
the
contract
or
they
can
do
something
else,
because
it
doesn't
work
if
you've
brought
into
a
consortium
or
decentralized
application.
You've
got
to
play
by
the
rules
of
a
group
of
other
people
and
all
of
these
things
we
use
a
lot
of
the
same
words
where
they
mean
different
things
and
this
confusion,
and
this
sort
of
mismatch
also
applies
internally
so
again,
yeah.
This
is
supposed
to
be.
A
A
I
can't
have
somebody
who
invented
their
own
language
being
the
cornerstone
of
my
business,
because
my
shareholder
wouldn't
think
that's
very
smart,
so
you've
got
a
whole
load
of
considerations
to
make,
on
the
code
sight
whole
load
of
considerations
to
make
on
the
the
jargon
side
and,
of
course,
when
you're
building
stuff,
that's
so
brand-new,
so
unfamiliar
so
uncharted.
You
also
need
a
really
good
community
of
people
to
to
work
with
them
today,
with
the
basic
way
that
most
people
solve
their
problems
today
or
is
the
first
thing
they
try?
A
Is
they
google
and
they
click
on
the
first
thing
that
has
Stack
Exchange
in
the
URL?
That's
how
you
solve
problems
today.
If
you
pick
something
that's
too
obscure,
you
won't
have
that
get
out
and
you'll
suddenly
find
that
a
sort
of
half
day
bug
cost
you
six
months
and
if
you're
costing
six
months
searching
through
for
some
kind
of
issue
that
you've
got
in
an
underlying
piece
of
utility
code.
Again,
that's
something
that
may
forgot
to
make
your
shareholders
quite
mad
at
you
for
picking
that
kind
of
thing.
A
So
we've
got
a
whole
load
of
business
customer
market
issues
which
are
somewhat
technical
in
nature,
because
the
reason
they
come
up
is
because
of
the
nature
of
the
technology,
and
we've
also
got
internal
operational
problems
which
are
very
technical
in
nature,
which
is
how
do
we
actually
have
enough
people
to
build
enough
stuff
to
sufficient
quality
that
it
will
actually
sell?
This
isn't
about
pocs.
This
isn't
about
science
experiments,
it's
not
about
having
a
cool
thing
in
the
lab.
That
draws
a
graph
at
the
end,
to
tell
you
how
good
something
is.
A
A
You've
got
lots
of
people
who
have
lots
of
legitimate
interest
in
this
thing,
it's
physical,
so
it
has
to
exist
in
exactly
one
place
and
by
and
large
they
tend
to
have
more
serious
consequences
if
they
go
wrong,
if
you
have
a
blast
furnace
or
if
you
have
a
centrifuge
or
anything
like
that
or
a
train,
if
somebody
does
the
wrong
thing
at
the
right
moment,
the
wrong
moment,
you
can
actually
end
up
on
Capitol
Hill.
You
can
end
up
with
a
big
lawsuit.
A
Right
now,
until
the
properly
competent
person
is
signed,
it
often
said
that
that's
a
good
idea,
and
even
when
you
sign
it
off
and
said,
it's
a
good
idea,
I'm
not
going
to
upgrade
my
baggage
carrousel
right
now,
because
it's
running
and
there's
a
guy
inside
it
who's
dealing
with
you
know,
oiling
the
chains
and
stuff
and
if
I
stop
it
or
restart
it,
while
he's
inside
I'm
gonna
be
in
trouble.
So
all
this
kind
of
stuff
is
a
collaboration
problem.
It's
an
information
sharing
problem.
A
It's
essentially
a
supply
chain
of
continuous
maintenance
information
and
that's
what
blockchains
it
good
for.
So
this
is
what
we
do
allow
people
to
you
know,
share
all
this
stuff
and
cover
their
risk.
So
the
other
side
once
you've
sort
of
got
the
information
in
you.
You
need
to
have
a
reason
for
everybody
to
play
and
the
reason
why
they
play
better
with
a
decentralized
system
than
with
a
this
simple.
You
know
centralized
database
or
a
SAS
or
whatever
else
is
that
nobody
knows
in
advance.
A
A
Just
as
much
as
the
owner
of
the
asset
wants
to
make
sure
that
it's
looked
after
properly
and
doesn't
break
down
the
people,
doing
the
maintenance
need
to
cover
their
risk
and
make
sure
that
if
it
does
go
wrong,
they're
not
left
holding
the
can
or
paying
our
it's
their
insurance
that
gets
gets
hammered
to
do
it.
So
everybody
gets
to
play
this
kind
of
mutually
distrustful,
mutually
trustful
game,
and
hopefully,
if
everybody
does
the
right
thing,
nothing
goes
wrong.
A
Everybody's
happy,
but
if
it
does,
you've
saved
an
awful
lot
of
money
and
time
in
finding
out
what
went
wrong
root,
causing
it
fixing
it
and
making
sure
it
doesn't
happen
again
and
that's
the
essence
of
distributed
ledges
and
blockchain
there.
I've
got
more
things
because
I
know
the
slides
are
going
to
be
published,
but
I
think
you
all
you
all
kind
of
get
that
right.
A
This
is
a
collaborative
system,
we're
people
who
currently
have
a
really
hard
time
sharing
information,
making
sure
that
information
is
complete
and
making
sure
that
information
is
trustworthy,
can
now
suddenly
come
together
and
ask
really
simple
questions
like
what
the
hell
happened
in
Idaho.
You
can
see
that
bill
updated
the
PLC's
yesterday.
You
can
then
ask
why
the?
Why
did
he
think
that
was
a
good
idea?
A
And
and
now
you
know
what
to
what
to
do,
rather
than
ending
up
in
court
and
arguing
about
the
meaning
of
true
time
or
aligning
two
different
siloed
proprietary
log
records
or
whatever
it
whatever
it
might
be.
So
that's
our
use
case
and
I
wanted
to
highlight
that,
mainly
because
we
are
not
a
blockchain
company.
This
is,
we
are
absolutely
fundamentally
a
cybersecurity
GRC
company.
We
just
happen
to
think
that
a
decentralized
application
and
a
collaborative
platform
is
the
best
way
to
achieve
them.
A
So
decisions.
What
do
we
want
to
do
with
with
our
or
DLT?
Where
are
we
going
to
go?
Gonna
get
one
from
so
I.
Always
like
this.
It's
a
simple,
it's
a
simple
thing
but
yeah.
When
people
ask
what's
the
best,
one
was
the
best
block
change
that
we
do
Corder
or
hyper
ledger
even
to
lump
hi
pledge
of
just
simple
thing.
A
The
answer
to
what's
the
best
vehicle
is:
where
are
you
going?
You
know
the
ninja
looking
thing
in
the
middle
is,
you
know,
probably
best
for
a
commute
if
you're
single,
but
it's
not
great,
if
you're
taking
the
kids
to
the
soccer
practice
or
having
a
midlife
crisis
on
the
end
there
so
yeah,
which
one
we
choose,
which
is
better,
so
we
actually
did
I
first
this
out,
partly
because
the
informations
kind
of
old
and
partly
because
we
don't
want
to
offend
people
with
the
pink
squares
on
sort
of
in
eternity
on
the
camera.
A
But
I
am
happy
to
sort
of
discuss
these
things
with
folks.
Afterwards,
if
you
genuinely
want
to
know
back
in
something
like
February
of
last
year,
so
about
a
year
ago,
when
we
started
this,
this
development,
we
went
and
did
a
fairly
good,
in-depth
assessment
check
of
the
various
options
available
to
us
and
did
some
pros
and
cons
based
on
a
few
key
principles
that
we
had
so
thinking
back
to
those
internal
technical
pressures
of
you
know,
can
I
hire.
People
who
can
write
this
code
can
I
have
a
hope
of
convincing
my
customers.
A
So
this
is
going
to
be
something
that's
familiar
enough,
that
they
could
at
least
hire
a
consultant
to
analyze
my
smart
contracts
and
things
like
that,
and
we
we
decided
at
some
point
to
standardize
on
solidity,
or
at
least
EVM
I
really
have
this
kind
of
shortcut
to
some
of
these
things.
I
really
like
sawtooth
I,
like
the
design
of
sawtooth
I,
think
it's
very
clean
because
of
our
use
case
for
sort
of
mutual
distrust,
but
also
having
this
kind
of
quick
collaborative
platform.
It's
really
important
to
make
sure
that
all
nodes
are
equal.
A
So
you
have
a
completely
fair
plain
peer
network
and
I.
Didn't
want
to
mess
around
with
fabric
cares
a
lot
of
really
lovely
features.
If
you
need
that
level
of
power
and
delegation
representation
and
differentiation
so
on,
but
I
didn't
want
those
to
mess
up
my
model
because
I
don't
really
need
them,
you
know
even
things
like
channels.
A
We
don't
need
channels
because
we
made
a
policy
of
doing
confidentiality
and
there
are
noise
in
kind
of
stuff
at
the
data
level,
so
in
working
out
those
those
relationships
in
the
data
elements
themselves,
partly
because
we
deal
with
data,
that's
bloody,
huge
and
it
doesn't
go
on
the
chain,
so
you
had
to
do
that
off
chain
anyway,
we
might
as
well
keep
that
go
to
lots
of
reasons
why
we
made
these
choices
and
went
down.
So
we've
got
things
like
EVM
compatibility
is
on
there
cuz.
A
We
decided
to
do
that
because
solidity
is
accessible
because
you've
got
a
whole
ton
of
open-source
tooling
that
works
and
because
there's
a
small
but
viable
industry
of
people
out
there
who
could
actually
write
code
for
you
or
write
code
for
our
customers
to
work.
So
we
went
and
did
a
bunch
of
things
and-
and
we
made
our
choice
Center
and
our
choice
was
at
the
time
sorting.
A
A
I,
don't
I've,
never
actually
read
the
book,
it's
one
of
those
things
where
you
just
pick
up,
quotes
and
put
them
on
PowerPoint
slides,
but
it's
full
of
quotes
that
are
very
quotable,
and
one
of
them
is
this
I
just
thought
it's
funny,
so
I've
put
it
out,
but
actually
the
experience
has
been
great,
but
We
certainly
have
learned
a
lot.
Actually
the
thing,
that's
most
interesting
that
everybody
knows
if
this
quote
has
shown
up
in
thousands
of
PowerPoint,
slides
and
I
suspect,
didn't
even
credit.
A
Howard
Marks
is
that
being
too
far
ahead
of
your
time
is
indistinguishable
from
being
wrong,
and
so
so
what
started
to
happen
was
that
there's
always
a
worry
that
you're
too
far
ahead
of
your
time
in
using
decentralized
applications,
blockchain
whatever
at
all
yeah?
This
is
a
young
industry.
It's
kind
of
new
I
think
everybody
in
this
room.
Hopefully
a
lot
of
people
on
the
far
side
of
that
camera.
To
really
believe
that
the
end
game
is
the
true
end
game.
We
know
that
we're
going
heading
for
a
data-driven
economy.
A
Even
so,
you
know
it's
early
in
that
journey.
Who
knows?
Well,
it
turned
out
that
our
timing
in
developing
the
product
was
also
slightly
exciting
because
between
starting
the
development
and
now
we're
last
week,
I
was
in
San
Francisco,
actually
launching
the
GA
of
the
products
that
we're
partnered
with
Microsoft
will
partner
with
ping
identity.
We've
got
the
thing
live,
you
can
just
buy
it
with
one
click.
A
If
you
want
to
pay
our
standard
terms,
so
we
kind
of
we
had
to
get
to
that
point
of
going
live
and
between
the
start
and
the
live
date.
We
had
a
bunch
of
disturbance
in
Piper
ledger
as
a
whole.
I
owe
all
of
the
etherium
Alliance
type
stuff
like
Bessie
came
in
in
between
that
time
would
have
changed
the
mathematics
changes.
The
dynamics
has
other
other
opportunities
and
things
that
maybe
if
it
had
been
there
before,
we
would
have
started
there.
Maybe
not
you
know.
A
A
sawtooth
also
has
been
through
a
period
of
stability,
which
is
good
going
up
to
one
point
two,
but
it
also
had
a
period
of
disturbance
because
of
upgrading
all
the
stuff
from
Python
to
rust,
and
you
know
finding
a
bunch
of
bugs
in
there
that
will
never
be
fixed
because
they
were
in
the
Python
version,
but
waiting
for
rust
to
be
fixed
and
ported
across.
Also
it
takes
too
long
and
of
course
again,
you
know
dude
good
developments,
but
just
a
little
bit
slow
for
our
use
cases.
A
Things
like
the
questions
over
which
are
the
more
popular
or
supported
consensus
mechanisms,
because
we
went
from
you
know,
having
everything
in
poet
and
then
poet
kind
of
almost
got
upgraded,
but
not
really,
and
then
we've
got
pbft
and
pbft
was
kind
of
working,
but
then
was
incompatible
with
one
one:
five,
which
was
a
problem
because
we
couldn't
wait
for
1.2
and
then
SB
ft
showed
up
as
an
option,
and
that
might
be
great
at
some
point.
But
it's
not
quite
in
there.
A
So
yeah
I
was
super
confident
that
at
some
point
this
will
all
be
good.
And
you
know
there
are
folks,
like
blockchain
technology
partners
in
the
audience
here
who
have
gone
through
that
mill
and
and
actually
made
the
thing
stable
and
working
so
I'm,
quite
confident
that
yeah
we
will.
We
will
get
to
a
point
where
it's
good,
but
for
money
timelines
in.
Why
use
it
just
wasn't
ready.
A
A
So
what
I've
called
Network
abstraction
here
is
kind
of
the
punchline
of
this
whole
thing,
but
also
to
make
the
application
and
the
user
experience
the
product
itself
isolated
from
any
of
this
disturbance
or
changes
in
in
the
blockchain
network.
So
an
awful
lot
of
what
we've
got
here
actually
isn't
blockchain
II
at
all,
because
it
turns
out
that's
what
people
will
will
buy.
So
the
first
thing
that
we
that
we
did
was
that
we
decided
to
make
the
primary
interface
to
identity,
be
not
our
problem,
so
we've
got
a
whole
bunch
of
stuff.
A
A
And
so
what
we
have
to
realize
is
that
enterprise
ID
is
a
very,
very
serious
business.
The
reason
why
people
take
it
so
seriously
and
have
lots
of
forms
to
give
somebody
a
two-factor
token
or
you
have
really
zero
harsh
HR
related
things
for
off-boarding
somebody
when
they
leave
or
when
they
do
something
bad.
It's
because
giving
so
many
access
to
an
enterprise's
to
an
enterprise
identity
essentially
allows
them
to
act
as
that
business.
A
A
A
So
the
next
thing
that
we
did
was
to
have
a
sort
of
it's
a
lot
more
complicated
than
this.
We've
got
some
kind
of
cool
cool
tweaks
in
here,
but
was
to
make
sure
the
first
thing
that
applications
and
so
on
deal
with
is
actually
a
ordinary-looking
web
web
access
layer,
and
this
allows
all
of
the
usual
stuff
like
familiar
programming.
But
most
of
all,
if
you
see
we've
got
things
like
the
the
handheld
device
that
maintenance
guys
walk
around
with,
if
you're
doing
things
like
field
inspections.
Quite
often
what
what?
A
A
You
just
cannot
sustain
that
kind
of
thing
in
a
wide
sail
implementation
and
that's
the
same
kind
of
thing
with
if
you've
got
actual
physical
devices.
If
we're
integrating
into
things
like
electric
vehicle
charges,
we
can't
just
go
and
keep
on
updating
that
thing
and
re-type
approving
it
every
time
the
blockchain
stuff
changes.
A
So
we
still
don't
go
straight
from
the
RPC
into
the
chain.
We
have
full
nice,
very
capable,
mostly
golang
micro
services,
that
handle
the
requests.
The
reason
we
have
to
do
things
like
this
is
partly
because
we've
got
this
big
Jitsu
in
bubble
in
the
middle,
you
know,
being
a
hybrid
architecture,
blockchain
nodes,
access
to
the
entire
ledger,
custody
of
the
important
keys
and
the
participant
data,
and
all
of
that
belongs
to
each
of
the
participants.
A
So
they
have
full
control
over
over
that
piece
of
it,
the
record
and
and
their
ability
to
recover
things
and
dispute
things
and
prove
truth
and
so
on,
but
we're
not
dealing
with
very,
very
simple
transactions.
We
tokenize
assets
again.
If
you
look
at
this
this
guy
up
here,
there's
something
like
a
PLC.
We
tokenize
those
assets
and
store
their
entire
life
history.
We
store
every
time
somebody
tightens
up
a
nut
or
every
time
somebody
issues
a
work
order,
or
every
time
you
get
a
vulnerability
alert.
A
Some
of
that
data
is
very
and,
as
we
know,
you
don't
stall
very,
very
large
data
on
a
blockchain,
and
so
we
have
a
whole
bunch
of
sass
services
which
are
shared
by
the
value
chain,
just
for
doing
things
like
D
duping,
large
files
and
storing
the
big
stuff
and
doing
quick
lookups,
and
some
other
things
like
that.
So
one
of
the
things
we
can
do
is
simply
deal
with
with
that.
A
One
of
the
other
things
you
have
to
do
is
that
having
a
micro
services
interface
here
allows
you
to
have
much
much
better
relationship
with
your
code
and
human
customers,
because
thinking
back
again,
I
mentioned
eventual
consistency.
Again,
you
know
this
isn't
new
everybody
in
this
room
knows
what
eventual
consistency
is
here.
Everybody
knows
that
you
have
to
wait
and
you
have
to
keep
pressing
refresh
and
you
have
to
look
and
search
and
accept
that
your
thing
isn't
found
by
hash
for
several
minutes
whatever
it
might
be.
A
That's
no
good
if
your
enterprise
UI
or
it's
no
good,
if
you're
a
guy.
Oh
this
poor
guy
who's
in
the
field,
he's
got
maintenance,
jobs
to
do
he's
judged
on
yield,
and
his
bosses
know
that
if
he
works
at
an
appropriate
work
rate,
he
can
visit
nine
devices
in
a
day
and
get
through
that
number
of
maintenance
calls
in
a
day,
and
so
if
he
has
to
sit
and
wait
and
stand
and
just
stare
at
his
phone
waiting
for
transactions
to
complete
and
then
waiting
to
make
sure
they
haven't
been
rolled
back.
A
That's
not
only
annoying.
It's
actually
a
business
deficit
and
it
won't
fly
so
we
we
get
to
do
a
whole
bunch
of
risk
assessment
and
making
sure
that
yeah
you've
got
no
obvious
problems
that
are
definitely
going
to
fail.
You
know
we
run
a
kind
of
simulation
of
the
transaction,
just
to
make
sure
there's
no
bad
objects
and
stuff
are
there,
so
you
can
get
a
very
quick,
very
high-quality,
usable
response
back
before
you
submit
yourself
to
the
the
wiles
of
the
of
the
DLT
down
at
the
bottom
yeah
smart
contracts.
A
We
all
know
that
smart
contracts
do
we've
got
our
source
of
truth,
and
it
is
very
important
that
the
source
of
truth
is
the
ledger
still
in
the
end,
everything
that
we
stand
by,
that
we
have
analysis
on
things
like
you
know.
If
bill
swears
blind
that
he
definitely
polished
the
thing
and
Burt
swears
blind
that
the
thing
is
not
polished
and
that's
why
it
stopped
moving.
You
know
how
do
we
very
work
out,
which
is
true
that
absolute
down
the
ledger
level?
A
It's
not
anything
to
do
with
the
the
top
web
stuff
and
so
to
bring
those
together.
What
we
needed
to
do
was
to
make
this
abstraction
layer
and
I,
don't
know
how
how
many
of
you
guys
actually
have
built
whole
systems
or
whether
you
kind
of
start
at
this
level.
If
you
start
at
this
level,
I
guess
the
the
choicest
thing
won't
make
a
huge
amount
of
sense.
A
You
might
nobody
knows
why,
but
for
us,
what
we
needed
to
do
was
to
be
able
to
build
this
whole
system
and
have
people
interacting
and
have
maintenance
teams
submitting
stuff
and
have
security
teams
submitting
patches
and
having
owner
organizations.
Doing
things
are
submitting
regulatory
compliance
reports
and
stuff
like
that.
So
that's
what
this
this
system
does,
but
we
also
needed
to
make
sure
that
this
part
was
going
to
work,
no
matter
what
the
turbulence
and
the
changes
and
the
sort
of
cutting-edge
stuff
we
were,
we
were
dealing
with.
A
While
we
worked
out
which
technology
could
could
work,
I
was
spending
fairly
long
hours,
trying
to
fix
bugs
in
in
Seth,
for
example,
while
the
guys
were
able
to
write
the
rest
of
the
stuff,
while
one
of
my
other
guys
who
was
working
in
Borough
on
a
on
a
plan
B.
So
this
was
a
nice
thing
and
the
choices
that
we
made
in
the
end
were
fairly
fairly
few.
A
We
stuck
with
the
idea
of
going
UVM
again
I
kind
of
I
like
transaction
families
and
sawtooth,
and
if
I
was
doing
a
home
project
or
if
it
were
less
critical
or
if
it
was
smaller,
I
probably
would
just
do
a
native
one
kind
of
like
damn
well
I'm,
a
big
fan
of
formal
stuff.
So
a
stronger
language
is
a
better
in
my
view.
A
Personally,
but
for
a
business
we
had
to
stick
with
something
that
fulfilled
my
original
plans,
so
EVM,
initially
solidity
effectively,
and
because
we've
made
that
choice,
we
also
were
able
to
standardize
on
our
LP
for
serializing
our
objects
for
points
where
you
really
can't
avoid
things
bleeding
through
the
layers.
We
did
that
and
we
had
to
make
sure
that
token
addressability
was
consistent,
and
so
we
stuck
with
particular
tokenization
form
in
any
VM
for
our
object,
IDs,
which
go
all
the
way
right
up
to
here.
A
If
you
want
to
access
a
a
machined
token
and
see
what
all
happened
to
this
particular
thing
that
bleeds
up
through
that
stack,
but
that
was
all
we
had
to
do
and
and
everything
else.
We
then
had
total
freedom
to
switch
out.
The
things
south
of
the
south
of
this
guy
guy
here
so
gave
us
an
awful
lot
of
choice,
just
with
those
three
very
simple,
simple
things
that
we
did.
So
what
made
that
actually
possible?
A
Strong
encapsulation
I
mean
these
two
I'll
put
them
up
quickly,
because
they're
kind
of
obvious,
if
you've
never
done
a
CS
course,
you'll
know
that
this
is.
This
is
right,
but
actually
it's
worth
repeating,
because
I
still
don't
see
this
practice
very
often.
If
you
look
at
a
lot
of
the
examples,
even
if
you
go
to
the
github
repositories
for
Hyper
ledger
or
if
you
look
at
a
lot
of
examples
in
outside
of
hyper
ledger,
you
get
it.
You
know
any
of
the
the
other
guys.
A
I
won't
won't
name
them
here,
just
because
I'm
guest
of
yes,
the
Lynx
foundation.
But
you
know
there
are
a
couple
of
other
big
organizations
that
do
decentralized
apps
and
they
have
a
bunch
of
examples,
and
actually
this
doesn't
tend
to
happen.
You
tend
to
end
up
with
slightly
messy
cross-cutting
concepts
in
smart
contracts
and
things
you
tend
to
end
up
with
having
tokens
that
are
used
for
a
bit
too
much
or
functions
that
have
side
effects,
which
you
don't
really
want.
A
It's
really
important
to
make
sure
that
your
functions
are
as
small
as
possible,
not
only
because
of
things
like
security,
not
only
because
of
things
like
upgrade
ability
and
durability,
but
also
because
if
you
find
that
a
tiny
piece
of
your
puzzle
doesn't
work,
the
less
of
it,
you
have
to
switch
out
a
short
notice,
the
better
so
yeah.
These
actually
are
fairly
important
points
to
make,
even
though
they
should
seem
obvious.
But
the
the
biggest
thing
is.
Is
this
I
hear
a
lot
of
people
talking
about
interoperability
in
blockchain?
A
I
was
on
a
panel
about
a
year
ago
in
London,
and
somebody
said:
what's
the
like
most
important
thing
about
interoperability
involve
chain,
you
have
to
kind
of
eat
the
same
dog
food
as
the
industry
as
a
whole.
If
we
think
that
we're
building
systems
and
plumbing
and
infrastructure
for
a
data-driven,
the
future,
where
everything
is
just
sort
of
passed
around
and
virtualized
and
tokenizing,
then
you
have
to
make
sure
that
your
interoperability
plan
is
at
that
data
level.
A
You
have
to
make
sure
that,
if
you've
got
tokens
that
token
format
is
expressible
and
consumable
in
multiple
different
technology
stacks
from
the
kind
of
at
least
the
middle,
if
not
the
top
right
down
to
the
bottom.
Otherwise,
your
stuff,
if
you've
got
attributes
on
those
tokens,
if
you
want
to
actually
be
manipulating
very
traditional
meta
and
also
real
data,
you've
got
to
make
sure
that
those
are
expressible
in
all
of
the
frameworks.
It's
no
good
having
you
know:
nested
complex
objects.
A
If
you
then
go
into
a
framework
that
doesn't
support
nested
confidence,
though
objects
you
just
end
up
having
a
real
nightmare.
So
again
seems
like
an
obvious
point,
but
actually
it's
really
important
to
knuckle
down.
Look
at
what's
really
valuable
to
your
business
case,
design,
a
very
strong
data,
typing
data
format,
design
and
then
shove
that
back
up
into
into
what
you're
using,
but
indeed
it's
not
only
three
wheels.
It's
full.
Definitely
a
fourth
rule.
It's
very
easy
in
all
of
this.
A
That's
not
what
you
want
to
do.
You've
got
to
remember
every
time
that
the
objects
on
the
ledger
are
true,
and
if
the
ledger
somehow
disagrees
with
your
data
store,
your
data
store
has
to
be
blown
away
and
rebuilt,
because
that's
you've
clearly
made
a
mistake.
You've
got
to
make
sure
that
all
of
the
state
transitions
and
everything
you're
promising
are
done
through
smart
contracts,
with
the
correct
keys
that
are
separate
for
every
node.
Otherwise,
what
you've
got
is
a
centralized
system,
and
that's
also
not
what
you
wanted.
A
You
better
make
damn
sure
those
devices
are
kept
up-to-date,
because
if
you
let
them
lapse
and
you
get
hacked
and
no
heaven
forfend.
Any
of
you
doesn't
know
this,
but
you
know
if
you
want
to
know
the
kind
of
consequences
just
search
for
ransomware
in
your
browser,
and
you
will
find
countless
opportunist
examples
of
infrastructure
that
was
left
on
patch
for
too
long
and
got
got
broken.
These
regulations
say:
if
you
live,
it's
unpatched
for
too
long.
A
You
are
negligent
and
you
will
get
fined
or
if
you
don't
get
fined,
you
might
even
lose
your
operating
license.
That's
a
big
big
problem.
I!
Don't
want
to
be
in
the
suspicion
loop
for
messing
with
that
kind
of
data.
I,
don't
want
anybody
to
think
that
I
can
press
a
big
button
and
shred
some
incriminating
evidence
or
hide
access
to
someone
who's
tried
to
build
a
defense
case.
We
just
want
to
make
a
fair
system
where
everybody
plays
by
the
rules.
A
Everybody
does
their
job
and
hopefully
everything's
fine,
but
if
it
isn't,
you
get
to
find
out
the
truth
quickly
and
there's
no
way
that
we
want
to
be
in
the
middle
of
any
kind
of
shredding
scandal.
So
so
what
we
managed
to
build
with
that
this
guy's
kind
of
fun.
This
was
never
intended
to
be
a
product,
but
we
had
to
prototype
things.
A
So
the
experience
that
the
user
gets
is
very
enterprising
standard.
Oh
I,
can
there
we
go
I
did
I
did
put
one
in
there.
The
the
enterprise
user
has
an
ordinary
experience.
They
see
a
SAS
service,
they
deal
with
interesting,
large
human,
readable
data
elements,
but
at
any
point,
if
you
want
to
double
check
and
make
sure
that
everybody's
seeing
the
same
thing,
you've
got
all
that
data
there,
just
in
case
there's
another
another
important
lesson
learned
from
a
lot
of
sort
of
PLC's
and
conversations
and
trials
and
stuff.
A
If
you
hide
the
Chane
completely,
nobody
gets
it
and
it's
kind
of
pointless.
But
if
you
make
it
very
prominent
and
you
put
things
like
transaction
IDs
is
the
first
element
in
the
list
everybody's
lost
that
they
wonder
what
the
hell
you're
talking
about.
So
having
that
that
ability
to
keep
it,
keep
it
there
when
it's
needed,
but
not
that
shove
it
in
people's
faces.
A
Fingers
crossed
maybe
we'll
come
back
to
at
some
point,
but
we
had
to
transition
off
sawtooth
for
now,
while
we're
doing
the
go-live,
so
our
live
networks
actually
running
on
quorum
right
now,
but
for
space
and
speed
reasons
and
all
sorts
of
other
things
cost
even
over.
Where
there's
another
session
next
door,
which
is
about
running
fabric
on
Microsoft
Azure.
So
we
run
on
Azure
and
we
have
to
pay
for
all
the
space
and
the
computing
time
and
the
networks
and
the
kubernetes
clusters
and
stuff
we
use.
A
We
actually
do
our
QA
our
smoke
qhs
on
Ganesh,
because
it's
really
simple,
it's
small
runs
quick
and
everything
else
and,
most
importantly,
we've
got
the
opportunity
to
flex
again
so
as
the
market
improves
as
things
get
better
or
worse,
as
we
get
more
sort
of
serviced,
blockchain
options
that
that
might
might
be
worth
worth
using
we're
able
to
do
that
without
having
to
rewrite
very
large
parts
of
our
stack
yeah.
We
don't
present
our
customers
with
the
blockchain
thing
as
the
entire
full
product.
A
We
present
them
with
the
thing
that's
underpinned
by
blockchain,
and
what
that
means
is
that
we're
able
to
go
and
keep
the.
However
many
million
dollars
of
investment
we've
already
spent
and
just
swap
out
for
something
better
underneath
which
of
course,
is
what
all
services
are
supposed
to
be
able
to
do
so.
That's
what
we
we
built
and
also
I,
made
two
point
earlier,
but
it
means
we
can
publish
our
Doc's
on
the
Internet,
and
people
can
write
code
today.
A
A
A
Yes,
and
no,
so
we
did
it
first
and
foremost
because
we
had
to
we.
We
had
a
solution
that
wasn't
working
and
my
job
is
to
make
things
work.
So
that's
a
we
did
that
and
with
a
bit
of
thinking,
and
one
of
my
guys
is
doing
a
PhD
in
blockchain
at
Cambridge,
and
you
know
we're
all
kind
of
old,
it's
a
start-up
but
I'm
nearly
41
now
and
I'm,
the
youngest
right.
A
So
we've
all
got
that
kind
of
systems,
engineering,
aerospace,
security,
experience
to
step
back
and
take
a
quick
look
at
a
problem
when
it
arises,
and
we
just
sort
of
decided
that
we're
gonna
have
to
change
anyway
and
actually
the
effort
of
making
something
good
and
flexible
and
retaining
our
business
choice
in
the
future
was
not
much
more
than
just
making
a
heart
switch.
So
that
was
kind
of
why
we
did
it.
But
indeed,
yet
those
choices
that
we
layered
into
that
going
with
something
like
solidity.
A
Exactly
yes,
because
it
gives
us
the
flexibility
of
what
test
frameworks
to
use.
It
gives
us
a
flexibility
on.
You
know,
libraries
and
things
that
we
can
draw
in
and
standards
and
and
everything
else
with
respect
to
the
data.
There's
very
little,
there's
very
little
data
that
we
run
through
the
system
which
isn't
somehow
touched,
but
it's
the
usual
thing
I.
So
a
lot
of
the
time,
if
you're
doing
something
like
a
maintenance
report,
you'll
have
a
three
or
four
page
scanned
PDF
and
we
don't
put
that
in.
But
we
do
have.
A
A
So
the
other
thing
I
missed
off,
of
course,
which
is
massively
important,
was
all
of
the
DevOps.
So
you
know
in
that
some
very
oversimplified
architecture
diagram
all
of
the
key
storage,
key
distribution,
backup
recovery,
the
kubernetes
clusters
that
we
run
the
system,
monitoring
the
health
probes,
a
that
that's
big
right,
but
it
just
wasn't
relevant
to
this
Kevin.
A
A
Currently,
currently,
no
so
currently
its
kind
of
it's
just
stuffed
straight
down.
We've
got
plans
to
distribute
that
piece
as
well.
So
right
now,
that's
just
part
of
the
sass,
and
we
we
run
that.
But
that's
really
for
practical
reasons.
It's
just
because
distributing
that
piece
requires
a
lot
more
infrastructure
in
the
customers
tenants.
It
requires
a
lot
more
networking
and
staff
and
staff
that
view
it's
just
not
worth
taking
that
operational
risk.
But
so
eventually
it
will
be
what
you
said:
the
question
by
the
way
salary
for
the
for
the
tape.
A
A
A
They
really
shouldn't
be
able
to
know
who's
performing
poorly
on
cyber
security,
SLA
s,
and
things
like
that.
So
so
that
still
has
a
lot
of
the
the
message
level
security
pieces
in
it,
which
again
makes
it
a
little
bit
harder
to
split
hair
in
the
beginning,
but
architectural
II
philosophically
yeah
there.
The
plan
is
to
split
that
out
too
and
allow
sharding
so
that
people
hold
on
you
know
only
the
right
hairs
or
whatever.
If
people
hold
on
to
even
encrypted
copies
of
their
stuff,
it'll
come.