►
Description
Hyperledger Member Webinar - Creating an API first settlement solution - Clear. Tackling the major challenges for enterprise readiness and usability in the context of the telecom industry.
----
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 #HyperledgerMember #Blockchain
A
B
A
C
C
A
Yeah,
like
a
ghost
floating
around
hello,
everybody
you
are
in
the
right
place,
fear
not
we'll
start
in
just
a
second.
I
will
introduce
our
wonderful
presenter
and
then
we'll
get
going
with
the
presentation.
Just
we
want
to
wait
for
a
couple
of
people
to
to
join
and
give
some
people
time
in
case
you're
having
lunch
or
breakfast.
In
some
cases,
I
guess
yeah.
C
B
C
B
C
A
Okay,
well,
it
seems
like
we,
we
have
the
attendance
that
we
had
that
we'll
get
out.
Hopefully
some
more
people
will
be
joining
as
we
go.
So,
let's
start
welcome
everyone.
This
is
margarita
and
I'm
director
of
ecosystem
for
hyperledger.
Today
we
will
hear
a
presentation
from
gal.
Hochberg
from
ceo
and
co-founder
of
clear
and
gal
will
be
telling
us
about
the
create
how
they
created
an
api
first
settlement
re
solution.
A
Before
we
start
a
couple
of
housekeeping
rules,
the
whole
meeting
is
held
under
antitrust
policy.
The
antitrust
policy
is
visib.
You
can
find
it
under
the
qr
code
that
is
in
the
bottom
left
corner.
Basically,
please
remember
not
to
share
anything
that
you
wouldn't
want
to
be
shared
publicly,
especially
when
it
comes
to
your
company
information.
A
A
B
B
B
We
always
want
to
innovate
all
right.
Thank
you.
Everyone,
hello,
I'm
as
as
said,
I'm
a
gaul
and
I'm
a
co-founder
at
a
company
called
clear
and
we're
a
company
that
builds
settlement
networks
between
enterprises.
I'll
tell
you
a
little
bit
more
about
that,
and
the
purpose
of
today
is
to
tell
you
about
our
system
the
challenges
we
face,
the
architecture
and
how
we
used
a
software
like
hyperloop
or
fabric,
to
build
a
global
multi-enterprise
network.
B
So
the
challenges
we
had
in
general,
the
the
agenda
we're
looking
at,
is
to
talk
about
the
business
problem.
So
you
guys,
you
know,
sort
of
see
what
problems
we're
trying
to
solve
talk
about
the
challenges
of
building
a
long-lasting
enterprise
network.
So
you
know
we
think
about
the
longer
term
scale
and
privacy
how
we
had
to
deal
with
that.
The
challenges
of
running
an
enterprise
id
which
are
probably,
which
are
you
know,
very
challenging,
sometimes
so
sort
of
some
will
sit
there
our
work
in
being
api.
B
B
So,
let's
get
started.
What's
the
business
solution
that
we
are
trying
to
solve
it
clear
if
you
look
at
what's
going
on
in
the
world,
global
enterprise
commerce
is
booming.
Now
I
don't
think
this
graph
is
updated
for
kovitz.
That's
interesting
to
do
at
some
point,
but
in
general
the
amount
of
transactions
of
business
between
enterprises
in
the
world
is
becoming
bigger
and
bigger.
B
Now
this
this
shouldn't
surprise
you
because,
like
we
all
know
that
there's
companies
like
amazon
and
facebook
and
uber,
which
become
global
and
give
us
services
everywhere
and
in
general
today,
you
when
you
buy
anything,
there's
like
five
different
international
companies
will
help
make
it
happen
if
in
the
past,
you'd
buy.
You
know
the
grocery
store.
Next,
your
house
today
you're
buying
from
this
deep
supply
chain.
You
can
get
avocados
in
summer
here
in
israel,
which
is
which
is
impressive,
so
anyways
the
amount
of
transactions
is
going
bigger.
B
The
services
are
becoming
more
complex.
Now,
to
make
that
work
in
the
back
office
of
all
these
companies
there's
this
sort
of
engine
build
of
people
and
software
that
does
the
process
that
is
here
on
the
left.
That's
the
process
of
negotiating
a
contract,
agreeing
on
the
terms
find
creating
invoices
comparing
the
invoices,
handling,
disputes
and
discrepancies.
B
Now,
that's
you
know
general
normal
stuff
that
businesses
do,
except
if
you're
running
a
global
business
that
has
complex
products,
say
you're,
a
cloud
provider
or
telecommunications
provider,
or
you
know
your
walmart
even
having
humans
and
siloed
systems
do
all
these
separate
tasks
is
very
inefficient
because
the
contracts
are
more
complex,
it
might
be
usage-based.
There
might
be
discount
models,
you're
dealing
with
people
throughout
the
world.
Now,
there's
covet,
you
can't
even
meet
them
physically
right,
they
might
speak
different
languages.
The
amount
of
events
is
very,
very
big
things.
B
B
We
say:
let's
get
you
all
on
a
network
that
will
let
you
do
have
a
contract
dispute
resolution
agreements,
payments
all
in
a
single
network
together,
so
that
it's
all
automated
if
I
modify
a
price
in
my
system,
it'll
show
up
in
your
system
which
you
can
then
use
for
erp
or
profit
planning
or
whatever.
If
there's
a
discrepancy,
we
can
know
about
it
immediately.
B
We
don't
have
to
wait
for
the
end
of
the
month
in
general,
from
what
we've
seen
the
left
thing,
the
manual
process
can
take
up
to
90
days
and
the
right
one
you
can
do
in
hours,
and
so
the
ability
to
get
paid
faster
and
sometimes
even
to
pay
faster,
is
also
one.
Now
it's
not
just
about
efficiency.
It's
about.
If
you're
moving
to
a
new
type
of
very
complicated
contract.
The
way
on
the
left,
you
won't
be
able
to
do
a
transition.
B
B
A
B
All
right,
so
let
me
I'll
I'll
continue
a
little
bit
more
and
then
we'll
stop
for
a
little
bit
of
questions,
and
then
we
can
continue
so
just
to
give
a
little
bit
of
you
know
color
to
this
process.
This
is
a
very
generalized
enterprise
settlement
process.
You
start
with
a
contract.
You
go
to
execution.
There's
changes
that
happens.
You
go
in
order,
delivery,
reconciliation,
payment
termination,
any
one
of
us
has
been
involved
in
any
sort
of
b2b
deal-
has
seen
this
sort
of
stuff
now.
B
The
reason
this
is
so
hard
is
that
if
you
look
at
all
the
places
you
need
to
check
things,
this
is
just
some
of
them
right.
So
when
you
sign
a
contract,
are
these
the
right
parties?
Can
they
be
trusted?
There's
this
famous
scam
that
people
didn't
get
to
say
through
google,
where
they
sent
fake
invoices
and
they
lost
100
million
dollars
just
paying
fake
invoices.
B
So
do
you
know
you're
working
with
the
right
company
when
you
do
changes
prices
is
that
allowed
or
the
price
of
a
lot
has
been
approved
in
the
right
way?
Orders
is
somebody
ordering
the
thing
they're
allowed
to,
or
are
they
ordering
something
they're
not
allowed
to
did
are
the
orders
you
know
this
is
when
you
pay
an
invoice
attached
to
the
right
order.
B
There's
all
these
controls
you
need
to
do
and
a
lot
of
them
have
to
do
with
information
that
doesn't
sit
with
your
systems,
but
sits
with
the
other
side
system.
So
having
a
shared
source
of
truth
allows
you
to
do
a
lot
of
this
stuff
entirely
automatically
all
right.
I
think
this
is
a
good
time
for
us.
It
was
about
the
business
problem
before
we
dive
into
how
we
solve
it.
A
B
Okay,
okay,
I
thought
that
was
like
asking
a
question
all
right:
okay,
cool
so
moving
on,
so
that's
the
problem
we're
trying
to
solve
and
why
we're
trying
to
transform
with
blockchain.
Now,
let's
move
on
to
the
challenges
of
building
this
network,
so
the
next,
the
the
we're
gonna
in
a
second
we're
gonna
go
a
little
bit
more
technical
stuff,
but
I
do
wanna
think
about
sort
of
timeline
here
from
a
broad
sense.
B
When
we're
building
this
network
there's
all
kinds
of
challenges.
The
first
one
is
private
data
and
not
just
private
data,
but
lots
of
private
data,
we're
talking
about
prices
which
are
very
sensitive
in
trading,
we're
talking
about
volumes
and
revenues
all
right.
This
is
information
that
you
can
only
it's
public
companies
you're
not
allowed
to
know
these
things
before
they
reach
the
you
know
the
public
markets,
a
customer
data.
So
if
this
is
any
service
that
has
names
attached
to
it
or
phone
numbers,
then
that's
gdpr.
B
B
Second,
one
is
that
a
lot
of
the
customers
are
enterprise
customers.
The
biggest
companies
have
the
most
deals,
so
they
have
to
be
on
the
network,
which
means
you're
talking
about
on-prem
or
on
cloud.
It's
not
going
to
be
sas
so
much
by
the
way.
That's
another
benefit
of
using
fabric
in
blockchain
is
that
you
can
get
a
network
without
having
to
give
every
be.
Have
your
company
control
everything?
B
You
know
we
clear
we're
a
great
company,
but
when
we
come
to
huge
companies
fortune
100
companies,
a
pitch
that
goes,
give
us
all
your
private
information
about
pricing
and
vendors
and
revenue.
That's
a
very
short
conversation,
but
when
we
tell
them
you
can
run
the
system
in
your
it,
but
it
still,
you
know,
connects
to
the
wider
network.
That's
that's
very
interesting
for
them!
There's
many
stakeholders
you
have
to
deal
with
privacy.
We
talked
about
that.
They
might
not
know
about
blockchain,
so
you
have
to
like
educate
them.
B
You
know,
maybe
100
years
requires
sort
of
a
different
type
of
thinking.
So
I
want
to
stop
on
that
for
a
second.
The
analogy
I
like
to
give
about
this
is
think
think
about
these
networks
like
cities,
right
when
you
are
when
you're
building
a
city,
a
city
will
last
for
hopefully
hundreds
of
years,
and
you
can't
you
can't
upgrade
one
building.
If
you,
if
you
want
to
change
the
buildings,
you
can
only
upgrade
one
has
to
work
with
the
other
buildings.
You
can't
replace
the
cars
all
one
day.
B
B
You
know
pretty
much
in
the
same
structure
for
tens
of
years
and
as
we
we
can
all
see
with
you
know,
say:
moving
itb4
to
ipv6
you're,
stuck
with
your
decisions
for
a
very
long
time,
so
things
that
might
happen
that
we
have
to
keep
in
mind
number
one
new
ledger
technologies,
and
that
might
be
you
know
a
hyper
ledger
version
three,
four
seven.
It
might
also
be
a
just
new
new
new
software.
B
That's
going
to
come
out,
so
you
need
to
be
able
to
support
that,
and
that
also
means
different
dlts
in
different
geographies.
So
we
as
a
company,
we
started
with
ethereum
and
hyperledger,
but
you
know
that's
something
you
have
to
keep
in
mind.
There's
a
standards
and
other
implementations
there
may
be.
You
know
people
who
are
going
to
build
a
compatible
piece
of
software
and,
you
might
say,
hey
control
the
whole
network
yourself,
but
that's
not
viable.
You
can't
run
the
network
for
the
whole
world.
You
have
to
be
compatible
with
these
different
things.
B
B
So
the
the
I
think
the
thing
I'm
trying
to
say
here
is
that
when
you
look
at
blockchain
solutions,
there's
building
for
a
poc,
that's
one
one
thing:
there's
building
for
a
production
solution
which
is
another
and
there's
thinking
in
this
long
term
of
I'm
going
to
truly
build
a
network.
That's
going
to
be
here
for
a
very
long
time.
What
do
I
have
to
think
about
ahead
of
time?
So
that's
something!
B
That
is
why
we
chose
to
be
api
first,
both
facing
the
customer,
but
also
facing
other
implementations
and
faking,
the
ledger
itself
and,
in
general,
think
about
ledgers
from
an
abstract
perspective,
just
a
concrete
perspective,
but
don't
worry,
I
will
talk
about
concrete
things
in
hyperledger.
During
this
talk.
B
All
right
all
right,
so,
let's
start
diving
a
little
bit
into
the
into
the
concrete
technical
challenges
that
we
had
to
solve
and
how
we
solve
them.
So
the
first
one
is
scale
and
privacy.
We
talked
about
the
fact
that
it's
billions
of
events
and
it's
hundreds
of
participants
in
the
network,
and
we
talk
about
the
fact
that
data
has
to
be
private.
It
has
to
be
private
to
the
sense
of
if
we
accidentally
expose
a
phone
number
to
the
wrong
company.
That's
a
that's
an
offense
for
the
for
the
for
the
customer
right.
B
That's
a
in
europe!
That's
going
to
they're
going
to
sued
for
that,
and
so
we
have
to
do
those
things.
So
the
way
that
we
do.
That
is
that
when
we
think
about
data
in
the
relationship,
we
think
about
three
different
types
of
information.
There
is
public
data.
Public
data
is
information
like
the
name
of
the
network
members,
the
ips
that
you
want.
You
want
to
connect
to
them
directly,
whether
they're
members
in
good
standing
or
were
they
kicked
off.
B
Those
are
information
that
you
need
so
well,
for
example,
if
I
wanted
to
do
a
deal
with
say
a
mars
mask,
I
would
want
to
know
that
I'm
talking
to
mirth
so
their
public
key,
their
name
that
needs
to
be
in
the
network
and
publicly.
So
that's
information
that
is
public,
it's
not
very
big
and
it's
administrated
by
whatever
the
people
understanding
the
membership.
Maybe
you
might
have
different
network
different
member
networks
on
the
same
ledger
too,
and
so
that's
something
you
would
store
in
a
shared
chain
code
and
a
shared
channel
right.
B
You
have
one
big
channel
where
everybody
connects
to
to
get
that
membership
information.
Now
you
might
say
another
option
would
be
to
have
a
central
server
running
this,
but
in
some
networks
there
is
no
central
body.
You
have
a
committee
of
maybe
10
founding
members
who
all
vote
to
change
things
in
the
network.
That's
the
governments
of
the
network
might
not
be
might
be
distributed
as
well,
and
so
you
store
that
information.
We
store
that
information
in
a
shared
change.
B
The
next
thing
is
information
related
to
the
workflow,
that's
stuff.
That's
saying
I
have
a
price
change.
I
have
more
data
about
events,
I'm
accepting
or
rejecting
your
disputes
right.
This
is
the
remember
that
graph
of
the
workflow
from
before
that's
a
workflow
between
the
parties,
that
type
of
information
is
it's
not
too
much
information
right,
there's
only
so
many
events,
it's
not
billion,
it's
only
so
many
interactions
per
month
per
pair,
but
it
is
private
to
the
pair
transacting.
B
You
do
want
strong
cryptographic
identity
so
that,
if
I
sign
for
clear
that
we
accept
a
dispute,
you
need
to
be
able
to
take
that
to
court,
maybe
and
show
that
it
was
really
me.
So
you
need
to
have
the
crypto
signatures
you
require
strong
ordering
because
the
order
of
when
we
agree,
I
don't
agree
matters
and
it
needs
to
be
auditable.
B
So
you
know
if
if
there
was
a
blockchain
101
course,
this
information
is
classic
for
a
ledger
between
the
two
parties
and
we
indeed
use
a
chain
code
for
an
agreement
and
we
might
use
either
a
shared
channel
with
some
privacy
like
implicit
collections
or
state
channels
in
ethereum,
or
we
can
spin
up
a
separate
channel
depending
on
the
requirements
of
the
interaction.
So
that's
the
workflow
right,
that's
a
less
less
less
transactions
per
second,
but
has
to
be
very
secure.
Auditable.
You
know
immutable
between
the
pair.
B
B
It's
highly
sensitive
information
where
workflow
information
is
sensitive,
but
if
you
leak
that
somebody
accepted
something,
that's
not
too
bad.
If
you
leak
a
price,
then
everybody
in
the
market
wants
that
price.
Now
right,
so
prices
are
incredibly
sensitive
and
the
phone
numbers
and
customer
information
is
highly
sensitive.
So
this
is
highly
sensitive,
it
can't
be
modified.
B
B
Now,
if
we
had
in
hyperledger
5
a
very,
very
fast
data
availability
layer,
then
we
could
maybe
put
some
of
this
on
chain,
but
today
what
we
do
is
we
put
an
encrypted.
Maybe
we
put
it
in
an
opt-chain
protocol,
and
so
we
send
the
bulk
information
off-chain
that
doesn't
have
strong
ordering.
It
necessarily
have
strong
cryptographic
identification
for
everything,
but
it
can
happen
very
quickly
and
we
can
anchor
that
on-chain.
B
All
right,
these
are
the
three
communication
methods.
There
is
a
network
channel
which
is
a
shared
channel
for
all
the
members
that
has
a
policy,
an
approval
policy
mainly
of
a
few
and
either
an
administrator
or
a
few
anchor
peers,
because
that
is
the
one
that
edits
the
registry
for
who
is
the
member
who
wasn't
a
member?
B
It
might
be,
you
know
with
you
know
a
few
approvers
or
it
might
be
with
more,
depending
on
the
governance
of
that
specific
network,
and
everybody
connects
to
that
and
is
able
to
know
about
people
joining
people
leaving.
You
know
their
public
information
ips
accompany
logos,
which
is
nice
for
ui,
sometimes
contact
information.
That's
that's
that
public
information.
B
The
second
one
is
the
private
channel.
Now
this
may
be
a
private
channel
or
it
may
be
chain
code
that
uses
implicit
collections
or
state
channels
or
something
like
that,
depending
on
the
specific
implementation-
and
here
you
have
the
workflow
between
the
parties,
the
peers
that
are
approvers
are
the
two
parties
they're
the
people
of
proving
that
that
the
transactions
in
that
channel
are
for
that
chance
and
there
they
say.
I
agree.
I
disagree.
B
You
know
information
is
encrypted
or
hidden
to
be
just
to
that
and
then
finally,
there's
the
off
chain
protocol,
which
is
it's
the
file
transfer,
we
use
a
https
to
transfer
the
bulk
files
and
we
anchor
the
hashes
of
those
files
in
that
channel.
So
I
will
tell
you
I'm
giving
you
new
data.
This
is
the
hash
you
use
my
public
information
to
come,
go
to
my
ip
and
say
here's
a
key
that
I
have
to
get
the
information
from
you.
You
download
you
verify
the
hash
and
now
we're
in
agreement
right
that
way.
B
I
can
transfer
book
data
to
you
without
putting
it
all
on
chain.
One
final
thing:
here,
that's
kind
of
cool:
sometimes
you
want
to
do
enforcement.
Sometimes
you
want
to
enforce
things
that
happen
in
one
in
one
channel
and
so
something
that
I
can't
dive
deep
into
here,
but
we
have
ways
to
take
partial
information
from
the
off
chain
and
from
the
channel
and
expose
it
in
the
network
chain
code
to
be
able
to
say
this
person
is
hanging
maliciously.
B
I
can't
dive
deep
into
it
here,
but
in
general,
we're
working
on
ways
to
have
some
that,
let
you
enforce
things
by
exposing
very
specific
information.
If
you're,
if
you
want,
it
really
depends
on
the
governance
of
the
network
and
what
that
means.
Like
does
that
mean
you
have
to
pay
sooner
or
anything
like
that
all
right?
I
think
that
was
pretty
technical,
so
I
can
stop
pause
for
a
second,
let's
see
if
anybody
has
questions
you
can
write
them
in
the
chat.
I
think.
A
B
That's
a
great
question,
so
I
can.
I
can
reshare
the
I
can
reshare
the
slide
one
sec
so
in
in
the
networks
that
we
build
right,
we
are.
We
are
usually
working
with
enterprises,
so
this
isn't
a
public
blockchain
network.
There's
no
token
in
the
network.
There's
no
like
something
like
that:
instead,
usually
the
people
who
want
to
run
the
network,
the
miners
are
they're,
not
miners,
they're,
more
like
validators.
B
So
when
we
build
networks,
we
work
with
the
industry
with
large
industry
bodies
or
with
the
enterprises
to
build
a
core
group
of
founding
members
who
are
then
the
anchors
for
the
validation
of
the
network,
so
what
they
get
isn't
money
what
they
get
is
prestige
and
you
know
the
respect
of
the
peers
and
and
political
clout.
Now
we
do
expect
in
the
future,
as
these
networks
mature,
that
they're
made
that
there
may
be
a
cost
right
now
connecting
to
the
network.
Isn't
it
doesn't
cost
a
lot
of
money
right?
B
It's
it's
free,
but
we
do
expect
in
the
future
for
the
networks
themselves
to
charge
price
and
that's
something.
We've
been
talking
to
some
of
the
networks
on
and
then
that
would
be
distributed
to
the
miners
or
the
block
producers.
I
do
want
to
say
from
our
running
of
models:
that'll
pretty
much
cover
the
server
costs,
but
not,
but
not
much
more.
It's
not
something
where
they're
going
to
make
a
crazy
amount
of
money
and
the
reason
is-
and
it's
interesting.
It's
different
than
in
crypto
networks.
B
In
crypto
networks
like
ethereum
and
bitcoin,
miners
need
to
be
an
independent
business,
and
so
they
do
make
some
money
by
the
way
they
don't
make
a
lot
of
money.
The
margin
isn't
that
big,
except
for
maybe
right
now
in
ethereum,
with
all
the
craziness
going
on
of
the
high
of
the
lots
of
the
market
going
up,
but
in
general
mining
isn't
a
very
lucrative
business
in
these
enterprise
networks.
B
You
gain
more
value
from
the
network
existing
by
being
able
to
do
more,
efficient
trans
settlements
by
being
able
to
innovate,
and
it's
less
about
creating
a
business
model
for
the
miners.
For
most
implementations,
the
cost
of
being
a
validator
is
very
small
compared
to
integration,
implementation,
etc,
and
so
companies
do
it
because
they
want
to
be
your
pillars
of
their
community
and
less
about
you
know
specifically
making
money.
Out
of
that.
I
hope
that
answered
your
question
are.
There
is.
B
A
B
All
right
cool,
so
the
diagram
it's
the
top
is
the
shared
chain
code
in
the
network.
The
middle
is
a
channel
between
the
two
or
or
a
chain
code
that
uses
an
implicit
collection
or
starting
up
the
private
collections
and
the
final
one
is
the
off
chain
protocol
and
there's
an
error
that
connects
it
got
deleted
when
I
made
it
bigger
tagging
the
files
in
the
option
protocol
to
that
channel
between
the
two
peers:
okay,
next
up
a
running
in
enterprise
id.
B
So
this
is
all
nice
architecture
and
it's
really
cool,
but
we
still
have
to
run
in
an
enterprise
idea,
environments
and
so
there's
a
bunch
of
challenges
there,
like
working
with
enterprise,
I.t
guys
we're
always
on
vacation.
No,
no,
if
there's
anybody
enterprise
like
you
guys
here,
I
love
your
job.
You
guys
are
awesome,
but
you're,
always
on
vacation
and
also
complying
with
lots
of
things
and
educating,
etc.
But
I
do
want
to
focus
on
two
specific
challenges
that
we
face.
B
One
is
the
one
of
running
on
cloud
or
on-prem,
and
the
other
is
about
networking.
So
when
you
want
to
connect
five
different
enterprises
in
different
geographies
with
different
rules
and
have
them
open
ports,
it's
sometimes
very
difficult.
So
I'll
talk
about
the
first
one
first
running
on
cloud
or
on-prem:
basically,
every
customer
has
their
own
environment,
you
know
might
be
a
different
cloud,
might
be
bare,
metal
might
be,
you
know
their
own
rules
and-
and
they
also
don't
want
to
spend
a
lot
of
time.
B
You
know
on
managing
your
system
right,
it's
a
you're,
not
a
30
million
dollar
sap
implementation,
you,
you
know
you're,
trying
to
help
them
be
efficient,
so
they
don't
want
to
spend.
You
know,
have
five
people
on
a
team,
doing
dba
for
your
system
and
as
a
developer,
it's
challenging
you
don't
always
have
constant
access.
B
You
might
not
have
access
to
your
system
so
the
way
that
we
solve
this
is
we
sort
of
try
to
build
a
little
cloud
inside
the
the
picture
of
a
small
cloud
inside
the
enterprise
environment
and
the
way
we
do
that
is
that
we
use
kubernetes
kubernetes,
as
I'm
sure,
a
lot
of
people
on
this
call
know
it's
an
orchestration
engine
that
lets.
You
run
containers
on
vms
in
a
way
where
you
can
you
basically
tell
it.
B
I
want
five
containers
with
this
image
and
it
spins
them
up
and
handles
networking
and
handles
you
know
alerting
if
they
go
down
et
cetera.
So
it's
a
it's
an
orchestrator,
and
so
what
we
do
is
we
package
our
entire
system
into
this
kubernetes
kubernetes
configuration,
and
then
we
set
up
a
small
cluster
inside
the
customer
environment
and
that's
sort
of
for
us.
It's
like
a
tiny
cloud.
It
means
that
it's
mostly
standard
because
containers
standardize
a
lot
of
things
and
you
can
package
the
os
into
the
container
in
a
nice
way.
It's
self-healing.
B
So
if
things
break,
they
immediately
heal
themselves
to
spin
back
up
and
it's
declarative
configuration
which
is
good
for
us,
as
developers
in
building
the
system,
but
also
good
for
the
enterprise.
I
t,
because
if
they
want
to
understand
how
things
work,
they
can
just
open
the
declaration
and
see.
Oh,
this
is
this
module
that
I
know
about
it's
running
three
times
this
module
is
down.
You
know
they
can
work
with
the
system
in
a
much
better
way
versus
you
know.
Here's
a
server
with
some
processes
in
it.
B
The
way
we
do
it
is
we
take
the
software
like
when
we
take
hyperledger
fabric,
we
build
our
own
custom
images
and
charts
so
charts,
so
we
have
our
own
build
system
that
can
package
it
in
the
right
way
because
we
have
tie-ins
to
secrets
in
the
environment.
So
in
general
we
have
sort
of
our
docker
container
images
that
are
deployed
in
kubernetes
and
run
and
I'll
talk
about
this
a
little
bit
later,
but.
B
B
The
second
thing
is
networking.
So
when
you
build
a
blockchain
network,
you
kind
of
need
everybody
to
open
their
ips
now,
if
it's
a
network
of
five
enterprises
and
find
open
watch
for
each
one.
But
when
you
talk
about
the
type
of
markets,
we're
in
this
we're
talking
about
hundreds
and
thousands
of
organizations
and
in
an
organization
opening
ports
is
difficult.
Opening
forks
to
the
wide
world
without
an
ip
white
list
is
something
that
enterprises
do
not
like
to
do.
B
B
So
we
need
to
find
a
way
to
let
enterprises
open
porch
to
the
world
while
still
complying
with
our
security
and
the
way
we
did
that
is,
we
put
a
we
built,
a
wrapper
that
can
take
that
can
take
a
hyperledger
fabric
and
take
that
and
not
just
fabricate
all
kinds
of
blockchains
and
connect
them
into
tunnel
them
through
a
vpn.
So
we
go
through
open
source
vpns.
B
We
use
openvpn
and
ipsec
which
are
built
into
linux,
and
what
this
lets
enterprises
do
is
say
here,
open
this
ipsec
port
to
the
world
and
here's
how
it's
in
it's
it's
a
vpn,
it's
a
vpn
you're
familiar
with.
You
can
open
the
you
can
open
via
the
linux
machine
right,
it's
it's
transparent
to
you.
You
can
add
new
ip
tables.
If
you
want
inside
this
is
very
native
to
the
itt
team.
They
know
how
to
work
with
it.
B
But
it's
all
you
know
open
source
technology,
but
it
does
create
a
vpn
across
all
the
participants.
And
so,
when
I
want
to
add
a
new
member
to
the
network,
I
just
have
to
give
them
the
vpn
credentials
and
they
can
connect
peer-to-peer,
and
this
is
a
peer-to-peer,
vpn.
There's
no
central
party
there's
just
a
certificate
authority
that
gives
certificates
to
every
party
or
appreciated,
depending
on
the
setup
and
it's
a
peer
to
peer
vpn,
which
aligns
very
well
with
a
decentralized
architecture
of
the
network.
B
B
This
is
a
slide.
I
want
to
show
this
slide.
So
when
we
talk
about
the
clear
node,
the
software
that
we're
building
it
needs
to
interact
with
four
types
of
sort
of
customer
systems,
one
is
applications
or
users
and
that's
going
to
the
mobile
platform
question
we
said
before
so
there's
the
the
uui
where
people
will
use
it
or
the
integration
with
the
business
system
that
the
customer
has.
It
needs
to
work
with
the
customer
data
systems.
So
the
systems
where
the
information
is
stored.
The
events,
the
prices,
you
know,
aggregation
reports,
etc.
B
We
need
to
work
with
other
clear
notes
or
in
the
in
also
other
vendors
implementations.
So
the
off
chain
api
has
to
be
compatible
of
transferring
files
and
transferring
messages,
and
we
need
to
work
with
ledgers
and
again
we
can
work
with
hyperledger
fabric,
but
we
also
need
to
work
with
ledgers
in
the
future
different
versions
of
fabric.
B
You
know
other
ledgers
as
well,
and
so
the
way
that
we
think
about
it
is
that
we
say
we
we
have
this
thing.
You
know
the
clear,
no,
the
clear
software
and
it
has
these
four
interfaces,
four
apis
which
allow
it
to
do
these
different
communications
towards
an
application.
It
uses
objects
like
a
contract,
a
discrepancy,
a
dispute,
a
peer,
a
result,
so
really
business
objects
that
represent
things
in
a
settlement
relationship
and
that's
what
it
exposed.
You
know
towards
the
applications
in
a
websocket
or
a
rest
api
towards
the
customer
data
systems.
B
You
want
an
api
that
says:
here's
a
big
csv
loaded
into
the
systems,
that's
an
api
for
events.
You
can
sell
it.
Here's
a
bunch
of
events.
Here's
new
prices,
you
know
it
might
stream
out
bi.
So
that's
an
api
that
sort
of
eats
in
the
feeds
of
events
that
are
coming
from
the
customer
system
and
is
able
to
process
them
towards
the
other
implementations.
You
want
to
be
able
to
transfer
files
to
transfer
messages,
there's
a
protocol
for
that
and
then
finally,
towards
the
ledgers.
B
Instead
of
being
very
tightly
coupled
to
the
specific
nuances
of
the
ledger,
we
have
sort
of
this
abstraction
layer
which
speaks
in
words
like
channel
and
contract
and
transaction
identity
which
in
hyperlogic
fabric
channel,
is
channel,
but
in
corda
it's
something
different
and
in
ethereum
it's
something.
Different
contract
is
chain
code
instance
in
hyperledger
fabric
in
the
ethereum.
It's
smart
contract
instance
and
then
in
recorded
something
else
and
transactions
tends
to
be
very
similar.
An
identity
may
be
you
know
in
one
it
may
be
a
certificate
and
another
it
might
be
a
public
key.
B
B
So
going
to
the
question
about
exposing
chaincode
apis,
we
don't
expose
the
chaincode
apis
directly
what
we
do
instead,
so
what
we
do
instead,
this
is
different,
say
than
the
app
on
ethereum.
We
have
a
software
that
runs
within
the
enterprise
that
expose
a
different
api
than
the
chain
code
and
therefore
the
app
communicates
with
that
server.
For
example,
we
don't
require
the
end
user
application
to
always
have
public
keys,
it
might
authenticate
with
a
user
and
password
and
then
the
server
would
sign
instead
of
it
right.
B
It
doesn't
translate
one
to
one.
So
the
server
translates
those
transactions
and
the
contracts,
and
that
view
to
a
view
which
speaks
the
language
of
business,
so
contracts,
discrepancies,
peers
results,
etc
to
the
applications.
And
so
then
the
challenge
becomes
not
unique
to
blockchain,
but
it's
more
of
how
do
you
build
a
good
application
api
right?
How
do
you
build
a
good
way
to
expose
your
your
functionality
and
that's
what
we
focus
on
for
the
for
for
that
api?
I
hope
that
answered
that
question.
B
Okay,
the
growing
network,
so
I'm
gonna
this
is,
I
think
this
is
my
last
line.
I
can
answer
more
questions.
What
I
said
till
now
was
pretty
abstract
right.
It
was,
you
know,
examples,
ideas
how
we
do
things
I
do
want
to
give
you
a
little
bit
of
traction
just
so
you
guys
know
that
these
are
lessons
that
are
you
know
in
the
real
world,
our
network
we've.
We
we're
mostly
focusing
on
telecommunications
right
now,
we're
working
with
customers
like
vodafone,
deutsche
telekom,
telefonica
hong
kong
telecom,
pc,
global
and
others.
B
This
isn't
the
full
list,
it's
the
ones
that
I
can
share
here,
and
these
are
all
you
know.
Each
one
of
them
is
a
huge
enterprise
which
runs
their
own
node
with
their
own
private
data.
You
know
dealing
with
all
kinds
of
products
and
we've
deployed
this
same
architecture
in
amazon,
web
services
and
google
cloud
and
vmware
clusters
in
deutsche
telekom's,
open
telecom
cloud
in
bare
metal.
B
So
that
way
we
can
say
you
know,
for
the
kubernetes
stuff,
we're
really
happy
with
it,
because
it
takes
us
the
same
amount
of
time
to
do
each
one
of
these
installations
and
for
us
it
works
almost
the
same
way.
We
give
the
customer
some
requirements
and
we
can
deploy
the
same
scripts.
Everything
runs
in
every
single
one
of
these
environments
and
we're
adding
more
every
day.
So
we're
we're
very
happy
with
that
ability
use
cases.
B
We've
done
are
things
like
mobile
roaming,
interconnect,
voice
and
data
on
demand
and
we're
expanding
more
and
I
can
say
we
support
both
hyperledger
fabric
and
private
ethereum.
So
basically,
this
is
pretty
cool.
We
have
one
ui
one
application
and
the
customer.
The
business
customer
doesn't
even
need
to
know
what
ledger
it
runs
on
and
in
the
future,
we'll
even
let
it
run
on
multiple
ledgers
at
once.
B
So
if
you're
part
of
multiple
networks,
you
don't
have
you'll
have
one
pane
of
glass,
one
ui,
where
you
can
do
settlement
and
dispute
resolution
with
any
customer
in
any
one
of
these
other
ledger
networks.
Anything
that's
pretty
cool
and
we're
also
always
doing
work.
To
add
more
of
these
here,
as
as
the
world
evolves.
B
So
to
summarize
this
is,
I
hope
this
was.
It
was
interesting.
We
sort
of
shared
our
challenges,
building
a
network
that
works
across
the
globe,
different
types
of
I.t
environments,
different
types
of
organizations,
different
types
of
ledgers
and
connects
together
to
really
provide
value
to
the
customers.
B
All
right,
I
see
another
question
about
the
central
authority.
So
that's
another
good
question.
One
of
the
things
that's
interesting
about
our
model
is
that
we,
oh
you
raised
the
question
that
we
we
don't
look
to
be
the
owners
of
the
network,
so
we're
not
selling
people
on
the
network
itself.
We
generally
partner
with
bodies,
like
you
know,
with
industry
bodies
like
the
gsma
or
c-band
in
telecommunications,
or
you
know
in
in
in
different
industries
or
a
different
body,
and
those
and
that's
usually
a
customer
decision.
B
So
there's
places
where
the
customers
say:
hey,
you
guys
run
the
order
for
us
there's
places
where
they
say
you
know
we
want
to
bring
build
an
spv
and
the
sdd
will
run
the
order.
There's
things
that
say
an
industry
body
will
run
the
order.
That's
sort
of
that's
sort
of
something
that
the
network
itself
needs
to
decide.
So
we
work
with
the
customers
to
understand.
A
A
B
So
it
could
be
for
two
farmers.
I
don't
have
much
experience
with
farmer's
it
sacks.
So
I
don't
know.
If
there's
you
can
run
servers
and
tractors,
but
for
large
farming
companies
you
could
do
settlements.
Yes,
we've
actually
done
some
work
and
exploring
this
for
things
like
pharmaceuticals
for
things
like
ip
rights,
so
it's
it's
a
the
system
is
generic.
Adding
new
use
cases
is
very
easy.
The
reason
we've
been
very
focused
in
going
to
market
isn't
because
the
tech
isn't
generic.
B
It's,
because
the
building
a
network
of
enterprises
takes
time,
and
so
you
need
a
critical
mass.
You
need
the
right
people
to
be
part
of
it,
and
so
that
way
we
can
we
can.
We
we
focus
on
places
where
we
can
build
a
network
quickly,
so
we're
starting
with
a
telecom
network
and
we're
also
already
starting
to
build
or
join
networks
and
other
verticals
as
well
stay
tuned.
Let's
talk
again
in
a
year,
and
I
can
tell
you
about
more
of
those
all
right.
B
B
On
top
of
that,
we
have
docker
containers
we're
using
a
typescript
for
the
back
end,
which
is
a
type
of
node.js
with
typing.
We
use
a
react
for
the
front
end.
We
use
hybrid
fabric
and
ethereum
for
the
blockchains.
We
use
rabbitmq
for
queuing
of
long-running
tasks.
We
use
postgres
for
the
database,
but
we
use
it
in
a
nosql
configuration
so
we're
using
it
more
as
a
very
stable
nosql
store
and
less
as
an
sql.
You
know
database
a
relational
one.
We've
been
very
happy
with
that.
B
B
A
lot
we
find
them
very
helpful
both
for
peer-to-peer
and
for
front-end
to
back-end.
We
leverage
cloud
hsms
in
certain
cases
for
for
hsms
those
you
can't
put
in
kubernetes.
You
have
to
use
cloud
ones.
We
make
use
of
kubernetes
secrets
and
stuff
like
that.
Yeah.
I
think
that's
that's
pretty
much
our
tech
stack
in
general.
So
this
is
interesting
because
we're
selling
when
we
come
to
sell
to
an
enterprise
customer
and
get
them
to
join
the
network,
blockchain
is
already
pretty
like,
sometimes
innovative
for
them.
So
we
try
to
make
choices.
B
Other
places
which
are,
I
wouldn't
say,
boring,
but
very
stable
right.
We
try
to
make
choices
that
are
not
necessarily,
you
know,
know
where
well,
okay,
we'll
take
people
taking
postgres,
because
that's
sort
of
like
something
where
people
are
like
yeah.
I
know
that
we're
happy
with
that.
The
worst
case
thing
that
can
happen
to
you
is
you're,
doing
an
architecture
review
with
a
customer,
and
they
say
this
piece
of
this
module.
That's
core
to
your
software.
I've
never
heard
of
it.
I
have
to
put
it
through
approval.
B
B
That's
an
important
thing
for
us
also,
when
you're
handling
hundreds
of
millions
of
dollars,
you
kind
of
want
to
be
very
stable,
and
so
we
try
to
choose
the
things
that
work
and
work
well
and
not
necessarily
the
ones
that
are
the
most
shiny
because
we
need
to
be
stable,
but
we
do
it
without
hurting
our
velocity.
We
can
still
integrate
cutting
edge
things
all
right
how
about
using
an
api
gateway.
B
So
that's
an
interesting
question
because,
most
of
the
times
the
consumers
of
our
apis
are
very
so
it's
either
the
ledger
or
the
other
people
who
are
peer-to-peer
like
the
other
blockchains
or
internal
enterprise
customers.
We
don't.
We
haven't,
found
the
real
big
need
for
an
api
gateway.
That's
separate.
We
sort
of
have
a
layer
inside
our
software
that
serves
like
an
api
game
that
held
authentication
and
rate
limiting,
but
because
the
amount
of
consumers
for
each
thing
isn't
super
big.
B
So
if
this
was
one
big
sas
solution,
we
would
have
to
have
an
api
gateway,
because
people
from
around
the
world
are
accessing
it,
but
because
it's
decentralized
every
instance
its
only
customers
are
the
is,
are
the
people
itself,
so
so
the
company
itself,
and
so
we
don't
have
to
do
an
api
gateway.
It's
something
we'll
consider
as
things
grow,
but
right
now
we
can
handle
with
just
doing
it.
You
know
part
of
the
software
itself.
We
do
use
a
load
balancer
inside
a
cluster,
so
use
traffic.
B
I
forgot
to
say
that
in
the
tech
stack,
we
use
a
traffic
and
we
can
use
that
as
sort
of
a
lightweight
api
gateway,
but
we
don't
need
a
separate
api
where
that's
the
amount
of
users.
Isn't
that
big?
So
there's
no
there's
no
denial
of
server.
We
don't
do
enough
service
protection.
The
rate
limiting
isn't
that
important,
because
most
api
integrations
are
with
a
very
specific
other
party,
except
for
those
peer-to-peer
ones
and
there
we
do
have
more
protections
all
right.
B
B
Be
returning,
I
gotta
make
okay,
sorry.
The
question
goes,
you
mentioned.
Currently
it's
a
private,
only
solution,
but
let's
say
if
the
governing
body
scale
your
solution
and
want
to
mandate
it
under
telecom
authority
of
that
country.
How
are
you
going
to
handle
that
and
the
motivation
for
the
managing
bodies
to
be
managing
the
network?
B
So
those
are
two
different
parts
of
that
question.
I'll
answer
the
second
one.
First,
the
motivation
for
us
for
us
to
work
with
to
let
them
work
is
that
our
promise
one
of
the
things
people
say
when
we
come
and
say
we're
building
this
network.
They
turn
to
us
and
say
you
say
it's
decentralized,
but
you'll,
take
over
everything
and
we
tell
them
no
you're
an
industry.
It's
your
network,
you'll
run
the
orders
you'll
own
the
network.
B
If
you
want
to
bring
in
more
vendors
to
implement
compatible
protocols,
we'll
share
the
specs
with
them.
We
want
to
be
part
of
this
ecosystem.
We
don't
necessarily
want
to
own
it,
and
so
it's
very
important
from
a
go
to
market
perspective
from
a
customer
perspective
about
thinking
about.
You
know
where
this
is
going
to
grow,
that
we
aren't
necessarily
the
people
running
the
whole
thing,
and
so
we
find
the
right
partner
who
has
legitimacy?
Who
is
you
know
known
in
the
market
and
to
be
able
to
run
those
those
things
and
running?
B
The
order
tends
to
be
something
that,
in
people's
mind
means
you
know
you
have
control
of
the
network
in
some
sense
right,
because
if
the
order
is
malicious,
it
can
hurt
the
ordering,
and
so
that's
that's
why
we
do
not
all
of
them
want
to
do
it.
Sometimes
we
do
it,
then,
but
in
general
we
are
trying
to
build
networks
for
industry.
So
in
the
end,
it's
not
a
clear
network
that
you
all
have
to
pay
clear.
It's
an
industry
network
where
we
provide
a
node
into
and
we
help
develop
with
the
industry.
B
So
that's
why
the
managing
body
wants
to
do
it
regarding
a
private,
only
it's
not
exactly
private.
Only
they
tend
to
be
public,
they're
they're
public,
to
an
industry
regarding.
So
I
don't
it's
not
it's
not
it's
not
usually
a
club
of
companies.
It's
usually
they
want
to
roll
it
out.
For
the
entire
world-
and
so
I
don't-
we
don't
think
of
it
private
only,
but
if
somebody
goes
to
a
governing
body
for
a
telecom
authority
in
interesting
in
telecom,
there's
telecom
is
interesting.
That's
in
telecom,
specifically
right.
B
Another
industry
is
different.
The
in
the
the
country,
specific
bodies
have
rules,
but
they
are
aware
of
the
fact
that
it's
a
global
network
right.
The
the
authority
of
eu
can't
tell
the
authority
of
china
or
the
of
us
how
to
run
their
telecoms
operations,
and
so
they
know
how
to
coordinate
with
each
other.
B
You
know
channels
lets
us
be
compliant
of
different
types
of
regulations.
At
the
same
time
now
questions
we
haven't
had
to
deal
with
is
what
happens
if
you
want
to
settle
between
what,
if
at
t,
is
on
the
same
network
as
iran
or
with
north
korea?
We
don't
have
those
problems
yet
we'll
we'll
hit
them,
and
thankfully
we
have
the
people
to
assist
us,
but
in
general
this
is
built
and
structured
to
be
able
to
work
with
to
be
able
to
work
with
global
jurisdictions,
different
regulators
and
we
track.
B
You
know
the
rulings
that
come
out,
but
as
this
is
b2b
commerce,
the
rules
and
regulations
are
more
lightweight.
Rules
tend
to
the
regulations,
tend
to
be
more
about
consumer
interactions
and
so
there's
a
little
bit
more
freedom
here.
I
hope
that
answers
that
question
all
right.
Another
question
is
that
even
applies
to
startups
like
who
are
trying
to
build
a
new
platform
or
provides
blockchain
services
to
use
a
stable
tech
stack,
listen.
This
is
a
little
bit
of
a
philosophical
question.
B
I
think
there's
I
think,
there's
two
things
here
that
that
matter,
one
is:
are
you
a
sas
provider
or
or
do
you
provide
on-prem
stuff
when
it's
sas
people
less?
Can
look
under
your
hood,
and
so
you
can
do
things
that
are
more
cutting
edge
in
that
sense,
not
to
say
that
what
we're
doing
isn't
cutting
edge,
because
we
use
the
tools
that
we
have
in
very
innovative
ways.
We
push
them
to
the
limit.
B
We
can
figure
them
in
really
smart
ways,
but
if
you
are
selling
software,
that's
going
to
be
installed
and
managed
by
a
local
it
team.
They
need
to
know
how
to
run
it.
They
need
to
be
very
stable
right.
They
don't.
They
can't
deal
with
your
app
so
much,
and
so
this
isn't
just
for
blockchain
or
hyperledger
and
from
my
experience
it's
good
to
make
technology
solutions
that
are
ones
that
they
will
be
able
to
be
happy
with.
B
If
you
choose
a
newfangled
database,
that's
nobody
heard
nobody's
heard
of,
or
some
special
orchestrator
that
nobody's
heard
of,
and
then
it
breaks
and
the
id
guy
for
the
customer
doesn't
know
how
to
fix
it.
Then
it's
gonna
be
your
problem,
but
if
you
chose
something,
they
do
know
how
to
fix.
They'd
be
loved,
they'd,
be
happy
to
learn
about
it
and
see
how
you
can
do
it.
B
The
regarding
the
other
thing,
it's
a
philosophical
thing.
This
is
a
blog
post.
I
read
once
every
startup
only
has
limited
resources
and
when
you
and
you
have
an
as
a
cto
of
a
startup,
you
have
like
you
know,
innovation
tokens
doing
anything.
That's
not
standard
costs,
you
attention
and
energy.
Now
you
only
have
so
many
of
these.
So
if
you
use
mysql
the
standard
things,
but
it's
there's
lots
of
documentation
stack
overflow
has
lots
of
information.
B
Then
you're
going
to
spend
all
your
time
on
this
new
technology
which
may
may
be
better,
but
not
necessarily
good
enough,
because
you're
spending,
all
the
energy
fixing
it
so
from
our
experience,
choosing
proven
but
very
well
maintained
and
and
fast
software
brings
a
blend
that
lets
us
focus
on
features
and
on
customers
and
not
on
our
weird
database
broke,
and
so
in
general,
it's
advice.
Not
just
about
blockchain,
but
in
general,
when
you're
a
startup,
you're
really
tempted
to
say
you
know,
I
was
stuck
in
this
corporate
job.
B
I
had
to
do
things
by
the
book
now
I
can
do
whatever
I
want.
You
should
probably
whatever
you
want
us
to
still
choose
very
stable
technology,
doesn't
mean
to
choose
a
mainframe
than
kobol,
but
to
choose
things
that
have
been
around
for
a
few
years
and
have
a
good
community
so
that
you
can
focus
on
building
your
product
and
not
your
tech
stack
right.
B
Okay.
Another
question
I
may
have
missed
this
earlier:
is
your
solution
interoperable
as
of
now
any
link
for
the
tech
documentation?
So
our
solution
is
that
it
doesn't
currently
interoperate
with
other
vendors.
The
reason
is
that
there
aren't
currently
any
other
vendor
solutions
on
the
market
that
are
ones
where
we
can
operate
with.
We
are
in
touch
with
a
bunch
of
them
and
as
they
bring
their
products
to
market,
we
will
integrate
and
build
with
them
and
connect
with
them.
B
We
are
involved
in
the
telecom
world
and
standards
being
written
in
a
body
called
cbn
in
in
where
you
collaborate
also
with
the
gsma
who's,
doing
work
on
standards
for
this,
and
so
not
yet,
but
soon
regarding
documentation,
that's
a
good
question.
We
made
the
decision
to
not
release
the
documentation
yet
as
the
target.
B
This
is
for
documentary
so
for
apis
to
use
our
platform,
if
you're
a
customer
we'll
share
that
with
you,
but
for
interoperability,
because
until
there
are
other
vendors
who
are
building
systems
being
able
to
be
flexible
in
the
protocols
is
helpful
for
us,
so
we
can
change
them
quickly.
We
can
innovate
rapidly.
We
can
change
things
and
we
can
learn.
We've
already
learned
many
things.
So
if
we
had
a
standard
api
out,
we
would
have
to
comply.
They
could
be
compatible
with
that.
What
we're
doing
is
we're
if
you.
B
Or
if
other
vendors
are
as
they
build
products,
we
usually
reach
out
to
them
and
say:
let's
connect
our
products
together
and,
as
we've
been
pretty
early
to
the
market,
there
aren't
that
many
yet,
but
more
are
coming
and
it's
up
to
them
to
say,
and
we
will
work
with
them
and
share.
You
know
the
chain
code
and
the
protocols
to
be
able
to
connect
them
together,
as
we
believe
it
will
be
stronger
with
multiple
vendors
than
with
one
now.
B
A
Time
yeah,
so
we
will
have
to
ask
people
to
those
watching
and
those
watching
live.
If
you
have
any
more
questions,
please
reach
out
to
me
or
gal,
just
a
couple,
more
slides
from
my
side.
I
wanted
to
remind
you
about
the
the
fact
that
this
is
a
series.
It's
not
a
one-off,
so
over
the
next
two
wednesdays,
we
will
have
a
hyperledger
web
web.
Fifa
ledger
labs
webinars,
it's
a
mouthful
for
those
of
you
who
don't
know.
A
So
the
two
upcoming
ones
will
be
one
about
mimi
fabric,
which
is
an
introduction
to
fabric
mini
fabric,
which
is
an
app
that
our
tools
allows
you
to
stand
up
and
build
your
fabric
networks
in
a
pretty
easy
way,
and
then
another
one
will
be
on
hyperledger
umbra,
which
it
talks
about
the
challenges
with
hyperledger
fabric
simulations
and
developing
your
applications
and
how
umbra
is
trying
to
tackle
it.
So
I'm
pretty
excited
because
these
seem
to
be
a
more
more
technical
talks,
but
also
very
hands-on
ones.
A
So
I'm
I'm
hoping
you
can
all
join
me.
If
you
would
like
some
more
sessions,
we
still
have
our
recordings
from
hyperledger
global
forum,
and
there
are
over
400.
There
were
over
450
attendees.
We
had
over
90
sessions.
All
of
them
are
recorded
and
available
on
our
youtube
channel,
where
you
will
also
find
the
presentation
that
we
had
today
and
finally,
please
get
involved.
We
really
want
to
hear
from
you.
We
really
want
you
to
start
participating
in
our
community.