►
Description
Decentralized Control with IBM Blockchain Platform - Gari Singh, IBM
A core tenet of blockchain is decentralized control.Such control ensures Blockchain data and transactions can be trusted and not compromised by any single party.A traditional blockchain-as-a -service offering (where one vendor runs everything) undermines this basic tenet.Further, even running all of the nodes in the same cloud can undermine this tenet .Decentralized control is what our production customers want and what the market has demanded
With IBM Blockchain Platform, we introduced the concept of a "blockchain management platform" which provides an ideal offering where a vendor offloads the management and maintenance of the blockchain nodes but at the same time the owner(s) of the node(s) still retain full control of their nodes and cryptographic material .Come see Gari Singh demonstrate the latest on IBM Blockchain Platform that can run anywhere (on any cloud or on premise) and get advice on how to implement your blockchain applications using the latest capabilities in Hyperledger Fabric or IBM Blockchain Platform.
----
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
All
right
can
everybody
hear
me
I,
don't
really
need
this
Wow
exactly,
but
they'd
like
to
have
it
for
recording.
So
thanks
for
thanks
for
coming
we're,
gonna
I'm
gonna,
just
my
name
is
Gary
saying
you
can
see
that
I'm
one
of
the
many
roles,
but
one
of
the
maintainer
is
on
hyper,
lighter
fabric
and
then
I
am
the
whatever
the
CTO
for
blockchain
at
IBM
I
also
run
the
team
that
builds
the
IBM
blockchain
platform,
which
is
essentially
our
distribution
of
a
hyper
ledger
fabric.
So
today,
I'm
just
gonna.
A
Take
you
through
a
quick
15
minute,
like
whirlwind
tour,
on
what
we've
been
up
to.
If
anybody
was
here
for
the
last
time
we
did
a
global
forum
which
was
I
think
in
Basel
sometime
a
century
or
so
ago.
The
yeah
I
did
a
session
there
and
we
spent
about
we've
made
some
updates.
You
know
since
then,
so
I
thought
I'd.
Take
you
to
that.
If
you
have
any,
you
only
have
15
minutes,
but
I
think
we
have
like
15
minutes
between.
So
if
you
have
any
questions,
we
can
definitely
address
those.
A
So
just
is
everybody.
Maybe
I
could
skip
these
slides
everybody
pretty
much
familiar
with
fabric
hybrid,
your
fabric,
you
guys
got
that
right,
so
I
mean
the
key
thing
on
here.
Right
was
just
to
talk
about
the
various
nodes
of
how
we
kind
of
break
up
fabric
into
essentially
the
core
being
the
peer
nodes.
We
also
have
ordering
service
nodes,
but
peer
nodes
are
on
your
smart
contract
and
then
we
broke
down
things
into
you
know.
How
can
different
organizations
essentially
run
their
own
peers
and
for
lack
of
a
better
term?
A
We
call
those
things
organizations,
so
that's
the
essential
breakdown
of
the
network
right,
a
set
of
set
of
nodes
that
are
managed
by
sort
of
different
parties,
the
the
kind
of
one
of
the
cool
things
that
I
think
that
we
did
in
in
fabric
itself
was
to
kind
of
make
everything
essentially,
policy
driven
right
and
then
in
all
these
policies,
so
we
can
have
policies,
for
example,
on
who's,
a
member
of
a
channel
which
would
be
our
version
of
a
ledger
right.
Each
peer
can
be
part
of
multiple
Ledger's.
A
A
Most
of
them
are
driven
by
molten
umber
of
signatures
required
to
update
them,
and
this
is
distributed
across,
obviously,
all
the
members
of
the
network.
So
we
have
all
these
kind
of
facilities
within
within
fabric
itself
and
one
of
the
things
that,
but
for
those
who
want
to
deal
with
a
low
level,
you
can
obviously
do
that.
One
of
the
areas
that
we
chose
to
focus
on
from
the
sort
of
IBM
perspective
was
the
overall
management
and
governance
of
these
of
these
policies
across
a
disparity
of
organizations.
A
These
quickly,
so
we
do
kind
of
two
things.
So
there's
there's
hyper
ledger
fabric
is
the
you
know,
open
source
side,
anybody's
free
to
take
it.
It's
a
project
out
there.
The
code
is
out
there.
On
the
IBM
side.
We
take
hyper
ledger
fabric.
We
I
will
just
I
always
like
to
state
this
fact.
We
don't
actually
modify
hyper
larger
fabric
at
all,
I
like
to
say,
because
that's
the
way
we
should
do
it.
It's
also
because
I'm
pretty
much
lazy
and
there's
no
reason
for
us
to
maintain
our
own
Fork.
A
So
we
essentially
take
the
literally
take
the
bits
we
don't
even
maintain
an
internal
copy
of
it.
In
IBM,
we
literally
build
straight
out
of
the
open
source
repository.
We
package,
those
up
into
certified
containers.
Those
containers
today
all
run
on
Red
Hat's
Universal
base
image
for
for
higher
security.
We
then
opted
to
take
a
focus
of
delivering
this
all
via
containers
seems
to
be
the
hip
thing
to
do,
but
also
the
best
way
to
kind
of
like
manage
and
orchestrate
these
things.
A
Essentially,
when
we,
when
we
first
built
the
IBM
blockchain
platform,
like
many
places
out
there,
we
built
it
all
in
IBM
cloud.
So
essentially
you
come
to
IBM
cloud.
You
provision,
you
know
you
create
an
instance
of
the
IBM
blockchain
service.
You
correct,
you
run
your
nodes
there.
This
is
good
convenient,
but
it's
also
prevent
you
know,
provides
kind
of
an
interesting
dilemma.
So
if
everybody,
the
way
we
did,
it
was
everybody
who
came
and
wanted
to
be
part
of
a
network
that
was
started
in
IBM
cloud
also
had
to
come
to
IBM
cloud.
A
So
you
essentially
end
up
with
these
supposedly
decentralized
nodes,
all
actually
running,
centralized
all
in
the
same
cloud
which
you
might
as
well
frankly
use
a
database
so
but
that
made
sense
when
we
first
started,
because
it's
very
hard
for
people
to
open
firewall
ports,
communicate,
etc.
So,
as
the
platform
evolved,
we
essentially
went
to
the
notion
of
okay,
we're
going
to
base
our
deployment
on
essentially
kubernetes
and
we
are
going
to
support
any
kubernetes
environment.
That's
out
there,
so
our
current
distribution
of
the
I'd
end
disagreement
fabric
will
run
on
you
know
any
kubernetes.
A
Distro,
obviously,
we
support
Red
Hat
OpenShift,
given
that
we
spent
a
large
chunk
of
change
on
that
company,
but
we
also
support
you
know
ibm's
kubernetes
service,
which
is
moving
to
open
shift.
We
have
people
running
on
things
like
rancher
in
different
different
regions
in
the
world,
where
IBM
clouds
not
available.
We
have
we're
running
on
Asher's
aks.
We
have
people
running
on
eks,
we
even
have
somebody
running
on
gke
Google's
is
Google's
as
well.
A
So
just
from
that
mere
perspective,
we
wanted
to
make
sure
that
our
distribution
could
run
new
across
all
those
sort
of
platforms.
We
use
the
industry,
buzzword
term
multi
cloud
deployment
for
that,
so
we
ship
either
as
cloud
or
as
software,
but
all
the
tooling
and
all
the
images
will
run
everywhere.
So
that
was
kind
of
you
know,
phase
one
of
saying,
hey
and
also
by
the
way,
there's
nothing
that
prevents.
A
You
know
me
from
deploying
my
stuff
on
the
IBM
version
of
the
IBM
distribution,
and
if
you
want
to
run
somebody
else's
distribution
or
the
open-source
distribution
it
is,
we
expose
all
the
fabric
api's,
so
you
can
obviously
connect
right.
So
if
somebody
wants
to
join
and
have
a
peer
and
you're
allowed
to
have
that
policy-
and
you
want
them
to
join
your
network-
that's
okay
as
well,
so
that
was
like
step
one
on
kind
of
our
decentralization
of
it
right.
We
said
we
got
to
take
everybody
off
of
the
same
cloud.
A
This
makes
no
sense.
So
let's
allow
it
to
be
spread
out
across
multiple
things.
The
I'm
gonna
skip
this
part,
but
it's
in
the
slides,
the
the--.
The
other
thing
that
we
wanted
to
do
was
one
of
the
key
things
for
obviously
making
fabric
do
anything
is
to
actually
write
what
we
call
chain
code.
You
know
chain
code
is
the
analog
of
smart
contracts.
You
know
in
the
and
blockchain
vernacular
we
put
out
a
so
chain
code
itself
can
be
written
in
three
languages:
Java,
Script,
Go,
Java,
I.
Think
there's!
A
You
know
other
people,
it
could
be
written
in
anyone,
but
those
are
the
three
that
are
supported
today.
One
of
the
things
that
we
wanted
to
do
was
figure
out
a
way
to
do
sort
of
collaborative
development.
So
clearly,
on
the
back
end,
you
can
use
any
you
know:
source
control
system,
github,
probably
the
most
common,
but
any
of
those.
So
we
decided
to
build
a
tool
for
doing
this
actually
to
make
it
easy
to
edit
and
share
all
of
your
artifacts.
We
chose
Visual
Studio
code,
which
is
the
open
source
tool.
A
A
A
One
of
the
key
value
proposition
that
we
had?
Obviously
we
can
do
all
the
deployment
I'm
not
going
to
get
into
that.
You
can
read
our
marketing
and
literature
about
that.
We,
like
I,
said
we
make
it
very
easy
to
deploy
your
notes
onto
kubernetes
environments.
The
more
important
piece
is
actually
how
do
I
manage
all
those
nodes.
So
for
this,
the
key
proposition
here
is
really
this
console
the
thing
about
the
the
console
is
it
actually
is
allowed
to.
We
actually
allow
you
to
communicate
across
other
consoles
as
well
right.
A
So
actually,
if
there's
multiple
people
who
are
actually
running
consoles
behind
the
scenes,
there's
an
actual
API
that's
exposed
and
you
have
the
ability
to
import
other
people's
endpoints
you'll
see
why
this
becomes
important
later,
when
I
try
to
actually
collect
signatures
and
policies.
So
the
essential
console
has
a
couple
of
capabilities.
We
have
the
ability
to
deploy
new
instances.
So,
for
example,
if
I
say
I
can
deploy
a
new
peer
and
it
will
actually
spin
up
a
peer
in
a
kubernetes
environment.
A
I
can
also
export,
for
example,
that
definition
or,
more
importantly,
it
might
be
of
my
ordering
service.
We
can
export
the
definition
of
that
as
a
JSON
metadata
file
and
then
somebody
else
can
actually
import
it
into
their
console
as
well
right.
So
the
use
case
may
be
that
there's
a
couple
of
organizations
who
are
running
the
ordering
service
nodes
I
still
might
want
to
be
able
to
do
things
like
join
those
channels,
sort
of
manage
nodes,
so
I
want
to
have
that
metadata
and
import
that
my
console.
A
A
The
the
other
thing
that
we
that
I
I'm
a
little
bit
proud
of
I
guess
so
I'll,
maybe
speak
too
much
on
this.
We
and
some
people,
some
other
people,
do
this
as
well.
All
the
fabric
is
essentially
managed
by
digital
signatures
right
so
peers
when
they
validate
in
science
and
transactions,
they're
signing
when
ordering
nodes
distribute
blocks,
they
sign
them
when
people
or
users
submit
transactions,
they
actually
sign
them.
So
when
we
had
our
previous
version
of
the
actual
console
itself,
we
IBM
or
actually
managing
your
private
keys
might
not
have
known
this.
A
But
essentially
you
want
to
have
our
console
and
says,
deploy
chain
code,
install
chain
code
create
channel
all
these
actions.
These
are
all
administrative
actions.
We
actually
had
your
private
keys.
I
mean
we
not
that
we
didn't
tell
you
this.
We
did
and
other
platforms
actually
do
this
as
well.
Today,
I
did
not
think
this
was
a
good
idea
for
a
variety
of
reasons.
It's
you
know
you
don't
want
to
have
the
legal
stuff,
but
it
just
doesn't
make
sense
that
if
you're
deploying
it
into
the
cloud,
you
should
have
control
of
your
own
keys.
A
So
clearly
you
have
access
to
the
fabric,
api's,
so
no
problem
there.
You
can
write
your
own
tools
to
do
that.
So
one
of
the
things
that
we
actually
chose
to
do
from
our
UI
perspective
is
all
signatures
actually
happen
in
the
browser.
So
we
actually
create
all
the
transactions
within
the
browser
themselves.
There
protobufs
we
serialize
them.
We
sign
them
in
the
browser
itself
and
then
we
submit
those
transactions
to
fabric,
so
there's
never
I
be
em
or
our
software
or
whatever
is
actually
never
in
possession
of
your
private
keys.
A
And
you
can,
you
know,
import
an
export.
These.
You
just
basically
upload
your
identities
into
the
console
itself.
Right
and
your
private
keys
are
in
there
they're
stored
in
local
storage.
For
a
second,
you
can
obviously
clear
the
cache
and
delete
them.
So
that
was
one
sort
of
key
feature
that
we
wanted
to
make
sure
of
it's
like
number
one.
As
I
said,
don't
just
run
on
IBM
cloud
number.
A
The
the
coolest
parts
of
the
technology
and
the
rules
that
we
have
and
fine
grained
authentication
and
authorization
would
be
around
the
notion
of
channels.
So
most
people
here,
familiar
with
fabric
channels,
fabric
channels
are
essentially
Ledger's
and,
as
I
said
earlier,
they
have,
they
can
have
some
very
complex
policies
right
who's
allowed
to
read
data
from
the
channel
who's
allowed
to
write
data
from
the
channel
who's
allowed
to
update
the
policy
of
who's
allowed
to
read
and
whose
the
Lots
are
right
to
the
channel,
who
are
members
of
the
channel,
yada
yada
yada
right.
A
These
are
all
can
have
fairly
complex
policies
right
they
can
require.
In
order
to
do
updates,
they
actually
require
multiple
signatures.
Generally,
they
require
multiple
signatures.
The
most
common
thing
for
adding
a
member
to
a
channel
is
majority
of
the
majority
policy,
but
you
can
do
you
know
anything
five
out
of
seven
five
out
of
nine,
whatever
you
want,
whatever
you
make,
I
guess
those
are
all
majorities
here,
but
whatever
you
may
want
to
do
so.
What
we
actually
do
here
is
once
you
actually
define
your
definition
of
the
ordering
service.
A
A
You
can
count
on
it
if
you
can
fully
see
this,
but
if
you
look
over
to
the
left-hand
side,
essentially,
when
you
go
in
and
say,
I
want
to
create
a
channel.
I
can
then
choose
who
the
members
of
that
channel
are
I,
can
add
and
remove
them.
I
can
actually
select
all
the
various
ACLs
there's
like
I
said:
I'm,
not
gonna
go
into
all
of
those,
but
all
that
he's
done
in
the
console
here
now.
A
A
Actually,
if,
for
example,
I
decide
that
I'm
going
to
add
a
member
to
a
channel-
and
it
requires
other
people
to
sign
off
on
it
the
con,
so
here
once
you
create
your
transaction,
it
will
actually
send
those
over
to
via
an
API
over
to
other
consoles.
They
will
be
notified
in
their
inbox.
They'll,
be
able
to
sign
those
transactions
post
back
to
whoever
the
initial
submitter
was.
You
can
collect
all
those
detached
signatures
and
then
submit
them
actual
to
the
actual
ordering
service
for
updates
with.
A
We
don't
do
it
yet,
but
once
we
once
fabrics
once
we
add
support
for
fabric,
oh
we're
a
fabric,
oh
actually
does
this
for
our
chain
code
as
well,
so
all
of
the
updates
to
chain
code,
the
endorsement
policies,
all
the
policies
they're.
They
will
actually
follow
a
simple,
a
similar
model
that
actually
requires
distributed
governance
where
multiple
parties
actually
have
to
sign
off
before
we
can
deploy.
It
will
enable
that
same
capability
within
the
console
itself.
A
So
the
kind
of
key
thing
here
is
the
key
message
here:
right
is:
how
do
we
actually
orchestrate
this
sort
of
complex
digital
signature
workflow
across
multiple
parties
and
while
keeping
ourselves
especially
more
in
the
cloud
while
keeping
ourselves
out
of
the
mix?
We
had
a
lot
of
these
capabilities
in
our
previous
versions,
but
the
way
we
did
it,
there
was
a
sense.
We
again
we
collected
everything,
pass
it
out
to
everybody.
We
had
all
of
your
admin
keys.
Did
all
your
signatures
collected
everything
and
sent
all
the
blobs
for
you.
A
So
in
this
particular
case
we
don't
have
to.
We
don't
have
to
be
in
control
of
anything.
The
other
unique
thing
here
is
that
I
think
a
lot
of
times,
people
within
the
fabric
within
the
fabric
world
or
the
blockchain
world
like
to
use
the
term
network
I,
get
it
I'm,
actually
not
a
big
fan
of
the
term
like
blockchain
Network,
because
we
built
we
build
models.
A
This
way
as
well
right,
you'll
see
this
in
other
clouds,
where
essentially
you
go
in,
you
create
an
order
of
your
you,
create
an
ordering
service
and
then
that
ordering
service
defines
the
network
right
so
to
ever,
control
that
ordering
service
all
the
channels
are
associated
without
that's,
actually
not
the
way
fabric
was
actually
designed
fabric
itself.
A
fabric
peer
can
actually
connect
to
channels
that
are
managed
by
multiple
ordering
services.
So
there's
no
reason
that.
A
So,
if
your,
let
me
to
IBM
so
horn,
we
have,
for
example,
two
networks
that
we
are
founding
members
of.
You
know:
trade
lands
and
IBM
food
trust
right
if
to
actually
have
a
peer
and
it
wants
to
a
single
peer
and
it
wants
to
participate
in
both
food
trust
and
trade.
Lens
fabric
allows
that
to
happen
right.
A
One
of
the
things
we
wanted
to
make
sure
we
could
actually
do
in
our
platform
was
actually
enable
that
that
capability
and
you'll
kind
of
see
if
I
fool
you
toot
our
own
horn,
again
I,
think
that's
one
thing
that
we
differentiates
us
from
the
other
sort
of
platform
vendors
out
there,
where
they
all
still
centralized
on.
You
know
it's
here's
the
ordering
service,
this
shared
ordering
service
and
you
can
only
have
nodes
connect
to
that.
But
that's
not
really
the
way
you
want
it
to
work.
A
You
essentially
may
have
people
who
want
to
run
different.
There
may
be
different
groups
that
you
trust
to
run
channels
for,
like
the
finance
part,
or
somebody
may
be
running
them,
for
you
know,
I,
don't
know
whatever
supply
chain
or
you
may
just
have
different
channels
governed
by
different
people,
and
they
want
to
run
different
ordering
nodes,
especially
with
fabric.
A
When
you
run
raft
with
our
raft
consensus
and
then
the
future
are
BFT
consensus,
you
can
actually
have
you
know
15
ordering
nodes
and
channels
can
you
can
actually
be
running
channels
on,
like
10
channels
run
on
5
of
them?
5
channels
run
on
4
of
them,
so
we
can
disperse
that
as
well.
So
we
really
wanted
to
make
sure
that
from
this
model
we
allow
you
to
have
complete
flexibility
of
how
fabric
actually
works.
Where
you
don't
have
to
have
a
centralized.
A
A
A
Yeah,
so
the
eventual
so
any
of
the
event,
so
we
don't
store
the
intermediate
artifacts
right.
So
the
mere
fact
that
if
somebody
decided
they
wanted
to
propose,
let's
say
somebody
proposes
that
I
say:
hey
I
want
mark
to
join
the
channel
and
I
send
that
out.
You
know
Brian
Tong,
you
know
Eddy
and
a
few
other
people.
A
We
don't
record
that,
but
once
if
you
did,
if
everybody
did
agree
and
you
got
enough
signatures
and
then
that's
submitted,
then
yes,
that
that
that
configuration
transaction
and
the
update
is
actually
part
of
the
actual
ledger
itself.
That's
actually
the
one
thing
that
you
know
in
fabric
that
we
do
I.
Think
very
you
do
some
things
well
do
very
well
right
is
the
ability
to
actually
change
policies
right
without
having
to
fork
or
anything
like
that
right?
It
was
sort
of
built
in
that
we
have
essentially
within
your
sort
of
this
channel.
A
We
have
this
notion
of
configuration
blocks
right
in
the
configuration
blocks,
essentially
store,
who
they're
members
of
the
channel.
What
are
the
policies
that
are
on
this
channel,
and
so
you
know
up
until
whatever
the
latest
config
block
is
that's
what
governs
the
behavior
of
the
of
the
of
that
channel
when
we
add
an
update
the
next
blocks
after
that
will
be
processed
under
the
new
policies.
But
if
somebody
joined
late
and
wanted
to
replay
everything
that
happened,
they
would
still
go
in
order
right.
A
So
when
they
get
the
first
block,
it's
going
to
be
whatever
the
initial
configuration
was
and
so
on
and
so
forth.
But
that
will
allow
us
to
do
things
like.
Let's
say
we
decide
that
you
know
elliptic,
you
know
you
see,
DSA
is
broken
or
sha-256
is
broken.
We'll
still
have
that,
obviously
for
the
prior
parts
of
the
change,
but
then
we
could
go
put
out
a
new
cryptographic
algorithm
that
everybody
uses.
So
that's
the
sort
of
power
sure.
A
A
Yeah
that
works
so
general
in
general,
that
works,
because
we
don't
actually
hide
any
of
the
fabric
api's.
So
all
the
fabric
api's
are
available,
so
yeah
there's
there's
no
no
issue
doing
that
and,
for
example,
even
if
you're
a
channel,
if
you're
a
channel
admin
or
something
like
that
and
you're
required
to
get
a
signature,
we
can
still
send
you.
Somebody
can
actually
send
you,
for
example,
the
block
to
update
the
you
know
the
channel
config
block.
A
They
could
send
it
to
you,
you
can
sign
it
out
of
band
and
you
could
return
your
detached
signature,
that'll
work
and
if
people
wanted
to
have
it
show
up
in
the
node,
we
don't
there's
a
metadata
format
of
how
to
describe
up
here.
So
as
long
as
you
give
somebody
else
like
that
JSON
format
they
could
potentially
even
have
your
representation
of
your
peers
show
up.
In
there
I
mean
we
don't
have
like
an
auto
generate
that
config
for
non
or
non
peers,
but
yeah
there's,
there's
no
issue
there.
A
A
So
we
don't
we're
not
necessarily
around
to
tell
you
how
to
connect
your
peer
to
IVM
blockchain
platform,
because
that's
if
those
are
just
we,
those
are
just
going
to
happen
at
a
fabric
level,
but
we,
you
know,
we
don't
we're
not
going
to
say
that
you
can't
that
you're
not
allowed
to
do
that
right
when,
if
somebody
buys
our
software
I
want
other
people
to
connect
to
it.
We
we
are
compatible
with
the
fabric
version
in
fabric
api's,
yeah
I
know
where's.
So
that's
the
fun
yeah.
That's
a
support
thing.
Oh.
A
A
Oh
yeah
yeah
so
right
when
so
yeah,
so
when
you
so
there's
sort
of
two
things
that
happen
so
one
if
you
go
in
and
like
immediately
enroll
a
user
via
the
console,
then
yeah,
the
private
key,
is
actually
stored
and
stored
in
theirs
to
be
stored
in
local
storage,
but
locked
down
to
that
actual
browser
session
or
lock
down
within
that.
So
you
can
clear
the
cache
if
you
want
after
the
fact
but
yeah
it
is
the
actual
private
key
itself
is
actually
in
local
storage
in
the
local
browser
stores.
Yet.
A
A
So
like
Firefox
for
example,
we
could
do
it
because
Firefox
will
actually
support
pkcs
11
straight
to
the
device,
so
we're
using
web
and
talk
more
with
on,
but
we
don't
today,
but
we
are
looking
at
the
ability
to
store
those
keys,
but
by
the
way,
once
you
delete
them
to
you,
if
you
delete
your
session
or
use
a
private
private
session,
they
won't
be
stored
in
there
and
then
they
can
be.
You
know
stored.
A
They
are
actually
technically
stored
offline
and
then
you
can
upload
them,
but
for
actually
being
able
to
communicate
with
an
HSM.
Unfortunately,
we
haven't
found
a
good
technology
for
that
yet,
but
if
you
have
some
ideas,
happy
to
you
always
have
idea
so
happy
to
look
at
them.
I
think
we're
the
next
presenter
here,
oh
well,
I
guess
where
you're
11:45
right.
What's
that,
okay,
any
any
more
wait.
A
A
So
they
don't
make
so
yes,
if
you
right
so
yeah
I
mean
you're,
gonna,
basically
use
it'll
be
similar.
You
doubt
you
would
usually
use
you
at
the
fabricate.
You
would
use
the
fabric
api's
to
do
that.
So,
for
example,
if
you
have
things
like
the
way,
AWS
works
right
on
their
piers
right,
you're
generally
talking
to
their
the
ordering
service
that
was
set
up
right.
The
consortium
is
set
up,
which
means
there's
an
ordering
service.
That's
run
by
Amazon.
A
Behind
the
scenes.
Peers
will
generally
their
tooling
I,
haven't
looked
at
their
latest
to
win
will
allow
you
to
join
those
channels,
but
because
you
have
the
fabric
API
available,
you
have
the
accessibility
of
the
fabric
api's.
Somebody
can
give
you,
for
example,
the
configuration
block
for
for
a
channel
managed
by
IBM
or
a
channel
created
on
an
order
or
that's
running
on
the
IBM
platform,
for
example,
and
then
you
can
use
the
joint
channel
API
to
actually
do
that.
A
Sure
that's
easier,
the
reverse
is
not
actually
necessarily
true,
because
Amazon
doesn't
like
Amazon
doesn't
exactly
give
us
give
us
give
you
access
to
their
orderer,
but
for
up
from
our
perspective,
yeah
any
so
anybody
running
our
software,
whether
it's
an
IBM
cloud
or
somebody
using
our
software
and
running
it,
anybody
can
actually
connect
to
it.
We
don't
stop
any
access
and
we
give
people
full
control.
They
they
own
it.
They
have
the
keys
they.
They
have
the
keys
to
the
kingdom
right.
A
They
have
admin
access
to
the
orderer,
they
have
all
of
it,
so
yeah
yeah,
which
was
by
the
way
I,
was
the
we
didn't
use
to
do
that.
We
had
a
lot
of
complaints
about
that.
So
when
we
chose
to
build
it
this
way,
that's
why
we
said
all
right.
We're
still
gonna
do
a
lot
of
the
operational
stuff
for
you,
but
you
really.
We
wanted
to
really
give
you
as
much
control
as
possible
so
that
you
had
full
power
of
fabric
your
stuff.
We
just
wanted
to
make
it
easier
for
you
to
do
it.