Blockchain technology’s inherent features are the driving factors behind its widespread incorporation as well as its involvement in upcoming innovations such as Web 3.0. But, despite all the apparent merits, it is still a new technology with less than two decades of existence. Advancements have been appearing across separate areas of research specialization with several notable ones stemming from one of the defining characteristics of blockchain technology- the Consensus mechanism. With blockchains like Ethereum shifting their working mechanism, it is worthwhile to delve a bit into the world of BFTs(particularly FastBFT), and understand how these functions can help expedite processes within the blockchain network.
The BFT mechanism is a core element of consensus mechanisms prevalent in distributed computer architecture such as blockchain. It can be referred to as the system’s ability to override complications and form consensus even with the possibility of disagreement between node members within the network, intentionally or unintentionally. Bitcoin’s proof of work(PoW) algorithm achieves this through technical solutions(with high computation requirements), provided over 2/3rd of the node members stay faithful to the system.
The consensus algorithm for Byzantine Fault Tolerance has been derived from the famous Byzantine Generals’ Problem explained in a 1982 Microsoft Research paper by Marshall Pease, Leslie Lamport, and Robert Shostak. The paper describes the need for an algorithm to ensure loyal Byzantine generals can successfully enact the winning strategy even with the existence of disloyal persons.
The paper for Practical Byzantine Fault Tolerance i.e. PBFT was published by Barbara Liskov and Miguel Castro in 1999. The proposition utilizes a functional algorithm through SMR(state machine replication). Also, for tolerating Byzantine faults. The process facilitates real-time data access and security, under two conditions:
a) A maximum of (n-1)/3 modes can be defective, with “n” being the total number of nodes.
b) The “t” delay does not outpace the growth rate indefinitely.
Delay refers to the exact time taken for the message transmission between sender and receiver.
As per general conventions, “f” represents byzantine failure nodes. The system is required to address two possible complications. The first possibility is the failure in delivering the message, while the second one reflects the chance of sending a separate message with malicious intent. In both cases, the network system must continue to function after the completion of n-f nodes.
It should however be noted that there may a chance that the responding failure nodes “f” may not always be inaccurate. This is why practical BFT solutions require an approach to outnumber faulty processes( e.g. (n-f)-f>f ). Hence, n>3f+1 is optimal recommended solution.
The Hyperledger fabric utilizes PBFT and the Kafka order system. The drawback of the Kafka ordering system is its failure to comply with BFT. The system makes up by offering crash fault tolerance and finality. This shields the mechanism from achieving consensus agreement in case of malicious nodes.
The blockchain processes reach consensus when:
a) All nodes agree upon the output value: A common output determines accuracy leading to process termination.
b) A majority of the nodes acknowledge the same output value: A majority consensus of agreement on a consensus value leads to output determination.
Decentralized blockchain technology has the BFT requirement inbuilt within its protocol. The PoW mechanism of Bitcoin solves the aforementioned Byzantine Generals Problem through the lack of a centralized authority, achieving a majority consensus despite the presence of non-trustworthy parties and a non-instantaneous network.
Under ideal zero-network latency conditions, BFT is 50%. In real-world application, the tolerance reduces to 49.5% in Bitcoin and 46% in Ethereum respectively. Under conditions where the network latency becomes equivalent to block time or approaches infinity, the byzantine fault tolerance becomes 33% and 0 respectively.
Byzantine faults are often arbitrary in nature, comprising a wide possibility of failures including crash failures, software bugs, cybersecurity attacks, collusion between nodes with illlicit intent and more. One of the main preferences for expediting Bzantine consensus protocol is low latency. At least two communication steps are necessary for consensus completion, in addition to require a hardware/computer application for Trusted Execution Envrironment(TEEs).
The FastBFT protocol is a noticeable improvement with significant improvements in speed and security. The technique utilizes message accumulation with hardware-centric TEEs with a facility for sharing lightweight secrets. FastBFT also comprises tree topology and failure detection capabilities.
The Secret Sharing system protects confidential data by splitting it into several pieces, which are later combined together to get the whole picture. The tiny bits of secrets are known as shadows. The data is shared using the (k,n) secret sharing scheme, where ‘n’ denotes the number of split pieces and ‘k’ represents the minimum number of required pieces for retrieving a secret. In special cases such as the XOR, where k=n, all the shadows are necessary, for the original message to be destroyed.
The Fast BFT is capable of detecting and segregating failures. Timeouts are used for crash faults. The verified shares are utilized for byzantine faults. The practice of message aggregation decreases operational cost communication. Instead of sending the same message to all nodes, a node transmits a single message to the root node(Primary). The primary node organizes the nodes into a balanced tree structure with proper distribution of communication and computational costs.
Research experiments have demonstrated that with a payload size limit of 1MB and a network of 200 nodes, FastBFT throughput is at least 8x faster than other available BFT protocols. The throughput increases further with smaller load sizes and node numbers and declines rather slowly in comparison to the other BFT protocols. Thus, FastBFT is one of the ideal options for the next generation of blockchain applications.
If we compare Bitcoin with FastBFT, the latter processes more than 100,000 transactions each second with the former’s parameters(1 MB block, 250 bytes for each transaction). Meanwhile, Bitcoin delivers just 7 transactions per second with its PoW mechanism. The world’s largest Ethereum blockchain has a transaction throughput currently capped at 15 transactions/second.
The FastBFT protocol has the potential to be a giant leap forward in terms of the blockchain revolution. It can be a perfect solution for one of the main challenges blockchain faces today: scalability.