|Global event||Hyperledger Global Forum|
|Consensus||Kafka, Solo (dummy consensus protocol)|
|Public / Private / Permissioned||Private, Permissioned|
|Smart contract language(s) supported||Go, Node.js, Java|
|Transaction privacy||Yes, via channels|
|Transaction visibility||Businesses can create multiple private channels. Through the DLT application, participants can commit confidential transactions over these channels.|
|Transaction ordering||In the case of Kafka, ordering nodes send to Kafka transactions and receive from Kafka transactions in the same order since Kafka presents an abstraction of a shared queue. Solo is the ordering mechanism most typically used by developers experimenting with Hyperledger Fabric networks and involves a single ordering node.|
The crash-tolerance mechanism comes into play by replication of the partitions among the multiple Kafka brokers. Thus, if one broker dies, due to a software or a hardware fault, data is preserved. What follows is, of course, a leader-follower system, wherein the leader owns a partition, and the follower has a replication of the same.
When the leader dies, the follower becomes the new leader. Kafka uses a fault-tolerant distributed streaming platform called Apache Kafka. It also enables distributed ordering service so that we can have multiple orderer nodes to avoid a single point of failure.
Solo mode requires all orderers to be up, and if one goes down the entire network goes down as well.
The Kafka orderer can efficiently order high numbers of transactions. It is composed of multiple virtual nodes forming a so-called “Kafka cluster”.
This decentralization makes the Kafka orderer tolerant to the failure of single nodes (e.g. through power shortages, software failures). Therefore it is considered fault-tolerant. However, the Kafka orderer is not Byzantine-Fault-tolerant as it can be compromised by a malicious node in the network.
Not meant for production use.
Kafka is recommended for use if members primarily transact in private channels with only a few known participants rather than in the main channel involving more participants. In such a setup the risk that single nodes in private channels will act maliciously is minimized.
Also, if you need very high transaction throughput e.g. higher than 1000 transactions per second, a fault-tolerant consensus algorithm is preferable. However, scaling in a scenario with thousands of suppliers, each with their own subnet wanting to transact with a specific entity (e.g. SWIFT), becomes a challenge as this entity needs to be a member of each subnet.
Security is improved with the use of a multitude of endorsement, validity, and versioning checks that are available on Fabric. There are also ongoing identity verifications happening in all directions of the transaction flow.
Not meant for production use.
B2B contracts, supply chain, asset depository, asset interoperability.
Support for Hyperledger Fabric will soon be ready. Head over to our Solution page to learn more about the protocols we already support, those on the roadmap, and numerous other features.
Complete the form below, and our experts will get in touch with you.