Demystifying Hyperledger Fabric ordering and decentralization
Is the Fabric ordering service centralized or not? Can organizations within a Fabric network run ordering nodes?
Hyperledger Fabric is designed to provide flexibility, performance, and finality. However, there is a lot of confusion about whether or not its ordering service is centralized, and whether or not multiple organizations within a Fabric network can run ordering nodes. This article clarifies this point, explaining Fabric’s design, the different types of ordering services available today and in the future, and the different degrees of decentralization that they provide.
It is not necessary for you to have a deep understanding of Hyperledger Fabric’s architecture and its transaction process flow to benefit from reading this article. However, to get the most out of it, if you are completely new to Fabric, you may want to read a bit about what Fabric is and familiarize yourself with Fabric’s transaction flow.
This article also assumes some familiarity with common blockchain-related concepts like consensus, as well as Byzantine fault tolerance (BFT) and crash fault tolerance (CFT).
Fabric’s consensus and the ordering service
One of the most unique characteristics of Hyperledger Fabric’s architecture is its consensus mechanism, which consists of three steps — execute > order > validate — as opposed to the more traditional order > execute mechanism typically found in other blockchain frameworks.
While the first and last steps, execute (also called endorsement) and validate, are performed by different peer nodes that are typically owned by different organizations in the network, the second step, order, is performed by what is called the ordering service. This service is central to the network and plays a crucial role in this process.
Most existing examples and tutorials related to Fabric exhibit networks containing an ordering service that is owned by a single organization. Naturally, this has led people to think that the ordering service is actually a central server and that Fabric is not a decentralized framework. However, this is not the case. Let me explain.
While the ordering service is central to the Fabric network, it can be made of several nodes that work together to perform the ordering function. Fabric is thus designed so that the ordering service can be decentralized and can provide for your Fabric network to be fully decentralized as you would expect from a blockchain framework.
Most examples that are currently available online have only one ordering node because up to Fabric 1.4.0 (released in early January 2019), there was no ordering service available that could effectively be fully decentralized. With version 1.4.1 (released in April 2019), you now have the option to use a new type of ordering service based on Raft which changes that … but we’ll get to that later on.
As of version 1.4.0, Fabric’s ordering service came in two different flavors: Solo, for development purposes, and Kafka, for production.
The Solo ordering service consists of a single node. When you use Solo, your network is clearly not decentralized and is not fault tolerant — but that’s OK because, again, it is just for development purposes. Solo is designed to provide the ordering service in its simplest possible form so that you can focus on other matters, such as the development of your chaincode and application, without having to worry about the ordering service. However, this is obviously not suitable for production deployments. For production, Fabric 1.4.0 provides the Kafka ordering service.
The Kafka ordering service leverages a cluster of Kafka brokers and a Zookeeper ensemble to provide for a crash fault tolerant (CFT) ordering service. It is possible for your ordering service to consist of several ordering nodes that are under the control of different organizations on your network. However, while the result is distributed, it is still not fully decentralized. The difference lies in the point of control because Kafka and Zookeeper are not designed to be run across large networks, but rather in a tight group of hosts. This means that practically speaking you need to have one organization run both the Kafka cluster and the Zookeeper ensemble. Given that, having ordering nodes run by different organizations doesn’t give you much in terms of decentralization because they will all go to the same Kafka cluster, which is under the control of a single organization.
Does this mean that Fabric is actually not decentralized? No, it doesn’t. And the latest version of Fabric (1.4.1) makes that clear.
Fabric 1.4.1 and beyond
Fabric 1.4.1 brings a new type of ordering service that is based on Raft. Although Raft is not Byzantine fault tolerant (BFT) either — meaning it is not designed to protect against adversarial organizations on the network — it does get you one step closer to decentralization of the ordering service because with the removal of the dependency on Kafka and Zookeeper, having ordering nodes run by different organizations now makes sense.
Raft is expected to become the default ordering service in all production deployments moving forward. It is actually simpler to manage because it is just a library that is used by the ordering node, so there are fewer moving parts and it provides for decentralization.
Looking forward, a BFT ordering service will be implemented at some point, and when it becomes available you will be able to have a fully decentralized Fabric network.
It is worth noting that, as I stated earlier, the ordering service is only one of three steps in Fabric’s consensus mechanism, and while the Kafka-based ordering service is not decentralized the other two steps are anyway.
A malicious or compromised organization running the ordering service might be able to impact the order in which the transactions are ordered in a block, which can favor transactions from one organization over those from others or, worse, deny service to some organizations — but the potential impact is limited. Controlling the ordering service is not sufficient to get an invalid transaction added to the ledger because the other steps in the consensus process protect the network against that.
It is also worth noting that not all use cases require a BFT network. For example, when deploying a blockchain network within a single enterprise or within a small set of business partners, a fully BFT network might not be worth the associated performance cost. As always, there are trade-offs and that’s why Fabric is designed to be very modular with pluggable components to support different possible deployments.
Hyperledger Fabric’s design supports blockchain networks that are fully decentralized. The Kafka-based ordering service provides for a crash fault tolerant ordering service that is not fully decentralized, but version 1.4.1 brings a Raft-based ordering service that gets you one step closer to having a decentralized network, and you will eventually be able to have a fully decentralized Fabric network when the BFT ordering service does become available.