►
From YouTube: Formalizing and Standardizing Blockchain Interoperabi... Dhinakaran Vinayagamurthy & Rafael Belchior
Description
Formalizing and Standardizing Blockchain Interoperability - Dhinakaran Vinayagamurthy, IBM & Rafael Belchior, Blockdaemon & Técnico Lisboa
With more blockchain networks being developed for specific applications and across layers of the stack, interoperability has emerged as one of the crucial features of blockchain technology to expand the blockchain tenets across multiple independent blockchain networks. Still a maturing technology, blockchain interoperability is undergoing research and development of solutions with different properties and tradeoffs. The technology necessary for achieving it is fragmented and a formal approach to the problem of general-purpose blockchain interoperability is still lacking. In this talk, Dhinakaran and Rafael will analyze the problem of blockchain interoperability from theoretical and practical standpoints. They will start by defining it and present an ontology for interoperability solutions. They will then present their existing standardization efforts in the IETF DLT Gateway Interoperability group. After that, they will present their ongoing work at the Hyperledger Interoperability Task Force on providing a formal security definition of interoperability across distributed ledgers using the framework of universal composability that is vetted by the cryptography research community.
Sessions Details & Slides (if available): https://sched.co/14H5d
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
Good
afternoon,
everyone
I
hope
you're
having
a
good
conference.
It
is
really
nice
to
be
talking
here
about
interoperability
in
hypological,
Forum
2020.
We
have
like
the
first
contact
with
hyperologic
actors
and
after
being
working
on
the
project
for
a
while
we've
seen
that
it
has
evolved
so
much,
which
also
motivates
this
work.
A
So
in
this
presentation,
Dina
and
I
are
going
to
talk
about
formalization,
systematization
and
standardization
of
blockchain
interoperability.
A
joint
effort
between
some
hyperledger
members,
showing
that
a
needed
disciplinary
approach
is
needed
to
solve
this
problem,
so
probably
you're
all
familiarized
with
interoperability,
but
essentially
it
helps
us
bringing
liquidity
to
other
networks.
It
helps
us
scale,
our
blockchain
Solutions,
and
it
also
help
us
reduce
risk
by,
for
example,
migrating
our
applications
to
a
more
secure,
blockchain
or
pegging
our
security
to
a
stronger
blockchain.
A
However,
we've
seen
that
blockchain
Bridges,
so
the
most
typical
crocheting
use
case
have
been
constantly
hacked,
namely
we
have
seen
about
one
and
a
half
billion
of
dollars
in
Damages
just
this
year
and
despite
several
academic
works
and
Industry
works
on
the
topic.
We've
seen
these
attacks,
so
we
would
like
to
mitigate
these
attacks,
and
our
hypothesis
is
that
by
formalizing,
blockchain
interoperability
and
then
instantiating
our
Solutions.
With
this
more
General
model,
we
may
help
mitigating
some
of
the
attack
factors.
A
A
Basically,
we
aggregate
interoperability
Solutions
into
different
categories
based
on
a
set
of
criteria,
and
one
of
the
insights
that
it's
important
to
understand
is
that
interoperability
is
not
solely
as
the
transfers.
So
bridges
are
not
the
only
use
case
for
interoperability,
for
example,
hyperledger,
Cactus
and
Weaver
no
called
cacti
support
more
General
types
of
interoperability,
so
we
can
have
cross-chain
use
cases
that
are
not
solely
asset
transfers.
A
So
when
we're
reasoning
about
interoperability,
it's
important
to
understand
what
is
the
object
that
you
want
to
interoperate.
So
we
call
this
the
interoperation
mode
and
we
divide
it
into
Data
transfers
as
the
transfers
and
asset
exchanges.
Asset
exchanges
are
different
from
asset
transfers
and
I'll
explain
a
bit
later.
How
is
that,
and
then
we
want
to
measure?
Can
the
system
interoperate
with
other
systems
as
it
is?
A
We
call
this
the
potentiality
of
a
system,
and
we
measure
this
with
what
we
call
the
T
levels,
and
then
we
have
the
sea
levels
for
compatibility
and
it
answers
the
questions
if
two
systems
can
interoperate
with
others,
as
they
are
we'll
explain
these
soon,
so
data
transfer
very
simple.
Typically,
we
have
a
piece
of
data
on
a
source,
blockchain,
an
interoperability
mechanism
in
the
middle
or
interoperability
solution.
We
copy
that
to
the
Target
blockchain
via
the
IM.
Typically,
we
also
might
provide
some
proofs
of
validity,
but
not
necessarily,
then
we
have
asset
transfers.
A
So
the
idea
here
is
to
move
an
asset
from
a
source
blockchain
to
a
Target
blockchain,
and
we
usually
do
this
by
locking
the
asset
on
the
source.
Blockchain
and
minting
the
representation
of
this
of
the
test
set
on
the
target.
Blockchain
note
that
the
idea
here
is
to
keep
the
total
circulation
of
that
asset
consistent
across
chains.
So
that's
why
we
need
to
lock
and
unlock
otherwise.
The
vsd
is
not
packed
or
backed
up
by
anything
on
the
source
chain,
which
is
problematic
when
bridges
are
hacked.
A
So
we
lock,
then
we
have
a
mighty
entity
in
the
middle,
can
be
more
centralized
or
more
decentralized.
That
asserts
for
the
validity
of
that
transaction,
and
then
the
asset
is
minted
on
on
the
target
blockchain,
then
we
have
asset
exchanges,
so
asset
exchanges
do
not
require
a
burn
means
or
a
lock
mint
mechanism,
but
rather
the
deposit
or
locks
some
value
or
some
acid
in
in
an
escrow
contract
right.
This
escrow
contract
can
be
redeemed
by
providing
a
pre-image
of
a
cryptographic
hash,
which
is
called
a
secret.
A
In
other
words,
if
I
have
the
secret
I
can
redeem
funds
so
visually
we
have
Alice
and
Bob
on
training.
Nb
Alice
creates
a
secret
which
is
it's
hidden
by
a
cryptographic
hash,
and
then
she
locks
the
transaction
into
dissolve
these
smart
contracts
such
that.
If
Bob
provides
the
red
key,
he
can
get
the
assets
right.
That's
the
transaction
where
he
gets
the
assets
and
similarly,
as
L
is
Bob,
deploys
a
smart
contract
on
his
chain,
such
that.
A
If
Alice
provides
the
key,
he
can,
they
always
can
redeem
the
funds,
and
the
point
of
Interest
here
is
that
the
the
key
is
the
same.
So
when
Alice
opens
the
Vault
and
redeems
the
the
funds,
Bob
gets
the
key
and
can
use
it
on
the
first
one
to
redeem
the
funds,
so
both
parties
get
the
funds
and
both
parties
use
Atomic
transactions
on
their
own
blockchains.
So
you
only
need
a
some
synchronization
happening
of
chain
for
this
to
happen
right.
Those
are
the
B
levels.
I'll
be
really
quick
about
this.
A
The
intuition
is
that
the
higher
the
P
level,
the
stronger
the
interoperation
system,
so,
for
example,
I
have
op1,
is
interoperability
across
smart
contracts.
If
you
saw
any
Weaver
presentation,
there's
a
very
similar
diagram
and,
for
example,
level
P3
is
interoperation
across
different
DLT
networks,
but
same
sub
networks,
same
functionality,
so
level
level
P3
could
be
across
ethereum
different
stdm
networks,
level
P4
could
be
across
different
LTE
protocols
such
as
polka
dot
and
Hyper,
larger
Fabric
or
ethereum
and
Hyper
larger
fabric,
the
sea
levels.
A
So
level
C1
is
compatibility
on
the
semantic
layer,
meaning
that
there
is
a
protocol
that
is
understood
by
two
different
systems.
So,
for
example,
an
asset
transfer
protocol,
that's
instantiated
on
a
set
of
blockchains
level.
C2
includes
synchronization
at
the
organizational
level,
meaning
that
there
are
some
agreements
across
organizations
that
enable
the
Fulfillment
of
a
common
goal.
For
example,
when
we
have
bridging
projects
that
have
a
collaboration
to
use
shared
infrastructure
across
several
blockchains,
we
have
organizational
or
compatibility.
A
And
finally,
we
have
legal
compatibility
which
conforms
to
jurisdictions,
laws,
regulations,
Etc,
and
there
is
not
a
lot
of
work
on
that
field.
As
far
as
We
Know
all
right,
so
then
our
systematization
deliverable,
we
look
at
the
B
level.
C
levels
and
d
stands
for
data
transfer
at
asset
transfer
and
aesthet
exchange.
A
If
we
want,
for
example,
a
P4
C1
and
as
a
transfer
solution,
we
look
into
these
columns
right
and
we
check
which
one
has
the
tick.
So
the
the
last
rows-
and
this
indicates
us
that
these
rows
here,
those
Solutions
provide
the
requirements
that
we
need
for.
So
those
are
interoperability,
solutions
that
support
those
P
level,
C
levels
and
so
on
and
now
I
would
like
to
call
Vina
to
present
our
efforts
on
formalization.
B
Okay,
so
thanks
Rafael
I,
think
till
now,
you'd
have
seen
what
we
can
call
a
system
systematization
of
different
solutions
that
are
available
for
interoperability
and
in
terms
of
both
techniques
and
the
interability
modes,
supported
across
various
Dimensions
right.
So
now
we'll
try
to
think
about
what
it
would
take
to
formalize
or
to
come
up
with
a
formal
definition
for
an
interoperability
protocol
right.
B
So
this
is
work
in
progress
that
Rafael
and
I
are
doing
with
the
heart
Montgomery
from
the
foundation
and
colleagues
from
the
IBM
media,
research
lab,
Shaker
and
Rama,
who
is
in
the
audience,
and
the
goals
of
this
work
is
to
come
up
with
a
cryptographic
definition
that
if
someone
comes
up
with
an
interability
protocol,
we
can
check
if
it's
secure
right.
So
what
is
mean
by
secure
is
let's
say
if
you
want
to
come
up
with
a
encryption
protocol
right.
So
that's
something.
Cryptographers
came
up
with
the
definition.
B
I
don't
know
a
few
decades
ago,
and
one
common
thing
that
you
would
do
is
encrypt
using
your
protocol,
encrypt
0,
using
your
protocol
and
then,
let's
say,
encrypt
one
using
your
protocol.
All
right.
If
you
give
it
to
someone
who
is
trying
to
bake
the
protocol
either
encryption
of
0
or
the
encryption
of
one
right
and
if
they
cannot
distinguish
between
them,
then
that
means
that
your
protocol
is
secure.
So
that's
that's
usually
like
one
like
very
simplified
way
of
saying
your
encryption
protocol
is
secure
right.
B
You
can
have
like
building
on
top
of
this
seminal
work
from
four
decades
ago
for
any
cryptographic,
primitive.
We
always
first
try
to
come
up
with
what
a
formal
definition
of
security
means
for
the
Primitive,
and
then
we
try
to
propose
protocols
for
that,
because
when
we
propose
protocols
we
want
to
say
whether
it's
satisfying
the
properties
that
we're
defining
for
eternal.
So,
similarly
for
interoperability,
what
we
aim
to
do
is
to
build
on
the
formalization
that
exists
for
individual
blockchain
ledgers
right.
B
So
what
does
it
take
to
formalize
interoperability
protocol
right
so
here
it
could
be
interpretation
between
two
different
individual
networks,
which
means
like
they
are
fundamentally
different
in
terms
of
I.
Don't
know
like
how
they
let
people
in
like
the
participants
of
the
network
are
they
can
be
fundamentally
different
in
terms
of
the
consensus
mechanisms
or
in
terms
of
let's
say,
I,
don't
know
the
signing
protocol
used,
how
the
data
is
stored
in
The,
Ledger
and
and
so
on,
right
and
the
derivatives
of
it
and
even
inside
a
protocol.
B
There
are
different
different
parts
involved
in
the
individual
Leisure.
We
have
consensus,
The,
Ledger
and
the
as
I
mentioned
before
the
membership
provider,
and
also
when
communicating
with
other
ledgers.
You
also
have
contracts
for
cross-ledger,
ID
management
or
like
cross
Ledger
verification
of
data,
that's
coming
from
the
other
Ledger
or
in
maintaining
locks
and
other
things.
So
one
of
the
these-
this
is
one
of
the
main
challenges
of
formalizing.
B
Interoperability
is
that
there
are
different
moving
blocks
and
we
have
to
come
up
with
a
model
that
right
we
have
to
come
up
with
a
model
that
is
aware
of
all
these
things
and
it's
secure
even
then.
So
this
is
where
we
use
this
notion
of
universal
composibility
I'm
not
going
to
talk
about
what
it
means.
B
This
is
just
to
motivate
that
if
there
are
like
multiple
pieces
of
a
protocol
or
if
a
particular
protocol
is
going
to
be
used
as
a
part
of
a
larger
system
with
other
things,
it's
very
common
or
if
this
protocol
is
different
instance
of
this
protocol
are
used
in
conjunction
right.
In
such
a
scenario,
it's
very
common,
it's
natural
to
use
this
notion
of
universal
composibility
to
give
an
analog
in
cryptography
when
people
use.
B
This
is,
let's
say,
if
you're
trying
to
use
a
signature
scheme
with
some
parameters
from
public
parameters
and,
let's
say
you're,
trying
to
use
the
similar
or
the
same.
The
secret
key
public
key
pair
for
an
encryption
scheme
I
mean
some
of
the
signature
schemes
and
ignitive
schemes
that
are
compatible
in
terms
of
public
key
private
key
parameters.
B
So
it's
okay
to
use
it
right,
but
even
though
the
key
like
the
mathematics
of
the
key
are
compatible,
it's
not
always
secure
if
they
are
used
like
in
conjunction
so
sometimes
it
like,
they
don't
naturally
do
and
also,
if
you
have
different
instances
of
if
you
use
the
same
parameters
for
let's
say
different
other
protocols
as
well.
The
randomization
of
the
secrets
are
used.
B
It's
not
clear
whether
it's
secure
or
not,
and
people
have
seen
in
the
literature
that
this
notion
of
universal
composibilities
has
a
good
way
of
capturing
whether
the
repeated
use
of
the
parameters
are
done
correctly
or
not,
or
when,
like
yeah
as
I
mentioned
before,
whether
the
protocol
is
choose
in
conjunction
with
other
instantiation,
the
same
protocol
or
different
protocols
to
check
whether
it's
done
well.
This
notion
of
universal
composibility
helps,
and
since
we
have
a
lot
of
moving
pieces,
we
will
also
try
to
use.
B
B
And
the
second
thing
is:
it
needs
to
support,
locking
right
to
enable
atomicity
across
ledger,
so
locking
is
another
fundamental
property,
so
some
of
these
is
what
we
will
try
to
capture
what
we
had
tried
to
capture
in
our
formal
definition,
and
this
is
the
only
sort
of
the
math
term
that
I
will
use
in
this
slide.
Is
we
do
this
by
defining
appropriately
defining
rules
right
and
see
the
transition
like
appropriately
defining
rules
and
the
transition
of
the
state
and
the
set
of
rules?
B
So
we
associate
with
a
particular
state
of
The
Ledger
a
set
of
rules,
and
then
we
define
transition
functions
which
go
from
the
state
set
rule
pair
to
the
updated
State
set,
updated
rule,
set
double
and
the
transition
function.
Outputs
I,
don't
know
one
if
the
update
from
the
previous
Tuple
to
the
new
Tuple
is
valid
and
zero.
B
Otherwise,
so
by
appropriately
crafting
these
things
is
how
we
came
up
with
the
definition
I
and
right,
and
we
model
this
as
a
two
layer,
Universal
composibility
model,
the
first
layer
captures
the
definition
of
the
single
Ledger
functionalities
and
okay.
The
second
layer
is
about
the
system
of
interoperabilities
right
and
the
first
layer.
B
There
is
a
prior
work
called
fledger
which
formalizes
the
second
definition
for
all
DLT
Technologies,
and
we
build
on
top
of
that
to
have
some
interrupt
enablers
like
checking
whether
the
transition,
the
rules
transition
function
is,
is
one
of
the
interrupt
enabler
right.
So
that's
is
the
first
layer
of
the
UC
model.
The
second
layer
is
the
system
of
multiple
interoperable
ledgers,
which
contains
things
like
the
global
clock
or
the
atomic
Summit
functionality
and
similar
things,
which
defines
how
a
cross
Ledger
functionality
would
look
like
right.
B
So
this
is
capturing
the
formulation
effort
at
a
very,
very
high
level
to
talk
to
us.
If
you
have
any
more
questions
after
this
session,
we
just
kept
it
at
a
high
level
because,
like
it
might
be
like
appropriate
for
a
wider
audience
right,
Okay
and
like
once,
we
Define
this
formally.
There
are
two
steps
of
like
once
we
write
down
the
formal
definition,
we'll
have
to
first
show
that
the
individual
ledgers
are
according
to
what
F,
Ledger
plus
is
asking
for
all
right
like
fabric
card
Basu.
B
We
would
want
to
or
ethereum
mean
so
we'll
have
to
prove
that
those
are
according
to
a
fledger
plus
and
then
we'll
have
to
prove
that
cacti.
Initially,
we
thought.
Okay,
we'll
prove
two
use
cases,
one
for
V1
for
characters
when
we
started
two
years
ago.
Okay,
now
it's
merged,
so
we'll
have
to
prove
that
the
different
kind
of
functionalities
that
each
of
these
support
are
secured
under
this
model.
Right
so
that's
I
mean
this
is
one
SL
one
excerpt
from
the
Weaver
deck?
Will
we
have
like
multiple
functionalities?
B
Regular
sharing
data
like
Rafael
mentioned
data
transfer,
asset
exchange
and
a
version
of
identity
management,
a
decent
placement
and
the
even
published
in
publication
subscription
so
like
we'll
have
as
after
we
write
down
the
formula,
definitely
will
be
proving
that
the
protocols
are
secure
under
this
definition.
Okay,
so
that's
that
with
the
formalization
part.
The
next
is
about
the
standardization
effort,
which
is
a
task
force
under
ietf
we're
trying
to
formally
like
get
into
the
ietf
working
group.
B
So
we
call
it
the
secure
asset
transfer
protocol,
the
SAT,
P
group
and
I
guess,
like
a
couple
of
us
in
the
audience,
I
think
who
have
been
part
of
the
working
groups
right.
So
the
scope
of
this
working
group
is
actually
yeah.
This
picture
captures
right,
so
there
will
be
gateways
that
a
singular
multiple
gateways
that
lie
in
front
of
each
of
the
network
and
the
scope
of
this
working
group
is
to
define
the
communication
between
gateways
and
mainly
to
facilitate
the
secure
asset
transfer
protocol
right.
B
And
what
all
do
we
have
here,
like
mainly,
we
try
to
formalize
the
the
API,
the
endpoint
definition
in
the
gateways
and
then
and
the
description
of
like
resource
identifiers
right,
the
like.
How
can
how
can
you
craft
the
query
or
the
request
to
be
made
to
the
other
network?
So
that's,
that's
also
part
of
it
right
and
how
do
you
define
each
asset
in
a
net
in
a
network?
So
that's
the
resource
identified
and
then
we'll
also
trying
to
formalize
the
payload
definition
for
different
kinds
of
payloads.
B
That
would
be
communicated
across
the
gateways
during
the
crossroad
protocol
and
then
the
the
protocol
itself
for
the
secure
asset
transfer
right.
So
there
is
a
charter.
There's
a
draft
Charter
and
like
Saul
has
gained
a
lot
of
traction
over
the
last
couple
of
months
and
there
was
like
above
session
in
Philadelphia
a
couple
of
months
ago.
So
after
that
the
group
has
trained
the
data
production
and
like
getting
formally
involved
with
ietf
recently.
B
So
there
are
like
sort
of
two
or
two
or
three
main
drafts,
and
then
some
Associated
drafts
currently
we're
thinking
about.
First
is
the
asset
transfer
protocol
and
then
the
architecture
and
then
the
the
use
cases
document
to
augment
that,
and
also
after
doing
that,
we'll
also
have
the
the
views,
data
sharing
document,
which
will
have
the
the
definition
for
the
view
and
view
addresses
for
the
data
sharing
protocol.
All
right
now,
I'll
hand
it
over
to
Rafael
to
go
through
this
in
a
bit
more
detail
about
the
standardization
thanks.
A
Thanks
Dina,
so
we've
been
working.
Excuse
me
on
this
protocol
for
a
while,
it
was
called
odap
before
we've
been
working
for
this
for
around
two
years.
So
there's
there
has
been
a
a
couple
iterations
in
the
meantime,
but
what
we
figured
out
is
for
gateways
to
communicate
securely
would
have
to
implement
a
three-phase
protocol-
that's
crash
fault,
tolerant
to
account
for
possible
failures
in
in
gateways,
which
would
eventually
happen.
A
They
coordinate
asset
exchanges,
asset
transfers
and
they
can
also
share
data
across
chains,
and
we
also
try
for
cross-chain
transactions
to
preserve
acid-like
properties,
so
the
atomicity
consistency,
isolation
and
durability
for
transactions
that
come.
You
know
from
the
database
research
area.
We
have
done
some
work,
so
we
have
a
paper
on
that
formalizes,
all
that
so
satp
previous
name,
which
you
can
check
for
some
details
if
you're
interested.
A
So
this
is
a
sketch
of
the
three
phases
that
odap
has
well
plus
phase
zero.
First,
we
have
an
end
user
that
requests
a
cross
chain
asset
transfer
and
we
have
basically
Gateway-
is
communicating
to
assert
their
identities
and
to
assert
that
they
can
effectively
transfer
their
asset.
So
they
verify
the
asset
profile
that
defines
what
an
asset
should
look
like.
They
verify
that
gateways
are
ran
by
a
valid
virtual
asset
service
providers,
they
verified
identities
and
so
on.
A
So
we
we
need
this
kind
of
standardization
because
to
bring
in
order
to
bring
interoperability
to
the
Enterprise
world.
We
need
some
sort
of
agreements
on
the
semantic
organizational
and
perhaps
even
legal
lawyer.
Otherwise,
if
we
keep
using
a
set
of
haddock
standards,
it
would
be
much
harder
to
communicate
and
to
abide
by
existing
regulations.
A
Well,
after
that,
the
gateways
agree
to
proceed
and
they
establish
a
secure
channel,
so
TLS,
etc,
etc,
and
this
is
where
things
start
to
get
interesting.
We
have.
Our
protocol
is
based
on
two-phase
Commit,
so
first
there
is
a
lock
asset
or
a
log
state,
so
notice
that
these
logs
might
be
logs
on
state,
according
also
to
the
framework
we're
developing.
A
So
we
need
the
ledgers
to
have
some
functionality
to
create
and
coordinate
such
logs,
and
when
we
have
a
lock
operation
on
either
side,
we
generate
a
proof
that
should
be
verifiable
by
other
gateways
right,
so
the
the
evidence
is
signed.
It's
preferably
published
in
a
decentralized
forum
and
the
receipts
are
exchanged
after
we
have
a
log,
so
it's
it
corresponds
to
the
pre-commit
phase
of
the
two-phase
commit
protocol.
A
A
Proofs
are
generated,
they're
exchanged,
they're
persisted
and
the
Gateway
concludes
the
session.
So
this
is
a
high
level
overview
of
the
protocol.
Then
we
have
the
architecture
graph,
which
specifies
the
components
specifies
and
explains
the
Gateway
Paradigm
right.
You
have
here
a
an
idea
of
where
gateways
are
located.
A
A
A
A
B
A
C
A
A
C
C
Hello,
hi
I
was
really
interested
in
your
P
level.
C-Level
curious,
if
there's
information
about
the
different
interoperability,
let's
just
say,
code
bases
that
exist
within
hyperledger
or
hyperledger
Labs,
specifically
Cactus,
Weaver,
UE,
peroon
and
Firefly,
and
if
you,
if
we
have
any
ideas
about
what
their
P
levels
and
sea
levels
are.
A
Let
me
get
this
slide,
so
Weaver
and
Cactus
aim
to
be
P4,
so
they
provide
Weaver
provides
more
the
protocol
to
which
you
can
realize
data
transfers
and
asset
transfers,
while
Cactus
aims
to
provide
the
infrastructure,
so
the
connectors,
the
test,
ledgers
and
so
on,
and
they
they
do
realize
before
interoperability.
And
if
you
have
several
Cactus
nodes
or
cacti
nodes
in
the
future.
Hopefully
you
could
realize
level
C2
and
perhaps
even
level
C3.
A
Now
we
haven't
done
a
very
comprehensive
analysis
to
the
best
of
my
knowledge
to
the
other
Solutions,
but
it's
interesting
to
notice
that
some
of
these
in
some
of
these
works,
the
Outsource
use,
for
example,
hyper
larger
fabric.
They
do
a
channel
to
channel
interoperability
or
interoperability
across
hyperledger
fabric
networks.
So
the
system
that
the
systems
that
are
proposed
in
some
of
those
papers
works
actually
enhance
the
levels
of
the
of
the
solutions.
A
Unless
fabric
has
these
interoperability
capabilities
by
default,
which
happens
in
some
blockchain
projects
like
Cosmos
and
polka
dot,
where
you
have
some
interoperability
between
instances
of
the
platform
so
between
para
chains
or
between
hubs,
but
you
do
not
have
native
interoperability
with
other
blockchains.
You
need
bridges
for
them
so,
and
this
is
a
design
decision
right,
polka
dot,
for
example,
started
working
on
this
modules
by
default.
Well,
hyperledger
focused
on
a
single
blockchain
for
Enterprise
applications.
B
And
one
caveat
is
also
about:
what's
the
end
goal
that
the
Project's
aiming
for
versus
the
current
implementation,
I
guess
for
some
of
the
projects,
the
end
goal
is
like
what
Raphael
mentioned,
but
I
think
we
are
working
towards
that
right,
like
we
don't
have
all
the
things
implemented.
Yet,
let's
say
yeah
for
Cactus
and
thanks.
B
D
B
Something
that
that
will
be
good
to
do
once
we
complete
the
formalization
like
we
haven't
done
it
yet,
but
that's
certainly
something
we
have
to
do
right.
We
currently
whenever
we
think
about
something.
We
will
first
Auntie
check
that
with
fabric
Basu
under
the
hyperledger
projects
right
our
unjust
ethereum
right,
but
for
the
other
we
haven't
done
a
thorough
check
on
like
what
are
the
other
public
blockchains
too.
We
probably
have
to
do
it
like
once
we
make
some
more
progress
in
completing
the
formalization,
so.
B
Locking
locking
and
some
level
of
synchronization
in
the
clocks,
yeah
so
I
mean
what
I
mean
by
some
level
of
synchronization
clocks
is.
We
have
to
be
have
some
level
of
predictability
in
logs.
It
should
not
be
too
fast
or
too
slow
right
and
also
it
should
be
not
too
variable
in
terms
of
like
yeah.
It
should
not
certainly
be
too
fast
and
then
slow
down
a
bit
and
so
on.
B
If
we
do
those
kind
of
things,
it's
very
hard
to
do
interactive
it's
hard
to
Define
any
kind
of
formal
properties
for
interoperability
right.
So
that's
one
part.
The
second
part
is,
should
have
the
ability
to
facilitate
locks
right.
Those
are
the
two
things
I
mentioned
in
the
slide.
If
that's
what
you're
talking
about
so.
B
A
Okay
and
we,
we
obviously
need
to
account
for
that,
because
different
blockchains
have
different
block
creation
times,
or
they
have
even
timestamps
saying,
for
example,
in
the
case
of
fabric,
we
do
not
have
time
timestamps,
which
could
make
it
more
difficult
to
have
a
decentralized
view
of
time
that
is
actually
some
papers.
Working
on
that.
B
B
Agree
so
we're
not
trying
to
synchronize
clocks
right,
it's
like
yeah,
so
what
we
are
saying
is
it
has
to
have
some
level
of
it's
not
about
synchronization
right,
it's
some
level
of
predictability.
Maybe
that's
a
better
word.
We
could
have
used
right.
So
if,
if
there
is
a
decent
amount
of
margin
in
terms
of
predictability,
then
it's
easy
to
then
it's
possible
to
Define
inter
interoperability
right
formally.
D
D
D
D
B
D
Okay,
so
it
is
a
working
system.
It's
not
like
some
creation
from
the
mind
right,
so
Swift
is
a
message-based
system
and
I.
Think
somebody
in
the
supply
chain,
world
came
up
with
this
message-based
interoperability
for
certain
I
mean
it's
almost
like
a
fungible
token,
because
in
the
end
you
can
spend
it.
You
know
in
different
places,
I
mean
that's
that's
what
drives,
for
example,
trade
Finance.
You
know
you
can
sell
a
bill
of
lading
or
a
so
they're
formalized,
something
there
I
wonder
whether
you
guys
have
taken
a
look
at
it.
So.
A
That's
a
bit
of
the
work
that
we're
doing
with
the
satp
protocol
right.
So
it's
message
based
it's
inspired
by
such
protocols
and
problems
in
the
supply
chain,
world
where
messages
are
just
beat
strings
and
they're
interpreted
differently
by
different
networks.
So
we
have
the
Gateway
layer
that
does
that
translation,
that
business
level
translation
and
has
some
accountability
guarantees.
B
E
One
that
involves
Gateway
is
communicating
with
each
other.
You
can
make
that
as
decentralized
or
as
centralized
as
you
want.
You
can
add,
centralized
components
to
make
it
perform
better
to
add
more
trust
and
companies
like
Swift
are
trying
to
do
that.
I
guess
what
the
satp
initiative
is
trying
to
do
is
to
propose
a
protocol
that
gives
you
a
very
general
way
to
get
two
networks:
Community
communicating
messages
with
each
other.
Now
you
can
adapt
that
for
your
purpose.
D
B
I
I
think
the
standardization
effort
tries
to
create
a
platform
where
you
can
adapt
it
to
like,
whichever
level
of
I
don't
know
like
the
parameter
parameters
or
variants
of
the
protocol
that
you
want
to
support.
Formalization
tries
to
say
that,
okay,
if
you
have
these
such
profit,
if,
if
you
do
it
in
such
ways,
then
it
satisfies
these
properties
formally
yeah.
A
Right
so
the
formalization
to
the
the
bridge
from
the
formalization
to
the
real
world
are
practical,
implementations
and
use
cases
and
to
make
them
more
robust.
We
try
to
work
on
standardization
as
well,
so
it's
full
stack
of
interoproval
I
think
we're
on
time.
Thank
you.
Everyone
for
attending
and
see
you
around
yeah.