Feature development in the Weaver project ended in early 2023 when it merged with Hyperledger Cactus to produce Hyperledger Cacti. See the following announcements for information and perspective:
- Introducing Hyperledger Cacti, a multi-faceted pluggable interoperability framework
- Hyperledger Cacti, A General-Purpose Modular Interoperability Framework, Moves to Graduated Status
To follow the progress of the Weaver system under the Cacti framework, use the system, or contribute to it, visit the Hyperledger Cacti repository. The official Cacti documentation has Weaver-specific pages that resemble the Weaver docs for those who are familiar with the latter.
We will soon be archiving this repository. Before doing so, we will publish updated and final versions of the Weaver packages.
We have provided a set of tips for existing Weaver users and contributors to migrate to using Cacti modules and packages instead of Weaver packages and modules.
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:
- A network is self-sovereign in matters of governance and should be able to choose who, how, and when, to interoperate with.
- Interoperation does not rely on trusted mediators. Rules and requirements are framed using the networks' internal governance mechanisms.
- 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).
- 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.
- 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.
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.
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:
- Data sharing across ledgers with proof of authenticity and provenance
- Atomic asset transfers between networks
- Atomic asset exchanges in multiple networks
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 for more information and references.
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 networks to sacrifice their independence. This is illustrated in the figure below.
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.
- The key platform elements are:
- 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.
- 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.
- 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.
- DLT-specific plugins called drivers that augment relay capabilities with query- and response-translation mechanisms.
- 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.
- Apart from the core platform features listed above, we provide SDK extensions for network application users to adapt existing apps for interoperability.
- We provide and maintain basic testnets built on different DLTs (Fabric, Corda, Besu at present) for rapid prototyping and testing.
For more details and illustrations, see the project overview.
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.
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.
- 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.
- 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.)
Prominent features in our future roadmap are:
- Make the protocols for data sharing, asset transfers, and asset exchanges, more robust and foolproof using techniques validated through research and experimentation.
- Support the use cases of cross-network transaction invocations (i.e., instructions) and event dissemination (publish/subscribe).
- Blockchain practitioners who wish to understand what Weaver offers, use Weaver capabilities, or experiment with the code, should check the Documentation.
- To dive straight into running a basic setup and testing sample interoperation scenarios, start with Getting Started.
- The source code for the documents lies in the docs folder.
- Comprehensive specifications of our architecture and protocol suite are written in the style of RFCs and found in the rfcs folder.
- Core Weaver components are implemented in the core folder.
- SDK extensions and libraries for DLT network applications to exercise Weaver interoperation capabilities are implemented in the sdks folder.
- Sample applications used for testing and benchmarking interoperation flows are implemented in the samples folder.
- Common data structures and features used by different platform components and applications are implemented in the common folder.
- Testing, experimentation, and evaluation frameworks, are implemented in the tests folder.
- An extensible testnet is implemented in the tests/network-setups folder to spin up basic Fabric, Corda, and Besu networks, and test various cross-network operations.
- https://github.com/VRamakrishna
- https://github.com/sanvenDev
- https://github.com/knarayan
- https://github.com/dhinakaran2705
- https://github.com/SIKHAR405
- https://github.com/ghoshbishakh
- https://github.com/michiboo
- https://github.com/officialfrancismendoza
- https://github.com/ermyas
- https://github.com/nwaywood
- https://github.com/dileban
- https://github.com/airvin
- https://github.com/AntTargett
- https://github.com//Yining-Hu
- https://github.com/Vinayaka-Pandit
- https://github.com/hyp0th3rmi4
- https://github.com/lehors - TSC Member