What is Sawtooth PBFT in Hyperledger?

The Sawtooth PBFT is a voting-based consensus algorithm with Byzantine fault tolerance (BFT). The article focuses on discussing the Sawtooth PBFT in Hyperledger. The following topics will be discussed here:

1. What is a Sawtooth PBFT?
2. What Is PBFT?
3. What is Primary Node?
4. Network Overview
5. How Does PBFT Work?
6. Pros of Sawtooth PBFT
7. Cons of Sawtooth PBFT

Let’s start discussing each of these topics in detail.

What is Sawtooth PBFT? 

Sawtooth PBFT (Practical Byzantine Fault Tolerance) is a voting-based consensus algorithm used in the Hyperledger Sawtooth blockchain platform. PBFT is a type of distributed consensus algorithm that allows a network of nodes to reach an agreement on the state of a distributed ledger, without the need for a trusted third party.

• It runs on each node on the network as a consensus engine that handles consensus-related functionality and communicates with the validator through the consensus API.
• In a PBFT-based system, each node in the network maintains a local copy of the ledger and communicates with other nodes to exchange information and reach a consensus on the current state of the ledger. 
• This is done through a series of rounds, where each node sends a message (called a “pre-prepare” message) to the other nodes, indicating the transactions that it would like to include in the next block.
• Once a node receives a pre-prepare message from a majority of the other nodes, it sends a “prepare” message to the network, indicating that it is ready to commit the proposed transactions to the ledger. 
• If a majority of the nodes send a prepare message for the same set of transactions, the node will then send a “commit” message, and the transactions will be added to the ledger.
• This process continues until all nodes in the network have reached a consensus on the current state of the ledger. 
• The network can tolerate a certain number of bad nodes. The network will work properly as long as the number is not exceeded.

PBFT is considered a “Byzantine fault tolerant” algorithm because it is able to tolerate failures or malicious behavior by some nodes in the network without compromising the integrity of the ledger.

Sawtooth PBFT is a variant of the PBFT algorithm that is specifically designed for use with the Hyperledger Sawtooth platform. It incorporates features from the Sawtooth platform, such as the use of cryptographic “leaves” to represent transactions and the ability to support multiple transaction families (i.e., different types of transactions) on the same ledger.

What is PBFT?

PBFT is Practical Byzantine Fault Tolerance a consensus algorithm that is designed to work in practical, asynchronous environments. 

• It is leader-based and non-forking.
• It does not support open enrollment but nodes can be added and removed by an administrator.
• It requires full peering which means all nodes must be connected to all other nodes.

In PBFT as long as a minimum number of nodes are working properly, and connected to the network then the network will make progress and will not allow any node on the network to manipulate the network.

What is a Primary Node?

The nodes on the Sawtooth PBFT network send many messages to reach consensus, commit blocks, and maintain a healthy leader node called a primary node. 

• The network switches to the primary node when the current primary node is faulty or at regular intervals.
• The primary node builds and publishes the blocks.
• The secondary nodes (nodes other than the primary node) vote on the blocks and health of the leader i.e. primary node.

Network Overview

1. Fault Tolerance: In a Practical Byzantine Fault Tolerance (PBFT) network, a series of nodes are ordered from 0 to n-1, where n is the total number of nodes in the network. The PBFT network can only tolerate up to a certain number of “bad” nodes, referred to as the constant f, which is equal to one-third of the total number of nodes in the network. This means that no more than a third of the network (rounded down) can be dishonest or out of order for the algorithm to work properly.

f = (n – 1) / 3 

Here,

n = Total number of nodes in network.
f = Maximum number of faulty nodes.

2. View Changes: This means choosing a new primary node. As the network operates, the nodes move through a series of “views,” where each view represents a period of time in which a given node is the primary leader of the network. In this way, each node takes turns being the primary in a continuous cycle, starting with the first node. 

Example:

In a four-node network,

node 0: primary at view 0
node 1: primary at view 1, and so on. 

When the network reaches view 4, it will “wrap back around” so that node 0 is the primary again.

The PBFT algorithm determines the primary node for each view based on the view number and the ordering of the nodes, using the formula:

p = v mod n

The Sawtooth PBFT changes the primary node at regular intervals or when the secondary nodes determine that the current primary node is faulty.

3. Sequence numbers: In Sawtooth PBFT, the sequence number is equivalent to the block number. For example, a node is on sequence number 5 is equivalent to saying that the node is performing consensus on block 5 in the chain.

4. Information Storage: Each node on the network maintains the following pieces of information:

• The list of nodes on the network.
• The current view number.
• The current sequence number.
• The current head of the chain.
• Log of the blocks it has received.
• Logs of the messages it has received.
• In the case of Normal operation mode, the step of the algorithm the node is currently on.

