Rename blocktree to blockstore (#7757)

automerge

banking-bench/src/main.rs

@@ -10,7 +10,7 @@ use solana_core::packet::to_packets_chunked;
 use solana_core::poh_recorder::PohRecorder;
 use solana_core::poh_recorder::WorkingBankEntry;
 use solana_ledger::bank_forks::BankForks;
-use solana_ledger::{blocktree::Blocktree, get_tmp_ledger_path};
+use solana_ledger::{blockstore::Blockstore, get_tmp_ledger_path};
 use solana_measure::measure::Measure;
 use solana_runtime::bank::Bank;
 use solana_sdk::hash::Hash;
@@ -139,11 +139,11 @@ fn main() {
     let mut verified: Vec<_> = to_packets_chunked(&transactions.clone(), PACKETS_PER_BATCH);
     let ledger_path = get_tmp_ledger_path!();
     {
-        let blocktree = Arc::new(
-            Blocktree::open(&ledger_path).expect("Expected to be able to open database ledger"),
+        let blockstore = Arc::new(
+            Blockstore::open(&ledger_path).expect("Expected to be able to open database ledger"),
         );
         let (exit, poh_recorder, poh_service, signal_receiver) =
-            create_test_recorder(&bank, &blocktree, None);
+            create_test_recorder(&bank, &blockstore, None);
         let cluster_info = ClusterInfo::new_with_invalid_keypair(Node::new_localhost().info);
         let cluster_info = Arc::new(RwLock::new(cluster_info));
         let banking_stage = BankingStage::new(
@@ -302,5 +302,5 @@ fn main() {
         sleep(Duration::from_secs(1));
         debug!("waited for poh_service");
     }
-    let _unused = Blocktree::destroy(&ledger_path);
+    let _unused = Blockstore::destroy(&ledger_path);
 }

book/art/validator.bob

@@ -18,9 +18,9 @@
       |      | `-------`  `--------` `--+---------`  | |  |            |  |
       |      |     ^              ^     |            | |  `------------`  |
       |      |     |              |     v            | |                  |
-      |      |     |           .--+--------.         | |                  |
-      |      |     |           | Blocktree |         | |                  |
-      |      |     |           `-----------`         | |  .------------.  |
+      |      |     |           .--+---------.        | |                  |
+      |      |     |           | Blockstore |        | |                  |
+      |      |     |           `------------`        | |  .------------.  |
       |      |     |                ^                | |  |            |  |
       |      |     |                |                | |  | Downstream |  |
       |      |  .--+--.     .-------+---.            | |  | Validators |  |

book/src/SUMMARY.md

@@ -21,7 +21,7 @@
 * [Anatomy of a Validator](validator/README.md)
   * [TPU](validator/tpu.md)
   * [TVU](validator/tvu/README.md)
-    * [Blocktree](validator/tvu/blocktree.md)
+    * [Blockstore](validator/tvu/blockstore.md)
   * [Gossip Service](validator/gossip.md)
   * [The Runtime](validator/runtime.md)
 * [Anatomy of a Transaction](transaction.md)
@@ -62,7 +62,7 @@
   * [Block Confirmation](proposals/block-confirmation.md)
   * [ABI Management](proposals/abi-management.md)
 * [Implemented Design Proposals](implemented-proposals/README.md)
-  * [Blocktree](implemented-proposals/blocktree.md)
+  * [Blockstore](implemented-proposals/blockstore.md)
   * [Cluster Software Installation and Updates](implemented-proposals/installer.md)
   * [Cluster Economics](implemented-proposals/ed_overview/README.md)
     * [Validation-client Economics](implemented-proposals/ed_overview/ed_validation_client_economics/README.md)

book/src/cluster/managing-forks.md

@@ -1,6 +1,6 @@
 # Managing Forks
 
-The ledger is permitted to fork at slot boundaries. The resulting data structure forms a tree called a _blocktree_. When the validator interprets the blocktree, it must maintain state for each fork in the chain. We call each instance an _active fork_. It is the responsibility of a validator to weigh those forks, such that it may eventually select a fork.
+The ledger is permitted to fork at slot boundaries. The resulting data structure forms a tree called a _blockstore_. When the validator interprets the blockstore, it must maintain state for each fork in the chain. We call each instance an _active fork_. It is the responsibility of a validator to weigh those forks, such that it may eventually select a fork.
 
 A validator selects a fork by submiting a vote to a slot leader on that fork. The vote commits the validator for a duration of time called a _lockout period_. The validator is not permitted to vote on a different fork until that lockout period expires. Each subsequent vote on the same fork doubles the length of the lockout period. After some cluster-configured number of votes \(currently 32\), the length of the lockout period reaches what's called _max lockout_. Until the max lockout is reached, the validator has the option to wait until the lockout period is over and then vote on another fork. When it votes on another fork, it performs a operation called _rollback_, whereby the state rolls back in time to a shared checkpoint and then jumps forward to the tip of the fork that it just voted on. The maximum distance that a fork may roll back is called the _rollback depth_. Rollback depth is the number of votes required to achieve max lockout. Whenever a validator votes, any checkpoints beyond the rollback depth become unreachable. That is, there is no scenario in which the validator will need to roll back beyond rollback depth. It therefore may safely _prune_ unreachable forks and _squash_ all checkpoints beyond rollback depth into the root checkpoint.
 

book/src/implemented-proposals/blocktree.md → book/src/implemented-proposals/blockstore.md

@@ -1,16 +1,16 @@
-# Blocktree
+# Blockstore
 
-After a block reaches finality, all blocks from that one on down to the genesis block form a linear chain with the familiar name blockchain. Until that point, however, the validator must maintain all potentially valid chains, called _forks_. The process by which forks naturally form as a result of leader rotation is described in [fork generation](../cluster/fork-generation.md). The _blocktree_ data structure described here is how a validator copes with those forks until blocks are finalized.
+After a block reaches finality, all blocks from that one on down to the genesis block form a linear chain with the familiar name blockchain. Until that point, however, the validator must maintain all potentially valid chains, called _forks_. The process by which forks naturally form as a result of leader rotation is described in [fork generation](../cluster/fork-generation.md). The _blockstore_ data structure described here is how a validator copes with those forks until blocks are finalized.
 
-The blocktree allows a validator to record every shred it observes on the network, in any order, as long as the shred is signed by the expected leader for a given slot.
+The blockstore allows a validator to record every shred it observes on the network, in any order, as long as the shred is signed by the expected leader for a given slot.
 
 Shreds are moved to a fork-able key space the tuple of `leader slot` + `shred index` \(within the slot\). This permits the skip-list structure of the Solana protocol to be stored in its entirety, without a-priori choosing which fork to follow, which Entries to persist or when to persist them.
 
-Repair requests for recent shreds are served out of RAM or recent files and out of deeper storage for less recent shreds, as implemented by the store backing Blocktree.
+Repair requests for recent shreds are served out of RAM or recent files and out of deeper storage for less recent shreds, as implemented by the store backing Blockstore.
 
-## Functionalities of Blocktree
+## Functionalities of Blockstore
 
-1. Persistence: the Blocktree lives in the front of the nodes verification
+1. Persistence: the Blockstore lives in the front of the nodes verification
 
    pipeline, right behind network receive and signature verification. If the
 
@@ -20,26 +20,26 @@ Repair requests for recent shreds are served out of RAM or recent files and out
 
 2. Repair: repair is the same as window repair above, but able to serve any
 
-   shred that's been received. Blocktree stores shreds with signatures,
+   shred that's been received. Blockstore stores shreds with signatures,
 
    preserving the chain of origination.
 
-3. Forks: Blocktree supports random access of shreds, so can support a
+3. Forks: Blockstore supports random access of shreds, so can support a
 
    validator's need to rollback and replay from a Bank checkpoint.
 
-4. Restart: with proper pruning/culling, the Blocktree can be replayed by
+4. Restart: with proper pruning/culling, the Blockstore can be replayed by
 
    ordered enumeration of entries from slot 0. The logic of the replay stage
 
    \(i.e. dealing with forks\) will have to be used for the most recent entries in
 
-   the Blocktree.
+   the Blockstore.
 
-## Blocktree Design
+## Blockstore Design
 
-1. Entries in the Blocktree are stored as key-value pairs, where the key is the concatenated slot index and shred index for an entry, and the value is the entry data. Note shred indexes are zero-based for each slot \(i.e. they're slot-relative\).
-2. The Blocktree maintains metadata for each slot, in the `SlotMeta` struct containing:
+1. Entries in the Blockstore are stored as key-value pairs, where the key is the concatenated slot index and shred index for an entry, and the value is the entry data. Note shred indexes are zero-based for each slot \(i.e. they're slot-relative\).
+2. The Blockstore maintains metadata for each slot, in the `SlotMeta` struct containing:
    * `slot_index` - The index of this slot
    * `num_blocks` - The number of blocks in the slot \(used for chaining to a previous slot\)
    * `consumed` - The highest shred index `n`, such that for all `m < n`, there exists a shred in this slot with shred index equal to `n` \(i.e. the highest consecutive shred index\).
@@ -53,16 +53,16 @@ Repair requests for recent shreds are served out of RAM or recent files and out
 
      is\_rooted\(0\) is\_rooted\(n+1\) iff \(is\_rooted\(n\) and slot\(n\).is\_full\(\)
 3. Chaining - When a shred for a new slot `x` arrives, we check the number of blocks \(`num_blocks`\) for that new slot \(this information is encoded in the shred\). We then know that this new slot chains to slot `x - num_blocks`.
-4. Subscriptions - The Blocktree records a set of slots that have been "subscribed" to. This means entries that chain to these slots will be sent on the Blocktree channel for consumption by the ReplayStage. See the `Blocktree APIs` for details.
-5. Update notifications - The Blocktree notifies listeners when slot\(n\).is\_rooted is flipped from false to true for any `n`.
+4. Subscriptions - The Blockstore records a set of slots that have been "subscribed" to. This means entries that chain to these slots will be sent on the Blockstore channel for consumption by the ReplayStage. See the `Blockstore APIs` for details.
+5. Update notifications - The Blockstore notifies listeners when slot\(n\).is\_rooted is flipped from false to true for any `n`.
 
-## Blocktree APIs
+## Blockstore APIs
 
-The Blocktree offers a subscription based API that ReplayStage uses to ask for entries it's interested in. The entries will be sent on a channel exposed by the Blocktree. These subscription API's are as follows: 1. `fn get_slots_since(slot_indexes: &[u64]) -> Vec<SlotMeta>`: Returns new slots connecting to any element of the list `slot_indexes`.
+The Blockstore offers a subscription based API that ReplayStage uses to ask for entries it's interested in. The entries will be sent on a channel exposed by the Blockstore. These subscription API's are as follows: 1. `fn get_slots_since(slot_indexes: &[u64]) -> Vec<SlotMeta>`: Returns new slots connecting to any element of the list `slot_indexes`.
 
 1. `fn get_slot_entries(slot_index: u64, entry_start_index: usize, max_entries: Option<u64>) -> Vec<Entry>`: Returns the entry vector for the slot starting with `entry_start_index`, capping the result at `max` if `max_entries == Some(max)`, otherwise, no upper limit on the length of the return vector is imposed.
 
-Note: Cumulatively, this means that the replay stage will now have to know when a slot is finished, and subscribe to the next slot it's interested in to get the next set of entries. Previously, the burden of chaining slots fell on the Blocktree.
+Note: Cumulatively, this means that the replay stage will now have to know when a slot is finished, and subscribe to the next slot it's interested in to get the next set of entries. Previously, the burden of chaining slots fell on the Blockstore.
 
 ## Interfacing with Bank
 
@@ -80,11 +80,11 @@ The bank exposes to replay stage:
 
    be able to be chained below this vote
 
-Replay stage uses Blocktree APIs to find the longest chain of entries it can hang off a previous vote. If that chain of entries does not hang off the latest vote, the replay stage rolls back the bank to that vote and replays the chain from there.
+Replay stage uses Blockstore APIs to find the longest chain of entries it can hang off a previous vote. If that chain of entries does not hang off the latest vote, the replay stage rolls back the bank to that vote and replays the chain from there.
 
-## Pruning Blocktree
+## Pruning Blockstore
 
-Once Blocktree entries are old enough, representing all the possible forks becomes less useful, perhaps even problematic for replay upon restart. Once a validator's votes have reached max lockout, however, any Blocktree contents that are not on the PoH chain for that vote for can be pruned, expunged.
+Once Blockstore entries are old enough, representing all the possible forks becomes less useful, perhaps even problematic for replay upon restart. Once a validator's votes have reached max lockout, however, any Blockstore contents that are not on the PoH chain for that vote for can be pruned, expunged.
 
 Archiver nodes will be responsible for storing really old ledger contents, and validators need only persist their bank periodically.