!!! Overview
[{$pagename}] is the [Distributed Consensus] protocol implemented in [Hyperledger Indy] and is based on [Redundant Byzantine Fault Tolerance]


Plenum is an implementation of [Redundant Byzantine Fault Tolerance], a [Distributed Consensus] [algorithm] proposed by Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Quéma. As described in their paper, existing [BFT] [protocols] use a special [replica], called the "primary", which indicates to other [replicas] the order in which requests should be processed. This primary can be smartly [malicious] and degrade the performance of the system without being detected by correct [replicas]. The evaluation shows that RBFT achieves similar performance as the most robust protocols when there is no failure and that, under faults, its maximum performance degradation is about 3%, whereas it is, at least, equal to 78% for existing protocols."

[RBFT] implements a new approach whereby multiple instances of the [protocol] run simultaneously, a [Master|Master-slave] [Replica] instance, and one or more Backup instances. All the instances order the requests, but only the requests ordered by the Master instance are actually executed. All nodes monitor the Master and compare its performance with that of the Backup instances. If the Master does not perform acceptably, it is considered [malicious|Bad Actor] and replaced.

In addition to using RBFT, Plenum leverages [Reliable Asynchronous Event Transport] ([RAET]) [Protocol], a high-performance, fault-tolerant communications protocol on top of [UDP]. RAET leverages Daniel J. Bernstein's [Curve25519], a highly-secure high-performance [Elliptic Curve Digital Signature Algorithm].

[{$pagename}] uses  [Digitally Signed] [messages] using [CurveZMQ] which differs from [RBFT] using [Message Authentication Codes] \\While [MAC] [authenticators] are computationally less expensive to verify than [Digital Signatures], [{$pagename}] felt that given the foreseeable [protocol] applications today, the security trade-offs of using MACs would be too high.

[{$pagename}] has additionally implemented a process that applies a voting to select the primary. The election strategy is pluggable, meaning another strategy with different security and performance characteristics could be substituted easily. 
[RBFT] does not specify the election process, that is, how the primaries of each [protocol] instance are selected.

Apart for the [Distributed Ledger Technology], [nodes] maintain [state] (for each ledger) which is [Merkle Patricia Trie|Merkle Tree]. [nodes] might maintain several other projections of the ledger.

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [The Plenum protocol|https://github.com/hyperledger/indy-plenum/wiki|target='_blank'] - based on information obtained 2018-02-05- 
* [#2] - [indy-plenum|https://github.com/hyperledger/indy-plenum/blob/master/docs/main.md|target='_blank'] - based on information obtained 2018-12-07-