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 the blockchain:

(1). Who validates the transaction?

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

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

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

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.

Answer 3

"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.