►
Description
Setting up a DLT network in a production-scale environment is not straightforward. It is complex and time consuming process with a huge learning curve. Therefore, when Blockchain developers are asked to use an unfamiliar DLT platform, it requires a great deal of effort for even experienced technicians to properly setup the DLT network. This is especially true in large-scale production projects across heterogeneous corporate environments which require other key aspects such as security and service availability.
BAF helps in simplifying this by providing a framework to automatically deploy by just taking a single configuration file as input. Hyperledger Member company, Accenture, implemented it for Hyperledger Fabric , Indy and Besu. This will be a technical presentation with a demo.
----
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
So
so,
thank
you
all.
I'm
extremely
excited
to
be
here
and
share
more
about
what
we've
been
doing
with
the
blockchain
automation
framework
and
hyperledger
labs.
I
I
think
we'll
we'll
be
sharing
a
bit
of
the
journey.
How
do
we
get
here
and
and
some
other
pieces
about
what,
how
we
view
the
the
landscape
of
the
various
different
dlt
frameworks,
but
before
that
we
do
that?
Let's
do
a
quick
intro,
so
my
name
is
michael
klein.
A
I
lead
our
blockchain
and
multi-party
systems,
architecture
group
globally
within
accenture,
I'm
responsible
for
for
the
blockchain
automation
framework,
as
well
as
hyperledger
cactus,
and
our
contributions
there
and
the
number
of
other
technology
assets
that
we
have
at
accenture
superajit.
Would
you
like
to
give
a
quick
update,
yeah.
B
A
Yep
well,
like
I
said,
we're
excited
to
be
here,
but
before
I
start
talking
about
blockchain
and
dlt,
I
did
want
to
share
a
little
bit
of
our
point
of
view
from
accenture
and
how
we
look
at
the
the
changing
space
of
data
within
organizations
and
and
first
off,
when
we
look
at
the
the
the
our
clients
and
our
customers
of
how
they
are
taking,
making
different
changes
and
making
different
choices.
In
this
era
of
a
pandemic
and
the
need
to
be
more
virtual.
A
We're
seeing
a
lot
more
drive
towards
digital,
virtual
and
cloud-based
services,
and
we
think,
there's
a
real
opportunity
for
our
clients
and
our
customers
to
be
thinking
about
not
just
their
their
journey
to
the
cloud.
How
do
they
become
more
virtual,
but
also?
How
can
they
take
advantage
of
new
ways
of
sharing
data
and
and
actually
maximizing
their
investments,
and
these
shifts
towards
cloud
platforms
in
a
way
that
allows
them
to
better
collaborate
and
tear
down
the
corporate
firewalls
between
organizations?
A
How
can
they
collaborate
better
with
their
partners
and
and
change
the
way
in
which
they're
sharing
data
and
and
what
what
we
really
mean
by
this
is
what-
and
this
is
sort
of
the
foundation
of
this
idea
of
multi-party
systems
versus
just
blockchain.
Looking
at
there's
many
different
ways
in
which
we
can
share
data,
many
different
patterns-
and,
I
think
all
are
valid,
as
we
really
try
to
break
down
these
data
silos
that
have
evolved
over
the
past.
A
A
How
do
we
actually
bring
multiple
organizations
together
to
agree
on
a
shared
strategy
and
governance,
a
shared
operating
m
model
and
platform,
but
also
how
does
this
ecosystem
grow?
How
does
it
sustain
itself
and
grow
over
time
and
have
a
way
in
which
it
can
operate,
where
that
shared
value
can
be
unlocked
for
all
participants?
A
I
think
we
often
talk
about
this
as
the
the
side.
Yes,
we
need
to
solve
that
in
the
technology
space,
but
what
we
see
when
we
go
implement
this
with
a
number
of
very
large
organizations
that
this
is
the
hardest
part
of
multi-party
systems
is
actually
getting
the
right
governance
operating
model
and
and
growth
model
for
that
to
be
a
sustainable
model
to
actually
support
the
need
for
the
technology,
and
so
that
ecosystem
comes
first.
A
A
A
But
the
ability
to
actually
share
data
in
a
common,
consistent
state
is
is
also
another
option
and
then
what
what
is
fundamentally
new
and
what
came
in
in
the
advent
of
blockchain?
Is
this
idea
of
sharing
assets
having
uniquely
digital
objects
that
can
be
shared
between
multiple
custodians
and
asset
holders?
And
you
can
prove
with
through
the
technology
that
us
that
that
digital
object
is
unique
and
that's
that's
something
a
unique
feature
of
a
distributed
ledger,
especially
as
it
relates
to
distributed
systems.
A
A
A
We
should
have
a
standard
way
that
this
integrates
with
the
rest
of
the
technology
stack
when
we
look
at
a
full
production
implementation.
What
are
all
the
capabilities
that
would
be
necessary
in
order
to
deliver
a
full
solution
for
a
customer,
so
we
we've,
we
developed
this
and
it
was
quite
quite
complete.
As
far
as
we
could
we're
concerned,
we
had
a
lot
of
success
for
it,
but
our
developers
and
our
technical
people
wanted
more.
They
said
well,
these
are.
A
This
is
a
lot
of
nice
slides,
but
how
do
I
actually
go
implement
this?
How
do
I
have
consistency?
How
can
we
accelerate
the
deployment
and
make
this
easier
for
everyone,
and
so
some
of
those
we
said?
Well,
we
we
want
to
turn
that
reference
architecture
into
something
physical.
So
we
started
looking
at
the
landscape
and
saying
well
what
are
the
common
challenges
across
all
of
our
different
customers
and
all
of
our
different
projects?
A
What
are
those
things
that
we
really
want
to
try
to
solve,
and
so,
when
we,
when
we
sort
of
scoured
the
landscape,
we
talked
to
a
lot
of
people
and
we
had
a
few
common
concerns
right
and
number
one
of
those
was
no
reuse
of
assets,
so
we're
building
something
new
for
every
single
implementation
and
it
feels
unnecessary.
Why
do
we
keep
on
rebuilding
from
scratch?
A
It's
expensive
and
hard,
and
I
think
for
people
who've
been
in
the
blockchain
space
for
a
while.
You
understand
that
you
know
developing
your
applications
themselves
is
not
actually
the
hard
part
in
the
technology
space.
It's
actually
administering
all
the
different
nodes
and
getting
everything
to
stand
up
and
talk
to
one
another,
especially
if
you're
dealing
with
firewalls
and
other
sort
of
complex
things
that
you
need
to
poke
holes
in
in
the
networking
space
and
getting
all
of
your
tls
certificates
and
everything
to
connect
right.
It's
hard
and
complicated.
A
The
applications
tend
to
tend
to
be
quite
a
bit
easier
in
scale.
So
it's
hard
to
get
these
things
rolled
out
the
there's
technology
silos
and
vendor
lock-in.
So
we
see
a
lot
of
solutions
out
of
the
marketplace
where
the
focus
is
trying
to
capture
a
certain
market
right,
and
so
what
that
does
is
in
the
space
of
where
we're
trying
to
build
ecosystems.
A
It's
creating
pockets
of
innovation
and
trying
to
say
everything
should
be
done
in
this
specific
technology,
and
we
wanted
to
avoid
that
as
much
as
possible
and
then
that
we
saw
a
high
risk
of
selecting
the
wrong
platform.
That's
actually
foundational
to
how
we,
you
know
the
foundations
of
how
we
came
up
with
hyperledger
cactus
as
well,
and
and
then
we
saw
that
there
weren't
established
best
practices,
so
that
conformance
with
the
dlt
reference
architecture
was
not
necessarily
easy
to
do
right.
A
That
brings
us
the
blockchain
automation
framework,
so
really
what
blockchain
automation
framework
started
as
with
an
accenture,
and
this
was
started
about
2018-
is
this
idea
of
how
do
we
take
that
you
know
high-level
reference
architecture
and
make
it
physical?
How
can
we
give
all
of
our
people
within
our
organization
the
ability
to
have
a
consistent
way
to
deploy
blockchain
and
dlt
platforms,
and
I'm
also
cheat
so
recover?
What
is
blockchain
automation
so
veggie?
What
is
it
yep.
B
So
that's
that's
the
ones
and
in
one
sentence,
if
I
have
to
define
it
so
on
it
on
a
high
level
or
on
a
nutshell,
if
you
have
to
look
at
what
that
does.
Is
that,
as
as
you
see
here
in
the
image
that
it
kind
of
takes
a
single
configuration
file,
so
this
configuration
file
kind
of
consists
of
various
network
configurations
such
as
the
dlt
platform
of
choice,
your
consensus
mechanism,
choice
or
and
other
organization
details
and
their
configuration.
B
So
there
is
no
lock-in
with
a
particular
configuration
tool
or
or
a
cloud
provider
and
in
the
later
slides,
we'll
also
talk
about
some
of
the
components
of
of
the
automation
and
and
how
these
are
kind
of
designed
in
a
modular
way,
so
most
of
the
components
or
modules
in
in
bav,
using
black
buffer
kind
of
plug
for
plug-in
and
play.
So
you
can
choose
your
modules
and
components
and
use
that
also.
B
B
We
kind
of
have
open
sourced
blockchain
our
path
with
hyperledger
labs.
So
what
we
have
open
sourced
is
our
automation,
deployment
components.
We
have
also
principles
our
reference
architecture
and
documentations.
We
have
also
open
source
the
supply
chain,
ref
app
and
it's
all
available
under
the
link
which
is
on
your
flight
yeah.
B
A
And
I
just
want
to
jump
in
and
point
out
the
a
little
bit
more
of
our
open
source
rationale,
so
we
we
built
this
this
in
within
accenture,
and
we
saw
a
lot
of
value
right.
We're
already
capturing
a
lot
of
value
by
reusing
this
across
a
number
of
our
of
our
customers.
But
what
is
really
the
one
of
the
biggest
rationales
for
us
to
make
this
open
source
is
the
fact
that
ip
concerns,
especially
when
building
an
ecosystem,
are
very
real
and
for
anyone
who's
participated
in
consortium
building.
A
Well,
we'll
probably
you
know
second,
that
opinion.
How
do
you
actually
agree
upon
who
owns
these
assets?
And
you
know
the
goal,
like
I
said
at
the
beginning,
with
blockchain
automation
framework
wasn't
to
try
to
lock
in
right.
Our
goal
wasn't
trying
to
lock
in
is
actually
trying
to
accelerate
these
discussions,
and-
and
if
we
got
into
a
conversation
about
who
owns
the
ip
around
this
type
of
automation
framework,
it
doesn't
actually
accelerate
in
true
implementation.
A
What
it
actually
does
is
hinder
because
we
get
into
conversations
about
who
owns
the
ip
and
whatnot
and
that's
the
exact
opposite
of
what
we
wanted
to
do
so
by
open
sourcing,
blockchain,
authentication
framework.
We
made
that
ip
concern,
essentially
a
moot
point
we
said
look.
This
is
not
something
that
we're
even
trying
to
commercialize.
A
We
want
you
to
have
the
same
rights
to
this,
this
set
of
code
that
we
do
and
and
that
you
can
contribute
to
it
as
you
see
fit,
or
you
can
do
just
take
it
and
run,
and
then
what
we
want
to
do
is
make
this
easier
and
more
accessible
for
everyone.
So
we
can
have
confidence
in
this
in
the
underlying
platform
and
architecture
that
we're
building
upon.
I
think
that
that
has
been
it's
actually
been
such
of
a
relief.
A
So
I'll
talk
a
little
bit
here
and
sumig.
Please
please
jump
in
here
about
the
various
components
of
the
the
blacksmith
automation
framework.
We
mentioned
that
it
sort
of
starts
with
kubernetes,
so
one
of
the
principles
is
we
want
to
be
cloud
agnostic.
We
want
this
to
run
on
every
cloud.
Kubernetes
is
everywhere,
but
that
really
provides
the
abstraction
layer
for
us
to
say
we
can
run
this
on-prem.
We
can
run
this
in
any
cloud
and
fundamentally
it
doesn't
change
our
platform
much.
A
A
Next,
we
wanted
to
really
focus
on
production,
and
so
when
we
think
about
production,
what
does
it
mean
to
operate
in
production?
We
need
to
change
things.
We
need
to
keep
track
of
how
things
change
over
time
and
we're
a
big
fan
of
the
get
ops
approach
of.
How
do
you
maintain
infrastructure
and
platforms
through
code
and
have
that
be
a
declarative
type
function
versus
a
procedural
function,
to
maintain
your
operations
and
and
doing
that
all
from
get
at
the
get-go?
A
Pun
is
really
a
great
a
great
way
to
do
that,
and
so
looking
at
what's
out,
there
there's
other
ways
to
do
this,
but
we
did
choose
flux
as
the
kubernetes
operator
for
effectively
making
sure
whatever
we
have
and
get
as
our
configuration
for
these
environments
be
guaranteed
to
match
what's
deployed
in
kubernetes.
In
fact,
we
don't
even
encourage
other
than
looking
at
logs
and
sort
of
checking
that
things
are
working,
that
anyone
even
uses
cube
control
right.
A
The
idea
is,
all
configuration
for
our
deployments
is
done
through
through
git
and
and
flux
automatically
applies.
Those
changes
for
us
into
the
environment
ensures
a
consistency,
the
deployment
between
what's
in
get
and
what's
in
in
kubernetes,
we
have
helm
as
the
the
the
way
in
which
we
do
that
right,
so
home
is
executed
via
flux
to
actually
deploy
the
the
platforms
into
the
the
the
pods
and
containers
running
on
kubernetes,
and
so
these
are.
A
This
is
our
set
of
instructions
for
how
we
actually
deploy
within
the
the
kubernetes
environment,
and
then
we
use
and
sorry
I'm
jumping
around
in
no
particular
order
here
on
the
slide.
But
then
we
actually
use
ansible
as
a
configuration
management
management.
Now
for
people
who
are
familiar
with
the
ansible,
you
may
say
well,
ansible
can
actually
do
deployments
and
it
can
do
a
lot
of
other
things
and
oftentimes.
It's
used
to
manage
infrastructure
and
make
sure
that
all
the
infrastructure
has
all
the
right
matches
applied.
A
That's
not
actually
how
we're
using
it
in
baf
baf
is
uses
ansible
purely
to
take
a
single
configuration
file
and
turn
it
into
many
helm
value
files.
That's
really
what
it's
doing.
It's
it's
being
used
strictly
as
a
configuration
management
tool
to
simplify,
instead
of
having
to
create
hundreds
of
configuration
files
across
all
the
different
home
packages
and
releases.
It
may
not
be
100,
I'm
exaggerating,
but
to
keep
that
simple
for
the
users.
A
A
A
The
reason
why
we
like
default
is
number
one:
it's
it's
open
source,
but
also
it
provides
some
abstraction
from
the
underlying
infrastructure
if
we
want
to
replace
it
with
other
key
management
solutions.
Corp
fault
has
integrations
with
many,
but
also
has
the
ability
to
to
be
fairly
easy,
swapped
out,
as
well
with
other
solutions.
B
A
Okay,
well,
I
think,
as
we
we
jump
in
here,
this
is
going
back
to
our
reference
architecture
and
maps
in
how
does
baf
actually
help
implement
our
reference
architecture
that
that
we
showed
sort
of
at
the
beginning
of
our
slides
super
g.
Do
you
want
to
sort
of
explain
how
our
baf
solves
or
doesn't
solve
certain
aspects
of
the
reference
architecture.
B
Yeah
sure
so
I
mean
just
kind
of
to
make
the
audience
understand
what
what
you're
seeing
right
now
is
I'll
just
go
through
the
legends
which
you
have
so
the
blue
ones.
What
you
see
here,
on
the
left
hand,
side,
is
kind
of
your
deployment
and
operation
architecture.
The
green
side
is
basically
your
runtime
or
execution
architecture.
B
B
B
Also
in
delivery
management,
we
have
read
the
docs,
which
is
our
our
documentation
or
where
we
maintain
our
documentation
documentation,
so
that
is
also
being
open
sourced
on
the
execution
architecture
or
the
green
side.
What
you
see
is
that
an
integration
service
we
have
ambassador
so
ambassador
is
basically
our
ingress
service,
which
is
kind
of
used.
For
let's
say
we
want
to
do
a
multi-cluster
communication
or
communication
between
various
components.
B
Currently,
in
dlt
platforms,
as
you
see
here,
we
support
corda.
We
support
hyperledger,
bishou,
indie
fabric
and
quran
as
well.
So
that's
from
the
dlt
part,
yes,
and
just
one
more
thing
is
that
if
you
look
at
your
security
services
on
the
left-hand
side,
you'll
see
that
some
of
them
are
kind
of
like,
for
example.
If
I
look
if
I
kind
of
talk
about
the
certificate
authorities
here
here,
it
is
kind
of
dependent
on
the
client
or
the
customer
options.
B
A
Just
add
in
one
one
more
thing
here:
this
is
a
picture
of
a
single
organization,
but
you
know
this
is
blockchain
automation
framework
started
with
what
does
it
take
to
do
production
implementation,
and
then
we
worked
backwards
to
the
automation
and
so
fundamental
to
how
we
designed
this
is.
This
is
actually
this
picture
is
actually
replicated
for
every
organization.
Every
company.
A
A
One
of
the
core
principles
here
is:
is
we're
not
trying
to
make
this
quick
and
easy
for
a
developer
to
run
their
code
on
what
we're
trying
to
do
is
make
it
quick
and
easy
for
an
ecosystem
to
deploy
a
blockchain
network
across
multiple
organizations,
and
those
are
two
different
problem
spaces,
and
why,
for
some
people
who
may
have
tried
out
baf
in
the
past
as
a
developer,
felt
that
is
a
bit
more
complicated
or
more?
I
didn't
work
well
on
minicube.
Well,
it
wasn't
designed
for
that
right.
C
A
Yeah
great
question:
we
are
currently
not
focused
on
adding
more
platforms.
You
do
see
the
grayed
out
distributed
databases
on
the
slide
here
and
we
were
looking
at
that
and
still
continue
to
keep
an
eye
on
it.
As
I
talked
about
our
multi-party
systems
strategy
right,
the
fact
that
there's
a
lot
of
ways
we
can
solve,
but
most
of
it's
been
on
our
customer
demand,
so
we're
not
actually
looking
to
add
from
our
point
of
view
more
platforms
at
this
point
in
time.
A
If
we
did
have
a
need-
and
we
see
a
rise
in
other
places-
definitely
would
and
we
would
love
others
who
think
there's
value
in
blockchain
automation
framework
to
contribute
their
own
platforms
into
the
code
base
as
well.
So
no
no,
no
concerns
there
right
now.
What
we
really
wanted
to
do
is
focus
more
on
the
operational
components
of
the
ledgers
we
already
have.
A
I
mean
we
have
five
six
sort
of
if
you
count
quarter
enterprise
and
there's
a
lot
to
do,
to
actually
make
those
more
operable
like
what,
if
we
want
to
do
in-place
upgrades
of
fabric
from
version
1.4
to
2.2
right.
That
is
something
we
want
to
have
some
support
for
and-
and
I
just
threw
out
that
one
in
random,
but
we
want
to
start
making
these
that
we
have
a
bit
more
operable
and
build
in
some
more
automation
for
these
specific
platforms.
A
A
Okay,
so
now
now
we
get
to
the
real
technical
stuff,
we're
gonna,
you
know,
lift
the
hood
back.
Let's
say
how
does
this
actually
work
when
we
get
into
the
specific
platforms
and
then
we'll
talk
a
little
bit
more
about
what
this
means,
but
sufiji,
do
you
want
to
walk
us
through
sir?
How?
How
does
this
work
for
fabric.
B
Right
mike
so
I
mean,
as
mike
you
kind
of
said,
that
that
we
are
kind
of
opening
the
up,
the
hood.
So
when
we
talked
about
how
baff
uses
a
single
configuration,
file
and
kind
of
deploys
the
various
components
on
a
on
a
kubernetes
cluster,
so
the
exact
flow
kind
of
happened
same
and
it's
consistent
across
all
the
dlts.
B
So
I
mean
for
what
you
see
on
the
slide
is
particularly
for
a
hyperledger
fabric,
and
so
the
automation
here
starts
from
a
developer
on
an
operator
putting
a
single
configuration
file.
So
this
configuration
file
is
consumed
or
or
taken
as
an
input
by
the
our
master
playbook,
which
is
which
is
which
is
a
playbook
enhanceable
so,
and
the
ansible
kind
of
contains
all
the
rules
and
tasks.
So
as
you
see
here
in
the
box,
the
various
rules
and
tasks
are
like.
B
B
So
the
work
of
ansible
here
is,
as
mike
has
already
kind
of
mentioned
in
the
previous
slides,
that
it
breaks
it
into
multiple
configurations
which
are
then
becomes
an
input
as
a
helm,
value
files
to
the
helm
so
and
this
kind
of
happens
and
is
managed
via
the
github
so
or
or
or
the
flux.
Basically,
so
all
all
the
value
files
management
and
the
operation
around
that
is
not
done
directly
by
ansible.
It
kind
of
this
flux
keeps
a
sync
of
whatever
new
configurations
has
been
approved
and
via
the
helm.
B
It
applies
it
to
kubernetes.
So,
on
the
helm
side,
you'll
see
that
all
the
various
kind
of
deployments
or
the
components
which
a
dlt
network
in
this
case
fabric
would
require
require,
are
provided
so,
for
example,
various
membership
service
providers.
The
period
nodes,
as
well
as
the
order
configuration
with
various
consensus
mechanism,
kafka
raft,
as
well
as
various
channel
management
like
creation
of
a
channel
joining
of
a
channel.
All
those
features
are
part
of
the
helm,
helm,
charts
or
helm
configuration.
B
B
A
Yeah
yeah,
I
think
you
know
what
may
be
helpful
is
we
can
sort
of
talk
about
experiences
with
with
fabric
and
using
this
a
little
bit,
and
you
know
I
think,
back
in
2000
wow
was
it
18,
2000,
maybe
or
even
early
19?
We
we
started
doing
we.
We
started
implementing
this
with
some
customers
and
one
of
our
first
customers,
which
was
a
large
internet
technology
company
who
wanted
us
to
implement
this
on
on
google
cloud
platform.
A
And
so,
while
our
development
team
has
done
all
of
our
work
on
aws,
the
the
the
first
actual
implementation
was
was
on
gcp
and
what
was
really
interesting
about
that
is.
Is
you
know
we
took
the
the
source
code
as
it
was.
We
weren't
we
hadn't
even
open
sourced
yet,
but
it's
still
very,
very
early
stages,
but
the
team
took
what
we
had
and
used
it
as
the
basis
of
their
implementation
with
a
customer
and
what
was
really
great
about
that
is.
A
We
got
to
see
how
it
got
used
right
and
we
were
able
to
incorporate
feedback
of
what
worked
and
what
didn't
and
actually
start
to
incorporate
some
of
the
things
that
they
added
to
the
platform
back
into
the
core,
and
I
think
you
know
that
was
really
interesting.
While
we
don't
test
on
gcp,
currently
as
a
dev
team,
we
just
you
know,
cost
of
infrastructure
the
the
ability
to
know
that
it
did
work
and
it
worked
almost
seamlessly.
A
There
was
not
too
much
that
needed
to
be
done
to
get
it
to
work
was
was
sort
of
a
validation
there,
and
this
was
back
in
the
early
stages
and
then
we've
also
implemented
this
at
a
large
media
company
and
we
what
was
interesting
there
is
that
this
was
a
media
company
looking
to
build
a
loyalty
platform
right.
They
wanted
to
build
a
loyalty
platform
across
multiple
of
their
media
states,
so
they
wanted
to
exchange
these
points
across
a
number
of
their
different
partners
and
what
they
wanted
was
fabric.
A
A
We
said
great,
we
can
do
that
as
well,
and
what
we
did
there
is.
We
actually
replaced
hash
corp
vault
with
a
azure
key
vault.
I
think
I
got
the
right
name,
yeah,
so
replaced
it
with
azure
key
vault,
and
we
did-
and
it
worked
very
well
that
that
that
change
was
you
know
a
week
or
so
of
developer
effort.
A
B
A
A
B
B
So
so,
if
I
have
to
talk
about
some
of
the
images,
some
of
them
were
officially
available
by
carda
some
of
them,
we
had
to
kind
of
build
and
create
so,
for
example,
the
architecture
around
the
core
enterprise
firewall,
also
how
the
hierarchy
of
these
services
will
be
deployed
in
the
network
so
based
on
those
architectural
or
the
process.
I
mean
process
definition
or
or
how
we
kind
of
thought
that
we'll
create
based
on
that.
We
we
have
to
have
to
change
and
design
our
roles
and
and
our
charts.
B
So
mostly
the
the
differences
here,
I
would
say,
is
on
the
on
the
features
that
that
are
currently
put
into
the
particular
dlt
architecture.
So
the
way
how
how
we
have
to
connect
our
nodes
and
how
the
sequence
of
the
various
services,
for
example,
in
quarter
enterprise,
we
have
the
cnm,
which
is
which
is
the
core
to
the
network.
So
those
things
we
have
to
take
care
and
have
to
kind
of
create
in
a
in
a
different
way.
A
A
You
can
also
then
layer
on
hyper
electric
cactus
in
a
future
world
in
a
future
state
that
would
actually
allow
you
to
interoperate
across
all
these
different
dlt
networks
as
well.
So
you
can
have
one
platform
to
actually
deploy
and
manage
the
dlt
networks
and
then
another
framework,
another
hyperledger
framework
to
actually
integrate
those
different
dlt
networks
and
and
and
so
what?
A
I'm
an
architect,
I
fully
understand,
there's
trade-offs
when
we
do
that
and
a
whole
bunch
of
other
things
that
come
into
play.
But
if
you
start
to
think
about
how
we
bring
the
hyperledger
greenhouse
together
and
how
do
we
bring
just
this
this
consistency
of?
How
can
we
all
work
together
across
different
ecosystems?
A
This
is
really
a
big
focus
of
ours
and
just
trying
to
make
it
easier
for
everyone
to
do
that
and
allow
the
entire
marketplace
to
accelerate
and
move
faster,
yeah
I'll.
Let
you
speak
a
little
bit
more
to
vegeta
about.
Is
there
anything
you
want
to
highlight,
as
it
relates
to
hyper
ledger
indie,
obviously,
a
very
different
platform
focused
on
identity
and
then
really
what's
intended
to
do.
Were
there
any
sort
of
challenges
you
had
or
differences
as
we
as
we
implemented
indie
versus
some
of
these
more
general
purpose,
dlt
platforms.
B
Right
so
for
indie,
in
fact,
we
kind
of
if
I
have
to
look
back
and
see
there
were
a
couple
of
challenges,
particularly
regarding
the
indie
key
management.
So
we
there
was
no
out
of
box
solution,
provided
so
we
had
to
kind
of
manage
that
ourselves.
We
created
an
image
and
we
are
using
it
for
all
the
key
management.
B
B
So
those
kind
of
things
we
have
to
take
care
of,
we
had
to
think
out
of
box
solutions
and
kind
of,
in
fact,
had
to
configure
our
ambassador
to
support
those
things
and
yeah
overall
in
terms
of
general
flow-wise
and
consistent
way
of
deployment.
It
remains
the
same
but
yeah
and
we
have
to
configure
or
create
some
features
or
charts
very
specific
to
the
requirement
and
and
the
limitations
of
particular
dlt
network.
A
Thank
you,
yeah,
and
I
think
for
people
who
aren't
familiar
with
indie
just
understanding
that,
indeed,
is
just
a
small
part
of
the
decentralized
identity
story.
Right,
there's,
there's
aries
and
a
lot
more
of
the
functionality
is
actually
built
into
the
wallet
where
the
people
have
control
over
their
own
identity.
So
you
know
indy's,
just
a
small
part
of
that
overall
solution,
and
hopefully
people
who
are
familiar-
and
you
know
part
of
the
indie
project-
would
wouldn't
back
those
statements
up.
A
So
we're
going
to
talk
about
one
more
and
you
know
I
think
it's
one
of
the
the
newer
platforms
in
hyperledger
right,
but
we
were
very
excited
to
to
get
to
bay
su
as
well.
Do
you
want
to
talk
a
little
bit
about?
I
think
we
we
got
involved
in
trying
to
get
baisu
in
very
early
after
I
joined
hyper
ledger
or
suji.
Do
you
want
to
talk
a
little
bit
about
what
we
were
able
to
do
there
and
and
how?
B
B
We
are
trying
to
understand
what
are
the
different
requirements
or
the
with
the
community
needs
and
trying
to
kind
of
make
it
more
consistent
with
other
platforms
which
we
have
so
we're
still
kind
of
working
on,
creating
the
base
network
setup
with
things
like
enabling
boot
nodes
and
as
well
as
so
right
now.
B2
is
also
kind
of
upgrading
their
their
images
and
charts.
So
we
are
also
kind
of
trying
to
see
if
we
we
need
those
things.
A
You
okay!
Well,
let's
take
a
a
little
snapshot
again.
Any
questions,
please
please
throw
them
out,
but
if
I
have
to
talk
about,
we've
had
a
great
success
from
an
accenture
perspective
on
on
baf
we're
using
that,
like
I
said
with
with
a
number
of
our
customers
and
we've
had
great
great
success,
and
I
think
the
hyperledger
labs
program
overall
is
often
an
overlooked
capability
within
hyperledger.
A
We
have
you
know
great
successes
in
terms
of
reducing
the
amount
of
time
to
set
up
some
of
the
stuff
and
conform
to
strong
reference
architecture
and
in
the
open
source
community.
We've
had
a
lot
of
people.
I'd
say
a
lot
of
more
experimentation
than
contribution
at
this
point,
and
for
me,
what
would
be
the
ultimate
success
here
is
if
other
people,
other
organizations,
think
this
is
valuable
as
well
and
wanted
to
contribute.
A
The
goal
here
is
not
to
is
to
accelerate
the
entire
ecosystem,
not
just
accelerate
things
for
accenture,
and
so
the
best
way
we
can
do,
that
is
to
have
other
other
organizations
to
contribute
and
participate,
and
we
have
had
a
very
active
participants
in
terms
of
use.
I'd
say,
but
you
know,
we'd
love
to
see
more
contributors,
contributing
those
there's.
So
many
features
that
we'd
love
to
do
that
that
we
can't
get
to
all
of
them.
A
B
Right,
so
what
we
have
already
implemented
is
that
we
have
an
hyperledger
fabric
network,
with
version
support
for
both
1.4.4
and
2.2.
So
2.2
has
been
our
latest
introduction
to
fabric,
so
this
is
also
based
on
one
of
our
customer
requirements
and
also
what
we
found
that
it
kind
of
hyperledger
fabric
has
upgraded
to
that
and
that
had
a
lot
of
other
features
and
different
things
to
which
we
we
wanted
to
kind
of
incorporate
and
looked,
and
we
found
values
value
in
that.
B
So
we
have
added
that
new
version.
We
have
consistency,
support
for
both
kafka
and
raft
raft
being
kind
of
for
both
the
versions
kafka
we
had
support
for
1.4.4
and
in
terms
of
network
operational
features,
we
kind
of
have
the
peers,
orders
and
channels
addition,
as
well
as
a
removal
of
an
organization.
B
B
B
Most
of
the
things
which
we
have
planned
forward
is
towards
towards
operational
features
enhancements
so
mike,
I
think,
can
you
move
to
the
next
one
yeah,
so
we
are
also
following
it
consistent
across
all
the
dlts,
so
here
also,
if
you
see
with
the
other
dlts
as
well,
our
focus
lies
on
particularly
upgrading
those
dlt
platforms
to
the
latest.
Support
kind
of,
and
also
some
of
the
operational
features
which
we
have
so
for
besu.
B
Indeed,
we
are
quite
stable,
I
guess
with
in
the
deployment
we
have
right
now.
What
we
have
planned
is
kind
of
look
at
different
operational
features
or
additional
features
which
we
can
provide
so
on
that
what
we
have
planned
is
that
to
have
various
language
support
for
the
ref
app
and
also
if
we,
if
there
are
kind
of
different
additional
database,
supports
and
version
upgrades,
so
yep
that's
some
of
the
features.
Currently
we
have
that's.
A
C
A
You
know,
I
think
the
technical
steering
committee
looks
at
the
longevity
of
projects
and
their
ability
to
be
maintained,
and
I
think
one
key
aspect
that
we
don't
have
right
now
is
other
organizations
that
are
contributing.
I
I
think
that
would
be
what
we
need
in
order
to
go
to
top
level
project.
We,
I
think,
that's
the
key
for
us.
I
think
everything
else
is
pretty
much
in
place,
but
to
know
that
this
isn't
just
a
tied
to
accenture,
I
think,
is
key
before
it
becomes
a
top
level
project.
C
Yeah,
well,
that
makes
sense,
and
I
I
do
hope
that
this
webinar
and
all
the
efforts
that
you're
doing
right
now
to
get
the
broader
community
participation
will
pay
off,
because
it's
really
worth
it.
It's
a
great
project.
Well,
thank
you
for
this.
If
there
are
no
more
questions,
I'm
going
to
just
close
it
out
with
a
couple
of
announcements
or
information,
but
if
you
have
questions
please
pop
them
in
the
q
a
or
raise
your
hand.
C
This
is
the
time
to
to
ask
those
questions.
In
the
meantime,
next
webinar
will
be
in
a
month's
time
on
january
20th
and
it
will
be
a
different
format.
So
we
are
starting
a
very
new
format,
an
hour
or
so
with
this
time,
smart
block
laboratory-
and
we
want
to
have
a
more
interactive,
guided
discussions.
C
You
could
expect
demos
tutorials
brainstorming.
It
will
be
hopefully
no
more
just
a
one-way
communication.
We
want
people
to
participate.
So
if
you
want
to
take
part
in
our
experiment,
please
sign
up
for
for
the
webinar
and
join
us
on
january,
the
20th
and
please
do
get
involved
as
today's
panelists
or
presenters
described
or
said,
we
are
looking
for
more
contributions,
we
want
you
to
contribute,
and
that
doesn't
mean
only
coding.
It
can
be
testing,
it
could
be
participating.
C
You
know
whatever
it
is,
I'm
sure
you
have
an
expertise
that
will
help
hyperledger
and
you
will
have
fun
so
go
to
our
website.
Go
to
our
wiki
join
the
mailing
lists
and
let's
see
where
it
takes
you
for
now.
Thank
you
for
joining
us
and
if
you
have
any
more
questions
or
you
want
to
get
in
touch
with
our
today's
presenters,
please
email
membership
at
hyperledger.org
and
guys.
Thank
you
so
much
for
presenting.
It
was
really
interesting,
and
I
really
appreciate
your
time.