►
From YouTube: Hyperledger Netherlands Meetup - April 21, 2020
Description
A virtual Hyperledger meetup hosted by Hyperledger Netherlands focused on how Hyperledger is being used in the telecom industry featuring Alfonso de la Rocha from Telefónica and Andreas Sommerwerk at Deutsche Telekom.
More details about the event are at:
https://www.meetup.com/Hyperledger-Netherlands/events/270038490/
----
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 #HyperledgerMeetups #Blockchain
A
We're
good
to
go
all
right,
recording
perfect,
so
welcome
everyone
and
welcome
to
another
hyper
ledger:
Netherlands
webinar!
My
name
is
Rudolph
and
I'm,
the
founder
of
BC
NL.
This
announce
the
community
for
blockchain,
crypto
and
ELT
startups
and
scallops
in
the
Netherlands,
and
we
are
the
official
community
leader,
fiber
ledger
in
the
Netherlands
I
hope
you're
doing
well.
A
In
these
hectic
times,
though,
and
we
managed
to
adapt
to
the
new
social
distant
society,
this
event
is
part
of
a
webinar
series
and
in
this
series
we
provide
you
with
relevant
talk
from
blockchain
entrepreneurs
and
experts
on
several
use.
Cases
and
industries
well
make
sure
to
sign
up
for
those
webinars
and
they
will
be
shared
by
all
media
channels.
So
today
we
will
dive
into
hyper
ledger.
Telco
use
cases
with
Telefonica
and
Deutsche
Telekom
got
some
important
notes.
The
session
takes
around
one
hour
and
will
be
recorded
as
set.
A
A
B
B
Now
you,
you
can
see
it
right.
Yes,
okay,
so
hello,
everyone,
my
name
is
Loretta,
as
shrewd
oaf
said,
I'm
from
telefónica.
Actually,
today,
I'm
gonna
share
a
talk
that
I
prepare
for
the
room,
but
I
didn't
have
the
chance
to
go
there.
So
I
said:
okay,
we
had
I
mean
we're
going
to
talk
about
going
into
production
and
performance
best
practices
with
hybrid
a
fabric.
We
did
a
performance
evaluation
of
fabric
that
we
wanted
to
share
with
the
community.
B
B
Weekly
newsletter
is
where
you
will
find
the
in-depth
articles
of
the
results
we
reach
from
this
performance
evaluation,
but
I
will
do
an
overview,
an
overview
here
today
so
I'm
here
to
tell
you
a
story
and
it's
the
story
of
how
we
tried
and
we
succeeded
to
move
hyper
little
fabric
or
a
hyper
light.
Your
fabric
network
into
productions,
huge.
B
As
I
was
saying,
we
started
as
I
think
everyone
started
with
hyper
data
fabric.
We
went
to
the
building
building
your
first
network
documentation
of
Hyperallergic
fabric.
We
had
any
deal
of
use
case
that
could
make
sense
using
fabric,
and
we
said:
okay,
let's
start
building
it,
so
we
set
up
our
first
network.
We
implemented
our
chain
cons,
we
did
our
application
and
it
was
all
great
I
mean
we
were
in
PLC.
B
We
were
having
test
users,
everything
was
working
fine,
but
when
we
moved
into
production
with
real
users
is
when
things
started
to
break
and
the
load
was
increasing,
our
stress
was
also
increasing
and
we
started.
We
were
starting
I
mean
we
started
to
wonder
several
things
here.
So,
first
of
all,
we
didn't
know
how
much
load
could
our
hyper
the
fabric
network
in
our
infrastructure
support,
and
it
was-
we
was
really
comfortable.
We
didn't
know
how
many
peers
to
to
put
in
our
network.
We
didn't
know
how
to
scale
our
infrastructure.
B
I
mean
we
end
up
succeeding
with
this
use
case,
and
we
have
even
more
know
that
we
were
accommodating.
How
would
we
scale
the
infrastructure?
We
didn't
know
if
we
were
implementing
the
SDK
correctly
or
if
we
thanked
our
chain
code
correctly.
We
have
been
with
high
loads
something
weird
called
MVCC
conflict
errors,
MVCC
fountain
compute
error.
B
So
we
said
what
the
we
don't
know
what
is
happening
under
the
hood
with
high
load,
and
this
is
the
reason
why
we
jumped
in
and
started
our
own
performance
evaluation
of
hyper
edge
of
fabric,
because
we
wanted
to
know
several
things.
First,
how?
Where
were
the
bottlenecks
in
hybrid
America?
How
to
appeal
to
production?
B
B
B
Even-
and
we
wanted
to
know
how
much
it
cost,
because,
as
I've
said,
it
will
have
unlimited
hardware,
we
just
host
a
networking
in
a
huge
cluster
and
that's
it,
but
we
didn't
have
unlimited
I
mean
we
have
it,
but
we
didn't
want
for
a
cost
model.
We
didn't
want
to
have
unlimited
hardware
and
such
that
we
wanted
to
do
the
evaluation
in
a
real
environment,
and
you
may
be
wondering
by
now.
Okay,
you
are
talking
about
an
application
that
you
moved
into
production.
What
is
this
application
so?
B
To
give
you
a
bit
of
context,
this
is
what
we
were
trying
to
move
into
production,
that
is
telefónica
stress
toys
in
the
interest.
Os
is
an
abstraction
layer
for
DLT
networks
so
that
anyone
can
build
a
fabric
based
or
a
DLT
based
application,
just
with
some
knowledge
of
web
development
without
having
to
know
about
transaction
blocks,
cryptography
and
so
on,
and
these
are
some
of
the
models
we
have
already
in
production
in
our
trust
to
us
and
the
core
engine
of
this
trust.
Us
product
is
a
hyper
ledger
fabric
network.
B
Actually,
another
reason
why
we
started
our
own
performance
evaluation
is
because
we
were
changing
a
bit
the
approach
we
followed
around
fabric
because
usually-
and
you
may
have
seen
already
applications
of
hype-
a
lot
of
fabric
that
are
I
really
specific
for
the
use
case.
So
you
build
a
network,
a
specific
for
the
use
case
to
be
hosted
in
that
in
that
infrastructure,
but
in
our
case,
as
I've,
said,
we're
trying
to
accommodate
many
application
over
the
network
of
many
developers.
B
So
what
we
wanted
to
do
is
a
performance
evaluation
of
a
dynamic,
multi-client
general-purpose
network.
That
is
the
one
that
that
telefónica
trust
West
uses
in
this
type
of
network.
All
the
members
can
interact
with
janko's
deployed
their
own
applications,
so
we
didn't,
we
couldn't
expect
a
specific
load
for
the
network
and
that
that
was
why
this
was
a
really
dynamic
environment
for
the
experiments.
What
we
did
is
I
mean
all
the
tests
we
did
were
over
hyper
at
the
fabric
I'm
pulling
for
one
point.
Four
point:
four
will
scale
the
number
of
peers.
B
We
tried
with
different
data
bases
for
the
ordering
service
we
used
raft
with
different
number
of
orders.
All
of
these
was
hosted
over
a
kubernetes
cluster,
measured
using
from
fuse
and
the
load
was
generating.
You
generated,
the
user
load
was
generated
for
the
test
using
that
and
one
last
piece
here
is
the
hf
service
that
you
see
here
so
instead
of
using
in
order
for
for
our
trust
to
us.
Instead
of
using
the
fabric
sdk
from
scratch
for
each
application,
we
abstracted
the
functionality
of
the
sdk
in
a
client
that
we
call
the
hf
service.
B
So
we
didn't
really
know
where
to
start
of
course,
so
we
wanted
to
see
where,
where
the
bottlenecks,
but
we
didn't
know
where
to
start
so.
The
first
thing
we
did
was
to
divide
the
hyper.
Let
your
fabric
stack
into
these
five
layers,
the
infrastructure
that
is
the
underlying
infrastructure
that
hosts
the
physical
resources
that
hosts
the
hyper
little
fabric
network,
their
architecture
that
we
refer
to
this
when
we
I
mean
this
is
the
topology
of
the
hyper
ledger
fabric
network,
the
number
of
nodes,
the
number
of
orders,
the
databases
we
used.
B
B
But
in
our
case,
as
we
want
it
to
be
in
production,
it
will
cease
you
to
to
host
it
in
in
coordinators,
for
our
operational
team
and
I've
said
that
you
start,
if
you
don't
have
enough
resources,
you
start
facing
weird
errors,
and-
and
this
is
a
fun
example
of
what
happened
to
us-
we
were
doing
some
tests
over
a
topology
where
we
weren't
giving
enough
resources
to
our
peers.
So
we
started
with
high
loads.
We
started
getting
this
error.
Peers
were
throwing
TLS
handshakes
arrows
and
we
were
saying
okay.
What
is
happening?
B
I
mean
we.
We
have
our
TLS
certificates
correctly
configured,
our
communications
are
working.
So
what
is
happening
and
the
problem
was
that
peers
were
running
out
of
CPU,
so
they
weren't
even
even
able
of
doing
the
TLS
handshake.
So
these
are
some
of
the
weird
errors
you
may
be
facing.
If
you
don't
have
enough
resources
for
your
for
your
network,
you
may
be
wondering
ok,
so
how
can
I
come?
How
can
I
calculate
the
number
of
resources
or
the
number
of
CPUs
I
need
to
accommodate
my
my
topology?
B
So
that's
what
we
answered
in
the
architecture
lab,
so
we
said:
ok,
how
I
mean
we.
We
tried
with
a
lot
of
different
topologies
with
different
number
of
endorsing
peers,
different
number
of
orders
we
played
with
the
CAS.
We
did
a
lot
of
things
because
we
wanted
to
understand
the
computational
profile
of
each
of
the
entities
of
a
hyper
edge
of
fabric
network
and
what
we
realize
here
is
first,
if
we
want
to
scale
our
infrastructure,
we
want
to
have
a
high
transaction
throughput
in
our
infrastructure.
B
We
need
to
scale
in
the
number
of
endorsing
peers
and
in
the
number
of
channels
or
and
or
in
the
number
of
channels,
because
the
more
anderson
peers
we
have
on
the
more
channels
we
have
in
our
infrastructure,
the
better
performance
we
will
have
in
our
network.
Of
course,
we
have
to
bear
in
mind
that
we
have
to
always
have
enough
physical
resources
to
accommodate
this
topology.
So
the
more
endorsing
peers
we
have
the
more
CPUs
we
will
need
in
our
underlying
infrastructure.
B
So,
with
this
in
mind,
we
we
answer
one
of
our
our
worry
that
it
was
how
to
scale
and
infrastructure.
If
we
scale
in
the
number
of
of
transactions
per
second
in
our
system,
then
related
to
the
orders
on
the
CA
I
mean
they
are
not
as
intensive
in
time
in
terms
of
CPU,
so
we
shouldn't
worry
that
much
I
mean
we
saw
some
cases
in
which
you
should
worry,
but
we
shouldn't
worry
that
much
about
them.
So
we
have
to
worry
about
channels
and
endorsing
fears
and
having
enough
resources
to
accommodate
that
topology.
B
B
It
depends
on
on
your
specific
use
case
because,
for
instance,
for
our
operational
team,
they
told
us
that
they
were
more
comfortable
with
CouchDB,
because
they
knew
how
to
manage
databases
and
for
high
availability,
it's
easier
to
manage
the
CouchDB
than
a
little
DB.
But,
of
course,
if
you
have,
if
you
want
high
performance
and
write
a
lot
of
in
the
ledger,
go
for
CouchDB,
because
it
would
give
sorry
for
level
DB
because
it
will
give
you
better
performance.
B
B
B
So
that's
why
we
just
messed
around
with
the
configuration
in
order
to
to
see
what
was
best
for
performance
and
a
few
things
here.
The
version
of
hybrid
fabric
that
you
use
will
definitely
affect
the
performance.
As
I've
said,
we,
our
test,
wear
with
fabric.
One
point
four
point
four,
but
if
you
go
down
to
one
point,
three
you'll
see
that
every
new
version
has
a
performance
improvement,
the
best
way
of
checking
what
has
been
included
in
each
in
each
version
or
what
to
expect
is
to
go
to
fabrics
dear.
B
They
are
I
mean
everything
is
really
well
documented
and
you
have
a
lot
of
information
of.
Why
are
they
have
plants
related
to
performance?
Also,
you
can
go
to
their
release,
notes
here,
for
instance,
in
the
release
notes
of
fabric
2.0.
We
already
see
some
changes
that
may
improve
our
performance,
so
that
I
mean
we
have
to
do
tests
again
with
2.0
to
see
how
better
it
gets
with
peace
with
these
changes.
B
But
what
I'm
saying
here
is
be
careful:
the
version
of
fabric
you
use
because
it
will,
it
will
affect
your
your
network
performance
and
in
the
protocol
we
didn't.
As
I've
said,
we
didn't
modify
anything
we
just
messed
around
with
with
configuration
and
some
of
our
learners
where
the
following
first
validating
signatures
is
an
expensive
operation
in
the
transaction
lifecycle.
B
So
if
you
use
endorsement
policies
as
far
as
you
can
use
the
less
parties
involved
as
possible
in
order
to
have
a
high
throughput,
because
if
not
I
mean
the
more
signatures
you
need
to
check,
the
I
mean
the
performance
will
be
worse
for
its
new
each
new
signature.
We
played
with
with
a
number
of
threats
underlying
infrastructure
we
find
in
calcdp.
B
All
of
these
is
in
the
in
some
of
the
papers
that
I
mentioned
above
so
I
mean
they
also
played
with
these
configurations
to
improve
performance
and
another
configuration
that
actually
gave
us
good
results
for
us.
Considering
that
we
didn't,
we
couldn't
expect,
and
we
couldn't
predict
that
they
load
we
would
have
in
our
network-
was
the
block
size,
the
number
of
transactions
per
block
and,
and
they
cut
time
out
of
the
block
for
us
for
two
seconds
and
ten
transactions
per
block.
B
So
that's
all
for
the
protocol.
Then
we
started
evaluating
our
Cheng
Coast
and
how
we
designed
Cheng
codes
and,
let's
be
honest,
when
we
started
with
our
PLC,
we
thought
that
we
were
doing
a
great
job
here
in
Jenkins
and
nothing
further
from
the
truth.
We
were
a
bottleneck
in
our
use
case
because
we
loadouts
everything
seemed
to
to
work.
But
then,
when
we
move
to
two
hollows,
we
had
to
refactor
all
our
codes
and
the
learnings
I
can
share
with
you.
B
Here
is,
first
of
all,
used
in
boats
and
queries
in
a
smart
way
and
as
atomic
as
possible
because
of
course
evokes
using
boats
whenever
you
have
to
write
in
the
ledger,
because
it
goes
to
the
order
and
they
are
way
slower
than
queries.
So
you
square
it's
only
when
you
have
to
read
from
the
ledger
in
boats
when
you
have
to
write
from
the
ledger
and
try
not
to
mix
them.
B
Use
them
as
atomic
as
possible
in
your
chain
called
functions,
because
in
that
way
you
will
you
will
get
the
better
performance
and
the
second
learning-
and
this
is
one
of
the
most
important
ones
in
this
layer-
is
to
avoid
MVCC
conflicts.
As
I've
said,
when
we
were
testing
with
high
loads
and
with
the
old,
not
refactor,
chain
codes.
We
were
facing
this
error
because
two
transactions
were
trying
to
modify
the
same
value.
B
B
As
I've
said,
one
of
the
of
the
key
problems
when
you
design
your
chain
box
in
order
to
be
performant
is
to
avoid
MVCC
conflict.
We
did
a
lot
of
research
around
MVCC
conflict.
Fortunately
this
is
an
issue
that
data
in
the
database
field
and
in
the
design
of
database
system
they
have
already
faced,
and
we
I
mean,
if
you're
interested
in
this.
B
So
one
of
the
things
we
did
in
order
to
see
all
of
these
and
to
evaluate
the
performance
of
our
changes
was
to
profile
our
chain
codes
using
T
proof.
So
what
we
did
is
take
the
take
our
goal
line
chain
codes
and
and
profile
them
as
if
it
was
a
golden
standard
along
in
order
to
realize
what
was
happening.
B
Things
were
going
fine
in
the
TOC,
but
then
when
we
moved
into
production
and
with
high
loss-
and
we
started
our
benchmark,
we
realized
that
we
were
making
some
mistakes
when
we
designed
our
SDK
and
some
things
that
we
learned
is
first
I,
wear
the
SDK
points
or
what
entity
in
the
network,
the
SDK
points
or
the
transaction
lifecycle
matters
for
performance.
I
tried
to
point
with
your
SDK
an
endorser
peer
or
ant
the
master
order.
B
But
our
problem
was
that
with
high-lows,
this
worked
fine
with
in
the
TOC,
but
with
high-lows,
the
common
user
context
were
being
messed
up
and
mixed,
and
we
weren't
like
following
the
transaction
lifecycle
correctly
so
I
mean
it
probably
makes
no
sense.
Now,
if
you
haven't
played
with
the
fabric
SDK,
but
once
you
read
the
documentation,
we
use
plans
for
the
same
user
with
cached
context
in
order
to
avoid
many
many
errors,
and
this
is
all
in
one
last
thing
when
I
said
the
one-to-one
SDK
mapping.
B
This
is
what
I
was
referring
to,
so
we
have
to
understand
peers
in
this
example,
we
would
have
to
as
the
case
and
a
load
balancer
before
balancing
the
load
between
the
different
endorsing
tiers.
With
this
approach,
it
was
the
one
that
with
which
we
got
the
best
performance,
so
we
really
recommend
this
topology
in
order
to
get
the
most
out
of
your
infrastructure,
and
we
was
all
that
I
wanted
to
share
with
you.
I
went
pretty
quickly
because
it
was
a
really
dense
work
and
we
did
a
lot
of
work
with
this
again.
B
If
you're
interested
we
published
throughout
the
last
month,
a
few
articles
on
a
series
were
we
go
in
in
detail
of
all
the
tests
we
did
and
all
our
learnings
and
from
all
this
from
all
this
experience,
what
we
can
get
is
I
mean
I
leave
you
with
this
message,
get
ready
for
blood
chaining
production,
because
it
was
a
hard
quest,
but
blockchain
is
getting
ready.
Step
by
step
is
getting
ready
to
be
employed
in
production.
So,
thank
you
very
much
and
that's
all
thanks.
A
C
So
yeah,
my
name
is
andreas
I
work
in
DT
Telecom
in
the
Innovation
Lab
in
Berlin
and
I'm
part
of
the
blockchain
team
there
and
leading
the
caracal
doctrine
activities.
So
we
have
various
virtual
activities
there
and
the
technical
ones
are
the
ones
that
I
would
like
to
talk
to
you
about
in
coming
minutes.
C
So
my
background
is
not
riteca.
Kalaiy
have
service
design
background,
and
so
my
role
is
to
match
the
requirements
of
the
business
to
the
possibilities
of
technology.
So
the
presentation
has
a
bit
of
a
different
focus
that
then
from
to
compare
to
our
phone
service
but
I
think
it
it's
a
good
to
go
a
complement
because
it's
less
technical
and
more
focusing
on
a
business
proposition
and
business
use
case.
So.
C
C
That
is
the
customer
facing
process.
It's
pretty
easy,
you
get
out
of
the
plane
and
you
can
use
your
phone
anywhere
around
the
globe,
but
behind
that,
of
course,
there
is
also
a
business
process
and
there
is
also,
of
course,
money
flowing
between
the
operators,
so
even
in
the
European
Union,
where
we
don't
pay
any
more
for
for
roaming
as
as
end-customers
there's
still
money
moving
being
moved
around
on
between
the
operators.
So
on
that
level-
and
this
is
what
our
project
is
focusing
on-
because
you
can
imagine-
there
is
a
lot
of.
C
C
Those
are
basically
just
yeah
monetary
values
that
assigned
to
the
different
services.
So
you
say:
okay,
we
agree
on
one
cent,
mobile
call
to
certain
destinations
or
certain
amount
of
money
for
mobile
data
and
text
messages
and
so
forth.
So
this
is
what
you
do
in
the
beginning,
mostly
on
a
yearly
basis.
C
So
there
is
different,
probably
won't
go
into
the
details,
even
as
different
problems
which,
with
each
of
these
process
steps.
So
one
thing
that
really
surprised
me
when
I
started
working
on
the
topic
is
that
the
contracts
are
all
paper-based.
So
even
though
we
vary
due
to
a
company,
these
contracts
are
actually
printed
out,
sign
and
then
sent.
We
are
snail
mail
around
the
globe
and
then
a
couple
of
weeks
later
you
get
the
contract
back
signed.
So
it's
a
very,
very
old-fashioned
process.
C
C
Being
tracked
only
on
one
side
and
these
discrepancies
need
to
be
discussed-
and
this
is
also
a
lot
of
manual
work,
sometimes
also
wrong
rates
are
being
a
play
applied,
because
the
rates
that
have
been
agreed
on
in
the
contracts
not
in
in
this
have
not
been
implemented
into
the
systems.
So
there's
a
lot
of
problems
that
arise
due
to
the
complexity
of
the
process
and
also
the
inefficiency
that
you
have
in
every
of
those
process
steps.
C
So
what
we
said
is
okay
for
for
fast
results.
We
start
with
the
contracts,
because
it's
not
too
many
I
mean
400
contracts
per
year
and
then
some
signatures.
So
that's
a
couple
of
hundred
transactions
on
a
blockchain
per
year,
so
this
means
we
won't
run
into
yes
problems
here.
Also,
the
amount
of
data
is
not
huge.
I
mean
is
a
contract
that
has
some
information
on
prices.
C
Pricing
that
that's
all
so
we
thought
we
on
the
safe
side
here
when
it
comes
to
number
of
transactions
and
data
volumes,
and
also
we
were
basically
working
on
a
process
where
there
were
no
legacy
systems,
because
you
had
everything
on
paper,
you
did
not
did
not
need
to
interact
with
legacy
systems,
as
you
usually
would
have
to
do
in
any
type
of
context.
So
it's
why
we
said:
okay,
let's
start
just
with
the
contracts
to
see
if
we
can
make
it
work
just
for
the
contracts
in
the
beginning.
So
it's
more
or.
C
Project
that
we
started
with
so,
but
still,
even
though
it's
just
one
part
of
the
process,
we
see
that
there
are
already
results
that
help
us
shape
the
process
in
a
more
efficient
way.
So
we
are
moving
from
something
that
is
time-consuming
and
error-prone
and
pen-and-paper
manual
to
something
that
is
fast,
reliable,
secure
and
transparent.
When
we
work.
C
So
the
last
step
is
our
next
step
in
the
development,
because
the
volume
tracking
is
probably
the
hardest
track
step
to
take
due
to
the
amount
of
data,
as
you
couldn't
imagine,
and
also
the
complexity
that
lies
behind
it,
because
there's
a
lot
of
different
data
formats,
so
there's
no
standard
for
that.
So
this
is
why
we
kept
this
as
the
as
the
last
step.
C
So
one
of
the
key
learnings
that
I
made
during
this
process
is
that
when
you
do
a
project
like
this,
so
you
say:
okay,
we
want
to
see.
Is
this
actually
working
in
as
a
business
process?
For
us
most
of
the
time
you
are
not
feeling
so
much
with
blockchain
technology,
but
you
deal
with
a
lot
of
other
stuff,
so
the
governance
legal,
your
act
stated
protection
system
and
integration,
data,
routing
and
and
the
like.
C
So
this
is
what
takes
up
most
of
the
time
of
the
of
the
team,
exactly
so
talking
to
lawyers
and
and
regulators
and
and
so
forth,
and
and
of
course,
if
you
connect
to
to
another
operator,
then
most
of
the
time
you're
discussing
how
you're
getting
through
firewalls
and
stuff
and
not
so
much
how
how
the
blockchain
actually
works.
So
this
is
a
probably
an
interesting
insight.
C
So
also
what
you
have
to
think
about
is
the
legal
framework,
because
I
mean
it's
nice
to
have
some
kind
of
prototype
where
you
can
simulate
contracts,
but
we
wanted
to
go
all
the
way.
So
we
wanted
to
see
if
we
can
actually
make
this
something
legally
valid
between
operators,
and
so
what
we
did
just
is
a
brief
description
here
is
that
we
split
up
the
current
paper
contract
into
two
parts.
So
you
see
that
there
is
a
framework
agreement
that
we
did.
C
C
So
this
is
the
the
legal
construction
that
that
we
agreed
on
and
then
what
you
have
is
you
have
the
bear
commercial
conditions
which
you
can,
which
you
first
put
into
an
excel
sheet,
so
that
we
can
actually
see
what
is
required
by
the
commercial
department,
because
Excel
is
is
the
tool
that
they
work
with.
Of
course,
then
we
translated
it
into
a
machine,
readable
JSON
file,
and
this
is
what
goes
as
a
hash
onto
the
onto
the
actual
blockchain.
C
So
we
select
the
topology
of
fabric
for
various
reasons.
Probably
the
most
important
reason
for
us
was
that
there
is
a
inbuilt
CA,
so
you
know
who
is
doing
what
on
the
network,
which
is
very
important
from
a
legal
point
of
view,
because
you
need
to
be
sure
that
a
contract
is
signed
by
the
right
organization
so
by
your
by
the
actual
entity
that
you
are
dealing
with
and
also
by
the
right
person
inside
the
organization's.
C
So
there's
signing
regulations
and
rules
in
place
in
all
larger
companies,
so,
depending
on
the
volume
of
the
contract,
only
certain
people
can
sign
a
contract
so
and
hyperedge
of
fabric
is
the
right
technology
to
keep
track
on
that.
So
this
is.
This
was
one
reason
beside
the
many
other
reasons
so
that
it's
open
source
it's
secure
and
that
there
is
a
rather
high
transaction,
throughput
and
and
so
forth
that
that
we
probably
all
know
so.
This
is
just
a
glimpse
of
how
I
mean
it's
just
a
UI
for
the
contract
managers.
C
So,
of
course,
as
this
is
something
that
you
do
with
the
partner
operators.
We
are
also
involved
partners
here
and
also
the
GSMA
as
this
standardization
body
of
the
mobile
communications
industry,
and
we
are
actually
working
in
a
working
group
also
with
friends
from
telefónica
and
six
other
operators
to
actually
standardize
this
as
a
solution
and
to
build
the
first
inter
operator
block
chain
network
for
the
wholesale
roaming.
C
Les,
we
also
have
a
t-mobile
us
on
board,
which
is
our
partner
company
in
North
America.
So
again,
also
the
you
can
imagine
that
the
partnering
is
something
that
is
that
we
need
to
do,
but
that
also
brings
further
complexities
to
the
discussions,
because
every
operator
has
their
own
views,
but
one
consensus
that
has
been
reached
and
now
therefore,
for
example,
is
that
for
the
first
prototypes
that
we
are
building
together,
we
also
will
be
also
using
a
high
branch
of
fabric.
C
So
I
think
we
are
on
a
good
way
here
to
actually
work
together
with
with
the
GSMA
to
create
something
that
is
going
to
be
the
industry
standard
in
the
future.
Also
forward-looking.
We
see
that
there
is
more
use
cases
in
the
telco
area,
so
roaming
is
just
one
fixed
voice,
data
on
demand
and
fibre
to
the
home.
A
A
B
The
answer
is
no,
but
to
be
honest,
this
is
something
that
we
have
to
check,
because
our
networks
were
short
living
I
mean
we
did
our
tests.
We
did
different
topologies
of
networks
and
our
production
network
has
been
on
for
six
months
now,
so
we
don't
know
if
this
would
be
an
issue.
Apparently
it
won't
be
an
issue.
We
were
thinking
about
way
of
ways
of
fixing
it
if
this
comes
to
be
an
issue,
but
I
cannot
give
you
a
specific
answer
because
I
don't
know:
okay,.
B
Okay,
so
I
think
they
shared
already
the
my
newsletter.
That's
what
we
have
for
now,
but
I
mean
we're
planning
to
generate
more
documentation.
This
is
an
ongoing
work.
I
mean
we
are
already
doing.
Other
I
mean
we
will
start
doing
some
tests
over
fabric
2.0.
We
want
to
test
things
that
we
left
behind,
because
our
deadline
was
the
high
political
forum
to
give
a
first
bunch
of
results.
But
of
course
our
network
is
now
in
production.
We
are
facing
other
issues
and
we
will
most
probably
generate
more
more
content.
B
I
can
I
mean
I
can
give
you
my
newsletter,
you
have
my
social
network
and
I
can
give
you
the
links
of
my
team
also,
and
you
can
contact
any
of
us
and
we
will
keep
you
updated.
We
are
constantly
updating
with
with
information
we
find
with
interesting
content,
and
we
will
definitely
generate
more
content
with
the
test.
We
are
ongoing
right
now
with
hyperbaric
2.0,
perfect.
A
Perfect
gum
less.
Thank
you
for
sharing
the
newsletter.
Martin
Luther
has
a
question
as
well
for
Alfonzo.
Do
you
have
any
comment
on
the
stability?
Is
there
given
enough
CPU
for
endorsing
beers?
Is
that
question
clear
enough
for
the
smart,
a
I
want
to
add
something
to
that?
He
can
clear
it
a
bit.
It.
C
B
That's
a
really
good
question,
so
it
depends
on
the
chain.
Code
is
true
that
our
channels
have
been
really
tested
already,
so
we're
not
facing
these
problems
anymore,
but
in
development.
This
is
something
we
face,
so
I
mean
wrong
request
to
the
chain
code
or
a
lot
of
load
into
a
single
function.
We
face
some
problems
in
which
the
chain
code
failed
and
it
made
the
whole
pier
fail
with
high
loads
and
also
when,
when
there
were
problems
like
MVCC,
a
lot
of
MVCC
conflicts
could
make
the
chain
code
fail.
B
So
that's
why
I
stressed
to
have
really
well
implemented
the
channels
and
the
design
in
order
to
avoid
these
kind
of
problems,
because
we
even
tried
to
have
chain
codes
as
system
chain
codes,
and
these
was
a
problem
also
because
every
single
mistake
made
the
because
we
thought
that
okay,
this
could
make
sense
in
order
to
have
a
better
performance.
But
every
single
mistake
made
the
pier
come
down,
so
we
had
to
be
really
careful.
So,
in
the
end
it
so
comes
to
the
stability
comes
to
the
to
the
stability
of
your
chambers.
I'll,
say.
A
C
C
C
But
so
the
the
front
end
template
that
you
seem
so.
The
UI
is
a
very
straightforward
UI,
and
this
is
not
so
I
mean
this
is
not
the
focus
after
of
the
project.
The
focus
really
was
how
how
to
ensure,
also
from
a
legal
perspective
that
we
can
digitize
contracts,
and
you
can
only
do
it
with
blockchain,
in
fact,
because
if
you
need
to
prove
later
on
that
a
certain
transaction
in
our
case
is
a
signature
or
contract
information
is
actually
the
one
that
you
agreed
on.
C
A
And
it
hardly
also
answers
the
question
of
Rahul
asking:
why
did
you
decide
to
use
blockchain
to
solve
this
use
case?
It
looks
like
you
are
really
solving
issues,
because
the
use
case
whatnot
was
not
digitized
and
was
based
on
paper
processes
that
could
have
been
done
using
existing
technology
stacks.
Would
you
like
to
respond
to
that?
Yes,.
C
So
I,
don't
I,
don't
know
which
stack
would
be
suitable
for
that,
given
the
legal
requirements
that
you
are
having,
so
you
are
I
mean
in
these
transactions
are
worth
a
couple
of
million
US
dollars
euros
whatever.
So
you
need
to
be
pretty
sure
that
what
you
are
signing
and
what
you're
creating
is
not
being
tampered
with.
So
this
is
why
we
think
doctrine
is
the
right
technology.
Oh.
A
B
Great
question,
and
actually
yes,
we
investigated
I
mean
we
called
it.
Layered
I
mean
if
you
see
the
content
we
shared,
and
maybe
we
should
go
in
depth
with
this.
We
called
them
layer,
2
infrastructure,
and
we
follow
different
approaches
based
on
on
on
message
queues
and
also
in
the
events
that
hyper
let
your
fabric
infrastructure
and
the
chain
codes
it
gives
you.
This
is
something
that
we're
still
evaluating
because
we
are
evaluating
if
it's
better,
to
have
a
batch
approach.
B
We
try
to
beef
MQTT,
and
so
this
is
something
I
cannot
give
you
a
specific
answer.
This
is
something
we're
exploring.
We
are
seeing,
for
instance,
in
we
have.
We
follow
an
approach
that
even
in
the
papers,
they
call
a
fire-and-forget
approach
in
which
you
just
throw
the
transaction
forget
about
it
and
then
get
the
event
to
know
the
results,
and
this
is
giving
us
really
good
results,
but
I
wouldn't
be
able
to
tell
you
a
specific
broker
that
it
creative,
because
we
tried
with
right
now
with
Redis
and
with
mqtt.
B
A
B
Yes,
we
did
the
valuation
at
different
layers
because
of
this
actually
to
understand
what
was
the
bottleneck
at
different
layers
and,
of
course
it
doesn't
matter.
If
you
have
I
mean
if
you
have
an
endorsement
policy,
that
is
it's
delaying
the
infrastructure.
It
doesn't
matter
the
amount
of
Anderson
peers
and
of
as
the
case
that
you
put,
because
the
bottom
leg
will
be
the
endorsing
policy.
B
But
if
you
I
mean,
of
course,
if
in
your
organization's
have
more
endorsing
peers
all
the
organizations,
you
will
have
a
better
throughput,
but
in
the
end,
if
there's
a
bottleneck
in
the
endorsement
policy,
the
you
won't
fix
it
with
more
education,
more
sand
or
Spears.
As
long
as
you
don't
have
the
same
replication
in
all
the
organization's.
A
C
C
So
yeah
the
governance
consortium
question
is
something
that
arises
a
lot
of
course,
and
we
are
very
lucky
that
we
have
the
GSMA
as
standardization
body
in
the
mobile
communications
industry.
So
what
we
are
envisioning
is
that
the
GSMA
will
be
leading
the
consortium
and
also
will
be
governing
blockchain
network
actually.
So
this
is
our
way
forward.
Yeah,
and
this
second
question
about
the
business
case
is
well.
C
The
host
a
roaming
process
is
quite
complicated
and
it's
going
to
get
even
more
complicated
in
the
future,
because
you
have
new
services
like
IOT
and
5g
coming
up,
and
you
have
third
parties
that
are
involved,
data,
clearing
houses
and
the
less
you
are
depending
on
seller
parties.
The
more
you
can,
of
course,
also
reduce
your
costs.
So
this
is
the
in
very
simple
terms.
Now
is
the
business
logic
behind
it,
so
you
are
reducing
your
internal
and
external
cost.
If
you
make
the
process
more
efficient
and
digitize,
it.
C
We
have
the
group
in
place
with
the
eight
operators
that
I
mentioned.
These
operators
are
committed
to
bring
in
their
resources
and
we
already
made
the
first
step.
So
we
agreed
on
on
kind
of
a
roadmap
forward,
so
the
architecture,
the
technology
that
we
want
to
use.
So,
as
I
said,
for
the
first
steps
is
going
to
be
hyper
edge
of
fabric,
and
so
we
do
this
step
by
step.
But
I
guess
we
are
not
on
a
good
way
to
to
move
forward
here
together.
C
Well,
the
lesson
on
it:
first,
you
need
to
you
need
to
find
a
governing
body.
Of
course.
One
way
to
do
it
would
be
a
completely
democratic
approach
so
that
you
say:
okay,
for
example,
if
you
do
a
chain
code
upgrade,
and
you
need
a
majority
that
approves
it
and
so
forth,
which
makes
the
process
probably
very
slow
if
you
have
a
couple
of
hundred
operators,
for
example,
and
IT
departments
involved.
So
this
is
why
we
said:
okay,
no,
we
probably
need
one
governing
neutral
governing
body
there.
C
A
B
Actually,
a
really
suitable
question,
because
tomorrow,
hopefully
in
the
log
of
we
had
a
lot
of
trouble
with,
as
I
said,
we
have
a
dynamic
multi-purpose,
general-purpose
multi-client
network,
so
identity
seemed
in
high
pressure
fabric
are
pretty
strict
with
certificates.
So
that's
why
we
built
one
of
all
the
models
we
built
in
in
the
trust
OS.
It's
a
trust
ID.
That
is
an
a
decentralized
identity
approach
for
high
polish
fabric.
B
Hopefully,
tomorrow
we
will
share
in
the
haplotype
block
what
we've
done,
and
what
we
do
here
is
that
we
follow
a
similar
approach
of
the
simplest
identity
where
we
can
be
the
custodian.
So,
yes,
we
have
to
store
your
service
or
you
can
be
that
your
own
custodian,
but
following
a
decentralized
identity
approach,
so
that
you
don't
have
to
be
forced
to
belong
to
an
organization
in
order
to
interact
with
the
hybrid
fabric
network.
So
the
answer
is
yes,
we
do
Kasturi,
oh
and
tomorrow.
A
Thanks
so
much
and
and
thanks
everyone
for
for
these
great
questions,
I'm
sorry,
we
cannot
answer
all
of
them,
so
please
feel
free
to
leave
questions
at
the
the
meetup
page
itself.
I
will
try
to
forward
them
and
you
can
always
directly
contact
any
one
of
us
in
particular
thanks.
So
much
andreas
and
Alfonso
for
sharing
your
your
insights
and
experience
is
very
relevant
for
us.
So
thank
you
so
much
and
also
David
from
the
Linux
Foundation
for
hosting
su
trance,
yeah
and
Rudolf.
Thank
you
for
organizing
this
and
running
it
great
yeah.