►
From YouTube: Making Distributed Ledgers Interoperable Using Weaver (Hyperledger Labs) - Venkatraman Ramakrishna
Description
Making Distributed Ledgers Interoperable Using Weaver (Hyperledger Labs) - Venkatraman Ramakrishna, IBM
The emergence of DeFi and CBDC have created a pressing need for blockchain/DLT interoperability. Several research and development efforts have focused on this challenge, as interoperability is a key ingredient for Web3. In this talk, Ramakrishna will present the unique value proposition of Weaver, a Hyperledger Labs project, and show how it advances the state-of-the-art in DLT interoperability by enabling almost any cross-network operation using a combination of basic interoperability modes. He will describe the Weaver architecture, built on design principles of network self-sovereignty, avoidance of DLT modifications, and eschewing trusted mediators and third-party blockchains. Ramakrishna will show how Weaver implements protocols for cross-network data sharing, asset exchange, and asset transfer, leveraging the networks' native consensus mechanisms. These protocols have been used and validated by the Bank of France and HSBC to communicate ledger state and effect delivery-vs-payment across the boundaries of CBDC and securities networks built on Fabric and Corda. He will conclude the presentation with a list of features and supported DLTs in Weaver and the project's future roadmap.
Sessions Details & Slides (if available): https://sched.co/14H4f
Access All Sessions: https://events.linuxfoundation.org/hyperledger-global-forum/program/schedule/
----
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
Discord: https://discord.gg/rVCn4j7UFd
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 #Blockchain
License
Creative Commons Attribution license (reuse allowed)
A
So
thanks
for
coming
I'm
going
to
talk
about
what
we've
been
doing
with
the
Weaver
last
project
over
the
past.
Well,
it's
a
year
and
a
half
since
the
open
sourced
it.
But
it's
been
a
project.
That's
almost
three
years
in
the
making,
so
I
think
I've
already
explained
the
value
proposition
of
interop
and
probably
to
this
audience
is
not
real
necessary.
You
have.
A
We
have
a
lot
of
different
networks
out
there
which
run
different
Limited
workflows,
and
these
networks
are
built
on
permissioned
dlts
and
the
problem
is
that
once
you
build
such
networks,
they
acquire
life
of
their
own
and
you
don't
really
want
to
expand
or
merge
them
with
other
networks
for
various
variety
of
reasons.
Maybe
privacy,
regulatory
performance
auditability
reasons,
but
in
the
real
world,
these
processes,
the
process
that
these
different
networks
run
like
trade,
Logistics,
Network
and
payments
Network
and
the
kyc
network
they
all
are
symbiotically
related
to
each
other.
A
So
their
needs
to
be
a
way
for
these
networks
to
so
these
networks
eventually
discover
reason
to
have
to
Interlink
or
interoperate
with
each
other.
So
what
we
are
trying
to
do
with
interoperabilities
enable
the
seamless
flow
of
data
and
value
across
different
kinds
of
networks
built
on
heterogeneous
DLT
Technologies,
so
that
they
can.
A
They
can
conduct
transactions
and
do
useful
things
without
being
limited
by
the
network
boundaries,
and
we
won't
do
this
in
a
way
that
preserves
their
production
security,
tenets
all
of
being
able
to
orchestrate
or
enable
cross
Network
linking
also
enable
scale
without
forcing
merging.
So
that's
really
the
what
I
want
to
leave
you
with
on
the
slide
now
different
people
have
different
views
on
what
on
how
to
achieve
this
so
and
people
have
different,
have
had
expressed
different
opinions
on
the
very
definition
of
interoperability.
A
Now,
in
the
previous
panel,
I
talked
about
what
my
definition
of
interoperability
is.
Let
me
just
show
you
a
couple
of
other
views
on
what
people
think
it
is
so.
Interoperability
can
range
from
it
can
range
along
a
spectrum
from,
and
these
different
kind
of
solutions
or
different
kind
of
opinions
can
can
be
expressed
as
to
the
level
of
centralization
or
the
level
of
trust
that
they
they
require,
or
they
use
when
they
are
trying
to
Interlink
two
networks
together.
A
So
if
you
look
at
the
the
first
pattern
here,
you
can
imagine
having
interoperation
across
different
networks
by
just
say,
take
multiple
fabric
networks.
Now,
fabric
networks
are
composed
of
peers
that
are
owned
by
different
organizations.
So
you
have
a
single
organization
that
participates
in
multiple
networks.
A
You
can
imagine
it
running
a
pure
that
has
access
to
all
the
different
networks
Ledges
right,
so
you
can
build
an
application
that
harnesses
the
information
and
the
contracts
on
these
different
ledgers
in
order
to
do
something
useful,
it's
a
form
of
interoperation,
but
again
it
serves
just
that
organization
that
is
running
the
peer
right.
It
does
not
serve
the
networks
collectively.
So
that's
one
limitation
of
that
now.
A
Another
pattern
which
people
have
talked
about
as
interoperability
is
the
is
the
ability
to
have
different
peers
running
on
different
kinds
of
hardware
and
Cloud
infrastures,
to
be
able
to
communicate
or
to
be
able
to
achieve
consensus
on
blocks
as
part
of
a
single
Network.
That's
another
valid
definition
of
interoperability,
but
that's
really
not
what
we
are
talking
about
here.
A
Why
are
these
applications?
The
problem
with
this
is
in
effect
you
have.
We
have
reduced
a
network
to
or
reduce
the
network
to
trusted
proxy,
which
is
really
which
is
his
application.
The
individual
networks
still
run
on
decentralized
principles,
but
once
you
bring
two
networks
together,
you
have,
in
effect
created
a
centralized
scenario,
so
we
do
not
want
we
do
not.
Ideally
we
do
not
want
that.
A
So
what
we
wanted
to
try
and
Achieve
was
a
deeper
level
of
interoperation
where
networks
can
interact
with
each
other
in
a
decentralized
manner
without
requiring
any
kind
of
trusted
proxies.
That
is,
the
applications
would
continue
to
run
on
their
respective
ledgers,
but
they
would
not.
You
would
not
use
any
of
those
applications
with
say
using
a
particular
wallet
identity
as
a
a
trusted
conduit
to
a
different
network.
So
what
exactly
are
we
trying
to
achieve?
A
So
we,
our
observation,
was
that
we
could
in
effect,
boil
down
the
different
kind
of
scenarios
you
want
to
achieve
across
networks
to
three
kind
of
patterns,
data
sharing,
asset
exchange
and
asset
transfer.
Data
sharing
means
the
ability
to
communicate
Ledger
records
across
two
distinct
ledgers
and
to
be
able
to
link
two
different
smart
contracts
together.
I'll
show
you
an
example
in
the
next
slide
asset
exchange
simply
to
understand
you
want
to
be
able
to
swap
assets
across
across
ledgers,
and
you
want
to
do
this
in
an
atomic
way
asset
transform.
A
You
have
an
asset
on
one
Ledger
and
you
want
to
move
it
to
a
different
Ledger
for
some
business
purpose.
So
how
do
you
achieve
that?
So
data
sharing
here
is
the
model.
You
have
two
networks:
Network
one
has
the
there
is
a
contract
that
Simplicity
here,
but
there
is
a
data
record.
That's
on
the
on
the
Ledger
and
network
B
is
running
another
contract
or
a
business
workflow
which,
for
some
reason
needs
this
data
record
on
this
particular
Network.
Now,
what
would
you
do?
A
Ordinarily,
you
could
have
Network
B
would
ordinarily
just
have
a
process
whereby
a
client,
some
client
would
be
trusted
to
fetch
this
data
record
from
this
network
and
the
supply
that
is
transaction
to
this
network,
and
it
should
validate
it
right
before
commitment.
Instead
of
that,
if
we
can
have
a
process
by
which
network
B
can
in
an
Institutional
way
request
this
data
record
from
Network
a
and
then
get
a
response
which
is
generated
along
with
State
proof
and
using
network
is
consensus
and
further
before
Network
beak
consumes
that
information.
A
It
also
validates
that
information
using
consensus.
That
would
be
great
because
what
you
achieved
now
is
the
way
by
which
we
we
have
created
a
thick
Pi
between
these
two
networks,
whereby
information
can
flow
between
groups
of
parties
without
requiring
any
other
trusted
proxy
in
the
middle
and
the
two
networks
now
can
be
in
sync,
and
this
can
be
very
useful
in
a
lot
of
scenarios.
One
of
which
I
will
point
out
here
is
here:
is
a
trade
Finance,
Network?
A
Okay,
this
diagram
looks
complex,
I'll,
just
give
you
the
elevator
pitch
the
trade
Finance
Network
processes,
letters
of
credit
using
it's
an
instrument
by
which,
when
a
seller
or
an
exporter,
ships
Goods
to
a
buyer
or
an
importer,
the
buyer
is
obligated
to
make
a
payment
to
the
seller.
Now,
in
order
to
for
the
seller,
to
ask
the
buyer
to
make
a
payment,
the
seller
has
to
provide
some
evidence
that
they
have
shipped
the
goods.
So
where
does
that
evidence
lie
now
in
the
real
world?
A
So
in
the
real
world,
shipping
involves
both
processing
Consignment
documentation
as
well
as
financing,
but
you
have
different
networks
that
are
doing
these
different
tasks,
so
you
have
the
evidence
of
the
seller
having
shipped
the
goods
on
this
particular
Ledger
on
the
trade
Logistics
Ledger
in
the
form
of
a
document
called
the
bill
of
reading
on
the
trade
Finance
Ledger,
you
have
a
document
called
the
letter
of
credit,
which
needs
a
valid
bill
of
aiding
in
order
to
ask
a
buyer
to
make
a
payment
to
the
seller.
So
what
can
we
do
here?
A
Yeah
in
step
number
11:
if
the
trade
Logistics
Network
can
supply
a
bill
of
lading
to
the
trade
Finance
Network,
then
the
trade
Finance
Network
knows
that
it.
That
is,
that
the
seller
has
dispatched
the
goods
that
it
was
obliged
to
and
therefore
the
buyer
needs
to
make
a
payment
to
the
seller.
In
the
absence
of
that,
what
would
the
trade
Finance
Network
have
to
do?
A
It
would
have
to
depend
on
seller
to
provide
a
bill
of
lading,
but
then
the
seller
has
an
incentive
to
supply
a
fake
bill
of
lading
in
order
to
get
payment
from
the
buyer.
So,
by
having
these
two
networks
link
and
one
network
fetch
a
data
record
from
the
other
network
through
an
interoperation
Channel,
we
can
avoid
these
kind
of
Hazards,
whereby
one
particular
party
can
hijack
a
business
workflow
in
this
particular
workflow.
A
We
also
added
another
step
whereby
the
trade
Logistics
Network
can
fetch
a
bill
of
leading
or
a
valid
letter
of
credit
from
the
trade
Finance
Network.
So
we
have
shown
that
because
this
particular
example
is
not
limited
to
like
bills
of
leading
or
trade,
but
it's
really
it.
It
can
be
generalized
to
any
sort
of
data
record,
any
sort
of
artifact
that
you
would
want
to
share
across
two
different
Ledges
across
two
different
business
processes.
A
Okay,
asset
exchange
is
a
case,
where
is
a
very
different
case
of
data
sharing,
but
it's
also
a
part
one
of
the
building
blocks
of
interoperation.
You
have
in
network
a
party
X
owned
an
asset
M
and
network
B
party
y
owns
an
asset
n,
and
the
outcome
you
want
is
y
gets
M
from
X
in
the
first
Network
in
exchange
for
giving
n
to
X
in
the
other
network.
Now
what
is
the
challenge
here?
The
challenge
is
that
this
needs
to
happen
in
an
atomic
manner.
A
You
don't
want
the
final
outcome
where
this
transfer
happened,
but
this
is
not
happen
or
vice
versa,
so
doing
that
across
two
different
ledgers
with
which
have
completely
different
governance,
which
are
completely
independent
of
each
other.
That
is
a
big
challenge
and,
as
an
example
there's
a
delivery
versus
payment
which
you
heard
in
the
previous
panel.
A
One
network
manages
bonds,
another
Network
managers,
currency
accounts,
and
if
you
have
two
parties,
A
and
B,
which
have
accounts
on
both
on
both
these
ledgers,
a
can
sell
a
bond
to
B
on
one
network
in
exchange
for
payment
on
the
other
network
in
an
atomic
manner.
If
this
kind
of
an
asset
exchange
feature
were
available,
and
finally,
the
asset
transfer
case
feature
is
one
where
you
want
one
party
in
one
network
to
be
able
to
transfer
an
asset
owns
to
a
different
party
on
a
different
network.
A
I
mean
in
this
case
X
and
Y
could
be
the
same,
but
in
the
most
General
case
they
are,
they
can
be
different,
so
what's
happening
here
is
that
the
the
asset
gets
expunged
from
one
network
and
gets
recreated
in
another,
maybe
in
a
somewhat
different
form,
but
an
equivalent
form.
Something
which
both
networks
have
agreed
is
is
an
equivalent
form.
A
As
a
combination
of
these
these
scenarios,
data
sharing
asset
exchange
and
asset
exchanges
and
asset
transfers
collectively
can
cover,
like
almost
all
of
the
use
cases
you
imagine
when
you
bring
two
different
blockchain
networks
or
two
different
DLT
networks
together
and
just
from
a
modeling
perspective,
we
can
think
of
it
in
this
way.
You
have
a.
If
you
imagine
dependency
the
cross
networks.
A
You
can
imagine
unidirectional
dependency
where
read
in
one
network
triggers
the
right
in
another,
and
that
is
the
data
sharing
use
case,
and
then
you
can
imagine
bi-directional
dependencies
where
write
in
one
network
triggers
the
right
in
another,
but
that's
both
have
to
happen.
Atomically
and
that's
and
the
two
kinds
of
scenarios
we're
talking
about:
there
are
asset
transfer
and
asset
Exchange.
A
Okay,
so
there
are
unique
challenges
we
face
for
DLT
interoperability,
which
we
did
not
face
in
the
traditional
centralized
service
interoperability
case,
mainly
that
the
authority
of
a
state
lies
in
a
collective
and
the
protocol
or
the
consensus
protocol
that
the
employee
to
ensures
Integrity.
So
if
it
is
just
single
party,
as
long
as
you
trust
the
party
that
is
supplying
information
or
that
is
translating
asset
to
you,
you're
good
interoperability
is
just
a
matter
of
ensuring
that
both
of
you
follow
the
right
message
formats.
A
But
when
it
comes
to
two
multi-party
networks,
it's
not
so
straightforward.
You
have
to
be
able
to
trust
the
information,
that's
coming
from
a
network,
and
you
cannot
really
boil
it
down
to
trusting
a
single
peer
in
that
Network,
because
single
peer
can
always
lie,
and
every
network
is
geared
to
guard
against
a
single
peer
line.
But
what
does
the
foreign
Network
do?
Because
the
foreign
network
does
not
participate
in
the
consensus
protocol
for
given
Network
right?
So
that's
the
really
the
main
challenge.
A
Now,
when
we
were
starting
to
investigate
a
viewer,
we
we
saw
solutions
that
were
out
there,
which
involved
this
kind
of
pattern.
So
the
pattern
here
I
am
showing
is
the
you
build
yet
another
blockchain
or
a
settlement,
Network
or
settlement
chain,
to
which
you
can
your
network
can
plug
in
as
a
as
a
side
chain
and
then
via
the
settlement
Network.
So
the
settlement
Network
provides
the
assurances
whereby
two
different
site
change
can
do
the
kinds
of
things
that
I
talked
about.
A
They
can
share
data,
they
can
transfer
assets
or
they
can
exchange
assets.
But
the
problem
with
this-
or
at
least
one
drawback
with
this-
is
that
you
have
to
depend
on
the
settlement
chain
and
there
are
the
way
you
connect
or
plug
into
this
ecosystem
is
intrusive.
You
need
validators
that
are
belonging
to
the
settlement,
Network
that
have
to
be
part
of
your
network
and
the
privy
to
your
private
information.
So
this
kind
of
solution
works.
A
If
all
of
these
networks
are
already
open
public
networks,
but
for
private
networks,
they
seem
to
us
like
a
suboptimal
solution.
How
do
you
get
private
networks?
How
can
you
enable
private
networks
to
be
able
to
interoperate
without
having
to
surrender
their
sovereignty
in
some
ways
to
another
Network
and
also
and
to
guard
the
Privacy?
So
that
was
the
challenge
we
set
out
to
solve
and
we
we
wanted
to
achieve
something
like
this
and
the
this
is
what
we
have
we
have
done
in
the
past
three
years.
A
So
for
as
an
example,
you
can
see
what
we
want
to
do
and
what
we
can
do
with.
The
word
is
allow
two
networks
to
directly
interact
with
each
other
without
any
kind
of
settlement
it
took
in
the
middle,
not
any
kind
of
trusted
proxy,
so
that
is,
we
feel
that's
less
constricting
a
way
of
doing
interoperation
and
for
permission
networks.
This
is
really
the
more
optimal
way
of
doing
interoperation.
A
So,
to
give
a
brief
history
of
the
viewer
project,
it
began
as
a
as
an
IBM
research
project
in
2019,
and
we
identified
the
kind
of
use
cases
that
we
thought
were
covered:
the
spectrum
of
interoperability
and
end
of
2019.
We
built
a
prototype
linking
two
different
fabric
networks
that
are
modeled
Loosely
on
the
trade
lens
and
the
V
trade
networks,
and
we
published
a
paper
in
middleware
that
established
the
the
basis
and
the
engineering
engine
engineering
principles
for
such
interoperability
to
happen.
In
2020
we
extended
support
for
coder
networks.
A
We
made
the
code
quite
modular
and
finally,
in
the
in
early
2021,
you
open
source.
We
were
under
hypology
Labs,
since
the
latter
part
of
that
year,
we've
been
having
discussions
with
the
hyperlegic
actors
team
and,
as
I
think
you
all
know.
You
know
now
we're
going
to
merge
Vivo
with
cactus
to
form
hypoallergic
acrylic.
So
there's
some
links
here,
I'll
come
to
I'll
show
you
the
links
towards
the
end
as
well.
So
just
a
shout
out
to
our
our
team
we
have
between
us.
A
We
have
four
researchers
and
developers
who
are
working
either
full-time
part-time,
and
then
we
have
vinayaka
who's.
Our
research
manager
and
thought
leader
he's
been
involved
in
this
space
for
for
four
years
now,
so
we
were
built
on
several
design
principles
that
are
really
we
want
that
are
really
important
to
understand,
and
we
wanted
to
make
sure
that
we
built
a
system
that
satisfies
these.
Inclusiveness
means
that
we
do
not
want
to
build
a
system
that
enforces
a
particular
approach
that
tied
to
a
given
DLT.
A
So
we
do
not
want
to
build.
We
were
to
be
fabric
like
interoperability,
solution
or
a
or
an
ethereum
like
interoperability
solution.
We
wanted
it
to
be
completely
neutral
to
that,
while
accommodating
both
Fabric
and
ethereum
and
Coda,
and
and
what
have
you
and
any
network
that
you
can,
you
might
Envision
creating
in
the
future
the
networks
we
wanted
to
be.
We
wanted
to
ensure
that
the
networks
retain
sovereignty
over
their
own
governance
processes
and
their
asses
control
rules.
A
So
if
you
imagine
interoperability
of
the
kind
that
talked
about
sharing
data
exchanging
assets
transferring
assets,
there
is
some
sort
of
intrusion
happening
in
the
network,
so
you
cannot
actually
allow
the
known
Network,
especially
if
it's
built
on
a
on
the
permission
principle.
It
would
not
want
anybody
to
just
poke
into
its
Network
and
say
extract
an
asset
right.
Whatever
is
happening
in
a
in
a
crosstalk
scenario
has
to
be
fully
under
the
control
of
a
network.
A
So
access
control
is
really
a
core
primary
feature
that
we
wanted
to
provide
for
the
networks
when
they
are
in
a
cross.
Network
scenario:
a
minimum
trust
I
will
talk
about
this,
the
net,
any
interaction
between
parties.
Two
networks
should
be
private
and
confidential
and
only
reveal
to
the
interested
parties.
We
do
not
want
to
rely
on
any
intermediary,
whether
it
be
sorry
whether
it
be
a
that's
a
third
party
or
a
common
settlement
network.
A
Any
in
shared
infrastructure
we
relied
on
would
be
minimal,
I,
say
minimal,
because
we
ended
up
discovering
that
we
need
date
infrastructure,
for
example,
in
order
to
be
able
to
establish
a
trust
basis
for
two
networks
to
interoperate.
So
that's
something
that
I
don't
think.
I
have
the
scope
to
cover
today,
but
I'll
just
leave
you
with
that,
and
we
can
have
offline
Chats
on
that.
A
If,
if
you,
if
you're
interested
in
it,
we
wanted
to
leverage,
we
wanted
a
system
or
an
interoperability
system
protocol
which
would
leverage
the
native
consensus
Protocols
of
the
respective
networks
rather
than
using
n
any
other
kind
of
consensus
mechanism.
The
whatever
is
happening
in
the
respective
networks
should
respect
and
follow
the
consensus
rules
that
have
already
been
set
out.
We
did
not
want
to
impose
any
other
kind
of
consensus
logic
over
what
was
already
supported.
A
What
this
ensures
is
that
any
interpretation
enabled
using
viewer
would
be
as
trustworthy
as
the
Network's
existing
transaction
commitment
processes
and
we.
Finally,
we
did
not
want
to
require
any
changes
to
the
core
d80
platforms,
so
Viva
does
not
require
a
fork
of
fabric
or
cord
or
ethereum
or
phone.
So
these
are
slanted
list
of
principles,
but
we
wanted
to
make
sure
that
we
provide
a
solution
that
that
ensures
all
of
these,
because
we
believe
that
this
constitutes
an
optimal
set
of
requirements
for
permission.
A
Networks,
so
OK
I
have
I
think
I
have
time.
You
have
time
to
six
right.
That's
what
time
do
we
end
yeah?
So
let
me
see
how
much
I
can
cover
here,
I'd
like
to
mention
that
we
have
a
tokens
Workshop
tomorrow,
where
we
will
be
covering
scenarios
where
viewer
was
actually
used
in
a
in
a
real
experiment,
and
that
involved
not
just
fever
but
the
fabric
token
SDK
as
well.
A
So
if
I
can't
cover
some
protocols,
please
try
to
attend
that
workshop
and
we
will
be
covering
that
tomorrow.
So
we
were.
This
is
the
vision
you
have
a
network
and
with
river.
What
we
were
adds
to
a
network
is
something
called
a
relay
along
with
the
protocol
driver
using
which
it
can
communicate
or
interact
with
the
different
network
that
similarly
employs
a
relay
and
driver,
and
the
arms
of
the
triangle
simply
show
the
three
different
interoperation
modes
as
a
transfer
data
sharing
and
asset
exchange.
And
what
exactly
is
the
relay?
A
So
the
protocol
drivers
understand
the
DLT
protocol.
The
relay
part
of
it
does
not.
The
relay
part
of
it
is
just
running
a
completely
neutral
protocol,
which
is
DL
technostic,
so
views
are,
is
a
concept
that
we
introduced,
which
is
akin
to
the
Views
that
you
would.
You
can
imagine
in
a
traditional
database
right
in
a
database.
A
view
is
just
some
procedure
that
you
run
to
extract
some
data
from
a
database.
A
So
we
are
just
extending
that
concept
for
cross
Network
scenarios,
and
we
are
what
the
core
feature
that
we've
built
in
Weaver
is
the
ability
for
one
network
to
generate
a
to
supply,
a
view
address
which
looks
something
like
a
URL
and
which
it
can
communicate
to
a
different
network
and
and
then
that
Network
can
supply
the
information
by
parsing.
This
particular
view
address.
So
this
is
a
feature
whereby
you
can
run
queries
across
networks
and
the
the
this
is
part
of
the
building
block
of
all
the
protocols
that
Weaver
provides.
A
So
if
you
can
imagine
this
simplified
Network
network
communication,
you
have
two
networks
consisting
of
a
group
of
peers
and
the
relay
is
communicating
enabling
communication
across
them.
So
the
relay
supports
the
ability
to
address
remote
views
so
Network.
This
network
can
supply
a
view
address
for
this
network
to
the
relay,
which
can
then
communicate
with
this
relay,
which
will
then
fetch
a
view
corresponding
to
that
view.
Address
and
Supply
it
back
to
this
network.
A
So
you
can
have
an
end-to-end
request
response
protocol
that
way,
and
we
can
also
we
imagine
doing
more
complex
operations
across
networks
like
having
a
contract
in
one
network,
invoke
a
contract
in
another
or
publish
events
and
subscribe
to
events
across
Network
boundaries.
So
the
relays
that
act
as
communication
modules
and
the
networks
act
as
validation
and
commitment
modules
going
to
what
the
networks
are
doing
further
here
is
the
set
of
operations
that
each
Network
needs
to
do
in
order
to
run
the
kind
of
protocols
that
you
want.
A
Access
control,
the
ability
to
generate
proof
of
legis
State
the
ability
to
independently
validate
such
registry
tools.
So
if
one
network
generates
some
proof,
the
other
network
must
be
able
to
independently
validate
that
without
having
to,
let's
say,
offer,
get
privileged
access
to
The
Ledger
of
this
network.
The
networks
must
be
able
to
lock
or
pledge
assets,
and
then
they
be
able
to
claim
them.
A
So
if
you
attended
the
interoperability
formalization
presentation
a
couple
of
hours
ago,
the
ability
to
lock
an
asset
is
a
key
enabling
feature
for
either
asset
transfers
or
asset
exchanges
without
the
ability
to
lock
assets,
especially
in
a
time-bound
manner.
A
network
cannot
be
deemed
to
be
interoperable,
but
most
proxy
networks
today
have
the
ability
to
do
that.
So
that's
something
that
we
can
rely
on
when
we
augment
the
network
with
Weaver
capabilities.
A
So
our
claim
is
that
there's
a
complete
set
of
building
blocks
to
realize
any
cross
Network
dependency,
so
I
mentioned
the
three
modes
or
the
three
different
kind
of
use.
Cases
that
we
were
supports.
Data
sharing
is
simply
the
ability
to
generate
and
verify
proof
and
does
the
request
response
protocol
across
two
different
networks
to
enable
that
one
network
requests
another
Network
for
some
Ledger
data.
The
supply
network
generates
proof
associated
with
the
data,
and
the
consumer.
Network
verifies
proof
that
accompanying
that
particular
data,
so
that
requested
some
protocol
achieves
that.
A
So
we
implemented
that
protocol
in
Weaver
and
and
at
present
we
are
working
on
augmenting
that
protocol,
making
it
more
fail,
safe
and
automated.
So
the
Weaver
architecture
consists
of
these
components.
So
let
me
just
mention
what
you
would
need
to
do
as
a
network
administrator
and
as
a
developer
as
a
network
administrator,
you
will
have
to
deploy
a
relay
and
a
driver
which
automatically
comes
with
viewer.
A
All
you
need
to
do
is
take
the
Reliant
driver
from
the
Weaver
code
base,
build
it,
and
you
just
need
a
configuration
file
that
you
have
to
adapt.
Sorry,
you
have
to
adapt
to
your
particular
Network.
The
interpretation
module
is
again
it's
a
built
in
the
style
of
a
contract
or
a
dab
so
in
fabric.
This
is
built
as
a
chain
code.
So
all
you
need
to
do
is
to
deploy
the
fabric
interoperation
chain
code
on
your
channel
and
your
network
will
be
Weaver
enabled
or
into
operation
ready
in
Coda.
A
We
Supply
this
equivalent
of
this
as
a
cord
app
and
the
recorder
distributor
application,
and
it
performs
similar
set
of
features.
What
are
the
set
of
features?
I
mentioned
that
a
couple
of
slides
ago,
gender
proof
validate
proof,
lock,
assets
claim
assets
and
so
on.
Finally,
there
are
application,
helpers
or
Library
functions
which
allow
any
client
application
to
be
able
to
trigger
transactions.
Using
the
in
order
to
share
to
make
two
Network
share
data
or
to
be
able
to
to
trigger
an
asset
lock
or
an
asset
claim,
or
an
asset
transfer,
so
yeah.
A
So
this
is
the
difference
between
a
traditional
fabric,
application
with
the
the
peer
smart
contracts
and
the
layer,
2
and
Weaver,
and
a
we
were
augmented
one.
You
can
already
mention
this.
I
won't
go
into
the
details.
I
think
I
want
to
yeah
I
want
to
stop
in
a
couple
of
minutes
for
questions.
Maybe
we
can
go
into
the
other
parts
of
it
in
the
Q
and
let
me
just
cut
to
the
yeah.
A
Ok,
so
Viva
provides
I
mentioned
the
SDK
that
we
have
provided.
So
what
does
this
look
like
exactly
so
suppose
you
want
to
trigger
a
cross
network
data
sharing
request
as
a
developer,
you
can
use
the
fabric
node
SDK
now,
for
in
fabric
we
offer
for
fabric
networks,
you
offer
the
SDK
both
in
node
and
in
go
and
Corridor.
You
offer
it
in
kotlin
again.
A
These
are
the
native
languages
that
you
would
use
to
program
on
the
respective
dlts
so
in
fabric
to
be
able
to
trigger
a
cross
network
data
sharing
request
as
a
developer.
You
just
need
to
call
this
interrupt
flow
function.
Now
this
has,
it
has
a
laundry
list
of
parameters
looks
complicated,
but
it's
just
single
function.
It
is
sort
of
like
submitting
a
job,
so
what
you
would
do
is
you
would
create
a
view
address.
You
would
that's
one
of
the
parameters
of
this
interpolo
function
and
what
happens
is
the
query
goes
to
the
relays.
A
It
goes
to
the
other
network,
proof
is
generated,
then
proof
comes
back
and
a
local
commitment
is
triggered
and
the
proof
is
validated
and
committed.
Assuming
everything
goes
right.
So
all
of
that
happens
via
just
this
interflow
function,
so
we
are
trying
to
make
it
as
easy
for
the
developer
as
possible
to
run
the
cross
network
data
sharing.
Similarly,
this
is
the
this
is
for
the
equivalent
for
a
quarter
Network.
This
is
the
same
interpolo
function.
You
have
again
list
of
parameters,
so
I
am
going
to
skip
those
these
ok.
A
So
what
is
the
status
of
viewer
so
far?
We
have,
as
you
can
see,
we
need
some
common
appliances.
The
relay
as
a
common
Appliance
exists.
You
need.
We
need
to
build
drivers
for
every
DLT
separately.
So
right
now
we
have
support,
we
have
drivers
of
fabric
and
Corridor
and
we
are
trying
to
build
a
driver
for
hypology
bezoo.
We
have
more
support
for
fabric
and
cord
as
compared
to
base
with
this
point,
but
that's
something
we
are
actively
working
on.
A
A
Would
then
Channel
those
events
or
publish
those
events
to
the
subscriber
decentralized
identity
is
something
we've
been
working
on
as
a
trust
basis
for
these
interoperation
to
happen,
because
what
we
need
in
order
for
two
networks
to
be
for
two
permission,
networks
to
be
able
to
generate
and
validate
proof
is
be
able
to
know
who
their
respective
certificate
Authority
certificates
are
and
validate
any
members
of
those
networks
against
those
CS.
So
we
need
the
ability
to
communicate
group
identities
and
CA
certificates
across
Network.
A
So
that's
what
this
particular
feature
is
all
about,
so
for
to
contribute
to
Weaver
you
can
or
to
use
fever.
You
can
just
go
to
the
documentation.
We
have
a
tutorials
that
help
you
get
the
viewer
samples
up
and
running
from
start
to
finish.
The
instructions
are
all
perfectly
clear
and
also
if
you
have
an
existing
Network,
you
want
to
adapt
for
Weaver
you.
There
are
instructions
for
that.
A
If
you
want
to
contribute
to
viewer
and
or
gain
more
information,
please
go
to
the
rfcs
folder
or
read
research
papers
that
are
in
the
overview
page
I
promise.
They
are
fairly
easy
to
read.
So
in
the
real
world,
this
is
something
I
mentioned
yesterday
as
well
and
I'm
not
going
to
talk
in
detail
about
this
to
find
out
about
the
use
case
involving
cbdc's
and
the
experiment
done
by
the
bank
de
France
and
HSBC
do
attend
the
tokens
Workshop
tomorrow
and
you'll
get
all
the
download
on
that.
A
There
is
standardization
effort
going
on
again
this
something
Raphael
and
dinakaran
talked
about
earlier.
Secure
asset
transfer
protocol
and
there's
several
links
here
for
your
inspection.
I
think
this
is
the
most
important.
We
do
solicit
involvement
from
anyone
with
an
interest
in
an
opinion
on
this
topic.
So
please
subscribe
to
the
mailing
list.
You're
welcome
to
join
the
weekly
meetings
at
9am
eastern
time
and
just
to
give
you
the
report
on
what's
going
on.
A
So
the
goal
of
this
is
this
effort
is
to
use,
is
to
create
or
offer
Network
gateways
that
are
compatible
with
a
universal
DLT
and
app
neutral
protocol,
whereby
two
gateways
working
for
on
the
behalf
of
two
different
networks
can
communicate
with
each
other
and
they
can
trade
assets
or
communicate
data
with
each
other.
If
we,
the
these
gateways
are
trying
to
keep
the
networks
behind
them
opaque
and
make
sure
that
we
are
not
hamstrung
by
any
particular
DRT
protocol.
A
That
is
the
this
gateway
to
Gateway
protocol
or
what
you
call
satp
is
not
specific
to
fabric
or
ethereum
or
cordon,
and
so
on.
So
that's
what
we
have
and
we
have
several
features
in
the
pipeline
again,
one
of
the
major
things
we're
going
to
be
doing
is
merging
with
cactus.
So
that's
going
to
occupy
our
time
for
the
moment,
so
thank
you
be
happy
to
take
any
questions.
If
we
have
time.
A
At
this
point,
I'm
not
exactly
sure
I
think
then
a
current
can
probably
offer
a
more
informed
opinion.
We
have
been
trying
to
understand
what's
the
best
way
to
build
a
a
driver
for
bezo
and
it's
it's
a.
It
involves
somewhat
different
logic
from
what
we've
used
in
both
Fabric
and
Coda.
So
I
don't
have
a
complete
answer
to
that
right
now.
But
if
you,
if
you
can
yeah.
C
Yeah
the
question
I'd
ask
is
why
what
would
restricted
the
bases
so
unless
you're,
using
private
transactions
or
the
Privacy
modes?
If
you
just
stick
to
Json
RPC
and
the
standard
ethereum
calls
they're
in
that
in
the
standard
evm
contracts
and
don't
rely
on
any
specific
basis,
specific
pre-compiles,
it
should
transport
any
evm,
Json
RPC
system
out
there,
whether
it's
Geth
or
whether
it's
Avalanche
or
some
other
chain,
like
that
good.
D
C
E
A
A
A
Not,
it
should
not
end
up
being
a
trusted
proxy,
so
our
protocols
ensure
that
any
data
that's
going
over
the
relay
is
already
encrypted
and
it's
already
signed
so
that
when
you
get
the
data
at
the
other
end,
that
is
in
the
network
across
the
other
relay,
then
the
decryption
happens
only
pause.
The
relay
and
the
signature.
Validation
can
also
happen
there.
A
So
the
relay
is
already
trusted
to,
or
does
not
need
to
be
trusted
to
to
not
Mount
man
in
the
middle
attack,
for
example,
because
it
can't
at
least
modulo
the
strength
of
the
cryptographic
algorithm
but
yeah,
for
it
could
potentially
mount
a
denial
service
attack.
But
for
that
you
should
have
enough
redundancy
in
your
release
and
viewer
allows
you
to
configure
multiple
relays.
Yeah.
A
Yeah,
so
I
will
mention
one
more
so
the
asset
exchange
protocol
that
I
mentioned
is
we.
We
have
built
the
support
for
the
hdlc
protocol
or
the
hash
time
log
protocol
that
by
itself
has
some
points
of
inefficiency
or
vulnerability
and
what
we
are
trying
to
do
with
one
of
the
hyperledger
interns.
Who's
who's
been
working
with
us
over
the
summer
is
try
to
add
more
Automation
and
failover
to
the
HDFC
protocol.
So
this
involves
doing
some
research
as
well
as
doing
some
redesign.
A
So
we,
hopefully
one
of
our
goals,
is
to
be
able
to
build
an
hdlc
actually
in
augmented
htlc
protocol
that
can
actually
work
in
production,
because
when
you
talk
to
different
clients,
companies
or
governmental
institutions,
they
are.
They
are
really
concerned
about
the
performance
of
asset
exchanges.
A
So
if
we
can
provide
a
mechanism
whereby
we
can
guarantee
that
asset
exchanges
will
have
happen
and
because
the
basic
htlc
protocol
kind
of
depends
on,
if
you
think
of
Alice
and
Bob
as
the
two
exchanges,
Alice
and
Bob
just
doing,
the
right
thing
is
the
right
time
and
Alison
Bob
have
incented
to
do
so,
but
in
the
real
world
at
least
when
you're
using
this
protocol
for
a
lot
of
financial
transactions,
you
don't
just
want
to
depend
on
that.
You
want
the
system
to
be
somewhat
more
robust.
A
So
that's
what
we
are
trying
to
do
and
in
order
to
build
a
more
robust
asset
exchange
protocol,
we
are
building
capabilities
that
involve
the
relays,
communicating
information
about
logs
and
and
proofs
and
enforcing
claims,
even
if,
let's
say
Alice
or
Bob
fail
to
do
so.
So
again,
this
is
a
longer
discussion,
but
just
in
a
nutshell,
hdlc
as
we
implemented
right
now,
it
depends
on
users
driving
the
protocol,
but
we
are
instituting
more
automation,
failover.