solana-docs 0.0.0

package/src/terminology.md

@@ -0,0 +1,346 @@
+---
+title: Terminology
+---
+
+The following terms are used throughout the documentation.
+
+## account
+
+A record in the Solana ledger that either holds data or is an executable program.
+
+Like an account at a traditional bank, a Solana account may hold funds called [lamports](#lamport). Like a file in Linux, it is addressable by a key, often referred to as a [public key](#public-key-pubkey) or pubkey.
+
+The key may be one of:
+
+* an ed25519 public key
+* a program-derived account address (32byte value forced off the ed25519 curve)
+* a hash of an ed25519 public key with a 32 character string
+
+## account owner
+
+The address of the program that owns the account. Only the owning program is capable of modifying the account.
+
+## app
+
+A front-end application that interacts with a Solana cluster.
+
+## bank state
+
+The result of interpreting all programs on the ledger at a given [tick height](#tick-height). It includes at least the set of all [accounts](#account) holding nonzero [native tokens](#native-token).
+
+## block
+
+A contiguous set of [entries](#entry) on the ledger covered by a [vote](#ledger-vote). A [leader](#leader) produces at most one block per [slot](#slot).
+
+## blockhash
+
+A unique value ([hash](#hash)) that identifies a record (block).  Solana computes a blockhash from the last [entry id](#entry-id) of the block.
+
+## block height
+
+The number of [blocks](#block) beneath the current block. The first block after the [genesis block](#genesis-block) has height one.
+
+## bootstrap validator
+
+The [validator](#validator) that produces the genesis (first) [block](#block) of a block chain.
+
+## BPF loader
+
+The Solana program that owns and loads [BPF](developing/on-chain-programs/overview#berkeley-packet-filter-bpf) smart contract programs, allowing the program to interface with the runtime.
+
+## client
+
+A computer program that accesses the Solana server network [cluster](#cluster).
+
+## cluster
+
+A set of [validators](#validator) maintaining a single [ledger](#ledger).
+
+## confirmation time
+
+The wallclock duration between a [leader](#leader) creating a [tick entry](#tick) and creating a [confirmed block](#confirmed-block).
+
+## confirmed block
+
+A [block](#block) that has received a [supermajority](#supermajority) of [ledger votes](#ledger-vote).
+
+## control plane
+
+A gossip network connecting all [nodes](#node) of a [cluster](#cluster).
+
+## cooldown period
+
+Some number of [epochs](#epoch) after [stake](#stake) has been deactivated while it progressively becomes available for withdrawal. During this period, the stake is considered to be "deactivating". More info about: [warmup and cooldown](implemented-proposals/staking-rewards.md#stake-warmup-cooldown-withdrawal)
+
+## credit
+
+See [vote credit](#vote-credit).
+
+## cross-program invocation (CPI)
+
+A call from one smart contract program to another. For more information, see [calling between programs](developing/programming-model/calling-between-programs.md).
+
+## data plane
+
+A multicast network used to efficiently validate [entries](#entry) and gain consensus.
+
+## drone
+
+An off-chain service that acts as a custodian for a user's private key. It typically serves to validate and sign transactions.
+
+## entry
+
+An entry on the [ledger](#ledger) either a [tick](#tick) or a [transactions entry](#transactions-entry).
+
+## entry id
+
+A preimage resistant [hash](#hash) over the final contents of an entry, which acts as the [entry's](#entry) globally unique identifier. The hash serves as evidence of:
+
+- The entry being generated after a duration of time
+- The specified [transactions](#transaction) are those included in the entry
+- The entry's position with respect to other entries in [ledger](#ledger)
+
+See [proof of history](#proof-of-history-poh).
+
+## epoch
+
+The time, i.e. number of [slots](#slot), for which a [leader schedule](#leader-schedule) is valid.
+
+## fee account
+
+The fee account in the transaction is the account that pays for the cost of including the transaction in the ledger. This is the first account in the transaction. This account must be declared as Read-Write (writable) in the transaction since paying for the transaction reduces the account balance.
+
+## finality
+
+When nodes representing 2/3rd of the [stake](#stake) have a common [root](#root).
+
+## fork
+
+A [ledger](#ledger) derived from common entries but then diverged.
+
+## genesis block
+
+The first [block](#block) in the chain.
+
+## genesis config
+
+The configuration file that prepares the [ledger](#ledger) for the [genesis block](#genesis-block).
+
+## hash
+
+A digital fingerprint of a sequence of bytes.
+
+## inflation
+
+An increase in token supply over time used to fund rewards for validation and to fund continued development of Solana.
+
+## inner instruction
+
+See [cross-program invocation](#cross-program-invocation-cpi).
+
+## instruction
+
+The smallest contiguous unit of execution logic in a [program](#program). An instruction specifies which program it is calling, which accounts it wants to read or modify, and additional data that serves as auxiliary input to the program. A [client](#client) can include one or multiple instructions in a [transaction](#transaction). An instruction may contain one or more [cross-program invocations](#cross-program-invocation-cpi).
+
+## keypair
+
+A [public key](#public-key-pubkey) and corresponding [private key](#private-key) for accessing an account.
+
+## lamport
+
+A fractional [native token](#native-token) with the value of 0.000000001 [sol](#sol).
+
+## leader
+
+The role of a [validator](#validator) when it is appending [entries](#entry) to the [ledger](#ledger).
+
+## leader schedule
+
+A sequence of [validator](#validator) [public keys](#public-key-pubkey) mapped to [slots](#slot). The cluster uses the leader schedule to determine which validator is the [leader](#leader) at any moment in time.
+
+## ledger
+
+A list of [entries](#entry) containing [transactions](#transaction) signed by [clients](#client).
+Conceptually, this can be traced back to the [genesis block](#genesis-block), but an actual [validator](#validator)'s ledger may have only newer [blocks](#block) to reduce storage, as older ones are not needed for validation of future blocks by design.
+
+## ledger vote
+
+A [hash](#hash) of the [validator's state](#bank-state) at a given [tick height](#tick-height). It comprises a [validator's](#validator) affirmation that a [block](#block) it has received has been verified, as well as a promise not to vote for a conflicting [block](#block) \(i.e. [fork](#fork)\) for a specific amount of time, the [lockout](#lockout) period.
+
+## light client
+
+A type of [client](#client) that can verify it's pointing to a valid [cluster](#cluster). It performs more ledger verification than a [thin client](#thin-client) and less than a [validator](#validator).
+
+## loader
+
+A [program](#program) with the ability to interpret the binary encoding of other on-chain programs.
+
+## lockout
+
+The duration of time for which a [validator](#validator) is unable to [vote](#ledger-vote) on another [fork](#fork).
+
+## native token
+
+The [token](#token) used to track work done by [nodes](#node) in a cluster.
+
+## node
+
+A computer participating in a [cluster](#cluster).
+
+## node count
+
+The number of [validators](#validator) participating in a [cluster](#cluster).
+
+## PoH
+
+See [Proof of History](#proof-of-history-poh).
+
+## point
+
+A weighted [credit](#credit) in a rewards regime. In the [validator](#validator) [rewards regime](cluster/stake-delegation-and-rewards.md), the number of points owed to a [stake](#stake) during redemption is the product of the [vote credits](#vote-credit) earned and the number of lamports staked.
+
+## private key
+
+The private key of a [keypair](#keypair).
+
+## program
+
+The code that interprets [instructions](#instruction).
+
+## program derived account (PDA)
+
+An account whose owner is a program and thus is not controlled by a private key like other accounts.
+
+## program id
+
+The public key of the [account](#account) containing a [program](#program).
+
+## proof of history (PoH)
+
+A stack of proofs, each which proves that some data existed before the proof was created and that a precise duration of time passed before the previous proof. Like a [VDF](#verifiable-delay-function-vdf), a Proof of History can be verified in less time than it took to produce.
+
+## public key (pubkey)
+
+The public key of a [keypair](#keypair).
+
+## root
+
+A [block](#block) or [slot](#slot) that has reached maximum [lockout](#lockout) on a [validator](#validator). The root is the highest block that is an ancestor of all active forks on a validator. All ancestor blocks of a root are also transitively a root. Blocks that are not an ancestor and not a descendant of the root are excluded from consideration for consensus and can be discarded.
+
+## runtime
+
+The component of a [validator](#validator) responsible for [program](#program) execution.
+
+## Sealevel
+
+Solana's parallel smart contracts run-time.
+
+## shred
+
+A fraction of a [block](#block); the smallest unit sent between [validators](#validator).
+
+## signature
+
+A 64-byte ed25519 signature of R (32-bytes) and S (32-bytes). With the requirement that R is a packed Edwards point not of small order and S is a scalar in the range of 0 <= S < L.
+This requirement ensures no signature malleability. Each transaction must have at least one signature for [fee account](terminology#fee-account).
+Thus, the first signature in transaction can be treated as [transacton id](#transaction-id)
+
+## skipped slot
+
+A past [slot](#slot) that did not produce a [block](#block), because the leader was offline or the [fork](#fork) containing the slot was abandoned for a better alternative by cluster consensus. A skipped slot will not appear as an ancestor for blocks at subsequent slots, nor increment the [block height](terminology#block-height), nor expire the oldest `recent_blockhash`.
+
+Whether a slot has been skipped can only be determined when it becomes older than the latest [rooted](#root) (thus not-skipped) slot.
+
+## slot
+
+The period of time for which each [leader](#leader) ingests transactions and produces a [block](#block).
+
+Collectively, slots create a logical clock. Slots are ordered sequentially and non-overlapping, comprising roughly equal real-world time as per [PoH](#proof-of-history-poh).
+
+## smart contract
+
+A program on a blockchain that can read and modify accounts over which it has control.
+
+## sol
+
+The [native token](#native-token) of a Solana [cluster](#cluster).
+
+## Solana Program Library (SPL)
+
+A library of programs on Solana such as spl-token that facilitates tasks such as creating and using tokens
+
+## stake
+
+Tokens forfeit to the [cluster](#cluster) if malicious [validator](#validator) behavior can be proven.
+
+## supermajority
+
+2/3 of a [cluster](#cluster).
+
+## sysvar
+
+A system [account](#account).  [Sysvars](developing/runtime-facilities/sysvars.md) provide cluster state information such as current tick height, rewards [points](#point) values, etc.  Programs can access Sysvars via a Sysvar account (pubkey) or by querying via a syscall.
+
+## thin client
+
+A type of [client](#client) that trusts it is communicating with a valid [cluster](#cluster).
+
+## tick
+
+A ledger [entry](#entry) that estimates wallclock duration.
+
+## tick height
+
+The Nth [tick](#tick) in the [ledger](#ledger).
+
+## token
+
+A digitally transferable asset.
+
+## tps
+
+[Transactions](#transaction) per second.
+
+## transaction
+
+One or more [instructions](#instruction) signed by a [client](#client) using one or more [keypairs](#keypair) and executed atomically with only two possible outcomes: success or failure.
+
+## transaction id
+
+The first [signature](#signature) in a [transaction](#transaction), which can be used to uniquely identify the transaction across the complete [ledger](#ledger).
+
+## transaction confirmations
+
+The number of [confirmed blocks](#confirmed-block) since the transaction was accepted onto the [ledger](#ledger). A transaction is finalized when its block becomes a [root](#root).
+
+## transactions entry
+
+A set of [transactions](#transaction) that may be executed in parallel.
+
+## validator
+
+A full participant in a Solana network [cluster](#cluster) that produces new [blocks](#block).  A validator validates the transactions added to the [ledger](#ledger)
+
+## VDF
+
+See [verifiable delay function](#verifiable-delay-function-vdf).
+
+## verifiable delay function (VDF)
+
+A function that takes a fixed amount of time to execute that produces a proof that it ran, which can then be verified in less time than it took to produce.
+
+## vote
+
+See [ledger vote](#ledger-vote).
+
+## vote credit
+
+A reward tally for [validators](#validator). A vote credit is awarded to a validator in its vote account when the validator reaches a [root](#root).
+
+## wallet
+
+A collection of [keypairs](#keypair) that allows users to manage their funds.
+
+## warmup period
+
+Some number of [epochs](#epoch) after [stake](#stake) has been delegated while it progressively becomes effective. During this period, the stake is considered to be "activating". More info about: [warmup and cooldown](cluster/stake-delegation-and-rewards.md#stake-warmup-cooldown-withdrawal)

package/src/theme/Footer/index.js

@@ -0,0 +1,126 @@
+/**
+ * Copyright (c) Facebook, Inc. and its affiliates.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+import React from "react";
+import clsx from "clsx";
+
+import Link from "@docusaurus/Link";
+import useDocusaurusContext from "@docusaurus/useDocusaurusContext";
+import useBaseUrl from "@docusaurus/useBaseUrl";
+import styles from "./styles.module.css";
+
+function FooterLink({ to, href, label, prependBaseUrlToHref, ...props }) {
+  const toUrl = useBaseUrl(to);
+  const normalizedHref = useBaseUrl(href, { forcePrependBaseUrl: true });
+
+  return (
+    <Link
+      className="footer__link-item"
+      {...(href
+        ? {
+            target: "_blank",
+            rel: "noopener noreferrer",
+            href: prependBaseUrlToHref ? normalizedHref : href,
+          }
+        : {
+            to: toUrl,
+          })}
+      {...props}
+    >
+      {label}
+    </Link>
+  );
+}
+
+const FooterLogo = ({ url, alt }) => (
+  <img className="footer__logo" alt={alt} src={url} />
+);
+
+function Footer() {
+  const context = useDocusaurusContext();
+  const { siteConfig = {} } = context;
+  const { themeConfig = {} } = siteConfig;
+  const { footer } = themeConfig;
+
+  const { copyright, links = [], logo = {} } = footer || {};
+  const logoUrl = useBaseUrl(logo.src);
+
+  if (!footer) {
+    return null;
+  }
+
+  return (
+    <footer
+      className={clsx("footer", {
+        "footer--dark": footer.style === "dark",
+      })}
+    >
+      <div className="container">
+        {links && links.length > 0 && (
+          <div className="row footer__links">
+            {links.map((linkItem, i) => (
+              <div key={i} className="col footer__col">
+                {linkItem.title != null ? (
+                  <h4 className="footer__title">{linkItem.title}</h4>
+                ) : null}
+                {linkItem.items != null &&
+                Array.isArray(linkItem.items) &&
+                linkItem.items.length > 0 ? (
+                  <ul className="footer__items">
+                    {linkItem.items.map((item, key) =>
+                      item.html ? (
+                        <li
+                          key={key}
+                          className="footer__item"
+                          dangerouslySetInnerHTML={{
+                            __html: item.html,
+                          }}
+                        />
+                      ) : (
+                        <li key={item.href || item.to} className="footer__item">
+                          <FooterLink {...item} />
+                        </li>
+                      )
+                    )}
+                  </ul>
+                ) : null}
+              </div>
+            ))}
+          </div>
+        )}
+        {(logo || copyright) && (
+          <div className="text--center">
+            {logo && logo.src && (
+              <div className="margin-bottom--sm">
+                {logo.href ? (
+                  <a
+                    href={logo.href}
+                    target="_blank"
+                    rel="noopener noreferrer"
+                    className={styles.footerLogoLink}
+                  >
+                    <FooterLogo alt={logo.alt} url={logoUrl} />
+                  </a>
+                ) : (
+                  <FooterLogo alt={logo.alt} url={logoUrl} />
+                )}
+              </div>
+            )}
+
+            <div
+              dangerouslySetInnerHTML={{
+                __html: copyright,
+              }}
+            />
+          </div>
+        )}
+      </div>
+    </footer>
+  );
+}
+
+export default Footer;

package/src/theme/Footer/styles.module.css

@@ -0,0 +1,15 @@
+/**
+ * Copyright (c) Facebook, Inc. and its affiliates.
+ *
+ * This source code is licensed under the MIT license found in the
+ * LICENSE file in the root directory of this source tree.
+ */
+
+.footerLogoLink {
+  opacity: 0.5;
+  transition: opacity 0.15s ease-in-out;
+}
+
+.footerLogoLink:hover {
+  opacity: 1;
+}

package/src/transaction_fees.md

@@ -0,0 +1,21 @@
+---
+title: Transaction Fees
+---
+
+**Subject to change.**
+
+Each transaction sent through the network, to be processed by the current leader validation-client and confirmed as a global state transaction, contains a transaction fee. Transaction fees offer many benefits in the Solana economic design, for example they:
+
+- provide unit compensation to the validator network for the CPU/GPU resources necessary to process the state transaction,
+- reduce network spam by introducing real cost to transactions,
+- and provide potential long-term economic stability of the network through a protocol-captured minimum fee amount per transaction, as described below.
+
+Network consensus votes are sent as normal system transfers, which means that validators pay transaction fees to participate in consensus.
+
+Many current blockchain economies \(e.g. Bitcoin, Ethereum\), rely on protocol-based rewards to support the economy in the short term, with the assumption that the revenue generated through transaction fees will support the economy in the long term, when the protocol derived rewards expire. In an attempt to create a sustainable economy through protocol-based rewards and transaction fees, a fixed portion (initially 50%) of each transaction fee is destroyed, with the remaining fee going to the current leader processing the transaction. A scheduled global inflation rate provides a source for rewards distributed to validation-clients, through the process described above.
+
+Transaction fees are set by the network cluster based on recent historical throughput, see [Congestion Driven Fees](implemented-proposals/transaction-fees.md#congestion-driven-fees). This minimum portion of each transaction fee can be dynamically adjusted depending on historical _signatures-per-slot_. In this way, the protocol can use the minimum fee to target a desired hardware utilization. By monitoring a protocol specified _signatures-per-slot_ with respect to a desired, target usage amount, the minimum fee can be raised/lowered which should, in turn, lower/raise the actual _signature-per-slot_ per block until it reaches the target amount. This adjustment process can be thought of as similar to the difficulty adjustment algorithm in the Bitcoin protocol, however in this case it is adjusting the minimum transaction fee to guide the transaction processing hardware usage to a desired level.
+
+As mentioned, a fixed-proportion of each transaction fee is to be destroyed. The intent of this design is to retain leader incentive to include as many transactions as possible within the leader-slot time, while providing an inflation limiting mechanism that protects against "tax evasion" attacks \(i.e. side-channel fee payments\).
+
+Additionally, the burnt fees can be a consideration in fork selection. In the case of a PoH fork with a malicious, censoring leader, we would expect the total fees destroyed to be less than a comparable honest fork, due to the fees lost from censoring. If the censoring leader is to compensate for these lost protocol fees, they would have to replace the burnt fees on their fork themselves, thus potentially reducing the incentive to censor in the first place.

package/src/validator/anatomy.md

@@ -0,0 +1,13 @@
+---
+title: Anatomy of a Validator
+---
+
+![Validator block diagrams](/img/validator.svg)
+
+## Pipelining
+
+The validators make extensive use of an optimization common in CPU design, called _pipelining_. Pipelining is the right tool for the job when there's a stream of input data that needs to be processed by a sequence of steps, and there's different hardware responsible for each. The quintessential example is using a washer and dryer to wash/dry/fold several loads of laundry. Washing must occur before drying and drying before folding, but each of the three operations is performed by a separate unit. To maximize efficiency, one creates a pipeline of _stages_. We'll call the washer one stage, the dryer another, and the folding process a third. To run the pipeline, one adds a second load of laundry to the washer just after the first load is added to the dryer. Likewise, the third load is added to the washer after the second is in the dryer and the first is being folded. In this way, one can make progress on three loads of laundry simultaneously. Given infinite loads, the pipeline will consistently complete a load at the rate of the slowest stage in the pipeline.
+
+## Pipelining in the Validator
+
+The validator contains two pipelined processes, one used in leader mode called the TPU and one used in validator mode called the TVU. In both cases, the hardware being pipelined is the same, the network input, the GPU cards, the CPU cores, writes to disk, and the network output. What it does with that hardware is different. The TPU exists to create ledger entries whereas the TVU exists to validate them.

package/src/validator/blockstore.md

@@ -0,0 +1,91 @@
+---
+title: 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 _blockstore_ data structure described here is how a validator copes with those forks until blocks are finalized.
+
+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 Blockstore.
+
+## Functionalities of Blockstore
+
+1. Persistence: the Blockstore lives in the front of the nodes verification
+
+   pipeline, right behind network receive and signature verification. If the
+
+   shred received is consistent with the leader schedule \(i.e. was signed by the
+
+   leader for the indicated slot\), it is immediately stored.
+
+2. Repair: repair is the same as window repair above, but able to serve any
+
+   shred that's been received. Blockstore stores shreds with signatures,
+
+   preserving the chain of origination.
+
+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 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 Blockstore.
+
+## Blockstore Design
+
+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\).
+   - `received` - The highest received shred index for the slot
+   - `next_slots` - A list of future slots this slot could chain to. Used when rebuilding
+
+     the ledger to find possible fork points.
+
+   - `last_index` - The index of the shred that is flagged as the last shred for this slot. This flag on a shred will be set by the leader for a slot when they are transmitting the last shred for a slot.
+   - `is_connected` - True iff every block from 0...slot forms a full sequence without any holes. We can derive is_connected for each slot with the following rules. Let slot\(n\) be the slot with index `n`, and slot\(n\).is_full\(\) is true if the slot with index `n` has all the ticks expected for that slot. Let is_connected\(n\) be the statement that "the slot\(n\).is_connected is true". Then:
+
+     is_connected\(0\) is_connected\(n+1\) iff \(is_connected\(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 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_connected is flipped from false to true for any `n`.
+
+## Blockstore APIs
+
+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 Blockstore.
+
+## Interfacing with Bank
+
+The bank exposes to replay stage:
+
+1. `prev_hash`: which PoH chain it's working on as indicated by the hash of the last
+
+   entry it processed
+
+2. `tick_height`: the ticks in the PoH chain currently being verified by this
+
+   bank
+
+3. `votes`: a stack of records that contain: 1. `prev_hashes`: what anything after this vote must chain to in PoH 2. `tick_height`: the tick height at which this vote was cast 3. `lockout period`: how long a chain must be observed to be in the ledger to
+
+   be able to be chained below this vote
+
+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 Blockstore
+
+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.