Additional tests for should_retransmit_and_persist (#6062) (#6070)

automerge

.appveyor.yml

@@ -1,22 +1,23 @@
-os: Visual Studio 2017
 version: '{build}'
 
 branches:
   only:
   - master
-  - /^v[0-9.]+/
+  - /^v[0-9.]+\.[0-9.]+/
 
 cache:
   - '%USERPROFILE%\.cargo'
   - '%APPVEYOR_BUILD_FOLDER%\target'
 
+clone_folder: d:\projects\solana
+
 build_script:
   - bash ci/publish-tarball.sh
 
 notifications:
   - provider: Slack
     incoming_webhook:
-      secure: 6HnLbeS6/Iv7JSMrrHQ7V9OSIjH/3KFzvZiinNWgQqEN0e9A6zaE4MwEXUYDWbcvVJiQneWit6dswY8Scoms2rS1PWEN5N6sjgLgyzroptc=
+      secure: GJsBey+F5apAtUm86MHVJ68Uqa6WN1SImcuIc4TsTZrDhA8K1QWUNw9FFQPybUWDyOcS5dly3kubnUqlGt9ux6Ad2efsfRIQYWv0tOVXKeY=
     channel: ci-status
     on_build_success: false
     on_build_failure: true
@@ -25,16 +26,16 @@ notifications:
 deploy:
   - provider: S3
     access_key_id:
-      secure: G6uzyGqbkMCXS2+sCeBCT/+s/11AHLWXCuGayfKcMEE=
+      secure: fTbJl6JpFebR40J7cOWZ2mXBa3kIvEiXgzxAj6L3N7A=
     secret_access_key:
-      secure: Lc+aVrbcPSXoDV7h2J7gqKT+HX0n3eEzp3JIrSP2pcKxbAikGnCtOogCiHO9/er2
+      secure: vItsBXb2rEFLvkWtVn/Rcxu5a5+2EwC+b7GsA0waJy9hXh6XuBAD0lnHd9re3g/4
     bucket: release.solana.com
     region: us-west-1
     set_public: true
 
   - provider: GitHub
     auth_token:
-      secure: JdggY+mrznklWDcV0yvetHhD9eRcNdc627q6NcZdZAJsDidYcGgZ/tgYJiXb9D1A
+      secure: 81fEmPZ0cV1wLtNuUrcmtgxKF6ROQF1+/ft5m+fHX21z6PoeCbaNo8cTyLioWBj7
     draft: false
     prerelease: false
     on:

.buildkite/pipeline-upload.sh

@@ -10,11 +10,22 @@
 set -e
 cd "$(dirname "$0")"/..
 
-buildkite-agent pipeline upload ci/buildkite.yml
+if [[ -n $BUILDKITE_TAG ]]; then
+  buildkite-agent annotate --style info --context release-tag \
+    "https://github.com/solana-labs/solana/releases/$BUILDKITE_TAG"
+  buildkite-agent pipeline upload ci/buildkite-release.yml
+else
+  if [[ $BUILDKITE_BRANCH =~ ^pull ]]; then
+    # Add helpful link back to the corresponding Github Pull Request
+    buildkite-agent annotate --style info --context pr-backlink \
+      "Github Pull Request: https://github.com/solana-labs/solana/$BUILDKITE_BRANCH"
+  fi
 
-if [[ $BUILDKITE_BRANCH =~ ^pull ]]; then
-  # Add helpful link back to the corresponding Github Pull Request
-  buildkite-agent annotate --style info --context pr-backlink \
-    "Github Pull Request: https://github.com/solana-labs/solana/$BUILDKITE_BRANCH"
+  if [[ $BUILDKITE_MESSAGE =~ GitBook: ]]; then
+    buildkite-agent annotate --style info --context gitbook-ci-skip \
+      "GitBook commit detected, CI skipped"
+    exit
+  fi
+
+  buildkite-agent pipeline upload ci/buildkite.yml
 fi
-

.gitbook.yaml

@@ -0,0 +1,5 @@
+root: ./book/src
+
+structure:
+    readme: introduction.md
+    summary: SUMMARY.md

.github/stale.yml

@@ -0,0 +1,24 @@
+only: pulls
+
+# Number of days of inactivity before a pull request becomes stale
+daysUntilStale: 30
+
+# Number of days of inactivity before a stale pull request is closed
+daysUntilClose: 7
+
+# Issues with these labels will never be considered stale
+exemptLabels:
+  - security
+
+# Label to use when marking a pull request as stale
+staleLabel: stale
+
+# Comment to post when marking a pull request as stale. Set to `false` to disable
+markComment: >
+  This pull request has been automatically marked as stale because it has not had
+  recent activity. It will be closed if no further activity occurs.
+
+# Comment to post when closing a stale pull request. Set to `false` to disable
+closeComment: >
+  This stale pull request has been automatically closed.
+  Thank you for your contributions.

.gitignore

@@ -1,5 +1,4 @@
 /book/html/
-/book/src/img/
 /book/src/tests.ok
 /farf/
 /solana-release/
@@ -11,10 +10,7 @@
 **/*.rs.bk
 .cargo
 
-# node config that is rsynced
 /config/
-# node config that remains local
-/config-local/
 
 # log files
 *.log

.mergify.yml

@@ -43,3 +43,35 @@ pull_request_rules:
       backport:
         branches:
           - v0.18
+  - name: v0.19 backport
+    conditions:
+      - base=master
+      - label=v0.19
+    actions:
+      backport:
+        branches:
+          - v0.19
+  - name: v0.20 backport
+    conditions:
+      - base=master
+      - label=v0.20
+    actions:
+      backport:
+        branches:
+          - v0.20
+  - name: v0.21 backport
+    conditions:
+      - base=master
+      - label=v0.21
+    actions:
+      backport:
+        branches:
+          - v0.21
+  - name: v0.22 backport
+    conditions:
+      - base=master
+      - label=v0.22
+    actions:
+      backport:
+        branches:
+          - v0.22

.travis.yml

@@ -2,9 +2,8 @@ os:
   - osx
 
 language: rust
-cache: cargo
 rust:
-  - 1.36.0
+  - 1.37.0
 
 install:
   - source ci/rust-version.sh
@@ -17,7 +16,7 @@ script:
 branches:
   only:
     - master
-    - /^v\d+\.\d+(\.\d+)?(-\S*)?$/
+    - /^v\d+\.\d+$/
 
 notifications:
   slack:

CONTRIBUTING.md

@@ -103,7 +103,7 @@ Solana's architecture is described by a book generated from markdown files in
 the `book/src/` directory, maintained by an *editor* (currently @garious). To
 add a design proposal, you'll need to at least propose a change the content
 under the [Accepted Design
-Proposals](https://solana-labs.github.io/book-edge/proposals.html) chapter.
+Proposals](https://docs.solana.com/book/v/master/proposals) chapter.
 Here's the full process:
 
 1. Propose a design by creating a PR that adds a markdown document to the

Cargo.toml

@@ -1,37 +1,43 @@
 [workspace]
-members = [
+# The members list excluding the `validator-cuda` crate
+default-members = [
     "bench-exchange",
     "bench-streamer",
     "bench-tps",
-    "sdk-c",
+    "banking_bench",
     "chacha-sys",
     "client",
     "core",
     "drone",
     "validator",
     "genesis",
+    "genesis_programs",
     "gossip",
     "install",
     "keygen",
     "kvstore",
     "ledger-tool",
+    "local_cluster",
     "logger",
     "merkle-tree",
     "measure",
     "metrics",
-    "netutil",
-    "programs/bpf",
     "programs/bpf_loader_api",
     "programs/bpf_loader_program",
     "programs/budget_api",
     "programs/budget_program",
+    "programs/btc_spv_program",
+    "programs/btc_spv_api",
+    "programs/btc_spv_bin",
     "programs/config_api",
     "programs/config_program",
+    "programs/config_tests",
     "programs/exchange_api",
     "programs/exchange_program",
     "programs/failure_program",
     "programs/move_loader_api",
     "programs/move_loader_program",
+    "programs/librapay_api",
     "programs/noop_program",
     "programs/stake_api",
     "programs/stake_program",
@@ -45,12 +51,77 @@ members = [
     "replicator",
     "runtime",
     "sdk",
+    "sdk-c",
     "upload-perf",
-    "validator-info",
+    "netutil",
+    "fixed-buf",
     "vote-signer",
-    "wallet",
+    "cli",
+    "rayon-threadlimit",
+]
+
+# The default-members list and the `validator-cuda` crate
+members = [
+    "bench-exchange",
+    "bench-streamer",
+    "bench-tps",
+    "banking_bench",
+    "chacha-sys",
+    "client",
+    "core",
+    "drone",
+    "validator",
+    "genesis",
+    "genesis_programs",
+    "gossip",
+    "install",
+    "keygen",
+    "kvstore",
+    "ledger-tool",
+    "local_cluster",
+    "logger",
+    "merkle-tree",
+    "measure",
+    "metrics",
+    "programs/bpf_loader_api",
+    "programs/bpf_loader_program",
+    "programs/budget_api",
+    "programs/budget_program",
+    "programs/btc_spv_program",
+    "programs/btc_spv_api",
+    "programs/btc_spv_bin",
+    "programs/config_api",
+    "programs/config_program",
+    "programs/config_tests",
+    "programs/exchange_api",
+    "programs/exchange_program",
+    "programs/failure_program",
+    "programs/move_loader_api",
+    "programs/move_loader_program",
+    "programs/librapay_api",
+    "programs/noop_program",
+    "programs/stake_api",
+    "programs/stake_program",
+    "programs/stake_tests",
+    "programs/storage_api",
+    "programs/storage_program",
+    "programs/token_api",
+    "programs/token_program",
+    "programs/vote_api",
+    "programs/vote_program",
+    "replicator",
+    "runtime",
+    "sdk",
+    "sdk-c",
+    "upload-perf",
+    "netutil",
+    "fixed-buf",
+    "vote-signer",
+    "cli",
+    "rayon-threadlimit",
+    "validator-cuda",
 ]
 
 exclude = [
-    "programs/bpf/rust/noop",
+    "programs/bpf",
 ]

README.md

@@ -1,5 +1,5 @@
-[![Solana crate](https://img.shields.io/crates/v/solana.svg)](https://crates.io/crates/solana)
-[![Solana documentation](https://docs.rs/solana/badge.svg)](https://docs.rs/solana)
+[![Solana crate](https://img.shields.io/crates/v/solana-core.svg)](https://crates.io/crates/solana-core)
+[![Solana documentation](https://docs.rs/solana-core/badge.svg)](https://docs.rs/solana-core)
 [![Build status](https://badge.buildkite.com/8cc350de251d61483db98bdfc895b9ea0ac8ffa4a32ee850ed.svg?branch=master)](https://buildkite.com/solana-labs/solana/builds?branch=master)
 [![codecov](https://codecov.io/gh/solana-labs/solana/branch/master/graph/badge.svg)](https://codecov.io/gh/solana-labs/solana)
 
@@ -26,9 +26,9 @@ Furthermore, and much to our surprise, it can be implemented using a mechanism t
 Architecture
 ===
 
-Before you jump into the code, review the online book [Solana: Blockchain Rebuilt for Scale](https://solana-labs.github.io/book/).
+Before you jump into the code, review the online book [Solana: Blockchain Rebuilt for Scale](https://docs.solana.com/book/).
 
-(The _latest_ development version of the online book is also [available here](https://solana-labs.github.io/book-edge/).)
+(The _latest_ development version of the online book is also [available here](https://docs.solana.com/book/v/master/).)
 
 Release Binaries
 ===
@@ -78,7 +78,7 @@ $ source $HOME/.cargo/env
 $ rustup component add rustfmt
 ```
 
-If your rustc version is lower than 1.34.0, please update it:
+If your rustc version is lower than 1.37.0, please update it:
 
 ```bash
 $ rustup update
@@ -120,7 +120,7 @@ $ cargo test
 Local Testnet
 ---
 
-Start your own testnet locally, instructions are in the book [Solana: Blockchain Rebuild for Scale: Getting Started](https://solana-labs.github.io/book/getting-started.html).
+Start your own testnet locally, instructions are in the book [Solana: Blockchain Rebuild for Scale: Getting Started](https://docs.solana.com/book/getting-started).
 
 Remote Testnets
 ---
@@ -240,5 +240,3 @@ problem is solved by this code?" On the other hand, if a test does fail and you
 better way to solve the same problem, a Pull Request with your solution would most certainly be
 welcome! Likewise, if rewriting a test can better communicate what code it's protecting, please
 send us that patch!
-
-

RELEASE.md

@@ -59,60 +59,88 @@ There are three release channels that map to branches as follows:
 * beta - tracks the largest (and latest) `vX.Y` stabilization branch, more stable.
 * stable - tracks the second largest `vX.Y` stabilization branch, most stable.
 
-## Release Steps
+## Steps to Create a Branch
 
-### Creating a new branch from master
-
-#### Create the new branch
-1. Pick your branch point for release on master.
-1. Create the branch.  The name should be "v" + the first 2 "version" fields
+### Create the new branch
+1. Check out the latest commit on `master` branch:
+    ```
+    git fetch --all
+    git checkout upstream/master
+    ```
+1. Determine the new branch name.  The name should be "v" + the first 2 version fields
    from Cargo.toml.  For example, a Cargo.toml with version = "0.9.0" implies
    the next branch name is "v0.9".
-    1.  Note the Cargo.toml in the repo root directory does not contain a version.  Look at any other Cargo.toml file.
-1. Create a new branch and push this branch to the solana repository.
-    1. `git checkout -b <branchname>`
-    1. `git push -u origin <branchname>`
+1. Create the new branch and push this branch to the `solana` repository:
+    ```
+    git checkout -b <branchname>
+    git push -u origin <branchname>
+    ```
 
-#### Update master with the next version
+### Update master branch with the next version
 
-1. After the new branch has been created and pushed, update Cargo.toml on **master** to the next semantic version (e.g. 0.9.0 -> 0.10.0)
-   by running `./scripts/increment-cargo-version.sh`, then rebuild with
-   `cargo build` to cause a refresh of `Cargo.lock`.
-1. Push your Cargo.toml change and the autogenerated Cargo.lock changes to the
-   master branch
+1. After the new branch has been created and pushed, update the Cargo.toml files on **master** to the next semantic version (e.g. 0.9.0 -> 0.10.0) with:
+     ```
+     scripts/increment-cargo-version.sh minor
+     ```
+1. Rebuild to get an updated version of `Cargo.lock`:
+    ```
+    cargo build
+    ```
+1. Push all the changed Cargo.toml and Cargo.lock files to the `master` branch with something like:
+    ```
+    git co -b version_update
+    git ls-files -m | xargs git add
+    git commit -m 'Update Cargo.toml versions from X.Y to X.Y+1'
+    git push -u origin version_update
+    ```
+1. Confirm that your freshly cut release branch is shown as `BETA_CHANNEL` and the previous release branch as `STABLE_CHANNEL`:
+    ```
+    ci/channel_info.sh
+    ```
 
-At this point, `ci/channel-info.sh` should show your freshly cut release branch as
-"BETA_CHANNEL" and the previous release branch as "STABLE_CHANNEL".
+## Steps to Create a Release
+
+### Create the Release Tag on GitHub
+
+1. Go to [GitHub's Releases UI](https://github.com/solana-labs/solana/releases) for tagging a release.
+1. Click "Draft new release".  The release tag must exactly match the `version`
+   field in `/Cargo.toml` prefixed by `v`.
+   1.  If the Cargo.toml verion field is **0.12.3**, then the release tag must be **v0.12.3**
+1. Make sure the Target Branch field matches the branch you want to make a release on.
+   1.  If you want to release v0.12.0, the target branch must be v0.12
+1. If this is the first release on the branch (e.g. v0.13.**0**), paste in [this
+   template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md).  Engineering Lead can provide summary contents for release notes if needed.
+1. Click "Save Draft", then confirm the release notes look good and the tag name and branch are correct.  Go back into edit the release and click "Publish release" when ready.
+
+### Update release branch with the next patch version
+
+1. After the new release has been tagged, update the Cargo.toml files on **release branch** to the next semantic version (e.g. 0.9.0 -> 0.9.1) with:
+     ```
+     scripts/increment-cargo-version.sh patch
+     ```
+1. Rebuild to get an updated version of `Cargo.lock`:
+    ```
+    cargo build
+    ```
+1. Push all the changed Cargo.toml and Cargo.lock files to the **release branch** with something like:
+    ```
+    git co -b version_update
+    git ls-files -m | xargs git add
+    git commit -m 'Update Cargo.toml versions from X.Y.Z to X.Y.Z+1'
+    git push -u origin version_update
+    ```
+
+### Verify release automation success
+1. Go to [Solana Releases](https://github.com/solana-labs/solana/releases) and click on the latest release that you just published.  Verify that all of the build artifacts are present.  This can take up to 90 minutes after creating the tag.
+1. The `solana-secondary` Buildkite pipeline handles creating the binary tarballs and updated crates.  Look for a job under the tag name of the release: https://buildkite.com/solana-labs/solana-secondary
+1. [Crates.io](https://crates.io/crates/solana) should have an updated Solana version.
 
 ### Update documentation
+TODO: Documentation update procedure is WIP as we move to gitbook
 
-Document the new recommended version by updating
-```export SOLANA_RELEASE=[new scheduled TESTNET_TAG value]```
-in book/src/testnet-participation.md on the release (beta) branch.
+Document the new recommended version by updating `book/src/running-replicator.md` and `book/src/validator-testnet.md` on the release (beta) branch to point at the `solana-install` for the upcoming release version.
 
-### Make the Release
-
-We use [github's Releases UI](https://github.com/solana-labs/solana/releases) for tagging a release.
-
-1. Go [there ;)](https://github.com/solana-labs/solana/releases).
-1. Click "Draft new release".  The release tag must exactly match the `version`
-   field in `/Cargo.toml` prefixed by `v` (ie, `<branchname>.X`).
-   1.  If the Cargo.toml verion field is **0.12.3**, then the release tag must be **v0.12.3**
-1. If this is the first release on the branch (e.g. v0.13.**0**), paste in [this
-   template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md)
-   and fill it in.
-1. Test the release by generating a tag using semver's rules.  First try at a
-   release should be `<branchname>.X-rc.0`.
-1. Verify release automation:
-   1. [Crates.io](https://crates.io/crates/solana) should have an updated Solana version.
-1. Once the release has been made, update Cargo.toml on the release branch to the next
-   semantic version (e.g. 0.9.0 -> 0.9.1) by running
-   `./scripts/increment-cargo-version.sh patch`, then rebuild with `cargo
-   build` to cause a refresh of `Cargo.lock`.
-1. Push your Cargo.toml change and the autogenerated Cargo.lock changes to the
-   release branch.
-
-### Publish updated Book
+#### Publish updated Book
 We maintain three copies of the "book" as official documentation:
 
 1) "Book" is the documentation for the latest official release.  This should get manually updated whenever a new release is made.  It is published here:

banking_bench/Cargo.toml

@@ -0,0 +1,19 @@
+[package]
+authors = ["Solana Maintainers <maintainers@solana.com>"]
+edition = "2018"
+name = "solana-banking-bench"
+version = "0.19.0-pre0"
+repository = "https://github.com/solana-labs/solana"
+license = "Apache-2.0"
+homepage = "https://solana.com/"
+
+[dependencies]
+log = "0.4.6"
+rayon = "1.2.0"
+solana-core = { path = "../core", version = "0.19.0-pre0" }
+solana-logger = { path = "../logger", version = "0.19.0-pre0" }
+solana-runtime = { path = "../runtime", version = "0.19.0-pre0" }
+solana-measure = { path = "../measure", version = "0.19.0-pre0" }
+solana-sdk = { path = "../sdk", version = "0.19.0-pre0" }
+rand = "0.6.5"
+crossbeam-channel = "0.3"

banking_bench/src/main.rs

@@ -0,0 +1,319 @@
+#[macro_use]
+extern crate solana_core;
+extern crate crossbeam_channel;
+
+use crossbeam_channel::unbounded;
+use log::*;
+use rand::{thread_rng, Rng};
+use rayon::prelude::*;
+use solana_core::bank_forks::BankForks;
+use solana_core::banking_stage::{create_test_recorder, BankingStage};
+use solana_core::blocktree::{get_tmp_ledger_path, Blocktree};
+use solana_core::cluster_info::ClusterInfo;
+use solana_core::cluster_info::Node;
+use solana_core::genesis_utils::{create_genesis_block, GenesisBlockInfo};
+use solana_core::packet::to_packets_chunked;
+use solana_core::poh_recorder::PohRecorder;
+use solana_core::poh_recorder::WorkingBankEntry;
+use solana_core::service::Service;
+use solana_measure::measure::Measure;
+use solana_runtime::bank::Bank;
+use solana_sdk::hash::Hash;
+use solana_sdk::pubkey::Pubkey;
+use solana_sdk::signature::Keypair;
+use solana_sdk::signature::Signature;
+use solana_sdk::system_transaction;
+use solana_sdk::timing::{duration_as_us, timestamp};
+use solana_sdk::transaction::Transaction;
+use std::iter;
+use std::sync::atomic::Ordering;
+use std::sync::mpsc::Receiver;
+use std::sync::{Arc, Mutex, RwLock};
+use std::thread::sleep;
+use std::time::{Duration, Instant};
+
+fn check_txs(
+    receiver: &Arc<Receiver<WorkingBankEntry>>,
+    ref_tx_count: usize,
+    poh_recorder: &Arc<Mutex<PohRecorder>>,
+) -> bool {
+    let mut total = 0;
+    let now = Instant::now();
+    let mut no_bank = false;
+    loop {
+        if let Ok((_bank, (entry, _tick_count))) = receiver.recv_timeout(Duration::from_millis(10))
+        {
+            total += entry.transactions.len();
+        }
+        if total >= ref_tx_count {
+            break;
+        }
+        if now.elapsed().as_secs() > 60 {
+            break;
+        }
+        if poh_recorder.lock().unwrap().bank().is_none() {
+            trace!("no bank");
+            no_bank = true;
+            break;
+        }
+    }
+    if !no_bank {
+        assert!(total >= ref_tx_count);
+    }
+    no_bank
+}
+
+fn make_accounts_txs(txes: usize, mint_keypair: &Keypair, hash: Hash) -> Vec<Transaction> {
+    let to_pubkey = Pubkey::new_rand();
+    let dummy = system_transaction::transfer(mint_keypair, &to_pubkey, 1, hash);
+    (0..txes)
+        .into_par_iter()
+        .map(|_| {
+            let mut new = dummy.clone();
+            let sig: Vec<u8> = (0..64).map(|_| thread_rng().gen()).collect();
+            new.message.account_keys[0] = Pubkey::new_rand();
+            new.message.account_keys[1] = Pubkey::new_rand();
+            new.signatures = vec![Signature::new(&sig[0..64])];
+            new
+        })
+        .collect()
+}
+
+struct Config {
+    packets_per_batch: usize,
+    chunk_len: usize,
+    num_threads: usize,
+}
+
+impl Config {
+    fn get_transactions_index(&self, chunk_index: usize) -> usize {
+        chunk_index * (self.chunk_len / self.num_threads) * self.packets_per_batch
+    }
+}
+
+fn bytes_as_usize(bytes: &[u8]) -> usize {
+    bytes[0] as usize | (bytes[1] as usize) << 8
+}
+
+fn main() {
+    solana_logger::setup();
+    let num_threads = BankingStage::num_threads() as usize;
+    //   a multiple of packet chunk duplicates to avoid races
+    const CHUNKS: usize = 8 * 2;
+    const PACKETS_PER_BATCH: usize = 192;
+    let txes = PACKETS_PER_BATCH * num_threads * CHUNKS;
+    let mint_total = 1_000_000_000_000;
+    let GenesisBlockInfo {
+        genesis_block,
+        mint_keypair,
+        ..
+    } = create_genesis_block(mint_total);
+
+    let (verified_sender, verified_receiver) = unbounded();
+    let (vote_sender, vote_receiver) = unbounded();
+    let bank0 = Bank::new(&genesis_block);
+    let mut bank_forks = BankForks::new(0, bank0);
+    let mut bank = bank_forks.working_bank();
+
+    info!("threads: {} txs: {}", num_threads, txes);
+
+    let mut transactions = make_accounts_txs(txes, &mint_keypair, genesis_block.hash());
+
+    // fund all the accounts
+    transactions.iter().for_each(|tx| {
+        let fund = system_transaction::transfer(
+            &mint_keypair,
+            &tx.message.account_keys[0],
+            mint_total / txes as u64,
+            genesis_block.hash(),
+        );
+        let x = bank.process_transaction(&fund);
+        x.unwrap();
+    });
+    //sanity check, make sure all the transactions can execute sequentially
+    transactions.iter().for_each(|tx| {
+        let res = bank.process_transaction(&tx);
+        assert!(res.is_ok(), "sanity test transactions");
+    });
+    bank.clear_signatures();
+    //sanity check, make sure all the transactions can execute in parallel
+    let res = bank.process_transactions(&transactions);
+    for r in res {
+        assert!(r.is_ok(), "sanity parallel execution");
+    }
+    bank.clear_signatures();
+    let mut verified: Vec<_> = to_packets_chunked(&transactions.clone(), PACKETS_PER_BATCH)
+        .into_iter()
+        .map(|x| {
+            let len = x.packets.len();
+            (x, iter::repeat(1).take(len).collect())
+        })
+        .collect();
+    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 (exit, poh_recorder, poh_service, signal_receiver) =
+            create_test_recorder(&bank, &blocktree);
+        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(
+            &cluster_info,
+            &poh_recorder,
+            verified_receiver,
+            vote_receiver,
+        );
+        poh_recorder.lock().unwrap().set_bank(&bank);
+
+        let chunk_len = verified.len() / CHUNKS;
+        let mut start = 0;
+
+        // This is so that the signal_receiver does not go out of scope after the closure.
+        // If it is dropped before poh_service, then poh_service will error when
+        // calling send() on the channel.
+        let signal_receiver = Arc::new(signal_receiver);
+        let signal_receiver2 = signal_receiver.clone();
+        let mut total = 0;
+        let mut tx_total = 0;
+        let mut txs_processed = 0;
+        let mut root = 1;
+        let collector = Pubkey::new_rand();
+        const ITERS: usize = 1_000;
+        let config = Config {
+            packets_per_batch: PACKETS_PER_BATCH,
+            chunk_len,
+            num_threads,
+        };
+        for _ in 0..ITERS {
+            let now = Instant::now();
+            let mut sent = 0;
+
+            for (i, v) in verified[start..start + chunk_len]
+                .chunks(chunk_len / num_threads)
+                .enumerate()
+            {
+                let mut byte = 0;
+                let index = config.get_transactions_index(start + i);
+                if index < transactions.len() {
+                    byte = bytes_as_usize(transactions[index].signatures[0].as_ref());
+                }
+                trace!(
+                    "sending... {}..{} {} v.len: {} sig: {} transactions.len: {} index: {}",
+                    start + i,
+                    start + chunk_len,
+                    timestamp(),
+                    v.len(),
+                    byte,
+                    transactions.len(),
+                    index,
+                );
+                for xv in v {
+                    sent += xv.0.packets.len();
+                }
+                verified_sender.send(v.to_vec()).unwrap();
+            }
+            let start_tx_index = config.get_transactions_index(start);
+            let end_tx_index = config.get_transactions_index(start + chunk_len);
+            for tx in &transactions[start_tx_index..end_tx_index] {
+                loop {
+                    if bank.get_signature_status(&tx.signatures[0]).is_some() {
+                        break;
+                    }
+                    if poh_recorder.lock().unwrap().bank().is_none() {
+                        break;
+                    }
+                    sleep(Duration::from_millis(5));
+                }
+            }
+            if check_txs(&signal_receiver2, txes / CHUNKS, &poh_recorder) {
+                debug!(
+                    "resetting bank {} tx count: {} txs_proc: {}",
+                    bank.slot(),
+                    bank.transaction_count(),
+                    txs_processed
+                );
+                assert!(txs_processed < bank.transaction_count());
+                txs_processed = bank.transaction_count();
+                tx_total += duration_as_us(&now.elapsed());
+
+                let mut poh_time = Measure::start("poh_time");
+                poh_recorder.lock().unwrap().reset(
+                    bank.last_blockhash(),
+                    bank.slot(),
+                    Some((bank.slot(), bank.slot() + 1)),
+                );
+                poh_time.stop();
+
+                let mut new_bank_time = Measure::start("new_bank");
+                let new_bank = Bank::new_from_parent(&bank, &collector, bank.slot() + 1);
+                new_bank_time.stop();
+
+                let mut insert_time = Measure::start("insert_time");
+                bank_forks.insert(new_bank);
+                bank = bank_forks.working_bank();
+                insert_time.stop();
+
+                poh_recorder.lock().unwrap().set_bank(&bank);
+                assert!(poh_recorder.lock().unwrap().bank().is_some());
+                if bank.slot() > 32 {
+                    bank_forks.set_root(root, &None);
+                    root += 1;
+                }
+                debug!(
+                    "new_bank_time: {}us insert_time: {}us poh_time: {}us",
+                    new_bank_time.as_us(),
+                    insert_time.as_us(),
+                    poh_time.as_us(),
+                );
+            } else {
+                tx_total += duration_as_us(&now.elapsed());
+            }
+
+            // This signature clear may not actually clear the signatures
+            // in this chunk, but since we rotate between CHUNKS then
+            // we should clear them by the time we come around again to re-use that chunk.
+            bank.clear_signatures();
+            total += duration_as_us(&now.elapsed());
+            debug!(
+                "time: {} us checked: {} sent: {}",
+                duration_as_us(&now.elapsed()),
+                txes / CHUNKS,
+                sent,
+            );
+
+            if bank.slot() > 0 && bank.slot() % 16 == 0 {
+                for tx in transactions.iter_mut() {
+                    tx.message.recent_blockhash = bank.last_blockhash();
+                    let sig: Vec<u8> = (0..64).map(|_| thread_rng().gen()).collect();
+                    tx.signatures[0] = Signature::new(&sig[0..64]);
+                }
+                verified = to_packets_chunked(&transactions.clone(), PACKETS_PER_BATCH)
+                    .into_iter()
+                    .map(|x| {
+                        let len = x.packets.len();
+                        (x, iter::repeat(1).take(len).collect())
+                    })
+                    .collect();
+            }
+
+            start += chunk_len;
+            start %= verified.len();
+        }
+        eprintln!(
+            "{{'name': 'banking_bench_total', 'median': '{}'}}",
+            total / ITERS as u64,
+        );
+        eprintln!(
+            "{{'name': 'banking_bench_tx_total', 'median': '{}'}}",
+            tx_total / ITERS as u64,
+        );
+
+        drop(vote_sender);
+        exit.store(true, Ordering::Relaxed);
+        poh_service.join().unwrap();
+        sleep(Duration::from_secs(1));
+        debug!("waited for poh_service");
+    }
+    let _unused = Blocktree::destroy(&ledger_path);
+}

bench-exchange/Cargo.toml

@@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-exchange"
-version = "0.17.0"
+version = "0.19.0-pre0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
@@ -10,33 +10,30 @@ publish = false
 
 [dependencies]
 bincode = "1.1.4"
-bs58 = "0.2.0"
+bs58 = "0.3.0"
 clap = "2.32.0"
 env_logger = "0.6.2"
 itertools = "0.8.0"
-log = "0.4.7"
+log = "0.4.8"
 num-derive = "0.2"
 num-traits = "0.2"
 rand = "0.6.5"
-rayon = "1.1.0"
-serde = "1.0.97"
-serde_derive = "1.0.97"
+rayon = "1.2.0"
+serde = "1.0.101"
+serde_derive = "1.0.101"
 serde_json = "1.0.40"
 serde_yaml = "0.8.9"
 # solana-runtime = { path = "../solana/runtime"}
-solana = { path = "../core", version = "0.17.0" }
-solana-client = { path = "../client", version = "0.17.0" }
-solana-drone = { path = "../drone", version = "0.17.0" }
-solana-exchange-api = { path = "../programs/exchange_api", version = "0.17.0" }
-solana-exchange-program = { path = "../programs/exchange_program", version = "0.17.0" }
-solana-logger = { path = "../logger", version = "0.17.0" }
-solana-metrics = { path = "../metrics", version = "0.17.0" }
-solana-netutil = { path = "../netutil", version = "0.17.0" }
-solana-runtime = { path = "../runtime", version = "0.17.0" }
-solana-sdk = { path = "../sdk", version = "0.17.0" }
+solana-core = { path = "../core", version = "0.19.0-pre0" }
+solana-genesis = { path = "../genesis", version = "0.19.0-pre0" }
+solana-client = { path = "../client", version = "0.19.0-pre0" }
+solana-drone = { path = "../drone", version = "0.19.0-pre0" }
+solana-exchange-api = { path = "../programs/exchange_api", version = "0.19.0-pre0" }
+solana-exchange-program = { path = "../programs/exchange_program", version = "0.19.0-pre0" }
+solana-logger = { path = "../logger", version = "0.19.0-pre0" }
+solana-metrics = { path = "../metrics", version = "0.19.0-pre0" }
+solana-netutil = { path = "../netutil", version = "0.19.0-pre0" }
+solana-runtime = { path = "../runtime", version = "0.19.0-pre0" }
+solana-sdk = { path = "../sdk", version = "0.19.0-pre0" }
 untrusted = "0.7.0"
-ws = "0.8.1"
-
-[features]
-cuda = ["solana/cuda"]
-
+ws = "0.9.0"

bench-exchange/README.md

@@ -23,7 +23,7 @@ demo demonstrates one way to host an exchange on the Solana blockchain by
 emulating a currency exchange.
 
 The assets are virtual tokens held by investors who may post order requests to
-the exchange.  A Swapper monitors the exchange and posts swap requests for
+the exchange.  A Matcher monitors the exchange and posts swap requests for
 matching orders.  All the transactions can execute concurrently.
 
 ## Premise
@@ -42,30 +42,26 @@ matching orders.  All the transactions can execute concurrently.
   - A request to create a token account
 - Token request
   - A request to deposit tokens of a particular type into a token account.
-- Token pair
-  - A unique ordered list of two tokens.  For the four types of tokens used in
-    this demo, the valid pairs are AB, AC, AD, BC, BD, CD.
-- Direction of trade
-  - Describes which token in the pair the investor wants to sell and buy and can
-    be either "To" or "From".  For example, if an investor issues a "To" trade
-    for "AB" then they which to exchange A tokens to B tokens.  A "From" order
-    would read the other way,  A tokens from B tokens.
+- Asset pair
+  - A struct with fields Base and Quote, representing the two assets which make up a 
+    trading pair,  which themselves are Tokens. The Base or 'primary' asset is the
+    numerator and the Quote is the denominator for pricing purposes.
+- Order side
+  - Describes which side of the market an investor wants to place a trade on. Options
+    are "Bid" or "Ask", where a bid represents an offer to purchase the Base asset of
+    the AssetPair for a sum of the Quote Asset and an Ask is an offer to sell Base asset
+    for the Quote asset.
 - Price ratio
-  -  An expression of the relative prices of two tokens.  They consist of the
-     price of the primary token and the price of the secondary token.  For
-     simplicity sake, the primary token's price is always 1, which forces the
-     secondary to be the common denominator.  For example, if token A was worth
-     2 and token B was worth 6, the price ratio would be 1:3 or just 3.  Price
-     ratios are represented as fixed point numbers.  The fixed point scaler is
-     defined in
+  -  An expression of the relative prices of two tokens. Calculated with the Base
+     Asset as the numerator and the Quote Asset as the denominator. Ratios are 
+     represented as fixed point numbers.  The fixed point scaler is defined in
      [exchange_state.rs](https://github.com/solana-labs/solana/blob/c2fdd1362a029dcf89c8907c562d2079d977df11/programs/exchange_api/src/exchange_state.rs#L7)
 - Order request
-  - A Solana transaction executed by the exchange requesting the trade of one
-    type of token for another.  order requests are made up of the token pair,
-    the direction of the trade, quantity of the primary token, the price ratio,
-    and the two token accounts to be credited/deducted.  An example trade
-    request looks like "T AB 5 2" which reads "Exchange 5 A tokens to B tokens
-    at a price ratio of 1:2"  A fulfilled trade would result in 5 A tokens
+  - A Solana transaction sent by a trader to the exchange to submit an order. 
+    Order requests are made up of the token pair, the order side (bid or ask),
+    quantity of the primary token, the price ratio, and the two token accounts
+    to be credited/deducted.  An example trade request looks like "T AB 5 2" 
+    which reads "Exchange 5 A tokens to B tokens at a price ratio of 1:2"  A fulfilled trade would result in 5 A tokens
     deducted and 10 B tokens credited to the trade initiator's token accounts.
     Successful order requests result in an order.
 - Order
@@ -75,59 +71,62 @@ matching orders.  All the transactions can execute concurrently.
     contain the same information as the order request.
 - Price spread
   - The difference between the two matching orders. The spread is the
-    profit of the Swapper initiating the swap request.
-- Swap requirements
+    profit of the Matcher initiating the swap request.
+- Match requirements
   - Policies that result in a successful trade swap.
-- Swap request
-  - A request to exchange tokens between to orders
-- Trade swap
-  - A successful trade.  A swap consists of two matching orders that meet
-    swap requirements.  A trade swap may not wholly satisfy one or both of the
-    orders in which case the orders are adjusted appropriately.  As
-    long as the swap requirements are met there will be an exchange of tokens
-    between accounts.  Any price spread is deposited into the Swapper's profit
-    account.  All trade swaps are recorded in a new account for posterity.
+- Match request
+  - A request to fill two complementary orders (bid/ask), resulting if successful,
+    in a trade being created.
+- Trade
+  - A successful trade is created from two matching orders that meet
+    swap requirements which are submitted in a Match Request by a Matcher and
+    executed by the exchange. A trade may not wholly satisfy one or both of the
+    orders in which case the orders are adjusted appropriately. Upon execution,
+    tokens are distributed to the traders' accounts and any overlap or 
+    "negative spread" between orders is deposited into the Matcher's profit
+    account.  All successful trades are recorded in the data of a new solana 
+    account for posterity.
 - Investor
   - Individual investors who hold a number of tokens and wish to trade them on
     the exchange.  Investors operate as Solana thin clients who own a set of
     accounts containing tokens and/or order requests.  Investors post
     transactions to the exchange in order to request tokens and post or cancel
     order requests.
-- Swapper
-  - An agent who facilitates trading between investors.  Swappers operate as
+- Matcher
+  - An agent who facilitates trading between investors.  Matchers operate as
     Solana thin clients who monitor all the orders looking for a trade
-    match.  Once found, the Swapper issues a swap request to the exchange.
-    Swappers are the engine of the exchange and are rewarded for their efforts by
-    accumulating the price spreads of the swaps they initiate.  Swappers also
+    match.  Once found, the Matcher issues a swap request to the exchange.
+    Matchers are the engine of the exchange and are rewarded for their efforts by
+    accumulating the price spreads of the swaps they initiate.  Matchers also
     provide current bid/ask price and OHLCV (Open, High, Low, Close, Volume)
     information on demand via a public network port.
 - Transaction fees
   - Solana transaction fees are paid for by the transaction submitters who are
-    the Investors and Swappers.
+    the Investors and Matchers.
 
 ## Exchange startup
 
 The exchange is up and running when it reaches a state where it can take
-investor's trades and Swapper's swap requests.  To achieve this state the
+investors' trades and Matchers' match requests.  To achieve this state the
 following must occur in order:
 
 - Start the Solana blockchain
-- Start the Swapper thin-client
-- The Swapper subscribes to change notifications for all the accounts owned by
+- Start the  thin-client
+- The Matcher subscribes to change notifications for all the accounts owned by
   the exchange program id.  The subscription is managed via Solana's JSON RPC
   interface.
-- The Swapper starts responding to queries for bid/ask price and OHLCV
+- The Matcher starts responding to queries for bid/ask price and OHLCV
 
-The Swapper responding successfully to price and OHLCV requests is the signal to
+The Matcher responding successfully to price and OHLCV requests is the signal to
 the investors that trades submitted after that point will be analyzed.  <!--This
 is not ideal, and instead investors should be able to submit trades at any time,
-and the Swapper could come and go without missing a trade.  One way to achieve
-this is for the Swapper to read the current state of all accounts looking for all
+and the Matcher could come and go without missing a trade.  One way to achieve
+this is for the Matcher to read the current state of all accounts looking for all
 open orders.-->
 
 Investors will initially query the exchange to discover their current balance
 for each type of token.  If the investor does not already have an account for
-each type of token, they will submit account requests.  Swappers as well will
+each type of token, they will submit account requests.  Matcher as well will
 request accounts to hold the tokens they earn by initiating trade swaps.
 
 ```rust
@@ -165,7 +164,7 @@ pub struct TokenAccountInfo {
 }
 ```
 
-For this demo investors or Swappers can request more tokens from the exchange at
+For this demo investors or Matcher can request more tokens from the exchange at
 any time by submitting token requests. In non-demos, an exchange of this type
 would provide another way to exchange a 3rd party asset into tokens.
 
@@ -269,10 +268,10 @@ pub enum ExchangeInstruction {
 
 ## Trade swaps
 
-The Swapper is monitoring the accounts assigned to the exchange program and
+The Matcher is monitoring the accounts assigned to the exchange program and
 building a trade-order table.  The order table is used to identify
 matching orders which could be fulfilled.  When a match is found the
-Swapper should issue a swap request.  Swap requests may not satisfy the entirety
+Matcher should issue a swap request.  Swap requests may not satisfy the entirety
 of either order, but the exchange will greedily fulfill it.  Any leftover tokens
 in either account will keep the order valid for further swap requests in
 the future.
@@ -310,14 +309,14 @@ whole for clarity.
 | 5 | 1 T AB 2 10 | 2 F AB 1 5 |
 
 As part of a successful swap request, the exchange will credit tokens to the
-Swapper's account equal to the difference in the price ratios or the two orders.
-These tokens are considered the Swapper's profit for initiating the trade.
+Matcher's account equal to the difference in the price ratios or the two orders.
+These tokens are considered the Matcher's profit for initiating the trade.
 
-The Swapper would initiate the following swap on the order table above:
+The Matcher would initiate the following swap on the order table above:
 
   - Row 1, To:   Investor 1 trades 2 A tokens to 8 B tokens
   - Row 1, From: Investor 2 trades 2 A tokens from 8 B tokens
-  - Swapper takes 8 B tokens as profit
+  - Matcher takes 8 B tokens as profit
 
 Both row 1 trades are fully realized, table becomes:
 
@@ -328,11 +327,11 @@ Both row 1 trades are fully realized, table becomes:
 | 3 | 1 T AB 2 8  | 2 F AB 3 6 |
 | 4 | 1 T AB 2 10 | 2 F AB 1 5 |
 
-The Swapper would initiate the following swap:
+The Matcher would initiate the following swap:
 
   - Row 1, To:   Investor 1 trades 1 A token to 4 B tokens
   - Row 1, From: Investor 2 trades 1 A token from 4 B tokens
-  - Swapper takes 4 B tokens as profit
+  - Matcher takes 4 B tokens as profit
 
 Row 1 From is not fully realized, table becomes:
 
@@ -343,11 +342,11 @@ Row 1 From is not fully realized, table becomes:
 | 3 | 1 T AB 2 10 | 2 F AB 3 6 |
 | 4 |             | 2 F AB 1 5 |
 
-The Swapper would initiate the following swap:
+The Matcher would initiate the following swap:
 
   - Row 1, To:   Investor 1 trades 1 A token to 6 B tokens
   - Row 1, From: Investor 2 trades 1 A token from 6 B tokens
-  - Swapper takes 2 B tokens as profit
+  - Matcher takes 2 B tokens as profit
 
 Row 1 To is now fully realized, table becomes:
 
@@ -357,11 +356,11 @@ Row 1 To is now fully realized, table becomes:
 | 2 | 1 T AB 2 8  | 2 F AB 3 5 |
 | 3 | 1 T AB 2 10 | 2 F AB 1 5 |
 
-The Swapper would initiate the following last swap:
+The Matcher would initiate the following last swap:
 
   - Row 1, To:   Investor 1 trades 2 A token to 12 B tokens
   - Row 1, From: Investor 2 trades 2 A token from 12 B tokens
-  - Swapper takes 4 B tokens as profit
+  - Matcher takes 4 B tokens as profit
 
 Table becomes:
 
@@ -383,7 +382,7 @@ pub enum ExchangeInstruction {
     /// key 3 - `From` order
     /// key 4 - Token account associated with the To Trade
     /// key 5 - Token account associated with From trade
-    /// key 6 - Token account in which to deposit the Swappers profit from the swap.
+    /// key 6 - Token account in which to deposit the Matcher profit from the swap.
     SwapRequest,
 }
 
@@ -442,14 +441,14 @@ pub enum ExchangeInstruction {
     /// key 3 - `From` order
     /// key 4 - Token account associated with the To Trade
     /// key 5 - Token account associated with From trade
-    /// key 6 - Token account in which to deposit the Swappers profit from the swap.
+    /// key 6 - Token account in which to deposit the Matcher profit from the swap.
     SwapRequest,
 }
 ```
 
 ## Quotes and OHLCV
 
-The Swapper will provide current bid/ask price quotes based on trade actively and
+The Matcher will provide current bid/ask price quotes based on trade actively and
 also provide OHLCV based on some time window.  The details of how the bid/ask
 price quotes are calculated are yet to be decided.
 

bench-exchange/src/bench.rs

@@ -5,20 +5,21 @@ use itertools::izip;
 use log::*;
 use rand::{thread_rng, Rng};
 use rayon::prelude::*;
-use solana::gen_keys::GenKeys;
 use solana_client::perf_utils::{sample_txs, SampleStats};
+use solana_core::gen_keys::GenKeys;
 use solana_drone::drone::request_airdrop_transaction;
 use solana_exchange_api::exchange_instruction;
 use solana_exchange_api::exchange_state::*;
 use solana_exchange_api::id;
+use solana_genesis::PrimordialAccountDetails;
 use solana_metrics::datapoint_info;
 use solana_sdk::client::Client;
 use solana_sdk::client::SyncClient;
 use solana_sdk::pubkey::Pubkey;
 use solana_sdk::signature::{Keypair, KeypairUtil};
-use solana_sdk::system_instruction;
 use solana_sdk::timing::{duration_as_ms, duration_as_s};
 use solana_sdk::transaction::Transaction;
+use solana_sdk::{system_instruction, system_program};
 use std::cmp;
 use std::collections::{HashMap, VecDeque};
 use std::fs::File;
@@ -88,7 +89,12 @@ pub fn create_client_accounts_file(
     keypairs.iter().for_each(|keypair| {
         accounts.insert(
             serde_json::to_string(&keypair.to_bytes().to_vec()).unwrap(),
-            fund_amount,
+            PrimordialAccountDetails {
+                balance: fund_amount,
+                executable: false,
+                owner: system_program::id().to_string(),
+                data: String::new(),
+            },
         );
     });
 
@@ -134,7 +140,8 @@ where
         let path = Path::new(&client_ids_and_stake_file);
         let file = File::open(path).unwrap();
 
-        let accounts: HashMap<String, u64> = serde_yaml::from_reader(file).unwrap();
+        let accounts: HashMap<String, PrimordialAccountDetails> =
+            serde_yaml::from_reader(file).unwrap();
         accounts
             .into_iter()
             .map(|(keypair, _)| {
@@ -527,21 +534,21 @@ fn trader<T>(
         let mut trade_infos = vec![];
         let start = account_group * batch_size as usize;
         let end = account_group * batch_size as usize + batch_size as usize;
-        let mut direction = Direction::To;
+        let mut side = OrderSide::Ask;
         for (signer, trade, src) in izip!(
             signers[start..end].iter(),
             trade_keys,
             srcs[start..end].iter(),
         ) {
-            direction = if direction == Direction::To {
-                Direction::From
+            side = if side == OrderSide::Ask {
+                OrderSide::Bid
             } else {
-                Direction::To
+                OrderSide::Ask
             };
             let order_info = OrderInfo {
                 /// Owner of the trade order
                 owner: Pubkey::default(), // don't care
-                direction,
+                side,
                 pair,
                 tokens,
                 price,
@@ -551,7 +558,7 @@ fn trader<T>(
                 trade_account: trade.pubkey(),
                 order_info,
             });
-            trades.push((signer, trade.pubkey(), direction, src));
+            trades.push((signer, trade.pubkey(), side, src));
         }
         account_group = (account_group + 1) % account_groups as usize;
 
@@ -562,7 +569,7 @@ fn trader<T>(
         trades.chunks(chunk_size).for_each(|chunk| {
             let trades_txs: Vec<_> = chunk
                 .par_iter()
-                .map(|(signer, trade, direction, src)| {
+                .map(|(signer, trade, side, src)| {
                     let s: &Keypair = &signer;
                     let owner = &signer.pubkey();
                     let space = mem::size_of::<ExchangeState>() as u64;
@@ -571,7 +578,7 @@ fn trader<T>(
                         vec![
                             system_instruction::create_account(owner, trade, 1, space, &id()),
                             exchange_instruction::trade_request(
-                                owner, trade, *direction, pair, tokens, price, src,
+                                owner, trade, *side, pair, tokens, price, src,
                             ),
                         ],
                         blockhash,
@@ -660,7 +667,7 @@ fn verify_funding_transfer<T: SyncClient + ?Sized>(
     false
 }
 
-pub fn fund_keys(client: &Client, source: &Keypair, dests: &[Arc<Keypair>], lamports: u64) {
+pub fn fund_keys(client: &dyn Client, source: &Keypair, dests: &[Arc<Keypair>], lamports: u64) {
     let total = lamports * (dests.len() as u64 + 1);
     let mut funded: Vec<(&Keypair, u64)> = vec![(source, total)];
     let mut notfunded: Vec<&Arc<Keypair>> = dests.iter().collect();
@@ -764,7 +771,7 @@ pub fn fund_keys(client: &Client, source: &Keypair, dests: &[Arc<Keypair>], lamp
                     retries += 1;
                     debug!("  Retry {:?}", retries);
                     if retries >= 10 {
-                        error!("  Too many retries, give up");
+                        error!("fund_keys: Too many retries ({}), give up", retries);
                         exit(1);
                     }
                 }
@@ -778,7 +785,7 @@ pub fn fund_keys(client: &Client, source: &Keypair, dests: &[Arc<Keypair>], lamp
     }
 }
 
-pub fn create_token_accounts(client: &Client, signers: &[Arc<Keypair>], accounts: &[Pubkey]) {
+pub fn create_token_accounts(client: &dyn Client, signers: &[Arc<Keypair>], accounts: &[Pubkey]) {
     let mut notfunded: Vec<(&Arc<Keypair>, &Pubkey)> = signers.iter().zip(accounts).collect();
 
     while !notfunded.is_empty() {
@@ -843,7 +850,10 @@ pub fn create_token_accounts(client: &Client, signers: &[Arc<Keypair>], accounts
                     retries += 1;
                     debug!("  Retry {:?}", retries);
                     if retries >= 20 {
-                        error!("  Too many retries, give up");
+                        error!(
+                            "create_token_accounts: Too many retries ({}), give up",
+                            retries
+                        );
                         exit(1);
                     }
                 }
@@ -908,7 +918,7 @@ fn generate_keypairs(num: u64) -> Vec<Keypair> {
     rnd.gen_n_keypairs(num)
 }
 
-pub fn airdrop_lamports(client: &Client, drone_addr: &SocketAddr, id: &Keypair, amount: u64) {
+pub fn airdrop_lamports(client: &dyn Client, drone_addr: &SocketAddr, id: &Keypair, amount: u64) {
     let balance = client.get_balance(&id.pubkey());
     let balance = balance.unwrap_or(0);
     if balance >= amount {
@@ -953,109 +963,9 @@ pub fn airdrop_lamports(client: &Client, drone_addr: &SocketAddr, id: &Keypair,
         debug!("  Retry...");
         tries += 1;
         if tries > 50 {
-            error!("Too many retries, give up");
+            error!("airdrop_lamports: Too many retries ({}), give up", tries);
             exit(1);
         }
         sleep(Duration::from_secs(2));
     }
 }
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-    use solana::gossip_service::{discover_cluster, get_multi_client};
-    use solana::local_cluster::{ClusterConfig, LocalCluster};
-    use solana::validator::ValidatorConfig;
-    use solana_drone::drone::run_local_drone;
-    use solana_exchange_api::exchange_processor::process_instruction;
-    use solana_runtime::bank::Bank;
-    use solana_runtime::bank_client::BankClient;
-    use solana_sdk::genesis_block::create_genesis_block;
-    use std::sync::mpsc::channel;
-
-    #[test]
-    fn test_exchange_local_cluster() {
-        solana_logger::setup();
-
-        const NUM_NODES: usize = 1;
-
-        let mut config = Config::default();
-        config.identity = Keypair::new();
-        config.duration = Duration::from_secs(1);
-        config.fund_amount = 100_000;
-        config.threads = 1;
-        config.transfer_delay = 20; // 15
-        config.batch_size = 100; // 1000;
-        config.chunk_size = 10; // 200;
-        config.account_groups = 1; // 10;
-        let Config {
-            fund_amount,
-            batch_size,
-            account_groups,
-            ..
-        } = config;
-        let accounts_in_groups = batch_size * account_groups;
-
-        let cluster = LocalCluster::new(&ClusterConfig {
-            node_stakes: vec![100_000; NUM_NODES],
-            cluster_lamports: 100_000_000_000_000,
-            validator_configs: vec![ValidatorConfig::default(); NUM_NODES],
-            native_instruction_processors: [solana_exchange_program!()].to_vec(),
-            ..ClusterConfig::default()
-        });
-
-        let drone_keypair = Keypair::new();
-        cluster.transfer(
-            &cluster.funding_keypair,
-            &drone_keypair.pubkey(),
-            2_000_000_000_000,
-        );
-
-        let (addr_sender, addr_receiver) = channel();
-        run_local_drone(drone_keypair, addr_sender, Some(1_000_000_000_000));
-        let drone_addr = addr_receiver.recv_timeout(Duration::from_secs(2)).unwrap();
-
-        info!("Connecting to the cluster");
-        let (nodes, _) = discover_cluster(&cluster.entry_point_info.gossip, NUM_NODES)
-            .unwrap_or_else(|err| {
-                error!("Failed to discover {} nodes: {:?}", NUM_NODES, err);
-                exit(1);
-            });
-
-        let (client, num_clients) = get_multi_client(&nodes);
-
-        info!("clients: {}", num_clients);
-        assert!(num_clients >= NUM_NODES);
-
-        const NUM_SIGNERS: u64 = 2;
-        airdrop_lamports(
-            &client,
-            &drone_addr,
-            &config.identity,
-            fund_amount * (accounts_in_groups + 1) as u64 * NUM_SIGNERS,
-        );
-
-        do_bench_exchange(vec![client], config);
-    }
-
-    #[test]
-    fn test_exchange_bank_client() {
-        solana_logger::setup();
-        let (genesis_block, identity) = create_genesis_block(100_000_000_000_000);
-        let mut bank = Bank::new(&genesis_block);
-        bank.add_instruction_processor(id(), process_instruction);
-        let clients = vec![BankClient::new(bank)];
-
-        let mut config = Config::default();
-        config.identity = identity;
-        config.duration = Duration::from_secs(1);
-        config.fund_amount = 100_000;
-        config.threads = 1;
-        config.transfer_delay = 20; // 0;
-        config.batch_size = 100; // 1500;
-        config.chunk_size = 10; // 1500;
-        config.account_groups = 1; // 50;
-
-        do_bench_exchange(clients, config);
-    }
-}

bench-exchange/src/cli.rs

@@ -1,5 +1,5 @@
 use clap::{crate_description, crate_name, crate_version, value_t, App, Arg, ArgMatches};
-use solana::gen_keys::GenKeys;
+use solana_core::gen_keys::GenKeys;
 use solana_drone::drone::DRONE_PORT;
 use solana_sdk::signature::{read_keypair, Keypair, KeypairUtil};
 use std::net::SocketAddr;

bench-exchange/src/lib.rs

@@ -0,0 +1,3 @@
+pub mod bench;
+pub mod cli;
+mod order_book;

bench-exchange/src/main.rs

@@ -2,13 +2,9 @@ pub mod bench;
 mod cli;
 pub mod order_book;
 
-#[cfg(test)]
-#[macro_use]
-extern crate solana_exchange_program;
-
 use crate::bench::{airdrop_lamports, create_client_accounts_file, do_bench_exchange, Config};
 use log::*;
-use solana::gossip_service::{discover_cluster, get_multi_client};
+use solana_core::gossip_service::{discover_cluster, get_multi_client};
 use solana_sdk::signature::KeypairUtil;
 
 fn main() {

bench-exchange/src/order_book.rs

@@ -96,12 +96,12 @@ impl OrderBook {
     //     Ok(())
     // }
     pub fn push(&mut self, pubkey: Pubkey, info: OrderInfo) -> Result<(), Box<dyn error::Error>> {
-        check_trade(info.direction, info.tokens, info.price)?;
-        match info.direction {
-            Direction::To => {
+        check_trade(info.side, info.tokens, info.price)?;
+        match info.side {
+            OrderSide::Ask => {
                 self.to_ab.push(ToOrder { pubkey, info });
             }
-            Direction::From => {
+            OrderSide::Bid => {
                 self.from_ab.push(FromOrder { pubkey, info });
             }
         }

bench-streamer/Cargo.toml

@@ -2,17 +2,13 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-streamer"
-version = "0.17.0"
+version = "0.19.0-pre0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
 
 [dependencies]
 clap = "2.33.0"
-solana = { path = "../core", version = "0.17.0" }
-solana-logger = { path = "../logger", version = "0.17.0" }
-solana-netutil = { path = "../netutil", version = "0.17.0" }
-
-[features]
-cuda = ["solana/cuda"]
-
+solana-core = { path = "../core", version = "0.19.0-pre0" }
+solana-logger = { path = "../logger", version = "0.19.0-pre0" }
+solana-netutil = { path = "../netutil", version = "0.19.0-pre0" }

bench-streamer/src/main.rs

@@ -1,8 +1,8 @@
 use clap::{crate_description, crate_name, crate_version, App, Arg};
-use solana::packet::PacketsRecycler;
-use solana::packet::{Packet, Packets, BLOB_SIZE, PACKET_DATA_SIZE};
-use solana::result::Result;
-use solana::streamer::{receiver, PacketReceiver};
+use solana_core::packet::PacketsRecycler;
+use solana_core::packet::{Packet, Packets, BLOB_SIZE, PACKET_DATA_SIZE};
+use solana_core::result::Result;
+use solana_core::streamer::{receiver, PacketReceiver};
 use std::cmp::max;
 use std::net::{IpAddr, Ipv4Addr, SocketAddr, UdpSocket};
 use std::sync::atomic::{AtomicBool, AtomicUsize, Ordering};

bench-tps/Cargo.toml

@@ -2,28 +2,34 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-tps"
-version = "0.17.0"
+version = "0.19.0-pre0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
 
 [dependencies]
+bincode = "1.1.4"
 clap = "2.33.0"
-log = "0.4.7"
-rayon = "1.1.0"
-serde = "1.0.97"
-serde_derive = "1.0.97"
+log = "0.4.8"
+rayon = "1.2.0"
+serde = "1.0.101"
+serde_derive = "1.0.101"
 serde_json = "1.0.40"
 serde_yaml = "0.8.9"
-solana = { path = "../core", version = "0.17.0" }
-solana-client = { path = "../client", version = "0.17.0" }
-solana-drone = { path = "../drone", version = "0.17.0" }
-solana-logger = { path = "../logger", version = "0.17.0" }
-solana-metrics = { path = "../metrics", version = "0.17.0" }
-solana-netutil = { path = "../netutil", version = "0.17.0" }
-solana-runtime = { path = "../runtime", version = "0.17.0" }
-solana-sdk = { path = "../sdk", version = "0.17.0" }
-
-[features]
-cuda = ["solana/cuda"]
+solana-core = { path = "../core", version = "0.19.0-pre0" }
+solana-genesis = { path = "../genesis", version = "0.19.0-pre0" }
+solana-client = { path = "../client", version = "0.19.0-pre0" }
+solana-drone = { path = "../drone", version = "0.19.0-pre0" }
+solana-librapay-api = { path = "../programs/librapay_api", version = "0.19.0-pre0" }
+solana-logger = { path = "../logger", version = "0.19.0-pre0" }
+solana-metrics = { path = "../metrics", version = "0.19.0-pre0" }
+solana-measure = { path = "../measure", version = "0.19.0-pre0" }
+solana-netutil = { path = "../netutil", version = "0.19.0-pre0" }
+solana-runtime = { path = "../runtime", version = "0.19.0-pre0" }
+solana-sdk = { path = "../sdk", version = "0.19.0-pre0" }
+solana-move-loader-program = { path = "../programs/move_loader_program", version = "0.19.0-pre0" }
+solana-move-loader-api = { path = "../programs/move_loader_api", version = "0.19.0-pre0" }
 
+[dev-dependencies]
+serial_test = "0.2.0"
+serial_test_derive = "0.2.0"

bench-tps/src/bench.rs

@@ -1,13 +1,19 @@
 use solana_metrics;
 
+use crate::cli::Config;
+use bincode;
 use log::*;
 use rayon::prelude::*;
-use solana::gen_keys::GenKeys;
 use solana_client::perf_utils::{sample_txs, SampleStats};
+use solana_core::gen_keys::GenKeys;
 use solana_drone::drone::request_airdrop_transaction;
+use solana_librapay_api::{create_genesis, upload_mint_program, upload_payment_program};
+use solana_measure::measure::Measure;
 use solana_metrics::datapoint_info;
 use solana_sdk::client::Client;
+use solana_sdk::fee_calculator::FeeCalculator;
 use solana_sdk::hash::Hash;
+use solana_sdk::pubkey::Pubkey;
 use solana_sdk::signature::{Keypair, KeypairUtil};
 use solana_sdk::system_instruction;
 use solana_sdk::system_transaction;
@@ -24,8 +30,9 @@ use std::thread::Builder;
 use std::time::Duration;
 use std::time::Instant;
 
+use solana_librapay_api::librapay_transaction;
+
 pub const MAX_SPENDS_PER_TX: u64 = 4;
-pub const NUM_LAMPORTS_PER_ACCOUNT: u64 = 128;
 
 #[derive(Debug)]
 pub enum BenchTpsError {
@@ -36,25 +43,17 @@ pub type Result<T> = std::result::Result<T, BenchTpsError>;
 
 pub type SharedTransactions = Arc<RwLock<VecDeque<Vec<(Transaction, u64)>>>>;
 
-pub struct Config {
-    pub id: Keypair,
-    pub threads: usize,
-    pub thread_batch_sleep_ms: usize,
-    pub duration: Duration,
-    pub tx_count: usize,
-    pub sustained: bool,
-}
+type LibraKeys = (Keypair, Pubkey, Pubkey, Vec<Keypair>);
 
-impl Default for Config {
-    fn default() -> Self {
-        Self {
-            id: Keypair::new(),
-            threads: 4,
-            thread_batch_sleep_ms: 0,
-            duration: Duration::new(std::u64::MAX, 0),
-            tx_count: 500_000,
-            sustained: false,
-        }
+fn get_recent_blockhash<T: Client>(client: &T) -> (Hash, FeeCalculator) {
+    loop {
+        match client.get_recent_blockhash() {
+            Ok((blockhash, fee_calculator)) => return (blockhash, fee_calculator),
+            Err(err) => {
+                info!("Couldn't get recent blockhash: {:?}", err);
+                sleep(Duration::from_secs(1));
+            }
+        };
     }
 }
 
@@ -63,6 +62,7 @@ pub fn do_bench_tps<T>(
     config: Config,
     gen_keypairs: Vec<Keypair>,
     keypair0_balance: u64,
+    libra_args: Option<LibraKeys>,
 ) -> u64
 where
     T: 'static + Client + Send + Sync,
@@ -74,6 +74,8 @@ where
         duration,
         tx_count,
         sustained,
+        num_lamports_per_account,
+        ..
     } = config;
 
     let clients: Vec<_> = clients.into_iter().map(Arc::new).collect();
@@ -82,7 +84,15 @@ where
     let start = gen_keypairs.len() - (tx_count * 2) as usize;
     let keypairs = &gen_keypairs[start..];
 
-    let first_tx_count = client.get_transaction_count().expect("transaction count");
+    let first_tx_count = loop {
+        match client.get_transaction_count() {
+            Ok(count) => break count,
+            Err(err) => {
+                info!("Couldn't get transaction count: {:?}", err);
+                sleep(Duration::from_secs(1));
+            }
+        }
+    };
     println!("Initial transaction count {}", first_tx_count);
 
     let exit_signal = Arc::new(AtomicBool::new(false));
@@ -165,6 +175,7 @@ where
             &keypairs[len..],
             threads,
             reclaim_lamports_back_to_source_account,
+            &libra_args,
         );
         // In sustained mode overlap the transfers with generation
         // this has higher average performance but lower peak performance
@@ -176,7 +187,7 @@ where
         }
 
         i += 1;
-        if should_switch_directions(NUM_LAMPORTS_PER_ACCOUNT, i) {
+        if should_switch_directions(num_lamports_per_account, i) {
             reclaim_lamports_back_to_source_account = !reclaim_lamports_back_to_source_account;
         }
     }
@@ -221,6 +232,74 @@ fn metrics_submit_lamport_balance(lamport_balance: u64) {
     );
 }
 
+fn generate_move_txs(
+    source: &[Keypair],
+    dest: &[Keypair],
+    reclaim: bool,
+    move_keypairs: &[Keypair],
+    libra_pay_program_id: &Pubkey,
+    libra_mint_id: &Pubkey,
+    blockhash: &Hash,
+) -> Vec<(Transaction, u64)> {
+    let count = move_keypairs.len() / 2;
+    let source_move = &move_keypairs[..count];
+    let dest_move = &move_keypairs[count..];
+    let pairs: Vec<_> = if !reclaim {
+        source_move
+            .iter()
+            .zip(dest_move.iter())
+            .zip(source.iter())
+            .collect()
+    } else {
+        dest_move
+            .iter()
+            .zip(source_move.iter())
+            .zip(dest.iter())
+            .collect()
+    };
+
+    pairs
+        .par_iter()
+        .map(|((from, to), payer)| {
+            (
+                librapay_transaction::transfer(
+                    libra_pay_program_id,
+                    libra_mint_id,
+                    &payer,
+                    &from,
+                    &to.pubkey(),
+                    1,
+                    *blockhash,
+                ),
+                timestamp(),
+            )
+        })
+        .collect()
+}
+
+fn generate_system_txs(
+    source: &[Keypair],
+    dest: &[Keypair],
+    reclaim: bool,
+    blockhash: &Hash,
+) -> Vec<(Transaction, u64)> {
+    let pairs: Vec<_> = if !reclaim {
+        source.iter().zip(dest.iter()).collect()
+    } else {
+        dest.iter().zip(source.iter()).collect()
+    };
+
+    pairs
+        .par_iter()
+        .map(|(from, to)| {
+            (
+                system_transaction::create_user_account(from, &to.pubkey(), 1, *blockhash),
+                timestamp(),
+            )
+        })
+        .collect()
+}
+
 fn generate_txs(
     shared_txs: &SharedTransactions,
     blockhash: &Hash,
@@ -228,25 +307,31 @@ fn generate_txs(
     dest: &[Keypair],
     threads: usize,
     reclaim: bool,
+    libra_args: &Option<LibraKeys>,
 ) {
     let tx_count = source.len();
     println!("Signing transactions... {} (reclaim={})", tx_count, reclaim);
     let signing_start = Instant::now();
 
-    let pairs: Vec<_> = if !reclaim {
-        source.iter().zip(dest.iter()).collect()
+    let transactions = if let Some((
+        libra_genesis_keypair,
+        libra_pay_program_id,
+        _libra_mint_program_id,
+        libra_keys,
+    )) = libra_args
+    {
+        generate_move_txs(
+            source,
+            dest,
+            reclaim,
+            &libra_keys,
+            libra_pay_program_id,
+            &libra_genesis_keypair.pubkey(),
+            blockhash,
+        )
     } else {
-        dest.iter().zip(source.iter()).collect()
+        generate_system_txs(source, dest, reclaim, blockhash)
     };
-    let transactions: Vec<_> = pairs
-        .par_iter()
-        .map(|(id, keypair)| {
-            (
-                system_transaction::create_user_account(id, &keypair.pubkey(), 1, *blockhash),
-                timestamp(),
-            )
-        })
-        .collect();
 
     let duration = signing_start.elapsed();
     let ns = duration.as_secs() * 1_000_000_000 + u64::from(duration.subsec_nanos());
@@ -296,7 +381,7 @@ fn do_tx_transfers<T: Client>(
             println!(
                 "Transferring 1 unit {} times... to {}",
                 txs0.len(),
-                client.as_ref().transactions_addr(),
+                client.as_ref().tpu_addr(),
             );
             let tx_len = txs0.len();
             let transfer_start = Instant::now();
@@ -353,7 +438,12 @@ pub fn fund_keys<T: Client>(
     let mut notfunded: Vec<&Keypair> = dests.iter().collect();
     let lamports_per_account = (total - (extra * max_fee)) / (notfunded.len() as u64 + 1);
 
-    println!("funding keys {}", dests.len());
+    println!(
+        "funding keys {} with lamports: {:?} total: {}",
+        dests.len(),
+        client.get_balance(&source.pubkey()),
+        total
+    );
     while !notfunded.is_empty() {
         let mut new_funded: Vec<(&Keypair, u64)> = vec![];
         let mut to_fund = vec![];
@@ -392,13 +482,10 @@ pub fn fund_keys<T: Client>(
             let mut to_fund_txs: Vec<_> = chunk
                 .par_iter()
                 .map(|(k, m)| {
-                    (
-                        k.clone(),
-                        Transaction::new_unsigned_instructions(system_instruction::transfer_many(
-                            &k.pubkey(),
-                            &m,
-                        )),
-                    )
+                    let tx = Transaction::new_unsigned_instructions(
+                        system_instruction::transfer_many(&k.pubkey(), &m),
+                    );
+                    (k.clone(), tx)
                 })
                 .collect();
 
@@ -421,7 +508,7 @@ pub fn fund_keys<T: Client>(
                     to_fund_txs.len(),
                 );
 
-                let (blockhash, _fee_calculator) = client.get_recent_blockhash().unwrap();
+                let (blockhash, _fee_calculator) = get_recent_blockhash(client);
 
                 // re-sign retained to_fund_txes with updated blockhash
                 to_fund_txs.par_iter_mut().for_each(|(k, tx)| {
@@ -471,7 +558,7 @@ pub fn airdrop_lamports<T: Client>(
             id.pubkey(),
         );
 
-        let (blockhash, _fee_calculator) = client.get_recent_blockhash().unwrap();
+        let (blockhash, _fee_calculator) = get_recent_blockhash(client);
         match request_airdrop_transaction(&drone_addr, &id.pubkey(), airdrop_amount, blockhash) {
             Ok(transaction) => {
                 let signature = client.async_send_transaction(transaction).unwrap();
@@ -602,15 +689,171 @@ pub fn generate_keypairs(seed_keypair: &Keypair, count: u64) -> (Vec<Keypair>, u
     (rnd.gen_n_keypairs(total_keys), extra)
 }
 
+fn fund_move_keys<T: Client>(
+    client: &T,
+    funding_key: &Keypair,
+    keypairs: &[Keypair],
+    total: u64,
+    libra_pay_program_id: &Pubkey,
+    libra_mint_program_id: &Pubkey,
+    libra_mint_key: &Keypair,
+) {
+    let (mut blockhash, _fee_calculator) = get_recent_blockhash(client);
+
+    info!("creating the libra funding account..");
+    let libra_funding_key = Keypair::new();
+    let tx = librapay_transaction::create_account(
+        funding_key,
+        &libra_funding_key.pubkey(),
+        1,
+        blockhash,
+    );
+    client.send_message(&[funding_key], tx.message).unwrap();
+
+    info!("minting to funding keypair");
+    let tx = librapay_transaction::mint_tokens(
+        &libra_mint_program_id,
+        funding_key,
+        libra_mint_key,
+        &libra_funding_key.pubkey(),
+        total,
+        blockhash,
+    );
+    client
+        .send_message(&[funding_key, libra_mint_key], tx.message)
+        .unwrap();
+
+    info!("creating {} move accounts...", keypairs.len());
+    let create_len = 8;
+    let mut funding_time = Measure::start("funding_time");
+    for (i, keys) in keypairs.chunks(create_len).enumerate() {
+        if client.get_balance(&keys[0].pubkey()).unwrap_or(0) > 0 {
+            // already created these accounts.
+            break;
+        }
+
+        let pubkeys: Vec<_> = keys.iter().map(|k| k.pubkey()).collect();
+        let tx = librapay_transaction::create_accounts(funding_key, &pubkeys, 1, blockhash);
+
+        let ser_size = bincode::serialized_size(&tx).unwrap();
+
+        client.send_message(&[funding_key], tx.message).unwrap();
+
+        if i % 10 == 0 {
+            info!(
+                "size: {} created {} accounts of {}",
+                ser_size,
+                i,
+                (keypairs.len() / create_len),
+            );
+        }
+    }
+    funding_time.stop();
+    info!("funding accounts {}ms", funding_time.as_ms());
+
+    const NUM_FUNDING_KEYS: usize = 4;
+    let funding_keys: Vec<_> = (0..NUM_FUNDING_KEYS).map(|_| Keypair::new()).collect();
+    let pubkey_amounts: Vec<_> = funding_keys
+        .iter()
+        .map(|key| (key.pubkey(), total / NUM_FUNDING_KEYS as u64))
+        .collect();
+    let tx = Transaction::new_signed_instructions(
+        &[funding_key],
+        system_instruction::transfer_many(&funding_key.pubkey(), &pubkey_amounts),
+        blockhash,
+    );
+    client.send_message(&[funding_key], tx.message).unwrap();
+    let mut balance = 0;
+    for _ in 0..20 {
+        if let Ok(balance_) = client.get_balance(&funding_keys[0].pubkey()) {
+            if balance_ > 0 {
+                balance = balance_;
+                break;
+            }
+        }
+        sleep(Duration::from_millis(100));
+    }
+    assert!(balance > 0);
+    info!("funded multiple funding accounts.. {:?}", balance);
+
+    let libra_funding_keys: Vec<_> = (0..NUM_FUNDING_KEYS).map(|_| Keypair::new()).collect();
+    for (i, key) in libra_funding_keys.iter().enumerate() {
+        let tx =
+            librapay_transaction::create_account(&funding_keys[i], &key.pubkey(), 1, blockhash);
+        client
+            .send_message(&[&funding_keys[i]], tx.message)
+            .unwrap();
+
+        let tx = librapay_transaction::transfer(
+            libra_pay_program_id,
+            &libra_mint_key.pubkey(),
+            &funding_keys[i],
+            &libra_funding_key,
+            &key.pubkey(),
+            total / NUM_FUNDING_KEYS as u64,
+            blockhash,
+        );
+        client
+            .send_message(&[&funding_keys[i], &libra_funding_key], tx.message)
+            .unwrap();
+
+        info!("funded libra funding key {}", i);
+    }
+
+    let tx_count = keypairs.len();
+    let amount = total / (tx_count as u64);
+    for (i, keys) in keypairs[..tx_count].chunks(NUM_FUNDING_KEYS).enumerate() {
+        for (j, key) in keys.iter().enumerate() {
+            let tx = librapay_transaction::transfer(
+                libra_pay_program_id,
+                &libra_mint_key.pubkey(),
+                &funding_keys[j],
+                &libra_funding_keys[j],
+                &key.pubkey(),
+                amount,
+                blockhash,
+            );
+
+            let _sig = client
+                .async_send_transaction(tx.clone())
+                .expect("create_account in generate_and_fund_keypairs");
+        }
+
+        info!("sent... checking balance {}", i);
+        for (j, key) in keys.iter().enumerate() {
+            let mut times = 0;
+            loop {
+                let balance =
+                    librapay_transaction::get_libra_balance(client, &key.pubkey()).unwrap();
+                if balance >= amount {
+                    break;
+                } else if times > 20 {
+                    info!("timed out.. {} key: {} balance: {}", i, j, balance);
+                    break;
+                } else {
+                    times += 1;
+                    sleep(Duration::from_millis(100));
+                }
+            }
+        }
+
+        info!("funded: {} of {}", i, keypairs.len() / NUM_FUNDING_KEYS);
+        blockhash = get_recent_blockhash(client).0;
+    }
+
+    info!("done funding keys..");
+}
+
 pub fn generate_and_fund_keypairs<T: Client>(
     client: &T,
     drone_addr: Option<SocketAddr>,
-    funding_pubkey: &Keypair,
+    funding_key: &Keypair,
     tx_count: usize,
     lamports_per_account: u64,
-) -> Result<(Vec<Keypair>, u64)> {
+    use_move: bool,
+) -> Result<(Vec<Keypair>, Option<LibraKeys>, u64)> {
     info!("Creating {} keypairs...", tx_count * 2);
-    let (mut keypairs, extra) = generate_keypairs(funding_pubkey, tx_count as u64 * 2);
+    let (mut keypairs, extra) = generate_keypairs(funding_key, tx_count as u64 * 2);
     info!("Get lamports...");
 
     // Sample the first keypair, see if it has lamports, if so then resume.
@@ -619,19 +862,60 @@ pub fn generate_and_fund_keypairs<T: Client>(
         .get_balance(&keypairs[tx_count * 2 - 1].pubkey())
         .unwrap_or(0);
 
+    let mut move_keypairs_ret = None;
+
     if lamports_per_account > last_keypair_balance {
-        let (_, fee_calculator) = client.get_recent_blockhash().unwrap();
+        let (_blockhash, fee_calculator) = get_recent_blockhash(client);
         let account_desired_balance =
             lamports_per_account - last_keypair_balance + fee_calculator.max_lamports_per_signature;
         let extra_fees = extra * fee_calculator.max_lamports_per_signature;
-        let total = account_desired_balance * (1 + keypairs.len() as u64) + extra_fees;
-        if client.get_balance(&funding_pubkey.pubkey()).unwrap_or(0) < total {
-            airdrop_lamports(client, &drone_addr.unwrap(), funding_pubkey, total)?;
+        let mut total = account_desired_balance * (1 + keypairs.len() as u64) + extra_fees;
+        if use_move {
+            total *= 3;
         }
-        info!("adding more lamports {}", account_desired_balance);
+
+        println!("Previous key balance: {} max_fee: {} lamports_per_account: {} extra: {} desired_balance: {} total: {}",
+                 last_keypair_balance, fee_calculator.max_lamports_per_signature, lamports_per_account, extra,
+                 account_desired_balance, total
+                 );
+
+        if client.get_balance(&funding_key.pubkey()).unwrap_or(0) < total {
+            airdrop_lamports(client, &drone_addr.unwrap(), funding_key, total)?;
+        }
+
+        if use_move {
+            let libra_genesis_keypair = create_genesis(&funding_key, client, 10_000_000);
+            let libra_mint_program_id = upload_mint_program(&funding_key, client);
+            let libra_pay_program_id = upload_payment_program(&funding_key, client);
+
+            // Generate another set of keypairs for move accounts.
+            // Still fund the solana ones which will be used for fees.
+            let seed = [0u8; 32];
+            let mut rnd = GenKeys::new(seed);
+            let move_keypairs = rnd.gen_n_keypairs(tx_count as u64 * 2);
+            fund_move_keys(
+                client,
+                funding_key,
+                &move_keypairs,
+                total / 3,
+                &libra_pay_program_id,
+                &libra_mint_program_id,
+                &libra_genesis_keypair,
+            );
+            move_keypairs_ret = Some((
+                libra_genesis_keypair,
+                libra_pay_program_id,
+                libra_mint_program_id,
+                move_keypairs,
+            ));
+
+            // Give solana keys 1/3 and move keys 1/3 the lamports. Keep 1/3 for fees.
+            total /= 3;
+        }
+
         fund_keys(
             client,
-            funding_pubkey,
+            funding_key,
             &keypairs,
             total,
             fee_calculator.max_lamports_per_signature,
@@ -642,23 +926,17 @@ pub fn generate_and_fund_keypairs<T: Client>(
     // 'generate_keypairs' generates extra keys to be able to have size-aligned funding batches for fund_keys.
     keypairs.truncate(2 * tx_count);
 
-    Ok((keypairs, last_keypair_balance))
+    Ok((keypairs, move_keypairs_ret, last_keypair_balance))
 }
 
 #[cfg(test)]
 mod tests {
     use super::*;
-    use solana::cluster_info::FULLNODE_PORT_RANGE;
-    use solana::local_cluster::{ClusterConfig, LocalCluster};
-    use solana::validator::ValidatorConfig;
-    use solana_client::thin_client::create_client;
-    use solana_drone::drone::run_local_drone;
     use solana_runtime::bank::Bank;
     use solana_runtime::bank_client::BankClient;
     use solana_sdk::client::SyncClient;
     use solana_sdk::fee_calculator::FeeCalculator;
     use solana_sdk::genesis_block::create_genesis_block;
-    use std::sync::mpsc::channel;
 
     #[test]
     fn test_switch_directions() {
@@ -675,47 +953,6 @@ mod tests {
         assert_eq!(should_switch_directions(20, 101), false);
     }
 
-    #[test]
-    fn test_bench_tps_local_cluster() {
-        solana_logger::setup();
-        const NUM_NODES: usize = 1;
-        let cluster = LocalCluster::new(&ClusterConfig {
-            node_stakes: vec![999_990; NUM_NODES],
-            cluster_lamports: 2_000_000,
-            validator_configs: vec![ValidatorConfig::default(); NUM_NODES],
-            ..ClusterConfig::default()
-        });
-
-        let drone_keypair = Keypair::new();
-        cluster.transfer(&cluster.funding_keypair, &drone_keypair.pubkey(), 1_000_000);
-
-        let (addr_sender, addr_receiver) = channel();
-        run_local_drone(drone_keypair, addr_sender, None);
-        let drone_addr = addr_receiver.recv_timeout(Duration::from_secs(2)).unwrap();
-
-        let mut config = Config::default();
-        config.tx_count = 100;
-        config.duration = Duration::from_secs(5);
-
-        let client = create_client(
-            (cluster.entry_point_info.rpc, cluster.entry_point_info.tpu),
-            FULLNODE_PORT_RANGE,
-        );
-
-        let lamports_per_account = 100;
-        let (keypairs, _keypair_balance) = generate_and_fund_keypairs(
-            &client,
-            Some(drone_addr),
-            &config.id,
-            config.tx_count,
-            lamports_per_account,
-        )
-        .unwrap();
-
-        let total = do_bench_tps(vec![client], config, keypairs, 0);
-        assert!(total > 100);
-    }
-
     #[test]
     fn test_bench_tps_bank_client() {
         let (genesis_block, id) = create_genesis_block(10_000);
@@ -727,10 +964,11 @@ mod tests {
         config.tx_count = 10;
         config.duration = Duration::from_secs(5);
 
-        let (keypairs, _keypair_balance) =
-            generate_and_fund_keypairs(&clients[0], None, &config.id, config.tx_count, 20).unwrap();
+        let (keypairs, _move_keypairs, _keypair_balance) =
+            generate_and_fund_keypairs(&clients[0], None, &config.id, config.tx_count, 20, false)
+                .unwrap();
 
-        do_bench_tps(clients, config, keypairs, 0);
+        do_bench_tps(clients, config, keypairs, 0, None);
     }
 
     #[test]
@@ -741,8 +979,8 @@ mod tests {
         let tx_count = 10;
         let lamports = 20;
 
-        let (keypairs, _keypair_balance) =
-            generate_and_fund_keypairs(&client, None, &id, tx_count, lamports).unwrap();
+        let (keypairs, _move_keypairs, _keypair_balance) =
+            generate_and_fund_keypairs(&client, None, &id, tx_count, lamports, false).unwrap();
 
         for kp in &keypairs {
             assert_eq!(client.get_balance(&kp.pubkey()).unwrap(), lamports);
@@ -759,8 +997,8 @@ mod tests {
         let tx_count = 10;
         let lamports = 20;
 
-        let (keypairs, _keypair_balance) =
-            generate_and_fund_keypairs(&client, None, &id, tx_count, lamports).unwrap();
+        let (keypairs, _move_keypairs, _keypair_balance) =
+            generate_and_fund_keypairs(&client, None, &id, tx_count, lamports, false).unwrap();
 
         let max_fee = client
             .get_recent_blockhash()

bench-tps/src/cli.rs

@@ -7,6 +7,8 @@ use solana_drone::drone::DRONE_PORT;
 use solana_sdk::fee_calculator::FeeCalculator;
 use solana_sdk::signature::{read_keypair, Keypair, KeypairUtil};
 
+const NUM_LAMPORTS_PER_ACCOUNT_DEFAULT: u64 = 64 * 1024;
+
 /// Holds the configuration for a single run of the benchmark
 pub struct Config {
     pub entrypoint_addr: SocketAddr,
@@ -22,6 +24,8 @@ pub struct Config {
     pub write_to_client_file: bool,
     pub read_from_client_file: bool,
     pub target_lamports_per_signature: u64,
+    pub use_move: bool,
+    pub num_lamports_per_account: u64,
 }
 
 impl Default for Config {
@@ -40,6 +44,8 @@ impl Default for Config {
             write_to_client_file: false,
             read_from_client_file: false,
             target_lamports_per_signature: FeeCalculator::default().target_lamports_per_signature,
+            use_move: false,
+            num_lamports_per_account: NUM_LAMPORTS_PER_ACCOUNT_DEFAULT,
         }
     }
 }
@@ -100,6 +106,11 @@ pub fn build_args<'a, 'b>() -> App<'a, 'b> {
                 .long("sustained")
                 .help("Use sustained performance mode vs. peak mode. This overlaps the tx generation with transfers."),
         )
+        .arg(
+            Arg::with_name("use-move")
+                .long("use-move")
+                .help("Use Move language transactions to perform transfers."),
+        )
         .arg(
             Arg::with_name("tx_count")
                 .long("tx_count")
@@ -139,6 +150,15 @@ pub fn build_args<'a, 'b>() -> App<'a, 'b> {
                      verification when the cluster is operating at target-signatures-per-slot",
                 ),
         )
+        .arg(
+            Arg::with_name("num_lamports_per_account")
+                .long("num-lamports-per-account")
+                .value_name("LAMPORTS")
+                .takes_value(true)
+                .help(
+                    "Number of lamports per account.",
+                ),
+        )
 }
 
 /// Parses a clap `ArgMatches` structure into a `Config`
@@ -211,5 +231,11 @@ pub fn extract_args<'a>(matches: &ArgMatches<'a>) -> Config {
         args.target_lamports_per_signature = v.to_string().parse().expect("can't parse lamports");
     }
 
+    args.use_move = matches.is_present("use-move");
+
+    if let Some(v) = matches.value_of("num_lamports_per_account") {
+        args.num_lamports_per_account = v.to_string().parse().expect("can't parse lamports");
+    }
+
     args
 }

bench-tps/src/lib.rs

@@ -0,0 +1,2 @@
+pub mod bench;
+pub mod cli;

bench-tps/src/main.rs

@@ -1,12 +1,10 @@
-mod bench;
-mod cli;
-
-use crate::bench::{
-    do_bench_tps, generate_and_fund_keypairs, generate_keypairs, Config, NUM_LAMPORTS_PER_ACCOUNT,
-};
-use solana::gossip_service::{discover_cluster, get_multi_client};
+use solana_bench_tps::bench::{do_bench_tps, generate_and_fund_keypairs, generate_keypairs};
+use solana_bench_tps::cli;
+use solana_core::gossip_service::{discover_cluster, get_multi_client};
+use solana_genesis::PrimordialAccountDetails;
 use solana_sdk::fee_calculator::FeeCalculator;
 use solana_sdk::signature::{Keypair, KeypairUtil};
+use solana_sdk::system_program;
 use std::collections::HashMap;
 use std::fs::File;
 use std::io::prelude::*;
@@ -17,7 +15,7 @@ use std::process::exit;
 pub const NUM_SIGNATURES_FOR_TXS: u64 = 100_000 * 60 * 60 * 24 * 7;
 
 fn main() {
-    solana_logger::setup();
+    solana_logger::setup_with_filter("solana=info");
     solana_metrics::set_panic_hook("bench-tps");
 
     let matches = cli::build_args().get_matches();
@@ -27,30 +25,34 @@ fn main() {
         entrypoint_addr,
         drone_addr,
         id,
-        threads,
         num_nodes,
-        duration,
         tx_count,
-        thread_batch_sleep_ms,
-        sustained,
         client_ids_and_stake_file,
         write_to_client_file,
         read_from_client_file,
         target_lamports_per_signature,
-    } = cli_config;
+        use_move,
+        num_lamports_per_account,
+        ..
+    } = &cli_config;
 
-    if write_to_client_file {
-        let (keypairs, _) = generate_keypairs(&id, tx_count as u64 * 2);
+    if *write_to_client_file {
+        let (keypairs, _) = generate_keypairs(&id, *tx_count as u64 * 2);
         let num_accounts = keypairs.len() as u64;
-        let max_fee = FeeCalculator::new(target_lamports_per_signature).max_lamports_per_signature;
+        let max_fee = FeeCalculator::new(*target_lamports_per_signature).max_lamports_per_signature;
         let num_lamports_per_account = (num_accounts - 1 + NUM_SIGNATURES_FOR_TXS * max_fee)
             / num_accounts
-            + NUM_LAMPORTS_PER_ACCOUNT;
+            + num_lamports_per_account;
         let mut accounts = HashMap::new();
         keypairs.iter().for_each(|keypair| {
             accounts.insert(
                 serde_json::to_string(&keypair.to_bytes().to_vec()).unwrap(),
-                num_lamports_per_account,
+                PrimordialAccountDetails {
+                    balance: num_lamports_per_account,
+                    executable: false,
+                    owner: system_program::id().to_string(),
+                    data: String::new(),
+                },
             );
         });
 
@@ -63,7 +65,7 @@ fn main() {
 
     println!("Connecting to the cluster");
     let (nodes, _replicators) =
-        discover_cluster(&entrypoint_addr, num_nodes).unwrap_or_else(|err| {
+        discover_cluster(&entrypoint_addr, *num_nodes).unwrap_or_else(|err| {
             eprintln!("Failed to discover {} nodes: {:?}", num_nodes, err);
             exit(1);
         });
@@ -78,31 +80,35 @@ fn main() {
         exit(1);
     }
 
-    let (keypairs, keypair_balance) = if read_from_client_file {
+    let (keypairs, move_keypairs, keypair_balance) = if *read_from_client_file && !use_move {
         let path = Path::new(&client_ids_and_stake_file);
         let file = File::open(path).unwrap();
 
-        let accounts: HashMap<String, u64> = serde_yaml::from_reader(file).unwrap();
+        let accounts: HashMap<String, PrimordialAccountDetails> =
+            serde_yaml::from_reader(file).unwrap();
         let mut keypairs = vec![];
         let mut last_balance = 0;
 
-        accounts.into_iter().for_each(|(keypair, balance)| {
-            let bytes: Vec<u8> = serde_json::from_str(keypair.as_str()).unwrap();
-            keypairs.push(Keypair::from_bytes(&bytes).unwrap());
-            last_balance = balance;
-        });
+        accounts
+            .into_iter()
+            .for_each(|(keypair, primordial_account)| {
+                let bytes: Vec<u8> = serde_json::from_str(keypair.as_str()).unwrap();
+                keypairs.push(Keypair::from_bytes(&bytes).unwrap());
+                last_balance = primordial_account.balance;
+            });
         // Sort keypairs so that do_bench_tps() uses the same subset of accounts for each run.
         // This prevents the amount of storage needed for bench-tps accounts from creeping up
         // across multiple runs.
         keypairs.sort_by(|x, y| x.pubkey().to_string().cmp(&y.pubkey().to_string()));
-        (keypairs, last_balance)
+        (keypairs, None, last_balance)
     } else {
         generate_and_fund_keypairs(
             &client,
-            Some(drone_addr),
+            Some(*drone_addr),
             &id,
-            tx_count,
-            NUM_LAMPORTS_PER_ACCOUNT,
+            *tx_count,
+            *num_lamports_per_account,
+            *use_move,
         )
         .unwrap_or_else(|e| {
             eprintln!("Error could not fund keys: {:?}", e);
@@ -110,14 +116,11 @@ fn main() {
         })
     };
 
-    let config = Config {
-        id,
-        threads,
-        thread_batch_sleep_ms,
-        duration,
-        tx_count,
-        sustained,
-    };
-
-    do_bench_tps(vec![client], config, keypairs, keypair_balance);
+    do_bench_tps(
+        vec![client],
+        cli_config,
+        keypairs,
+        keypair_balance,
+        move_keypairs,
+    );
 }

book/build-svg.sh

@@ -0,0 +1,11 @@
+#!/usr/bin/env bash
+set -e
+
+cd "$(dirname "$0")"
+
+make -j"$(nproc)" -B svg 
+
+if [[ -n $CI ]]; then
+  # In CI confirm that no svgs need to be built 
+  git diff --exit-code
+fi

book/makefile

@@ -2,13 +2,15 @@ BOB_SRCS=$(wildcard art/*.bob)
 MSC_SRCS=$(wildcard art/*.msc)
 MD_SRCS=$(wildcard src/*.md)
 
-SVG_IMGS=$(BOB_SRCS:art/%.bob=src/img/%.svg) $(MSC_SRCS:art/%.msc=src/img/%.svg)
+SVG_IMGS=$(BOB_SRCS:art/%.bob=src/.gitbook/assets/%.svg) $(MSC_SRCS:art/%.msc=src/.gitbook/assets/%.svg)
 
 TARGET=html/index.html
 TEST_STAMP=src/tests.ok
 
 all: $(TARGET)
 
+svg: $(SVG_IMGS)
+
 test: $(TEST_STAMP)
 
 open: $(TEST_STAMP)
@@ -17,11 +19,11 @@ open: $(TEST_STAMP)
 watch: $(SVG_IMGS)
 	mdbook watch
 
-src/img/%.svg: art/%.bob
+src/.gitbook/assets/%.svg: art/%.bob
 	@mkdir -p $(@D)
 	svgbob < $< > $@
 
- src/img/%.svg: art/%.msc
+src/.gitbook/assets/%.svg: art/%.msc
 	@mkdir -p $(@D)
 	mscgen -T svg -i $< -o $@
 

book/src/.gitbook/assets/data-plane-fanout.svg

@@ -0,0 +1,183 @@
+<svg class="bob" font-family="arial" font-size="14" height="304" width="544" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="304" width="544" x="0" y="0"/>
+<g>
+<line x1="4" x2="4" y1="8" y2="184"/>
+<line x1="4" x2="540" y1="8" y2="8"/>
+<line x1="4" x2="540" y1="184" y2="184"/>
+<line x1="540" x2="540" y1="8" y2="184"/>
+</g>
+<g>
+<line x1="28" x2="28" y1="232" y2="296"/>
+<line x1="28" x2="108" y1="232" y2="232"/>
+<line x1="28" x2="196" y1="296" y2="296"/>
+<line x1="108" x2="164" y1="232" y2="232"/>
+<line x1="164" x2="196" y1="232" y2="232"/>
+<line x1="196" x2="196" y1="232" y2="296"/>
+</g>
+<g>
+<line x1="36" x2="36" y1="40" y2="104"/>
+<line x1="36" x2="180" y1="40" y2="40"/>
+<line x1="36" x2="108" y1="104" y2="104"/>
+<line x1="108" x2="108" y1="104" y2="176"/>
+<line x1="108" x2="124" y1="104" y2="104"/>
+<line x1="124" x2="124" y1="104" y2="136"/>
+<line x1="124" x2="180" y1="104" y2="104"/>
+<line x1="124" x2="364" y1="136" y2="136"/>
+<line x1="180" x2="180" y1="40" y2="56"/>
+<line x1="180" x2="180" y1="56" y2="88"/>
+<line marker-end="url(#triangle)" x1="180" x2="356" y1="56" y2="56"/>
+<line x1="180" x2="180" y1="88" y2="104"/>
+<line x1="180" x2="184" y1="88" y2="88"/>
+<line x1="364" x2="364" y1="136" y2="152"/>
+<line x1="364" x2="364" y1="152" y2="176"/>
+<line x1="364" x2="420" y1="152" y2="152"/>
+<line x1="420" x2="420" y1="104" y2="152"/>
+<line x1="420" x2="436" y1="104" y2="104"/>
+<line x1="436" x2="436" y1="104" y2="176"/>
+<line x1="436" x2="508" y1="104" y2="104"/>
+<line x1="508" x2="508" y1="40" y2="104"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="108" x2="108" y1="192" y2="220"/>
+</g>
+<g>
+<line x1="164" x2="164" y1="152" y2="176"/>
+<line x1="164" x2="364" y1="152" y2="152"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="164" x2="164" y1="192" y2="220"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="192" x2="188" y1="88" y2="88"/>
+<line x1="192" x2="364" y1="88" y2="88"/>
+<line x1="364" x2="364" y1="56" y2="88"/>
+<line x1="364" x2="364" y1="88" y2="104"/>
+<line x1="364" x2="420" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="348" x2="348" y1="232" y2="296"/>
+<line x1="348" x2="364" y1="232" y2="232"/>
+<line x1="348" x2="516" y1="296" y2="296"/>
+<line x1="364" x2="436" y1="232" y2="232"/>
+<line x1="436" x2="516" y1="232" y2="232"/>
+<line x1="516" x2="516" y1="232" y2="296"/>
+</g>
+<g>
+<line x1="364" x2="364" y1="40" y2="56"/>
+<line x1="364" x2="508" y1="40" y2="40"/>
+<line x1="364" x2="360" y1="56" y2="56"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="364" x2="364" y1="192" y2="220"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="436" x2="436" y1="192" y2="220"/>
+</g>
+<g>
+<text x="57" y="268">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="65" y="76">
+Validator
+</text>
+</g>
+<g>
+<text x="145" y="76">
+1
+</text>
+</g>
+<g>
+<text x="161" y="268">
+1
+</text>
+</g>
+<g>
+<text x="217" y="44">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="321" y="44">
+0
+</text>
+</g>
+<g>
+<text x="377" y="268">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="393" y="76">
+Validator
+</text>
+</g>
+<g>
+<text x="473" y="76">
+2
+</text>
+</g>
+<g>
+<text x="481" y="268">
+2
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/data-plane-neighborhood.svg

@@ -0,0 +1,322 @@
+<svg class="bob" font-family="arial" font-size="14" height="400" width="856" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="400" width="856" x="0" y="0"/>
+<g>
+<line x1="4" x2="4" y1="8" y2="152"/>
+<line x1="4" x2="852" y1="8" y2="8"/>
+<line x1="4" x2="852" y1="152" y2="152"/>
+<line x1="852" x2="852" y1="8" y2="152"/>
+</g>
+<g>
+<line x1="4" x2="4" y1="248" y2="392"/>
+<line x1="4" x2="852" y1="248" y2="248"/>
+<line x1="4" x2="852" y1="392" y2="392"/>
+<line x1="852" x2="852" y1="248" y2="392"/>
+</g>
+<g>
+<line x1="60" x2="60" y1="56" y2="120"/>
+<line x1="60" x2="196" y1="56" y2="56"/>
+<line x1="60" x2="84" y1="120" y2="120"/>
+<line x1="84" x2="84" y1="120" y2="144"/>
+<line x1="84" x2="196" y1="120" y2="120"/>
+<line x1="196" x2="196" y1="56" y2="72"/>
+<line x1="196" x2="196" y1="72" y2="104"/>
+<line marker-end="url(#triangle)" x1="196" x2="252" y1="72" y2="72"/>
+<line x1="196" x2="196" y1="104" y2="120"/>
+<line x1="196" x2="200" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="60" x2="60" y1="296" y2="360"/>
+<line x1="60" x2="84" y1="296" y2="296"/>
+<line x1="60" x2="196" y1="360" y2="360"/>
+<line x1="84" x2="196" y1="296" y2="296"/>
+<line x1="196" x2="196" y1="296" y2="312"/>
+<line x1="196" x2="196" y1="312" y2="344"/>
+<line marker-end="url(#triangle)" x1="196" x2="252" y1="312" y2="312"/>
+<line x1="196" x2="196" y1="344" y2="360"/>
+<line x1="196" x2="200" y1="344" y2="344"/>
+</g>
+<g>
+<line x1="84" x2="84" y1="160" y2="240"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="84" x2="84" y1="256" y2="284"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="208" x2="204" y1="104" y2="104"/>
+<line x1="208" x2="260" y1="104" y2="104"/>
+<line x1="260" x2="260" y1="72" y2="104"/>
+<line x1="260" x2="260" y1="104" y2="120"/>
+<line x1="260" x2="284" y1="120" y2="120"/>
+<line x1="284" x2="284" y1="120" y2="144"/>
+<line x1="284" x2="396" y1="120" y2="120"/>
+<line x1="396" x2="396" y1="104" y2="120"/>
+<line x1="396" x2="400" y1="104" y2="104"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="208" x2="204" y1="344" y2="344"/>
+<line x1="208" x2="260" y1="344" y2="344"/>
+<line x1="260" x2="260" y1="312" y2="344"/>
+<line x1="260" x2="260" y1="344" y2="360"/>
+<line x1="260" x2="396" y1="360" y2="360"/>
+<line x1="396" x2="396" y1="344" y2="360"/>
+<line x1="396" x2="400" y1="344" y2="344"/>
+</g>
+<g>
+<line x1="260" x2="260" y1="56" y2="72"/>
+<line x1="260" x2="396" y1="56" y2="56"/>
+<line x1="260" x2="256" y1="72" y2="72"/>
+<line x1="396" x2="396" y1="56" y2="72"/>
+<line x1="396" x2="396" y1="72" y2="104"/>
+<line marker-end="url(#triangle)" x1="396" x2="452" y1="72" y2="72"/>
+</g>
+<g>
+<line x1="260" x2="260" y1="296" y2="312"/>
+<line x1="260" x2="284" y1="296" y2="296"/>
+<line x1="260" x2="256" y1="312" y2="312"/>
+<line x1="284" x2="396" y1="296" y2="296"/>
+<line x1="396" x2="396" y1="296" y2="312"/>
+<line x1="396" x2="396" y1="312" y2="344"/>
+<line marker-end="url(#triangle)" x1="396" x2="452" y1="312" y2="312"/>
+</g>
+<g>
+<line x1="284" x2="284" y1="160" y2="240"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="284" x2="284" y1="256" y2="284"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="408" x2="404" y1="104" y2="104"/>
+<line x1="408" x2="460" y1="104" y2="104"/>
+<line x1="460" x2="460" y1="72" y2="104"/>
+<line x1="460" x2="460" y1="104" y2="120"/>
+<line x1="460" x2="508" y1="120" y2="120"/>
+<line x1="508" x2="508" y1="120" y2="144"/>
+<line x1="508" x2="596" y1="120" y2="120"/>
+<line x1="596" x2="596" y1="104" y2="120"/>
+<line x1="596" x2="600" y1="104" y2="104"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="408" x2="404" y1="344" y2="344"/>
+<line x1="408" x2="460" y1="344" y2="344"/>
+<line x1="460" x2="460" y1="312" y2="344"/>
+<line x1="460" x2="460" y1="344" y2="360"/>
+<line x1="460" x2="596" y1="360" y2="360"/>
+<line x1="596" x2="596" y1="344" y2="360"/>
+<line x1="596" x2="600" y1="344" y2="344"/>
+</g>
+<g>
+<line x1="460" x2="460" y1="56" y2="72"/>
+<line x1="460" x2="596" y1="56" y2="56"/>
+<line x1="460" x2="456" y1="72" y2="72"/>
+<line x1="596" x2="596" y1="56" y2="72"/>
+<line x1="596" x2="596" y1="72" y2="104"/>
+<line marker-end="url(#triangle)" x1="596" x2="652" y1="72" y2="72"/>
+</g>
+<g>
+<line x1="460" x2="460" y1="296" y2="312"/>
+<line x1="460" x2="508" y1="296" y2="296"/>
+<line x1="460" x2="456" y1="312" y2="312"/>
+<line x1="508" x2="596" y1="296" y2="296"/>
+<line x1="596" x2="596" y1="296" y2="312"/>
+<line x1="596" x2="596" y1="312" y2="344"/>
+<line marker-end="url(#triangle)" x1="596" x2="652" y1="312" y2="312"/>
+</g>
+<g>
+<line x1="508" x2="508" y1="160" y2="240"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="508" x2="508" y1="256" y2="284"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="608" x2="604" y1="104" y2="104"/>
+<line x1="608" x2="660" y1="104" y2="104"/>
+<line x1="660" x2="660" y1="72" y2="104"/>
+<line x1="660" x2="660" y1="104" y2="120"/>
+<line x1="660" x2="684" y1="120" y2="120"/>
+<line x1="684" x2="684" y1="120" y2="144"/>
+<line x1="684" x2="796" y1="120" y2="120"/>
+<line x1="796" x2="796" y1="56" y2="120"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="608" x2="604" y1="344" y2="344"/>
+<line x1="608" x2="660" y1="344" y2="344"/>
+<line x1="660" x2="660" y1="312" y2="344"/>
+<line x1="660" x2="660" y1="344" y2="360"/>
+<line x1="660" x2="796" y1="360" y2="360"/>
+<line x1="796" x2="796" y1="296" y2="360"/>
+</g>
+<g>
+<line x1="660" x2="660" y1="56" y2="72"/>
+<line x1="660" x2="796" y1="56" y2="56"/>
+<line x1="660" x2="656" y1="72" y2="72"/>
+</g>
+<g>
+<line x1="660" x2="660" y1="296" y2="312"/>
+<line x1="660" x2="684" y1="296" y2="296"/>
+<line x1="660" x2="656" y1="312" y2="312"/>
+<line x1="684" x2="796" y1="296" y2="296"/>
+</g>
+<g>
+<line x1="684" x2="684" y1="160" y2="240"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="684" x2="684" y1="256" y2="284"/>
+</g>
+<g>
+<text x="89" y="92">
+Neighbor
+</text>
+</g>
+<g>
+<text x="89" y="332">
+Neighbor
+</text>
+</g>
+<g>
+<text x="161" y="92">
+1
+</text>
+</g>
+<g>
+<text x="161" y="332">
+1
+</text>
+</g>
+<g>
+<text x="289" y="92">
+Neighbor
+</text>
+</g>
+<g>
+<text x="289" y="332">
+Neighbor
+</text>
+</g>
+<g>
+<text x="353" y="28">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="353" y="268">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="361" y="92">
+2
+</text>
+</g>
+<g>
+<text x="361" y="332">
+2
+</text>
+</g>
+<g>
+<text x="457" y="28">
+Above
+</text>
+</g>
+<g>
+<text x="457" y="268">
+Below
+</text>
+</g>
+<g>
+<text x="489" y="92">
+Neighbor
+</text>
+</g>
+<g>
+<text x="489" y="332">
+Neighbor
+</text>
+</g>
+<g>
+<text x="561" y="92">
+3
+</text>
+</g>
+<g>
+<text x="561" y="332">
+3
+</text>
+</g>
+<g>
+<text x="689" y="92">
+Neighbor
+</text>
+</g>
+<g>
+<text x="689" y="332">
+Neighbor
+</text>
+</g>
+<g>
+<text x="761" y="92">
+4
+</text>
+</g>
+<g>
+<text x="761" y="332">
+4
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/data-plane-seeding.svg

@@ -0,0 +1,138 @@
+<svg class="bob" font-family="arial" font-size="14" height="240" width="544" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="240" width="544" x="0" y="0"/>
+<g>
+<line x1="4" x2="4" y1="104" y2="232"/>
+<line x1="4" x2="108" y1="104" y2="104"/>
+<line x1="4" x2="540" y1="232" y2="232"/>
+<line x1="108" x2="436" y1="104" y2="104"/>
+<line x1="436" x2="540" y1="104" y2="104"/>
+<line x1="540" x2="540" y1="104" y2="232"/>
+</g>
+<g>
+<line x1="36" x2="36" y1="136" y2="200"/>
+<line x1="36" x2="180" y1="136" y2="136"/>
+<line x1="36" x2="180" y1="200" y2="200"/>
+<line x1="180" x2="180" y1="136" y2="152"/>
+<line x1="180" x2="180" y1="152" y2="184"/>
+<line marker-end="url(#triangle)" x1="180" x2="356" y1="152" y2="152"/>
+<line x1="180" x2="180" y1="184" y2="200"/>
+<line x1="180" x2="184" y1="184" y2="184"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="108" x2="108" y1="40" y2="92"/>
+<line x1="108" x2="212" y1="40" y2="40"/>
+<line x1="212" x2="212" y1="8" y2="40"/>
+<line x1="212" x2="332" y1="8" y2="8"/>
+<line x1="212" x2="212" y1="40" y2="72"/>
+<line x1="212" x2="332" y1="72" y2="72"/>
+<line x1="332" x2="332" y1="8" y2="40"/>
+<line x1="332" x2="332" y1="40" y2="72"/>
+<line x1="332" x2="436" y1="40" y2="40"/>
+<line marker-end="url(#triangle)" x1="436" x2="436" y1="40" y2="92"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="192" x2="188" y1="184" y2="184"/>
+<line x1="192" x2="364" y1="184" y2="184"/>
+<line x1="364" x2="364" y1="152" y2="184"/>
+<line x1="364" x2="364" y1="184" y2="200"/>
+<line x1="364" x2="508" y1="200" y2="200"/>
+<line x1="508" x2="508" y1="136" y2="200"/>
+</g>
+<g>
+<line x1="364" x2="364" y1="136" y2="152"/>
+<line x1="364" x2="508" y1="136" y2="136"/>
+<line x1="364" x2="360" y1="152" y2="152"/>
+</g>
+<g>
+<text x="65" y="172">
+Validator
+</text>
+</g>
+<g>
+<text x="145" y="172">
+1
+</text>
+</g>
+<g>
+<text x="217" y="140">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="249" y="44">
+Leader
+</text>
+</g>
+<g>
+<text x="321" y="140">
+0
+</text>
+</g>
+<g>
+<text x="393" y="172">
+Validator
+</text>
+</g>
+<g>
+<text x="473" y="172">
+2
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/data-plane.svg

@@ -0,0 +1,192 @@
+<svg class="bob" font-family="arial" font-size="14" height="288" width="736" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="288" width="736" x="0" y="0"/>
+<g>
+<line x1="4" x2="4" y1="216" y2="280"/>
+<line x1="4" x2="156" y1="216" y2="216"/>
+<line x1="4" x2="172" y1="280" y2="280"/>
+<line x1="156" x2="172" y1="216" y2="216"/>
+<line x1="172" x2="172" y1="216" y2="280"/>
+</g>
+<g>
+<line x1="124" x2="124" y1="104" y2="168"/>
+<line x1="124" x2="204" y1="104" y2="104"/>
+<line x1="124" x2="156" y1="168" y2="168"/>
+<line marker-end="url(#triangle)" x1="156" x2="156" y1="168" y2="204"/>
+<line x1="156" x2="204" y1="168" y2="168"/>
+<line x1="204" x2="292" y1="104" y2="104"/>
+<line marker-end="url(#triangle)" x1="204" x2="204" y1="168" y2="204"/>
+<line x1="204" x2="292" y1="168" y2="168"/>
+<line x1="292" x2="292" y1="104" y2="168"/>
+</g>
+<g>
+<line x1="188" x2="188" y1="216" y2="280"/>
+<line x1="188" x2="204" y1="216" y2="216"/>
+<line x1="188" x2="356" y1="280" y2="280"/>
+<line x1="204" x2="356" y1="216" y2="216"/>
+<line x1="356" x2="356" y1="216" y2="280"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="204" x2="204" y1="40" y2="92"/>
+<line x1="204" x2="276" y1="40" y2="40"/>
+<line x1="276" x2="276" y1="8" y2="40"/>
+<line x1="276" x2="444" y1="8" y2="8"/>
+<line x1="276" x2="276" y1="40" y2="72"/>
+<line x1="276" x2="444" y1="72" y2="72"/>
+<line x1="444" x2="444" y1="8" y2="40"/>
+<line x1="444" x2="444" y1="40" y2="72"/>
+<line x1="444" x2="532" y1="40" y2="40"/>
+<line marker-end="url(#triangle)" x1="532" x2="532" y1="40" y2="92"/>
+</g>
+<g>
+<line x1="380" x2="380" y1="216" y2="280"/>
+<line x1="380" x2="532" y1="216" y2="216"/>
+<line x1="380" x2="548" y1="280" y2="280"/>
+<line x1="532" x2="548" y1="216" y2="216"/>
+<line x1="548" x2="548" y1="216" y2="280"/>
+</g>
+<g>
+<line x1="444" x2="444" y1="104" y2="168"/>
+<line x1="444" x2="532" y1="104" y2="104"/>
+<line x1="444" x2="532" y1="168" y2="168"/>
+<line x1="532" x2="612" y1="104" y2="104"/>
+<line marker-end="url(#triangle)" x1="532" x2="532" y1="168" y2="204"/>
+<line x1="532" x2="580" y1="168" y2="168"/>
+<line marker-end="url(#triangle)" x1="580" x2="580" y1="168" y2="204"/>
+<line x1="580" x2="612" y1="168" y2="168"/>
+<line x1="612" x2="612" y1="104" y2="168"/>
+</g>
+<g>
+<line x1="564" x2="564" y1="216" y2="280"/>
+<line x1="564" x2="580" y1="216" y2="216"/>
+<line x1="564" x2="732" y1="280" y2="280"/>
+<line x1="580" x2="732" y1="216" y2="216"/>
+<line x1="732" x2="732" y1="216" y2="280"/>
+</g>
+<g>
+<text x="33" y="252">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="137" y="252">
+3
+</text>
+</g>
+<g>
+<text x="153" y="140">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="217" y="252">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="257" y="140">
+1
+</text>
+</g>
+<g>
+<text x="305" y="44">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="321" y="252">
+4
+</text>
+</g>
+<g>
+<text x="409" y="44">
+0
+</text>
+</g>
+<g>
+<text x="409" y="252">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="473" y="140">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="513" y="252">
+5
+</text>
+</g>
+<g>
+<text x="577" y="140">
+2
+</text>
+</g>
+<g>
+<text x="593" y="252">
+Neighborhood
+</text>
+</g>
+<g>
+<text x="697" y="252">
+6
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/fork-generation.svg

@@ -0,0 +1,330 @@
+<svg class="bob" font-family="arial" font-size="14" height="208" width="768" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="208" width="768" x="0" y="0"/>
+<g>
+<line marker-end="url(#triangle)" x1="76" x2="76" y1="32" y2="172"/>
+</g>
+<g>
+<line x1="124" x2="124" y1="24" y2="56"/>
+<line x1="124" x2="164" y1="24" y2="24"/>
+<line x1="124" x2="124" y1="56" y2="88"/>
+<line x1="124" x2="164" y1="56" y2="56"/>
+<line x1="124" x2="124" y1="88" y2="120"/>
+<line x1="124" x2="164" y1="88" y2="88"/>
+<line x1="124" x2="124" y1="120" y2="152"/>
+<line x1="124" x2="164" y1="120" y2="120"/>
+<line x1="124" x2="124" y1="152" y2="184"/>
+<line x1="124" x2="164" y1="152" y2="152"/>
+<line x1="124" x2="164" y1="184" y2="184"/>
+<line x1="164" x2="164" y1="24" y2="56"/>
+<line x1="164" x2="164" y1="56" y2="88"/>
+<line x1="164" x2="164" y1="88" y2="120"/>
+<line x1="164" x2="164" y1="120" y2="152"/>
+<line x1="164" x2="164" y1="152" y2="184"/>
+</g>
+<g>
+<line x1="188" x2="188" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="200" x2="208" y1="128" y2="112"/>
+</g>
+<g>
+<line x1="224" x2="236" y1="112" y2="136"/>
+</g>
+<g>
+<line x1="232" x2="240" y1="96" y2="80"/>
+</g>
+<g>
+<line x1="236" x2="236" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="260" x2="260" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="264" x2="272" y1="64" y2="48"/>
+</g>
+<g>
+<line x1="272" x2="280" y1="80" y2="96"/>
+</g>
+<g>
+<line x1="272" x2="280" y1="128" y2="112"/>
+</g>
+<g>
+<line x1="304" x2="316" y1="112" y2="136"/>
+</g>
+<g>
+<line x1="316" x2="316" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="348" x2="360" y1="136" y2="112"/>
+</g>
+<g>
+<line x1="348" x2="348" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="368" x2="376" y1="96" y2="80"/>
+</g>
+<g>
+<line x1="376" x2="384" y1="48" y2="64"/>
+</g>
+<g>
+<line x1="376" x2="388" y1="112" y2="136"/>
+</g>
+<g>
+<line x1="388" x2="388" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="416" x2="424" y1="80" y2="96"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="436" x2="420" y1="104" y2="136"/>
+</g>
+<g>
+<line x1="448" x2="460" y1="112" y2="136"/>
+</g>
+<g>
+<line x1="460" x2="460" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="512" x2="640" y1="24" y2="24"/>
+</g>
+<g>
+<text x="17" y="108">
+time
+</text>
+</g>
+<g>
+<text x="137" y="44">
+L1
+</text>
+</g>
+<g>
+<text x="137" y="76">
+L2
+</text>
+</g>
+<g>
+<text x="137" y="108">
+L3
+</text>
+</g>
+<g>
+<text x="137" y="140">
+L4
+</text>
+</g>
+<g>
+<text x="137" y="172">
+L5
+</text>
+</g>
+<g>
+<text x="185" y="140">
+x
+</text>
+</g>
+<g>
+<text x="185" y="172">
+xx
+</text>
+</g>
+<g>
+<text x="209" y="108">
+E3
+</text>
+</g>
+<g>
+<text x="225" y="172">
+xx
+</text>
+</g>
+<g>
+<text x="249" y="76">
+E2
+</text>
+</g>
+<g>
+<text x="257" y="140">
+E4
+</text>
+</g>
+<g>
+<text x="257" y="172">
+xx
+</text>
+</g>
+<g>
+<text x="289" y="108">
+x
+</text>
+</g>
+<g>
+<text x="305" y="172">
+E5
+</text>
+</g>
+<g>
+<text x="313" y="44">
+E1
+</text>
+</g>
+<g>
+<text x="337" y="172">
+xx
+</text>
+</g>
+<g>
+<text x="361" y="108">
+E3&#39;
+</text>
+</g>
+<g>
+<text x="377" y="172">
+xx
+</text>
+</g>
+<g>
+<text x="393" y="76">
+x
+</text>
+</g>
+<g>
+<text x="409" y="172">
+xx
+</text>
+</g>
+<g>
+<text x="449" y="172">
+xx
+</text>
+</g>
+<g>
+<text x="513" y="12">
+validator
+</text>
+</g>
+<g>
+<text x="513" y="60">
+vote(E1)
+</text>
+</g>
+<g>
+<text x="513" y="92">
+vote(E2)
+</text>
+</g>
+<g>
+<text x="513" y="124">
+slash(E3)
+</text>
+</g>
+<g>
+<text x="513" y="156">
+vote(E4)
+</text>
+</g>
+<g>
+<text x="513" y="188">
+hang
+</text>
+</g>
+<g>
+<text x="553" y="188">
+on
+</text>
+</g>
+<g>
+<text x="577" y="188">
+to
+</text>
+</g>
+<g>
+<text x="593" y="12">
+action
+</text>
+</g>
+<g>
+<text x="601" y="188">
+E4
+</text>
+</g>
+<g>
+<text x="625" y="188">
+and
+</text>
+</g>
+<g>
+<text x="657" y="188">
+E5
+</text>
+</g>
+<g>
+<text x="681" y="188">
+for
+</text>
+</g>
+<g>
+<text x="713" y="188">
+more...
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/forks-pruned.svg

@@ -0,0 +1,92 @@
+<svg class="bob" font-family="arial" font-size="14" height="144" width="48" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="144" width="48" x="0" y="0"/>
+<g>
+<line x1="20" x2="24" y1="88" y2="80"/>
+<line x1="20" x2="20" y1="96" y2="88"/>
+<line x1="20" x2="20" y1="96" y2="128"/>
+<line x1="24" x2="40" y1="80" y2="48"/>
+</g>
+<g>
+<line x1="44" x2="44" y1="16" y2="32"/>
+</g>
+<g>
+<line x1="44" x2="44" y1="48" y2="96"/>
+</g>
+<g>
+<text x="17" y="140">
+5
+</text>
+</g>
+<g>
+<text x="41" y="12">
+1
+</text>
+</g>
+<g>
+<text x="41" y="44">
+2
+</text>
+</g>
+<g>
+<text x="41" y="108">
+4
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/forks-pruned2.svg

@@ -0,0 +1,92 @@
+<svg class="bob" font-family="arial" font-size="14" height="176" width="40" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="176" width="40" x="0" y="0"/>
+<g>
+<line x1="12" x2="12" y1="16" y2="32"/>
+</g>
+<g>
+<line x1="12" x2="12" y1="48" y2="128"/>
+</g>
+<g>
+<line x1="16" x2="32" y1="48" y2="80"/>
+<line x1="36" x2="32" y1="88" y2="80"/>
+<line x1="36" x2="36" y1="96" y2="88"/>
+<line x1="36" x2="36" y1="96" y2="160"/>
+</g>
+<g>
+<text x="9" y="12">
+1
+</text>
+</g>
+<g>
+<text x="9" y="44">
+3
+</text>
+</g>
+<g>
+<text x="9" y="140">
+6
+</text>
+</g>
+<g>
+<text x="33" y="172">
+7
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/forks.svg

@@ -0,0 +1,122 @@
+<svg class="bob" font-family="arial" font-size="14" height="208" width="96" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="208" width="96" x="0" y="0"/>
+<g>
+<line x1="20" x2="24" y1="88" y2="80"/>
+<line x1="20" x2="20" y1="96" y2="88"/>
+<line x1="20" x2="20" y1="96" y2="128"/>
+<line x1="24" x2="40" y1="80" y2="48"/>
+</g>
+<g>
+<line x1="44" x2="44" y1="16" y2="32"/>
+</g>
+<g>
+<line x1="44" x2="44" y1="48" y2="96"/>
+</g>
+<g>
+<line x1="48" x2="64" y1="16" y2="48"/>
+<line x1="68" x2="64" y1="56" y2="48"/>
+<line x1="68" x2="68" y1="64" y2="56"/>
+</g>
+<g>
+<line x1="68" x2="68" y1="80" y2="160"/>
+</g>
+<g>
+<line x1="72" x2="80" y1="80" y2="96"/>
+<line x1="80" x2="88" y1="96" y2="112"/>
+<line x1="92" x2="88" y1="120" y2="112"/>
+<line x1="92" x2="92" y1="128" y2="120"/>
+<line x1="92" x2="92" y1="128" y2="192"/>
+</g>
+<g>
+<text x="17" y="140">
+5
+</text>
+</g>
+<g>
+<text x="41" y="12">
+1
+</text>
+</g>
+<g>
+<text x="41" y="44">
+2
+</text>
+</g>
+<g>
+<text x="41" y="108">
+4
+</text>
+</g>
+<g>
+<text x="65" y="76">
+3
+</text>
+</g>
+<g>
+<text x="65" y="172">
+6
+</text>
+</g>
+<g>
+<text x="89" y="204">
+7
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/passive-staking-callflow.svg

@@ -0,0 +1,238 @@
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
+ "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg version="1.1"
+ width="1320px" height="487px"
+ viewBox="0 0 1320 487"
+ xmlns="http://www.w3.org/2000/svg" shape-rendering="crispEdges"
+ stroke-width="1" text-rendering="geometricPrecision">
+<polygon fill="white" points="101,7 161,7 161,16 101,16"/>
+<text x="132" y="16" textLength="59" font-family="Helvetica" font-size="12" fill="black" text-anchor="middle">
+
+VoteSigner
+</text>
+<polygon fill="white" points="371,7 419,7 419,16 371,16"/>
+<text x="396" y="16" textLength="47" font-family="Helvetica" font-size="12" fill="black" text-anchor="middle">
+
+Validator
+</text>
+<polygon fill="white" points="639,7 679,7 679,16 639,16"/>
+<text x="660" y="16" textLength="38" font-family="Helvetica" font-size="12" fill="black" text-anchor="middle">
+
+Cluster
+</text>
+<polygon fill="white" points="901,7 945,7 945,16 901,16"/>
+<text x="924" y="16" textLength="43" font-family="Helvetica" font-size="12" fill="black" text-anchor="middle">
+
+StakerX
+</text>
+<polygon fill="white" points="1165,7 1209,7 1209,16 1165,16"/>
+<text x="1188" y="16" textLength="43" font-family="Helvetica" font-size="12" fill="black" text-anchor="middle">
+
+StakerY
+</text>
+<line x1="132" y1="22" x2="132" y2="39" stroke="black"/>
+<line x1="396" y1="22" x2="396" y2="39" stroke="black"/>
+<line x1="660" y1="22" x2="660" y2="39" stroke="black"/>
+<line x1="924" y1="22" x2="924" y2="39" stroke="black"/>
+<line x1="1188" y1="22" x2="1188" y2="39" stroke="black"/>
+<line x1="132" y1="39" x2="132" y2="67" stroke="black"/>
+<line x1="396" y1="39" x2="396" y2="67" stroke="black"/>
+<line x1="660" y1="39" x2="660" y2="67" stroke="black"/>
+<line x1="924" y1="39" x2="924" y2="67" stroke="black"/>
+<line x1="1188" y1="39" x2="1188" y2="67" stroke="black"/>
+<polygon fill="white" points="272,39 520,39 520,61 272,61"/>
+<line x1="272" y1="39" x2="520" y2="39" stroke="black"/>
+<line x1="272" y1="61" x2="520" y2="61" stroke="black"/>
+<line x1="272" y1="39" x2="272" y2="61" stroke="black"/>
+<line x1="520" y1="39" x2="520" y2="61" stroke="black"/>
+<polygon fill="white" points="379,46 411,46 411,55 379,55"/>
+<text x="380" y="55" textLength="30" font-family="Helvetica" font-size="12" fill="black">
+boot..
+</text>
+<line x1="132" y1="67" x2="132" y2="106" stroke="black"/>
+<line x1="396" y1="67" x2="396" y2="106" stroke="black"/>
+<line x1="660" y1="67" x2="660" y2="106" stroke="black"/>
+<line x1="924" y1="67" x2="924" y2="106" stroke="black"/>
+<line x1="1188" y1="67" x2="1188" y2="106" stroke="black"/>
+<line x1="132" y1="82" x2="396" y2="82" stroke="black"/>
+<line x1="132" y1="84" x2="396" y2="84" stroke="black"/>
+<polygon fill="black" points="396,83 386,89 386,77"/>
+<polygon fill="black" points="132,83 142,89 142,77"/>
+<polygon fill="white" points="242,68 284,68 284,77 242,77"/>
+<text x="243" y="77" textLength="40" font-family="Helvetica" font-size="12" fill="black">
+register
+</text>
+<polygon fill="white" points="262,79 264,79 264,88 262,88"/>
+<text x="263" y="88" textLength="0" font-family="Helvetica" font-size="12" fill="black">
+
+</text>
+<polygon fill="white" points="237,90 289,90 289,99 237,99"/>
+<text x="238" y="99" textLength="50" font-family="Helvetica" font-size="12" fill="black">
+(optional)
+</text>
+<line x1="132" y1="106" x2="132" y2="134" stroke="black"/>
+<line x1="396" y1="106" x2="396" y2="134" stroke="black"/>
+<line x1="660" y1="106" x2="660" y2="134" stroke="black"/>
+<line x1="924" y1="106" x2="924" y2="134" stroke="black"/>
+<line x1="1188" y1="106" x2="1188" y2="134" stroke="black"/>
+<line x1="396" y1="117" x2="660" y2="117" stroke="black"/>
+<polygon fill="black" points="660,117 650,123 650,111"/>
+<polygon fill="white" points="441,107 613,107 613,116 441,116"/>
+<text x="442" y="116" textLength="170" font-family="Helvetica" font-size="12" fill="black">
+VoteState::Initialize(VoteSigner)
+</text>
+<line x1="132" y1="134" x2="132" y2="162" stroke="black"/>
+<line x1="396" y1="134" x2="396" y2="162" stroke="black"/>
+<line x1="660" y1="134" x2="660" y2="162" stroke="black"/>
+<line x1="924" y1="134" x2="924" y2="162" stroke="black"/>
+<line x1="1188" y1="134" x2="1188" y2="162" stroke="black"/>
+<line x1="924" y1="145" x2="660" y2="145" stroke="black"/>
+<polygon fill="black" points="660,145 670,151 670,139"/>
+<polygon fill="white" points="706,135 877,135 877,144 706,144"/>
+<text x="707" y="144" textLength="169" font-family="Helvetica" font-size="12" fill="black">
+StakeState::Delegate(Validator)
+</text>
+<line x1="132" y1="162" x2="132" y2="190" stroke="black"/>
+<line x1="396" y1="162" x2="396" y2="190" stroke="black"/>
+<line x1="660" y1="162" x2="660" y2="190" stroke="black"/>
+<line x1="924" y1="162" x2="924" y2="190" stroke="black"/>
+<line x1="1188" y1="162" x2="1188" y2="190" stroke="black"/>
+<line x1="1188" y1="173" x2="660" y2="173" stroke="black"/>
+<polygon fill="black" points="660,173 670,179 670,167"/>
+<polygon fill="white" points="838,163 1009,163 1009,172 838,172"/>
+<text x="839" y="172" textLength="169" font-family="Helvetica" font-size="12" fill="black">
+StakeState::Delegate(Validator)
+</text>
+<line x1="132" y1="190" x2="132" y2="207" stroke="black"/>
+<line x1="396" y1="190" x2="396" y2="207" stroke="black"/>
+<line x1="660" y1="190" x2="660" y2="207" stroke="black"/>
+<line x1="924" y1="190" x2="924" y2="207" stroke="black"/>
+<line x1="1188" y1="190" x2="1188" y2="207" stroke="black"/>
+<line x1="132" y1="207" x2="132" y2="246" stroke="black"/>
+<line x1="396" y1="207" x2="396" y2="246" stroke="black"/>
+<line x1="660" y1="207" x2="660" y2="246" stroke="black"/>
+<line x1="924" y1="207" x2="924" y2="246" stroke="black"/>
+<line x1="1188" y1="207" x2="1188" y2="246" stroke="black"/>
+<polygon fill="white" points="272,207 784,207 784,240 272,240"/>
+<line x1="272" y1="207" x2="784" y2="207" stroke="black"/>
+<line x1="272" y1="240" x2="784" y2="240" stroke="black"/>
+<line x1="272" y1="207" x2="272" y2="240" stroke="black"/>
+<line x1="784" y1="207" x2="784" y2="240" stroke="black"/>
+<polygon fill="white" points="526,208 528,208 528,217 526,217"/>
+<text x="527" y="217" textLength="0" font-family="Helvetica" font-size="12" fill="black">
+
+</text>
+<polygon fill="white" points="506,219 549,219 549,228 506,228"/>
+<text x="507" y="228" textLength="41" font-family="Helvetica" font-size="12" fill="black">
+validate
+</text>
+<polygon fill="white" points="526,230 528,230 528,239 526,239"/>
+<text x="527" y="239" textLength="0" font-family="Helvetica" font-size="12" fill="black">
+
+</text>
+<line x1="132" y1="246" x2="132" y2="274" stroke="black"/>
+<line x1="396" y1="246" x2="396" y2="274" stroke="black"/>
+<line x1="660" y1="246" x2="660" y2="274" stroke="black"/>
+<line x1="924" y1="246" x2="924" y2="274" stroke="black"/>
+<line x1="1188" y1="246" x2="1188" y2="274" stroke="black"/>
+<line x1="396" y1="257" x2="132" y2="257" stroke="black"/>
+<polygon fill="black" points="132,257 142,263 142,251"/>
+<polygon fill="white" points="236,247 291,247 291,256 236,256"/>
+<text x="237" y="256" textLength="53" font-family="Helvetica" font-size="12" fill="black">
+sign(vote)
+</text>
+<line x1="132" y1="274" x2="132" y2="302" stroke="black"/>
+<line x1="396" y1="274" x2="396" y2="302" stroke="black"/>
+<line x1="660" y1="274" x2="660" y2="302" stroke="black"/>
+<line x1="924" y1="274" x2="924" y2="302" stroke="black"/>
+<line x1="1188" y1="274" x2="1188" y2="302" stroke="black"/>
+<line x1="132" y1="285" x2="396" y2="285" stroke="black" stroke-dasharray="2,2"/>
+<polygon fill="black" points="396,285 386,291 386,279"/>
+<polygon fill="white" points="232,275 295,275 295,284 232,284"/>
+<text x="233" y="284" textLength="61" font-family="Helvetica" font-size="12" fill="black">
+signed vote
+</text>
+<line x1="132" y1="302" x2="132" y2="330" stroke="black"/>
+<line x1="396" y1="302" x2="396" y2="330" stroke="black"/>
+<line x1="660" y1="302" x2="660" y2="330" stroke="black"/>
+<line x1="924" y1="302" x2="924" y2="330" stroke="black"/>
+<line x1="1188" y1="302" x2="1188" y2="330" stroke="black"/>
+<line x1="396" y1="313" x2="660" y2="313" stroke="black"/>
+<polygon fill="black" points="660,313 650,319 650,307"/>
+<polygon fill="white" points="494,303 561,303 561,312 494,312"/>
+<text x="495" y="312" textLength="65" font-family="Helvetica" font-size="12" fill="black">
+gossip(vote)
+</text>
+<line x1="132" y1="330" x2="132" y2="347" stroke="black" stroke-dasharray="2,2"/>
+<line x1="396" y1="330" x2="396" y2="347" stroke="black" stroke-dasharray="2,2"/>
+<line x1="660" y1="330" x2="660" y2="347" stroke="black" stroke-dasharray="2,2"/>
+<line x1="924" y1="330" x2="924" y2="347" stroke="black" stroke-dasharray="2,2"/>
+<line x1="1188" y1="330" x2="1188" y2="347" stroke="black" stroke-dasharray="2,2"/>
+<line x1="132" y1="347" x2="132" y2="364" stroke="black" stroke-dasharray="2,2"/>
+<line x1="396" y1="347" x2="396" y2="364" stroke="black" stroke-dasharray="2,2"/>
+<line x1="660" y1="347" x2="660" y2="364" stroke="black" stroke-dasharray="2,2"/>
+<line x1="924" y1="347" x2="924" y2="364" stroke="black" stroke-dasharray="2,2"/>
+<line x1="1188" y1="347" x2="1188" y2="364" stroke="black" stroke-dasharray="2,2"/>
+<line x1="132" y1="364" x2="132" y2="414" stroke="black"/>
+<line x1="396" y1="364" x2="396" y2="414" stroke="black"/>
+<line x1="660" y1="364" x2="660" y2="414" stroke="black"/>
+<line x1="924" y1="364" x2="924" y2="414" stroke="black"/>
+<line x1="1188" y1="364" x2="1188" y2="414" stroke="black"/>
+<polygon fill="white" points="278,364 514,364 514,408 278,408"/>
+<polygon fill="white" points="278,364 278,408 272,386"/>
+<polygon fill="white" points="514,364 514,408 520,386"/>
+<line x1="278" y1="364" x2="514" y2="364" stroke="black"/>
+<line x1="278" y1="408" x2="514" y2="408" stroke="black"/>
+<line x1="278" y1="364" x2="272" y2="386" stroke="black"/>
+<line x1="272" y1="386" x2="278" y2="408" stroke="black"/>
+<line x1="514" y1="364" x2="520" y2="386" stroke="black"/>
+<line x1="520" y1="386" x2="514" y2="408" stroke="black"/>
+<polygon fill="white" points="394,365 396,365 396,374 394,374"/>
+<text x="395" y="374" textLength="0" font-family="Helvetica" font-size="12" fill="black">
+
+</text>
+<polygon fill="white" points="383,376 408,376 408,385 383,385"/>
+<text x="384" y="385" textLength="23" font-family="Helvetica" font-size="12" fill="black">
+max
+</text>
+<polygon fill="white" points="375,387 415,387 415,396 375,396"/>
+<text x="376" y="396" textLength="38" font-family="Helvetica" font-size="12" fill="black">
+lockout
+</text>
+<polygon fill="white" points="394,398 396,398 396,407 394,407"/>
+<text x="395" y="407" textLength="0" font-family="Helvetica" font-size="12" fill="black">
+
+</text>
+<line x1="132" y1="414" x2="132" y2="431" stroke="black"/>
+<line x1="396" y1="414" x2="396" y2="431" stroke="black"/>
+<line x1="660" y1="414" x2="660" y2="431" stroke="black"/>
+<line x1="924" y1="414" x2="924" y2="431" stroke="black"/>
+<line x1="1188" y1="414" x2="1188" y2="431" stroke="black"/>
+<line x1="132" y1="431" x2="132" y2="459" stroke="black"/>
+<line x1="396" y1="431" x2="396" y2="459" stroke="black"/>
+<line x1="660" y1="431" x2="660" y2="459" stroke="black"/>
+<line x1="924" y1="431" x2="924" y2="459" stroke="black"/>
+<line x1="1188" y1="431" x2="1188" y2="459" stroke="black"/>
+<line x1="924" y1="442" x2="660" y2="442" stroke="black"/>
+<polygon fill="black" points="660,442 670,448 670,436"/>
+<polygon fill="white" points="712,432 871,432 871,441 712,441"/>
+<text x="713" y="441" textLength="157" font-family="Helvetica" font-size="12" fill="black">
+StakeState::RedeemCredits()
+</text>
+<line x1="132" y1="459" x2="132" y2="487" stroke="black"/>
+<line x1="396" y1="459" x2="396" y2="487" stroke="black"/>
+<line x1="660" y1="459" x2="660" y2="487" stroke="black"/>
+<line x1="924" y1="459" x2="924" y2="487" stroke="black"/>
+<line x1="1188" y1="459" x2="1188" y2="487" stroke="black"/>
+<line x1="1188" y1="470" x2="660" y2="470" stroke="black"/>
+<polygon fill="black" points="660,470 670,476 670,464"/>
+<polygon fill="white" points="844,460 1003,460 1003,469 844,469"/>
+<text x="845" y="469" textLength="157" font-family="Helvetica" font-size="12" fill="black">
+StakeState::RedeemCredits()
+</text>
+<line x1="132" y1="481" x2="132" y2="487" stroke="black"/>
+<line x1="396" y1="481" x2="396" y2="487" stroke="black"/>
+<line x1="660" y1="481" x2="660" y2="487" stroke="black"/>
+<line x1="924" y1="481" x2="924" y2="487" stroke="black"/>
+<line x1="1188" y1="481" x2="1188" y2="487" stroke="black"/>
+</svg>

book/src/.gitbook/assets/runtime.svg

@@ -0,0 +1,346 @@
+<svg class="bob" font-family="arial" font-size="14" height="160" width="848" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="160" width="848" x="0" y="0"/>
+<g>
+<line marker-end="url(#triangle)" x1="0" x2="28" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="4" x2="4" y1="12" y2="52"/>
+<path d="M 4 52 A 4 4 0 0 0 8 56" fill="none"/>
+<path d="M 8 8 A 4 4 0 0 0 4 12" fill="none"/>
+</g>
+<g>
+<line x1="8" x2="104" y1="8" y2="8"/>
+<path d="M 108 12 A 4 4 0 0 0 104 8" fill="none"/>
+</g>
+<g>
+<line x1="8" x2="104" y1="56" y2="56"/>
+<path d="M 104 56 A 4 4 0 0 0 108 52" fill="none"/>
+</g>
+<g>
+<line x1="36" x2="36" y1="92" y2="116"/>
+<path d="M 36 116 A 4 4 0 0 0 40 120" fill="none"/>
+<path d="M 40 88 A 4 4 0 0 0 36 92" fill="none"/>
+</g>
+<g>
+<line x1="40" x2="160" y1="88" y2="88"/>
+<path d="M 164 92 A 4 4 0 0 0 160 88" fill="none"/>
+</g>
+<g>
+<line x1="40" x2="160" y1="120" y2="120"/>
+<path d="M 160 120 A 4 4 0 0 0 164 116" fill="none"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="12" y2="24"/>
+<line x1="108" x2="108" y1="24" y2="52"/>
+<line marker-end="url(#triangle)" x1="108" x2="140" y1="24" y2="24"/>
+</g>
+<g>
+<line x1="156" x2="156" y1="12" y2="36"/>
+<path d="M 156 36 A 4 4 0 0 0 160 40" fill="none"/>
+<path d="M 160 8 A 4 4 0 0 0 156 12" fill="none"/>
+</g>
+<g>
+<line x1="160" x2="248" y1="8" y2="8"/>
+<path d="M 252 12 A 4 4 0 0 0 248 8" fill="none"/>
+</g>
+<g>
+<line x1="160" x2="248" y1="40" y2="40"/>
+<path d="M 248 40 A 4 4 0 0 0 252 36" fill="none"/>
+</g>
+<g>
+<line x1="164" x2="164" y1="92" y2="104"/>
+<line x1="164" x2="164" y1="104" y2="116"/>
+<line marker-end="url(#triangle)" x1="164" x2="196" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="204" x2="204" y1="92" y2="116"/>
+<path d="M 204 116 A 4 4 0 0 0 208 120" fill="none"/>
+<path d="M 208 88 A 4 4 0 0 0 204 92" fill="none"/>
+</g>
+<g>
+<line x1="208" x2="280" y1="88" y2="88"/>
+<path d="M 284 92 A 4 4 0 0 0 280 88" fill="none"/>
+</g>
+<g>
+<line x1="208" x2="280" y1="120" y2="120"/>
+<path d="M 280 120 A 4 4 0 0 0 284 116" fill="none"/>
+</g>
+<g>
+<line x1="252" x2="252" y1="12" y2="24"/>
+<line x1="252" x2="252" y1="24" y2="36"/>
+<line marker-end="url(#triangle)" x1="252" x2="284" y1="24" y2="24"/>
+</g>
+<g>
+<line x1="284" x2="284" y1="92" y2="104"/>
+<line x1="284" x2="284" y1="104" y2="116"/>
+<line marker-end="url(#triangle)" x1="284" x2="316" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="292" x2="292" y1="12" y2="36"/>
+<path d="M 292 36 A 4 4 0 0 0 296 40" fill="none"/>
+<path d="M 296 8 A 4 4 0 0 0 292 12" fill="none"/>
+</g>
+<g>
+<line x1="296" x2="416" y1="8" y2="8"/>
+<path d="M 420 12 A 4 4 0 0 0 416 8" fill="none"/>
+</g>
+<g>
+<line x1="296" x2="416" y1="40" y2="40"/>
+<path d="M 416 40 A 4 4 0 0 0 420 36" fill="none"/>
+</g>
+<g>
+<line x1="324" x2="324" y1="92" y2="132"/>
+<path d="M 324 132 A 4 4 0 0 0 328 136" fill="none"/>
+<path d="M 328 88 A 4 4 0 0 0 324 92" fill="none"/>
+</g>
+<g>
+<line x1="328" x2="424" y1="88" y2="88"/>
+<path d="M 428 92 A 4 4 0 0 0 424 88" fill="none"/>
+</g>
+<g>
+<line x1="328" x2="424" y1="136" y2="136"/>
+<path d="M 424 136 A 4 4 0 0 0 428 132" fill="none"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="12" y2="24"/>
+<line x1="420" x2="420" y1="24" y2="36"/>
+<line marker-end="url(#triangle)" x1="420" x2="452" y1="24" y2="24"/>
+</g>
+<g>
+<line x1="428" x2="428" y1="92" y2="104"/>
+<line x1="428" x2="428" y1="104" y2="132"/>
+<line marker-end="url(#triangle)" x1="428" x2="460" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="460" x2="460" y1="12" y2="36"/>
+<path d="M 460 36 A 4 4 0 0 0 464 40" fill="none"/>
+<path d="M 464 8 A 4 4 0 0 0 460 12" fill="none"/>
+</g>
+<g>
+<line x1="464" x2="576" y1="8" y2="8"/>
+<path d="M 580 12 A 4 4 0 0 0 576 8" fill="none"/>
+</g>
+<g>
+<line x1="464" x2="576" y1="40" y2="40"/>
+<path d="M 576 40 A 4 4 0 0 0 580 36" fill="none"/>
+</g>
+<g>
+<line x1="468" x2="468" y1="92" y2="116"/>
+<path d="M 468 116 A 4 4 0 0 0 472 120" fill="none"/>
+<path d="M 472 88 A 4 4 0 0 0 468 92" fill="none"/>
+</g>
+<g>
+<line x1="472" x2="608" y1="88" y2="88"/>
+<path d="M 612 92 A 4 4 0 0 0 608 88" fill="none"/>
+</g>
+<g>
+<line x1="472" x2="608" y1="120" y2="120"/>
+<path d="M 608 120 A 4 4 0 0 0 612 116" fill="none"/>
+</g>
+<g>
+<line x1="580" x2="580" y1="12" y2="24"/>
+<line x1="580" x2="580" y1="24" y2="36"/>
+<line marker-end="url(#triangle)" x1="580" x2="612" y1="24" y2="24"/>
+</g>
+<g>
+<line x1="612" x2="612" y1="92" y2="104"/>
+<line x1="612" x2="612" y1="104" y2="116"/>
+<line marker-end="url(#triangle)" x1="612" x2="636" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="620" x2="620" y1="12" y2="36"/>
+<path d="M 620 36 A 4 4 0 0 0 624 40" fill="none"/>
+<path d="M 624 8 A 4 4 0 0 0 620 12" fill="none"/>
+</g>
+<g>
+<line x1="624" x2="808" y1="8" y2="8"/>
+<path d="M 812 12 A 4 4 0 0 0 808 8" fill="none"/>
+</g>
+<g>
+<line x1="624" x2="808" y1="40" y2="40"/>
+<path d="M 808 40 A 4 4 0 0 0 812 36" fill="none"/>
+</g>
+<g>
+<line x1="644" x2="644" y1="92" y2="116"/>
+<path d="M 644 116 A 4 4 0 0 0 648 120" fill="none"/>
+<path d="M 648 88 A 4 4 0 0 0 644 92" fill="none"/>
+</g>
+<g>
+<line x1="648" x2="784" y1="88" y2="88"/>
+<path d="M 788 92 A 4 4 0 0 0 784 88" fill="none"/>
+</g>
+<g>
+<line x1="648" x2="784" y1="120" y2="120"/>
+<path d="M 784 120 A 4 4 0 0 0 788 116" fill="none"/>
+</g>
+<g>
+<line x1="788" x2="788" y1="92" y2="116"/>
+</g>
+<g>
+<line x1="812" x2="812" y1="12" y2="24"/>
+<line x1="812" x2="812" y1="24" y2="36"/>
+<line marker-end="url(#triangle)" x1="812" x2="844" y1="24" y2="24"/>
+</g>
+<g>
+<text x="17" y="28">
+PoH
+</text>
+</g>
+<g>
+<text x="49" y="28">
+verify
+</text>
+</g>
+<g>
+<text x="49" y="44">
+TVU
+</text>
+</g>
+<g>
+<text x="49" y="108">
+load
+</text>
+</g>
+<g>
+<text x="89" y="108">
+accounts
+</text>
+</g>
+<g>
+<text x="169" y="28">
+sigverify
+</text>
+</g>
+<g>
+<text x="217" y="108">
+execute
+</text>
+</g>
+<g>
+<text x="305" y="28">
+lock
+</text>
+</g>
+<g>
+<text x="337" y="108">
+PoH
+</text>
+</g>
+<g>
+<text x="345" y="28">
+accounts
+</text>
+</g>
+<g>
+<text x="361" y="124">
+TPU
+</text>
+</g>
+<g>
+<text x="369" y="108">
+record
+</text>
+</g>
+<g>
+<text x="473" y="28">
+validate
+</text>
+</g>
+<g>
+<text x="481" y="108">
+commit
+</text>
+</g>
+<g>
+<text x="537" y="108">
+accounts
+</text>
+</g>
+<g>
+<text x="545" y="28">
+fee
+</text>
+</g>
+<g>
+<text x="633" y="28">
+allocate
+</text>
+</g>
+<g>
+<text x="657" y="108">
+unlock
+</text>
+</g>
+<g>
+<text x="705" y="28">
+new
+</text>
+</g>
+<g>
+<text x="713" y="108">
+accounts
+</text>
+</g>
+<g>
+<text x="737" y="28">
+accounts
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/sdk-tools.svg

@@ -0,0 +1,237 @@
+<svg class="bob" font-family="arial" font-size="14" height="320" width="560" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="320" width="560" x="0" y="0"/>
+<g>
+<line x1="20" x2="20" y1="140" y2="196"/>
+<path d="M 20 196 A 4 4 0 0 0 24 200" fill="none"/>
+<path d="M 24 136 A 4 4 0 0 0 20 140" fill="none"/>
+</g>
+<g>
+<line x1="24" x2="104" y1="136" y2="136"/>
+<path d="M 108 140 A 4 4 0 0 0 104 136" fill="none"/>
+</g>
+<g>
+<line x1="24" x2="104" y1="200" y2="200"/>
+<path d="M 104 200 A 4 4 0 0 0 108 196" fill="none"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="140" y2="152"/>
+<line x1="108" x2="108" y1="152" y2="184"/>
+<line x1="108" x2="176" y1="152" y2="152"/>
+<line x1="108" x2="108" y1="184" y2="196"/>
+<line x1="108" x2="176" y1="184" y2="184"/>
+<path d="M 176 152 A 4 4 0 0 0 180 148" fill="none"/>
+<path d="M 180 188 A 4 4 0 0 0 176 184" fill="none"/>
+</g>
+<g>
+<line x1="180" x2="180" y1="108" y2="148"/>
+<path d="M 184 104 A 4 4 0 0 0 180 108" fill="none"/>
+</g>
+<g>
+<line x1="180" x2="180" y1="188" y2="244"/>
+<path d="M 180 244 A 4 4 0 0 0 184 248" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="184" x2="252" y1="104" y2="104"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="184" x2="252" y1="248" y2="248"/>
+</g>
+<g>
+<line x1="228" x2="228" y1="28" y2="96"/>
+<path d="M 232 24 A 4 4 0 0 0 228 28" fill="none"/>
+</g>
+<g>
+<line x1="228" x2="228" y1="112" y2="240"/>
+</g>
+<g>
+<line x1="228" x2="228" y1="256" y2="308"/>
+<path d="M 228 308 A 4 4 0 0 0 232 312" fill="none"/>
+</g>
+<g>
+<line x1="232" x2="552" y1="24" y2="24"/>
+<path d="M 556 28 A 4 4 0 0 0 552 24" fill="none"/>
+</g>
+<g>
+<line x1="232" x2="552" y1="312" y2="312"/>
+<path d="M 552 312 A 4 4 0 0 0 556 308" fill="none"/>
+</g>
+<g>
+<line x1="260" x2="260" y1="76" y2="132"/>
+<path d="M 260 132 A 4 4 0 0 0 264 136" fill="none"/>
+<path d="M 264 72 A 4 4 0 0 0 260 76" fill="none"/>
+</g>
+<g>
+<line x1="260" x2="260" y1="220" y2="276"/>
+<path d="M 260 276 A 4 4 0 0 0 264 280" fill="none"/>
+<path d="M 264 216 A 4 4 0 0 0 260 220" fill="none"/>
+</g>
+<g>
+<line x1="264" x2="360" y1="72" y2="72"/>
+<path d="M 364 76 A 4 4 0 0 0 360 72" fill="none"/>
+</g>
+<g>
+<line x1="264" x2="360" y1="136" y2="136"/>
+<path d="M 360 136 A 4 4 0 0 0 364 132" fill="none"/>
+</g>
+<g>
+<line x1="264" x2="316" y1="216" y2="216"/>
+<line x1="316" x2="316" y1="188" y2="216"/>
+<line x1="316" x2="360" y1="216" y2="216"/>
+<path d="M 320 184 A 4 4 0 0 0 316 188" fill="none"/>
+<path d="M 364 220 A 4 4 0 0 0 360 216" fill="none"/>
+</g>
+<g>
+<line x1="264" x2="360" y1="280" y2="280"/>
+<path d="M 360 280 A 4 4 0 0 0 364 276" fill="none"/>
+</g>
+<g>
+<line x1="320" x2="448" y1="184" y2="184"/>
+<path d="M 448 184 A 4 4 0 0 0 452 180" fill="none"/>
+</g>
+<g>
+<line x1="364" x2="364" y1="76" y2="104"/>
+<line x1="364" x2="364" y1="104" y2="132"/>
+<line marker-end="url(#triangle)" x1="364" x2="388" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="364" x2="364" y1="220" y2="248"/>
+<line x1="364" x2="364" y1="248" y2="276"/>
+<line marker-end="url(#triangle)" x1="364" x2="388" y1="248" y2="248"/>
+</g>
+<g>
+<line x1="396" x2="396" y1="76" y2="132"/>
+<path d="M 396 132 A 4 4 0 0 0 400 136" fill="none"/>
+<path d="M 400 72 A 4 4 0 0 0 396 76" fill="none"/>
+</g>
+<g>
+<line x1="396" x2="396" y1="220" y2="276"/>
+<path d="M 396 276 A 4 4 0 0 0 400 280" fill="none"/>
+<path d="M 400 216 A 4 4 0 0 0 396 220" fill="none"/>
+</g>
+<g>
+<line x1="400" x2="496" y1="72" y2="72"/>
+<path d="M 500 76 A 4 4 0 0 0 496 72" fill="none"/>
+</g>
+<g>
+<line x1="400" x2="496" y1="136" y2="136"/>
+<path d="M 496 136 A 4 4 0 0 0 500 132" fill="none"/>
+</g>
+<g>
+<line x1="400" x2="504" y1="216" y2="216"/>
+<path d="M 508 220 A 4 4 0 0 0 504 216" fill="none"/>
+</g>
+<g>
+<line x1="400" x2="504" y1="280" y2="280"/>
+<path d="M 504 280 A 4 4 0 0 0 508 276" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="452" x2="452" y1="160" y2="148"/>
+<line x1="452" x2="452" y1="160" y2="180"/>
+</g>
+<g>
+<line x1="500" x2="500" y1="76" y2="132"/>
+</g>
+<g>
+<line x1="508" x2="508" y1="220" y2="276"/>
+</g>
+<g>
+<line x1="556" x2="556" y1="28" y2="308"/>
+</g>
+<g>
+<text x="41" y="172">
+Client
+</text>
+</g>
+<g>
+<text x="281" y="108">
+Verifier
+</text>
+</g>
+<g>
+<text x="281" y="252">
+Loader
+</text>
+</g>
+<g>
+<text x="329" y="44">
+Solana
+</text>
+</g>
+<g>
+<text x="337" y="172">
+LoadAccounts
+</text>
+</g>
+<g>
+<text x="385" y="44">
+Runtime
+</text>
+</g>
+<g>
+<text x="409" y="252">
+Interpreter
+</text>
+</g>
+<g>
+<text x="417" y="108">
+Accounts
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/spv-bank-merkle.svg

@@ -0,0 +1,163 @@
+<svg class="bob" font-family="arial" font-size="14" height="288" width="432" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="288" width="432" x="0" y="0"/>
+<g>
+<line x1="12" x2="12" y1="248" y2="280"/>
+<line x1="12" x2="140" y1="248" y2="248"/>
+<line x1="12" x2="140" y1="280" y2="280"/>
+<line x1="140" x2="140" y1="248" y2="280"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="112" x2="126" y1="240" y2="212"/>
+</g>
+<g>
+<line x1="124" x2="124" y1="88" y2="120"/>
+<line x1="124" x2="268" y1="88" y2="88"/>
+<line x1="124" x2="268" y1="120" y2="120"/>
+<line x1="268" x2="268" y1="88" y2="120"/>
+</g>
+<g>
+<line x1="124" x2="124" y1="168" y2="200"/>
+<line x1="124" x2="180" y1="168" y2="168"/>
+<line x1="124" x2="180" y1="200" y2="200"/>
+<line x1="180" x2="180" y1="168" y2="200"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="160" x2="174" y1="160" y2="132"/>
+</g>
+<g>
+<line x1="172" x2="172" y1="248" y2="280"/>
+<line x1="172" x2="300" y1="248" y2="248"/>
+<line x1="172" x2="300" y1="280" y2="280"/>
+<line x1="300" x2="300" y1="248" y2="280"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="184" x2="178" y1="224" y2="212"/>
+<line x1="184" x2="192" y1="224" y2="240"/>
+</g>
+<g>
+<line x1="212" x2="212" y1="168" y2="200"/>
+<line x1="212" x2="428" y1="168" y2="168"/>
+<line x1="212" x2="428" y1="200" y2="200"/>
+<line x1="428" x2="428" y1="168" y2="200"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="224" x2="218" y1="144" y2="132"/>
+<line x1="224" x2="232" y1="144" y2="160"/>
+</g>
+<g>
+<line x1="236" x2="236" y1="8" y2="40"/>
+<line x1="236" x2="340" y1="8" y2="8"/>
+<line x1="236" x2="340" y1="40" y2="40"/>
+<line x1="340" x2="340" y1="8" y2="40"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="248" x2="262" y1="80" y2="52"/>
+</g>
+<g>
+<line x1="308" x2="308" y1="88" y2="120"/>
+<line x1="308" x2="420" y1="88" y2="88"/>
+<line x1="308" x2="420" y1="120" y2="120"/>
+<line x1="420" x2="420" y1="88" y2="120"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="320" x2="314" y1="64" y2="52"/>
+<line x1="320" x2="328" y1="64" y2="80"/>
+</g>
+<g>
+<text x="25" y="268">
+Hash(Account1)
+</text>
+</g>
+<g>
+<text x="137" y="108">
+Bank-Diff-Merkle
+</text>
+</g>
+<g>
+<text x="137" y="188">
+Hash
+</text>
+</g>
+<g>
+<text x="185" y="268">
+Hash(Account2)
+</text>
+</g>
+<g>
+<text x="225" y="188">
+Previous
+</text>
+</g>
+<g>
+<text x="249" y="28">
+Bank-Merkle
+</text>
+</g>
+<g>
+<text x="297" y="188">
+Bank-Diff-Merkle
+</text>
+</g>
+<g>
+<text x="321" y="108">
+Block-Merkle
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/spv-block-merkle.svg

@@ -0,0 +1,203 @@
+<svg class="bob" font-family="arial" font-size="14" height="304" width="584" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="304" width="584" x="0" y="0"/>
+<g>
+<line x1="12" x2="12" y1="248" y2="280"/>
+<line x1="12" x2="156" y1="248" y2="248"/>
+<line x1="12" x2="156" y1="280" y2="280"/>
+<line x1="156" x2="156" y1="248" y2="280"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="128" x2="142" y1="240" y2="212"/>
+</g>
+<g>
+<line x1="148" x2="148" y1="168" y2="200"/>
+<line x1="148" x2="212" y1="168" y2="168"/>
+<line x1="148" x2="212" y1="200" y2="200"/>
+<line x1="212" x2="212" y1="168" y2="200"/>
+</g>
+<g>
+<line x1="180" x2="180" y1="88" y2="120"/>
+<line x1="180" x2="292" y1="88" y2="88"/>
+<line x1="180" x2="292" y1="120" y2="120"/>
+<line x1="292" x2="292" y1="88" y2="120"/>
+</g>
+<g>
+<line x1="188" x2="188" y1="248" y2="280"/>
+<line x1="188" x2="332" y1="248" y2="248"/>
+<line x1="188" x2="332" y1="280" y2="280"/>
+<line x1="332" x2="332" y1="248" y2="280"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="192" x2="206" y1="160" y2="132"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="212" x2="212" y1="224" y2="212"/>
+<line x1="212" x2="212" y1="224" y2="240"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="264" x2="278" y1="80" y2="52"/>
+</g>
+<g>
+<line x1="284" x2="284" y1="8" y2="40"/>
+<line x1="284" x2="412" y1="8" y2="8"/>
+<line x1="284" x2="412" y1="40" y2="40"/>
+<line x1="412" x2="412" y1="8" y2="40"/>
+</g>
+<g>
+<line x1="364" x2="364" y1="248" y2="280"/>
+<line x1="364" x2="508" y1="248" y2="248"/>
+<line x1="364" x2="508" y1="280" y2="280"/>
+<line x1="508" x2="508" y1="248" y2="280"/>
+</g>
+<g>
+<line x1="396" x2="396" y1="88" y2="120"/>
+<line x1="396" x2="508" y1="88" y2="88"/>
+<line x1="396" x2="508" y1="120" y2="120"/>
+<line x1="508" x2="508" y1="88" y2="120"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="416" x2="410" y1="64" y2="52"/>
+<line x1="416" x2="424" y1="64" y2="80"/>
+</g>
+<g>
+<line x1="468" x2="468" y1="168" y2="200"/>
+<line x1="468" x2="532" y1="168" y2="168"/>
+<line x1="468" x2="532" y1="200" y2="200"/>
+<line x1="532" x2="532" y1="168" y2="200"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="476" x2="476" y1="224" y2="212"/>
+<line x1="476" x2="476" y1="224" y2="240"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="480" x2="474" y1="144" y2="132"/>
+<line x1="480" x2="488" y1="144" y2="160"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="536" x2="530" y1="224" y2="212"/>
+<line x1="536" x2="544" y1="224" y2="240"/>
+</g>
+<g>
+<line x1="540" x2="540" y1="248" y2="280"/>
+<line x1="540" x2="572" y1="248" y2="248"/>
+<line x1="540" x2="572" y1="280" y2="280"/>
+<line x1="572" x2="572" y1="248" y2="280"/>
+</g>
+<g>
+<text x="25" y="268">
+Hash(T1,
+</text>
+</g>
+<g>
+<text x="97" y="268">
+status)
+</text>
+</g>
+<g>
+<text x="169" y="188">
+Hash
+</text>
+</g>
+<g>
+<text x="193" y="108">
+Entry-Merkle
+</text>
+</g>
+<g>
+<text x="201" y="268">
+Hash(T2,
+</text>
+</g>
+<g>
+<text x="273" y="268">
+status)
+</text>
+</g>
+<g>
+<text x="305" y="28">
+Block-Merkle
+</text>
+</g>
+<g>
+<text x="377" y="268">
+Hash(T3,
+</text>
+</g>
+<g>
+<text x="409" y="108">
+Entry-Merkle
+</text>
+</g>
+<g>
+<text x="449" y="268">
+status)
+</text>
+</g>
+<g>
+<text x="489" y="188">
+Hash
+</text>
+</g>
+<g>
+<text x="553" y="268">
+0
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/tpu.svg

@@ -0,0 +1,312 @@
+<svg class="bob" font-family="arial" font-size="14" height="304" width="696" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="304" width="696" x="0" y="0"/>
+<g>
+<line x1="12" x2="12" y1="140" y2="164"/>
+<path d="M 12 164 A 4 4 0 0 0 16 168" fill="none"/>
+<path d="M 16 136 A 4 4 0 0 0 12 140" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="88" y1="136" y2="136"/>
+<path d="M 92 140 A 4 4 0 0 0 88 136" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="88" y1="168" y2="168"/>
+<path d="M 88 168 A 4 4 0 0 0 92 164" fill="none"/>
+</g>
+<g>
+<line x1="92" x2="92" y1="140" y2="164"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="92" x2="124" y1="152" y2="152"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="92" y2="144"/>
+<path d="M 112 88 A 4 4 0 0 0 108 92" fill="none"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="160" y2="212"/>
+<path d="M 108 212 A 4 4 0 0 0 112 216" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="356" y1="88" y2="88"/>
+<line x1="356" x2="396" y1="88" y2="88"/>
+<line x1="396" x2="560" y1="88" y2="88"/>
+<path d="M 564 92 A 4 4 0 0 0 560 88" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="380" y1="216" y2="216"/>
+<line x1="380" x2="560" y1="216" y2="216"/>
+<path d="M 560 216 A 4 4 0 0 0 564 212" fill="none"/>
+</g>
+<g>
+<line x1="132" x2="132" y1="124" y2="180"/>
+<path d="M 132 180 A 4 4 0 0 0 136 184" fill="none"/>
+<path d="M 136 120 A 4 4 0 0 0 132 124" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="192" y1="120" y2="120"/>
+<path d="M 196 124 A 4 4 0 0 0 192 120" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="192" y1="184" y2="184"/>
+<path d="M 192 184 A 4 4 0 0 0 196 180" fill="none"/>
+</g>
+<g>
+<line x1="196" x2="196" y1="124" y2="180"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="196" x2="212" y1="152" y2="152"/>
+</g>
+<g>
+<line x1="220" x2="220" y1="124" y2="180"/>
+<path d="M 220 180 A 4 4 0 0 0 224 184" fill="none"/>
+<path d="M 224 120 A 4 4 0 0 0 220 124" fill="none"/>
+</g>
+<g>
+<line x1="224" x2="312" y1="120" y2="120"/>
+<path d="M 316 124 A 4 4 0 0 0 312 120" fill="none"/>
+</g>
+<g>
+<line x1="224" x2="312" y1="184" y2="184"/>
+<path d="M 312 184 A 4 4 0 0 0 316 180" fill="none"/>
+</g>
+<g>
+<line x1="316" x2="316" y1="124" y2="180"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="316" x2="332" y1="152" y2="152"/>
+</g>
+<g>
+<line x1="324" x2="324" y1="28" y2="52"/>
+<path d="M 324 52 A 4 4 0 0 0 328 56" fill="none"/>
+<path d="M 328 24 A 4 4 0 0 0 324 28" fill="none"/>
+</g>
+<g>
+<line x1="328" x2="432" y1="24" y2="24"/>
+<path d="M 436 28 A 4 4 0 0 0 432 24" fill="none"/>
+</g>
+<g>
+<line x1="328" x2="396" y1="56" y2="56"/>
+<line marker-end="url(#triangle)" x1="396" x2="396" y1="56" y2="108"/>
+<line x1="396" x2="432" y1="56" y2="56"/>
+<path d="M 432 56 A 4 4 0 0 0 436 52" fill="none"/>
+</g>
+<g>
+<line x1="340" x2="340" y1="124" y2="180"/>
+<path d="M 340 180 A 4 4 0 0 0 344 184" fill="none"/>
+<path d="M 344 120 A 4 4 0 0 0 340 124" fill="none"/>
+</g>
+<g>
+<line x1="344" x2="356" y1="120" y2="120"/>
+<line x1="356" x2="356" y1="80" y2="120"/>
+<line x1="356" x2="416" y1="120" y2="120"/>
+<path d="M 420 124 A 4 4 0 0 0 416 120" fill="none"/>
+</g>
+<g>
+<line x1="344" x2="380" y1="184" y2="184"/>
+<line marker-end="url(#triangle)" x1="380" x2="380" y1="184" y2="252"/>
+<line x1="380" x2="416" y1="184" y2="184"/>
+<path d="M 416 184 A 4 4 0 0 0 420 180" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="356" x2="356" y1="80" y2="68"/>
+</g>
+<g>
+<line x1="356" x2="356" y1="268" y2="292"/>
+<path d="M 356 292 A 4 4 0 0 0 360 296" fill="none"/>
+<path d="M 360 264 A 4 4 0 0 0 356 268" fill="none"/>
+</g>
+<g>
+<line x1="360" x2="408" y1="264" y2="264"/>
+<path d="M 412 268 A 4 4 0 0 0 408 264" fill="none"/>
+</g>
+<g>
+<line x1="360" x2="408" y1="296" y2="296"/>
+<path d="M 408 296 A 4 4 0 0 0 412 292" fill="none"/>
+</g>
+<g>
+<line x1="412" x2="412" y1="268" y2="292"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="124" y2="180"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="420" x2="436" y1="152" y2="152"/>
+</g>
+<g>
+<line x1="436" x2="436" y1="28" y2="52"/>
+</g>
+<g>
+<line x1="444" x2="444" y1="124" y2="180"/>
+<path d="M 444 180 A 4 4 0 0 0 448 184" fill="none"/>
+<path d="M 448 120 A 4 4 0 0 0 444 124" fill="none"/>
+</g>
+<g>
+<line x1="448" x2="536" y1="120" y2="120"/>
+<path d="M 540 124 A 4 4 0 0 0 536 120" fill="none"/>
+</g>
+<g>
+<line x1="448" x2="536" y1="184" y2="184"/>
+<path d="M 536 184 A 4 4 0 0 0 540 180" fill="none"/>
+</g>
+<g>
+<line x1="540" x2="540" y1="124" y2="180"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="540" x2="580" y1="152" y2="152"/>
+</g>
+<g>
+<line x1="564" x2="564" y1="92" y2="144"/>
+</g>
+<g>
+<line x1="564" x2="564" y1="160" y2="212"/>
+</g>
+<g>
+<line x1="588" x2="588" y1="124" y2="180"/>
+<path d="M 588 180 A 4 4 0 0 0 592 184" fill="none"/>
+<path d="M 592 120 A 4 4 0 0 0 588 124" fill="none"/>
+</g>
+<g>
+<line x1="592" x2="688" y1="120" y2="120"/>
+<path d="M 692 124 A 4 4 0 0 0 688 120" fill="none"/>
+</g>
+<g>
+<line x1="592" x2="688" y1="184" y2="184"/>
+<path d="M 688 184 A 4 4 0 0 0 692 180" fill="none"/>
+</g>
+<g>
+<line x1="692" x2="692" y1="124" y2="180"/>
+</g>
+<g>
+<text x="25" y="156">
+Clients
+</text>
+</g>
+<g>
+<text x="121" y="108">
+TPU
+</text>
+</g>
+<g>
+<text x="145" y="140">
+Fetch
+</text>
+</g>
+<g>
+<text x="145" y="156">
+Stage
+</text>
+</g>
+<g>
+<text x="233" y="140">
+SigVerify
+</text>
+</g>
+<g>
+<text x="233" y="156">
+Stage
+</text>
+</g>
+<g>
+<text x="337" y="44">
+PoH
+</text>
+</g>
+<g>
+<text x="353" y="140">
+Banking
+</text>
+</g>
+<g>
+<text x="353" y="156">
+Stage
+</text>
+</g>
+<g>
+<text x="369" y="44">
+Service
+</text>
+</g>
+<g>
+<text x="369" y="284">
+Bank
+</text>
+</g>
+<g>
+<text x="457" y="140">
+Broadcast
+</text>
+</g>
+<g>
+<text x="457" y="156">
+Stage
+</text>
+</g>
+<g>
+<text x="601" y="140">
+Downstream
+</text>
+</g>
+<g>
+<text x="601" y="156">
+Validators
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/tvu.svg

@@ -0,0 +1,311 @@
+<svg class="bob" font-family="arial" font-size="14" height="352" width="616" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="352" width="616" x="0" y="0"/>
+<g>
+<line x1="12" x2="12" y1="156" y2="196"/>
+<path d="M 12 196 A 4 4 0 0 0 16 200" fill="none"/>
+<path d="M 16 152 A 4 4 0 0 0 12 156" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="112" y1="152" y2="152"/>
+<path d="M 116 156 A 4 4 0 0 0 112 152" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="112" y1="200" y2="200"/>
+<path d="M 112 200 A 4 4 0 0 0 116 196" fill="none"/>
+</g>
+<g>
+<line x1="116" x2="116" y1="156" y2="168"/>
+<line x1="116" x2="116" y1="168" y2="196"/>
+<line marker-end="url(#triangle)" x1="116" x2="164" y1="168" y2="168"/>
+</g>
+<g>
+<line x1="148" x2="148" y1="92" y2="160"/>
+<path d="M 152 88 A 4 4 0 0 0 148 92" fill="none"/>
+</g>
+<g>
+<line x1="148" x2="148" y1="176" y2="244"/>
+<path d="M 148 244 A 4 4 0 0 0 152 248" fill="none"/>
+</g>
+<g>
+<line x1="152" x2="444" y1="88" y2="88"/>
+<line x1="444" x2="608" y1="88" y2="88"/>
+<path d="M 612 92 A 4 4 0 0 0 608 88" fill="none"/>
+</g>
+<g>
+<line x1="152" x2="220" y1="248" y2="248"/>
+<line x1="220" x2="308" y1="248" y2="248"/>
+<line x1="308" x2="444" y1="248" y2="248"/>
+<line x1="444" x2="608" y1="248" y2="248"/>
+<path d="M 608 248 A 4 4 0 0 0 612 244" fill="none"/>
+</g>
+<g>
+<line x1="172" x2="172" y1="140" y2="196"/>
+<path d="M 172 196 A 4 4 0 0 0 176 200" fill="none"/>
+<path d="M 176 136 A 4 4 0 0 0 172 140" fill="none"/>
+</g>
+<g>
+<line x1="176" x2="232" y1="136" y2="136"/>
+<path d="M 236 140 A 4 4 0 0 0 232 136" fill="none"/>
+</g>
+<g>
+<line x1="176" x2="232" y1="200" y2="200"/>
+<path d="M 232 200 A 4 4 0 0 0 236 196" fill="none"/>
+</g>
+<g>
+<line x1="212" x2="212" y1="300" y2="340"/>
+<path d="M 212 340 A 4 4 0 0 0 216 344" fill="none"/>
+<path d="M 216 296 A 4 4 0 0 0 212 300" fill="none"/>
+</g>
+<g>
+<line x1="216" x2="312" y1="344" y2="344"/>
+<path d="M 312 344 A 4 4 0 0 0 316 340" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="220" x2="220" y1="224" y2="212"/>
+<line x1="220" x2="220" y1="224" y2="296"/>
+<line x1="220" x2="216" y1="296" y2="296"/>
+<line x1="220" x2="312" y1="296" y2="296"/>
+<path d="M 316 300 A 4 4 0 0 0 312 296" fill="none"/>
+</g>
+<g>
+<line x1="236" x2="236" y1="140" y2="168"/>
+<line x1="236" x2="236" y1="168" y2="196"/>
+<line marker-end="url(#triangle)" x1="236" x2="260" y1="168" y2="168"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="140" y2="196"/>
+<path d="M 268 196 A 4 4 0 0 0 272 200" fill="none"/>
+<path d="M 272 136 A 4 4 0 0 0 268 140" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="136" y2="136"/>
+<path d="M 372 140 A 4 4 0 0 0 368 136" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="308" y1="200" y2="200"/>
+<line marker-end="url(#triangle)" x1="308" x2="308" y1="200" y2="284"/>
+<line x1="308" x2="368" y1="200" y2="200"/>
+<path d="M 368 200 A 4 4 0 0 0 372 196" fill="none"/>
+</g>
+<g>
+<line x1="316" x2="316" y1="300" y2="340"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="140" y2="168"/>
+<line x1="372" x2="372" y1="168" y2="196"/>
+<line marker-end="url(#triangle)" x1="372" x2="396" y1="168" y2="168"/>
+</g>
+<g>
+<line x1="404" x2="404" y1="12" y2="36"/>
+<path d="M 404 36 A 4 4 0 0 0 408 40" fill="none"/>
+<path d="M 408 8 A 4 4 0 0 0 404 12" fill="none"/>
+</g>
+<g>
+<line x1="404" x2="404" y1="140" y2="196"/>
+<path d="M 404 196 A 4 4 0 0 0 408 200" fill="none"/>
+<path d="M 408 136 A 4 4 0 0 0 404 140" fill="none"/>
+</g>
+<g>
+<line x1="408" x2="472" y1="8" y2="8"/>
+<path d="M 476 12 A 4 4 0 0 0 472 8" fill="none"/>
+</g>
+<g>
+<line x1="408" x2="472" y1="40" y2="40"/>
+<path d="M 472 40 A 4 4 0 0 0 476 36" fill="none"/>
+</g>
+<g>
+<line x1="408" x2="444" y1="136" y2="136"/>
+<line x1="444" x2="444" y1="64" y2="136"/>
+<line x1="444" x2="472" y1="136" y2="136"/>
+<path d="M 476 140 A 4 4 0 0 0 472 136" fill="none"/>
+</g>
+<g>
+<line x1="408" x2="444" y1="200" y2="200"/>
+<line marker-end="url(#triangle)" x1="444" x2="444" y1="200" y2="284"/>
+<line x1="444" x2="472" y1="200" y2="200"/>
+<path d="M 472 200 A 4 4 0 0 0 476 196" fill="none"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="300" y2="324"/>
+<path d="M 420 324 A 4 4 0 0 0 424 328" fill="none"/>
+<path d="M 424 296 A 4 4 0 0 0 420 300" fill="none"/>
+</g>
+<g>
+<line x1="424" x2="472" y1="296" y2="296"/>
+<path d="M 476 300 A 4 4 0 0 0 472 296" fill="none"/>
+</g>
+<g>
+<line x1="424" x2="472" y1="328" y2="328"/>
+<path d="M 472 328 A 4 4 0 0 0 476 324" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="444" x2="444" y1="64" y2="52"/>
+</g>
+<g>
+<line x1="476" x2="476" y1="12" y2="36"/>
+</g>
+<g>
+<line x1="476" x2="476" y1="140" y2="168"/>
+<line x1="476" x2="476" y1="168" y2="196"/>
+<line marker-end="url(#triangle)" x1="476" x2="500" y1="168" y2="168"/>
+</g>
+<g>
+<line x1="476" x2="476" y1="300" y2="324"/>
+</g>
+<g>
+<line x1="508" x2="508" y1="140" y2="196"/>
+<path d="M 508 196 A 4 4 0 0 0 512 200" fill="none"/>
+<path d="M 512 136 A 4 4 0 0 0 508 140" fill="none"/>
+</g>
+<g>
+<line x1="512" x2="584" y1="136" y2="136"/>
+<path d="M 588 140 A 4 4 0 0 0 584 136" fill="none"/>
+</g>
+<g>
+<line x1="512" x2="584" y1="200" y2="200"/>
+<path d="M 584 200 A 4 4 0 0 0 588 196" fill="none"/>
+</g>
+<g>
+<line x1="588" x2="588" y1="140" y2="196"/>
+</g>
+<g>
+<line x1="612" x2="612" y1="92" y2="244"/>
+</g>
+<g>
+<text x="25" y="172">
+Upstream
+</text>
+</g>
+<g>
+<text x="25" y="188">
+Validators
+</text>
+</g>
+<g>
+<text x="169" y="108">
+TVU
+</text>
+</g>
+<g>
+<text x="185" y="156">
+Blob
+</text>
+</g>
+<g>
+<text x="185" y="172">
+Fetch
+</text>
+</g>
+<g>
+<text x="185" y="188">
+Stage
+</text>
+</g>
+<g>
+<text x="225" y="316">
+Gossip
+</text>
+</g>
+<g>
+<text x="225" y="332">
+Service
+</text>
+</g>
+<g>
+<text x="281" y="156">
+Retransmit
+</text>
+</g>
+<g>
+<text x="281" y="172">
+Stage
+</text>
+</g>
+<g>
+<text x="417" y="28">
+Leader
+</text>
+</g>
+<g>
+<text x="417" y="156">
+Replay
+</text>
+</g>
+<g>
+<text x="417" y="172">
+Stage
+</text>
+</g>
+<g>
+<text x="433" y="316">
+Bank
+</text>
+</g>
+<g>
+<text x="521" y="156">
+Storage
+</text>
+</g>
+<g>
+<text x="521" y="172">
+Stage
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/validator-proposal.svg

@@ -0,0 +1,496 @@
+<svg class="bob" font-family="arial" font-size="14" height="960" width="528" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="960" width="528" x="0" y="0"/>
+<g>
+<line x1="12" x2="12" y1="188" y2="212"/>
+<path d="M 12 212 A 4 4 0 0 0 16 216" fill="none"/>
+<path d="M 16 184 A 4 4 0 0 0 12 188" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="80" y1="184" y2="184"/>
+<path d="M 84 188 A 4 4 0 0 0 80 184" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="80" y1="216" y2="216"/>
+<path d="M 80 216 A 4 4 0 0 0 84 212" fill="none"/>
+</g>
+<g>
+<line x1="20" x2="20" y1="748" y2="788"/>
+<path d="M 20 788 A 4 4 0 0 0 24 792" fill="none"/>
+<path d="M 24 744 A 4 4 0 0 0 20 748" fill="none"/>
+</g>
+<g>
+<line x1="24" x2="80" y1="744" y2="744"/>
+<path d="M 84 748 A 4 4 0 0 0 80 744" fill="none"/>
+</g>
+<g>
+<line x1="24" x2="80" y1="792" y2="792"/>
+<path d="M 80 792 A 4 4 0 0 0 84 788" fill="none"/>
+</g>
+<g>
+<line x1="84" x2="84" y1="188" y2="200"/>
+<line x1="84" x2="84" y1="200" y2="212"/>
+<line marker-end="url(#triangle)" x1="84" x2="124" y1="200" y2="200"/>
+</g>
+<g>
+<line x1="84" x2="84" y1="748" y2="760"/>
+<line x1="84" x2="84" y1="760" y2="788"/>
+<line marker-end="url(#triangle)" x1="84" x2="124" y1="760" y2="760"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="124" y2="192"/>
+<path d="M 112 120 A 4 4 0 0 0 108 124" fill="none"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="208" y2="436"/>
+<path d="M 108 436 A 4 4 0 0 0 112 440" fill="none"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="700" y2="752"/>
+<path d="M 112 696 A 4 4 0 0 0 108 700" fill="none"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="768" y2="836"/>
+<path d="M 108 836 A 4 4 0 0 0 112 840" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="392" y1="120" y2="120"/>
+<path d="M 396 124 A 4 4 0 0 0 392 120" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="392" y1="440" y2="440"/>
+<path d="M 392 440 A 4 4 0 0 0 396 436" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="392" y1="696" y2="696"/>
+<path d="M 396 700 A 4 4 0 0 0 392 696" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="392" y1="840" y2="840"/>
+<path d="M 392 840 A 4 4 0 0 0 396 836" fill="none"/>
+</g>
+<g>
+<line x1="132" x2="132" y1="172" y2="212"/>
+<path d="M 132 212 A 4 4 0 0 0 136 216" fill="none"/>
+<path d="M 136 168 A 4 4 0 0 0 132 172" fill="none"/>
+</g>
+<g>
+<line x1="132" x2="132" y1="268" y2="308"/>
+<path d="M 132 308 A 4 4 0 0 0 136 312" fill="none"/>
+<path d="M 136 264 A 4 4 0 0 0 132 268" fill="none"/>
+</g>
+<g>
+<line x1="132" x2="132" y1="748" y2="788"/>
+<path d="M 132 788 A 4 4 0 0 0 136 792" fill="none"/>
+<path d="M 136 744 A 4 4 0 0 0 132 748" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="224" y1="168" y2="168"/>
+<path d="M 228 172 A 4 4 0 0 0 224 168" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="164" y1="216" y2="216"/>
+<line marker-end="url(#triangle)" x1="164" x2="164" y1="216" y2="252"/>
+<line x1="164" x2="224" y1="216" y2="216"/>
+<path d="M 224 216 A 4 4 0 0 0 228 212" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="224" y1="264" y2="264"/>
+<path d="M 228 268 A 4 4 0 0 0 224 264" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="224" y1="312" y2="312"/>
+<path d="M 224 312 A 4 4 0 0 0 228 308" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="224" y1="744" y2="744"/>
+<path d="M 228 748 A 4 4 0 0 0 224 744" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="224" y1="792" y2="792"/>
+<path d="M 224 792 A 4 4 0 0 0 228 788" fill="none"/>
+</g>
+<g>
+<line x1="228" x2="228" y1="172" y2="212"/>
+</g>
+<g>
+<line x1="228" x2="228" y1="268" y2="308"/>
+</g>
+<g>
+<line x1="228" x2="228" y1="748" y2="760"/>
+<line x1="228" x2="228" y1="760" y2="788"/>
+<line marker-end="url(#triangle)" x1="228" x2="260" y1="760" y2="760"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="240" x2="236" y1="280" y2="280"/>
+<line marker-end="url(#triangle)" x1="240" x2="260" y1="280" y2="280"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="28" y2="68"/>
+<path d="M 268 68 A 4 4 0 0 0 272 72" fill="none"/>
+<path d="M 272 24 A 4 4 0 0 0 268 28" fill="none"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="172" y2="212"/>
+<path d="M 268 212 A 4 4 0 0 0 272 216" fill="none"/>
+<path d="M 272 168 A 4 4 0 0 0 268 172" fill="none"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="268" y2="308"/>
+<path d="M 268 308 A 4 4 0 0 0 272 312" fill="none"/>
+<path d="M 272 264 A 4 4 0 0 0 268 268" fill="none"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="364" y2="404"/>
+<path d="M 268 404 A 4 4 0 0 0 272 408" fill="none"/>
+<path d="M 272 360 A 4 4 0 0 0 268 364" fill="none"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="492" y2="532"/>
+<path d="M 268 532 A 4 4 0 0 0 272 536" fill="none"/>
+<path d="M 272 488 A 4 4 0 0 0 268 492" fill="none"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="604" y2="644"/>
+<path d="M 268 644 A 4 4 0 0 0 272 648" fill="none"/>
+<path d="M 272 600 A 4 4 0 0 0 268 604" fill="none"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="748" y2="788"/>
+<path d="M 268 788 A 4 4 0 0 0 272 792" fill="none"/>
+<path d="M 272 744 A 4 4 0 0 0 268 748" fill="none"/>
+</g>
+<g>
+<line x1="268" x2="268" y1="892" y2="932"/>
+<path d="M 268 932 A 4 4 0 0 0 272 936" fill="none"/>
+<path d="M 272 888 A 4 4 0 0 0 268 892" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="24" y2="24"/>
+<path d="M 372 28 A 4 4 0 0 0 368 24" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="308" y1="72" y2="72"/>
+<line x1="308" x2="308" y1="72" y2="112"/>
+<line x1="308" x2="368" y1="72" y2="72"/>
+<path d="M 368 72 A 4 4 0 0 0 372 68" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="168" y2="168"/>
+<path d="M 372 172 A 4 4 0 0 0 368 168" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="308" y1="216" y2="216"/>
+<line marker-end="url(#triangle)" x1="308" x2="308" y1="216" y2="252"/>
+<line x1="308" x2="368" y1="216" y2="216"/>
+<path d="M 368 216 A 4 4 0 0 0 372 212" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="264" y2="264"/>
+<path d="M 372 268 A 4 4 0 0 0 368 264" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="308" y1="312" y2="312"/>
+<line marker-end="url(#triangle)" x1="308" x2="308" y1="312" y2="348"/>
+<line x1="308" x2="368" y1="312" y2="312"/>
+<path d="M 368 312 A 4 4 0 0 0 372 308" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="360" y2="360"/>
+<path d="M 372 364 A 4 4 0 0 0 368 360" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="308" y1="408" y2="408"/>
+<line x1="308" x2="308" y1="408" y2="432"/>
+<line x1="308" x2="368" y1="408" y2="408"/>
+<path d="M 368 408 A 4 4 0 0 0 372 404" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="488" y2="488"/>
+<path d="M 372 492 A 4 4 0 0 0 368 488" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="536" y2="536"/>
+<path d="M 368 536 A 4 4 0 0 0 372 532" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="600" y2="600"/>
+<path d="M 372 604 A 4 4 0 0 0 368 600" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="332" y1="648" y2="648"/>
+<line x1="332" x2="332" y1="648" y2="688"/>
+<line x1="332" x2="368" y1="648" y2="648"/>
+<path d="M 368 648 A 4 4 0 0 0 372 644" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="300" y1="744" y2="744"/>
+<line x1="300" x2="300" y1="704" y2="744"/>
+<line x1="300" x2="368" y1="744" y2="744"/>
+<path d="M 372 748 A 4 4 0 0 0 368 744" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="316" y1="792" y2="792"/>
+<line x1="316" x2="316" y1="792" y2="832"/>
+<line x1="316" x2="368" y1="792" y2="792"/>
+<path d="M 368 792 A 4 4 0 0 0 372 788" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="888" y2="888"/>
+<path d="M 372 892 A 4 4 0 0 0 368 888" fill="none"/>
+</g>
+<g>
+<line x1="272" x2="368" y1="936" y2="936"/>
+<path d="M 368 936 A 4 4 0 0 0 372 932" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="300" x2="300" y1="672" y2="660"/>
+<line x1="300" x2="300" y1="672" y2="688"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="308" x2="308" y1="128" y2="156"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="308" x2="308" y1="448" y2="476"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="316" x2="316" y1="848" y2="876"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="332" x2="332" y1="704" y2="732"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="28" y2="68"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="172" y2="212"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="268" y2="308"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="364" y2="404"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="492" y2="532"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="604" y2="644"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="748" y2="788"/>
+</g>
+<g>
+<line x1="372" x2="372" y1="892" y2="932"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="384" x2="380" y1="760" y2="760"/>
+<line marker-end="url(#triangle)" x1="384" x2="412" y1="760" y2="760"/>
+</g>
+<g>
+<line x1="396" x2="396" y1="124" y2="436"/>
+</g>
+<g>
+<line x1="396" x2="396" y1="700" y2="752"/>
+</g>
+<g>
+<line x1="396" x2="396" y1="768" y2="836"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="748" y2="788"/>
+<path d="M 420 788 A 4 4 0 0 0 424 792" fill="none"/>
+<path d="M 424 744 A 4 4 0 0 0 420 748" fill="none"/>
+</g>
+<g>
+<line x1="424" x2="520" y1="744" y2="744"/>
+<path d="M 524 748 A 4 4 0 0 0 520 744" fill="none"/>
+</g>
+<g>
+<line x1="424" x2="520" y1="792" y2="792"/>
+<path d="M 520 792 A 4 4 0 0 0 524 788" fill="none"/>
+</g>
+<g>
+<line x1="524" x2="524" y1="748" y2="788"/>
+</g>
+<g>
+<text x="25" y="204">
+Client
+</text>
+</g>
+<g>
+<text x="33" y="764">
+Fetch
+</text>
+</g>
+<g>
+<text x="33" y="780">
+Stage
+</text>
+</g>
+<g>
+<text x="121" y="140">
+Validator
+</text>
+</g>
+<g>
+<text x="121" y="716">
+TPU
+</text>
+</g>
+<g>
+<text x="145" y="188">
+Fetch
+</text>
+</g>
+<g>
+<text x="145" y="204">
+Stage
+</text>
+</g>
+<g>
+<text x="145" y="284">
+TPU
+</text>
+</g>
+<g>
+<text x="145" y="764">
+SigVerify
+</text>
+</g>
+<g>
+<text x="145" y="780">
+Stage
+</text>
+</g>
+<g>
+<text x="281" y="44">
+Upstream
+</text>
+</g>
+<g>
+<text x="281" y="60">
+Validators
+</text>
+</g>
+<g>
+<text x="281" y="188">
+Repair
+</text>
+</g>
+<g>
+<text x="281" y="204">
+Stage
+</text>
+</g>
+<g>
+<text x="281" y="284">
+Blockstore
+</text>
+</g>
+<g>
+<text x="281" y="380">
+Multicast
+</text>
+</g>
+<g>
+<text x="281" y="396">
+Stage
+</text>
+</g>
+<g>
+<text x="281" y="508">
+Downstream
+</text>
+</g>
+<g>
+<text x="281" y="524">
+Validators
+</text>
+</g>
+<g>
+<text x="281" y="620">
+PoH
+</text>
+</g>
+<g>
+<text x="281" y="636">
+Service
+</text>
+</g>
+<g>
+<text x="281" y="764">
+Banking
+</text>
+</g>
+<g>
+<text x="281" y="780">
+Stage
+</text>
+</g>
+<g>
+<text x="281" y="908">
+Banktree
+</text>
+</g>
+<g>
+<text x="433" y="764">
+Blockstore
+</text>
+</g>
+</svg>

book/src/.gitbook/assets/validator.svg

@@ -0,0 +1,456 @@
+<svg class="bob" font-family="arial" font-size="14" height="480" width="592" xmlns="http://www.w3.org/2000/svg">
+<defs>
+<marker id="triangle" markerHeight="8" markerWidth="8" orient="auto" refX="4" refY="2" viewBox="0 0 8 4">
+<polygon fill="black" points="0,0 0,4 8,2 0,0"/>
+</marker>
+<marker id="clear_triangle" markerHeight="10" markerWidth="10" orient="auto" refX="1" refY="7" viewBox="0 0 20 14">
+<polygon fill="none" points="2,2 2,12 18,7 2,2" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="circle" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="black" r="8"/>
+</marker>
+<marker id="square" markerHeight="5" markerWidth="5" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<rect fill="black" height="20" width="20" x="0" y="0"/>
+</marker>
+<marker id="open_circle" markerHeight="10" markerWidth="10" orient="auto" refX="10" refY="10" viewBox="0 0 20 20">
+<circle cx="10" cy="10" fill="white" r="4" stroke="black" stroke-width="2"/>
+</marker>
+<marker id="big_open_circle" markerHeight="20" markerWidth="20" orient="auto" refX="20" refY="20" viewBox="0 0 40 40">
+<circle cx="20" cy="20" fill="white" r="6" stroke="black" stroke-width="2"/>
+</marker>
+</defs>
+<style type="text/css">
+
+    line,path {
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    line.dashed {
+        stroke-dasharray: 5;
+    }
+    circle.solid {
+      fill:black;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    circle.open {
+      fill:none;
+      stroke: black;
+      stroke-width: 2;
+      stroke-opacity: 1;
+      fill-opacity: 1;
+      stroke-linecap: round;
+      stroke-linejoin: miter;
+    }
+    tspan.head{
+        fill: none;
+        stroke: none;
+    }
+    
+</style>
+<rect fill="white" height="480" width="592" x="0" y="0"/>
+<g>
+<line x1="12" x2="12" y1="60" y2="116"/>
+<path d="M 12 116 A 4 4 0 0 0 16 120" fill="none"/>
+<path d="M 16 56 A 4 4 0 0 0 12 60" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="80" y1="56" y2="56"/>
+<path d="M 84 60 A 4 4 0 0 0 80 56" fill="none"/>
+</g>
+<g>
+<line x1="16" x2="52" y1="120" y2="120"/>
+<line x1="52" x2="52" y1="120" y2="420"/>
+<line x1="52" x2="80" y1="120" y2="120"/>
+<path d="M 52 420 A 4 4 0 0 0 56 424" fill="none"/>
+<path d="M 80 120 A 4 4 0 0 0 84 116" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="56" x2="124" y1="424" y2="424"/>
+</g>
+<g>
+<line x1="84" x2="84" y1="60" y2="116"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="84" x2="124" y1="72" y2="72"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="96" x2="92" y1="104" y2="104"/>
+<line x1="96" x2="132" y1="104" y2="104"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="12" y2="64"/>
+<path d="M 112 8 A 4 4 0 0 0 108 12" fill="none"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="80" y2="96"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="112" y2="416"/>
+</g>
+<g>
+<line x1="108" x2="108" y1="432" y2="468"/>
+<path d="M 108 468 A 4 4 0 0 0 112 472" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="416" y1="8" y2="8"/>
+<path d="M 420 12 A 4 4 0 0 0 416 8" fill="none"/>
+</g>
+<g>
+<line x1="112" x2="416" y1="472" y2="472"/>
+<path d="M 416 472 A 4 4 0 0 0 420 468" fill="none"/>
+</g>
+<g>
+<line x1="124" x2="124" y1="236" y2="276"/>
+<path d="M 124 276 A 4 4 0 0 0 128 280" fill="none"/>
+<path d="M 128 232 A 4 4 0 0 0 124 236" fill="none"/>
+</g>
+<g>
+<line x1="128" x2="156" y1="232" y2="232"/>
+<line x1="156" x2="156" y1="144" y2="232"/>
+<line x1="156" x2="184" y1="232" y2="232"/>
+<path d="M 188 236 A 4 4 0 0 0 184 232" fill="none"/>
+</g>
+<g>
+<line x1="128" x2="184" y1="280" y2="280"/>
+<path d="M 184 280 A 4 4 0 0 0 188 276" fill="none"/>
+</g>
+<g>
+<line x1="132" x2="132" y1="60" y2="116"/>
+<path d="M 132 116 A 4 4 0 0 0 136 120" fill="none"/>
+<path d="M 136 56 A 4 4 0 0 0 132 60" fill="none"/>
+</g>
+<g>
+<line x1="132" x2="132" y1="412" y2="436"/>
+<path d="M 132 436 A 4 4 0 0 0 136 440" fill="none"/>
+<path d="M 136 408 A 4 4 0 0 0 132 412" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="288" y1="56" y2="56"/>
+<path d="M 292 60 A 4 4 0 0 0 288 56" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="288" y1="120" y2="120"/>
+<path d="M 288 120 A 4 4 0 0 0 292 116" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="156" y1="408" y2="408"/>
+<line x1="156" x2="156" y1="304" y2="408"/>
+<line x1="156" x2="176" y1="408" y2="408"/>
+<path d="M 180 412 A 4 4 0 0 0 176 408" fill="none"/>
+</g>
+<g>
+<line x1="136" x2="176" y1="440" y2="440"/>
+<path d="M 176 440 A 4 4 0 0 0 180 436" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="156" x2="156" y1="144" y2="132"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="156" x2="156" y1="304" y2="292"/>
+</g>
+<g>
+<line x1="180" x2="180" y1="412" y2="424"/>
+<line x1="180" x2="180" y1="424" y2="436"/>
+<line marker-end="url(#triangle)" x1="180" x2="220" y1="424" y2="424"/>
+</g>
+<g>
+<line x1="188" x2="188" y1="236" y2="276"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="200" x2="196" y1="248" y2="248"/>
+<line x1="200" x2="212" y1="248" y2="248"/>
+<line x1="212" x2="212" y1="236" y2="248"/>
+<line x1="212" x2="212" y1="248" y2="276"/>
+<path d="M 212 276 A 4 4 0 0 0 216 280" fill="none"/>
+<path d="M 216 232 A 4 4 0 0 0 212 236" fill="none"/>
+</g>
+<g>
+<line x1="204" x2="204" y1="156" y2="180"/>
+<path d="M 204 180 A 4 4 0 0 0 208 184" fill="none"/>
+<path d="M 208 152 A 4 4 0 0 0 204 156" fill="none"/>
+</g>
+<g>
+<line x1="208" x2="336" y1="152" y2="152"/>
+<path d="M 340 156 A 4 4 0 0 0 336 152" fill="none"/>
+</g>
+<g>
+<line x1="208" x2="336" y1="184" y2="184"/>
+<path d="M 336 184 A 4 4 0 0 0 340 180" fill="none"/>
+</g>
+<g>
+<line x1="216" x2="252" y1="232" y2="232"/>
+<line x1="252" x2="252" y1="208" y2="232"/>
+<line x1="252" x2="280" y1="232" y2="232"/>
+<path d="M 284 236 A 4 4 0 0 0 280 232" fill="none"/>
+</g>
+<g>
+<line x1="216" x2="280" y1="280" y2="280"/>
+<path d="M 280 280 A 4 4 0 0 0 284 276" fill="none"/>
+</g>
+<g>
+<line x1="228" x2="228" y1="412" y2="452"/>
+<path d="M 228 452 A 4 4 0 0 0 232 456" fill="none"/>
+<path d="M 232 408 A 4 4 0 0 0 228 412" fill="none"/>
+</g>
+<g>
+<line x1="232" x2="292" y1="408" y2="408"/>
+<line x1="292" x2="292" y1="384" y2="408"/>
+<line x1="292" x2="320" y1="408" y2="408"/>
+<path d="M 324 412 A 4 4 0 0 0 320 408" fill="none"/>
+</g>
+<g>
+<line x1="232" x2="320" y1="456" y2="456"/>
+<path d="M 320 456 A 4 4 0 0 0 324 452" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="252" x2="252" y1="208" y2="196"/>
+</g>
+<g>
+<line x1="252" x2="252" y1="332" y2="356"/>
+<path d="M 252 356 A 4 4 0 0 0 256 360" fill="none"/>
+<path d="M 256 328 A 4 4 0 0 0 252 332" fill="none"/>
+</g>
+<g>
+<line x1="256" x2="276" y1="328" y2="328"/>
+<line x1="276" x2="276" y1="304" y2="328"/>
+<line x1="276" x2="344" y1="328" y2="328"/>
+<path d="M 348 332 A 4 4 0 0 0 344 328" fill="none"/>
+</g>
+<g>
+<line x1="256" x2="344" y1="360" y2="360"/>
+<path d="M 344 360 A 4 4 0 0 0 348 356" fill="none"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="276" x2="276" y1="304" y2="292"/>
+</g>
+<g>
+<line x1="284" x2="284" y1="236" y2="276"/>
+</g>
+<g>
+<line x1="292" x2="292" y1="60" y2="116"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="292" x2="292" y1="384" y2="372"/>
+</g>
+<g>
+<line x1="300" x2="300" y1="236" y2="276"/>
+<path d="M 300 276 A 4 4 0 0 0 304 280" fill="none"/>
+<path d="M 304 232 A 4 4 0 0 0 300 236" fill="none"/>
+</g>
+<g>
+<line x1="304" x2="392" y1="232" y2="232"/>
+<path d="M 396 236 A 4 4 0 0 0 392 232" fill="none"/>
+</g>
+<g>
+<line x1="304" x2="324" y1="280" y2="280"/>
+<line marker-end="url(#triangle)" x1="324" x2="324" y1="280" y2="316"/>
+<line x1="324" x2="392" y1="280" y2="280"/>
+<path d="M 392 280 A 4 4 0 0 0 396 276" fill="none"/>
+</g>
+<g>
+<line x1="324" x2="324" y1="412" y2="424"/>
+<line x1="324" x2="324" y1="424" y2="452"/>
+<line marker-end="url(#triangle)" x1="324" x2="452" y1="424" y2="424"/>
+</g>
+<g>
+<line x1="340" x2="340" y1="156" y2="180"/>
+</g>
+<g>
+<line x1="348" x2="348" y1="332" y2="356"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="352" x2="348" y1="168" y2="168"/>
+<line x1="352" x2="436" y1="168" y2="168"/>
+</g>
+<g>
+<line x1="396" x2="396" y1="236" y2="276"/>
+</g>
+<g>
+<line marker-end="url(#triangle)" x1="408" x2="404" y1="248" y2="248"/>
+<line x1="408" x2="460" y1="248" y2="248"/>
+<line x1="460" x2="460" y1="220" y2="248"/>
+<line x1="460" x2="460" y1="248" y2="292"/>
+<path d="M 460 292 A 4 4 0 0 0 464 296" fill="none"/>
+<path d="M 464 216 A 4 4 0 0 0 460 220" fill="none"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="12" y2="160"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="176" y2="240"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="256" y2="416"/>
+</g>
+<g>
+<line x1="420" x2="420" y1="432" y2="468"/>
+</g>
+<g>
+<line x1="436" x2="436" y1="156" y2="240"/>
+<path d="M 440 152 A 4 4 0 0 0 436 156" fill="none"/>
+</g>
+<g>
+<line x1="436" x2="436" y1="256" y2="416"/>
+</g>
+<g>
+<line x1="436" x2="436" y1="432" y2="452"/>
+<path d="M 436 452 A 4 4 0 0 0 440 456" fill="none"/>
+</g>
+<g>
+<line x1="440" x2="584" y1="152" y2="152"/>
+<path d="M 588 156 A 4 4 0 0 0 584 152" fill="none"/>
+</g>
+<g>
+<line x1="440" x2="584" y1="456" y2="456"/>
+<path d="M 584 456 A 4 4 0 0 0 588 452" fill="none"/>
+</g>
+<g>
+<line x1="460" x2="460" y1="364" y2="436"/>
+<path d="M 460 436 A 4 4 0 0 0 464 440" fill="none"/>
+<path d="M 464 360 A 4 4 0 0 0 460 364" fill="none"/>
+</g>
+<g>
+<line x1="464" x2="560" y1="216" y2="216"/>
+<path d="M 564 220 A 4 4 0 0 0 560 216" fill="none"/>
+</g>
+<g>
+<line x1="464" x2="560" y1="296" y2="296"/>
+<path d="M 560 296 A 4 4 0 0 0 564 292" fill="none"/>
+</g>
+<g>
+<line x1="464" x2="560" y1="360" y2="360"/>
+<path d="M 564 364 A 4 4 0 0 0 560 360" fill="none"/>
+</g>
+<g>
+<line x1="464" x2="560" y1="440" y2="440"/>
+<path d="M 560 440 A 4 4 0 0 0 564 436" fill="none"/>
+</g>
+<g>
+<line x1="564" x2="564" y1="220" y2="292"/>
+</g>
+<g>
+<line x1="564" x2="564" y1="364" y2="436"/>
+</g>
+<g>
+<line x1="588" x2="588" y1="156" y2="452"/>
+</g>
+<g>
+<text x="25" y="92">
+Client
+</text>
+</g>
+<g>
+<text x="129" y="28">
+Validator
+</text>
+</g>
+<g>
+<text x="137" y="252">
+Bank
+</text>
+</g>
+<g>
+<text x="137" y="268">
+Forks
+</text>
+</g>
+<g>
+<text x="145" y="92">
+JSON
+</text>
+</g>
+<g>
+<text x="145" y="428">
+TPU
+</text>
+</g>
+<g>
+<text x="185" y="92">
+RPC
+</text>
+</g>
+<g>
+<text x="217" y="92">
+Service
+</text>
+</g>
+<g>
+<text x="217" y="172">
+Gossip
+</text>
+</g>
+<g>
+<text x="225" y="252">
+Replay
+</text>
+</g>
+<g>
+<text x="225" y="268">
+Stage
+</text>
+</g>
+<g>
+<text x="241" y="428">
+Broadcast
+</text>
+</g>
+<g>
+<text x="241" y="444">
+Stage
+</text>
+</g>
+<g>
+<text x="265" y="348">
+Blocktree
+</text>
+</g>
+<g>
+<text x="273" y="172">
+Service
+</text>
+</g>
+<g>
+<text x="313" y="252">
+BlobFetch
+</text>
+</g>
+<g>
+<text x="321" y="268">
+Stage
+</text>
+</g>
+<g>
+<text x="449" y="172">
+Validators
+</text>
+</g>
+<g>
+<text x="473" y="252">
+Upstream
+</text>
+</g>
+<g>
+<text x="473" y="268">
+Validators
+</text>
+</g>
+<g>
+<text x="473" y="396">
+Downstream
+</text>
+</g>
+<g>
+<text x="473" y="412">
+Validators
+</text>
+</g>
+</svg>

book/src/SUMMARY.md

@@ -1,79 +1,81 @@
-# Solana Architecture
+# Table of contents
 
-- [Introduction](introduction.md)
+* [Introduction](introduction.md)
+* [Terminology](terminology.md)
+* [Getting Started](getting-started/README.md)
+  * [Testnet Participation](getting-started/testnet-participation.md)
+  * [Example Client: Web Wallet](getting-started/webwallet.md)
+* [Programming Model](programs/README.md)
+  * [Example: Tic-Tac-Toe](programs/tictactoe.md)
+  * [Drones](programs/drones.md)
+* [A Solana Cluster](cluster/README.md)
+  * [Synchronization](cluster/synchronization.md)
+  * [Leader Rotation](cluster/leader-rotation.md)
+  * [Fork Generation](cluster/fork-generation.md)
+  * [Managing Forks](cluster/managing-forks.md)
+  * [Turbine Block Propagation](cluster/turbine-block-propagation.md)
+  * [Ledger Replication](cluster/ledger-replication.md)
+  * [Secure Vote Signing](cluster/vote-signing.md)
+  * [Stake Delegation and Rewards](cluster/stake-delegation-and-rewards.md)
+  * [Performance Metrics](cluster/performance-metrics.md)
+* [Anatomy of a Validator](validator/README.md)
+  * [TPU](validator/tpu.md)
+  * [TVU](validator/tvu/README.md)
+    * [Blocktree](validator/tvu/blocktree.md)
+  * [Gossip Service](validator/gossip.md)
+  * [The Runtime](validator/runtime.md)
+* [Anatomy of a Transaction](transaction.md)
+* [Running a Validator](running-validator/README.md)
+  * [Hardware Requirements](running-validator/validator-hardware.md)
+  * [Choosing a Testnet](running-validator/validator-testnet.md)
+  * [Installing the Validator Software](running-validator/validator-software.md)
+  * [Starting a Validator](running-validator/validator-start.md)
+  * [Staking](running-validator/validator-stake.md)
+  * [Monitoring a Validator](running-validator/validator-monitor.md)
+  * [Publishing Validator Info](running-validator/validator-info.md)
+  * [Troubleshooting](running-validator/validator-troubleshoot.md)
+  * [FAQ](running-validator/validator-faq.md)
+* [Running a Replicator](running-replicator.md)
+* [API Reference](api-reference/README.md)
+  * [Transaction](api-reference/transaction-api.md)
+  * [Instruction](api-reference/instruction-api.md)
+  * [Blockstreamer](api-reference/blockstreamer.md)
+  * [JSON RPC API](api-reference/jsonrpc-api.md)
+  * [JavaScript API](api-reference/javascript-api.md)
+  * [solana CLI](api-reference/cli.md)
+* [Accepted Design Proposals](proposals/README.md)
+  * [Ledger Replication](proposals/ledger-replication-to-implement.md)
+  * [Secure Vote Signing](proposals/vote-signing-to-implement.md)
+  * [Staking Rewards](proposals/staking-rewards.md)
+  * [Cluster Economics](proposals/ed_overview/README.md)
+    * [Validation-client Economics](proposals/ed_overview/ed_validation_client_economics/README.md)
+      * [State-validation Protocol-based Rewards](proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md)
+      * [State-validation Transaction Fees](proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md)
+      * [Replication-validation Transaction Fees](proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md)
+      * [Validation Stake Delegation](proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md)
+    * [Replication-client Economics](proposals/ed_overview/ed_replication_client_economics/README.md)
+      * [Storage-replication Rewards](proposals/ed_overview/ed_replication_client_economics/ed_rce_storage_replication_rewards.md)
+      * [Replication-client Reward Auto-delegation](proposals/ed_overview/ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md)
+    * [Economic Sustainability](proposals/ed_overview/ed_economic_sustainability.md)
+    * [Attack Vectors](proposals/ed_overview/ed_attack_vectors.md)
+    * [Economic Design MVP](proposals/ed_overview/ed_mvp.md)
+    * [References](proposals/ed_overview/ed_references.md)
+  * [Cluster Test Framework](proposals/cluster-test-framework.md)
+  * [Validator](proposals/validator-proposal.md)
+  * [Simple Payment and State Verification](proposals/simple-payment-and-state-verification.md)
+  * [Cross-Program Invocation](proposals/cross-program-invocation.md)
+* [Implemented Design Proposals](implemented-proposals/README.md)
+  * [Blocktree](implemented-proposals/blocktree.md)
+  * [Cluster Software Installation and Updates](implemented-proposals/installer.md)
+  * [Deterministic Transaction Fees](implemented-proposals/transaction-fees.md)
+  * [Tower BFT](implemented-proposals/tower-bft.md)
+  * [Leader-to-Leader Transition](implemented-proposals/leader-leader-transition.md)
+  * [Leader-to-Validator Transition](implemented-proposals/leader-validator-transition.md)
+  * [Passive Stake Delegation and Rewards](implemented-proposals/passive-stake-delegation-and-rewards.md)
+  * [Persistent Account Storage](implemented-proposals/persistent-account-storage.md)
+  * [Reliable Vote Transmission](implemented-proposals/reliable-vote-transmission.md)
+  * [Repair Service](implemented-proposals/repair-service.md)
+  * [Testing Programs](implemented-proposals/testing-programs.md)
+  * [Credit-only Accounts](implemented-proposals/credit-only-credit-debit-accounts.md)
+  * [Embedding the Move Langauge](implemented-proposals/embedding-move.md)
 
-- [Terminology](terminology.md)
-
-- [Getting Started](getting-started.md)
-  - [Testnet Participation](testnet-participation.md)
-  - [Testnet Replicator](testnet-replicator.md)
-  - [Example: Web Wallet](webwallet.md)
-
-- [Programming Model](programs.md)
-  - [Example: Tic-Tac-Toe](tictactoe.md)
-  - [Drones](drones.md)
-
-- [A Solana Cluster](cluster.md)
-  - [Synchronization](synchronization.md)
-  - [Leader Rotation](leader-rotation.md)
-  - [Fork Generation](fork-generation.md)
-  - [Managing Forks](managing-forks.md)
-  - [Turbine Block Propagation](turbine-block-propagation.md)
-  - [Ledger Replication](ledger-replication.md)
-  - [Secure Vote Signing](vote-signing.md)
-  - [Stake Delegation and Rewards](stake-delegation-and-rewards.md)
-  - [Performance Metrics](performance-metrics.md)
-
-- [Anatomy of a Validator](validator.md)
-  - [TPU](tpu.md)
-  - [TVU](tvu.md)
-    - [Blocktree](blocktree.md)
-  - [Gossip Service](gossip.md)
-  - [The Runtime](runtime.md)
-  
-- [Anatomy of a Transaction](transaction.md)
-
-- [API Reference](api-reference.md)
-  - [Transaction](transaction-api.md)
-  - [Instruction](instruction-api.md)
-  - [Blockstreamer](blockstreamer.md)
-  - [JSON RPC API](jsonrpc-api.md)
-  - [JavaScript API](javascript-api.md)
-  - [solana-wallet CLI](wallet.md)
-
-- [Accepted Design Proposals](proposals.md)
-  - [Ledger Replication](ledger-replication-to-implement.md)
-  - [Secure Vote Signing](vote-signing-to-implement.md)
-  - [Staking Rewards](staking-rewards.md)
-  - [Cluster Economics](ed_overview.md)
-    - [Validation-client Economics](ed_validation_client_economics.md)
-      - [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md)
-      - [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md)
-      - [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md)
-      - [Validation Stake Delegation](ed_vce_validation_stake_delegation.md)
-    - [Replication-client Economics](ed_replication_client_economics.md)
-      - [Storage-replication Rewards](ed_rce_storage_replication_rewards.md)
-      - [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md)
-    - [Economic Sustainability](ed_economic_sustainability.md)
-    - [Attack Vectors](ed_attack_vectors.md)
-	- [Economic Design MVP](ed_mvp.md)
-    - [References](ed_references.md)
-  - [Cluster Test Framework](cluster-test-framework.md)
-  - [Credit-only Accounts](credit-only-credit-debit-accounts.md)
-  - [Validator](validator-proposal.md)
-  - [Simple Payment and State Verification](simple-payment-and-state-verification.md)
-  - [Embedding the Move Langauge](embedding-move.md)
-  - [Cross-Program Invocation](cross-program-invocation.md)
-
-- [Implemented Design Proposals](implemented-proposals.md)
-  - [Blocktree](blocktree.md)
-  - [Cluster Software Installation and Updates](installer.md)
-  - [Deterministic Transaction Fees](transaction-fees.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)

book/src/api-reference/README.md

@@ -0,0 +1,4 @@
+# API Reference
+
+The following sections contain API references material you may find useful when developing applications utilizing a Solana cluster.
+

book/src/api-reference/blockstreamer.md

@@ -0,0 +1,28 @@
+# Blockstreamer
+
+Solana supports a node type called an _blockstreamer_. This fullnode variation is intended for applications that need to observe the data plane without participating in transaction validation or ledger replication.
+
+A blockstreamer runs without a vote signer, and can optionally stream ledger entries out to a Unix domain socket as they are processed. The JSON-RPC service still functions as on any other node.
+
+To run a blockstreamer, include the argument `no-signer` and \(optional\) `blockstream` socket location:
+
+```bash
+$ ./multinode-demo/validator-x.sh --no-signer --blockstream <SOCKET>
+```
+
+The stream will output a series of JSON objects:
+
+* An Entry event JSON object is sent when each ledger entry is processed, with the following fields:
+  * `dt`, the system datetime, as RFC3339-formatted string
+  * `t`, the event type, always "entry"
+  * `s`, the slot height, as unsigned 64-bit integer
+  * `h`, the tick height, as unsigned 64-bit integer
+  * `entry`, the entry, as JSON object
+* A Block event JSON object is sent when a block is complete, with the following fields:
+  * `dt`, the system datetime, as RFC3339-formatted string
+  * `t`, the event type, always "block"
+  * `s`, the slot height, as unsigned 64-bit integer
+  * `h`, the tick height, as unsigned 64-bit integer
+  * `l`, the slot leader id, as base-58 encoded string
+  * `id`, the block id, as base-58 encoded string
+

book/src/api-reference/cli.md

@@ -1,98 +1,100 @@
-## solana-wallet CLI
+# solana CLI
 
-The [solana crate](https://crates.io/crates/solana) is distributed with a command-line interface tool
+The [solana-cli crate](https://crates.io/crates/solana-cli) provides a command-line interface tool for Solana
 
-### Examples
+## Examples
 
-#### Get Pubkey
+### Get Pubkey
 
-```sh
+```bash
 // Command
-$ solana-wallet address
+$ solana address
 
 // Return
 <PUBKEY>
 ```
 
-#### Airdrop Lamports
+### Airdrop Lamports
 
-```sh
+```bash
 // Command
-$ solana-wallet airdrop 123
+$ solana airdrop 123
 
 // Return
 "Your balance is: 123"
 ```
 
-#### Get Balance
+### Get Balance
 
-```sh
+```bash
 // Command
-$ solana-wallet balance
+$ solana balance
 
 // Return
 "Your balance is: 123"
 ```
 
-#### Confirm Transaction
+### Confirm Transaction
 
-```sh
+```bash
 // Command
-$ solana-wallet confirm <TX_SIGNATURE>
+$ solana confirm <TX_SIGNATURE>
 
 // Return
 "Confirmed" / "Not found" / "Transaction failed with error <ERR>"
 ```
 
-#### Deploy program
+### Deploy program
 
-```sh
+```bash
 // Command
-$ solana-wallet deploy <PATH>
+$ solana deploy <PATH>
 
 // Return
 <PROGRAM_ID>
 ```
 
-#### Unconditional Immediate Transfer
+### Unconditional Immediate Transfer
 
-```sh
+```bash
 // Command
-$ solana-wallet pay <PUBKEY> 123
+$ solana pay <PUBKEY> 123
 
 // Return
 <TX_SIGNATURE>
 ```
 
-#### Post-Dated Transfer
+### Post-Dated Transfer
 
-```sh
+```bash
 // Command
-$ solana-wallet pay <PUBKEY> 123 \
+$ solana pay <PUBKEY> 123 \
     --after 2018-12-24T23:59:00 --require-timestamp-from <PUBKEY>
 
 // Return
 {signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
 ```
-*`require-timestamp-from` is optional. If not provided, the transaction will expect a timestamp signed by this wallet's secret key*
 
-#### Authorized Transfer
+_`require-timestamp-from` is optional. If not provided, the transaction will expect a timestamp signed by this wallet's secret key_
+
+### Authorized Transfer
 
 A third party must send a signature to unlock the lamports.
-```sh
+
+```bash
 // Command
-$ solana-wallet pay <PUBKEY> 123 \
+$ solana pay <PUBKEY> 123 \
     --require-signature-from <PUBKEY>
 
 // Return
 {signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
 ```
 
-#### Post-Dated and Authorized Transfer
+### Post-Dated and Authorized Transfer
 
-```sh
+```bash
 // Command
-$ solana-wallet pay <PUBKEY> 123 \
+$ solana pay <PUBKEY> 123 \
     --after 2018-12-24T23:59 --require-timestamp-from <PUBKEY> \
     --require-signature-from <PUBKEY>
 
@@ -100,11 +102,11 @@ $ solana-wallet pay <PUBKEY> 123 \
 {signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
 ```
 
-#### Multiple Witnesses
+### Multiple Witnesses
 
-```sh
+```bash
 // Command
-$ solana-wallet pay <PUBKEY> 123 \
+$ solana pay <PUBKEY> 123 \
     --require-signature-from <PUBKEY> \
     --require-signature-from <PUBKEY>
 
@@ -112,11 +114,11 @@ $ solana-wallet pay <PUBKEY> 123 \
 {signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
 ```
 
-#### Cancelable Transfer
+### Cancelable Transfer
 
-```sh
+```bash
 // Command
-$ solana-wallet pay <PUBKEY> 123 \
+$ solana pay <PUBKEY> 123 \
     --require-signature-from <PUBKEY> \
     --cancelable
 
@@ -124,32 +126,33 @@ $ solana-wallet pay <PUBKEY> 123 \
 {signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
 ```
 
-#### Cancel Transfer
+### Cancel Transfer
 
-```sh
+```bash
 // Command
-$ solana-wallet cancel <PROCESS_ID>
+$ solana cancel <PROCESS_ID>
 
 // Return
 <TX_SIGNATURE>
 ```
 
-#### Send Signature
+### Send Signature
 
-```sh
+```bash
 // Command
-$ solana-wallet send-signature <PUBKEY> <PROCESS_ID>
+$ solana send-signature <PUBKEY> <PROCESS_ID>
 
 // Return
 <TX_SIGNATURE>
 ```
 
-#### Indicate Elapsed Time
+### Indicate Elapsed Time
 
 Use the current system time:
-```sh
+
+```bash
 // Command
-$ solana-wallet send-timestamp <PUBKEY> <PROCESS_ID>
+$ solana send-timestamp <PUBKEY> <PROCESS_ID>
 
 // Return
 <TX_SIGNATURE>
@@ -157,21 +160,21 @@ $ solana-wallet send-timestamp <PUBKEY> <PROCESS_ID>
 
 Or specify some other arbitrary timestamp:
 
-```sh
+```bash
 // Command
-$ solana-wallet send-timestamp <PUBKEY> <PROCESS_ID> --date 2018-12-24T23:59:00
+$ solana send-timestamp <PUBKEY> <PROCESS_ID> --date 2018-12-24T23:59:00
 
 // Return
 <TX_SIGNATURE>
 ```
 
-### Usage
+## Usage
 
-```manpage
-solana-wallet 0.12.0
+```text
+solana 0.12.0
 
 USAGE:
-    solana-wallet [FLAGS] [OPTIONS] [SUBCOMMAND]
+    solana [FLAGS] [OPTIONS] [SUBCOMMAND]
 
 FLAGS:
     -h, --help       Prints help information
@@ -200,24 +203,24 @@ SUBCOMMANDS:
     send-timestamp           Send a timestamp to unlock a transfer
 ```
 
-```manpage
-solana-wallet-address
+```text
+solana-address
 Get your public key
 
 USAGE:
-    solana-wallet address
+    solana address
 
 FLAGS:
     -h, --help       Prints help information
     -V, --version    Prints version information
 ```
 
-```manpage
-solana-wallet-airdrop
+```text
+solana-airdrop
 Request a batch of lamports
 
 USAGE:
-    solana-wallet airdrop <NUM>
+    solana airdrop <NUM>
 
 FLAGS:
     -h, --help       Prints help information
@@ -227,24 +230,24 @@ ARGS:
     <NUM>    The number of lamports to request
 ```
 
-```manpage
-solana-wallet-balance
+```text
+solana-balance
 Get your balance
 
 USAGE:
-    solana-wallet balance
+    solana balance
 
 FLAGS:
     -h, --help       Prints help information
     -V, --version    Prints version information
 ```
 
-```manpage
-solana-wallet-cancel
+```text
+solana-cancel
 Cancel a transfer
 
 USAGE:
-    solana-wallet cancel <PROCESS_ID>
+    solana cancel <PROCESS_ID>
 
 FLAGS:
     -h, --help       Prints help information
@@ -254,12 +257,12 @@ ARGS:
     <PROCESS_ID>    The process id of the transfer to cancel
 ```
 
-```manpage
-solana-wallet-confirm
+```text
+solana-confirm
 Confirm transaction by signature
 
 USAGE:
-    solana-wallet confirm <SIGNATURE>
+    solana confirm <SIGNATURE>
 
 FLAGS:
     -h, --help       Prints help information
@@ -269,12 +272,12 @@ ARGS:
     <SIGNATURE>    The transaction signature to confirm
 ```
 
-```manpage
-solana-wallet-deploy
+```text
+solana-deploy
 Deploy a program
 
 USAGE:
-    solana-wallet deploy <PATH>
+    solana deploy <PATH>
 
 FLAGS:
     -h, --help       Prints help information
@@ -284,36 +287,36 @@ ARGS:
     <PATH>    /path/to/program.o
 ```
 
-```manpage
-solana-wallet-fees
+```text
+solana-fees
 Display current cluster fees
 
 USAGE:
-    solana-wallet fees
+    solana fees
 
 FLAGS:
     -h, --help       Prints help information
     -V, --version    Prints version information
 ```
 
-```manpage
-solana-wallet-get-transaction-count
+```text
+solana-get-transaction-count
 Get current transaction count
 
 USAGE:
-    solana-wallet get-transaction-count
+    solana get-transaction-count
 
 FLAGS:
     -h, --help       Prints help information
     -V, --version    Prints version information
 ```
 
-```manpage
-solana-wallet-pay
+```text
+solana-pay
 Send a payment
 
 USAGE:
-    solana-wallet pay [FLAGS] [OPTIONS] <PUBKEY> <NUM>
+    solana pay [FLAGS] [OPTIONS] <PUBKEY> <NUM>
 
 FLAGS:
         --cancelable
@@ -330,12 +333,12 @@ ARGS:
     <NUM>       The number of lamports to send
 ```
 
-```manpage
-solana-wallet-send-signature
+```text
+solana-send-signature
 Send a signature to authorize a transfer
 
 USAGE:
-    solana-wallet send-signature <PUBKEY> <PROCESS_ID>
+    solana send-signature <PUBKEY> <PROCESS_ID>
 
 FLAGS:
     -h, --help       Prints help information
@@ -346,12 +349,12 @@ ARGS:
     <PROCESS_ID>    The process id of the transfer to authorize
 ```
 
-```manpage
-solana-wallet-send-timestamp
+```text
+solana-send-timestamp
 Send a timestamp to unlock a transfer
 
 USAGE:
-    solana-wallet send-timestamp [OPTIONS] <PUBKEY> <PROCESS_ID>
+    solana send-timestamp [OPTIONS] <PUBKEY> <PROCESS_ID>
 
 FLAGS:
     -h, --help       Prints help information
@@ -364,3 +367,4 @@ ARGS:
     <PUBKEY>        The pubkey of recipient
     <PROCESS_ID>    The process id of the transfer to unlock
 ```
+

book/src/api-reference/instruction-api.md

@@ -0,0 +1,38 @@
+# Instruction
+
+For the purposes of building a [Transaction](../transaction.md), a more verbose instruction format is used:
+
+* **Instruction:**
+  * **program\_id:** The pubkey of the on-chain program that executes the
+
+    instruction
+
+  * **accounts:** An ordered list of accounts that should be passed to
+
+    the program processing the instruction, including metadata detailing
+
+    if an account is a signer of the transaction and if it is a credit
+
+    only account.
+
+  * **data:** A byte array that is passed to the program executing the
+
+    instruction
+
+A more compact form is actually included in a `Transaction`:
+
+* **CompiledInstruction:**
+  * **program\_id\_index:** The index of the `program_id` in the
+
+    `account_keys` list
+
+  * **accounts:** An ordered list of indices into `account_keys`
+
+    specifying the accounds that should be passed to the program
+
+    processing the instruction.
+
+  * **data:** A byte array that is passed to the program executing the
+
+    instruction
+

book/src/api-reference/javascript-api.md

@@ -0,0 +1,4 @@
+# JavaScript API
+
+See [solana-web3](https://solana-labs.github.io/solana-web3.js/).
+

book/src/api-reference/jsonrpc-api.md

@@ -0,0 +1,788 @@
+# JSON RPC API
+
+Solana nodes accept HTTP requests using the [JSON-RPC 2.0](https://www.jsonrpc.org/specification) specification.
+
+To interact with a Solana node inside a JavaScript application, use the [solana-web3.js](https://github.com/solana-labs/solana-web3.js) library, which gives a convenient interface for the RPC methods.
+
+## RPC HTTP Endpoint
+
+**Default port:** 8899 eg. [http://localhost:8899](http://localhost:8899), [http://192.168.1.88:8899](http://192.168.1.88:8899)
+
+## RPC PubSub WebSocket Endpoint
+
+**Default port:** 8900 eg. ws://localhost:8900, [http://192.168.1.88:8900](http://192.168.1.88:8900)
+
+## Methods
+
+* [confirmTransaction](jsonrpc-api.md#confirmtransaction)
+* [getAccountInfo](jsonrpc-api.md#getaccountinfo)
+* [getBalance](jsonrpc-api.md#getbalance)
+* [getClusterNodes](jsonrpc-api.md#getclusternodes)
+* [getEpochInfo](jsonrpc-api.md#getepochinfo)
+* [getGenesisBlockhash](jsonrpc-api.md#getgenesisblockhash)
+* [getLeaderSchedule](jsonrpc-api.md#getleaderschedule)
+* [getProgramAccounts](jsonrpc-api.md#getprogramaccounts)
+* [getRecentBlockhash](jsonrpc-api.md#getrecentblockhash)
+* [getSignatureStatus](jsonrpc-api.md#getsignaturestatus)
+* [getSlot](jsonrpc-api.md#getslot)
+* [getSlotLeader](jsonrpc-api.md#getslotleader)
+* [getSlotsPerSegment](jsonrpc-api.md#getslotspersegment)
+* [getStorageTurn](jsonrpc-api.md#getstorageturn)
+* [getStorageTurnRate](jsonrpc-api.md#getstorageturnrate)
+* [getNumBlocksSinceSignatureConfirmation](jsonrpc-api.md#getnumblockssincesignatureconfirmation)
+* [getTransactionCount](jsonrpc-api.md#gettransactioncount)
+* [getTotalSupply](jsonrpc-api.md#gettotalsupply)
+* [getVersion](jsonrpc-api.md#getversion)
+* [getVoteAccounts](jsonrpc-api.md#getvoteaccounts)
+* [requestAirdrop](jsonrpc-api.md#requestairdrop)
+* [sendTransaction](jsonrpc-api.md#sendtransaction)
+* [startSubscriptionChannel](jsonrpc-api.md#startsubscriptionchannel)
+* [Subscription Websocket](jsonrpc-api.md#subscription-websocket)
+  * [accountSubscribe](jsonrpc-api.md#accountsubscribe)
+  * [accountUnsubscribe](jsonrpc-api.md#accountunsubscribe)
+  * [programSubscribe](jsonrpc-api.md#programsubscribe)
+  * [programUnsubscribe](jsonrpc-api.md#programunsubscribe)
+  * [signatureSubscribe](jsonrpc-api.md#signaturesubscribe)
+  * [signatureUnsubscribe](jsonrpc-api.md#signatureunsubscribe)
+
+## Request Formatting
+
+To make a JSON-RPC request, send an HTTP POST request with a `Content-Type: application/json` header. The JSON request data should contain 4 fields:
+
+* `jsonrpc`, set to `"2.0"`
+* `id`, a unique client-generated identifying integer
+* `method`, a string containing the method to be invoked
+* `params`, a JSON array of ordered parameter values
+
+Example using curl:
+
+```bash
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getBalance", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"]}' 192.168.1.88:8899
+```
+
+The response output will be a JSON object with the following fields:
+
+* `jsonrpc`, matching the request specification
+* `id`, matching the request identifier
+* `result`, requested data or success confirmation
+
+Requests can be sent in batches by sending an array of JSON-RPC request objects as the data for a single POST.
+
+## Definitions
+
+* Hash: A SHA-256 hash of a chunk of data.
+* Pubkey: The public key of a Ed25519 key-pair.
+* Signature: An Ed25519 signature of a chunk of data.
+* Transaction: A Solana instruction signed by a client key-pair.
+
+## JSON RPC API Reference
+
+### confirmTransaction
+
+Returns a transaction receipt
+
+#### Parameters:
+
+* `string` - Signature of Transaction to confirm, as base-58 encoded string
+
+#### Results:
+
+* `boolean` - Transaction status, true if Transaction is confirmed
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"confirmTransaction", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":true,"id":1}
+```
+
+### getAccountInfo
+
+Returns all information associated with the account of provided Pubkey
+
+#### Parameters:
+
+* `string` - Pubkey of account to query, as base-58 encoded string
+
+#### Results:
+
+The result field will be a JSON object with the following sub fields:
+
+* `lamports`, number of lamports assigned to this account, as a signed 64-bit integer
+* `owner`, array of 32 bytes representing the program this account has been assigned to
+* `data`, array of bytes representing any data associated with the account
+* `executable`, boolean indicating if the account contains a program \(and is strictly read-only\)
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getAccountInfo", "params":["2gVkYWexTHR5Hb2aLeQN3tnngvWzisFKXDUPrgMHpdST"]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":{"executable":false,"owner":[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"lamports":1,"data":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]},"id":1}
+```
+
+### getBalance
+
+Returns the balance of the account of provided Pubkey
+
+#### Parameters:
+
+* `string` - Pubkey of account to query, as base-58 encoded string
+
+#### Results:
+
+* `integer` - quantity, as a signed 64-bit integer
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getBalance", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":0,"id":1}
+```
+
+### getClusterNodes
+
+Returns information about all the nodes participating in the cluster
+
+#### Parameters:
+
+None
+
+#### Results:
+
+The result field will be an array of JSON objects, each with the following sub fields:
+
+* `pubkey` - Node public key, as base-58 encoded string
+* `gossip` - Gossip network address for the node
+* `tpu` - TPU network address for the node
+* `rpc` - JSON RPC network address for the node, or `null` if the JSON RPC service is not enabled
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getClusterNodes"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":[{"gossip":"10.239.6.48:8001","pubkey":"9QzsJf7LPLj8GkXbYT3LFDKqsj2hHG7TA3xinJHu8epQ","rpc":"10.239.6.48:8899","tpu":"10.239.6.48:8856"}],"id":1}
+```
+
+### getEpochInfo
+
+Returns information about the current epoch
+
+#### Parameters:
+
+None
+
+#### Results:
+
+The result field will be an object with the following fields:
+
+* `epoch`, the current epoch
+* `slotIndex`, the current slot relative to the start of the current epoch
+* `slotsInEpoch`, the number of slots in this epoch
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochInfo"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":{"epoch":3,"slotIndex":126,"slotsInEpoch":256},"id":1}
+```
+
+### getGenesisBlockhash
+
+Returns the genesis block hash
+
+#### Parameters:
+
+None
+
+#### Results:
+
+* `string` - a Hash as base-58 encoded string
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getGenesisBlockhash"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC","id":1}
+```
+
+### getLeaderSchedule
+
+Returns the leader schedule for the current epoch
+
+#### Parameters:
+
+None
+
+#### Results:
+
+The result field will be an array of leader public keys \(as base-58 encoded strings\) for each slot in the current epoch
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getLeaderSchedule"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":[...],"id":1}
+```
+
+### getProgramAccounts
+
+Returns all accounts owned by the provided program Pubkey
+
+#### Parameters:
+
+* `string` - Pubkey of program, as base-58 encoded string
+
+#### Results:
+
+The result field will be an array of arrays. Each sub array will contain:
+
+* `string` - the account Pubkey as base-58 encoded string and a JSON object, with the following sub fields:
+* `lamports`, number of lamports assigned to this account, as a signed 64-bit integer
+* `owner`, array of 32 bytes representing the program this account has been assigned to
+* `data`, array of bytes representing any data associated with the account
+* `executable`, boolean indicating if the account contains a program \(and is strictly read-only\)
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getProgramAccounts", "params":["8nQwAgzN2yyUzrukXsCa3JELBYqDQrqJ3UyHiWazWxHR"]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":[["BqGKYtAKu69ZdWEBtZHh4xgJY1BYa2YBiBReQE3pe383", {"executable":false,"owner":[50,28,250,90,221,24,94,136,147,165,253,136,1,62,196,215,225,34,222,212,99,84,202,223,245,13,149,99,149,231,91,96],"lamports":1,"data":[]], ["4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T", {"executable":false,"owner":[50,28,250,90,221,24,94,136,147,165,253,136,1,62,196,215,225,34,222,212,99,84,202,223,245,13,149,99,149,231,91,96],"lamports":10,"data":[]]]},"id":1}
+```
+
+### getRecentBlockhash
+
+Returns a recent block hash from the ledger, and a fee schedule that can be used to compute the cost of submitting a transaction using it.
+
+#### Parameters:
+
+None
+
+#### Results:
+
+An array consisting of
+
+* `string` - a Hash as base-58 encoded string
+* `FeeCalculator object` - the fee schedule for this block hash
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getRecentBlockhash"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":["GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC",{"lamportsPerSignature": 0}],"id":1}
+```
+
+### getSignatureStatus
+
+Returns the status of a given signature. This method is similar to [confirmTransaction](jsonrpc-api.md#confirmtransaction) but provides more resolution for error events.
+
+#### Parameters:
+
+* `string` - Signature of Transaction to confirm, as base-58 encoded string
+
+#### Results:
+
+* `null` - Unknown transaction
+* `object` - Transaction status:
+  * `"Ok": null` - Transaction was successful
+  * `"Err": <ERR>` - Transaction failed with TransactionError  [TransactionError definitions](https://github.com/solana-labs/solana/blob/master/sdk/src/transaction.rs#L14)
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getSignatureStatus", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"SignatureNotFound","id":1}
+```
+
+### getSlot
+
+Returns the current slot the node is processing
+
+#### Parameters:
+
+None
+
+#### Results:
+
+* `u64` - Current slot
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getSlot"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"1234","id":1}
+```
+
+### getSlotLeader
+
+Returns the current slot leader
+
+#### Parameters:
+
+None
+
+#### Results:
+
+* `string` - Node Id as base-58 encoded string
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getSlotLeader"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"ENvAW7JScgYq6o4zKZwewtkzzJgDzuJAFxYasvmEQdpS","id":1}
+```
+
+### getSlotsPerSegment
+
+Returns the current storage segment size in terms of slots
+
+#### Parameters:
+
+None
+
+#### Results:
+
+* `u64` - Number of slots in a storage segment
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getSlotsPerSegment"}' http://localhost:8899
+// Result
+{"jsonrpc":"2.0","result":"1024","id":1}
+```
+
+### getStorageTurn
+
+Returns the current storage turn's blockhash and slot
+
+#### Parameters:
+
+None
+
+#### Results:
+
+An array consisting of
+
+* `string` - a Hash as base-58 encoded string indicating the blockhash of the turn slot
+* `u64` - the current storage turn slot
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getStorageTurn"}' http://localhost:8899
+ // Result
+{"jsonrpc":"2.0","result":["GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC", "2048"],"id":1}
+```
+
+### getStorageTurnRate
+
+Returns the current storage turn rate in terms of slots per turn
+
+#### Parameters:
+
+None
+
+#### Results:
+
+* `u64` - Number of slots in storage turn
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getStorageTurnRate"}' http://localhost:8899
+ // Result
+{"jsonrpc":"2.0","result":"1024","id":1}
+```
+
+### getNumBlocksSinceSignatureConfirmation
+
+Returns the current number of blocks since signature has been confirmed.
+
+#### Parameters:
+
+* `string` - Signature of Transaction to confirm, as base-58 encoded string
+
+#### Results:
+
+* `integer` - count, as unsigned 64-bit integer
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getNumBlocksSinceSignatureConfirmation", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":8,"id":1}
+```
+
+### getTransactionCount
+
+Returns the current Transaction count from the ledger
+
+#### Parameters:
+
+None
+
+#### Results:
+
+* `integer` - count, as unsigned 64-bit integer
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getTransactionCount"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":268,"id":1}
+```
+
+### getTotalSupply
+
+Returns the current total supply in Lamports
+
+#### Parameters:
+
+None
+
+#### Results:
+
+* `integer` - Total supply, as unsigned 64-bit integer
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getTotalSupply"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":10126,"id":1}
+```
+
+### getVersion
+
+Returns the current solana versions running on the node
+
+#### Parameters:
+
+None
+
+#### Results:
+
+The result field will be a JSON object with the following sub fields:
+
+* `solana-core`, software version of solana-core
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getVersion"}' http://localhost:8899
+// Result
+{"jsonrpc":"2.0","result":{"solana-core": "0.17.2"},"id":1}
+```
+
+### getVoteAccounts
+
+Returns the account info and associated stake for all the voting accounts in the current bank.
+
+#### Parameters:
+
+None
+
+#### Results:
+
+The result field will be a JSON object of `current` and `delinquent` accounts, each containing an array of JSON objects with the following sub fields:
+
+* `votePubkey` - Vote account public key, as base-58 encoded string
+* `nodePubkey` - Node public key, as base-58 encoded string
+* `activatedStake` - the stake, in lamports, delegated to this vote account and active in this epoch
+* `epochVoteAccount` - bool, whether the vote account is staked for this epoch
+* `commission`, an 8-bit integer used as a fraction \(commission/MAX\_U8\) for rewards payout
+* `lastVote` - Most recent slot voted on by this vote account
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getVoteAccounts"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":{"current":[{"commission":0,"epochVoteAccount":true,"nodePubkey":"B97CCUW3AEZFGy6uUg6zUdnNYvnVq5VG8PUtb2HayTDD","lastVote":147,"activatedStake":42,"votePubkey":"3ZT31jkAGhUaw8jsy4bTknwBMP8i4Eueh52By4zXcsVw"}],"delinquent":[{"commission":127,"epochVoteAccount":false,"nodePubkey":"6ZPxeQaDo4bkZLRsdNrCzchNQr5LN9QMc9sipXv9Kw8f","lastVote":0,"activatedStake":0,"votePubkey":"CmgCk4aMS7KW1SHX3s9K5tBJ6Yng2LBaC8MFov4wx9sm"}]},"id":1}
+```
+
+### requestAirdrop
+
+Requests an airdrop of lamports to a Pubkey
+
+#### Parameters:
+
+* `string` - Pubkey of account to receive lamports, as base-58 encoded string
+* `integer` - lamports, as a signed 64-bit integer
+
+#### Results:
+
+* `string` - Transaction Signature of airdrop, as base-58 encoded string
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"requestAirdrop", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri", 50]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW","id":1}
+```
+
+### sendTransaction
+
+Creates new transaction
+
+#### Parameters:
+
+* `array` - array of octets containing a fully-signed Transaction
+
+#### Results:
+
+* `string` - Transaction Signature, as base-58 encoded string
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"sendTransaction", "params":[[61, 98, 55, 49, 15, 187, 41, 215, 176, 49, 234, 229, 228, 77, 129, 221, 239, 88, 145, 227, 81, 158, 223, 123, 14, 229, 235, 247, 191, 115, 199, 71, 121, 17, 32, 67, 63, 209, 239, 160, 161, 2, 94, 105, 48, 159, 235, 235, 93, 98, 172, 97, 63, 197, 160, 164, 192, 20, 92, 111, 57, 145, 251, 6, 40, 240, 124, 194, 149, 155, 16, 138, 31, 113, 119, 101, 212, 128, 103, 78, 191, 80, 182, 234, 216, 21, 121, 243, 35, 100, 122, 68, 47, 57, 13, 39, 0, 0, 0, 0, 50, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 50, 0, 0, 0, 0, 0, 0, 0, 40, 240, 124, 194, 149, 155, 16, 138, 31, 113, 119, 101, 212, 128, 103, 78, 191, 80, 182, 234, 216, 21, 121, 243, 35, 100, 122, 68, 47, 57, 11, 12, 106, 49, 74, 226, 201, 16, 161, 192, 28, 84, 124, 97, 190, 201, 171, 186, 6, 18, 70, 142, 89, 185, 176, 154, 115, 61, 26, 163, 77, 1, 88, 98, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"2EBVM6cB8vAAD93Ktr6Vd8p67XPbQzCJX47MpReuiCXJAtcjaxpvWpcg9Ege1Nr5Tk3a2GFrByT7WPBjdsTycY9b","id":1}
+```
+
+### Subscription Websocket
+
+After connect to the RPC PubSub websocket at `ws://<ADDRESS>/`:
+
+* Submit subscription requests to the websocket using the methods below
+* Multiple subscriptions may be active at once
+* All subscriptions take an optional `confirmations` parameter, which defines
+
+  how many confirmed blocks the node should wait before sending a notification.
+
+  The greater the number, the more likely the notification is to represent
+
+  consensus across the cluster, and the less likely it is to be affected by
+
+  forking or rollbacks. If unspecified, the default value is 0; the node will
+
+  send a notification as soon as it witnesses the event. The maximum
+
+  `confirmations` wait length is the cluster's `MAX_LOCKOUT_HISTORY`, which
+
+  represents the economic finality of the chain.
+
+### accountSubscribe
+
+Subscribe to an account to receive notifications when the lamports or data for a given account public key changes
+
+#### Parameters:
+
+* `string` - account Pubkey, as base-58 encoded string
+* `integer` - optional, number of confirmed blocks to wait before notification.
+
+  Default: 0, Max: `MAX_LOCKOUT_HISTORY` \(greater integers rounded down\)
+
+#### Results:
+
+* `integer` - Subscription id \(needed to unsubscribe\)
+
+#### Example:
+
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"accountSubscribe", "params":["CM78CPUeXjn8o3yroDHxUtKsZZgoy4GPkPPXfouKNH12"]}
+
+{"jsonrpc":"2.0", "id":1, "method":"accountSubscribe", "params":["CM78CPUeXjn8o3yroDHxUtKsZZgoy4GPkPPXfouKNH12", 15]}
+
+// Result
+{"jsonrpc": "2.0","result": 0,"id": 1}
+```
+
+#### Notification Format:
+
+```bash
+{"jsonrpc": "2.0","method": "accountNotification", "params": {"result": {"executable":false,"owner":[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"lamports":1,"data":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]},"subscription":0}}
+```
+
+### accountUnsubscribe
+
+Unsubscribe from account change notifications
+
+#### Parameters:
+
+* `integer` - id of account Subscription to cancel
+
+#### Results:
+
+* `bool` - unsubscribe success message
+
+#### Example:
+
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"accountUnsubscribe", "params":[0]}
+
+// Result
+{"jsonrpc": "2.0","result": true,"id": 1}
+```
+
+### programSubscribe
+
+Subscribe to a program to receive notifications when the lamports or data for a given account owned by the program changes
+
+#### Parameters:
+
+* `string` - program\_id Pubkey, as base-58 encoded string
+* `integer` - optional, number of confirmed blocks to wait before notification.
+
+  Default: 0, Max: `MAX_LOCKOUT_HISTORY` \(greater integers rounded down\)
+
+#### Results:
+
+* `integer` - Subscription id \(needed to unsubscribe\)
+
+#### Example:
+
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"programSubscribe", "params":["9gZbPtbtHrs6hEWgd6MbVY9VPFtS5Z8xKtnYwA2NynHV"]}
+
+{"jsonrpc":"2.0", "id":1, "method":"programSubscribe", "params":["9gZbPtbtHrs6hEWgd6MbVY9VPFtS5Z8xKtnYwA2NynHV", 15]}
+
+// Result
+{"jsonrpc": "2.0","result": 0,"id": 1}
+```
+
+#### Notification Format:
+
+* `string` - account Pubkey, as base-58 encoded string
+* `object` - account info JSON object \(see [getAccountInfo](jsonrpc-api.md#getaccountinfo) for field details\)
+
+  ```bash
+  {"jsonrpc":"2.0","method":"programNotification","params":{{"result":["8Rshv2oMkPu5E4opXTRyuyBeZBqQ4S477VG26wUTFxUM",{"executable":false,"lamports":1,"owner":[129,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"data":[1,1,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,49,56,45,49,50,45,50,52,84,50,51,58,53,57,58,48,48,90,235,233,39,152,15,44,117,176,41,89,100,86,45,61,2,44,251,46,212,37,35,118,163,189,247,84,27,235,178,62,55,89,0,0,0,0,50,0,0,0,0,0,0,0,235,233,39,152,15,44,117,176,41,89,100,86,45,61,2,44,251,46,212,37,35,118,163,189,247,84,27,235,178,62,45,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}],"subscription":0}}
+  ```
+
+### programUnsubscribe
+
+Unsubscribe from program-owned account change notifications
+
+#### Parameters:
+
+* `integer` - id of account Subscription to cancel
+
+#### Results:
+
+* `bool` - unsubscribe success message
+
+#### Example:
+
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"programUnsubscribe", "params":[0]}
+
+// Result
+{"jsonrpc": "2.0","result": true,"id": 1}
+```
+
+### signatureSubscribe
+
+Subscribe to a transaction signature to receive notification when the transaction is confirmed On `signatureNotification`, the subscription is automatically cancelled
+
+#### Parameters:
+
+* `string` - Transaction Signature, as base-58 encoded string
+* `integer` - optional, number of confirmed blocks to wait before notification.
+
+  Default: 0, Max: `MAX_LOCKOUT_HISTORY` \(greater integers rounded down\)
+
+#### Results:
+
+* `integer` - subscription id \(needed to unsubscribe\)
+
+#### Example:
+
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"signatureSubscribe", "params":["2EBVM6cB8vAAD93Ktr6Vd8p67XPbQzCJX47MpReuiCXJAtcjaxpvWpcg9Ege1Nr5Tk3a2GFrByT7WPBjdsTycY9b"]}
+
+{"jsonrpc":"2.0", "id":1, "method":"signatureSubscribe", "params":["2EBVM6cB8vAAD93Ktr6Vd8p67XPbQzCJX47MpReuiCXJAtcjaxpvWpcg9Ege1Nr5Tk3a2GFrByT7WPBjdsTycY9b", 15]}
+
+// Result
+{"jsonrpc": "2.0","result": 0,"id": 1}
+```
+
+#### Notification Format:
+
+```bash
+{"jsonrpc": "2.0","method": "signatureNotification", "params": {"result": "Confirmed","subscription":0}}
+```
+
+### signatureUnsubscribe
+
+Unsubscribe from signature confirmation notification
+
+#### Parameters:
+
+* `integer` - subscription id to cancel
+
+#### Results:
+
+* `bool` - unsubscribe success message
+
+#### Example:
+
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"signatureUnsubscribe", "params":[0]}
+
+// Result
+{"jsonrpc": "2.0","result": true,"id": 1}
+```
+

book/src/api-reference/transaction-api.md

@@ -0,0 +1,63 @@
+# Transaction
+
+## Components of a `Transaction`
+
+* **Transaction:**
+  * **message:** Defines the transaction
+    * **header:** Details the account types of and signatures required by
+
+      the transaction
+
+      * **num\_required\_signatures:** The total number of signatures
+
+        required to make the transaction valid.
+
+      * **num\_credit\_only\_signed\_accounts:** The last
+
+        `num_credit_only_signed_accounts` signatures refer to signing
+
+        credit only accounts. Credit only accounts can be used concurrently
+
+        by multiple parallel transactions, but their balance may only be
+
+        increased, and their account data is read-only.
+
+      * **num\_credit\_only\_unsigned\_accounts:** The last
+
+        `num_credit_only_unsigned_accounts` pubkeys in `account_keys` refer
+
+        to non-signing credit only accounts
+
+    * **account\_keys:** List of pubkeys used by the transaction, including
+
+      by the instructions and for signatures. The first
+
+      `num_required_signatures` pubkeys must sign the transaction.
+
+    * **recent\_blockhash:** The ID of a recent ledger entry. Validators will
+
+      reject transactions with a `recent_blockhash` that is too old.
+
+    * **instructions:** A list of [instructions](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/instruction.md) that are
+
+      run sequentially and committed in one atomic transaction if all
+
+      succeed.
+  * **signatures:** A list of signatures applied to the transaction. The
+
+    list is always of length `num_required_signatures`, and the signature
+
+    at index `i` corresponds to the pubkey at index `i` in `account_keys`.
+
+    The list is initialized with empty signatures \(i.e. zeros\), and
+
+    populated as signatures are added.
+
+## Transaction Signing
+
+A `Transaction` is signed by using an ed25519 keypair to sign the serialization of the `message`. The resulting signature is placed at the index of `signatures` matching the index of the keypair's pubkey in `account_keys`.
+
+## Transaction Serialization
+
+`Transaction`s \(and their `message`s\) are serialized and deserialized using the [bincode](https://crates.io/crates/bincode) crate with a non-standard vector serialization that uses only one byte for the length if it can be encoded in 7 bits, 2 bytes if it fits in 14 bits, or 3 bytes if it requires 15 or 16 bits. The vector serialization is defined by Solana's [short-vec](https://github.com/solana-labs/solana/blob/master/sdk/src/short_vec.rs).
+

book/src/blocktree.md

@@ -9,29 +9,29 @@ naturally form as a result of leader rotation is described in
 described here is how a validator copes with those forks until blocks
 are finalized.
 
-The blocktree allows a validator to record every blob it observes
-on the network, in any order, as long as the blob is signed by the expected
+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.
 
-Blobs are moved to a fork-able key space the tuple of `leader slot` + `blob
+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 blobs are served out of RAM or recent files and out
-of deeper storage for less recent blobs, as implemented by the store backing
+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.
 
 ### Functionalities of Blocktree
 
 1. Persistence: the Blocktree lives in the front of the nodes verification
    pipeline, right behind network receive and signature verification.  If the
-blob received is consistent with the leader schedule (i.e. was signed by 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
-   blob that's been received. Blocktree stores blobs with signatures,
+   shred that's been received. Blocktree stores shreds with signatures,
 preserving the chain of origination.
-3. Forks: Blocktree supports random access of blobs, so can support a
+3. Forks: Blocktree 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
    ordered enumeration of entries from slot 0.  The logic of the replay stage
@@ -41,22 +41,22 @@ the Blocktree.
 ### Blocktree Design
 
 1. Entries in the Blocktree are stored as key-value pairs, where the key is the concatenated
-slot index and blob index for an entry, and the value is the entry data. Note blob indexes are zero-based for each slot (i.e. they're slot-relative).
+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:
       * `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 blob index `n`, such that for all `m < n`, there exists a blob in this slot with blob index equal to `n` (i.e. the highest consecutive blob index).
-      * `received` - The highest received blob index for the 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 blob that is flagged as the last blob for this slot. This flag on a blob will be set by the leader for a slot when they are transmitting the last blob for a slot.
+      * `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_rooted` - True iff every block from 0...slot forms a full sequence without any holes. We can derive is_rooted 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_rooted(n) be the statement that "the slot(n).is_rooted is true". Then:
 
       is_rooted(0)
       is_rooted(n+1) iff (is_rooted(n) and slot(n).is_full()
 
-3. Chaining - When a blob for a new slot `x` arrives, we check the number of blocks (`num_blocks`) for that new slot (this information is encoded in the blob). We then know that this new slot chains to slot `x - num_blocks`.
+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.
 

book/src/cli.md

@@ -0,0 +1,865 @@
+## solana CLI
+
+The [solana-cli crate](https://crates.io/crates/solana-cli) provides a command-line interface tool for Solana
+
+### Examples
+
+#### Get Pubkey
+
+```sh
+// Command
+$ solana address
+
+// Return
+<PUBKEY>
+```
+
+#### Airdrop SOL/Lamports
+
+```sh
+// Command
+$ solana airdrop 2
+
+// Return
+"2.00000000 SOL"
+
+// Command
+$ solana airdrop 123 --lamports
+
+// Return
+"123 lamports"
+```
+
+#### Get Balance
+
+```sh
+// Command
+$ solana balance
+
+// Return
+"3.00050001 SOL"
+```
+
+#### Confirm Transaction
+
+```sh
+// Command
+$ solana confirm <TX_SIGNATURE>
+
+// Return
+"Confirmed" / "Not found" / "Transaction failed with error <ERR>"
+```
+
+#### Deploy program
+
+```sh
+// Command
+$ solana deploy <PATH>
+
+// Return
+<PROGRAM_ID>
+```
+
+#### Unconditional Immediate Transfer
+
+```sh
+// Command
+$ solana pay <PUBKEY> 123
+
+// Return
+<TX_SIGNATURE>
+```
+
+#### Post-Dated Transfer
+
+```sh
+// Command
+$ solana pay <PUBKEY> 123 \
+    --after 2018-12-24T23:59:00 --require-timestamp-from <PUBKEY>
+
+// Return
+{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
+```
+*`require-timestamp-from` is optional. If not provided, the transaction will expect a timestamp signed by this wallet's private key*
+
+#### Authorized Transfer
+
+A third party must send a signature to unlock the lamports.
+```sh
+// Command
+$ solana pay <PUBKEY> 123 \
+    --require-signature-from <PUBKEY>
+
+// Return
+{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
+```
+
+#### Post-Dated and Authorized Transfer
+
+```sh
+// Command
+$ solana pay <PUBKEY> 123 \
+    --after 2018-12-24T23:59 --require-timestamp-from <PUBKEY> \
+    --require-signature-from <PUBKEY>
+
+// Return
+{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
+```
+
+#### Multiple Witnesses
+
+```sh
+// Command
+$ solana pay <PUBKEY> 123 \
+    --require-signature-from <PUBKEY> \
+    --require-signature-from <PUBKEY>
+
+// Return
+{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
+```
+
+#### Cancelable Transfer
+
+```sh
+// Command
+$ solana pay <PUBKEY> 123 \
+    --require-signature-from <PUBKEY> \
+    --cancelable
+
+// Return
+{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
+```
+
+#### Cancel Transfer
+
+```sh
+// Command
+$ solana cancel <PROCESS_ID>
+
+// Return
+<TX_SIGNATURE>
+```
+
+#### Send Signature
+
+```sh
+// Command
+$ solana send-signature <PUBKEY> <PROCESS_ID>
+
+// Return
+<TX_SIGNATURE>
+```
+
+#### Indicate Elapsed Time
+
+Use the current system time:
+```sh
+// Command
+$ solana send-timestamp <PUBKEY> <PROCESS_ID>
+
+// Return
+<TX_SIGNATURE>
+```
+
+Or specify some other arbitrary timestamp:
+
+```sh
+// Command
+$ solana send-timestamp <PUBKEY> <PROCESS_ID> --date 2018-12-24T23:59:00
+
+// Return
+<TX_SIGNATURE>
+```
+
+### Usage
+
+```manpage
+solana 0.12.0
+
+USAGE:
+    solana [FLAGS] [OPTIONS] [SUBCOMMAND]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+SUBCOMMANDS:
+    address                               Get your public key
+    airdrop                               Request lamports
+    authorize-voter                       Authorize a new vote signing keypair for the given vote account
+    balance                               Get your balance
+    cancel                                Cancel a transfer
+    claim-storage-reward                  Redeem storage reward credits
+    cluster-version                       Get the version of the cluster entrypoint
+    confirm                               Confirm transaction by signature
+    create-replicator-storage-account     Create a replicator storage account
+    create-storage-mining-pool-account    Create mining pool account
+    create-validator-storage-account      Create a validator storage account
+    create-vote-account                   Create a vote account
+    deactivate-stake                      Deactivate the delegated stake from the stake account
+    delegate-stake                        Delegate stake to a vote account
+    deploy                                Deploy a program
+    fees                                  Display current cluster fees
+    get                                   Get wallet config settings
+    get-slot                              Get current slot
+    get-transaction-count                 Get current transaction count
+    help                                  Prints this message or the help of the given subcommand(s)
+    pay                                   Send a payment
+    ping                                  Submit transactions sequentially
+    redeem-vote-credits                   Redeem credits in the stake account
+    send-signature                        Send a signature to authorize a transfer
+    send-timestamp                        Send a timestamp to unlock a transfer
+    set                                   Set a wallet config setting
+    show-account                          Show the contents of an account
+    show-stake-account                    Show the contents of a stake account
+    show-storage-account                  Show the contents of a storage account
+    show-vote-account                     Show the contents of a vote account
+    validator-info                        Publish/get Validator info on Solana
+    withdraw-stake                        Withdraw the unstaked lamports from the stake account
+```
+
+```manpage
+solana-address
+Get your public key
+
+USAGE:
+    solana address [OPTIONS]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+```
+
+```manpage
+solana-airdrop
+Request a batch of lamports
+
+USAGE:
+    solana airdrop [OPTIONS] <AMOUNT> [unit]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>        Configuration file to use [default: /Users/tyeraeulberg/.config/solana/wallet/config.yml]
+        --drone-host <HOST>    Drone host to use [default: the --url host]
+        --drone-port <PORT>    Drone port to use [default: 9900]
+    -u, --url <URL>            JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>       /path/to/id.json
+
+ARGS:
+    <AMOUNT>    The airdrop amount to request (default unit SOL)
+    <unit>      Specify unit to use for request and balance display [possible values: SOL, lamports]
+
+```
+
+```manpage
+solana-authorize-voter
+Authorize a new vote signing keypair for the given vote account
+
+USAGE:
+    solana authorize-voter [OPTIONS] <VOTE ACCOUNT PUBKEY> <CURRENT VOTER KEYPAIR FILE> <NEW VOTER PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <VOTE ACCOUNT PUBKEY>           Vote account in which to set the authorized voter
+    <CURRENT VOTER KEYPAIR FILE>    Keypair file for the currently authorized vote signer
+    <NEW VOTER PUBKEY>              New vote signer to authorize
+
+```
+
+```manpage
+solana-balance
+Get your balance
+
+USAGE:
+    solana balance [FLAGS] [OPTIONS] [PUBKEY]
+
+FLAGS:
+    -h, --help        Prints help information
+        --lamports    Display balance in lamports instead of SOL
+    -V, --version     Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <PUBKEY>    The public key of the balance to check
+```
+
+```manpage
+solana-cancel
+Cancel a transfer
+
+USAGE:
+    solana cancel [OPTIONS] <PROCESS ID>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <PROCESS ID>    The process id of the transfer to cancel
+```
+
+```manpage
+solana-claim-storage-reward
+Redeem storage reward credits
+
+USAGE:
+    solana claim-storage-reward [OPTIONS] <NODE PUBKEY> <STORAGE ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <NODE PUBKEY>               The node account to credit the rewards to
+    <STORAGE ACCOUNT PUBKEY>    Storage account address to redeem credits for
+```
+
+```manpage
+solana-cluster-version
+Get the version of the cluster entrypoint
+
+USAGE:
+    solana cluster-version [OPTIONS]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+```
+
+```manpage
+solana-confirm
+Confirm transaction by signature
+
+USAGE:
+    solana confirm [OPTIONS] <SIGNATURE>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <SIGNATURE>    The transaction signature to confirm
+```
+
+```manpage
+solana-create-replicator-storage-account
+Create a replicator storage account
+
+USAGE:
+    solana create-replicator-storage-account [OPTIONS] <STORAGE ACCOUNT OWNER PUBKEY> <STORAGE ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STORAGE ACCOUNT OWNER PUBKEY>
+    <STORAGE ACCOUNT PUBKEY>
+```
+
+```manpage
+solana-create-storage-mining-pool-account
+Create mining pool account
+
+USAGE:
+    solana create-storage-mining-pool-account [OPTIONS] <STORAGE ACCOUNT PUBKEY> <AMOUNT> [unit]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: /Users/tyeraeulberg/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STORAGE ACCOUNT PUBKEY>    Storage mining pool account address to fund
+    <AMOUNT>                    The amount to assign to the storage mining pool account (default unit SOL)
+    <unit>                      Specify unit to use for request [possible values: SOL, lamports]
+```
+
+```manpage
+solana-create-validator-storage-account
+Create a validator storage account
+
+USAGE:
+    solana create-validator-storage-account [OPTIONS] <STORAGE ACCOUNT OWNER PUBKEY> <STORAGE ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STORAGE ACCOUNT OWNER PUBKEY>
+    <STORAGE ACCOUNT PUBKEY>
+```
+
+```manpage
+solana-create-vote-account
+Create a vote account
+
+USAGE:
+    solana create-vote-account [OPTIONS] <VOTE ACCOUNT PUBKEY> <VALIDATOR PUBKEY> <LAMPORTS>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+        --commission <NUM>    The commission taken on reward redemption (0-255), default: 0
+    -C, --config <PATH>       Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>           JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>      /path/to/id.json
+
+ARGS:
+    <VOTE ACCOUNT PUBKEY>    Vote account address to fund
+    <VALIDATOR PUBKEY>       Validator that will vote with this account
+    <LAMPORTS>               The amount of lamports to send to the vote account
+```
+
+```manpage
+solana-deactivate-stake
+Deactivate the delegated stake from the stake account
+
+USAGE:
+    solana deactivate-stake [OPTIONS] <STAKE ACCOUNT KEYPAIR FILE> <PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STAKE ACCOUNT KEYPAIR FILE>    Keypair file for the stake account, for signing the delegate transaction.
+    <PUBKEY>                        The vote account to which the stake is currently delegated
+```
+
+```manpage
+solana-delegate-stake
+Delegate stake to a vote account
+
+USAGE:
+    solana delegate-stake [OPTIONS] <STAKE ACCOUNT KEYPAIR FILE> <VOTE ACCOUNT PUBKEY> <AMOUNT> [unit]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: /Users/tyeraeulberg/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STAKE ACCOUNT KEYPAIR FILE>    Keypair file for the new stake account
+    <VOTE ACCOUNT PUBKEY>           The vote account to which the stake will be delegated
+    <AMOUNT>                        The amount to delegate (default unit SOL)
+    <unit>                          Specify unit to use for request [possible values: SOL, lamports]
+```
+
+```manpage
+solana-deploy
+Deploy a program
+
+USAGE:
+    solana deploy [OPTIONS] <PATH TO PROGRAM>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <PATH TO PROGRAM>    /path/to/program.o
+```
+
+```manpage
+solana-fees
+Display current cluster fees
+
+USAGE:
+    solana fees [OPTIONS]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+```
+
+```manpage
+solana-get
+Get wallet config settings
+
+USAGE:
+    solana get [OPTIONS] [CONFIG_FIELD]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <CONFIG_FIELD>    Return a specific config setting [possible values: url, keypair]
+```
+
+```manpage
+solana-get-slot
+Get current slot
+
+USAGE:
+    solana get-slot [OPTIONS]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+```
+
+```manpage
+solana-get-transaction-count
+Get current transaction count
+
+USAGE:
+    solana get-transaction-count [OPTIONS]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+```
+
+```manpage
+solana-pay
+Send a payment
+
+USAGE:
+    solana pay [FLAGS] [OPTIONS] <PUBKEY> <AMOUNT> [--] [unit]
+
+FLAGS:
+        --cancelable
+    -h, --help          Prints help information
+    -V, --version       Prints version information
+
+OPTIONS:
+    -C, --config <PATH>                         Configuration file to use [default:
+                                                /Users/tyeraeulberg/.config/solana/wallet/config.yml]
+    -u, --url <URL>                             JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>                        /path/to/id.json
+        --after <DATETIME>                      A timestamp after which transaction will execute
+        --require-timestamp-from <PUBKEY>       Require timestamp from this third party
+        --require-signature-from <PUBKEY>...    Any third party signatures required to unlock the lamports
+
+ARGS:
+    <PUBKEY>    The public key of recipient
+    <AMOUNT>    The amount to send (default unit SOL)
+    <unit>      Specify unit to use for request [possible values: SOL, lamports]
+```
+
+```manpage
+solana-ping
+Submit transactions sequentially
+
+USAGE:
+    solana ping [OPTIONS]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>         Configuration file to use [default:
+                                ~/.config/solana/wallet/config.yml]
+    -c, --count <NUMBER>        Stop after submitting count transactions
+    -i, --interval <SECONDS>    Wait interval seconds between submitting the next transaction [default: 2]
+    -u, --url <URL>             JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>        /path/to/id.json
+    -t, --timeout <SECONDS>     Wait up to timeout seconds for transaction confirmation [default: 10]
+```
+
+```manpage
+solana-redeem-vote-credits
+Redeem credits in the stake account
+
+USAGE:
+    solana redeem-vote-credits [OPTIONS] <STAKING ACCOUNT PUBKEY> <VOTE ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STAKING ACCOUNT PUBKEY>    Staking account address to redeem credits for
+    <VOTE ACCOUNT PUBKEY>       The vote account to which the stake was previously delegated.
+```
+
+```manpage
+solana-send-signature
+Send a signature to authorize a transfer
+
+USAGE:
+    solana send-signature [OPTIONS] <PUBKEY> <PROCESS ID>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <PUBKEY>        The public key of recipient
+    <PROCESS ID>    The process id of the transfer to authorize
+```
+
+```manpage
+solana-send-timestamp
+Send a timestamp to unlock a transfer
+
+USAGE:
+    solana send-timestamp [OPTIONS] <PUBKEY> <PROCESS ID>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>      Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+        --date <DATETIME>    Optional arbitrary timestamp to apply
+    -u, --url <URL>          JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>     /path/to/id.json
+
+ARGS:
+    <PUBKEY>        The public key of recipient
+    <PROCESS ID>    The process id of the transfer to unlock
+```
+
+```manpage
+solana-set
+Set a wallet config setting
+
+USAGE:
+    solana set [OPTIONS] <--url <URL>|--keypair <PATH>>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+```
+
+```manpage
+solana-show-account
+Show the contents of an account
+
+USAGE:
+    solana show-account [FLAGS] [OPTIONS] <ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help        Prints help information
+        --lamports    Display balance in lamports instead of SOL
+    -V, --version     Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+    -o, --output <FILE>     Write the account data to this file
+
+ARGS:
+    <ACCOUNT PUBKEY>    Account public key
+```
+
+```manpage
+solana-show-stake-account
+Show the contents of a stake account
+
+USAGE:
+    solana show-stake-account [OPTIONS] <STAKE ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STAKE ACCOUNT PUBKEY>    Stake account public key
+```
+
+```manpage
+solana-show-storage-account
+Show the contents of a storage account
+
+USAGE:
+    solana show-storage-account [OPTIONS] <STORAGE ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STORAGE ACCOUNT PUBKEY>    Storage account public key
+```
+
+```manpage
+solana-show-vote-account
+Show the contents of a vote account
+
+USAGE:
+    solana show-vote-account [OPTIONS] <VOTE ACCOUNT PUBKEY>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <VOTE ACCOUNT PUBKEY>    Vote account public key
+```
+
+```manpage
+solana-validator-info
+Publish/get Validator info on Solana
+
+USAGE:
+    solana validator-info [OPTIONS] [SUBCOMMAND]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: ~/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+SUBCOMMANDS:
+    get        Get and parse Solana Validator info
+    help       Prints this message or the help of the given subcommand(s)
+    publish    Publish Validator info on Solana
+```
+
+```manpage
+solana-withdraw-stake
+Withdraw the unstaked lamports from the stake account
+
+USAGE:
+    solana withdraw-stake [OPTIONS] <STAKE ACCOUNT KEYPAIR FILE> <DESTINATION PUBKEY> <AMOUNT> [unit]
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -C, --config <PATH>     Configuration file to use [default: /Users/tyeraeulberg/.config/solana/wallet/config.yml]
+    -u, --url <URL>         JSON RPC URL for the solana cluster
+    -k, --keypair <PATH>    /path/to/id.json
+
+ARGS:
+    <STAKE ACCOUNT KEYPAIR FILE>    Keypair file for the stake account, for signing the withdraw transaction.
+    <DESTINATION PUBKEY>            The account where the lamports should be transfered
+    <AMOUNT>                        The amount to withdraw from the stake account (default unit SOL)
+    <unit>                          Specify unit to use for request [possible values: SOL, lamports]
+```

book/src/cluster.md

@@ -13,7 +13,7 @@ buggy and malicious nodes.
 
 Before starting any fullnodes, one first needs to create a *genesis block*.
 The block contains entries referencing two public keys, a *mint* and a
-*bootstrap leader*. The fullnode holding the bootstrap leader's secret key is
+*bootstrap leader*. The fullnode holding the bootstrap leader's private key is
 responsible for appending the first entries to the ledger. It initializes its
 internal state with the mint's account. That account will hold the number of
 native tokens defined by the genesis block. The second fullnode then contacts

book/src/cluster/README.md

@@ -0,0 +1,41 @@
+# A Solana Cluster
+
+A Solana cluster is a set of fullnodes working together to serve client transactions and maintain the integrity of the ledger. Many clusters may coexist. When two clusters share a common genesis block, they attempt to converge. Otherwise, they simply ignore the existence of the other. Transactions sent to the wrong one are quietly rejected. In this chapter, we'll discuss how a cluster is created, how nodes join the cluster, how they share the ledger, how they ensure the ledger is replicated, and how they cope with buggy and malicious nodes.
+
+## Creating a Cluster
+
+Before starting any fullnodes, one first needs to create a _genesis block_. The block contains entries referencing two public keys, a _mint_ and a _bootstrap leader_. The fullnode holding the bootstrap leader's secret key is responsible for appending the first entries to the ledger. It initializes its internal state with the mint's account. That account will hold the number of native tokens defined by the genesis block. The second fullnode then contacts the bootstrap leader to register as a _validator_ or _replicator_. Additional fullnodes then register with any registered member of the cluster.
+
+A validator receives all entries from the leader and submits votes confirming those entries are valid. After voting, the validator is expected to store those entries until replicator nodes submit proofs that they have stored copies of it. Once the validator observes a sufficient number of copies exist, it deletes its copy.
+
+## Joining a Cluster
+
+Validators and replicators enter the cluster via registration messages sent to its _control plane_. The control plane is implemented using a _gossip_ protocol, meaning that a node may register with any existing node, and expect its registration to propagate to all nodes in the cluster. The time it takes for all nodes to synchronize is proportional to the square of the number of nodes participating in the cluster. Algorithmically, that's considered very slow, but in exchange for that time, a node is assured that it eventually has all the same information as every other node, and that that information cannot be censored by any one node.
+
+## Sending Transactions to a Cluster
+
+Clients send transactions to any fullnode's Transaction Processing Unit \(TPU\) port. If the node is in the validator role, it forwards the transaction to the designated leader. If in the leader role, the node bundles incoming transactions, timestamps them creating an _entry_, and pushes them onto the cluster's _data plane_. Once on the data plane, the transactions are validated by validator nodes and replicated by replicator nodes, effectively appending them to the ledger.
+
+## Confirming Transactions
+
+A Solana cluster is capable of subsecond _confirmation_ for up to 150 nodes with plans to scale up to hundreds of thousands of nodes. Once fully implemented, confirmation times are expected to increase only with the logarithm of the number of validators, where the logarithm's base is very high. If the base is one thousand, for example, it means that for the first thousand nodes, confirmation will be the duration of three network hops plus the time it takes the slowest validator of a supermajority to vote. For the next million nodes, confirmation increases by only one network hop.
+
+Solana defines confirmation as the duration of time from when the leader timestamps a new entry to the moment when it recognizes a supermajority of ledger votes.
+
+A gossip network is much too slow to achieve subsecond confirmation once the network grows beyond a certain size. The time it takes to send messages to all nodes is proportional to the square of the number of nodes. If a blockchain wants to achieve low confirmation and attempts to do it using a gossip network, it will be forced to centralize to just a handful of nodes.
+
+Scalable confirmation can be achieved using the follow combination of techniques:
+
+1. Timestamp transactions with a VDF sample and sign the timestamp.
+2. Split the transactions into batches, send each to separate nodes and have
+
+   each node share its batch with its peers.
+
+3. Repeat the previous step recursively until all nodes have all batches.
+
+Solana rotates leaders at fixed intervals, called _slots_. Each leader may only produce entries during its allotted slot. The leader therefore timestamps transactions so that validators may lookup the public key of the designated leader. The leader then signs the timestamp so that a validator may verify the signature, proving the signer is owner of the designated leader's public key.
+
+Next, transactions are broken into batches so that a node can send transactions to multiple parties without making multiple copies. If, for example, the leader needed to send 60 transactions to 6 nodes, it would break that collection of 60 into batches of 10 transactions and send one to each node. This allows the leader to put 60 transactions on the wire, not 60 transactions for each node. Each node then shares its batch with its peers. Once the node has collected all 6 batches, it reconstructs the original set of 60 transactions.
+
+A batch of transactions can only be split so many times before it is so small that header information becomes the primary consumer of network bandwidth. At the time of this writing, the approach is scaling well up to about 150 validators. To scale up to hundreds of thousands of validators, each node can apply the same technique as the leader node to another set of nodes of equal size. We call the technique _data plane fanout_; learn more in the [data plan fanout](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/data-plane-fanout.md) section.
+

book/src/cluster/fork-generation.md

@@ -0,0 +1,81 @@
+# Fork Generation
+
+The chapter describes how forks naturally occur as a consequence of [leader rotation](leader-rotation.md).
+
+## Overview
+
+Nodes take turns being leader and generating the PoH that encodes state changes. The cluster can tolerate loss of connection to any leader by synthesizing what the leader _**would**_ have generated had it been connected but not ingesting any state changes. The possible number of forks is thereby limited to a "there/not-there" skip list of forks that may arise on leader rotation slot boundaries. At any given slot, only a single leader's transactions will be accepted.
+
+## Message Flow
+
+1. Transactions are ingested by the current leader.
+2. Leader filters valid transactions.
+3. Leader executes valid transactions updating its state.
+4. Leader packages transactions into entries based off its current PoH slot.
+5. Leader transmits the entries to validator nodes \(in signed blobs\)
+   1. The PoH stream includes ticks; empty entries that indicate liveness of
+
+      the leader and the passage of time on the cluster.
+
+   2. A leader's stream begins with the tick entries necessary complete the PoH
+
+      back to the leaders most recently observed prior leader slot.
+6. Validators retransmit entries to peers in their set and to further
+
+   downstream nodes.
+
+7. Validators validate the transactions and execute them on their state.
+8. Validators compute the hash of the state.
+9. At specific times, i.e. specific PoH tick counts, validators transmit votes
+
+   to the leader.
+
+   1. Votes are signatures of the hash of the computed state at that PoH tick
+
+      count
+
+   2. Votes are also propagated via gossip
+
+10. Leader executes the votes as any other transaction and broadcasts them to
+
+    the cluster.
+
+11. Validators observe their votes and all the votes from the cluster.
+
+## Partitions, Forks
+
+Forks can arise at PoH tick counts that correspond to a vote. The next leader may not have observed the last vote slot and may start their slot with generated virtual PoH entries. These empty ticks are generated by all nodes in the cluster at a cluster-configured rate for hashes/per/tick `Z`.
+
+There are only two possible versions of the PoH during a voting slot: PoH with `T` ticks and entries generated by the current leader, or PoH with just ticks. The "just ticks" version of the PoH can be thought of as a virtual ledger, one that all nodes in the cluster can derive from the last tick in the previous slot.
+
+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 [Tower BFT](../implemented-proposals/tower-bft.md).
+
+### Validator's View
+
+#### Time Progression
+
+The diagram below represents a validator's view of the PoH stream with possible forks over time. L1, L2, etc. are leader slots, and `E`s represent entries from that leader during that leader's slot. The `x`s represent ticks only, and time flows downwards in the diagram.
+
+![Fork generation](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/fork-generation.svg)
+
+Note that an `E` appearing on 2 forks at the same slot is a slashable condition, so a validator observing `E3` and `E3'` can slash L3 and safely choose `x` for that slot. Once a validator commits to a forks, other forks can be discarded below that tick count. For any slot, validators need only consider a single "has entries" chain or a "ticks only" chain to be proposed by a leader. But multiple virtual entries may overlap as they link back to the a previous slot.
+
+#### Time Division
+
+It's useful to consider leader rotation over PoH tick count as time division of the job of encoding state for the cluster. The following table presents the above tree of forks as a time-divided ledger.
+
+| leader slot | L1 | L2 | L3 | L4 | L5 |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| data | E1 | E2 | E3 | E4 | E5 |
+| ticks since prev |  |  |  | x | xx |
+
+Note that only data from leader L3 will be accepted during leader slot L3. Data from L3 may include "catchup" ticks back to a slot other than L2 if L3 did not observe L2's data. L4 and L5's transmissions include the "ticks to prev" PoH entries.
+
+This arrangement of the network data streams permits nodes to save exactly this to the ledger for replay, restart, and checkpoints.
+
+### Leader's View
+
+When a new leader begins a slot, it must first transmit any PoH \(ticks\) required to link the new slot with the most recently observed and voted slot. The fork the leader proposes would link the current slot to a previous fork that the leader has voted on with virtual ticks.
+

book/src/cluster/leader-rotation.md

@@ -0,0 +1,98 @@
+# Leader Rotation
+
+At any given moment, a cluster expects only one fullnode to produce ledger entries. By having only one leader at a time, all validators are able to replay identical copies of the ledger. The drawback of only one leader at a time, however, is that a malicious leader is capable of censoring votes and transactions. Since censoring cannot be distinguished from the network dropping packets, the cluster cannot simply elect a single node to hold the leader role indefinitely. Instead, the cluster minimizes the influence of a malicious leader by rotating which node takes the lead.
+
+Each validator selects the expected leader using the same algorithm, described below. When the validator receives a new signed ledger entry, it can be certain that entry was produced by the expected leader. The order of slots which each leader is assigned a slot is called a _leader schedule_.
+
+## Leader Schedule Rotation
+
+A validator rejects blocks that are not signed by the _slot leader_. The list of identities of all slot leaders is called a _leader schedule_. The leader schedule is recomputed locally and periodically. It assigns slot leaders for a duration of time called an _epoch_. The schedule must be computed far in advance of the slots it assigns, such that the ledger state it uses to compute the schedule is finalized. That duration is called the _leader schedule offset_. Solana sets the offset to the duration of slots until the next epoch. That is, the leader schedule for an epoch is calculated from the ledger state at the start of the previous epoch. The offset of one epoch is fairly arbitrary and assumed to be sufficiently long such that all validators will have finalized their ledger state before the next schedule is generated. A cluster may choose to shorten the offset to reduce the time between stake changes and leader schedule updates.
+
+While operating without partitions lasting longer than an epoch, the schedule only needs to be generated when the root fork crosses the epoch boundary. Since the schedule is for the next epoch, any new stakes committed to the root fork will not be active until the next epoch. The block used for generating the leader schedule is the first block to cross the epoch boundary.
+
+Without a partition lasting longer than an epoch, the cluster will work as follows:
+
+1. A validator continuously updates its own root fork as it votes.
+2. The validator updates its leader schedule each time the slot height crosses an epoch boundary.
+
+For example:
+
+The epoch duration is 100 slots. The root fork is updated from fork computed at slot height 99 to a fork computed at slot height 102. Forks with slots at height 100,101 were skipped because of failures. The new leader schedule is computed using fork at slot height 102. It is active from slot 200 until it is updated again.
+
+No inconsistency can exist because every validator that is voting with the cluster has skipped 100 and 101 when its root passes 102. All validators, regardless of voting pattern, would be committing to a root that is either 102, or a descendant of 102.
+
+### Leader Schedule Rotation with Epoch Sized Partitions.
+
+The duration of the leader schedule offset has a direct relationship to the likelihood of a cluster having an inconsistent view of the correct leader schedule.
+
+Consider the following scenario:
+
+Two partitions that are generating half of the blocks each. Neither is coming to a definitive supermajority fork. Both will cross epoch 100 and 200 without actually committing to a root and therefore a cluster wide commitment to a new leader schedule.
+
+In this unstable scenario, multiple valid leader schedules exist.
+
+* A leader schedule is generated for every fork whose direct parent is in the previous epoch.
+* The leader schedule is valid after the start of the next epoch for descendant forks until it is updated.
+
+Each partition's schedule will diverge after the partition lasts more than an epoch. For this reason, the epoch duration should be selected to be much much larger then slot time and the expected length for a fork to be committed to root.
+
+After observing the cluster for a sufficient amount of time, the leader schedule offset can be selected based on the median partition duration and its standard deviation. For example, an offset longer then the median partition duration plus six standard deviations would reduce the likelihood of an inconsistent ledger schedule in the cluster to 1 in 1 million.
+
+## Leader Schedule Generation at Genesis
+
+The genesis block declares the first leader for the first epoch. This leader 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 [Tower BFT](../implemented-proposals/tower-bft.md).
+
+## Leader Schedule Generation Algorithm
+
+Leader schedule is generated using a predefined seed. The process is as follows:
+
+1. Periodically use the PoH tick height \(a monotonically increasing counter\) to
+
+   seed a stable pseudo-random algorithm.
+
+2. At that height, sample the bank for all the staked accounts with leader
+
+   identities that have voted within a cluster-configured number of ticks. The
+
+   sample is called the _active set_.
+
+3. Sort the active set by stake weight.
+4. Use the random seed to select nodes weighted by stake to create a
+
+   stake-weighted ordering.
+
+5. This ordering becomes valid after a cluster-configured number of ticks.
+
+## Schedule Attack Vectors
+
+### Seed
+
+The seed that is selected is predictable but unbiasable. There is no grinding attack to influence its outcome.
+
+### Active Set
+
+A leader can bias the active set by censoring validator votes. Two possible ways exist for leaders to censor the active set:
+
+* Ignore votes from validators 
+* Refuse to vote for blocks with votes from validators
+
+To reduce the likelihood of censorship, the active set is calculated at the leader schedule offset boundary over an _active set sampling duration_. The active set sampling duration is long enough such that votes will have been collected by multiple leaders.
+
+### Staking
+
+Leaders can censor new staking transactions or refuse to validate blocks with new stakes. This attack is similar to censorship of validator votes.
+
+### Validator operational key loss
+
+Leaders and validators are expected to use ephemeral keys for operation, and stake owners authorize the validators to do work with their stake via delegation.
+
+The cluster should be able to recover from the loss of all the ephemeral keys used by leaders and validators, which could occur through a common software vulnerability shared by all the nodes. Stake owners should be able to vote directly co-sign a validator vote even though the stake is currently delegated to a validator.
+
+## Appending Entries
+
+The lifetime of a leader schedule is called an _epoch_. The epoch is split into _slots_, where each slot has a duration of `T` PoH ticks.
+
+A leader transmits entries during its slot. After `T` ticks, all the validators switch to the next scheduled leader. Validators must ignore entries sent outside a leader's assigned slot.
+
+All `T` ticks must be observed by the next leader for it to build its own entries on. If entries are not observed \(leader is down\) or entries are invalid \(leader is buggy or malicious\), the next leader must produce ticks to fill the previous leader's slot. Note that the next leader should do repair requests in parallel, and postpone sending ticks until it is confident other validators also failed to observe the previous leader's entries. If a leader incorrectly builds on its own ticks, the leader following it must replace all its ticks.
+

book/src/cluster/ledger-replication.md

@@ -0,0 +1,269 @@
+# Ledger Replication
+
+At full capacity on a 1gbps network solana will generate 4 petabytes of data per year. To prevent the network from centralizing around validators that have to store the full data set this protocol proposes a way for mining nodes to provide storage capacity for pieces of the data.
+
+The basic idea to Proof of Replication is encrypting a dataset with a public symmetric key using CBC encryption, then hash the encrypted dataset. The main problem with the naive approach is that a dishonest storage node can stream the encryption and delete the data as it's hashed. The simple solution is to periodically regenerate the hash based on a signed PoH value. This ensures that all the data is present during the generation of the proof and it also requires validators to have the entirety of the encrypted data present for verification of every proof of every identity. So the space required to validate is `number_of_proofs * data_size`
+
+## Optimization with PoH
+
+Our improvement on this approach is to randomly sample the encrypted segments faster than it takes to encrypt, and record the hash of those samples into the PoH ledger. Thus the segments stay in the exact same order for every PoRep and verification can stream the data and verify all the proofs in a single batch. This way we can verify multiple proofs concurrently, each one on its own CUDA core. The total space required for verification is `1_ledger_segment + 2_cbc_blocks * number_of_identities` with core count equal to `number_of_identities`. We use a 64-byte chacha CBC block size.
+
+## Network
+
+Validators for PoRep are the same validators that are verifying transactions. If a replicator can prove that a validator verified a fake PoRep, then the validator will not receive a reward for that storage epoch.
+
+Replicators are specialized _light clients_. They download a part of the ledger \(a.k.a Segment\) and store it, and provide PoReps of storing the ledger. For each verified PoRep replicators earn a reward of sol from the mining pool.
+
+## Constraints
+
+We have the following constraints:
+
+* Verification requires generating the CBC blocks. That requires space of 2
+
+  blocks per identity, and 1 CUDA core per identity for the same dataset. So as
+
+  many identities at once should be batched with as many proofs for those
+
+  identities verified concurrently for the same dataset.
+
+* Validators will randomly sample the set of storage proofs to the set that
+
+  they can handle, and only the creators of those chosen proofs will be
+
+  rewarded. The validator can run a benchmark whenever its hardware configuration
+
+  changes to determine what rate it can validate storage proofs.
+
+## Validation and Replication Protocol
+
+### Constants
+
+1. SLOTS\_PER\_SEGMENT: Number of slots in a segment of ledger data. The
+
+   unit of storage for a replicator.
+
+2. NUM\_KEY\_ROTATION\_SEGMENTS: Number of segments after which replicators
+
+   regenerate their encryption keys and select a new dataset to store.
+
+3. NUM\_STORAGE\_PROOFS: Number of storage proofs required for a storage proof
+
+   claim to be successfully rewarded.
+
+4. RATIO\_OF\_FAKE\_PROOFS: Ratio of fake proofs to real proofs that a storage
+
+   mining proof claim has to contain to be valid for a reward.
+
+5. NUM\_STORAGE\_SAMPLES: Number of samples required for a storage mining
+
+   proof.
+
+6. NUM\_CHACHA\_ROUNDS: Number of encryption rounds performed to generate
+
+   encrypted state.
+
+7. NUM\_SLOTS\_PER\_TURN: Number of slots that define a single storage epoch or
+
+   a "turn" of the PoRep game.
+
+### Validator behavior
+
+1. Validators join the network and begin looking for replicator accounts at each
+
+   storage epoch/turn boundary.
+
+2. Every turn, Validators sign the PoH value at the boundary and use that signature
+
+   to randomly pick proofs to verify from each storage account found in the turn boundary.
+
+   This signed value is also submitted to the validator's storage account and will be used by
+
+   replicators at a later stage to cross-verify.
+
+3. Every `NUM_SLOTS_PER_TURN` slots the validator advertises the PoH value. This is value
+
+   is also served to Replicators via RPC interfaces.
+
+4. For a given turn N, all validations get locked out until turn N+3 \(a gap of 2 turn/epoch\).
+
+   At which point all validations during that turn are available for reward collection.
+
+5. Any incorrect validations will be marked during the turn in between.
+
+### Replicator behavior
+
+1. Since a replicator is somewhat of a light client and not downloading all the
+
+   ledger data, they have to rely on other validators and replicators for information.
+
+   Any given validator may or may not be malicious and give incorrect information, although
+
+   there are not any obvious attack vectors that this could accomplish besides having the
+
+   replicator do extra wasted work.  For many of the operations there are a number of options
+
+   depending on how paranoid a replicator is:
+
+   * \(a\) replicator can ask a validator
+   * \(b\) replicator can ask multiple validators
+   * \(c\) replicator can ask other replicators
+   * \(d\) replicator can subscribe to the full transaction stream and generate
+
+     the information itself \(assuming the slot is recent enough\)
+
+   * \(e\) replicator can subscribe to an abbreviated transaction stream to
+
+     generate the information itself \(assuming the slot is recent enough\)
+
+2. A replicator obtains the PoH hash corresponding to the last turn with its slot.
+3. The replicator signs the PoH hash with its keypair. That signature is the
+
+   seed used to pick the segment to replicate and also the encryption key. The
+
+   replicator mods the signature with the slot to get which segment to
+
+   replicate.
+
+4. The replicator retrives the ledger by asking peer validators and
+
+   replicators. See 6.5.
+
+5. The replicator then encrypts that segment with the key with chacha algorithm
+
+   in CBC mode with `NUM_CHACHA_ROUNDS` of encryption.
+
+6. The replicator initializes a chacha rng with the a signed recent PoH value as
+
+   the seed.
+
+7. The replicator generates `NUM_STORAGE_SAMPLES` samples in the range of the
+
+   entry size and samples the encrypted segment with sha256 for 32-bytes at each
+
+   offset value. Sampling the state should be faster than generating the encrypted
+
+   segment.
+
+8. The replicator sends a PoRep proof transaction which contains its sha state
+
+   at the end of the sampling operation, its seed and the samples it used to the
+
+   current leader and it is put onto the ledger.
+
+9. During a given turn the replicator should submit many proofs for the same segment
+
+   and based on the `RATIO_OF_FAKE_PROOFS` some of those proofs must be fake.
+
+10. As the PoRep game enters the next turn, the replicator must submit a
+
+    transaction with the mask of which proofs were fake during the last turn. This
+
+    transaction will define the rewards for both replicators and validators.
+
+11. Finally for a turn N, as the PoRep game enters turn N + 3, replicator's proofs for
+
+    turn N will be counted towards their rewards.
+
+### The PoRep Game
+
+The Proof of Replication game has 4 primary stages. For each "turn" multiple PoRep games can be in progress but each in a different stage.
+
+The 4 stages of the PoRep Game are as follows:
+
+1. Proof submission stage
+   * Replicators: submit as many proofs as possible during this stage
+   * Validators: No-op
+2. Proof verification stage
+   * Replicators: No-op
+   * Validators: Select replicators and verify their proofs from the previous turn
+3. Proof challenge stage
+   * Replicators: Submit the proof mask with justifications \(for fake proofs submitted 2 turns ago\)
+   * Validators: No-op
+4. Reward collection stage
+   * Replicators: Collect rewards for 3 turns ago
+   * Validators:  Collect rewards for 3 turns ago
+
+For each turn of the PoRep game, both Validators and Replicators evaluate each stage. The stages are run as separate transactions on the storage program.
+
+### Finding who has a given block of ledger
+
+1. Validators monitor the turns in the PoRep game and look at the rooted bank
+
+   at turn boundaries for any proofs.
+
+2. Validators maintain a map of ledger segments and corresponding replicator public keys.
+
+   The map is updated when a Validator processes a replicator's proofs for a segment.
+
+   The validator provides an RPC interface to access the this map. Using this API, clients
+
+   can map a segment to a replicator's network address \(correlating it via cluster\_info table\).
+
+   The clients can then send repair requests to the replicator to retrieve segments.
+
+3. Validators would need to invalidate this list every N turns.
+
+## Sybil attacks
+
+For any random seed, we force everyone to use a signature that is derived from a PoH hash at the turn boundary. Everyone uses the same count, so the same PoH hash is signed by every participant. The signatures are then each cryptographically tied to the keypair, which prevents a leader from grinding on the resulting value for more than 1 identity.
+
+Since there are many more client identities then encryption identities, we need to split the reward for multiple clients, and prevent Sybil attacks from generating many clients to acquire the same block of data. To remain BFT we want to avoid a single human entity from storing all the replications of a single chunk of the ledger.
+
+Our solution to this is to force the clients to continue using the same identity. If the first round is used to acquire the same block for many client identities, the second round for the same client identities will force a redistribution of the signatures, and therefore PoRep identities and blocks. Thus to get a reward for replicators need to store the first block for free and the network can reward long lived client identities more than new ones.
+
+## Validator attacks
+
+* If a validator approves fake proofs, replicator can easily out them by
+
+  showing the initial state for the hash.
+
+* If a validator marks real proofs as fake, no on-chain computation can be done
+
+  to distinguish who is correct. Rewards would have to rely on the results from
+
+  multiple validators to catch bad actors and replicators from being denied rewards.
+
+* Validator stealing mining proof results for itself. The proofs are derived
+
+  from a signature from a replicator, since the validator does not know the
+
+  private key used to generate the encryption key, it cannot be the generator of
+
+  the proof.
+
+## Reward incentives
+
+Fake proofs are easy to generate but difficult to verify. For this reason, PoRep proof transactions generated by replicators may require a higher fee than a normal transaction to represent the computational cost required by validators.
+
+Some percentage of fake proofs are also necessary to receive a reward from storage mining.
+
+## Notes
+
+* We can reduce the costs of verification of PoRep by using PoH, and actually
+
+  make it feasible to verify a large number of proofs for a global dataset.
+
+* We can eliminate grinding by forcing everyone to sign the same PoH hash and
+
+  use the signatures as the seed
+
+* The game between validators and replicators is over random blocks and random
+
+  encryption identities and random data samples. The goal of randomization is
+
+  to prevent colluding groups from having overlap on data or validation.
+
+* Replicator clients fish for lazy validators by submitting fake proofs that
+
+  they can prove are fake.
+
+* To defend against Sybil client identities that try to store the same block we
+
+  force the clients to store for multiple rounds before receiving a reward.
+
+* Validators should also get rewarded for validating submitted storage proofs
+
+  as incentive for storing the ledger. They can only validate proofs if they
+
+  are storing that slice of the ledger.
+

book/src/cluster/managing-forks.md

@@ -0,0 +1,35 @@
+# Managing Forks
+
+The ledger is permitted to fork at slot boundaries. The resulting data structure forms a tree called a _blocktree_. When the fullnode 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 fullnode to weigh those forks, such that it may eventually select a fork.
+
+A fullnode selects a fork by submiting a vote to a slot leader on that fork. The vote commits the fullnode for a duration of time called a _lockout period_. The fullnode 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 fullnode 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 fullnode votes, any checkpoints beyond the rollback depth become unreachable. That is, there is no scenario in which the fullnode 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.
+
+## Active Forks
+
+An active fork is as a sequence of checkpoints that has a length at least one longer than the rollback depth. The shortest fork will have a length exactly one longer than the rollback depth. For example:
+
+![Forks](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/forks.svg)
+
+The following sequences are _active forks_:
+
+* {4, 2, 1}
+* {5, 2, 1}
+* {6, 3, 1}
+* {7, 3, 1}
+
+## Pruning and Squashing
+
+A fullnode may vote on any checkpoint in the tree. In the diagram above, that's every node except the leaves of the tree. After voting, the fullnode prunes nodes that fork from a distance farther than the rollback depth and then takes the opportunity to minimize its memory usage by squashing any nodes it can into the root.
+
+Starting from the example above, wth a rollback depth of 2, consider a vote on 5 versus a vote on 6. First, a vote on 5:
+
+![Forks after pruning](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/forks-pruned.svg)
+
+The new root is 2, and any active forks that are not descendants from 2 are pruned.
+
+Alternatively, a vote on 6:
+
+![Forks](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/forks-pruned2.svg)
+
+The tree remains with a root of 1, since the active fork starting at 6 is only 2 checkpoints from the root.
+

book/src/cluster/performance-metrics.md

@@ -0,0 +1,16 @@
+# Performance Metrics
+
+Solana cluster performance is measured as average number of transactions per second that the network can sustain \(TPS\). And, how long it takes for a transaction to be confirmed by super majority of the cluster \(Confirmation Time\).
+
+Each cluster node maintains various counters that are incremented on certain events. These counters are periodically uploaded to a cloud based database. Solana's metrics dashboard fetches these counters, and computes the performance metrics and displays it on the dashboard.
+
+## TPS
+
+Each node's bank runtime maintains a count of transactions that it has processed. The dashboard first calculates the median count of transactions across all metrics enabled nodes in the cluster. The median cluster transaction count is then averaged over a 2 second period and displayed in the TPS time series graph. The dashboard also shows the Mean TPS, Max TPS and Total Transaction Count stats which are all calculated from the median transaction count.
+
+## Confirmation Time
+
+Each validator node maintains a list of active ledger forks that are visible to the node. A fork is considered to be frozen when the node has received and processed all entries corresponding to the fork. A fork is considered to be confirmed when it receives cumulative super majority vote, and when one of its children forks is frozen.
+
+The node assigns a timestamp to every new fork, and computes the time it took to confirm the fork. This time is reflected as validator confirmation time in performance metrics. The performance dashboard displays the average of each validator node's confirmation time as a time series graph.
+

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

@@ -0,0 +1,209 @@
+# Stake Delegation and Rewards
+
+Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and send votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validator and staker need some economic incentive to play their part. The validator needs to be compensated for its hardware and the staker needs to be compensated for the risk of getting its stake slashed. The economics are covered in [staking rewards](../proposals/staking-rewards.md). This chapter, on the other hand, describes the underlying mechanics of its implementation.
+
+## Basic Design
+
+The general idea is that the validator owns a Vote account. The Vote account tracks validator votes, counts validator generated credits, and provides any additional validator specific state. The Vote account is not aware of any stakes delegated to it and has no staking weight.
+
+A separate Stake account \(created by a staker\) names a Vote account to which the stake is delegated. Rewards generated are proportional to the amount of lamports staked. The Stake account is owned by the staker only. Some portion of the lamports stored in this account are the stake.
+
+## Passive Delegation
+
+Any number of Stake accounts can delegate to a single Vote account without an interactive action from the identity controlling the Vote account or submitting votes to the account.
+
+The total stake allocated to a Vote account can be calculated by the sum of all the Stake accounts that have the Vote account pubkey as the `StakeState::Stake::voter_pubkey`.
+
+## Vote and Stake accounts
+
+The rewards process is split into two on-chain programs. The Vote program solves the problem of making stakes slashable. The Stake account acts as custodian of the rewards pool, and provides passive delegation. The Stake program is responsible for paying out each staker once the staker proves to the Stake program that its delegate has participated in validating the ledger.
+
+### VoteState
+
+VoteState is the current state of all the votes the validator has submitted to the network. VoteState contains the following state information:
+
+* `votes` - The submitted votes data structure.
+* `credits` - The total number of rewards this vote program has generated over its lifetime.
+* `root_slot` - The last slot to reach the full lockout commitment necessary for rewards.
+* `commission` - The commission taken by this VoteState for any rewards claimed by staker's Stake accounts. This is the percentage ceiling of the reward.
+* Account::lamports - The accumulated lamports from the commission. These do not count as stakes.
+* `authorized_vote_signer` - Only this identity is authorized to submit votes. This field can only modified by this identity.
+
+### VoteInstruction::Initialize
+
+* `account[0]` - RW - The VoteState
+
+  `VoteState::authorized_vote_signer` is initialized to `account[0]`
+
+   other VoteState members defaulted
+
+### VoteInstruction::AuthorizeVoteSigner\(Pubkey\)
+
+* `account[0]` - RW - The VoteState
+
+  `VoteState::authorized_vote_signer` is set to to `Pubkey`, the transaction must by
+
+   signed by the Vote account's current `authorized_vote_signer`.    
+
+
+   `VoteInstruction::AuthorizeVoter` allows a staker to choose a signing service
+
+  for its votes. That service is responsible for ensuring the vote won't cause
+
+  the staker to be slashed.
+
+### VoteInstruction::Vote\(Vec\)
+
+* `account[0]` - RW - The VoteState
+
+  `VoteState::lockouts` and `VoteState::credits` are updated according to voting lockout rules see [Tower BFT](../implemented-proposals/tower-bft.md)
+
+* `account[1]` - RO - A list of some N most recent slots and their hashes for the vote to be verified against.
+
+### StakeState
+
+A StakeState takes one of three forms, StakeState::Uninitialized, StakeState::Stake and StakeState::RewardsPool.
+
+### StakeState::Stake
+
+StakeState::Stake is the current delegation preference of the **staker** and contains the following state information:
+
+* Account::lamports - The lamports available for staking.
+* `stake` - the staked amount \(subject to warm up and cool down\) for generating rewards, always less than or equal to Account::lamports
+* `voter_pubkey` - The pubkey of the VoteState instance the lamports are delegated to.
+* `credits_observed` - The total credits claimed over the lifetime of the program.
+* `activated` - the epoch at which this stake was activated/delegated. The full stake will be counted after warm up.
+* `deactivated` - the epoch at which this stake will be completely de-activated, which is `cool down` epochs after StakeInstruction::Deactivate is issued.
+
+### StakeState::RewardsPool
+
+To avoid a single network wide lock or contention in redemption, 256 RewardsPools are part of genesis under pre-determined keys, each with std::u64::MAX credits to be able to satisfy redemptions according to point value.
+
+The Stakes and the RewardsPool are accounts that are owned by the same `Stake` program.
+
+### StakeInstruction::DelegateStake\(u64\)
+
+The Stake account is moved from Uninitialized to StakeState::Stake form. This is how stakers choose their initial delegate validator node and activate their stake account lamports.
+
+* `account[0]` - RW - The StakeState::Stake instance.   `StakeState::Stake::credits_observed` is initialized to `VoteState::credits`,  `StakeState::Stake::voter_pubkey` is initialized to `account[1]`,  `StakeState::Stake::stake` is initialized to the u64 passed as an argument above,  `StakeState::Stake::activated` is initialized to current Bank epoch, and  `StakeState::Stake::deactivated` is initialized to std::u64::MAX
+* `account[1]` - R - The VoteState instance.
+* `account[2]` - R - sysvar::current account, carries information about current Bank epoch
+* `account[3]` - R - stake\_api::Config accoount, carries warmup, cooldown, and slashing configuration
+
+### StakeInstruction::RedeemVoteCredits
+
+The staker or the owner of the Stake account sends a transaction with this instruction to claim rewards.
+
+The Vote account and the Stake account pair maintain a lifetime counter of total rewards generated and claimed. Rewards are paid according to a point value supplied by the Bank from inflation. A `point` is one credit \* one staked lamport, rewards paid are proportional to the number of lamports staked.
+
+* `account[0]` - RW - The StakeState::Stake instance that is redeeming rewards.
+* `account[1]` - R - The VoteState instance, must be the same as `StakeState::voter_pubkey`
+* `account[2]` - RW - The StakeState::RewardsPool instance that will fulfill the request \(picked at random\).
+* `account[3]` - R - sysvar::rewards account from the Bank that carries point value.
+* `account[4]` - R - sysvar::stake\_history account from the Bank that carries stake warmup/cooldown history
+
+Reward is paid out for the difference between `VoteState::credits` to `StakeState::Stake::credits_observed`, multiplied by `sysvar::rewards::Rewards::validator_point_value`. `StakeState::Stake::credits_observed` is updated to`VoteState::credits`. The commission is deposited into the Vote account token balance, and the reward is deposited to the Stake account token balance.
+
+```text
+let credits_to_claim = vote_state.credits - stake_state.credits_observed;
+stake_state.credits_observed = vote_state.credits;
+```
+
+`credits_to_claim` is used to compute the reward and commission, and `StakeState::Stake::credits_observed` is updated to the latest `VoteState::credits` value.
+
+### StakeInstruction::Deactivate
+
+A staker may wish to withdraw from the network. To do so he must first deactivate his stake, and wait for cool down.
+
+* `account[0]` - RW - The StakeState::Stake instance that is deactivating, the transaction must be signed by this key.
+* `account[1]` - R - The VoteState instance to which this stake is delegated, required in case of slashing
+* `account[2]` - R - sysvar::current account from the Bank that carries current epoch
+
+StakeState::Stake::deactivated is set to the current epoch + cool down. The account's stake will ramp down to zero by that epoch, and Account::lamports will be available for withdrawal.
+
+### StakeInstruction::Withdraw\(u64\)
+
+Lamports build up over time in a Stake account and any excess over activated stake can be withdrawn.
+
+* `account[0]` - RW - The StakeState::Stake from which to withdraw, the transaction must be signed by this key.
+* `account[1]` - RW - Account that should be credited with the withdrawn lamports.
+* `account[2]` - R - sysvar::current account from the Bank that carries current epoch, to calculate stake.
+* `account[3]` - R - sysvar::stake\_history account from the Bank that carries stake warmup/cooldown history
+
+## Benefits of the design
+
+* Single vote for all the stakers.
+* Clearing of the credit variable is not necessary for claiming rewards.
+* Each delegated stake can claim its rewards independently.
+* Commission for the work is deposited when a reward is claimed by the delegated stake.
+
+## Example Callflow
+
+![Passive Staking Callflow](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/passive-staking-callflow.svg)
+
+## Staking Rewards
+
+The specific mechanics and rules of the validator rewards regime is outlined here. Rewards are earned by delegating stake to a validator that is voting correctly. Voting incorrectly exposes that validator's stakes to [slashing](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/staking-and-rewards.md).
+
+### Basics
+
+The network pays rewards from a portion of network [inflation](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/inflation.md). The number of lamports available to pay rewards for an epoch is fixed and must be evenly divided among all staked nodes according to their relative stake weight and participation. The weighting unit is called a [point](../terminology.md#point).
+
+Rewards for an epoch are not available until the end of that epoch.
+
+At the end of each epoch, the total number of points earned during the epoch is summed and used to divide the rewards portion of epoch inflation to arrive at a point value. This value is recorded in the bank in a [sysvar](../terminology.md#sysvar) that maps epochs to point values.
+
+During redemption, the stake program counts the points earned by the stake for each epoch, multiplies that by the epoch's point value, and transfers lamports in that amount from a rewards account into the stake and vote accounts according to the vote account's commission setting.
+
+### Economics
+
+Point value for an epoch depends on aggregate network participation. If participation in an epoch drops off, point values are higher for those that do participate.
+
+### Earning credits
+
+Validators earn one vote credit for every correct vote that exceeds maximum lockout, i.e. every time the validator's vote account retires a slot from its lockout list, making that vote a root for the node.
+
+Stakers who have delegated to that validator earn points in proportion to their stake. Points earned is the product of vote credits and stake.
+
+### Stake warmup, cooldown, withdrawal
+
+Stakes, once delegated, do not become effective immediately. They must first pass through a warm up period. During this period some portion of the stake is considered "effective", the rest is considered "activating". Changes occur on epoch boundaries.
+
+The stake program limits the rate of change to total network stake, reflected in the stake program's `config::warmup_rate` \(typically 15% per epoch\).
+
+The amount of stake that can be warmed up each epoch is a function of the previous epoch's total effective stake, total activating stake, and the stake program's configured warmup rate.
+
+Cooldown works the same way. Once a stake is deactivated, some part of it is considered "effective", and also "deactivating". As the stake cools down, it continues to earn rewards and be exposed to slashing, but it also becomes available for withdrawal.
+
+Bootstrap stakes are not subject to warmup.
+
+Rewards are paid against the "effective" portion of the stake for that epoch.
+
+#### Warmup example
+
+Consider the situation of a single stake of 1,000 activated at epoch N, with network warmup rate of 20%, and a quiescent total network stake at epoch N of 2,000.
+
+At epoch N+1, the amount available to be activated for the network is 400 \(20% of 200\), and at epoch N, this example stake is the only stake activating, and so is entitled to all of the warmup room available.
+
+| epoch | effective | activating | total effective | total activating |
+| :--- | ---: | ---: | ---: | ---: |
+| N-1 |  |  | 2,000 | 0 |
+| N | 0 | 1,000 | 2,000 | 1,000 |
+| N+1 | 400 | 600 | 2,400 | 600 |
+| N+2 | 880 | 120 | 2,880 | 120 |
+| N+3 | 1000 | 0 | 3,000 | 0 |
+
+Were 2 stakes \(X and Y\) to activate at epoch N, they would be awarded a portion of the 20% in proportion to their stakes. At each epoch effective and activating for each stake is a function of the previous epoch's state.
+
+| epoch | X eff | X act | Y eff | Y act | total effective | total activating |
+| :--- | ---: | ---: | ---: | ---: | ---: | ---: |
+| N-1 |  |  |  |  | 2,000 | 0 |
+| N | 0 | 1,000 | 0 | 200 | 2,000 | 1,200 |
+| N+1 | 320 | 680 | 80 | 120 | 2,400 | 800 |
+| N+2 | 728 | 272 | 152 | 48 | 2,880 | 320 |
+| N+3 | 1000 | 0 | 200 | 0 | 3,200 | 0 |
+
+### Withdrawal
+
+As rewards are earned lamports can be withdrawn from a stake account. Only lamports in excess of effective+activating stake may be withdrawn at any time. This means that during warmup, effectively no stake can be withdrawn. During cooldown, any tokens in excess of effective stake may be withdrawn \(activating == 0\);
+

book/src/cluster/synchronization.md

@@ -0,0 +1,27 @@
+# Synchronization
+
+Fast, reliable synchronization is the biggest reason Solana is able to achieve such high throughput. Traditional blockchains synchronize on large chunks of transactions called blocks. By synchronizing on blocks, a transaction cannot be processed until a duration called "block time" has passed. In Proof of Work consensus, these block times need to be very large \(~10 minutes\) to minimize the odds of multiple fullnodes producing a new valid block at the same time. There's no such constraint in Proof of Stake consensus, but without reliable timestamps, a fullnode cannot determine the order of incoming blocks. The popular workaround is to tag each block with a [wallclock timestamp](https://en.bitcoin.it/wiki/Block_timestamp). Because of clock drift and variance in network latencies, the timestamp is only accurate within an hour or two. To workaround the workaround, these systems lengthen block times to provide reasonable certainty that the median timestamp on each block is always increasing.
+
+Solana takes a very different approach, which it calls _Proof of History_ or _PoH_. Leader nodes "timestamp" blocks with cryptographic proofs that some duration of time has passed since the last proof. All data hashed into the proof most certainly have occurred before the proof was generated. The node then shares the new block with validator nodes, which are able to verify those proofs. The blocks can arrive at validators in any order or even could be replayed years later. With such reliable synchronization guarantees, Solana is able to break blocks into smaller batches of transactions called _entries_. Entries are streamed to validators in realtime, before any notion of block consensus.
+
+Solana technically never sends a _block_, but uses the term to describe the sequence of entries that fullnodes vote on to achieve _confirmation_. In that way, Solana's confirmation times can be compared apples to apples to block-based systems. The current implementation sets block time to 800ms.
+
+What's happening under the hood is that entries are streamed to validators as quickly as a leader node can batch a set of valid transactions into an entry. Validators process those entries long before it is time to vote on their validity. By processing the transactions optimistically, there is effectively no delay between the time the last entry is received and the time when the node can vote. In the event consensus is **not** achieved, a node simply rolls back its state. This optimisic processing technique was introduced in 1981 and called [Optimistic Concurrency Control](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.65.4735). It can be applied to blockchain architecture where a cluster votes on a hash that represents the full ledger up to some _block height_. In Solana, it is implemented trivially using the last entry's PoH hash.
+
+## Relationship to VDFs
+
+The Proof of History technique was first described for use in blockchain by Solana in November of 2017. In June of the following year, a similar technique was described at Stanford and called a [verifiable delay function](https://eprint.iacr.org/2018/601.pdf) or _VDF_.
+
+A desirable property of a VDF is that verification time is very fast. Solana's approach to verifying its delay function is proportional to the time it took to create it. Split over a 4000 core GPU, it is sufficiently fast for Solana's needs, but if you asked the authors of the paper cited above, they might tell you \([and have](https://github.com/solana-labs/solana/issues/388)\) that Solana's approach is algorithmically slow and it shouldn't be called a VDF. We argue the term VDF should represent the category of verifiable delay functions and not just the subset with certain performance characteristics. Until that's resolved, Solana will likely continue using the term PoH for its application-specific VDF.
+
+Another difference between PoH and VDFs is that a VDF is used only for tracking duration. PoH's hash chain, on the other hand, includes hashes of any data the application observed. That data is a double-edged sword. On one side, the data "proves history" - that the data most certainly existed before hashes after it. On the side, it means the application can manipulate the hash chain by changing _when_ the data is hashed. The PoH chain therefore does not serve as a good source of randomness whereas a VDF without that data could. Solana's [leader rotation algorithm](synchronization.md#leader-rotation), for example, is derived only from the VDF _height_ and not its hash at that height.
+
+## Relationship to Consensus Mechanisms
+
+Proof of History is not a consensus mechanism, but it is used to improve the performance of Solana's Proof of Stake consensus. It is also used to improve the performance of the data plane and replication protocols.
+
+## More on Proof of History
+
+* [water clock analogy](https://medium.com/solana-labs/proof-of-history-explained-by-a-water-clock-e682183417b8)
+* [Proof of History overview](https://medium.com/solana-labs/proof-of-history-a-clock-for-blockchain-cf47a61a9274)
+

book/src/cluster/turbine-block-propagation.md

@@ -0,0 +1,44 @@
+# Turbine Block Propagation
+
+A Solana cluster uses a multi-layer block propagation mechanism called _Turbine_ to broadcast transaction blobs to all nodes with minimal amount of duplicate messages. The cluster divides itself into small collections of nodes, called _neighborhoods_. Each node is responsible for sharing any data it receives with the other nodes in its neighborhood, as well as propagating the data on to a small set of nodes in other neighborhoods. This way each node only has to communicate with a small number of nodes.
+
+During its slot, the leader node distributes blobs between the validator nodes in the first neighborhood \(layer 0\). Each validator shares its data within its neighborhood, but also retransmits the blobs to one node in some neighborhoods in the next layer \(layer 1\). The layer-1 nodes each share their data with their neighborhood peers, and retransmit to nodes in the next layer, etc, until all nodes in the cluster have received all the blobs.
+
+## Neighborhood Assignment - Weighted Selection
+
+In order for data plane fanout to work, the entire cluster must agree on how the cluster is divided into neighborhoods. To achieve this, all the recognized validator nodes \(the TVU peers\) are sorted by stake and stored in a list. This list is then indexed in different ways to figure out neighborhood boundaries and retransmit peers. For example, the leader will simply select the first nodes to make up layer 0. These will automatically be the highest stake holders, allowing the heaviest votes to come back to the leader first. Layer-0 and lower-layer nodes use the same logic to find their neighbors and next layer peers.
+
+To reduce the possibility of attack vectors, each blob is transmitted over a random tree of neighborhoods. Each node uses the same set of nodes representing the cluster. A random tree is generated from the set for each blob using randomness derived from the blob itself. Since the random seed is not known in advance, attacks that try to eclipse neighborhoods from certain leaders or blocks become very difficult, and should require almost complete control of the stake in the cluster.
+
+## Layer and Neighborhood Structure
+
+The current leader makes its initial broadcasts to at most `DATA_PLANE_FANOUT` nodes. If this layer 0 is smaller than the number of nodes in the cluster, then the data plane fanout mechanism adds layers below. Subsequent layers follow these constraints to determine layer-capacity: Each neighborhood contains `DATA_PLANE_FANOUT` nodes. Layer-0 starts with 1 neighborhood with fanout nodes. The number of nodes in each additional layer grows by a factor of fanout.
+
+As mentioned above, each node in a layer only has to broadcast its blobs to its neighbors and to exactly 1 node in some next-layer neighborhoods, instead of to every TVU peer in the cluster. A good way to think about this is, layer-0 starts with 1 neighborhood with fanout nodes, layer-1 adds "fanout" neighborhoods, each with fanout nodes and layer-2 will have `fanout * number of nodes in layer-1` and so on.
+
+This way each node only has to communicate with a maximum of `2 * DATA_PLANE_FANOUT - 1` nodes.
+
+The following diagram shows how the Leader sends blobs with a Fanout of 2 to Neighborhood 0 in Layer 0 and how the nodes in Neighborhood 0 share their data with each other.
+
+![Leader sends blobs to Neighborhood 0 in Layer 0](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/data-plane-seeding.svg)
+
+The following diagram shows how Neighborhood 0 fans out to Neighborhoods 1 and 2.
+
+![Neighborhood 0 Fanout to Neighborhood 1 and 2](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/data-plane-fanout.svg)
+
+Finally, the following diagram shows a two layer cluster with a Fanout of 2.
+
+![Two layer cluster with a Fanout of 2](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/data-plane.svg)
+
+### Configuration Values
+
+`DATA_PLANE_FANOUT` - Determines the size of layer 0. Subsequent layers grow by a factor of `DATA_PLANE_FANOUT`. The number of nodes in a neighborhood is equal to the fanout value. Neighborhoods will fill to capacity before new ones are added, i.e if a neighborhood isn't full, it _must_ be the last one.
+
+Currently, configuration is set when the cluster is launched. In the future, these parameters may be hosted on-chain, allowing modification on the fly as the cluster sizes change.
+
+## Neighborhoods
+
+The following diagram shows how two neighborhoods in different layers interact. To cripple a neighborhood, enough nodes \(erasure codes +1\) from the neighborhood above need to fail. Since each neighborhood receives blobs from multiple nodes in a neighborhood in the upper layer, we'd need a big network failure in the upper layers to end up with incomplete data.
+
+![Inner workings of a neighborhood](https://github.com/solana-labs/solana/tree/6b18db969dd1616eff07de35e7b823c75339fea8/book/src/img/data-plane-neighborhood.svg)
+

book/src/cluster/vote-signing.md

@@ -0,0 +1,67 @@
+# Secure Vote Signing
+
+A validator fullnode receives entries from the current leader and submits votes confirming those entries are valid. This vote submission presents a security challenge, because forged votes that violate consensus rules could be used to slash the validator's stake.
+
+The validator votes on its chosen fork by submitting a transaction that uses an asymmetric key to sign the result of its validation work. Other entities can verify this signature using the validator's public key. If the validator's key is used to sign incorrect data \(e.g. votes on multiple forks of the ledger\), the node's stake or its resources could be compromised.
+
+Solana addresses this risk by splitting off a separate _vote signer_ service that evaluates each vote to ensure it does not violate a slashing condition.
+
+## Validators, Vote Signers, and Stakeholders
+
+When a validator receives multiple blocks for the same slot, it tracks all possible forks until it can determine a "best" one. A validator selects the best fork by submitting a vote to it, using a vote signer to minimize the possibility of its vote inadvertently violating a consensus rule and getting a stake slashed.
+
+A vote signer evaluates the vote proposed by the validator and signs the vote only if it does not violate a slashing condition. A vote signer only needs to maintain minimal state regarding the votes it signed and the votes signed by the rest of the cluster. It doesn't need to process a full set of transactions.
+
+A stakeholder is an identity that has control of the staked capital. The stakeholder can delegate its stake to the vote signer. Once a stake is delegated, the vote signer votes represent the voting weight of all the delegated stakes, and produce rewards for all the delegated stakes.
+
+Currently, there is a 1:1 relationship between validators and vote signers, and stakeholders delegate their entire stake to a single vote signer.
+
+## Signing service
+
+The vote signing service consists of a JSON RPC server and a request processor. At startup, the service starts the RPC server at a configured port and waits for validator requests. It expects the following type of requests: 1. Register a new validator node
+
+* The request must contain validator's identity \(public key\)
+* The request must be signed with the validator's private key
+* The service drops the request if signature of the request cannot be
+
+  verified
+
+* The service creates a new voting asymmetric key for the validator, and
+
+  returns the public key as a response
+
+* If a validator tries to register again, the service returns the public key
+
+  from the pre-existing keypair
+
+  1. Sign a vote
+
+* The request must contain a voting transaction and all verification data
+* The request must be signed with the validator's private key
+* The service drops the request if signature of the request cannot be
+
+  verified
+
+* The service verifies the voting data
+* The service returns a signature for the transaction
+
+## Validator voting
+
+A validator node, at startup, creates a new vote account and registers it with the cluster by submitting a new "vote register" transaction. The other nodes on the cluster process this transaction and include the new validator in the active set. Subsequently, the validator submits a "new vote" transaction signed with the validator's voting private key on each voting event.
+
+### Configuration
+
+The validator node is configured with the signing service's network endpoint \(IP/Port\).
+
+### Registration
+
+At startup, the validator registers itself with its signing service using JSON RPC. The RPC call returns the voting public key for the validator node. The validator creates a new "vote register" transaction including this public key, and submits it to the cluster.
+
+### Vote Collection
+
+The validator looks up the votes submitted by all the nodes in the cluster for the last voting period. This information is submitted to the signing service with a new vote signing request.
+
+### New Vote Signing
+
+The validator creates a "new vote" transaction and sends it to the signing service using JSON RPC. The RPC request also includes the vote verification data. On success, the RPC call returns the signature for the vote. On failure, RPC call returns the failure code.
+

book/src/ed_economic_sustainability.md

@@ -1,18 +1,18 @@
 ## Economic Sustainability
 
-Long term economic sustainability is one of the guiding principles of Solana’s economic design. While it is impossible to predict how decentralized economies will develop over time, especially economies with flexible decentralized governances, we can arrange economic components such that, under certain conditions, a sustainable economy may take shape in the long term. In the case of Solana’s network, these components take the form of the remittances and deposits into and out of the reserve ‘mining pool’.
+Long term economic sustainability is one of the guiding principles of Solana’s economic design. While it is impossible to predict how decentralized economies will develop over time, especially economies with flexible decentralized governances, we can arrange economic components such that, under certain conditions, a sustainable economy may take shape in the long term. In the case of Solana’s network, these components take the form of token issuance (via inflation) and token burning’.
 
-The dominant remittances from the Solana mining pool are validator and replicator rewards. The deposit mechanism is a flat, protocol-specified and adjusted, % of each transaction fee.
+The dominant remittances from the Solana mining pool are validator and replicator rewards. The disinflationary mechanism is a flat, protocol-specified and adjusted, % of each transaction fee.
 
-The Replicator rewards are to be delivered to replicators from the mining pool after successful PoRep validation. The per-PoRep reward amount is determined as a function of the total network storage redundancy at the time of the PoRep validation and the network goal redundancy. This function is likely to take the form of a discount from a base reward to be delivered when the network has achieved and maintained its goal redundancy. An example of such a reward function is shown in **Figure 3**
+The Replicator rewards are to be delivered to replicators as a portion of the network inflation after successful PoRep validation. The per-PoRep reward amount is determined as a function of the total network storage redundancy at the time of the PoRep validation and the network goal redundancy. This function is likely to take the form of a discount from a base reward to be delivered when the network has achieved and maintained its goal redundancy. An example of such a reward function is shown in **Figure 3**
 
 <!-- ![image alt text](porep_reward.png) -->
-<p style="text-align:center;"><img src="img/porep_reward.png" alt="==PoRep Reward Curve ==" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/porep_reward.png" alt="==PoRep Reward Curve ==" width="800"/></p>
 
 **Figure 3**: Example PoRep reward design as a function of global network storage redundancy.
 
 In the example shown in Figure 1, multiple per PoRep base rewards are explored (as a % of Tx Fee) to be delivered when the global ledger replication redundancy meets 10X. When the global ledger replication redundancy is less than 10X, the base reward is discounted as a function of the square of the ratio of the actual ledger replication redundancy to the goal redundancy (i.e. 10X).
 
-The other protocol-based remittance goes to validation-clients as a reward distributed in proportion to stake-weight for voting to validate the ledger state. The functional issuance of this reward is described in [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md) and is designed to reduce over time until validators are incentivized solely through collection of transaction fees. Therefore, in the long-run, protocol-based rewards to replication-nodes will be the only remittances from the mining pool, and will have to be countered by the portion of each non-PoRep transaction fee that is directed back into the mining pool. I.e. for a long-term self-sustaining economy, replicator-client rewards must be subsidized through a minimum fee on each non-PoRep transaction pre-allocated to the mining pool.  Through this constraint, we can write the following inequality:
-
-**== WIP [here](https://docs.google.com/document/d/1HBDasdkjS4Ja9wC_tIUsZPVcxGAWTuYOq9zf6xoQNps/edit?usp=sharing) ==**
+<!-- The other protocol-based remittance goes to validation-clients as a reward distributed in proportion to stake-weight for voting to validate the ledger state. The functional issuance of this reward is described in [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md) and is designed to reduce over time until validators are incentivized solely through collection of transaction fees. Therefore, in the long-run, protocol-based rewards to replication-nodes will be the only remittances from the mining pool, and will have to be countered by the portion of each non-PoRep transaction fee that is directed back into the mining pool. I.e. for a long-term self-sustaining economy, replicator-client rewards must be subsidized through a minimum fee on each non-PoRep transaction pre-allocated to the mining pool.  Through this constraint, we can write the following inequality:
+--> 
+<!-- **== WIP [here](https://docs.google.com/document/d/1HBDasdkjS4Ja9wC_tIUsZPVcxGAWTuYOq9zf6xoQNps/edit?usp=sharing) ==** -->

book/src/ed_mvp.md

@@ -5,8 +5,9 @@ The preceeding sections, outlined in the [Economic Design Overview](ed_overview.
 ### MVP Economic Features
 
 * Faucet to deliver testnet SOLs to validators for staking and dapp development.
-* Mechanism by which validators are rewarded in proportion to their stake. Interest rate mechansism (i.e. to be determined by total % staked) to come later.
-* Ability to delegate tokens to validator nodes.
+* Mechanism by which validators are rewarded via network inflation.
+* Ability to delegate tokens to validator nodes
+* Validator set commission fees on interest from delegated tokens.
 * Replicators to receive fixed, arbitrary reward for submitting validated PoReps. Reward size mechanism (i.e. PoRep reward as a function of total ledger redundancy) to come later.
 * Pooling of replicator PoRep transaction fees and weighted distribution to validators based on PoRep verification (see [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md). It will be useful to test this protection against attacks on testnet.
 * Nice-to-have: auto-delegation of replicator rewards to validator.

book/src/ed_overview.md

@@ -1,16 +1,16 @@
 ## Economic Design Overview
 
-Solana’s crypto-economic system is designed to promote a healthy, long term self-sustaining economy with participant incentives aligned to the security and decentralization of the network. The main participants in this economy are validation-clients and replication-clients. Their contributions to the network, state validation and data storage respectively, and their requisite remittance mechanisms are discussed below.
+Solana’s crypto-economic system is designed to promote a healthy, long term self-sustaining economy with participant incentives aligned to the security and decentralization of the network. The main participants in this economy are validation-clients and replication-clients. Their contributions to the network, state validation and data storage respectively, and their requisite incentive mechanisms are discussed below.
 
-The main channels of participant remittances are referred to as protocol-based rewards and transaction fees. Protocol-based rewards are protocol-derived issuances from a network-controlled reserve of tokens (sometimes referred to as the ‘mining pool’). These rewards will constitute the total reward delivered to replication clients and a portion of the total rewards for validation clients, the remaining sourced from transaction fees. In the early days of the network, it is likely that protocol-based rewards, deployed based on predefined issuance schedule, will drive the majority of participant incentives to join the network.
+The main channels of participant remittances are referred to as protocol-based rewards and transaction fees. Protocol-based rewards are issuances from a global, protocol-defined, inflation rate. These rewards will constitute the total reward delivered to replication and validation clients, the remaining sourced from transaction fees. In the early days of the network, it is likely that protocol-based rewards, deployed based on predefined issuance schedule, will drive the majority of participant incentives to participate in the network.
 
-These protocol-based rewards, to be distributed to participating validation and replication clients, are to be specified as annual interest rates calculated per, real-time, Solana epoch [DEFINITION]. As discussed further below, the issuance rates are determined as a function of total network validator staked percentage and total replication provided by replicators in each previous epoch. The choice for validator and replicator client rewards to be based on participation rates, rather than a global fixed inflation or interest rate, emphasizes a protocol priority of overall economic security, rather than monetary supply predictability. Due to Solana’s hard total supply cap of 1B tokens and the bounds of client participant rates in the protocol, we believe that global interest, and supply issuance, scenarios should be able to be modeled with reasonable uncertainties.
+These protocol-based rewards, to be distributed to participating validation and replication clients, are to be a result of a global supply inflation rate, calculated per Solana epoch and distributed amongst the active validator set. As discussed further below, the per annum inflation rate is based on a pre-determined disinflationary schedule. This provides the network with monetary supply predictability which supports long term economic stability and security. 
 
-Transaction fees are market-based participant-to-participant transfers, attached to network interactions as a necessary motivation and compensation for the inclusion and execution of a proposed transaction (be it a state execution or proof-of-replication verification). A mechanism for continuous and long-term funding of the mining pool through a pre-dedicated portion of transaction fees is also discussed below.
+Transaction fees are market-based participant-to-participant transfers, attached to network interactions as a necessary motivation and compensation for the inclusion and execution of a proposed transaction (be it a state execution or proof-of-replication verification). A mechanism for long-term economic stability and forking protection through partial burning of each transaction fee is also discussed below.
 
-A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics.md), [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. The [Replication-client Economics](ed_replication_client_economics.md) chapter will review the Solana network design for global ledger storage/redundancy and replicator-client economics ([Storage-replication rewards](ed_rce_storage_replication_rewards.md)) along with a replicator-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md). The [Economic Sustainability](ed_economic_sustainability.md) section dives deeper into Solana’s design for long-term economic sustainability and outlines the constraints and conditions for a self-sustaining economy. An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. Finally, in chapter [Attack Vectors](ed_attack_vectors.md), various attack vectors will be described and potential vulnerabilities explored and parameterized.
+A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics.md), [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. Additionally, in [Storage Rent Economics](ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. The [Replication-client Economics](ed_replication_client_economics.md) chapter will review the Solana network design for global ledger storage/redundancy and replicator-client economics ([Storage-replication rewards](ed_rce_storage_replication_rewards.md)) along with a replicator-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md). <!-- The [Economic Sustainability](ed_economic_sustainability.md) section dives deeper into Solana’s design for long-term economic sustainability and outlines the constraints and conditions for a self-sustaining economy.--> An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. Finally, in chapter [Attack Vectors](ed_attack_vectors.md), various attack vectors will be described and potential vulnerabilities explored and parameterized.
 
 <!-- ![img alt text](solana_economic_design.png) -->
-<p style="text-align:center;"><img src="img/solana_economic_design.png" alt="== Solana Economic Design Diagram ==" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/economic_design_infl_230719.png" alt="== Solana Economic Design Diagram ==" width="800"/></p>
 
 **Figure 1**: Schematic overview of Solana economic incentive design.

book/src/ed_rce_replication_client_reward_auto_delegation.md

@@ -1,5 +1,5 @@
 ### Replication-client Reward Auto-delegation
 
-The ability for Solana network participant’s to earn rewards by providing storage service is a unique on-boarding path that requires little hardware overhead and minimal upfront capital. It offers an avenue for individuals with extra-storage space on their home laptops or PCs to contribute to the security of the network and become integrated into the Solana economy.
+The ability for Solana network participants to earn rewards by providing storage service is a unique on-boarding path that requires little hardware overhead and minimal upfront capital. It offers an avenue for individuals with extra-storage space on their home laptops or PCs to contribute to the security of the network and become integrated into the Solana economy.
 
-To enhance this on-boarding ramp and facilitate further participation and investment in the Solana economy, replication-clients have the opportunity to auto-delegate their rewards to validation-clients of their choice. Much like the automatic reinvestment of stock dividends, in this scenario, a replicator-client can earn Solana tokens by providing some storage capacity to the network (i.e. via submitting valid PoReps), have the protocol-based rewards automatically assigned as delegation to a staked validator node and therefore earning interest in the validation-client reward pool.
+To enhance this on-boarding ramp and facilitate further participation and investment in the Solana economy, replication-clients have the opportunity to auto-delegate their rewards to validation-clients of their choice. Much like the automatic reinvestment of stock dividends, in this scenario, a replicator-client can earn Solana tokens by providing some storage capacity to the network (i.e. via submitting valid PoReps), have the protocol-based rewards automatically assigned as delegation to a staked validator node of the replicator's choice and earn interest, less a fee, from the validation-client's network participation.

book/src/ed_replication_client_economics.md

@@ -1,3 +1,3 @@
 ## Replication-client economics
 
-Replication-clients should be rewarded for providing the network with storage space. Incentivization of the set of replicators provides data security through redundancy of the historical ledger. Replication nodes are rewarded in proportion to the amount of ledger data storage provided. These rewards are captured by generating and entering Proofs of Replication (PoReps) into the PoH stream which can be validated by Validation nodes as described above in the [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md) chapter.
+Replication-clients should be rewarded for providing the network with storage space. Incentivization of the set of replicators provides data security through redundancy of the historical ledger. Replication nodes are rewarded in proportion to the amount of ledger data storage provided, as proved by successfully submitting Proofs-of-Replication to the cluster.. These rewards are captured by generating and entering Proofs of Replication (PoReps) into the PoH stream which can be validated by Validation nodes as described above in the [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md) chapter.

book/src/ed_storage_rent_economics.md

@@ -0,0 +1,18 @@
+## Storage Rent Economics
+
+Each transaction that is submitted to the Solana ledger imposes costs. Transaction fees paid by the submitter, and collected by a validator, in theory, account for the acute, transacitonal, costs of validating and adding that data to the ledger. At the same time, our compensation design for replicators (see [Replication-client Economics](ed_replication_client_economics.md)), in theory, accounts for the long term storage of the historical ledger. Unaccounted in this process is the mid-term storage of active ledger state, necessarily maintined by the rotating validator set. This type of storage imposes costs not only to validators but also to the broader network as active state grows so does data transmission and validation overhead. To account for these costs, we describe here our preliminary design and implementation of storage rent. 
+
+Storage rent can be paid via one of two methods:
+
+Method 1: Set it and forget it
+
+With this approach, accounts with two-years worth of rent deposits secured are exempt from network rent charges. By maintaining this minimum-balance, the broader network benefits from reduced liquitity and the account holder can trust that their `Account::data` will be retained for continual access/usage. 
+
+Method 2: Pay per byte
+
+If an account has less than two-years worth of deposited rent the network charges rent on a per-epoch basis, in credit for the next epoch (but in arrears when necessary). This rent is deducted at a rate specified in genesis, in lamports per kilobyte-year.
+
+For information on the technical implementation details of this design, see the [Rent](rent.md) section. 
+
+
+

book/src/ed_validation_client_economics.md

@@ -1,3 +1,6 @@
 ## Validation-client Economics
 
-Validator-clients are eligible to receive protocol-based (i.e. via mining pool) rewards issued via stake-based annual interest rates by providing compute (CPU+GPU) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic schedule as a function of total amount of Solana tokens staked in the system and duration since network launch (genesis block). Additionally, these clients may earn revenue through two types of transaction fees: state-validation transaction fees and pooled Proof-of-Replication (PoRep) transaction fees. The distribution of these two types of transaction fees to the participating validation set are designed independently as economic goals and attack vectors are unique between the state- generation/validation mechanism and the ledger replication/validation mechanism. For clarity, we separately describe the design and motivation of the three types of potential revenue streams for validation-clients below: state-validation protocol-based rewards, state-validation transaction fees and PoRep-validation transaction fees.
+Validator-clients are eligible to receive protocol-based (i.e. inflation-based) rewards issued via stake-based annual interest rates (calculated per epoch) by providing compute (CPU+GPU) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic disinflationary schedule as a function of total amount of circulating tokens. 
+The network is expected to launch with an annual inflation rate around 15%, set to decrease by 15% per year until a long-term stable rate of 1-2% is reached. These issuances are to be split and distributed to participating validators and replicators, with around 90% of the issued tokens allocated for validator rewards. Because the network will be distributing a fixed amount of inflation rewards across the stake-weighted valdiator set, any individual validator's interest rate will be a function of the amount of staked SOL in relation to the circulating SOL. 
+
+Additionally, validator clients may earn revenue through fees via state-validation transactions and Proof-of-Replication (PoRep) transactions. For clarity, we separately describe the design and motivation of these revenue distriubutions for validation-clients below: state-validation protocol-based rewards, state-validation transaction fees and rent,  and PoRep-validation transaction fees.

book/src/ed_vce_replication_validation_transaction_fees.md

@@ -1,9 +1,9 @@
 ### Replication-validation Transaction Fees
 
-As previously mentioned, validator-clients will also be responsible for validating PoReps submitted into the PoH stream by replicator-clients. In this case, validators are providing compute (CPU/GPU) and light storage resources to confirm that these replication proofs could only be generated by a client that is storing the referenced PoH leger block.2
+As previously mentioned, validator-clients will also be responsible for validating PoReps submitted into the PoH stream by replicator-clients. In this case, validators are providing compute (CPU/GPU) and light storage resources to confirm that these replication proofs could only be generated by a client that is storing the referenced PoH leger block.
 
-While replication-clients are incentivized and rewarded through protocol-based rewards schedule (see [Replication-client Economics](ed_replication_client_economics.md)), validator-clients will be incentivized to include and validate PoReps in PoH through the distribution of the transaction fees associated with the submitted PoRep. As will be described in detail in the Section 3.1, replication-client rewards are protocol-based and designed to reward based on a global data redundancy factor. I.e. the protocol will incentivize replication-client participation through rewards based on a target ledger redundancy (e.g. 10x data redundancy). It was chosen not to include a distribution of these rewards to PoRep validators, and to rely only on the collection of PoRep attached transaction fees, due to the fact that the confluence of two participation incentive modes (state-validation inflation rate via global staked % and replication-validation rewards based on global redundancy factor) on the incentives of a single network participant (a validator-client) potentially opened up a significant incentive-driven attack surface area.
+While replication-clients are incentivized and rewarded through protocol-based rewards schedule (see [Replication-client Economics](ed_replication_client_economics.md)), validator-clients will be incentivized to include and validate PoReps in PoH through collection of transaction fees associated with the submitted PoReps and distribution of protocol rewards proportional to the validated PoReps. As will be described in detail in the Section 3.1, replication-client rewards are protocol-based and designed to reward based on a global data redundancy factor. I.e. the protocol will incentivize replication-client participation through rewards based on a target ledger redundancy (e.g. 10x data redundancy). 
 
-The validation of PoReps by validation-clients is computationally more expensive than state-validation (detail in the [Economic Sustainability](ed_economic_sustainability.md) chapter), thus the transaction fees are expected to be proportionally higher. However, because replication-client rewards are distributed in proportion to and only after submitted PoReps are validated, they are uniquely motivated for the inclusion and validation of their proofs. This pressure is expected to generate an adequate market economy between replication-clients and validation-clients. Additionally, transaction fees submitted with PoReps have no minimum amount pre-allocated to the mining pool, as do state-validation transaction fees.
+The validation of PoReps by validation-clients is computationally more expensive than state-validation (detail in the [Economic Sustainability](ed_economic_sustainability.md) chapter), thus the transaction fees are expected to be proportionally higher. 
 
-There are various attack vectors available for colluding validation and replication clients, as described in detail below in [Economic Sustainability](ed_economic_sustainability). To protect against various collusion attack vectors, for a given epoch, PoRep transaction fees are pooled, and redistributed across participating validation-clients in proportion to the number of validated PoReps in the epoch less the number of invalidated PoReps [DIAGRAM]. This design rewards validators proportional to the number of PoReps they process and validate, while providing negative pressure for validation-clients to submit lazy or malicious invalid votes on submitted PoReps (note that it is computationally prohibitive to determine whether a validator-client has marked a valid PoRep as invalid).
+There are various attack vectors available for colluding validation and replication clients, also described in detail below in [Economic Sustainability](ed_economic_sustainability). To protect against various collusion attack vectors, for a given epoch, validator rewards are distributed across participating validation-clients in proportion to the number of validated PoReps in the epoch less the number of PoReps that mismatch the replicators challenge. The PoRep challenge game is described in [Ledger Replication](https://github.com/solana-labs/solana/blob/master/book/src/ledger-replication.md#the-porep-game). This design rewards validators proportional to the number of PoReps they process and validate, while providing negative pressure for validation-clients to submit lazy or malicious invalid votes on submitted PoReps (note that it is computationally prohibitive to determine whether a validator-client has marked a valid PoRep as invalid).

book/src/ed_vce_state_validation_protocol_based_rewards.md

@@ -1,46 +1,40 @@
 ### State-validation protocol-based rewards
 
-Validator-clients have two functional roles in the Solana network
+Validator-clients have two functional roles in the Solana network:
 
-* Validate (vote) the current global state of that PoH along with any Proofs-of-Replication (see [Replication Client Economics](ed_replication_client_economics.md)) that they are eligible to validate
+* Validate (vote) the current global state of that PoH along with any Proofs-of-Replication (see [Replication Client Economics](ed_replication_client_economics.md)) that they are eligible to validate.
 
 * Be elected as ‘leader’ on a stake-weighted round-robin schedule during which time they are responsible for collecting outstanding transactions and Proofs-of-Replication and incorporating them into the PoH, thus updating the global state of the network and providing chain continuity.
 
-Validator-client rewards for these services are to be distributed at the end of each Solana epoch. Compensation for validator-clients is provided via a protocol-based annual interest rate dispersed in proportion to the stake-weight of each validator (see below) along with leader-claimed transaction fees available during each leader rotation. I.e. during the time a given validator-client is elected as leader, it has the opportunity to keep a portion of each non-PoRep transaction fee, less a protocol-specified amount that is returned to the mining pool (see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)). PoRep transaction fees are not collected directly by the leader client but pooled and returned to the validator set in proportion to the number of successfully validated PoReps. (see [Replication-client Transaction Fees](ed_vce_replication_validation_transaction_fees.md))
+Validator-client rewards for these services are to be distributed at the end of each Solana epoch. As previously discussed, compensation for validator-clients is provided via a protocol-based annual inflation rate dispersed in proportion to the stake-weight of each validator (see below) along with leader-claimed transaction fees available during each leader rotation. I.e. during the time a given validator-client is elected as leader, it has the opportunity to keep a portion of each transaction fee, less a protocol-specified amount that is destroyed (see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)). PoRep transaction fees are also collected by the leader client and validator PoRep rewards are distributed in proportion to the number of validated PoReps less the number of PoReps that mismatch a replicator's challenge. (see [Replication-client Transaction Fees](ed_vce_replication_validation_transaction_fees.md))
 
 
-The protocol-based annual interest-rate (%) per epoch to be distributed to validation-clients is to be a function of:
+The effective protocol-based annual interest rate (%) per epoch received by validation-clients is to be a function of:
 
-* the current fraction of staked SOLs out of the current total circulating supply,
+* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule (see [Validation-client Economics](ed_validartion_client_economics.md))
 
-* the global time since the genesis block instantiation
+* the fraction of staked SOLs out of the current total circulating supply,
 
-* the up-time/participation [% of available slots/blocks that validator had opportunity to vote on?] of a given validator over the previous epoch.
+* the up-time/participation [% of available slots that validator had opportunity to vote on] of a given validator over the previous epoch.
 
-The first two factors are protocol parameters only (i.e. independent of validator behavior in a given epoch) and describe a global validation reward schedule designed to both incentivize early participation and optimal security in the network. This schedule sets a maximum annual validator-client interest rate per epoch.
+The first factor is a function of protocol parameters only (i.e. independent of validator behavior in a given epoch) and results in a global validation reward schedule designed to incentivize early participation, provide clear montetary stability and provide optimal security in the network. 
 
-At any given point in time, this interest rate is pegged to a defined value given a specific % staked SOL out of the circulating supply (e.g. 10% interest rate when 66% of circulating SOL is staked). The interest rate adjusts as the square-root [TBD] of the % staked, leading to higher validation-client interest rates as the % staked drops below the targeted goal, thus incentivizing more participation leading to more security in the network. An example of such a schedule, for a specified point in time (e.g. network launch) is shown in **Table 1**.
+At any given point in time, a specific validator's interest rate can be determined based on the porportion of circulating supply that is staked by the network and the validator's uptime/activity in the previous epoch. For example, consider a hypothetical instance of the network with an initial circulating token supply of 250MM tokens with an additional 250MM vesting over 3 years. Additionally an inflation rate is specified at network launch of 7.5%, and a disinflationary schedule of 20% decrease in inflation rate per year (the actual rates to be implemented are to be worked out during the testnet experimentation phase of mainnet launch). With these broad assumptions, the 10-year inflation rate (adjusted daily for this example) is shown in **Figure 2**, while the total circulating token supply is illustrated in **Figure 3**. Neglected in this toy-model is the inflation supression due to the portion of each transaction fee that is to be destroyed.
 
-| Percentage circulating supply staked [%] | Annual validator-client interest rate [%] |
-| ---:    | ---:      |
-| 5       | 13.87     |
-| 15      | 13.31     |
-| 25      | 12.73     |
-| 35      | 12.12     |
-| 45      | 11.48     |
-| 55      | 10.80     |
-| **66**  | **10.00** |
-| 75      | 9.29      |
-| 85      | 8.44      |    
+<p style="text-align:center;"><img src=".gitbook/assets/p_ex_schedule.png" alt="drawing" width="800"/></p>
+**Figure 2:** In this example schedule, the annual inflation rate [%] reduces at around 20% per year, until it reaches the long-term, fixed, 1.5% rate.
 
-**Table 1:** Example interest rate schedule based on % SOL staked out of circulating supply. In this case, interest rates are fixed at 10% for 66% of staked circulating supply
+<p style="text-align:center;"><img src=".gitbook/assets/p_ex_supply.png" alt="drawing" width="800"/></p>
+**Figure 3:** The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in **Figure 2**
 
-Over time, the interest rate, at any network staked percentage, will drop as described by an algorithmic schedule. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. This mining-pool provided interest rate will reduce over time until a network-chosen baseline value is reached. This is a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for both state-validation and ledger storage replication (PoReps) are not accounted for here. A validation-client interest rate schedule as a function of % network staked and time is shown in** Figure 2**.
+Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabalize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for state-validation and ledger storage replication (PoReps) are not accounted for here. 
+
+Given these example parameters, annualized validator-specific interest rates can be determined based on the global fraction of tokens bonded as stake, as well as their uptime/activity in the previous epoch. For the purpose of this example, we assume 100% uptime for all validators and a split in interest-based rewards between validators and replicator nodes of 80%/20%. Additionally, the fraction of staked circulating supply is assummed to be constant. Based on these assumptions, an annualized validation-client interest rate schedule as a function of % circulating token supply that is staked is shown in** Figure 4**.
 
 <!-- ![== Validation Client Interest Rates Figure ==](validation_client_interest_rates.png =250x) -->
 
-<p style="text-align:center;"><img src="img/validation_client_interest_rates.png" alt="drawing" width="800"/></p>
+<p style="text-align:center;"><img src=".gitbook/assets/p_ex_interest.png" alt="drawing" width="800"/></p>
 
-**Figure 2:** In this example schedule, the annual interest rate [%] reduces at around 16.7% per year, until it reaches the long-term, fixed, 4% rate.
+**Figure 4:** Shown here are example validator interest rates over time, neglecting transaction fees, segmented by fraction of total circulating supply bonded as stake.
 
-This epoch-specific protocol-defined interest rate sets an upper limit of *protocol-generated* annual interest rate (not absolute total interest rate) possible to be delivered to any validator-client per epoch. The distributed interest rate per epoch is then discounted from this value based on the participation of the validator-client during the previous epoch. Each epoch is comprised of XXX slots. The protocol-defined interest rate is then discounted by the log [TBD] of the % of slots a given validator submitted a vote on a PoH branch during that epoch, see **Figure XX**
+This epoch-specific protocol-defined interest rate sets an upper limit of *protocol-generated* annual interest rate (not absolute total interest rate) possible to be delivered to any validator-client per epoch. The distributed interest rate per epoch is then discounted from this value based on the participation of the validator-client during the previous epoch.

book/src/ed_vce_state_validation_transaction_fees.md

@@ -1,6 +1,6 @@
 ### State-validation Transaction Fees
 
-Each message sent through the network, to be processed by the current leader validation-client and confirmed as a global state transaction, must contain a transaction fee. Transaction fees offer many benefits in the Solana economic design, for example they:
+Each transaction sent through the network, to be processed by the current leader validation-client and confirmed as a global state transaction, must contain 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,
 
@@ -10,11 +10,11 @@ Each message sent through the network, to be processed by the current leader val
 
 * and provide potential long-term economic stability of the network through a protocol-captured minimum fee amount per transaction, as described below.
 
-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 of each transaction fee is sent to the mining pool, with the resulting fee going to the current leader processing the transaction. These pooled fees, then re-enter the system through rewards distributed to validation-clients, through the process described above, and replication-clients, as discussed below.
+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 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, and replication-clients, as discussed below. 
 
-The intent of this design is to retain leader incentive to include as many transactions as possible within the leader-slot time, while providing a redistribution avenue that protects against "tax evasion" attacks (i.e. side-channel fee payments)<sup>[1](ed_referenced.md)</sup>. Constraints on the fixed portion of transaction fees going to the mining pool, to establish long-term economic sustainability, are established and discussed in detail in the [Economic Sustainability](ed_economic_sustainability.md) section.
+Transaction fees are set by the network cluster based on recent historical throughput, see [Congestion Driven Fees](transaction-fees.md#congestion-driven-fees). This minimum portion of each transaction fee can be dynamically adjusted depending on historical gas usage. In this way, the protocol can use the minimum fee to target a desired hardware utilisation. By monitoring a protocol specified gas usage with respect to a desired, target usage amount, the minimum fee can be raised/lowered which should, in turn, lower/raise the actual gas usage 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. 
 
-This minimum, protocol-earmarked, portion of each transaction fee can be dynamically adjusted depending on historical gas usage. In this way, the protocol can use the minimum fee to target a desired hardware utilisation. By monitoring a protocol specified gas usage with respect to a desired, target usage amount (e.g. 50% of a block's capacity), the minimum fee can be raised/lowered which should, in turn, lower/raise the actual gas usage 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 mechansim that protects against "tax evasion" attacks (i.e. side-channel fee payments)<sup>[1](ed_referenced.md)</sup>. 
 
-Additionally, the minimum protocol captured fee can be a consideration in fork selection. In the case of a PoH fork with a  malicious, censoring leader, we would expect the total procotol captured fee 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 fees on their fork themselves, thus potentially reducing the incentive to censor in the first place. 
+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. 
 

book/src/ed_vce_validation_stake_delegation.md

@@ -26,4 +26,4 @@ Despite the low-barrier to entry as a validation-client, from a capital investme
 
     a. This participant has the additional option to directly delegate their earned storage rewards ([Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md))
 
-Delegation of tokens to validation-clients, via option 1, provides a way for passive Solana token holders to become part of the active Solana economy and earn interest rates proportional to the interest rate generated by the delegated validation-client. Additionally, this feature creates a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services.
+Delegation of tokens to validation-clients, via option 1, provides a way for passive Solana token holders to become part of the active Solana economy and earn interest rates proportional to the interest rate generated by the delegated validation-client. Additionally, this feature intends to create a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services.

book/src/fork-generation.md

@@ -67,7 +67,7 @@ PoH stream with possible forks over time.  L1, L2, etc. are leader slots, and
 represent ticks only, and time flows downwards in the diagram.
 
 
-<img alt="Fork generation" src="img/fork-generation.svg" class="center"/>
+<img alt="Fork generation" src=".gitbook/assets/fork-generation.svg" class="center"/>
 
 Note that an `E` appearing on 2 forks at the same slot is a slashable
 condition, so a validator observing `E3` and `E3'` can slash L3 and safely

book/src/getting-started.md

@@ -44,7 +44,7 @@ $ git checkout $TAG
 Ensure important programs such as the vote program are built before any
 nodes are started
 ```bash
-$ cargo build --all
+$ cargo build
 ```
 
 The network is initialized with a genesis ledger generated by running the
@@ -110,7 +110,7 @@ some transactions!
 In a separate shell start the client:
 
 ```bash
-$ ./multinode-demo/client.sh # runs against localhost by default
+$ ./multinode-demo/bench-tps.sh # runs against localhost by default
 ```
 
 What just happened? The client demo spins up several threads to send 500,000 transactions
@@ -161,7 +161,7 @@ This will dump all the threads stack traces into gdb.txt
 In this example the client connects to our public testnet. To run validators on the testnet you would need to open udp ports `8000-10000`.
 
 ```bash
-$ ./multinode-demo/client.sh --entrypoint testnet.solana.com:8001 --drone testnet.solana.com:9900 --duration 60 --tx_count 50
+$ ./multinode-demo/bench-tps.sh --entrypoint testnet.solana.com:8001 --drone testnet.solana.com:9900 --duration 60 --tx_count 50
 ```
 
 You can observe the effects of your client's transactions on our [dashboard](https://metrics.solana.com:3000/d/testnet/testnet-hud?orgId=2&from=now-30m&to=now&refresh=5s&var-testnet=testnet)

book/src/getting-started/README.md

@@ -0,0 +1,132 @@
+# Getting Started
+
+The Solana git repository contains all the scripts you might need to spin up your own local testnet. Depending on what you're looking to achieve, you may want to run a different variation, as the full-fledged, performance-enhanced multinode testnet is considerably more complex to set up than a Rust-only, singlenode testnode. If you are looking to develop high-level features, such as experimenting with smart contracts, save yourself some setup headaches and stick to the Rust-only singlenode demo. If you're doing performance optimization of the transaction pipeline, consider the enhanced singlenode demo. If you're doing consensus work, you'll need at least a Rust-only multinode demo. If you want to reproduce our TPS metrics, run the enhanced multinode demo.
+
+For all four variations, you'd need the latest Rust toolchain and the Solana source code:
+
+First, install Rust's package manager Cargo.
+
+```bash
+$ curl https://sh.rustup.rs -sSf | sh
+$ source $HOME/.cargo/env
+```
+
+Now checkout the code from github:
+
+```bash
+$ git clone https://github.com/solana-labs/solana.git
+$ cd solana
+```
+
+The demo code is sometimes broken between releases as we add new low-level features, so if this is your first time running the demo, you'll improve your odds of success if you check out the [latest release](https://github.com/solana-labs/solana/releases) before proceeding:
+
+```bash
+$ TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
+$ git checkout $TAG
+```
+
+### Configuration Setup
+
+Ensure important programs such as the vote program are built before any nodes are started
+
+```bash
+$ cargo build --all
+```
+
+The network is initialized with a genesis ledger generated by running the following script.
+
+```bash
+$ ./multinode-demo/setup.sh
+```
+
+### Drone
+
+In order for the fullnodes and clients to work, we'll need to spin up a drone to give out some test tokens. The drone delivers Milton Friedman-style "air drops" \(free tokens to requesting clients\) to be used in test transactions.
+
+Start the drone with:
+
+```bash
+$ ./multinode-demo/drone.sh
+```
+
+### Singlenode Testnet
+
+Before you start a validator, make sure you know the IP address of the machine you want to be the bootstrap leader for the demo, and make sure that udp ports 8000-10000 are open on all the machines you want to test with.
+
+Now start the bootstrap leader in a separate shell:
+
+```bash
+$ ./multinode-demo/bootstrap-leader.sh
+```
+
+Wait a few seconds for the server to initialize. It will print "leader ready..." when it's ready to receive transactions. The leader will request some tokens from the drone if it doesn't have any. The drone does not need to be running for subsequent leader starts.
+
+### Multinode Testnet
+
+To run a multinode testnet, after starting a leader node, spin up some additional validators in separate shells:
+
+```bash
+$ ./multinode-demo/validator-x.sh
+```
+
+To run a performance-enhanced full node on Linux, [CUDA 10.0](https://developer.nvidia.com/cuda-downloads) must be installed on your system:
+
+```bash
+$ ./fetch-perf-libs.sh
+$ SOLANA_CUDA=1 ./multinode-demo/bootstrap-leader.sh
+$ SOLANA_CUDA=1 ./multinode-demo/validator.sh
+```
+
+### Testnet Client Demo
+
+Now that your singlenode or multinode testnet is up and running let's send it some transactions!
+
+In a separate shell start the client:
+
+```bash
+$ ./multinode-demo/client.sh # runs against localhost by default
+```
+
+What just happened? The client demo spins up several threads to send 500,000 transactions to the testnet as quickly as it can. The client then pings the testnet periodically to see how many transactions it processed in that time. Take note that the demo intentionally floods the network with UDP packets, such that the network will almost certainly drop a bunch of them. This ensures the testnet has an opportunity to reach 710k TPS. The client demo completes after it has convinced itself the testnet won't process any additional transactions. You should see several TPS measurements printed to the screen. In the multinode variation, you'll see TPS measurements for each validator node as well.
+
+### Testnet Debugging
+
+There are some useful debug messages in the code, you can enable them on a per-module and per-level basis. Before running a leader or validator set the normal RUST\_LOG environment variable.
+
+For example
+
+* To enable `info` everywhere and `debug` only in the solana::banking\_stage module:
+
+  ```bash
+  $ export RUST_LOG=solana=info,solana::banking_stage=debug
+  ```
+
+* To enable BPF program logging:
+
+  ```bash
+  $ export RUST_LOG=solana_bpf_loader=trace
+  ```
+
+Generally we are using `debug` for infrequent debug messages, `trace` for potentially frequent messages and `info` for performance-related logging.
+
+You can also attach to a running process with GDB. The leader's process is named _solana-validator_:
+
+```bash
+$ sudo gdb
+attach <PID>
+set logging on
+thread apply all bt
+```
+
+This will dump all the threads stack traces into gdb.txt
+
+## Public Testnet
+
+In this example the client connects to our public testnet. To run validators on the testnet you would need to open udp ports `8000-10000`.
+
+```bash
+$ ./multinode-demo/client.sh --entrypoint testnet.solana.com:8001 --drone testnet.solana.com:9900 --duration 60 --tx_count 50
+```
+
+You can observe the effects of your client's transactions on our [dashboard](https://metrics.solana.com:3000/d/testnet/testnet-hud?orgId=2&from=now-30m&to=now&refresh=5s&var-testnet=testnet)
+

book/src/getting-started/testnet-participation.md

@@ -0,0 +1,7 @@
+# Testnet Participation
+
+Participate in our testnet:
+
+* [Running a Validator](../running-validator/)
+* [Running a Replicator](../running-replicator.md)
+

book/src/getting-started/webwallet.md

@@ -0,0 +1,16 @@
+# Example Client: Web Wallet
+
+## Build and run a web wallet locally
+
+First fetch the example code:
+
+```bash
+$ git clone https://github.com/solana-labs/example-webwallet.git
+$ cd example-webwallet
+$ TAG=$(git describe --tags $(git rev-list --tags
+--max-count=1))
+$ git checkout $TAG
+```
+
+Next, follow the steps in the git repository's [README](https://github.com/solana-labs/example-webwallet/blob/master/README.md).
+

book/src/implemented-proposals/README.md

@@ -0,0 +1,4 @@
+# Implemented Design Proposals
+
+The following design proposals are fully implemented.
+

book/src/implemented-proposals/blocktree.md

@@ -0,0 +1,93 @@
+# Blocktree
+
+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.
+
+The blocktree allows a validator to record every blob it observes on the network, in any order, as long as the blob is signed by the expected leader for a given slot.
+
+Blobs are moved to a fork-able key space the tuple of `leader slot` + `blob 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 blobs are served out of RAM or recent files and out of deeper storage for less recent blobs, as implemented by the store backing Blocktree.
+
+## Functionalities of Blocktree
+
+1. Persistence: the Blocktree lives in the front of the nodes verification
+
+   pipeline, right behind network receive and signature verification.  If the
+
+   blob 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
+
+   blob that's been received. Blocktree stores blobs with signatures,
+
+   preserving the chain of origination.
+
+3. Forks: Blocktree supports random access of blobs, 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
+
+   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.
+
+## Blocktree Design
+
+1. Entries in the Blocktree are stored as key-value pairs, where the key is the concatenated slot index and blob index for an entry, and the value is the entry data. Note blob 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:
+   * `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 blob index `n`, such that for all `m < n`, there exists a blob in this slot with blob index equal to `n` \(i.e. the highest consecutive blob index\).
+   * `received` - The highest received blob 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 blob that is flagged as the last blob for this slot. This flag on a blob will be set by the leader for a slot when they are transmitting the last blob for a slot.
+   * `is_rooted` - True iff every block from 0...slot forms a full sequence without any holes. We can derive is\_rooted 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\_rooted\(n\) be the statement that "the slot\(n\).is\_rooted is true". Then:
+
+     is\_rooted\(0\) is\_rooted\(n+1\) iff \(is\_rooted\(n\) and slot\(n\).is\_full\(\)
+3. Chaining - When a blob for a new slot `x` arrives, we check the number of blocks \(`num_blocks`\) for that new slot \(this information is encoded in the blob\). 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`.
+
+## Blocktree 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`.
+
+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.
+
+## 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 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.
+
+## Pruning Blocktree
+
+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.
+
+Replicator nodes will be responsible for storing really old ledger contents, and validators need only persist their bank periodically.
+