5. Network Configuration: Sawtooth PBFT configures the network with on-chain settings which list each node in the network, set the view-change interval, and specify items like timeout periods, block publishing frequency, and message log size. 

Message Types 

Below are the different types of Sawtooth PBFT messages:

Message Type	Description
PrePrepare	This message is sent by the primary node after it has published a new block.
Prepare	This message is broadcasted by every node in the Preparing phase.
Commit	This message is broadcasted by every node in the Committing phase.
ViewChange	This message is sent by any secondary node that suspects that the primary node is faulty.
NewView	This message is sent by the node that will be the new primary node to complete a view change.
Seal	This message proves that a block was committed after 2f + 1 node agreed to commit it.
SealRequest	This message is sent by a node that is requesting a consensus seal for the block that was committed at a given sequence number.

How Does PBFT Work?

The Sawtooth PBFT starts with the Initialization phase and then operates in two modes, Normal mode and View Changing mode.

• Initialization: When Sawtooth PBFT starts, it loads the configuration, Initializes its state and message log, and establishes timers and counters.
• Normal mode: In a PBFT consensus algorithm, the nodes in the network go through three phases in order to commit a new block and make progress on the distributed ledger. These phases are:

1. PrePreparing Phase: All nodes begin in prepreparing phase and the purpose of this phase is for the primary node to publish a new block and endorse the block with the preprepare message. 

• The primary node sends a request to its validator to initialize a new block.
• After a configurable timeout, the primary node will send a request to the validator to finalize the block and broadcast it to the network.
• All nodes after receiving the new block in the BlockNew update and ensuring the block is valid will store the block in their PBFT logs.
• After receiving the BlockNew update, the primary node will broadcast the PrePrepare message to all the nodes on the network. When the nodes receive PrePrepare message, they will make sure that it is valid and if it is valid they will add it to their logs and move to the next phase Preparing phase.

2. Preparing Phase: In the prepare phase, the secondary nodes broadcast a Prepare message that matches the accepted PrePrepare message. Each node will add its own Prepare message to its log, accept Prepare messages from other nodes and add them to its log. Once the node has 2f +1 Prepare messages that match with the accepted PrePrepare message it has received, then it will move to the committing phase.

3. Committing Phase: In this phase, the primary node is also allowed to broadcast a message. Here, the nodes will broadcast a commit message to all nodes in the network and wait until there are 2f +1 commit messages in their logs and move on to the finishing phase. 

4. Finishing Phase: In this phase, each node will tell its validator to commit the block for which they have matching PrePrepare message, 2f + 1 Prepare message, and 2f + 1 Commit messages. The node will wait for the BlockCommit message from the validator and upon receiving the message the node will increment the sequence number by 1, Update the current chain head to the newly added block, and reset its phase to PrePreparing phase.

Log Pruning: When the block is committed, each node compares the size of its log with the maximum log size (–max_log_size) and if the size exceeds then Sawtooth PBFT follows these rules to prune the log:

• It keeps the blocks and messages for the sequence number of the block that was just committed and for those of any higher sequence numbers.
• Delete blocks and messages for all lower sequence numbers.

View Changing mode: View changing is a mechanism that is used in PBFT (Practical Byzantine Fault Tolerance) consensus algorithms to handle situations where the primary node is unable to fulfill its duties. In a PBFT system, the primary node is responsible for receiving client requests, broadcasting them to the other nodes in the network, and executing requests that have been agreed upon by a sufficient number of nodes. However, if the primary node becomes unavailable or unable to fulfill its duties, the other nodes in the network must take action to ensure that the system can continue to operate and reach a consensus. This is where view-changing comes into play. A node starts a view change process if any of the following situations occur:

• Idle timeout expires: When the node enters the PrePreparing phase it starts the idle timeout. If the node receives the new block and a matching PrePrepare message from the primary node for its current sequence number before the timer expires then it will stop the timeout else the node will initiate the view change.
• Commit timeout expires: When the node enters the PrePreparing phase it starts the commit timeout. If the node is able to move to the Finishing phase and send a request to the validator to commit the block before the timeout expires then it will stop the timeout else the node will initiate the view change.
• View change timeout expires: When the node starts a view change to view v it will start the view change timeout. If the node is able to complete the view change before the timeout expires then it will stop the timeout else the node will initiate a new view change to view v + 1.
• Multiple PrePrepare messages received: When multiple PrePrepare messages are received from the same view and sequence number but from different blocks then it means that the primary node is faulty.
• Prepare message received from primary node: If a prepare message is received from the primary node then it means that the primary node is faulty.
• f + 1 view change messages received from the same view: If f + 1 view messages are received from the same view then it means that a node does not want to wait for too long to start a view change.

