tower consensus naming (#4598)

s/locktower/tower/g

book/src/SUMMARY.md

@@ -62,11 +62,11 @@
   - [Blocktree](blocktree.md)
   - [Cluster Software Installation and Updates](installer.md)
   - [Deterministic Transaction Fees](transaction-fees.md)
-  - [Fork Selection](fork-selection.md)
+  - [Tower BFT](tower-bft.md)
   - [Leader-to-Leader Transition](leader-leader-transition.md)
   - [Leader-to-Validator Transition](leader-validator-transition.md)
   - [Passive Stake Delegation and Rewards](passive-stake-delegation-and-rewards.md)
   - [Persistent Account Storage](persistent-account-storage.md)
   - [Reliable Vote Transmission](reliable-vote-transmission.md)
   - [Repair Service](repair-service.md) 
-  - [Testing Programs](testing-programs.md)
+  - [Testing Programs](testing-programs.md)

book/src/block-confirmation.md

@@ -4,7 +4,7 @@ A validator votes on a PoH hash for two purposes. First, the vote indicates it
 believes the ledger is valid up until that point in time. Second, since many
 valid forks may exist at a given height, the vote also indicates exclusive
 support for the fork. This document describes only the former. The latter is
-described in [fork selection](fork-selection.md).
+described in [Tower BFT](tower-bft.md).
 
 ## Current Design
 
@@ -50,12 +50,11 @@ log the time since the NewBlock transaction was submitted.
 
 ### Finality and Payouts
 
-Locktower is the proposed [fork selection](fork-selection.md) algorithm. It
-proposes that payment to miners be postponed until the *stack* of validator
-votes reaches a certain depth, at which point rollback is not economically
-feasible. The vote program may therefore implement locktower. Vote instructions
-would need to reference a global locktower account so that it can track
-cross-block state.
+[Tower BFT](tower-bft.md) is the proposed fork selection algorithm.  It proposes
+that payment to miners be postponed until the *stack* of validator votes reaches
+a certain depth, at which point rollback is not economically feasible. The vote
+program may therefore implement Tower BFT. Vote instructions would need to
+reference a global Tower account so that it can track cross-block state.
 
 ## Challenges
 

book/src/fork-generation.md

@@ -55,7 +55,7 @@ Validators can ignore forks at other points (e.g. from the wrong leader), or
 slash the leader responsible for the fork.
 
 Validators vote based on a greedy choice to maximize their reward described in
-[forks selection](fork-selection.md).
+[Tower BFT](tower-bft.md).
 
 ### Validator's View
 

book/src/leader-rotation.md

@@ -96,7 +96,7 @@ ends up scheduled for the first two epochs because the leader schedule is also
 generated at slot 0 for the next epoch.  The length of the first two epochs can
 be specified in the genesis block as well.  The minimum length of the first
 epochs must be greater than or equal to the maximum rollback depth as defined in
-[fork selection](fork-selection.md).
+[Tower BFT](tower-bft.md).
 
 ## Leader Schedule Generation Algorithm
 

book/src/ledger-replication-to-implement.md

@@ -74,7 +74,7 @@ The program should have a list of slots which are valid storage mining slots.
 This list should be maintained by keeping track of slots which are rooted slots in which a significant
 portion of the network has voted on with a high lockout value, maybe 32-votes old. Every SLOTS\_PER\_SEGMENT
 number of slots would be added to this set. The program should check that the slot is in this set. The set can
-be maintained by receiving a AdvertiseStorageRecentBlockHash and checking with its bank/locktower state.
+be maintained by receiving a AdvertiseStorageRecentBlockHash and checking with its bank/Tower BFT state.
 
 The program should do a signature verify check on the signature, public key from the transaction submitter and the message of
 the previous storage epoch PoH value.

book/src/persistent-account-storage.md

@@ -60,7 +60,7 @@ The read is satisfied by pointing to a memory-mapped location in the
 
 ## Root Forks
 
-The [fork selection algorithm](fork-selection.md) eventually selects a fork as a
+[Tower BFT](tower-bft.md) eventually selects a fork as a
 root fork and the fork is squashed.  A squashed/root fork cannot be rolled back.
 
 When a fork is squashed, all accounts in its parents not already present in the

book/src/stake-delegation-and-rewards.md

@@ -77,7 +77,7 @@ count as stakes.
 ### VoteInstruction::Vote(Vec<Vote>)
 
 * `account[0]` - RW - The VoteState
-  `VoteState::lockouts` and `VoteState::credits` are updated according to voting lockout rules see [Fork Selection](fork-selection.md)
+  `VoteState::lockouts` and `VoteState::credits` are updated according to voting lockout rules see [Tower BFT](tower-bft.md)
 
 
 * `account[1]` - RO - A list of some N most recent slots and their hashes for the vote to be verified against.

book/src/tower-bft.md

@@ -1,7 +1,7 @@
-# Fork Selection
+# Tower BFT
 
-This design describes a *Fork Selection* algorithm. It addresses the following
-problems:
+This design describes Solana's *Tower BFT* algorithm. It addresses the
+following problems:
 
 * Some forks may not end up accepted by the super-majority of the cluster, and
 voters need to recover from voting on such forks.