FastBFT in Blockchain, Purpose, How It Works and Features

In order to attain high speed, FastBFT is a scalable Byzantine Fault Tolerant (BFT) consensus protocol that specifically addresses issues in blockchain networks. Although its liveness, or capacity to advance, depends on weak synchronization constraints, it is recognized as an asynchronous protocol.

The main features, operation, and performance of FastBFT are explained as follows:

Purpose and Evolution

• A fundamental part of consensus methods in distributed computer architectures like blockchain is the Byzantine Fault Tolerance (BFT) mechanism. It describes a system’s capacity to resolve conflicts and come to an agreement in spite of possible conflicts, intentional or not, between network nodes.
• The “Byzantine Generals Problem,” which was initially covered in a 1982 publication, is the lengthy history of advancements to BFT algorithms, including FastBFT. In order to withstand Byzantine faults, earlier protocols such as Practical Byzantine Fault Tolerance (PBFT), which was published in 1999, required state machine replication (SMR). Usually, more than 3f+1 total replicas are needed to tolerate f faulty ones.
• Motivated by the explosion of blockchain technologies that demand high-performance BFT algorithms, FastBFT seeks to expand on these developments. It is regarded as a possible remedy for blockchain scaling issues as well as an impending advancement in blockchain performance.

Important Features and Improvements

FastBFT is “fast” because of several approaches and optimizations:

• Hardware-assisted Secret Sharing and Trusted Execution Environments (TEEs): FastBFT uses TEEs, such Intel SGX, to put in place a simple secret sharing system. TEEs are protected regions inside a main processor that can thwart Sybil attacks and exhibit unchangeable uniqueness within a network. The TEE is used to calculate all cryptographic operations.
• Unique Sequence Numbers: TEEs ensure the monotonicity of a counter, which is used to assign unique, sequential numbers to client requests. This means replicas cannot assign the same counter value to different messages. This eliminates the need for the primary to assign unique sequence numbers and broadcast them for total order consensus, as is done in PBFT’s pre-prepare phase.
• Message Aggregation: This method drastically lowers the cost of communication. Each replica unicasts a single message to the primary rather than broadcasting it to all the replicas.
• Tree Topology: The primary arranges replicas into a balanced tree rooted at itself in order to further divide the expenses of computation and communication. This approach reduces communication complexity from O(n^2) to O(1) by enabling the protocol to reach consensus in a fixed number of message rounds, independent of the total number of replicas.
• Optimistic Approach (Hopeful Execution): FastBFT employs an optimistic approach where only a subset of replicas (f+1 active replicas) participate in agreement and execution, while others (f passive replicas) passively update their state and become active only if the agreement protocol fails. This concept, similar to optimistic replication, reduces replication costs and the number of communication messages.
• Two-Phase Protocol: Unlike PBFT, which requires three phases (pre-prepare, prepare, commit), FastBFT only needs two phases to proceed with the protocol to the use of TEEs.
• Novel Failure Detection:
  • Timeouts are used to identify crash issues. A non-leaf replica assumes a crash fault and sends a “SUSPECT” message if it doesn’t get a secret value from a child node within a predetermined amount of time.
  • Verifying shares helps identify Byzantine problems. Replicas compare the hash of the combined secrets from their descendants with a pre-calculated hash during the message aggregation process. A Byzantine fault is presumed if they diverge, and the defective replica is eliminated from the active group.

You can also read Blockchain Digital Signatures: Immutable And Verifiable

How FastBFT Works (Simplified Protocol Flow)

• During preprocessing (Secret Distribution), a secret (sc) is created for every counter value c, bound to the counter and view number, and then divided into n parts (shadows). A hash of the combined secrets from each replica’s descendants is sent to it. The ciphertext can only be decrypted by authorised replicas to authenticated encryption. This cryptographic data is used to create a digital signature.
• Client’s Request: The client sends a request containing the function name and parameters.
• Prepare Phase: To start the message aggregation process, the main multicasts a message.
• Non-leaf replicas set a timer and wait for their children to reveal secrets during the Commit Phase (Message Aggregation & Multicast). Replica leaves communicate their secrets to their parents. Non-leaf clones collect secrets from their offspring (confirmed by hashes) and forward them upwards until all secrets are sent to the primary. All active replicas get messages from the primary after it has aggregated all secrets. These replicas then carry out the operation and begin their own aggregation process for the reply phase.
• Reply Phase (Message Aggregation & Multicast): Secrets are aggregated upwards to the primary, just like in the commit phase. The primary multicasts messages to the client and passive replicas after aggregating all secrets. When a reply message is received, passive replicas update their status.

View Change and Checkpointing

• When the current primary is thought to be malfunctioning, the View Change Protocol is started. A message with a new view number is transmitted by accurate replicas. A message is broadcast upon receiving f+1 such messages. After receiving f+1 messages, the new primary broadcasts a message, chooses a fresh set of active replicas, and asks its TEE for a counter.
• Logging every message (, , ) consumes too much data, making checkpointing essential, especially for high transaction rates (e.g., 100,000 transactions/second Checkpointing overcomes this by trashing and erasing communications older than the last checkpoint. All operations following the most recent checkpoint are redone if the primary changes.

Performance

• According to reports, FastBFT can process 1800 transactions per second (TPS).
• It is said to have a latency of less than two seconds.
• FastBFT’s throughput was at least eight times quicker than that of other BFT protocols in tests using a network of 200 nodes and a 1MB payload. In comparison to other BFT protocols, it also demonstrated a noticeably slower throughput decline as network capacity increased.
• Under the same conditions, FastBFT can process over 100,000 transactions per second (1 MB block, 250 bytes per transaction), which is faster than Bitcoin’s Proof of Work (PoW) mechanism, which processes about 7 transactions per second. The throughput of Ethereum is now limited to 15 transactions per second.
• According to reports, FastBFT is six times quicker than Zyzzyva, lowering replica overheads to almost theoretical levels and reaching BFT protocols’ near-optimal efficiency.
• Environment and Implementation Golang has been utilised to implement FastBFT, while Intel SGX has been used for the Trusted Execution Environment. A private network of five computers with particular hardware setups was used for testing.

You can also read Explain Digital Signature Algorithm Definition, Advantages