View changing is a process by which the nodes in the network can select a new primary node to take over the duties of the old primary node. This typically involves a voting process, in which the nodes in the network agree on a new primary node. Once a new primary node has been selected, it can take over the duties of the old primary node and the network can continue to operate normally.

A node will perform the following actions to start a view change:

• The node will update its mode to ViewChanging(v) where v is the view the node is changing to.
• Stop both idle and commit timeouts.
• Stop the view change timeout if already started.
• Broadcast ViewChange message for the new view.

ViewChanging message are accepted and added to the log if they are for later view than the node’s current view or if the node is in the ViewChanging (v) mode and the view in the message must be greater than or equal to v. 

Once the node has received 2f + 1 ViewChange messages for the new view then it will start view change timeout. This timeout helps to ensure that the new primary node starts the new view in a timely manner.

View change timeout = (DesiredViewNumber  – CurrentViewNumber) * ViewChangeDuration

When the primary node for the new view receives 2f +1 ViewChange messages it will broadcast a NewView message to the network to signify that the new view is valid and it will add 2f + 1 signed ViewChange messages from the other nodes in the NewView message. This will be validated by other nodes on the network.

If a node receives the new primary’s valid NewView message before the view change timeout expires then the node will stop the timeout, update its view, and revert back to normal mode else the node will stop the timeout and initiate the new view change for view v + 1 where v is view the node was attempting to change before. 

Overall, view-changing is a critical mechanism in PBFT systems that ensures that the network can continue to operate and reach consensus, even in the event of a primary node failure.

Summary

1. A client sends a request to the network to perform a specific action, such as transferring funds.
2. The request is broadcast to all nodes in the network, known as replicas.
3. Each replica verifies the validity of the request and reaches a consensus on whether to approve or reject it.
4. Once a consensus is reached, the replicas enter the pre-prepare phase, where they prepare to execute the request.
5. In the prepare phase, the replicas send messages to each other indicating that they are ready to execute the request.
6. In the commit phase, the replicas send messages to each other indicating that they have committed to executing the request.
7. The replicas then execute the request and update their local copies of the ledger to reflect the changes.
8. Finally, the replicas send messages to each other to confirm that the request has been executed and the ledger has been updated.
9. The client receives a response from the network indicating the success or failure of the request.

Pros of Sawtooth PBFT

Some of the main advantages of Sawtooth PBFT include:

• High performance: PBFT is designed to be a high-performance consensus algorithm, with low latency and high throughput. This means that it can handle a large number of transactions per second, making it well-suited for applications that require fast and efficient consensus-reaching.
• Fault tolerance: PBFT is a Byzantine Fault Tolerant (BFT) algorithm, which means that it can handle situations where some nodes in the network may be faulty or malicious. In a PBFT system, as long as less than 1/3 of the nodes are faulty, the network can still reach consensus and continue to operate normally.
• Simplicity: Compared to other BFT algorithms, PBFT is relatively simple to implement and understand. This makes it easier for developers to build applications on top of PBFT-based distributed ledgers.
• Security: PBFT uses digital signatures and other cryptographic techniques to ensure the authenticity and integrity of messages and transactions within the network. This helps to prevent malicious attacks and ensures the security of the distributed ledger.

Overall, Sawtooth PBFT offers a number of benefits over other consensus algorithms, making it a popular choice for distributed ledger systems.

Cons of Sawtooth PBFT

While Sawtooth PBFT (Practical Byzantine Fault Tolerance) offers several benefits over other consensus algorithms, it also has some limitations and drawbacks. Some of the main disadvantages of Sawtooth PBFT include:

• High resource requirements: PBFT is a resource-intensive algorithm, which can require a significant amount of computing power, memory, and network bandwidth. This can make it more challenging to implement in some environments, particularly in resource-constrained settings.
• Limited scalability: PBFT is not as scalable as some other consensus algorithms, such as Proof of Work (PoW) or Proof of Stake (PoS). This means that it may not be suitable for very large distributed ledger systems with a large number of nodes.
• Centralization: In a PBFT system, a single primary node is responsible for receiving client requests and coordinating the consensus process. This centralization of power can make the system vulnerable to attacks and malicious behavior.
• Slow view change: In the event of a primary node failure, the other nodes in the network must go through a view change process to select a new primary node. This can take some time, which can result in delays and disruptions to the normal operation of the system.

Overall, while Sawtooth PBFT offers several advantages over other consensus algorithms, it also has some limitations and drawbacks that must be considered when choosing a consensus algorithm for a distributed ledger system.