Key Points
- Grid uses Sawtooth and is developed in Rust
References
| Reference_description_with_linked_URLs_______________________________ | Notes_______________________________________________________ |
|---|---|
| https://github.com/hyperledger/cactus/blob/master/docs/whitepaper/whitepaper.md | Cactus ( BIF ) Whitepaper |
| https://www.hyperledger.org/blog/2018/01/23/introducing-hyperledger-labs | Hyperledger Labs |
| Hyperledger Transact | |
| https://www.hyperledger.org/blog/2019/06/27/introducing-hyperledger-transact | Generic Smart Contract execution framework |
Key Concepts
Blockchain Interoperability
interoperability use cases
simple Oracles - read only
simple asset exchanges
Dynamic relations between parties
discovery services, routers, decentralized directory services, lookups, authentication services
permanent or temporary relations
Full ACID transactions with rollback across different types of blockchains with privacy
the escrow, asynchronous, tokenized ACID transaction with rollabck
Play forward transactions from a checkpoint for a blockchain member
Hyperledger Labs Blockchain Interoperability Project
https://github.com/hyperledger-labs/blockchain-integration-framework
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, but later expanded to permissionless ones as well.
How It Works
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)
Potential Value Opportunities
Potential Challenges
Performance
Candidate Solutions
Step-by-step guide for Example
sample code block