►
From YouTube: From Public to Private Blockchain Networks:
Description
Free Your Developers from Dealing with the Intricacies of Blockchain Networks with a Network Agnostic Broker
Swetha Repakula & Nima Kaviani, IBM
Deploying and developing smart contracts is a complicated task. A developer not only needs to understand and implement the logic of a contract but also know how to set up and integrate their nodes to a network. With configuration and management differing by network, the learning curve for a polyglot blockchain developers is quite steep.
PaaS aim to hide the complexities of the IaaS and allow cloud application developers to focus solely on their application logic. We believe the same analogy can and should be applied to blockchain application developers.
In this talk, we will demonstrate how the Blockhead broker facilitates the process of developing DApps independent of the blockchain network used. In particular, we will demo the deployment of smart contracts across both a public blockchain network (i.e. the Ethereum network) and a private blockchain network (i.e. Hyperledger Fabric).
----
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 #HyperledgerGlobalForum2018 #Blockchain
A
All
right,
hello,
everyone,
my
name
is
Nemo
KP
on
e
and
today
with
my
colleagues
with
our
Pakula,
we're
gonna
talk
to
you
about
how
you
can
deploy
your
application,
irrespective
of
the
public
blockchain
or
the
private
blockchain
that
you
use.
So
if
you
have
absolute
jumped
in
too
quickly
I
think
there
you
go
okay.
A
A
It's
just
Joe!
Alright!
Sorry
over!
If
you've
been
a
developer
of
blockchain
applications,
you
know
that
writing
decentralized.
Apps
is
actually
quite
difficult,
because
what
you
need
to
do
is
that
you
need
to
write
an
application
and
if
you
need
it,
if
you
need
to
write
it
in
a
language
like
solidity,
you
have
to
learn
the
language.
Once
you
write
the
contract,
then
you
have
to
compile
it.
Then
you
have
to
bring
up
a
node
or
a
gateway
to
deploy
your
application
to
the
blockchain
network.
A
Then,
once
the
application
is
deployed,
you
have
to
get
the
information
back
from
the
blockchain
networking
about
how
to
access
your
contract,
and
then
you
have
to
provide
that
information
to
the
decentralized
applications
that
you
have,
whether
it's
a
web,
3
or
some
other
sort
of
application,
and
only
then
you're
going
to
be
able
to
use
the
application.
So
this
entire
process
is
quite
cumbersome
and
requires
an
in-depth
knowledge
of
you
know:
writing
the
code
using
the
blockchain
you
know
connecting
it
to
the
network,
etc,
etc.
A
So,
as
we
were
looking
into
this
process,
we
realized
that
there
are
a
number
of
things
that
we
can
simplify
so
the
team
and
that
we
formed
started
looking
into
motivations
for
making
this
entire
process
simpler.
What
we
wanted
to
do
was
to
make
the
deployment
and
development
of
web
3
applications
easier.
We
wanted
to
simplify
the
way
blockchain
networks
are
accessed.
You
actually
develop
blockchain
applications
or
decentralized
applications.
We
wanted
to
make
it
easier
to
manage
the
network
or
the
blockchain
network
that
you're
using
whether
through
the
Gateway
or
a
proxy
or
a
node.
A
A
So
the
high-level
vision
that
we
had
for
this
project
when
we
started
thinking
about
it
is
that
you
know,
as
blockchain
gains
more
momentum
and
it
starts
being
used
by
organizations.
We
wanted
to
make
it
so
that
for
every
organization
that
chooses
to
do
this
peer-to-peer
trustless
transactions,
they
are
able
to
actually
utilize
it
in
their
production
environment
in
a
much
easier
way,
and
they
can
actually
benefit
from
the
offerings
of
cloud
to
deploy
the
decentralized
applications
for
the
purpose
of
scalability
and
availability.
A
So
what
we
did
was
that
we
started
looking
into
ways
to
do
it
in
the
cloud,
and
one
of
the
interesting
thing
is
that
the
team
that
we
have
and
when
we
saw
or
basically
I,
should
say
we
had
when
we
started
working
on
this
project.
We
are
all
coming
from
cloud
development
backgrounds.
All
of
us,
our
core
contributors
to
cloud
platforms,
shweta
and
I-
have
contributed
to
Cloud
Foundry
and
we've
also
looked
into
kubernetes
and
other
stuff.
A
So
we
know
quite
a
bit
about
you
know
what
it
what
it
takes
to
write
applications
for
the
cloud
and,
if
you're
familiar
with
the
concept
of
12
factor
web
applications
in
the
cloud.
You
know
that
there
are
like
12
principles
that
every
application
that
gets
deployed
to
cloud
platforms
need
to
follow
for
it
to
be
scalable
and
highly
available.
If
you're
not
familiar
with
these
12
concepts,
I
highly
recommend
that
you
actually
go
and
look
into
them.
But
the
important
thing
is
that
the
application
needs
to
be
configurable.
A
It
needs
to
be
auditable,
you
have
to
be
able
to.
You
know,
collect
logs
and
monitoring
information.
You
need
to
be
able
to
bind
the
state
as
type
of
a
service
to
the
application,
and
then,
when
you
provide
all
of
this,
it
will
affect
their
application.
Then
you're
going
to
be
able
to
seamlessly
you
know
scale
the
application
and
make
it
highly
available.
A
One
of
the
important
aspects
about
these
twelve
factors
is
the
backing
services,
and
so,
if
you
deploy
your
application
in
the
cloud,
what
you
want
to
do
is
that
you
want
to
manage
the
state
that
the
application
requires
through
some
services,
and
this
services
can
be
database
services,
file,
storage
services.
You
know,
code,
repository
services,
etc,
etc.
A
So
we
came
to
this
problem
that
I
mentioned
initially
about
trying
to
make
decentralized
applications
more
easily
developable,
with
this
knowledge
that
we
had
from
developing
to
a
factor
web
applications,
and
what
we
noticed
is
that
decentralized
apps
are
essentially
not
very
different
from
two
effective
web
applications.
The
difference
is
that
you
know
usually
the
state
that
these
applications
have
are
kept
in
the
blockchain
right.
A
So
one
thing
that
we
realize
is
that
we
can
provide
blocks
and
as
a
backing
datastore
to
the
application
and
that's
the
idea
that
basically
resulted
in
you
know
kicking
off
this
project.
So
we
thought
that
we
can
provide
the
permission,
blockchain
or
a
public
floor
chain
as
the
backing
service
and
to
a
decentralized
web
app
and
that's
how
we
formed
and
the
idea
of
developing
a
service
broker.
A
So
the
idea
for
the
service
broker
is
that
the
service
pro
broker
is
a
piece
of
software
that
manages
the
services
that
are
provided
to
a
to
your
application
and
in
the
case
of
a
decentralized
app,
and
this
can
be
the
blockchain
service
that
is
offered
to
your
location,
so
I
am
going
to
quickly
over
go
over
the
architecture
that
we
had
for
the
design
of
the
broker.
So
on
the
left
end,
you
see
that
you
have
a
cloud
platform.
A
This
cloud
platform
can
be
anything
like
cloud
foundry,
it
can
be
kubernetes,
it
can
be
Heroku
or
basically
any
platform
that
can
run
your
decentralized
application
in
the
middle.
You
have
the
broker,
and
the
idea
for
the
broker
is
that
it
provides
you
two
levels
of
abstraction
one
for
managing
containers
and
the
other
one
is
for
managing
the
d-block
shape
network.
So
the
broker
basically
does
two
things:
it
provisions
services
and
then
it
point
services
to
the
applications.
A
So,
let's
see
what
happens
when
you
try
to
provision
a
service
with
the
broker,
when
the
provision
happens,
the
platform
sends
a
request
to
the
broker
to
bring
up
access
to
the
blockchain
Network.
Now
the
broker
with
this
container
manager,
the
site
looks
into
the
type
of
network
that
your
application
wants
to
connect
to.
If
it's
a
public
launch
a
network
like
aetherium,
it
brings
up
a
get
node
and
then
the
get
nodes
gets
connected
to
the
rest
of
the
network,
the
etherium
network
and
the
information.
A
If
it's
a
hyper
ledger
fabric,
for
example,
then
what
the
broker
brings
up
is
a
proxy
or
a
gateway
to
the
network
which
provides
authentication
and
authorization
for
the
users
and
again
the
information
gets
relayed
back
to
the
to
the
platform.
The
next
step
is
to
bind
the
service
with
a
contract.
So
what
happens
is
that
the
platform
sends
a
contract
information
to
their
broker,
with
the
information
about
which
node
the
contract
needs
to
be
deployed
to,
and
at
that
point
the
blockchain
the
deployer
takes.
A
The
contract
goes
to
the
node,
whether
it's
the
get
node
or
whether
it's
the
proxy
deploys.
The
contract
through
the
node
into
the
blockchain
network,
gets
the
information
for
the
deployed
contract
back
from
the
network,
which
is
like
the
contract
address
and
some
other
information
that
it
requires
to
connect
to
the
to
the
deploy
contract
and
provides
all
of
that
information
back
to
the
application.
And
now
you
have
an
application
that
has
the
contract
information
and
the
IP
address
of
the
node
that
it
can
talk
to
and
the
port
word.
A
You
know
the
node
responds
on
and
with
all
of
that
information,
then
you
can
easily
start
interacting
with
your
application.
The
decentralized
can
start
communicating
with
the
node
and
then
start
writing
and
reading
from
the
blockchain
network
or
to
the
blockchain
network,
so
the
essential
parts
here,
or
the
container
manager
interface
and
the
blockchain
and
deployer
interface
that
we've
kind
of
used
to
abstract
away
the
complexities
of
where
you
run
your
node
and
what
type
of
node
you
run
and
also
what
type
of
blockchain
you
want
to
deploy
your
contract.
A
B
So
some
of
the
things
that
we,
when
we
started
doing
this
work,
we
kind
of
want,
we
knew
right
away
that
we're
not
gonna,
only
support
one
network.
We
want
to
make
sure
our
thing
is
scalable
and
we're
able
to
add
other
blockchain
networks.
As
you
know,
some
become
more
popular
or
if
they're
different
reasons.
So
obviously
we
were
talking
about
permissioned
networks
as
well
as
public
networks.
So
that's
one
big
thing:
that's
actually
the
second
section
there
that's
the
blockchain,
deploy
our
interface
and
the
idea
is.
B
We
should
be
able
to
deploy
either
blockchain
nodes
when
it's
a
public
network
and
you
can
run
full
nodes
or
it
could
be
access
points
or
gateways
into
a
network
when
it's
a
permission
system
like
fabric
we're,
not
everyone's
allowed
to
run
our
node.
So
we
wanted
to
make
sure
that
piece
is
flexible.
The
other
piece
that
we
want
it
to
be
flexible
on
is
how
are
these
nodes
being
deployed?
So
our
initial
way
we
do
this
is
we're
actually
create
a
VM.
B
We
expect
that
you
create
this
broker
and
is
running
in
a
VM,
and
we
use
docker
to
kind
of
manage
the
nodes
and
they
bring
up
some
of
these
images
now
for
a
public
network,
something
like
aetherium
death
node
is
a
very
standard
image.
It's
very
easy
to
just
kind
of
run
that
and
maybe
pass
in
a
few
different
arguments.
If
you
want
to
connect
to
test
net
main
net,
maybe
you
want
to
run
it
in
dev
mode.
It's
all
in
the
end.
It's
one
it's
the
same
docker
image,
so
we
okay
Dockers
one.
B
We
we're
using
the
concepts
of
containers
and
stuff
and
trying
to
apply
it
to
some
of
these
blockchain
nodes.
The
other
thing
that
we
thought
is
with
the
popularity
of
kubernetes.
We
want
to
be
able
to
scale
up,
because
on
a
VM
right,
you're
limited
to
the
resources
that
one
VM
has
versus
a
kubernetes
clusters,
you
can
add
clusters,
you
can
expand
it.
You
can
add
more
pods
to
it.
So
we've
also
made
sure
that
the
nodes
and
these
access
points
that
we're
deploying
we're
gonna
also
make
it
available
using
a
kubernetes
thing.
B
So,
let's
kind
of
go
into
some
of
those
container
manager
implementations.
So,
as
I
said,
currently,
we
support
docker
and
kubernetes.
Let's
dive
a
little
bit
into
docker
quickly,
so
the
first
thing
is:
we
use
something
called
a
docker
bas-reliefs.
So
if
you're
familiar
with
cloud
foundry
and
the
technologies
that
are
used
there,
Bosh
is
just
a
way
to
deploy
software
and
run
it
in
VMs,
Bosh
kind
of
makes
it
a
nice
simple
way.
B
So
that
way,
you
write
the
software
once,
but
you
can
deploy
it,
whether
it's
to
the
IBM
cloud
or
whether
it's
to
AWS
GCP
its
kind
of
makes
that
interface
a
little
bit
easier.
So
we
that
was
our
first
attempt
at
how
we
wanted
to
do
this.
This
docker
Bosh
release
it
works
really
well
with
the
Cloud
Foundry
platform,
because
Cloud
Foundry
itself,
it's
way
of
being
deployed
is
also
a
Bosh
release
and
the
idea
is
every
service
that
you
create.
B
If
you're
familiar
with
the
open
service
broker
API,
we
call
these
services
when
you
ask
for
something
these
are
actually
going
to
each
be
correspond
to
a
specific
docker
container.
So
the
idea
is
when
one
person
asked
for
a
note:
they're
not
sharing
a
node
with
somebody
else,
it
is
being
it's
private.
It's
confident
you
know
it.
These
data
is
separated
between
the
two
nodes
as
much
as
can
be
on
a
blockchain
network.
B
B
So
that
way,
any
time
you
create
a
new
service,
the
broker
is
going
to
create
a
new
pod
and
that
new
pod
will
be
running,
whether
it
you're
get
snowed
or
if
it's
your
fab,
three
proxy,
depending
on
that
again
it's
up
to
the
services
and
what
we
made
the
whole
broker
architecture
really
easy
is.
These
are
all
docker
images.
B
Currently,
the
one
that
we're
supporting
right
now
is
the
etherium
JSON
RPC
API,
so
which
is
basically
what
Gethin
and
implements
we
also
have
work
in
fabric
and
implementing
something
we
call
the
fab
3
proxy,
which
allows
people
to
use
aetherium
clients
and
tools
and
interact
with
the
theorem
smart
contracts
on
fabric.
So
that
kind
of
brings
me
into
the
next
thing:
what
is
the
backend
blockchain
network?
So
the
first
thing
we
tried
was
the
public
etherium
network.
B
We
found
this
was
an
easy
thing
to
kind
of
start
off
with,
for
many
of
the
reasons
I
just
said
or
mentioned
previously,
deathnote
is
simple:
there's
only
one
image,
there's
only
one
network
or
there's
only
a
few
different
networks
out
there
that
people
want
to
connect
to,
and
it's
very
easy
to
make
assumptions.
So
we
can
say:
hey
this
person
wants
to
connect
a
test
net.
We
know
how
to
do
that.
B
We
know
how
to
connect
two
main
net
and
it's
kind
of
all,
currently
we're
supporting
only
dev
nodes,
but
the
next
step
is
to
take
our
dev
nodes
and
connect
them
into
a
public
network
and
the
problems
there
are
the
type
of
decisions
that
we're
actually
looking
into
is:
how
do
we
make
sure
we're
not
copying,
tons
and
tons
of
ledger
information,
because
in
the
end,
these
nodes
are
all
kind
of
being
connected
to
this
broker.
So
we
want
to
simplify
some
of
that
process.
B
Now,
when
we
come
into
a
permissioned
network,
there
are
a
lot
of
decisions
that
we
kind
of
had
to
make.
So
the
first
thing
is,
as
a
permission
network
permission
can
mean
many
different
things:
whether
it's
about
the
user
being
allowed
to
submit
a
transactions
to
whether
the
users
are
allowed
to
submit
a
node.
How
much
information
does
the
user
have
to
be
able
to
connect
to
a
network
who's
in
control?
So
these
are
all
like
a
lot
of
open-ended
questions
and
it
becomes
like
a
by
a
use
case
kind
of
a
situation.
B
B
What
is
the
topology
of
it,
and
we
expect
them
to
actually
create
the
docker
image
that
they
want
their
users
to
be
able
to
deploy
in
this
case,
these
are
some
of
the
things
that
I
think
are
important
to
consider
when
you're,
creating
that
docker
image.
One
is
the
network
information.
So
what
are
the
peers?
What
are
the
peer
I'm
using
fabric
terminology,
but
what
are
the
nodes
that
this
proxy
or
this
know
or
what
are
their
nodes?
Should
the
docker
image
or
the
container
be
allowed
to
talk
to
user
credentials?
B
How
are
we
going
to
get
those
credentials
in
there?
Currently,
we've
gone
with
the
approach
that,
if
you
are
creating
this
broker,
you
already
have
access
to
this
network,
you're,
probably
managing
that
a
node
in
that
permission
network.
So
you
probably
can
bake
in
some
kind
of
credential
system
into
the
container
itself.
This,
depending
on
how
the
network
works,
you
can
change
it.
B
For
example,
currently
we
have
all
the
credentials
and
stored
into
our
fabric
container
that
we're
using,
but
in
the
future
we
want
to
convert
to
using
the
certificate
authority
that
fabric
has
fabric
CA
to
do
some
kind
of
user
creation,
as
well
as
a
at
least
some
kind
of
a
basic
auth
when
the
user
deploys
their
service
and
I'll
show
you
that
in
the
demo,
what
I
mean
by
that
as
I
said,
docker
images
we're
going
to
force,
put
the
burden
on
the
operators
to
create
them.
They
have
to
offer
it
they
get
to
decide.
B
What
is
the
information
that
a
user
needs
to
provide
when
they
create
the
service?
Am
I
expecting
them
to
just
give
me
a
username
and
password
am
I
expecting
them
to
just
say:
hey
I
want
to
be
part
of
organization
one.
This
is
the
channel
that
I'm
creating
again
it's
kind
of
up
to
the
operator
and
I'll
show
you
an
example
of
what
we
think
would
be
a
reasonable
approach
to
this,
and
then
the
last
thing
is
the
deployer
interfaces.
So
now
we've
mentioned
deployer
interface
in
two
ways.
B
Here
one
is:
how
is
the
actual
blockchain
network
node
proxy
being
deployed?
That's
one
thing,
but
the
other
thing
is
also
how
our
smart
contracts
deployed
on
these
permission
networks
or
on
these
public
networks.
So
we've
kind
of
I
wouldn't
say
we
cheated,
but
we've
kind
of
used
some
of
the
technologies
and
the
integrations
that
are
occurring
to
make
this
process
a
little
bit
easier
for
us
right
now
we
have
an
aetherium
deployer,
which
basically
uses
the
etherium
JSON
RPC
API,
and
it
expects
that
whatever
proxy
node
or
that
is
communicating
to
implements
that.
B
So
it
makes
it
a
little
bit
easier.
So
we
can
use
the
theorem
tools
like
web
3j
s
to
deploy
smart
contracts,
get
contact,
information
and
the
schema
all
out,
and
it's
all
kind
of
one
basic
interface-
that's
happening.
We
want
to
in
the
future,
though,
expand
this
and
support
some
of
the
other
languages
that
are
out
there.
So,
for
example,
hyper
ledger
fabric
has
go
and
node
smart
contracts.
It
would
be
nice
if
we
give
them
the
ability
to
be
able
to
deploy
those
using
our
similar
process.
B
So
let
me
quickly
go
over
what
I
want
to
show
you
guys.
In
a
demo
we
have
a
broker,
that's
deployed
and
a
Bosch
light.
Bosch
light
is
basically
a
mini
VM,
that's
running
on
my
machine
currently
and
the
broker
is
deployed
on
there.
We
also
have
a
platform,
a
cloud
foundry
platform
running
on
the
same
VM.
What
we're
going
to
do
is
we're
going
to
create
an
aetherium
and
a
fabric
service,
so
in
the
etherium.
That
means
we're
going
to
start
up
a
guest
node
we're
going
to
do
it
in
dev
in
fabric.
B
What
it
means
is
we're
gonna
start
up
a
fab,
3
proxy
if
you're
familiar-
or
this
is
a
slightly
new
feature
in
fabric
we
had.
There
is
an
EVM
chain
code,
that's
been
created
and
there's
a
fab
3
proxy
that
helps
uses
the
etherium
JSON
RPC
API.
So
there
iam
clients
can
talk
directly
to
the
chain
code.
That's
been
installed
in
fabric,
we're
going
to
push
a
voting
app,
which
is
basically
a
decentralized
application
that
we've
created.
B
It
is
going
to
use
the
web
3
j/s
as
its
way
of
communicating
to
a
network,
and
then
what
we're
going
to
be
able
to
do
is
we're
going
to
provision
it.
We're
going
to
bind
it
to
the
etherium
service,
we're
going
to
show
you
that
the
app
is
running
and
then
we're
going
to
switch
the
blockchain
Network
behind
the
scenes
and
we're
going
to
show
you
how
the
application
is
still
working
and
all
we've
done
is
just
switch
which
network
it's
talking
to
and
then
with
that.
Let
me
try.
B
So
let
me
know
if
you
cannot
see
that
just
raise
or
say
it's
too
small,
so
we're
gonna
start
off
with
showing
you
the
Cloud
Foundry
marketplace.
This
is
basically
if
you're
familiar
with
the
PA's.
This
is
basically
saying
all
the
services
that
are
created.
As
you
can
see,
we
have
an
aetherium
service
and
there's
a
plan
that
says
get
dev,
there's
a
fabric
service,
fab,
3
and
there's
fab
3
org
1
and
fab
3
org
2
some
before
earlier.
B
I
was
mentioning
that
there
are
some
decisions
that
the
operator
is
going
to
have
to
make
when
they
create
their
docker
images.
So
in
this
case,
I'm
going
to
say
that
the
difference
is
going
to
be
they've
created
a
image
for
organization,
1
and
they've
created
an
image
for
org
2
and
typically
you
would
think
that
both
of
them
would
not
be
available,
but
just
to
kind
of
show
how
you
could
split
this
up
is
why
we
have
both
of
these
plans
available
on
the
right.
What
we
have
here
is
the
actual
broker.
B
The
broker
that's
running
in
a
VM
I
have
a
docker
PS.
This
is
using
the
docker
container
manager
for
the
moment,
so
we're
going
to
be
able
to
track
what
containers
happens
as
I
do
some
things.
You'll
should
be
able
to
see
some
changes
happening
over
here.
So
the
first
thing
I
want
to
do
is
I'm
going
to
show
you
my
application.
I've
already
pre
deployed
it
to
kind
of
speed
up
the
upload
times
and
everything
and
not
worry
about
the
internet
too
much.
B
But
it's
stopped
right
now,
it's
not
connected
to
show
you
what
is
can
what
are
the
what's
the
environment
that
the
app
is
running
in
you
can
see,
there's
not
much
information
if
you're
familiar
with
the
paths.
This
is
all
basic
information
about.
You
know
what
are
the
resources
it
has.
What
are
the
routes
to
it?
I
wouldn't
worry
too
much
about
this,
but
this
is
just
to
show
you.
Nothing
is
connected
to
the
outbreak.
Now,
with
that
I'm
going
to
create
a
service.
B
Okay,
there
you
go
so,
as
you
can
see
here,
this
is
a
docker
image
that
we've
kind
of
just
played
with
it's
a
net.
There's
nothing
special
about
it.
It's
a
get
note
that's
running
with
the
dev
flag
on
it.
What
you
can
see
here
is
the
ports
that
are
open
on
this,
the
one
that,
if
you're
familiar
with
the
theory,
immed
evelopment,
is
the
eight
five
four
five
port,
which
is
this
one,
that's
the
one
that
they
expect
DAPs
or
clients
to
talk
to
the
node.
B
B
So
all
we
have
to
do
in
this
case
is
bind
the
service
I'm
going
to
bind
it
to
F,
and
we
provide
here
some
information.
So
all
we
have
to
do
is
give
it
the
contract
URL.
So
the
expectation
is
this:
contract
is
a
solidity
contract
and
it's
available
somewhere
on
the
internet.
I
have
a
simple
polling
app
that
our
DAP
uses.
It's
again
very
simple:
there's
two
options:
you
can
vote
a
or
you
can
vote
B
and
all
I'm
gonna
do
is
I'm
gonna.
Take
this
URL
pass
it
in
before
I.
B
Cool-
and
you
can
see
here-
we've
sealed
that
you
can
see
that
it's
mine
new
blocks
and
then
there's
also
a
contract
creation,
which
is
the
contract
that
we
have
given,
and
you
can
actually
even
see
the
contract
address
right
there.
So
what
I'm
going
to
also
show
you
here
before
I
show
you
that
application
is
I'm
going
to
show
you
the
environment
that
it
has,
and
previously
all
of
this
information
was
in
there.
But
there's
this
new
object.
That's
been
there
called
the
bee
cap
services.
B
Each
platform
is
different,
so
it
might
not
show
up
like
this
everywhere,
but
this
is
information
that
the
brokers
return
to
the
platform
and
it's
up
to
the
platform,
how
to
show
that
information
to
the
user.
In
the
end
here
we
have
something
with
a
net,
that's
the
key
of
the
service,
and
if
you
can
see
this
is
all
that
information
that
if
we
did
the
docker
PS,
it's
all
that
port
information.
B
You
have
the
addresses
of
where
this
container
is
located
and
then,
if
this
is
all
kind
of
information
that
an
etherium
DAP
needs
it's
the
ABI,
which
is
basically
the
schema
of
the
smart
contract,
so
it's
able
to
communicate.
You
have
a
user
account
address
here
and
I
can
see
that
the
contract
address
did
not
show
up.
So
let
me
run
this
again.
B
As
you
can
see,
we
have
a
new
container,
that's
running
from
here,
I'm
going
to
bind
the
service
again,
it's
gonna
do
the
same
thing:
I'm
not
going
to
show
you
the
logs,
because
it's
gonna
look
exactly
the
same,
but
we'll
give
it
a
second,
let's
see
if
this
time
this
worked-
and
you
can
see
now-
we
do
have
a
contract
address
previously.
That
was
missing
and
it
is
so
with
that.
There's
one
more
thing.
So
this
DAP,
because
of
how
Cloud
Foundry
provides
the
information
to
the
depth.
B
It
uses
this
key
called
ëthe,
which
is
the
service
name
that
we
use
when
we
created
the
service.
So
when
I
switch
over
to
a
fabric
or
something
else
is
going
to
have
a
different
service
name
for
ease
of
being
able
to
switch
the
application.
We
also
work
with
the
application
that
we
have
requires
one
more
environment
variable
to
be
set,
which
is
the
service
name
and
all
I'm
gonna
do
here
is
say
that
it's
app
that
matches
that
key
and
then,
if
I,
do.
B
B
So
with
this
then
I'm
gonna
just
go
to
this
application.
It's
a
very
simple
kind
of
fun.
Little
question:
do
you
prefer
dogs
or
cats
I'm
a
avid
dog
lover?
So
the
only
acceptable
answer
is
this:
as
I
submit
this
we're
going
to
see
some
logs
that
are
kind
of
piling
up
here
you
can
see
a
new
block
is
being
minted
and
then,
with
that
this
is
our
results.
Page
it's
just
pulling.
So
the
dogs
and
cats
actually
correspond
to
the
poll
boat,
a
boat,
be
part
of
the
contract.
B
B
B
B
And
then
now
you
can
see
there
is
a
new
container.
This
is
a
different
image.
It's
a
fab,
3
org,
one
versus
the
at
dev.
If
I
go
back
here
we
can
see.
This
is
what
the
this
is:
the
mini
blockchain
network
that
we've
deploy.
We
have
two
organizations
in
appear
in
each
which
is
basically
a
node
in
hyper
ledger
fabric,
and
then
we
have
an
order,
which
is
the
component
that
produces
the
blocks.
What
I
have
up
here
is
the
order
ER
logs.
B
Similarly,
I'm
gonna
do
PS
I'm
going
to
get
this
so
that
way
we
can
watch
these
logs,
so
that
is
our
fab,
3
proxy,
that's
running
and
then
I'm
going
to
do
a
bind
service.
Now,
if
you
look,
the
only
thing
I
have
to
change
here
is
the
name
of
the
service
that
I've
created.
Everything
else
is
the
same
at
this
point
and
then,
as
this
occurs,
we
should
see
both
logs
here
and
we'll
start
getting
logs
over
here.
So
you
can
see,
estimate
gasps.
B
The
logging
on
fab
3
is
not
the
same
as
get
it's
not
going
to
be
able
to
tell
you
when
a
block
has
been
mined
because
it's
an
access
point,
it's
not
actually
a
node
and
then
here
you
can
see.
We've
developed
more
logs
because
a
block
has
been
created,
I'm
not
going
to
go
through
these
logs,
but
just
to
kind
of
show
you
what's
happening
and
then
with
that
we're
going
to
stop
the
voting
app
temporarily,
so
we
can
kind
of
switch
it.
B
The
other
thing
we
need
to
do
to
tell
it
to
move
is
change
the
service
name
again.
Oh
yes,
let
me
quickly
before
I.
Do
that
I'm
going
to
show
you
guys
we
have
a
new
service.
That's
been
added
into
the
V
cab
services
block,
so
we
still
have
the
old
aetherium
piece.
But
now
we
have
a
fab
3pls
piece
and
it
looks
very
similar,
except
here
we
only
have
one
port
mapping.
The
ABI
is
exactly
the
same.
B
If
you
look,
you
can
see
the
account
address
and
the
contract
address
our
act
usually
different
from
the
etherium,
which
is
what
you
would
expect,
because
there
are
two
different
blockchain
networks
that
we're
using
so
to
make
this
work.
Let's
do
and
vote
and
I'm
going
to
switch
it
over
to
fab
3
and
that
I'm
going
to
start
the
app
again.
B
Perfect,
okay,
so
this
is
the
same
page.
Remember
it's
the
same
application.
So
it's
the
same
route
I'm,
going
to
just
refresh
before
I.
Go
to
the
part
that
vote
and
you
can
see
we're
on
a
different
network
because
there's
no
data
and
I'm
going
to
restart.
As
I
said,
dogs
was
the
only
appropriate
answer
here.
B
So
I'm
gonna
go
back
over
here
and
you're
gonna
start
seeing
again
logs
because
new
blocks
are
being
created
and
if
we
need
further
proof
that
we
have,
you
know
separated
out
the
or
we
have
switched
out
the
backing
block
chain.
Network
I'm
going
to
do
another
watch,
docker,
PS
and
I
can't
CF
unbind.
B
Okay,
with
that
we've
lost
the
container,
but
I
can
still
vote
without
any
errors
that
hopefully
no
errors,
and
there
you
go
so.
We've
I've
successfully
switched
out
the
blockchain
Network
we've
used
the
same
application
and
we
can
kind
of
show
you
that
the
DAP
Development
now
can
kind
of
be
separated
a
little
bit
from
the
actual
backing
blockchain
Network
granted.
There
is
a
few
caveats
both
fabric
and
aetherium
support
solidity
contracts,
which
is
why
this
works.
B
So
a
couple
of
things
that
we've
already
done
this
initial
broker,
so
this
actually
started
as
a
hackathon
project
which
was
written
in
Ruby,
we've
rewritten
it
in
go.
We
have
a
dev
node
dev
mode
for
the
etherium
death
note
available.
We
allowing
deploying
the
broker
through
kubernetes
and
Bausch,
which
we've
talked
about,
and
the
other
cool
thing
is
that
the
actual
nodes
can
be
hosted
through
docker
kubernetes,
and
then
we
now
we
are
supporting
permission.
B
Blockchain
networks,
the
one
that
we
worked
on
is
hyper
ledger
fabric,
assuming,
though,
that
you're
using
the
EBM
chain
code
and
using
the
etherium
kind
of
clients.
So
that
is
a
caveat
to
the
hyper
ledger
fabric
support.
The
next
thing
we
kind
of
want
to
look
into
is
actually
those
nodes,
those
get
nodes.
We
want
to
connect
them
into
an
actual
blockchain
network.
We
want
to
look
at
support
for
other
permission
networks,
not
just
fabric
and
see
how
that
works.
B
So
here
are
some
of
our
resources.
So
this
is
a
Cloud
Foundry
extensions
project.
So
here
the
proposal
is
the
first
link
the
project
repositories.
There's
the
block
head.
There's
the
block
head
Bosh
release
if
you're
want
to
deploy
using
Bosh
and
the
last
is
the
app
sample
application
and
the
smart
contract
that
I
used
it's
all
available
on
github
and
with
that
any
questions,
it's.