You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Toward the right of the figure, you can see functions in the semantic layer called out as distinct use cases involving some exchange of information across two networks, leading to ledger record updates in those networks. The three scenarios are:
25
-
- Data transfers
26
-
- Asset transfers
27
-
- Asset exchanges
25
+
- Data sharing
26
+
- Asset transfer
27
+
- Asset exchange
28
28
29
29
You can find details on these use cases (or _modes_ of interoperation) in [Interoperability Modes](https://hyperledger-labs.github.io/weaver-dlt-interoperability/docs/external/interoperability-modes).
30
30
31
-
_Relay_ modules owned and managed by networks enable cross-network communications or even communications between networks and enterprises systems of record. Cross-network identity management occurs on a separate plane from the information exchanges, and our vision for this is described in [Decentralized Identity](https://hyperledger-labs.github.io/weaver-dlt-interoperability/docs/external/architecture-and-design/decentralized-identity) and [Distributed Identity Management for Interoperation](./rfcs/models/identity/distributed-identity-management.md).
31
+
_Relay_ modules owned and managed by networks enable cross-network communications or even communications between networks and enterprises systems of record. Cross-network identity management occurs on a separate plane from the information exchanges, and our vision for this is described in [Decentralized Identity](https://hyperledger-labs.github.io/weaver-dlt-interoperability/docs/external/architecture-and-design/decentralized-identity) and [Distributed Identity Management for Interoperation](./rfcs/models/identity/decentralized-network-identity-discovery-management.md).
32
32
33
33
## Architecture and Deployment
34
34
@@ -38,7 +38,7 @@ Because DLTs can be highly divergent, it is difficult to create components that
38
38
39
39
In the middle, for cross-network communications, lie DLT-agnostic relays, which can have one or more DLT-specific _drivers_ to interpret requests and orchestrate response collection from the network. _Interoperation modules_ lie within the network and operate the way smart contracts for that platform natively do. Hence, in a Fabric network, these are implemented and deployed as _chaincode_ on all peers, whereas in a Corda network, they are implemented and deployed within a special _Interop Cordapp_ that can trigger flows across the network. Lastly, for applications that are already deployed on these networks to exercise interoperation capabilities, Weaver provides SDK extensions and libraries.
40
40
41
-
For a data transfer use case, the following are the functions that are performed network-wide using the interoperation modules (i.e., through consensus):
41
+
For a data sharing use case, the following are the functions that are performed network-wide using the interoperation modules (i.e., through consensus):
42
42
- Access control of requests for data from another network
43
43
- Proof of response data authenticity generated in the form of peers' digital signatures
44
44
- Optionally, encryption of repsonse data and signatures to avoid confidentiality and integrity attacks mounted by relays
@@ -56,9 +56,21 @@ Because relays are additional components introduced by Weaver into a DLT network
1. Dileban Karunamoorthy and Ermyas Abebe, [On the Interoperability of Distributed Ledgers](https://medium.com/thinkdecentralized/on-the-interoperability-of-distributed-ledgers-15f584b79808), _Medium.com_
62
-
2. Ermyas Abebe, Dushyant Behl, Chander Govindarajan, Yining Hu, Dileban Karunamoorthy, Petr Novotny, Vinayaka Pandit, Venkatraman Ramakrishna, Christian Vecchiola, [Enabling Enterprise Blockchain Interoperability with Trusted Data Transfer](https://arxiv.org/abs/1911.01064), _Middleware 2019 - Industry Track_
1. Venkatraman Ramakrishna and Vinayaka Pandit, [Making permissioned blockchains interoperable with Weaver](https://www.ibm.com/blogs/blockchain/2021/07/making-permissioned-blockchains-interoperable-with-weaver/), _Blockchain Pulse: IBM Blockchain Blog_
62
+
2. Venkatraman Ramakrishna, [Meet Weaver, one of the new Hyperledger Labs taking on cross-chain and off-chain operations](https://www.hyperledger.org/blog/2021/06/09/meet-weaver-one-the-new-hyperledger-labs-projects-taking-on-cross-chain-and-off-chain-operations), _Hyperledger Global Forum 2021 Blog_
63
+
3. Dileban Karunamoorthy and Ermyas Abebe, [On the Interoperability of Distributed Ledgers](https://medium.com/thinkdecentralized/on-the-interoperability-of-distributed-ledgers-15f584b79808), _Medium.com_
64
+
65
+
## Presentations
66
+
67
+
1.[Blockchain Interoperability with Hyperledger Cactus & Weaver](https://www.youtube.com/watch?v=l-nZlLK8IMM), Peter Somogyvari and Venkatraman Ramakrishna, _Hyperledger NYC Meetup_, October 14, 2021
68
+
2. Panel discussion on Blockchain Interoperability: Moderator: Vinayaka Pandit; Panelists: Rafael Belchior, Hart Montgomery, and Venkatraman Ramakrishna, _IEEE Services 2021: Blockchain Interoperability_, September 8, 2021
69
+
3. Blockchain Interoperability: Challenges, Ongoing Efforts, and Potential Solutions: Vinayaka Pandit, _Hyperledger Global Forum 2021_, June 9, 2021
70
+
4. Hosted Discussion: The Future of Blockchain Interoperability: Hart Montgomery, Tracy Kuhrt, Susumu Toriumi, and Venkatraman Ramakrishna, _Hyperledger Global Forum 2021_, June 8, 2021
71
+
72
+
## Peer-Reviewed Research Publications
73
+
74
+
1. Ermyas Abebe, Dushyant Behl, Chander Govindarajan, Yining Hu, Dileban Karunamoorthy, Petr Novotny, Vinayaka Pandit, Venkatraman Ramakrishna, Christian Vecchiola, [Enabling Enterprise Blockchain Interoperability with Trusted Data Transfer](https://arxiv.org/abs/1911.01064), _Middleware 2019 - Industry Track_
12
12
13
-
## Short Description
14
-
A framework, with a family of protocols, to enable interoperation for data sharing and asset movements between independent networks built on heterogeneous DLTs in a manner that preserves the core blockchain tenets of decentralization and security.
15
-
16
-
## Scope of Lab
17
-
- We aim to provide a framework that allows two independent networks, typically (though not limited to) permissioned ones, to interoperate on a need basis.
13
+
Weaver is a framework, with a family of protocols, to enable interoperation for data sharing and asset movements among independent networks built on similar or different distributed ledger technologies (DLTs) in a manner that preserves the core blockchain tenets of decentralization and security. To this end, it is built on a particular design philosophy that differentiates it from other DLT interoperability solutions in the market. This philosophy can be summarized through the following design principles or guidelines:
14
+
- A network is self-sovereign in matters of governance and should be able to choose who, how, and when, to interoperate with.
18
15
- Interoperation does not rely on trusted mediators. Rules and requirements are framed using the networks' internal governance mechanisms.
19
-
- Interoperation relies minimally on shared infrastructure, which may provide identity services but does not play a part in core request-response protocols.
20
-
- Interoperation occurs through protocols that derive their trust from the counterparty networks' native consensus mechanisms.
21
-
- Core capabilities (or suported use cases) include data-sharing across ledgers with proof of authenticity and provenance, atomic asset transfers between networks, and atomic asset exchanges in multiple networks.
22
-
- We already support Hyperledger Fabric and Corda, and plan to extend support soon to Hyperledger Besu. We expect to build our framework in such a way that it can support any other arbitrary DLT with minimal effort.
16
+
- Interoperation relies minimally on shared infrastructure, which may provide identity, discovery, and routing, services but does not play a part in core cross-network transactions (which may involve request-response protocols).
17
+
- Interoperation occurs through protocols that derive their trust from the counterparty networks' native consensus mechanisms, because any cross-network transaction method that eschews or bypasses the respective networks' consensus mechanisms will be vulnerable to failure or attack.
18
+
- Interoperation should be enabled without requiring modifications to the DLT stack on which a network is built nor should it disrupt regular network operation. All that should be required are addition and configuration of enabling modules and adapting application workflows to make them interoperation-aware.
19
+
20
+
## Weaver Use Cases
21
+
The framework allows two independent networks built on the same or different DLTs to interoperate on a need basis. Though presently, Weaver supports only permissioned DLTs (Hyperledger Fabric, Corda, and to some extent Hyperledger Besu), the design encompasses both permissioned and open DLTs. We expect to add support to the latter (e.g., Ethereum, Bitcoin) in due course.
22
+
23
+
Weaver, in effect, allows smart contracts managing data and assets on their respective ledgers to interlink and thereby produce an augnmented business workflow that can span multiple shared ledgers and networks. The core capabilities (or use cases) in Weaver that are the building blocks for cross-network operations are:
24
+
- Data sharing across ledgers with proof of authenticity and provenance
25
+
- Atomic asset transfers between networks
26
+
- Atomic asset exchanges in multiple networks
27
+
28
+
Each capability is implemented as a protocol with the endpoints being the respective peer networks that arrive at ledger state update decisions through consensus. See the [project overview](./OVERVIEW.md) for more information and references.
29
+
30
+
With Weaver, limited-scope blockchain networks can be scaled up to a _network-of-networks_ where different DLT networks can interoperate using Weaver's protocols ad hoc, thereby creating an illusion of a worldwide distributed ledger (or blockchain) without requiring netowrks to sacrifice their independence. This is illustrated in the figure below.
31
+
32
+
<imgsrc="./resources/images/weaver-vision.png">
33
+
34
+
## Weaver Components
35
+
The framework offers common components that can be reused in networks built on any arbitrary DLT as well as design templates for components that must be built on DLT-specific tech stacks. We will strive to provide acclerators that minimize the effort involved in building DLT-specific components. Presently, we support Hyperledger Fabric and Corda, and to some extent Hyperledger Besu.
23
36
- The key platform elements are:
24
-
* Protocol units, namely request access control, and generation and verification of authenticity proofs. These leverage the networks' native smart contract frameworks.
25
-
* Generic and extensible patterns for _ledger views_ and _artifact addresses_ for seamless inter-network communication. Our goal is to provide a basis for an eventual standard that is not tied to a particular DLT implementation.
37
+
* Protocol units, namely request access control, generation and verification of ledger state authenticity proofs, hash- and time-locking of assets, and claiming and unlocking of assets. These units leverage the networks' native smart contract frameworks.
38
+
* Generic and extensible patterns for _ledger views_ and _view addresses_ for seamless inter-network communication. Our goal is to provide a basis for an eventual standard that is not tied to a particular DLT implementation.
26
39
* Generic (i.e., not DLT-specific) semi-trusted _relay_ modules that mediate communication while acting on behalf of individual networks. They serve discovery and routing purposes akin to the routing and DNS infrastructure of the conventional internet.
27
-
* DLT-specific plugins called _drivers_ augment relay capabilities with query- and response-translation mechanisms.
40
+
* DLT-specific plugins called _drivers_ that augment relay capabilities with query- and response-translation mechanisms.
41
+
* Agents, consisting of both generic and DLT-specific features, that sync foreign networks' membership lists and identity provider credentials, using existing decentralized identity (DID) and verifiable credential (VC) infrastructure.
28
42
- Apart from the core platform features listed above, we provide SDK extensions for network application users to adapt existing apps for interoperability.
29
-
- We will provide and maintain a basic _testnet_ for rapid prototyping and testing.
43
+
- We provide and maintain basic _testnets_ built on different DLTs (Fabric, Corda, Besu at present) for rapid prototyping and testing.
44
+
30
45
For more details and illustrations, see the [project overview](./OVERVIEW.md).
31
46
47
+
## Weaver Applications
48
+
49
+
Weaver can be used to link business workflows (implemented as smart contracts or decentralized applications) spanning multiple independent permissioned ledgers, in effect scaling up the reach and impact of those processes without sacrificing decentralized operation and network sovereignty.
50
+
51
+
Two popular categories of enterprise applications in which blockchain or distributed ledger technology play a major role today and which need interoperability support of the kind Weaver offers are:
The table below shows what interoperation capabilities (or use cases) are presently supported by Weaver, and what DLTs the platform offers out-of-the-box components for.
57
+
- Any network built on a supported DLT can utilize Weaver capabilities with additional effort required only in configuration and minor adaptations in applications to exercise those capabilities as required in their workflows.
58
+
- For any unsupported DLT, engineering effort will be required to build protocol units, drivers, and identity sync agents, using Weaver's common protobuf structures, design templates, and API specifications. (Because DLTs are heterogeneous with divergent models for data storage, smart contracts, and distributed application development procedures, it is difficult to write reusable code for this purpose.)
- Make the protocols for data sharing, asset transfers, and asset exchanges, more robust and foolproof using techniques validated through research and experimentation.
64
+
- Support the use cases of cross-network transaction invocations (i.e., instructions) and event dissemination (publish/subscribe).
65
+
32
66
## Repository Structure
33
-
- Blockchain practitioners who wish to use and experiment with our code should check the [Documentation](https://hyperledger-labs.github.io/weaver-dlt-interoperability).
67
+
- Blockchain practitioners who wish to understand what Weaver offers, use Weaver capabilities, or experiment with the code, should check the [Documentation](https://hyperledger-labs.github.io/weaver-dlt-interoperability).
34
68
* To dive straight into running a basic setup and testing sample interoperation scenarios, start with [Getting Started](https://labs.hyperledger.org/weaver-dlt-interoperability/docs/external/getting-started/guide).
35
69
* The source code for the documents lies in the [docs folder](./docs).
36
70
- Comprehensive specifications of our architecture and protocol suite are written in the style of RFCs and found in the [rfcs folder](./rfcs).
@@ -39,18 +73,23 @@ For more details and illustrations, see the [project overview](./OVERVIEW.md).
39
73
- Sample applications used for testing and benchmarking interoperation flows are implemented in the [samples folder](./samples).
40
74
- Common data structures and features used by different platform components and applications are implemented in the [common folder](./common).
41
75
- Testing, experimentation, and evaluation frameworks, are implemented in the [tests](./tests) folder.
42
-
* An extensible _testnet_ is implemented in the [tests/network-setups folder](./tests/network-setups) to spin up basic Fabricand Corda networks and test data sharing (with proof) among them.
76
+
* An extensible _testnet_ is implemented in the [tests/network-setups folder](./tests/network-setups) to spin up basic Fabric, Corda, and Besu networks, and test various cross-network operations.
0 commit comments