PBFT algorithm in hyperledger

Question

Can anyone explain PBFT Algorithm in detail without giving any link for the same? And how it works in hyperledger. So, once the transaction is sent to

Answer 1

The above is missing the Consensus algorithms from Hyperledger Sawtooth, so here they are:

• PoET Proof of Elapsed Time (optional Nakamoto-style consensus algorithm used for Sawtooth). PoET with SGX has BFT. PoET Simulator has CFT. Not CPU-intensive as with PoW-style algorithms, although it still can fork and have stale blocks . See PoET specification at https://sawtooth.hyperledger.org/docs/core/release s/latest/architecture/poet.html
• RAFT Consensus algorithm that elects a leader for a term of arbitrary time. Leader replaced if it times-out. Raft is faster than PoET, but is not BFT (Raft is CFT). Also Raft does not fork. Hyperledger Sawtooth has the advantage of having Unpluggable Consensus. An algorithm can be changed without reinitializing the blockchain or even restarting the software.

Here are some other consensus algorithms:

• PoW Proof of Work. Completing work (CPU-intensive Nakamoto-style consensus algorithm). Usually used in permissionless blockchains
• PoS Proof of Stake. Nakamoto-style consensus algorithm based on the most wealth or age (stake)
• PBFT Practical Byzantine Fault Tolerance. A "classical" consensus algorithm that uses a state machine. Uses leader and block election. PBFT is a three-phase, network-intensive algorithm (n^2 messages), so is not scalable to large networks

Answer 2

"Hyperledger" is a blockchain consortium under The Linux Foundation. Currently there are at least 4 different implementations of blockchain frameworks under Hyperledger:

• Fabric (IBM)
• Corda (R3)
• Iroha
• Sawtooth Lake (Intel)

In Fabric v0.6:

All validation peers keep open connection to each other. You can submit your transaction to any of them, and this transaction will be broadcasted to other peers in the network. One of peer is elected as "leader". At the moment when a new block is going to be generated:

1. The leader orders the transactions candidates that should be included in a block, and broadcasts this list of ordered transactions to all other validation peers in the network.
2. When each of the Validation Peers receives the ordered list of transactions, each validation peer does the following:
   1. It starts executing the ordered transactions one by one.
   2. As soon as all the transactions are executed, it will calculate the hash code for the newly created bloc (the hash code includes hashes for executed transactions and final state of the world).
   3. Then it broadcasts its answer (the resulting hash code) to other peers in the network, and starts counting the responses from them.
   4. If it sees that 2/3 of all validation peers have the same hash code, it will commit the new block to its local copy of the ledger.

In Fabric v1.0:

This version is still in development. In v1 the is no "leader", separate service "Orderer" is responsible for transactions order in a block. This service is pluggable and announced that the will be 3 different options:

1. Solo - single process is responsible for ordering
2. Kafka orderer - leverages the Kafka pubsub system to perform the ordering
3. PBFT - is not implemented yet.

In Corda:

PBFT is not used. This implementation uses another architecture approach.

Answer 3

pbft is a consensus algorithm given by Barbara Liskov and Miguel Castro in 1999 in order to prevent malicious attacks as malicious attacks and software errors can cause faulty nodes to exhibit Byzantine (i.e., arbitrary) behavior. pBFT was designed to work efficiently in asynchronous systems as compared to previous bft algorithms which only worked on synchronous systems.

here is the research paper which states that

Practical algorithm for state machine replication that tolerates Byzantine faults. The algorithm offers both liveness and safety provided at most ⌊n-1 / 3⌋ out of a total of replicas are simultaneously faulty. This means that clients eventually receive replies to their requests and those replies are correct according to linearizability. The algorithm works in asynchronous systems like the Internet and it incorporates important optimizations that enable it to perform efficiently

The algorithm works roughly as follows:

1. A client sends a request to invoke a service operation to the primary
2. The primary multicasts the request to the backups
3. Replicas execute the request and send a reply to the client
4. The client waits for 1 replies from different replicas with the same result; this is the result of the operation.

Like all state machine replication techniques, two requirements are imposed on replicas:

• They must be deterministic
• They must start in the same state.

Given these two requirements, the algorithm ensures the safety property by guaranteeing that all nonfaulty replicas agree on a total order for the execution of requests despite failures.

Limitations of pbft:

The pbft consensus algorithm works efficiently only when the number of nodes in the distributed network are less.

Hyperledger Fabric:

According to Hyperledger Fabric v1.4 the consensus mechanisms which are currently used include SOLO, Kafka, and Raft.

Hyperledger Sawtooth:

According to Hyperledger Sawtooth, how pbft is used is well explained here

Answer 4

In Corda, consensus is provided by notaries. It is up to the notary operator which consensus algorithm they use. BFT is one option. You can see a Corda BFT notary sample here: https://github.com/corda/corda/tree/master/samples/notary-demo.

To answer your questions:

(1). Who validates the transaction?

The transaction is validated by a cluster of one or more notaries. Notaries are nodes with the sole purpose of deconflicting double-spend attempts.

(2). How the consensus is achieved on the transaction?

Using a standard BFT algorithm. Each node in the notary cluster votes on whether they consider the transaction to be a double-spend attempt. The final decision is based on a majority rule, and can tolerate up to 1/3rd of the nodes in the cluster being malicious.

(3). How the transaction is committed to the blockchain?

In Corda, there is no central store of information that the transaction is committed to. The notary cluster simply adds the spent state reference to an internal database table. It will check future attempts to spend states against this table, and reject the spending attempt if the state reference is already stored there.