X

The Supply Chain Management Blog covers the latest
in SCM strategy, technology, and innovation.

Oracle Blockchain Platform adds the Raft Consensus Algorithm

Baohua Yang, and Mark Rakhmilevich

One new major feature in the recent release of the Oracle Blockchain Platform is the enhanced consensus protocol with a new Raft algorithm. With this new type of consensus, blockchain users can manage larger sized networks compared with the previous version, while also improving data privacy and governance capability.

So why does consensus protocol mean so much to a blockchain network? And why did the Oracle Blockchain Platform decide to adopt the Raft consensus protocol? What benefits will the customers gain with the new feature? This blog will reveal all the secrets underneath and respond to these questions.

Why is consensus important to Blockchain?

Most Blockchain users already know that a blockchain network is a typical distributed system, which consists of a number of decentralized nodes maintaining a copy of a distributed ledger and executing smart contracts. The network achieves trust by enabling multiple members to store a copy of the ledger locally and to only allow updates based on the agreement of the members expressed through the smart contract endorsements and associated policies.

But where does this trustworthy data come from? What if someone sends malicious transactions to the blockchain? The answer here is that a practical consensus algorithm will guarantee the data consistency among different members. One of the widest deployed enterprise blockchain frameworks, Hyperledger Fabric (the largest open-source enterprise distributed ledger project hosted by the Linux Foundation and adopted by Oracle Blockchain Platform) enforces a policy mechanism, which requires that before a member can send a transaction to the network, it must collect enough endorsements (implemented as PKI signatures) as defined by policies agreed with other members sharing the same ledger. And once the transaction is sent to the network, the ordering service will cut the batch of transactions into blocks and distribute it to the network nodes. The entire process aims to provide exactly what the consensus does here – to allow different members of a distributed system to have the same global view of the data with continuous updates from multiple sources. Because of its significance, consensus is still an important computer science research topic in spite of a long history of nearly fifty years' study.

In theory, a valid consensus algorithm in distributed systems must achieve safeness and liveness properties at the same time. Safeness means that as long as most users are following the same consensus protocol, with arbitrary transactions from different members, the ledger data must be valid, or the majority of members must see the same copy of ledger data, even with the possibility of data corruptions at the client side or during network data transmission. Liveness is the other basic requirement that at any time, the operation of the distributed ledger should be completed within a given time window, even with faulty nodes or connectivity fluctuations, as long as a majority of members in the network are healthy. This property allows the blockchain network to continue operation and be tolerant even if some members are offline.

Besides safety and liveness, in practice, the scalability must be taken into consideration. It is easier for a consensus algorithm to achieve good performance (e.g., throughput and latency) with a small size such as only three nodes. But it can be more challenging with large scale networks containing tens or hundreds of nodes.

Evaluating these three properties, the Oracle Blockchain Platform development team decided to support the Raft protocol in the new release, which will serve our customers who care about decentralization with better performance and data privacy.

What is the Raft consensus protocol?

The Raft consensus protocol was first introduced in 2013, and since then it was adopted widely in a number of production-ready projects such as Kubernetes and Hyperledger Fabric.

In previous release, Oracle Blockchain Platform provided the Kafka based consensus. As illustrated in the Figure 1, the Kafka based consensus is simple in architecture. Since every orderer node in the blockchain will connect to the Kafka cluster directly, all transactions in the network must be sent to the Kafka cluster. This introduces a shortcoming of the single failure point that once the Kafka cluster is broken, the entire blockchain network will be out of service.

An additional limitation of using Kafka is that its performance suffers significantly when its brokers are distributed across multiple datacenters in a wide area network (WAN).  This implies that it’s best to deploy it in one organization’s datacenter and leads to a common topology where all ordering nodes are supplied by a single organization, typically designated as Founder.  This limits the degree to which the network is decentralized if all the transactions must go through the Founder’s ordering nodes, and imposes restriction on the privacy capabilities of individual groups of members that may prefer to not share their transactions with the Founder node.

The Raft consensus is designed as an alternative to the Kafka-based consensus in Hyperledger Fabric. Both protocols are proven safe and correct in consensus, but the Raft algorithm offers the additional advantages as its implementation using Replicated State Machine architecture doesn’t depend on external components, such as Kafka.  This enables a simple implementation, meaning that the ordering service will be realized in a more elegant architecture, as shown in the Figure 2.

Raft ordering in blockchain

In the Raft consensus, the orders will finish the negotiation among them directly, without additional dependencies of external Kafka cluster. And they may be associated into several clusters. For example, in Figure 2, Orderer 1, Orderer 2 and Orderer 3 connect with each other as one cluster, while Orderer 4, Orderer 5 and Orderer 6 group together as another cluster. It is notable that the transactions sent to different clusters are isolated from each other, which results in better data privacy protection.

What advantages does the new RAFT consensus offer?

