Key Points

1. Grid uses Sawtooth and is developed in Rust

References

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

• Whitepaper
• Original Design Principles Google Doc

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

Chris Ferris on Fabric performance - 191106

https://www.ibm.com/blogs/blockchain/2019/01/answering-your-questions-on-hyperledger-fabric-performance-and-scale/

The reality is that Hyperledger Fabric does perform and scale nicely, given the right compute and networking infrastructure. However, it can also yield results that are inadequate for your application’s needs. As with any newish technology, the impacts on performance range from improper (or should I say unexpected) use, improper fabric application to software, and hardware bottlenecks to be addressed over time.

Fabric network components that impact performance

application client

First, there is the application client — the component that sends transactions to the endorsing nodes. The language in which the client application is written may influence the choice of Hyperledger Fabric software developer kit (SDK) like Go, Node.js, Java, Python and others. The choice of SDK can have an effect on performance based on the language in which it is written. The Go and Java SDKs may yield better performance than the Node.js or Python SDK simply because they are compiled and support multiple threads of execution.

Additionally, there’s the client software itself. Let’s be honest, no software is defect-free and hence when analyzing the performance of your blockchain application, you should examine all aspects of the application, including your own code. As an example, in reviewing performance concerns of an application, we found that the client software that was invoking the SDK was leaking open connections to the peer that were not being closed until they timed out. A simple change to the application code resolved that problem.

Fabric peer (endorser/committer) and choice of ledger database

Secondly, there is the Hyperledger Fabric peer (endorser/committer) and choice of ledger database — currently, LevelDB and CouchDB, but over time, other choices will likely emerge. The LevelDB database performs better than CouchDB, generally, but is not as effective at supporting a rich schema for the world state. If you are dealing with simple key-value data, then you might opt for LevelDB.

Additionally, the choice of endorsement policy and the number of available endorsing nodes for a channel can impact peer performance. We’ll dive into that discussion below.

smart contract

Third, there is the smart contract, or what Hyperledger Fabric calls chaincode. Presently, Hyperledger Fabric offers a variety of chaincode implementation choices: Go, JavaScript, Java and an implementation of the Hyperledger Burrow Ethereum Virtual Machine (EVM) that supports execution of smart contract bytecode compiled from one of the Ethereum-smart contract languages such as Solidity. As with the SDK, choosing Go or Java for your chaincode may yield performance benefits over JavaScript, for the same reasons.

Fourth, the ordering service node (OSN) may also have an impact on performance. One factor will be the choice of consensus mechanism. While presently, Hyperledger Fabric has but two modes (solo and Kafka), as we add other protocols that choice may also have an impact on performance. Realistically today, there is but a single choice as the “solo” OSN is not suitable for production usage, but that will be changing soon as we add support for Raft and Byzantine Fault Tolerance (BFT) OSNs in 2019.

Another aspect of the OSN that can have an impact on performance are the configuration parameters that determine the block size and frequency. Modifying these can influence the latency that transactions experience from submission to the OSN to being committed to the ledger. If too few messages are received for a channel to fill the block (per the BatchSize configuration), then the minimum latency will be the BatchTimeout.

Fifth, there is the distribution of work within your blockchain network based on how you have architected use of channels and/or private transactions to deliver privacy. Channels allow you to choose which organizations participate in transactions directed to that channel. Hence, you might limit transaction traffic to the two organizations involved in a transaction plus say an auditor(s) or regulator(s) as neutral observers. The transaction traffic on this channel will not have an effect (other than in shared virtual contexts) on the other organizations in your network.

Finally, there is the physical and/or virtual infrastructure that all of these services run on that can affect performance. For instance, giving the peer nodes more vCPUs can help improve performance in many cases. Of course, this comes at a cost, so you will want to balance the cost of running a peer with the benefits of the improved performance. Disk and memory are also factors as we will explore in future posts in this series.

https://www.ibm.com/blogs/blockchain/2019/04/does-hyperledger-fabric-perform-at-scale/

Candidate Solutions

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles