►
Description
A virtual meetup hosted by Hyperledger NYC on October 14, 2021 with Venkatraman Ramakrishna, from the Weaver Lab, and Peter Somogyvari, Hyperledger Cactus Lead, Accenture, providing an overview of their respective projects. This session takes a deep dive into blockchain interoperability and shares real-life examples of how two key Hyperledger projects are addressing challenges.
More about Hyperledger Cactus is at: https://wiki.hyperledger.org/display/cactus/Hyperledger+Cactus+Home
More about the Weaver lab is at: https://github.com/hyperledger-labs/weaver-dlt-interoperability
More about this meetup is at: https://www.meetup.com/Hyperledger-NYC/events/280752067/
----
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 #HyperledgerMeetup #Blockchain
A
So
at
this
point
I
will
hand
it
off
to
peter
and
rama
with
their
presentation,
and
as
david
mentioned,
you
know
we'll
be
happy
to
answer
any
questions
just
feel
free
to
put
them
in
the
chat
I'll
also
be
going
on.
The
youtube
live
stream
and
bringing
up
any
questions
that
are
asked
there
as
well
floor
is
yours.
Both
yeah.
B
So
a
very
quick
note
about
the
agenda,
so
we
have
the
intro.
Then
we
will
talk.
Meanwhile,
we'll
keep
passing
it
back
and
forth
for
the
slides,
we'll
talk
about
interoperability
in
general,
then
we'll
have
two
little
lightning
talks
about
the
respective
projects
that
we
represent,
which
is
hyperlogic
access
for
me
and
hyperledger
labs
weaver
for
rama,
and
then
we'll
talk
about.
Finally,
we'll
close
that
with
the
sort
of
collaboration
progress
update,
because
what
we're
trying
to
do
is
somehow
bring
the
two
projects
together
under
the
ages
of
five
letter
and
then
we'll
take
questions.
B
B
B
B
But
the
way
I
want
to
put
it
is
that
if
you
have
two
different
distributed
legislator,
technologies
or
ledgers
deployed-
and
then
you
have
use
cases
on
those
as
a
business
person,
then
you
can
get
a
certain
amount
of
value
out
of
using
those
individually
which,
on
my
mini
fake
equation,
it
goes
as
v1
and
v2
and
then
the
way
I
define
interoperability
in
the
broadest
of
terms
is
that
anything
that
you
build
oops,
anything
that
you
build.
That
makes
the
lt1
and
dlt2
somehow
work
together,
producing
the
value
of
v3.
B
And
then
one
more
note
on
fragmentation.
Just
to
put
it
really
in
terms
of
numbers,
the
number
of
different
ledgers
or
dlts
that
are
in
existence
is
growing
and
the
number
of
integrations
in
an
ideal
case
where
you
want
all
of
them
to
be
able
to
talk
to
all
the
other
types
which
is
the
intuitive
default.
C
Thanks
peter
so
just
to
emphasize
the
point
peter
made
a
couple
of
slides
ago.
If
you
look
at
the
figure
at
the
right,
we
have
several
different
network
enterprise,
blockchain
or
dlt
networks
available
today,
and
they
all
solve
different
purposes
they,
the
key,
is
they
all
solve,
very
restricted,
restricted
portion
of
whatever
business
workflow
needs
to
be
run
in
a
particular
enterprise
sector.
Like
a
network
could
be
devoted
to
maintaining
know
your
customer
records,
a
network
could
be
devoted
to
doing
processing
payments.
C
Another
could
be
managing
a
trade
logistics
workflow
from
tracking
the
export
of
goods
from
one
country
to
another.
Another
network
could
be
managing
insurance
contracts
or
other
nominations
here,
like
financing
and
so
on.
So
the
thing
is,
you
have
all
these
different
networks
that
have
been
built
on
permissioned,
ledger
technology
and
the
in
the
real
world.
They
cannot
afford
to
remain
isolated.
Their
business
processes
are
inevitably
or
inextricably
interlink
in
the
real
world,
so
what
you
have
to
do
is,
but
still
there
were.
There
were
some
reasons.
C
There
were
good
reasons
why
the
members
of
these
networks
chose
to
keep
those
networks
limited
and
separate
from
other
networks.
So
we
don't
want
force
networks
to
be
able
to
to
have
to
merge
and
sort
of
create
a
super
consortium,
but
rather
we
want
allow
networks
to
have
the
chance
the
opportunity
to
interoperate
with
each
other
as
they
need.
C
So
that's
the
point
we're
trying
to
make
here
is
that,
given
all
these
networks,
we
want
to
enable
the
seamless
flow
of
data
and
value
across
these
networks
in
a
manner
that
preserves
the
trust
and
security.
So
just
because
we
are
enabling
prosthetic
interoperation
does
not
mean
that
we
would
sacrifice
the
principles
of
decentralized
trust
that
blockchains
themselves
were
designed
to
solve.
The
first
place
this.
If
he
enables
injector
operation,
we
will
end
up
removing
network
data
and
value
silos.
C
We
will
end
up
scaling
all
of
these
small
scale
blockchains
into
potentially
one
super
blockchain,
but
without
having
to
do
the
administrative
and
privacy
breaking
the
task
of
forcing
everybody
to
part
of
the
same
consortium.
This
improves
network
effects,
increase
market
sizes,
all
of
the
good
things
you
get
in
the
business
world.
You
also
can
build
complex
business
functionality
across
networks,
so
you
have
smart
contracts
running
on
these
different
platforms.
C
C
So
if
you
have
been
reading
the
literature,
interoperability,
different
people
mean
different
things
when
they
look
at
that
word.
So
I'm
just
referring
to
few
here
and
talking
about
what
exactly
it
is
that
projects
like
cactus
and
viewer
are
trying
to
do.
If
you
look
at
pattern,
one
on
the
top
left
there's
a
view
of
interoperability
that
was
espoused
a
few
years
ago,
where
you
can
think
of
different
permissioned
networks
that
had
that
share
a
common
peer.
C
That
peer
is
managed
by
some
enterprise,
which
happens
to
be
part
of
the
consortium
of
network
a
and
it
will
be
as
well
as
network
c.
So
interoperability
in
the
scenario
means
simply
writing
some
software.
That
will
run
on
the
pier
that
orchestrates
transactions
across
different
networks
and
that
has
access
to
the
data
of
the
different
peers
in
effect,
you're
writing
some
sort
of
integration.
Software,
that's
one
view
of
interoperability.
Another
view
is
going
in
a
different
direction.
C
C
So
you
want
the
blockchain
of
the
dlt
software
to
maintain
a
consensus
over
peers,
regardless
of
what
hardware
and
what
cloud
they're
running
on.
So
that's
another
view
of
interoperability
very
valid
view.
That's
also
not
what
we
are
aiming
for.
What
we
are
aiming
for
is
really
the.
As
I
mentioned
the
previous
slide
as
peter
mentioned
earlier,
you
have
two
different
networks,
just
looking
at
two
networks.
C
C
Can
we
do
that
by
simply
representing
the
network
by
a
proxy?
Now
we
every
tlt
or
every
blockchain
today
offers
you
the
feature
to
build
applications,
hyperledger
fabric
card,
any
ethereum.
You
can
build
some
application
over
the
network
right
so
can
we
just
have
applications
that
are
that
have
access
to
particular
networks
just
talk
to
each
other,
in
effect
using
the
same
sort
of
service
integration
patterns
that
people
are
familiar
with
from
the
enterprise
world.
The
thing
is,
then
you're
reducing
a
network
to
a
kind
of
a
trusted
proxy.
C
C
C
Third
party
not
use
any
kind
of
trusted
proxies,
but
be
able
to
reflect
that
consensus,
use
onto
the
other
network
and
thereby
enable
some
sort
of
complex
transaction
and
also
share
their
legislation
and
we'll
come
to
details
as
we
talk
about
the
weaver
and
the
cactus
projects
later
peter.
Next
type,
please
so
interoperability
can
be
viewed
as
a
the
different
concerns
can
be
viewed
in
different
layers.
So,
if
you
look
at
this
layer,
diagram
think
of
osi
stack
for
networking.
C
We
have.
This
is
sort
of
like
that.
You
can
think
of
concerns
going
from
at
the
bottom
data
going
over
the
wire
and
you
need
to.
We
need
to
ensure
that
two
networks
are
able
to
communicate
over
the
wire
with
delivery
guarantees
negotiating
a
session
and
so
on.
The
standard
networking
then,
but
above
that
you
start
getting
to
more
complexities
and
more
some
things
that
are
specific
to
blockchain
or
distributed
ledger
networks
as
opposed
to
conventional
network.
C
So
we
would
like
to
define
particular
protocols
and
particular
payload
formats
that
are
going
to
be
commonly
used
for
two
blockchain
networks
to
come
further
above
we
want
to
be
able
to
communicate
semantics
of
distributed
legislation
so
as
opposed
to
a
single,
centralized
service
or
some
sort
of
erp
system.
That's
communicating
with
the
remote
entity.
C
C
In
addition,
what
you
would
want
is
some
notion
of
the
the
fact
that
the
data
reflects
the
state
that
has
been
agreed
to
by
a
consensus
of
parties,
so,
in
addition
to
the
raw
data,
you'll
also
need
some
other
something
else,
along
with
the
data
to
convey
the
fact
that
the
end
point
here
is
a
group
of
parties
that
that
are
maintaining
shared
leisure
rather
than
a
single
party.
That's
where
the
state
notion
of
state
and
cryptographic,
proofs
and
identity
comes,
and
about
that
we
can
hear
various
protocols.
C
There
are
different
kinds
of
protocols
and
I'll
talk
about
these
in
the
subsequent
slides.
Further
up,
when
you
go
past
the
actual
message
communication,
we
would
like
to
be
able
to
think
about
standards
that
enable
two
networks
that
are
stay
operating
on
the
same
domain,
to
be
able
to
interoperate
there's
a
standard
called
gs1,
for
example,
which
is
attempting
to
create
specifications
for
all
blockchain
or
dlt
networks
that
are
engaged
in
any
part
of
the
trade
ecosystem.
C
It
could
be
trade
logistics,
it
could
be
trade
finance,
even
payments
further
up.
We
there's
also
concerns
about
governance.
Different
actors
put
up
different
policies,
how
they
govern
their
own
network
members
joining
and
leaving.
What
are
the
update
policies
for
the
ledgers
and
so
on.
So
these
these
parts
are
a
little
more
fuzzy
at
this
point,
but
we
we
need
to
think
a
bit
more
about
them,
but
we
just
put
them
here
to
show
that
those
concerns
are
going
to
arise
sooner
as
in
later
next.
C
Okay,
so
this
diagram
simply
shows
what
are
the
different
scopes
of
interoperability
or
what
is
the?
What
is
the
spectrum
of
possibilities
that
we
can
achieve
if
we
enable
interoperability
among
networks?
If
you
look
at
this
connection
here,
think
of
two
different
ledgers
that
are
running
on
the
same
network
now,
the
sort
of
thing
is
possible
with,
let's
say,
hybridge
fabric
or
ethereum
or
recorder
you
both
these
ledgers
have
their
own
shared
tools
and
they
are
distinct
from
each
other
right.
C
So
interoperability
is
important
even
for
those
two
legends,
even
if
they're
part
of
the
same
network,
you
still
need
a
way
for
them
to
share
information
with
some
assurance,
as
well
as
run
complex
transactions.
Similarly,
you
have
a
legend
one
network
that
needs
to
interoperate
with
a
ledger
running
on
a
different
network.
It
could
run
on
same
dlt
protocol.
The
dlt
protocol
here
could
be
say,
apologies
going
from
there
you
could
have.
C
So
there
are
different
levels
of
interoperability.
Now
when
we
actually
build
the
mechanisms
it
turns
out,
you
can
build
certain
common
mechanisms
that
will
be
applicable
to
all
of
these
different
patterns,
so
that
is
so.
The
interoperability
model
that
at
least
books,
bookstore,
cactus
and
we
are
building,
is
quite
powerful
as
we
as
we
assume
later
going
to
the
left
here.
C
We
we
would
also
like
a
distributed
ledger
to
be
interoperable
with
a
non-distributed
system
like
an
erp
system
and
and
also
relying
on
articles
and
so
on.
And
finally,
there
are
vertical
concerns
like
policy
and
governance,
which
are
a
bit
more
fuzzy
at
this
point,
but
they'll
always
arise
when
you
have
two
different
networks
that
are
being
operated
by
two
different
consortia.
C
The
interest
of
time
probably
move
ahead,
peter
next
slide
yeah.
Okay.
I
think
this
is
the
last
step
before
we
move
into
the
project.
So
what
are
the
unique
technical
challenges
of
interoperability,
as
I
mentioned
earlier,
you
can
think
of.
If
you
think,
of
the
traditional
services-based
world,
it's
fairly
easy
to
communicate.
C
C
Another
network,
then
that
the
information
or
the
state
has
to
be
accompanied
by
some
proof,
and
this
proof
has
to
be
validated
without
the
the
foreign
entity
having
been
able
to
observe
the
ledger
of
the
source
entry,
because
remember
these
two
can
be
two
permission
networks.
So
a
node
in
this
network
does
not
it's
not
privy
to
the
blogs
of
the
ledger
of
this
network,
so
any
consumer
has
to
obtain
an
independently
verifiable
cryptographic
proof
the
validity
used.
That's
really
the
the
key
here.
C
How
the
nature
of
this
proof,
as
well
as
what
denotes
reality,
can
take
different
forms.
Then
we
have
to
also
think
about
data
versus
acid,
so
an
asset
is
we
can
think
of
as
a
something
that
has
it's
a
single
instance,
so
it
it's
some
piece
of
information,
that's
required
on
the
ledger
which
moves
from
place
to
place.
So
if
it
goes
from
one
place
to
another
or
if
it
changes
ownership,
then
you
you
always
have
just
one
copy
of
that.
C
Rather
than
making
copies
wherever
you
go.
Data,
on
the
other
hand,
is
something
that
can
actually
be
copied
from
legit
to
lecture
so
any
or
or
when
you're
moving
it
when
you're
copying
it
from
one
party
to
another,
even
on
the
same
ledger.
So
the
notion
of
data
versus
asset
is
important
because
that
impacts
what
protocol
you
would
use
for
interoperation.
So,
for
example,
if
you
want
an
asset
to
move
from
one
ledger
to
another,
it
will
have
to
disappear
from
the
source
ledger.
C
When,
if
you
want
to
copy
data
from
knowledge
to
another,
you
it
won't
disappear,
you
just
need
to
copy
it,
but
additionally,
you
have
to
provide
some
assurance
that
it
was
valid
state.
Also,
these
activities
must
be
coordinated
without
any
sort
of
central
mediator
or
clock.
So
we
do
not.
We
cannot
assume
that
the
two
networks
are
synchronized
okay,
so
these
are
technical
challenges
and
now
we
can
go
to
the
project
details.
Let's
skip
this
in
the
interest
of
time
period,
and
we
can
maybe
talk
about
this
towards
end.
B
B
So
the
first
thing
I
have
to
say
about
cactus
is
the
safe
harbor.
It
is
an
incubation
status
within
hyperledger,
which
means
it
means
that
it
is
not
in
active
status,
meaning
there
hasn't
been
a
stable,
1.0
ga
release
yet
and
therefore
it's
not
considered
production
just
yet
we
are
hoping
to
get
there
as
soon
as
possible,
but
at
the
same
time
I
don't
want
to
claim
something
that
simply
just
isn't
yet.
So
that's
why
it's
important
to
notice
in
the
beginning
and
then
what
is
it?
B
B
So
that's
where
cactuses
it
is
under
tools,
but
you
could
also
make
an
argument
that
it's
a
library
in
the
sense
that,
if
you're
an
application
developer
whose
scope
on
a
business
applications
just
to
implement
a
specific
feature
connecting
to
a
specific
ledger
or
some
other
pleasures,
then
it
will
feel
much
more
like
just
the
library
quote.
Unquote,.
B
A
few
words
about
the
design
principles,
I'll
be
very
brief.
Definitely
the
most
important
is
secure
by
default.
We're
trying
to
avoid
having
it
to
deal
with
situations
where
the
project
gets
popular.
Everyone
deploys
it
and
then
it
should
start
to
come
up
where
the
insecure
or
unsecure
defaults
are
causing
people
to
have
data
breaches
or
any
sort
of
attacks
that
we
enable
them
on
them.
B
B
B
B
B
Obviously,
there's
an
insane
amount
of
development
resources
required
for
this,
but
this
is
where
the
plug-in
architecture
comes
in
and
I'll
talk
more
about
the
governance
later,
but
for
now
I'll
just
say
that
anyone
anywhere
can
create
a
plugin
for
cactus.
That
adds
support
for
any
lecturer.
That
is
not
currently
in
the
officially
supported
list
of
lectures.
B
So
what
we
are
hoping
to
do
there
is
to
leverage
the
open
source
community
growth
around
the
project
and
then
prevent
double
spending
where
applicable.
This
is
important
to
say,
because
people
have
expectations
regarding
what
they
can
and
cannot
do,
and
I
always
have
to
highlight
that
there
are
public
permissionless
ledgers
out
there
who
do
not
have
transaction
finality
guaranteed
in
the
sense
that,
for
example,
they
they
will
deal
with
proof
of
work
as
the
consensus
algorithm
and
there's
always
the
possibility
of
a
fork,
although
the
probability
of
it
is
decreasing
over
time.
B
Finally,
horizontal
scalability,
which
means
that
we
work
very
hard
on
the
architectural
design
of
the
cactus
api
server
to
make
sure
that
you
can
deploy
any
number
of
them
in
a
cluster
in
an
auto
scaling
group
for
any
other
structure
that
your
cloud
provider
allows
for
and
then,
if
you,
if
you
want
to
read
more
about
these
and
the
use
case
ideas,
we
have
please
visit
the
white
paper
that
I
linked
below
and
then
on
to
our
architecture.
Decisions.
B
B
B
We
want
that
because
we
want
to
lower
the
barrier
of
entry.
We
want
to
be
able
to
deploy
cactus
in
resource
constrained
environments,
maybe
even
cloud
functions
or
lambda
functions,
and
the
name
depends
on
your
favorite
cloud
provider
and
we
use
learner
plus
yarn
to
manage
a
mono
repo,
which
is
the
backbone
of
the
plugin
architecture,
meaning
that
there's
separate
packages
within
the
same
git
repository
which
allows
us
to
quickly
add
new
ones
and
to
have
code
sharing
between
the
backend
and
the
front
end.
B
So
we
have
packages
that
are
cross-platform
and
universal,
meaning
that
they
run
the
same
way,
both
in
node.js
and
in
the
browser,
and
then
the
other
big
decision
we
have
is
to
focus
a
lot
on
test
automation.
We
have
dozens
of
end-to-end
tests
that
pull
up
a
pristine
ledger
for
our
supported
ledger,
such
as
corda
fabric
or
on
bay,
zoo,
iboja,
etc.
B
So
we
have
tests
where
pristine
ledgers
are
being
pulled
up
from
containers
and
then
the
cactus
connector
plugins
are
being
verified
against
those
actual
ledgers,
instead
of
just
doing
mocking
or
stubbing
or
any
other
unit
testing
strategy,
which
is
still
good
and
has
value.
But
it's
not
as
sure
of
a
thing
as
you
actually
testing
your
code
against
a
real
ledger.
B
B
So
that's
why
we
have
the
plugin
architecture
where
we
hope
to
be
able
to
respond
to
these
changes
as
time
passes.
So
we
are
just
basically
in
it
for
the
long
haul
and
then
what
I
promised
a
few
slides
earlier
regarding
the
governance
model.
I
want
to
hash
this
out,
especially
because
this
is
important.
B
B
C
So
before
I
talk
about
the
system,
the
way
we
began
when
you're
thinking
about
what
to
build
for
an
interoperability
platform
was
what
are
the
categories
of
use
cases
we
want
to
satisfy,
and
we
call
them
interoperability
modes
here,
and
there
are
three
of
them:
asset
transfers,
asset
exchange
data
transfers
and
between
these
we
believe
they
cover
the
all
spectrum
of
cross
network
transactions
that
you
would
like
and
I'll
show
them
through
examples.
So
next
slide
peter,
so
asset
transfer
is
indicated
by
the
model
you
see
in
the
top
diagram.
C
Here
you
have
two
networks
and
there's
a
party
in
network
a
which
wishes
to
give
an
asset
to
body
network
b.
So
in
the
beginning
you
have
asset
owned
by
x
and
a
and
y
and
b
does
not
have
it
and
at
the
end,
at
the
end
of
the
transaction,
you're
going
to
have
the
acid
rune
by
y
and
x
does
not
own
that
asset
anymore,
an
example
you
can
see
at
the
bottom.
C
You
can
have
two
different
retail
central
bank,
digital
currency
networks,
and
if
you
have
different
banks
that
are
on
different
networks,
a
bank
may
want
to
transfer
digital
currency
from
its
account
in
one
network
to
that
of
an
account
of
another
commercial
bank
on
the
other
network.
So
that's
the
scenario.
C
C
So
if
you
look
at
the
diagram
at
the
top,
you
have
a
you:
have
two
parties
x
and
y
that
are
members
of
two
different
networks:
a
and
b
x
owns
asset
m
in
network,
a
and
y
owns
acid
n
and
network
b,
and
at
the
end
of
this
exchange,
what
you
want
is
the
assets
to
interchange,
hands
so
y
ends
up
owning
m
in
network.
A
and
x
ends
up
owning
n
network
b
keys.
This
has
to
happen
atomically.
C
So,
despite
the
fact
that
the
two
networks
do
not
have
any
centralized
coordinator,
do
not
have
any
central
clock,
you
want
both
networks
to
you
want
the
asset
to
exchange
hands
in
assets
to
exchange
hands
in
both
networks
or
neither
of
those
exchanges
to
happen.
So
as
an
example,
you
can
see
the
at
the
bottom
consider
a
network
on
the
left,
which
is
managing
bonds
ledger
for
different
commercial
banks
and
on
the
right.
You
have
a
different
banks
that
maintain
currency
accounts
on
a
central
bank,
digital
currency
network
view.
C
C
Actually,
this
is
data
transfer
or
sharing.
As
I
mentioned
a
short
while
ago,
data
is
different
from
asset
in
that
data
is
just
some
state
information.
That's
agreed
to
by
the
parties
the
stakeholders
of
the
ledger,
which
of
which
copies
can
be
made
now
that
the
data
can
actually
be
important
in
driving
forward
the
business
process
or
the
smart
contract
in
a
given
network.
So
this
is
the
the
example
below
conveys
this.
C
C
So
the
reason
for
having
this
letter
of
credit
is
because
of
the
inherent
mistrust
between
the
seller
and
the
buyer
so
of
the
important
exporter,
because
if,
let's
say
the
exporter,
ships,
the
goods,
there's
no
guarantee
you
get
the
payment,
and
if
the
on
the
other
hand,
if
the
importer
makes
the
payment
first,
he
has
no
guarantee
of
getting
goods.
So
that's
what
the
network
on
the
left
is
doing.
The
trade
finance
network
and
it
took
on
the
right
logistics
network-
is
managing
the
shipment.
C
It's
tracking
the
shipping,
so
you
have
a
seller
who's.
Dispatching
goods
wire
carrier,
so
what's
happening
in
this
network,
is
that
you
have
once
a
good
set
dispatch.
A
document
called
a
bill
of
lading
gets
recorded
on
the
on
that
ledger
on
the
network
on
the
right.
Now
that,
if
that
bill
of
lading
were
to
be
shared
with
the
trade
finance
network,
then
the
trade
finance
network
could
enforce
the
payment
obligation
from
the
buyers
bank
to
the
seller
or
actually
to
the
sales
bank.
C
So
today,
when
these
two
networks
are
distinct
and
separate,
we
need
some
sort
of
a
trusted
intermediary
and
usually
that
will
be
the
seller.
But
then
sellers
an
interested
party,
a
seller,
has
an
incentive
to
disable
about
the
nature
of
a
bill
of
lading.
So
if,
if
we
have,
if
we
can
build
a
connection
or
a
data
sharing
pipeline
between
two
networks,
whereby
a
document
like
the
bill
of
trading
can
be
shared
with
assurance,
then
that
makes
the
cross
network
transactions
trustworthy
next
type.
C
So
we
began
when
you're
building
weaver.
We
had
several
different
principles,
so,
unlike
several
systems
that
existed
at
that
time,
like
I
mentioned
a
couple
of
frames,
cosmos
and
polkadot-
also
a
system
like
ethereum
plasma
which
which
are
trying
to
build
a
common
relay
network
that
would
enable
settlement
among
different
side
networks
or
different
side
chains.
So
you
have
a
common
infrastructure
which
is
itself
built
on
blockchain
principles,
which
is
mediating
interaction
between
two
different
networks,
that
is
common
approach
to
interoperability.
C
We
wanted
to
step
away
from
that
and
instead
avoid
such
reliance
and
that
led
to
our
various
design
principles.
So
one
of
them
is
inclusiveness.
We
we
want
to
avoid
approaches
that
are
specific
to
any
particular
dlt.
We
you
can.
If
your
networks
are
running
a
fabric
or
saw
to
the
recorder,
it
should
not
matter.
The
interoperable
networks
must
retain
sovereignty
on
the
processes,
as
well
as
the
rules
by
which
they
govern
access.
So
we
do
not
want
so.
C
Networks
should
be
able
to
determine
when
and
how
they
interoperate
with
another
minimal
trust
footprint,
of
course,
standard
security
principle
privacy
by
design.
That
is
the
any
interaction
between
the
parties
belonging
to
two
different
networks
should
be
private
and
confidential,
and
only
the
interested
parties
should
have
should
be
privy
to
it.
No
intermediaries.
We
do
not
want
any
sort
of
intermediary.
Nor
do
you
want
to
rely
on
industrial
infrastructure.
Now,
as
it
happens,
we
you
know
in
the
viewer
project.
C
We
do
rely
on
some
trusted
identity
infrastructure
in
order
to
facilitate
transactions,
but
not
we
do
not
rely
on
any
infrastructure
for
the
actual
settlements.
We
believe
that
these
this,
that
constitutes
a
minimal
set
of
requirements
and
that
will
facilitate
adoption
and
it
could
be
applicable
to
interoperability
in
different
contexts.
Next
time.
C
So
what
the
left
diagram
is
showing
is
simply
the
different
configurations
by
which
networks
can
interoperate
via
these
relays
and
also
with
existing
erp
systems.
And
if
you
look
at
the
bottom,
we
have
decentralized
identity
registries.
Those
are
also
a
key
part
of
how
you
would
engineer
any
sort
of
cross
network
interaction.
If
you
have
time
to
talk
about
that
in
qnd
I'll
do
that,
but
otherwise
I'll
skip
it
for
now
for
every
protocol
here,
and
that
is
the
data
transfer
asset
exchange
or
asset
transfer.
C
C
So
what
does
this
really
look
like
now?
The
relay
is
built
in
the
form
of
a
using
a
microservice
architecture,
and
this
module
actually
is
very
similar
in
scope,
objectives
and
function
to
the
cactus,
connector
and
peter
will
talk
to
its
end
about
how
does
he's
at
prison
trying
to
integrate
the
weaver
relay
with
the
cactus
connector.
C
So
the
relay
has
two
different
parts:
it
has
a
network,
a
tlt,
independent
part
and
a
dlt
dlt
specific
part,
so
that's
left
and
the
right
respectively.
What
the?
What
does
the
relay
do
now?
Because,
as
you
can
see
in
the
at
the
left
relays
have
to
talk
to
each
other,
so
they
have
to
talk
some
sort
of
protocol
right,
so
this
protocol
we
want
to
be
network
neutral.
It
should
not
be
by
to
any
particular
dlt.
C
You
should
not
have
anything
to
do
with
fabric
or
corda
or
sawtooth,
bezel
or
so
on,
but
then
internally,
when
you
have
two
networks
that
are
trying
to
communicate
instructions
or
communicate
requests
for
state
to
each
other.
There
has
to
be
some
dlt
specific
component
that
can
reach
to
the
peers
and
either
run
a
smart
contact
transaction
or
look
up
some
ledger
data,
but
that's
what
the
boxes
on
the
right
are
showing.
So
these
are
pluggable
modules.
We
call
them
drivers
and
they
are
specific
to
the
particular
dlt
so
for
any
network.
C
What
you
need
to
do
to
make
it
weaver
enabled
and
interoperation
ready,
is
deploy
a
a
common
relay
which
does
not
have
anything
to
do
with
that
particular
dlt
stack
and
then
you
also
plug
in
a
driver
which
is
specific
to
that
particular
dlc.
So
at
present
we
have
drivers
built
for
we
have
the
common
relay
component
built
and
we
also
have
drivers
built
for
fabric
and
cord.
C
We
are
working
on
one
for
bezu,
hopefully
want
to
be
ready
by
end
of
the
year
or
early
next
year,
next
slide,
so
the
relay,
if
you're
wondering,
can
be
deployed
in
several
different
ways.
Now.
This
is
actually
an
important
concern
when
it
comes
to
network
administration.
So
you
have
so
I'm
just
going
to
show
you
how
we
envision
this
happening
in
fabric.
C
So
a
relay
can
be
issued
because
relay
has
to
reach
the
network
right,
so
it
needs
to
have
some
credentials
to
be
able
to
access
the
peers
to
be
able
to
access
ledger
content,
so
in
the
more
in
modern,
a
relay
can
be
issued
credentials
by
one
particular
organization.
So,
if
you
know
hyperledger
fabric,
your
network
is
classified
to
several
different
organizations,
which
are
the
fundamental
units
or
the
members
of
the
network.
C
So
any
of
the
network
can
build
a
relay
and
offer
it
to
the
network
or
issue
credentials
to
that
relay
and
offer
it
to
the
network.
The
reason
this
model
works
is
because
our
relay
is
a
trustless
service.
It
does
not
actually
matter
which
organization
it
belongs
to.
It
will
be
if
we
don't
trust
it
for
anything
other
than
availability.
C
The
relay,
similarly
again
as
model
b
shows
can
be
part
of
the
ordering
service
organization
and
or,
as
model
c
shows,
can
be
its
own
organization
because
of
this
trustless
nature
doesn't
really
matter
how
you
organize
this,
and
similarly,
we
can
deploy,
and
we
have
examples
for
coord
network
as
well,
where
relay
can
be
affiliated
with
a
particular
coda
node,
which
is
one
of
the
primary
members
of
the
network,
or
it
can
be
its
own,
separate,
node
or
it
could
be
even
associated
with
the
notary,
for
example.
Next
slide.
C
Okay,
this
is
a
rather
busy
diagram.
I'm
just
going
to
this
just
serves
to
illustrate
what
the
data
sharing
protocol
that
I
talked
about.
So
without
going
to
details
what
you
have
on
both
sides,
you
can
see
there
are
certain
common
modules
there.
That
is
on
the.
If
you
see
at
the
left
most
end,
you
have
sdk
and
libraries
in
in
the
recorder
network
and
then
in
the
middle,
you
see
you
have
certain
contracts
and
then
at
the
right
you
see
you
have
relay
and
a
driver.
C
What
I
mean
by
that
is
these
are
common
contracts
that
are
that
you
would
deploy
on
all
the
peers
of
your
system,
in
effect
acting
as
library
functions
and
the
steps
of
the
protocol,
which
are
simply
talking
about
how
a
client
in
one
network
can
make
a
request
for
data
which
is
a
state
of
another
network
and
also
provide
a
verification
policy
that
tells
other
network.
What
are
the
standards
of
proof?
C
It's
going
to
accept
and
it's
up
to
the
other
network,
really
it's
triggered
by
the
driver
on
the
on
the
network,
which
will
invoke
the
system
contracts,
as
well
as
the
application
contacts
indirectly,
and
it
will
collect
the
data
as
well
as
the
proof
return
it
to
the
client
on
the
requesting
network,
which
will
then
trigger
a
smart
contract
transaction
in
the
quarter
network.
It's
a
pizza
flow
and
that
can
independently
verify
the
the
proof
against
the
verification
policy
and
update
is
registered.
C
So
this
is
a
quite
a
complicated
protocol
which,
but
at
its
heart
it's
a
request
response
protocol.
It's
just
that
at
the
end
points.
Particular
things
are
happening
via
consensus
on
the
source
network.
That's
the
network,
that's
providing
the
data,
the
right
network
on
the
right
hand,
in
this
case
there
there
are
access,
control
rules
being
run
to
determine
whether
the
request
should
be
satisfied
by
consensus,
because
they're
being
run
on
the
different
peers
and
the
data
is
being
then
provided
with
endorsements
or
signatures,
and
on
the
network
on
the
left.
C
The
proof
is
again
independently
validated
by
the
different
nodes
of
the
quarter
network
within
the
flow
to
ensure
that
the
state
is
actually
valid.
How
do
they
do
this
independent
validation
that
actually
depends
on
some
identity
management
or
the
sharing
of
the
route
and
the
intermediate
ca
certificate?
Okay,
so
that's
part
that
we
haven't
talked
about
here
again,
the
there
are
more
details
on
the
on
our
project
rfcs,
as
well
as
there's
a
paper
that
talks
about
it.
C
C
C
What
what
you
saw
as
system
contracts
in
the
two
sites
before
and
these
manage
proofs,
these
two
asset
lock
management,
because
we
are
also
running
an
hash
time
lock,
contract
to,
in
effect,
asset
exchanges
as
well
as
associated
sdks
for
use
by
any
corda
distributed
application
in
a
recorder
network
or
a
fabric,
client
application
in
fabric
we're
also
working
on
hyperledger
basis
requirement
of
that.
Then
there
is
a
decentralized
identity
management
which
don't
have
time
to
go
into
right
now,
but
we
have.
C
If
you
go
to
our
projects
rfc,
you
see
a
list
of
specifications
on
that.
We
have
a
relay.
We
have
a
support
built
for
data
transfer
for
fabric
in
corda
peso.
Not
it's
not
done
yet
for
asset
transfer
is
a
protocol
that
relies
on
data
transfer.
That's
it
relies
on
the
ability
to
request
for
data
and
validate
the
state,
along
with
proof.
C
Asset
exchange
is
a
protocol,
that's
built
on
the
common
hash
time,
lock
mechanism
which
most
of
you
may
be
aware
of,
and
again
that's
a
presence
supported
for
fabric
in
corda
and
it's
in
the
works
of
bezu
yeah.
So
the
takes
means
that
that
particular
module
or
that
particular
feature
has
been
completed.
The
orange
dot
refers
to
something
that's
going
on
the
gray.
Dot
refers
to
something
that's
not
done
yet
that's
not
being
actively
worked
on
now,
but
will
be
in
the
future.
B
All
right
yeah,
so
the
common
goal
is
to
join
forces
between
the
two
projects
because
there's
strength
in
numbers
and
there's
no
point
in
doing
the
same
thing
multiple
times.
If
we
can
instead
just
make
some
of
those
things
once
and
make
it
better,
because
we
had
more
resources
to
develop
it.
That's
kind
of
the
broad
vision
and
timeline
wise.
You
know
I'm
always
very
careful
to
give
any
sort
of
estimates,
because
everything
always
takes
much
longer
than
we
would.
B
But
it
would
be
great
to
have
something
tangible
in
the
first
half
of
2022
next
year
and
then
we
would.
The
idea
is
that
we
would
merge
some
parts
of
the
project.
We
would
take
it
step
by
step.
It
wouldn't
be
a
big
one-size-fits-all
kind
of
one-off
operation,
but
instead
we
would
gradually
ramp
it
up
and
get
it
better
over
time.
B
B
And
then
the
goal
for
the
common
framework
together
is
to
cover
all
interoperability
modes
or
use
cases,
meaning
that
if
you
read
any
sort
of
interoperability
paper
that
summarizes
the
different
modes
or
if
you
just
look
back
at
the
ones
that
we
talked
about
now,
we
would
ideally
be
able
to
cover
all
of
those
because
it
would
be
flexible
enough
and
that
australian
forces
would
have
more
resources
to
actually
support.
All
of
those,
because
we're
talking
about
a
lot
of
work.
B
And
then
the
merged
framework
would
look
like
it
would
have
a
common
code
base,
but
it
would
be
divided
into
packages,
and
I
have
ideas
about
how
we
could
leverage
github's
code
owners
feature
for
this,
which
means
that
you
can
mark
each
file
or
each
directory
within
the
source.
Tree
is
being
owned
by
certain
maintainers,
and
this
way
we
could
divide
up
the
work
efficiently.
As
in
we
could
sort
of
have
little
patches
of
the
code
that
are
maintained
by
person,
a
and
other
patches
of
code
than
or
maintained
by
person
b.
B
And
so
the
challenges
that
first
and
foremost,
is
that
there's
different
programming
languages
that
the
two
projects
use
cactus
is
written
in
typescript,
the
the
read
the
viva
relay
is
written
in
rust.
Obviously,
drivers
for
the
ledgers
have
to
be
sometimes
written
in
different
languages
that
the
letter
itself
mandates,
but
here
in
this
context,
when
I
mean
weaver,
I
mostly
mean
the
weaver
relay
for
now,
so
that's
written
in
rust
and
then
there's
also
runtime
incompatibilities
of
the
apis,
such
as
right.
B
B
Users
or
consumers
of
the
framework
at
the
end
is
that
you
can
pick
and
choose
your
trade-offs,
because
in
technology
or
pretty
much
anywhere
in
life,
it'll
something
the
decision
that
you
make.
It
always
comes
with
trade-offs,
and
the
best
we
can
do
is
to
give
you
the
option
to
choose
which
trade-offs
you
want,
so
that
you're
not
forced
into
a
specific
one.
B
It's
a
vap
standard
and
it
is
a
binary
instruction
format
for
a
stack
based
virtual
machine
again
that
doesn't
matter
much.
The
the
big
news
here
is
that
it
has
shipped
and
it
is
supported
by
four
major
project-
browser
engines,
the
big
ones,
and
if
you
have
been
in
the
industry
for
a
while,
then
you
know
that
this
is
some
very,
very
special
thing
to
achieve
for
any
kind
of
standard
or
technology,
because
a
lot
of
new
things
that
come
out
in
the
vap
space
are
not
like
that
at
all.
Unfortunately,.
B
And
so
a
little
more
about
how
we
will
achieve
that,
but
I've
been
looking
into
and
made
some
really
good.
Headway
personally
is
to
compile
rustcode
down
into
web
assembly
with
this
tool
called
vason
pack,
which,
at
the
end
of
the
day,
it's
an
extension
to
rust's
built-in
build
tool
called
cargo,
and
it
gives
you
a
lot
of
really
really
helpful
project
templates
for
setting
up
a
rust
project
that
you
can
pretty
much
out
of
the
box,
compile
down
to
webassembly.
B
And
it
has
useful
components
to
deal
with
the
lower
level
mechanical
differences
between
the
javascript
environment
and
the
rust
language
runtime,
meaning
that
it
has
language
primitives,
not
language.
Privileges
are
language,
components
that
allow
you
to
write
an
asyncross
function
that
actually
returns
a
promise
to
the
javascript
layer.
B
So
this
way,
there's
there's
a
much
much
closer
working
together
between
the
two
runtimes
and
then
the
other
thing
it
can
do,
which
is
great,
is
support,
serialization
and
deserialization
into
actual
types.
So
if
you
have
a
class
in
javascript
or
acne
script,
six,
however,
you
wanna
call
it.
If
you
have
a
class
in
there,
you
can
pass
that
into
rust
and
have
it
automatically
convert
into
sorry.
B
B
You
can
load
that
as
a
plugin
into
the
cactus
api
server,
which
is
a
node.js
process,
and
you
can
compile
down
rust
to
webassembly
and
then
also
load
that
as
a
module
into
the
cactus
api
server
and
this
way
for
the
typescript
code
and
for
the
rust
code,
it's
basically
transparent.
If
that
method,
that
they're
calling
at
runtime
is
actually
being
implemented
in
typescript
or
us,
and
for
now
this
has
only
been
proved
for
us,
but
in
the
future
we
can
of
course
foresee
this
happening
to
other
languages.
B
And
we
have
some
reference
materials
here
about
standardization
efforts
in
case
someone
wants
to
do
a
lot
more
reading
and
a
lot
more
research.
Then
there's
a
really
good
initiatives
out
there.
There's
a
lot
of
people
doing
a
lot
of
really
good
work
in
this
space,
especially
within
the
ietf
working
group
and
the
iso.
A
B
C
C
C
C
You
can
run
that
network
and
then
you
can
write
any
sort
of
performance
of
benchmarking
code
on
that
you
can
try
to
use
any
of
the
available
load
generators
to
drive
transactions,
so
the
instructions
show
you
exactly
how
to
run
an
interoperation
query.
This
is
I'm
talking
about
data
sharing,
which
was
our
what
we
mainly
started
off
with.
C
We
also
have
instructions
for
doing
cross
network
asset
exchanges
that
is
using
htlc,
so
you
can
follow
the
instructions
for
each
of
them
and
then
you
have
to
write
your
own
test
harness
on
top
of
that
you'll
have
to
build
a
load
generator
pump
in
a
load
according
to
whatever
traffic
pattern.
You
want
and
write
some
additional
code
to
collect
statistics
like
throughput
and
latency,
and
so.
A
C
Yeah,
so
we
are,
we
almost
have
asset
exchange
going
with
where
one
network
is
hyperledger,
bezu
we're
doing
some
large
final
refactoring
on
the
code
before
we
merge
into
main
but
yeah
that
the
bezu
side
of
it
is
built
on
something
it's
built
on
the
erc20
library,
so
we're
assuming
that
any
fungible
asset.
That
is
that
you
would
like
to
exchange
on
a
baseball
network
in
exchange
for
some
other
asset
on
a
say,
another
basis
network
or
be
it
a
fabric
or
a
coordinator.
C
You
can
do
that.
Just
watch
out
that
the
bazel
support
should
be
both
coming
quite
soon.
We
already
have
fabric
support
for
these
forms
of
asset
exchanges
and
corda
is
mostly
done
or
it
is.
One
version
is
already
done.
We
are
trying
to
refine
it,
but
bezoo
with
erc20
based
assets,
something
basic
got.
A
It
I
know
we
are
a
little
bit
over
time,
so
if
there's
any
other
questions,
I
would
say,
you
know
feel
free
to
reach
out
to
peter
and
ramen.
If
there's
nothing
else
here
again.
Thank
you
both
for
for
volunteering
to
give
this
very
interesting,
and
thank
you
to
the
audience
for
your
questions
and
we
look
forward
to
seeing
you
at
the
next
meet
up
thanks
ann
both
of
you.