With the new consensus mechanism, Oracle Blockchain Platform offers the following advantages to customers:

Simplification of Architecture

Removing the dependency on Kafka makes the deployment and scale-out simpler, improving resilience of the blockchain platform overall and its manageability.  Fewer components and network connections to manage helps to reduce potential failure scenarios and avoids using additional CPU resources to provide replication of these extra components for high availability.

Improved data privacy and confidentiality

Privacy is increasingly important for today's enterprise blockchain applications. When different consensus clusters (i.e., the consenter set) are available by combining groups of orderers that are contributed by different organizations, customers can choose the specific consenter set for their channel to increase the privacy of their ledger. For example, there are two channels using individual consensus cluster respectively, the transaction sent to one channel will be separated from the other. In this case, even with the same Blockchain network, users can choose who they would like to share the data with.  In the past, Founder’s orderers were involved in all transactions.

Oracle customers involved in global consortiums, such as the Global Shipping Business Consortium launched by CargoSmart with nine leading ocean carriers and terminal operators, operate in a number of countries with different government mandates concerning data residency and sovereignty.  Separating domestic transactions from international ones using separate channels and related sets of Raft orderers provides the flexibility to meet these regulatory requirements.

Higher scalability

With Kafka consensus, every orderer needs to join all channels in the network, hence the throughput of the entire network will be limited by the Kafka cluster, no matter how many channels exist. On the contrary, with the new Raft consensus, since the orderer node does not need to join every channel, the network can be extended to a larger scale by supporting more channels with separate sets of orderer nodes. This ability to independently scale the ordering clusters based on the needs of the specific channels they host is critical for high volume blockchains, such as those being contemplated for Central Bank Digital Currency (CBDC.)  Improved scalability, resilience, and independent granular scaling based on specific load requirements are key to large scale deployments of enterprise blockchains in financial services, supply chains, healthcare, and public sector.

More flexible governance

Flexible and democratic governance is at the core of decentralized management. With Kafka consensus, the member who owns the Kafka cluster (a.k.a, the Founder instance) is typically the admin of the entire network, which leads to a partially centralized governance model. However, with the new Raft-based consensus feature, any organization can have ordering nodes and contribute them to varied consenter sets. Then each channel (an isolated ledger) can be created with its respective authorized group of members, who will offer the ordering service through their ordering nodes. For example, company A, B and C can agree to administer the channel ABC together, and company C, D and E can administer channel CDE by managing its corresponding ordering service. As the result, the entire Blockchain network will be governed by multiple groups of members in a more decentralized approach.

Highest Degree of Resilience Through Geo-redundancy

Since multiple instances deployed across geographic regions can contribute Raft-based ordering nodes to support different channels, it now becomes possible to run a geographically distributed ordering cluster, ensuring geo-redundancy. With sufficient number of regions and ordering nodes, a failure or communication disruption with a particular region, will not impact other blockchain nodes operating outside the impacted region as long as there’s sufficient number of orders remaining.  Raft protocol requires a quorum of nodes defined as N/2 + 1, where N >= 3 is the initial number of ordering nodes in the network. For blockchains operating on a global level, this geo-redundancy is an important factor.  With Oracle Blockchain Platform available across many OCI datacenters, this is easy to achieve as shown in this example topology below.


This topology can be expanded further to multi-cloud deployments in order to spread the blockchain nodes across multiple vendors.  For example, an Oracle partner, HACERA, has created a MiPasa.org blockchain network to provide researchers data lineage and provenance traceability for COVID-19 pandemic datasets released by various health authorities around the world. To ensure a decentralized governance model and highest levels of resilience, including geo-redundancy, the blockchain network uses blockchain nodes from Oracle, IBM, and Microsoft cloud datacenters across the world.  Researchers and healthcare professionals depend on the trustworthiness of the datasets anchored on MiPasa blockchain to search for answers to combat the spread of the virus and examine the results reported by the many trials of therapeutics and vaccines. The decentralized governance of the network is a key enabler of this trust and geo-redundancy ensures highest levels of resilience.

In summary, the new enhanced consensus feature of Oracle Blockchain Platform will help enterprise customers to easily extend their business consortiums to larger size with better data privacy protection and decentralized governance, by adopting the most advanced blockchain technologies.

How to try the new feature

Using Oracle Blockchain Platform, each new created instance, whether a Founder or Participant, will by default enable the new Raft consensus. The Participant instances have an orderer that is not activated by default. Follow this documentation to add their orderer to the network and assign it to various channels.  Once done, a participant instance will be able to become a part in the ordering service. To manage which orderers support a specific channel, follow this documentation on adding or removing orderers from a channel.

Existing instances that are still using Kafka consensus can request migration to the new release with ledger preservation, which will enable them to use the new Raft-based ordering consensus.

For more information about the new features of this release, please visit the Oracle Blockchain Platform Cloud Service documentation page and the Oracle Blockchain website.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.