What is Tower BFT
Tower Byzantine Fault Tolerance (Tower BFT) acts as the consensus protocol underpinning Solana. Essentially, it is an adaptation of Practical Byzantine Fault Tolerance (PBFT) tailored to function with Solana’s Proof-of-History (PoH) clock. The protocol is the primary reason that Solana has been able to handle a vast amount of transaction throughput while simultaneously securing the network against malicious attacks.
The mechanics of Tower BFT are similar to that of a voting scheme with validators staking their SOL tokens to vote on transaction confirmation throughout the network. One of the core challenges in a standard PBFT is that it forces nodes to exchange multiple messages back and forth to come to an agreement, which can slow network speeds significantly. Tower BFT avoids this drawback by leveraging Solana’s PoH clock to facilitate a common shared time across nodes, thereby reducing the amount of messaging required for consensus. This feature, which enables the network to process thousands of transactions every second, is what allows the blockchain to maintain its speed and security.
Tower BFT received the moniker “tower” due to the stacking effect of validator votes on blocks. In short, when validators vote on a block, they are essentially casting their vote for a specific version of the Solana chain. If they choose to switch from one chain to another, the amount of time they have to wait is proportional to the number of votes they have already issued. This stack of votes is called a tower. This voting scheme helps the network reach consensus without compromising its security.
How Tower BFT Works on Solana
Tower BFT enables Solana’s high-speed consensus mechanism by utilizing stake-weighted voting. Each validator is assigned an epoch-based schedule based on the number of SOL tokens they have staked on their Solana node, which in turn grants them a slot where they may produce a block. A given schedule also defines a particular leader schedule, which means the validator knows who is supposed to produce a block and when.
Another important component of Tower BFT is the voting lockout mechanism. When a validator votes for a block, they are locked out of voting for any other version of the chain. The number of votes issued for a specific version of the chain also determines the length of the lockout period, i.e., the longer a validator votes for a chain, the longer the lockout period becomes. Validators would therefore prefer to stick with their chosen chain for as long as possible. This means validators will tend to stick to their chains and eventually converge on a specific chain that is not the subject of a fork as quickly as possible. Switching sides would result in significant costs due to missed block rewards.
For a block to be deemed final, it must have a combined two-thirds of the total stake that voted for it. Additionally, it requires at least 32 blocks after itself that each have two-thirds votes. These two requirements allow the network to reach a stable consensus with the highest degree of accuracy and at a fast speed. Another important aspect of Tower BFT is that it uses a Proof-of-History clock for consensus, so validators do not require any time-out messages or any messaging back and forth, which makes this mechanism much faster than standard PBFT systems.
Tower BFT’s Benefits and Security
The strong tie between the Tower BFT system and Proof-of-History makes it more resilient to potential attacks. This is because Proof-of-History creates a shared global view of time for every validator across the network. This allows the network to handle much higher transaction volumes while eliminating the need for any unnecessary messaging overhead.
Tower BFT also uses long lockout periods based on how many votes validators issue. This significantly increases the cost of attacking the network and is designed to deter potential double spending or chain fork attacks. If a validator switches their voting preference from one version to another, the lockout period becomes exponentially higher as a result, thereby making it difficult to vote for multiple chains simultaneously. In addition, Tower BFT also adopts a view-change mechanism from PBFT that ensures that in case a leader is unresponsive or malicious, another leader in the current leader schedule steps in and the network continues to move forward without any interruption.
Overall, this consensus protocol allows Solana to confirm transactions within a second while simultaneously processing thousands of transactions per second. Thanks to the combination of the voting tower scheme and Byzantine fault tolerance, Solana can scale up to accommodate any additional demand without sacrificing security or decentralization.
