Blockchain Integration Framework
A new approach to the blockchain interoperability problem
Define a communication model to enable permissioned blockchain ecosystems to exchange any on-chain data or custom assets (fungible/non fungible) independent of the platform (e.g. Hyperledger Fabric, Quorum, etc.) without a middleman. This lab project will implement an interoperability validator network, which is an overlay network of hand-picked actors that will validate and sign data before sharing.
If you look at the Blockchain Interoperability space, several different approaches have been proposed. Among the existing contributions, we identified two main ways to solve the interoperability problem. The “connector approach” focuses on building transfer protocols for non-trusted blockchain gateways (e.g. Interledger). The “blockchain of blockchains approach” proposes a central blockchain “hub” to connect multiple blockchain “zones” together (e.g. Cosmos).
This lab project proposes an alternative to these models, and it is designed specifically for permissioned blockchain networks
- Direct transfer between requestors (from different ledgers)
- Pluggable model and components
- Flexible requirements and data protocols
- Leverage pre-existing roles
Blockchain Integration Framework introduces an “interoperability validator” overlay network for each of the interoperable blockchains. Interoperability validators are known or broadly discoverable by the ecosystem and are typically participants already taking part in the governance or consensus. Interoperability validators will collectively handle export requests from local nodes by verifying against their version of the ledger (steps 1 to 3). Each request is answered by a (configurable) minimum quorum of validator signatures necessary or rejected as fast as possible (steps 4 and 5). The network can continue working even if some of the validators are down, or not participating, but assuming the minimum quorum can be guaranteed. Messages certified by a distributed ledger’s transfer validators can be delivered by any secure off-chain communication system (step 6). A proof coming from a foreign distributed ledger can be verified against the public keys of the transfer validators of that foreign distributed ledger either locally by the recipient or using an on-chain logic –- typically smart-contracts (step 7 and 8)
- Integrate Hyperledger Indy to manage the interoperability validator identities across the different blockchains
- Implement more complex interoperability use cases. (e.g. atomic swap or asset synchronization)
- Test scalability and performance
- Integrate more platforms (e.g. Hyperledger Sawtooth, Digital Asset, etc.)
- Implement confidential communication within the overlay network. The validator network should match the confidentiality setup of the local ledger
- Replace current signature scheme by BLS to optimize the proof size (Hyperledger Ursa is a lead)
We welcome your questions & feedback on our Rocketchat channel.
We welcome contributions to BIF in many forms, and there’s always plenty to do!
First things first, please review the Hyperledger Code of Conduct before participating.
There are many ways to contibute to BIF, both as a user and as a developer.
As a user, this can inlcude:
As a developer:
- if you only have a little time, consider picking up a “help-wanted” or "good-first-issue" task
- If you can commit to full-time development, then please contact us on our Rocketchat channel to work through logistics!
Hart Montgomery (hartm) - TSC member