Given that Hyperledger Fabric has several ordering service implementations (including Solo, Kafka, and Raft), you as the developer should understand the advantages and disadvantages of each implementation before making a design decision. As the new default for production blockchain networks, the Raft consensus algorithm is a crash-fault-tolerant ordering service implementation that is easier to set up and manage than Kafka. More importantly, Raft allows different organizations to contribute nodes to the ordering service, enabling a more decentralized network architecture.
Given that there are many possible ways that the nodes on a blockchain network can come to agreement (or consensus), and that agreement is essential for a distributed computing network, it is no surprise that the debate over the most efficient consensus algorithm is often heated and even religious. At the heart of consensus algorithms is the need to solve a difficult, popular, distributed computing question: How can we (computers) agree on one result (reach consensus) among a group of computers when we know that the computers are unreliable? Although there is no perfect way to solve this problem, the de-facto standard since 1989 has been the Paxos algorithm. The problem with Paxos, is that it can take Ph.D students years to master. Even the brightest of engineers who try to implement this algorithm in practice have difficulties fully understanding, and thus implementing, their solution.
Enter Raft. Designed as an alternative consensus algorithm to Paxos, Raft is much easier to understand, and is now used in some of the most successful software projects, such as Docker. Since the launch of Hyperledger Fabric, consensus has been designed as pluggable, and you the developer get to choose which type of consensus your ordering nodes will use. Raft enables a much easier setup than Kafka, a more decentralized approach because multiple organizations can contribute nodes to the ordering service, and greater crash fault tolerance than Solo, because Solo features a single ordering node. This code pattern helps you understand how to build and deploy a smart contract onto a Hyperledger Fabric network running Raft, and enables you to test the tolerance of the network by stopping and starting some of the ordering nodes.
When you have completed this code pattern, you will understand:
- How the Raft algorithm works
- How to build and run a Raft ordering service with multiple organizations in Hyperledger Fabric
- How to submit transactions and run a blockchain network using a Raft ordering service
- How to test the ordering service fault tolerance by deleting (crashing) one of the ordering nodes
- The blockchain operator generates cryptographic materials, such as public and private keys, for the organizations that will manage the peer nodes.
- The blockchain operator brings up the network, including five ordering nodes running Raft, installs the smart contract on the peers, and queries the network to ensure the contract is working properly.
- The blockchain operator installs dependencies for the Fabcar web application, including server-side and client-side dependencies.
- The blockchain operator creates a cryptographic identity for the client, which submits transactions via the Fabcar UI and stores that identity in a wallet.
- The user interacts with the Fabcar Angular web application to update the blockchain state, and the Raft-based ordering nodes use leader election to decide which node will take the lead in writing blocks.
- The user inspects the ordering service logs to ensure that the raft consensus algorithm is running as expected.
Find the detailed steps for this pattern in the README file. The steps show you how to:
- Clone the repo.
- Clean your Docker images.
- Generate cryptographic material.
- Install Fabcar web app dependencies.
- Create a cryptographic identity.
- Start the Fabcar web app.
- Test the network — crash the ordering nodes.