Specify version for solana-sdk-macro to enable crate.io publishing (#7616)

automerge

.mergify.yml

@@ -19,6 +19,22 @@ pull_request_rules:
       label:
         add:
           - automerge
+  - 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
   - name: v0.23 backport
     conditions:
       - base=master
@@ -27,27 +43,3 @@ pull_request_rules:
       backport:
         branches:
           - v0.23
-  - name: v1.0 backport
-    conditions:
-      - base=master
-      - label=v1.0
-    actions:
-      backport:
-        branches:
-          - v1.0
-  - name: v1.1 backport
-    conditions:
-      - base=master
-      - label=v1.1
-    actions:
-      backport:
-        branches:
-          - v1.1
-  - name: v1.2 backport
-    conditions:
-      - base=master
-      - label=v1.2
-    actions:
-      backport:
-        branches:
-          - v1.2

Cargo.toml

@@ -4,10 +4,7 @@ members = [
     "bench-streamer",
     "bench-tps",
     "banking-bench",
-    "chacha",
-    "chacha-cuda",
     "chacha-sys",
-    "cli-config",
     "client",
     "core",
     "faucet",
@@ -41,9 +38,6 @@ members = [
     "programs/vest",
     "programs/vote",
     "archiver",
-    "archiver-lib",
-    "archiver-utils",
-    "remote-wallet",
     "runtime",
     "sdk",
     "sdk-c",
@@ -51,6 +45,7 @@ members = [
     "sys-tuner",
     "upload-perf",
     "net-utils",
+    "fixed-buf",
     "vote-signer",
     "cli",
     "rayon-threadlimit",

README.md

@@ -87,8 +87,7 @@ $ rustup update
 On Linux systems you may need to install libssl-dev, pkg-config, zlib1g-dev, etc.  On Ubuntu:
 
 ```bash
-$ sudo apt-get update
-$ sudo apt-get install libssl-dev libudev-dev pkg-config zlib1g-dev llvm clang
+$ sudo apt-get install libssl-dev pkg-config zlib1g-dev llvm clang
 ```
 
 Download the source code:
@@ -121,13 +120,16 @@ $ cargo test
 Local Testnet
 ---
 
-Start your own testnet locally, instructions are in the book [Solana: Blockchain Rebuild for Scale: Getting Started](https://docs.solana.com/book/building-from-source).
+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
 ---
 
-* `testnet` - public stable testnet accessible via devnet.solana.com. Runs 24/7
+We maintain several testnets:
 
+* `testnet` - public stable testnet accessible via testnet.solana.com. Runs 24/7
+* `testnet-beta` - public beta channel testnet accessible via beta.testnet.solana.com. Runs 24/7
+* `testnet-edge` - public edge channel testnet accessible via edge.testnet.solana.com. Runs 24/7
 
 ## Deploy process
 

RELEASE.md

@@ -140,9 +140,28 @@ TODO: Documentation update procedure is WIP as we move to gitbook
 
 Document the new recommended version by updating `book/src/running-archiver.md` and `book/src/validator-testnet.md` on the release (beta) branch to point at the `solana-install` for the upcoming release version.
 
-### Update software on devnet.solana.com
+#### Publish updated Book
+We maintain three copies of the "book" as official documentation:
 
-The testnet running on devnet.solana.com is set to use a fixed release tag
+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:
+https://solana-labs.github.io/book/
+
+2) "Book-edge" tracks the tip of the master branch and updates automatically.
+https://solana-labs.github.io/book-edge/
+
+3) "Book-beta" tracks the tip of the beta branch and updates automatically.
+https://solana-labs.github.io/book-beta/
+
+To manually trigger an update of the "Book", create a new job of the manual-update-book pipeline.
+Set the tag of the latest release as the PUBLISH_BOOK_TAG environment variable.
+```bash
+PUBLISH_BOOK_TAG=v0.16.6
+```
+https://buildkite.com/solana-labs/manual-update-book
+
+### Update software on testnet.solana.com
+
+The testnet running on testnet.solana.com is set to use a fixed release tag
 which is set in the Buildkite testnet-management pipeline.
 This tag needs to be updated and the testnet restarted after a new release
 tag is created.
@@ -182,4 +201,4 @@ TESTNET_OP=create-and-start
 ### Alert the community
 
 Notify Discord users on #validator-support that a new release for
-devnet.solana.com is available
+testnet.solana.com is available

archiver-lib/Cargo.toml

@@ -1,39 +0,0 @@
-[package]
-name = "solana-archiver-lib"
-version = "1.0.0"
-description = "Solana Archiver Library"
-authors = ["Solana Maintainers <maintainers@solana.com>"]
-repository = "https://github.com/solana-labs/solana"
-license = "Apache-2.0"
-homepage = "https://solana.com/"
-edition = "2018"
-
-[dependencies]
-bincode = "1.2.1"
-crossbeam-channel = "0.3"
-ed25519-dalek = "=1.0.0-pre.1"
-log = "0.4.8"
-rand = "0.6.5"
-rand_chacha = "0.1.1"
-solana-client = { path = "../client", version = "1.0.0" }
-solana-storage-program = { path = "../programs/storage", version = "1.0.0" }
-thiserror = "1.0"
-serde = "1.0.104"
-serde_json = "1.0.46"
-serde_derive = "1.0.103"
-solana-net-utils = { path = "../net-utils", version = "1.0.0" }
-solana-chacha = { path = "../chacha", version = "1.0.0" }
-solana-chacha-sys = { path = "../chacha-sys", version = "1.0.0" }
-solana-ledger = { path = "../ledger", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-perf = { path = "../perf", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
-solana-core = { path = "../core", version = "1.0.0" }
-solana-archiver-utils = { path = "../archiver-utils", version = "1.0.0" }
-solana-metrics = { path = "../metrics", version = "1.0.0" }
-
-[dev-dependencies]
-hex = "0.4.0"
-
-[lib]
-name = "solana_archiver_lib"

archiver-lib/src/lib.rs

@@ -1,11 +0,0 @@
-#[macro_use]
-extern crate log;
-
-#[macro_use]
-extern crate serde_derive;
-
-#[macro_use]
-extern crate solana_metrics;
-
-pub mod archiver;
-mod result;

archiver-lib/src/result.rs

@@ -1,48 +0,0 @@
-use serde_json;
-use solana_client::client_error;
-use solana_ledger::blockstore;
-use solana_sdk::transport;
-use std::any::Any;
-use thiserror::Error;
-
-#[derive(Error, Debug)]
-pub enum ArchiverError {
-    #[error("IO error")]
-    IO(#[from] std::io::Error),
-
-    #[error("blockstore error")]
-    BlockstoreError(#[from] blockstore::BlockstoreError),
-
-    #[error("crossbeam error")]
-    CrossbeamSendError(#[from] crossbeam_channel::SendError<u64>),
-
-    #[error("send error")]
-    SendError(#[from] std::sync::mpsc::SendError<u64>),
-
-    #[error("join error")]
-    JoinError(Box<dyn Any + Send + 'static>),
-
-    #[error("transport error")]
-    TransportError(#[from] transport::TransportError),
-
-    #[error("client error")]
-    ClientError(#[from] client_error::ClientError),
-
-    #[error("Json parsing error")]
-    JsonError(#[from] serde_json::error::Error),
-
-    #[error("Storage account has no balance")]
-    EmptyStorageAccountBalance,
-
-    #[error("No RPC peers..")]
-    NoRpcPeers,
-
-    #[error("Couldn't download full segment")]
-    SegmentDownloadError,
-}
-
-impl std::convert::From<Box<dyn Any + Send + 'static>> for ArchiverError {
-    fn from(e: Box<dyn Any + Send + 'static>) -> ArchiverError {
-        ArchiverError::JoinError(e)
-    }
-}

archiver-utils/Cargo.toml

@@ -1,25 +0,0 @@
-[package]
-name = "solana-archiver-utils"
-version = "1.0.0"
-description = "Solana Archiver Utils"
-authors = ["Solana Maintainers <maintainers@solana.com>"]
-repository = "https://github.com/solana-labs/solana"
-license = "Apache-2.0"
-homepage = "https://solana.com/"
-edition = "2018"
-
-[dependencies]
-log = "0.4.8"
-rand = "0.6.5"
-solana-chacha = { path = "../chacha", version = "1.0.0" }
-solana-chacha-sys = { path = "../chacha-sys", version = "1.0.0" }
-solana-ledger = { path = "../ledger", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-perf = { path = "../perf", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
-
-[dev-dependencies]
-hex = "0.4.0"
-
-[lib]
-name = "solana_archiver_utils"

archiver-utils/src/lib.rs

@@ -1,120 +0,0 @@
-#[macro_use]
-extern crate log;
-
-use solana_sdk::hash::{Hash, Hasher};
-use std::fs::File;
-use std::io::{self, BufReader, ErrorKind, Read, Seek, SeekFrom};
-use std::mem::size_of;
-use std::path::Path;
-
-pub fn sample_file(in_path: &Path, sample_offsets: &[u64]) -> io::Result<Hash> {
-    let in_file = File::open(in_path)?;
-    let metadata = in_file.metadata()?;
-    let mut buffer_file = BufReader::new(in_file);
-
-    let mut hasher = Hasher::default();
-    let sample_size = size_of::<Hash>();
-    let sample_size64 = sample_size as u64;
-    let mut buf = vec![0; sample_size];
-
-    let file_len = metadata.len();
-    if file_len < sample_size64 {
-        return Err(io::Error::new(ErrorKind::Other, "file too short!"));
-    }
-    for offset in sample_offsets {
-        if *offset > (file_len - sample_size64) / sample_size64 {
-            return Err(io::Error::new(ErrorKind::Other, "offset too large"));
-        }
-        buffer_file.seek(SeekFrom::Start(*offset * sample_size64))?;
-        trace!("sampling @ {} ", *offset);
-        match buffer_file.read(&mut buf) {
-            Ok(size) => {
-                assert_eq!(size, buf.len());
-                hasher.hash(&buf);
-            }
-            Err(e) => {
-                warn!("Error sampling file");
-                return Err(e);
-            }
-        }
-    }
-
-    Ok(hasher.result())
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-    use rand::{thread_rng, Rng};
-    use std::fs::{create_dir_all, remove_file};
-    use std::io::Write;
-    use std::path::PathBuf;
-
-    extern crate hex;
-
-    fn tmp_file_path(name: &str) -> PathBuf {
-        use std::env;
-        let out_dir = env::var("FARF_DIR").unwrap_or_else(|_| "farf".to_string());
-        let mut rand_bits = [0u8; 32];
-        thread_rng().fill(&mut rand_bits[..]);
-
-        let mut path = PathBuf::new();
-        path.push(out_dir);
-        path.push("tmp");
-        create_dir_all(&path).unwrap();
-
-        path.push(format!("{}-{:?}", name, hex::encode(rand_bits)));
-        println!("path: {:?}", path);
-        path
-    }
-
-    #[test]
-    fn test_sample_file() {
-        solana_logger::setup();
-        let in_path = tmp_file_path("test_sample_file_input.txt");
-        let num_strings = 4096;
-        let string = "12foobar";
-        {
-            let mut in_file = File::create(&in_path).unwrap();
-            for _ in 0..num_strings {
-                in_file.write(string.as_bytes()).unwrap();
-            }
-        }
-        let num_samples = (string.len() * num_strings / size_of::<Hash>()) as u64;
-        let samples: Vec<_> = (0..num_samples).collect();
-        let res = sample_file(&in_path, samples.as_slice());
-        let ref_hash: Hash = Hash::new(&[
-            173, 251, 182, 165, 10, 54, 33, 150, 133, 226, 106, 150, 99, 192, 179, 1, 230, 144,
-            151, 126, 18, 191, 54, 67, 249, 140, 230, 160, 56, 30, 170, 52,
-        ]);
-        let res = res.unwrap();
-        assert_eq!(res, ref_hash);
-
-        // Sample just past the end
-        assert!(sample_file(&in_path, &[num_samples]).is_err());
-        remove_file(&in_path).unwrap();
-    }
-
-    #[test]
-    fn test_sample_file_invalid_offset() {
-        let in_path = tmp_file_path("test_sample_file_invalid_offset_input.txt");
-        {
-            let mut in_file = File::create(&in_path).unwrap();
-            for _ in 0..4096 {
-                in_file.write("123456foobar".as_bytes()).unwrap();
-            }
-        }
-        let samples = [0, 200000];
-        let res = sample_file(&in_path, &samples);
-        assert!(res.is_err());
-        remove_file(in_path).unwrap();
-    }
-
-    #[test]
-    fn test_sample_file_missing_file() {
-        let in_path = tmp_file_path("test_sample_file_that_doesnt_exist.txt");
-        let samples = [0, 5];
-        let res = sample_file(&in_path, &samples);
-        assert!(res.is_err());
-    }
-}

archiver/Cargo.toml

@@ -2,19 +2,18 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-archiver"
-version = "1.0.0"
+version = "0.22.0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
 
 [dependencies]
 clap = "2.33.0"
-console = "0.9.2"
-solana-clap-utils = { path = "../clap-utils", version = "1.0.0" }
-solana-core = { path = "../core", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-metrics = { path = "../metrics", version = "1.0.0" }
-solana-archiver-lib = { path = "../archiver-lib", version = "1.0.0" }
-solana-net-utils = { path = "../net-utils", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
+console = "0.9.1"
+solana-clap-utils = { path = "../clap-utils", version = "0.22.0" }
+solana-core = { path = "../core", version = "0.22.0" }
+solana-logger = { path = "../logger", version = "0.22.0" }
+solana-metrics = { path = "../metrics", version = "0.22.0" }
+solana-net-utils = { path = "../net-utils", version = "0.22.0" }
+solana-sdk = { path = "../sdk", version = "0.22.0" }
 

archiver/src/main.rs

@@ -1,6 +1,5 @@
 use clap::{crate_description, crate_name, App, Arg};
 use console::style;
-use solana_archiver_lib::archiver::Archiver;
 use solana_clap_utils::{
     input_validators::is_keypair,
     keypair::{
@@ -9,10 +8,11 @@ use solana_clap_utils::{
     },
 };
 use solana_core::{
+    archiver::Archiver,
     cluster_info::{Node, VALIDATOR_PORT_RANGE},
     contact_info::ContactInfo,
 };
-use solana_sdk::{commitment_config::CommitmentConfig, signature::Signer};
+use solana_sdk::{commitment_config::CommitmentConfig, signature::KeypairUtil};
 use std::{net::SocketAddr, path::PathBuf, process::exit, sync::Arc};
 
 fn main() {

banking-bench/Cargo.toml

@@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-banking-bench"
-version = "1.0.0"
+version = "0.22.0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
@@ -10,11 +10,11 @@ homepage = "https://solana.com/"
 [dependencies]
 log = "0.4.6"
 rayon = "1.2.0"
-solana-core = { path = "../core", version = "1.0.0" }
-solana-ledger = { path = "../ledger", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-runtime = { path = "../runtime", version = "1.0.0" }
-solana-measure = { path = "../measure", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
+solana-core = { path = "../core", version = "0.22.0" }
+solana-ledger = { path = "../ledger", version = "0.22.0" }
+solana-logger = { path = "../logger", version = "0.22.0" }
+solana-runtime = { path = "../runtime", version = "0.22.0" }
+solana-measure = { path = "../measure", version = "0.22.0" }
+solana-sdk = { path = "../sdk", version = "0.22.0" }
 rand = "0.6.5"
 crossbeam-channel = "0.3"

banking-bench/src/main.rs

@@ -10,7 +10,7 @@ use solana_core::packet::to_packets_chunked;
 use solana_core::poh_recorder::PohRecorder;
 use solana_core::poh_recorder::WorkingBankEntry;
 use solana_ledger::bank_forks::BankForks;
-use solana_ledger::{blockstore::Blockstore, get_tmp_ledger_path};
+use solana_ledger::{blocktree::Blocktree, get_tmp_ledger_path};
 use solana_measure::measure::Measure;
 use solana_runtime::bank::Bank;
 use solana_sdk::hash::Hash;
@@ -139,11 +139,11 @@ fn main() {
     let mut verified: Vec<_> = to_packets_chunked(&transactions.clone(), PACKETS_PER_BATCH);
     let ledger_path = get_tmp_ledger_path!();
     {
-        let blockstore = Arc::new(
-            Blockstore::open(&ledger_path).expect("Expected to be able to open database ledger"),
+        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, &blockstore, None);
+            create_test_recorder(&bank, &blocktree, None);
         let cluster_info = ClusterInfo::new_with_invalid_keypair(Node::new_localhost().info);
         let cluster_info = Arc::new(RwLock::new(cluster_info));
         let banking_stage = BankingStage::new(
@@ -162,8 +162,8 @@ fn main() {
         // 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 mut total_us = 0;
-        let mut tx_total_us = 0;
+        let mut total = 0;
+        let mut tx_total = 0;
         let mut txs_processed = 0;
         let mut root = 1;
         let collector = Pubkey::new_rand();
@@ -173,7 +173,6 @@ fn main() {
             chunk_len,
             num_threads,
         };
-        let mut total_sent = 0;
         for _ in 0..ITERS {
             let now = Instant::now();
             let mut sent = 0;
@@ -224,7 +223,7 @@ fn main() {
                 );
                 assert!(txs_processed < bank.transaction_count());
                 txs_processed = bank.transaction_count();
-                tx_total_us += duration_as_us(&now.elapsed());
+                tx_total += duration_as_us(&now.elapsed());
 
                 let mut poh_time = Measure::start("poh_time");
                 poh_recorder.lock().unwrap().reset(
@@ -256,21 +255,20 @@ fn main() {
                     poh_time.as_us(),
                 );
             } else {
-                tx_total_us += duration_as_us(&now.elapsed());
+                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_us += duration_as_us(&now.elapsed());
+            total += duration_as_us(&now.elapsed());
             debug!(
                 "time: {} us checked: {} sent: {}",
                 duration_as_us(&now.elapsed()),
                 txes / CHUNKS,
                 sent,
             );
-            total_sent += sent;
 
             if bank.slot() > 0 && bank.slot() % 16 == 0 {
                 for tx in transactions.iter_mut() {
@@ -286,11 +284,11 @@ fn main() {
         }
         eprintln!(
             "{{'name': 'banking_bench_total', 'median': '{}'}}",
-            (1000.0 * 1000.0 * total_sent as f64) / (total_us as f64),
+            total / ITERS as u64,
         );
         eprintln!(
             "{{'name': 'banking_bench_tx_total', 'median': '{}'}}",
-            (1000.0 * 1000.0 * total_sent as f64) / (tx_total_us as f64),
+            tx_total / ITERS as u64,
         );
 
         drop(verified_sender);
@@ -302,5 +300,5 @@ fn main() {
         sleep(Duration::from_secs(1));
         debug!("waited for poh_service");
     }
-    let _unused = Blockstore::destroy(&ledger_path);
+    let _unused = Blocktree::destroy(&ledger_path);
 }

bench-exchange/Cargo.toml

@@ -2,33 +2,40 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-exchange"
-version = "1.0.0"
+version = "0.22.0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
 publish = false
 
 [dependencies]
+bincode = "1.2.1"
+bs58 = "0.3.0"
 clap = "2.32.0"
+env_logger = "0.7.1"
 itertools = "0.8.2"
 log = "0.4.8"
 num-derive = "0.3"
 num-traits = "0.2"
 rand = "0.6.5"
 rayon = "1.2.0"
-serde_json = "1.0.46"
+serde = "1.0.104"
+serde_derive = "1.0.103"
+serde_json = "1.0.44"
 serde_yaml = "0.8.11"
-solana-clap-utils = { path = "../clap-utils", version = "1.0.0" }
-solana-core = { path = "../core", version = "1.0.0" }
-solana-genesis = { path = "../genesis", version = "1.0.0" }
-solana-client = { path = "../client", version = "1.0.0" }
-solana-faucet = { path = "../faucet", version = "1.0.0" }
-solana-exchange-program = { path = "../programs/exchange", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-metrics = { path = "../metrics", version = "1.0.0" }
-solana-net-utils = { path = "../net-utils", version = "1.0.0" }
-solana-runtime = { path = "../runtime", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
+solana-clap-utils = { path = "../clap-utils", version = "0.22.0" }
+solana-core = { path = "../core", version = "0.22.0" }
+solana-genesis = { path = "../genesis", version = "0.22.0" }
+solana-client = { path = "../client", version = "0.22.0" }
+solana-faucet = { path = "../faucet", version = "0.22.0" }
+solana-exchange-program = { path = "../programs/exchange", version = "0.22.0" }
+solana-logger = { path = "../logger", version = "0.22.0" }
+solana-metrics = { path = "../metrics", version = "0.22.0" }
+solana-net-utils = { path = "../net-utils", version = "0.22.0" }
+solana-runtime = { path = "../runtime", version = "0.22.0" }
+solana-sdk = { path = "../sdk", version = "0.22.0" }
+untrusted = "0.7.0"
+ws = "0.9.1"
 
 [dev-dependencies]
-solana-local-cluster = { path = "../local-cluster", version = "1.0.0" }
+solana-local-cluster = { path = "../local-cluster", version = "0.22.0" }

bench-exchange/src/bench.rs

@@ -15,7 +15,7 @@ use solana_sdk::{
     client::{Client, SyncClient},
     commitment_config::CommitmentConfig,
     pubkey::Pubkey,
-    signature::{Keypair, Signer},
+    signature::{Keypair, KeypairUtil},
     timing::{duration_as_ms, duration_as_s},
     transaction::Transaction,
     {system_instruction, system_program},
@@ -701,7 +701,7 @@ fn verify_funding_transfer<T: SyncClient + ?Sized>(
     false
 }
 
-pub fn fund_keys<T: Client>(client: &T, 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();
@@ -824,11 +824,7 @@ pub fn fund_keys<T: Client>(client: &T, source: &Keypair, dests: &[Arc<Keypair>]
     }
 }
 
-pub fn create_token_accounts<T: Client>(
-    client: &T,
-    signers: &[Arc<Keypair>],
-    accounts: &[Keypair],
-) {
+pub fn create_token_accounts(client: &dyn Client, signers: &[Arc<Keypair>], accounts: &[Keypair]) {
     let mut notfunded: Vec<(&Arc<Keypair>, &Keypair)> = signers.iter().zip(accounts).collect();
 
     while !notfunded.is_empty() {
@@ -972,12 +968,7 @@ fn generate_keypairs(num: u64) -> Vec<Keypair> {
     rnd.gen_n_keypairs(num)
 }
 
-pub fn airdrop_lamports<T: Client>(
-    client: &T,
-    faucet_addr: &SocketAddr,
-    id: &Keypair,
-    amount: u64,
-) {
+pub fn airdrop_lamports(client: &dyn Client, faucet_addr: &SocketAddr, id: &Keypair, amount: u64) {
     let balance = client.get_balance_with_commitment(&id.pubkey(), CommitmentConfig::recent());
     let balance = balance.unwrap_or(0);
     if balance >= amount {

bench-exchange/src/cli.rs

@@ -1,7 +1,7 @@
 use clap::{crate_description, crate_name, value_t, App, Arg, ArgMatches};
 use solana_core::gen_keys::GenKeys;
 use solana_faucet::faucet::FAUCET_PORT;
-use solana_sdk::signature::{read_keypair_file, Keypair};
+use solana_sdk::signature::{read_keypair_file, Keypair, KeypairUtil};
 use std::net::SocketAddr;
 use std::process::exit;
 use std::time::Duration;

bench-exchange/src/main.rs

@@ -5,7 +5,7 @@ pub mod order_book;
 use crate::bench::{airdrop_lamports, create_client_accounts_file, do_bench_exchange, Config};
 use log::*;
 use solana_core::gossip_service::{discover_cluster, get_multi_client};
-use solana_sdk::signature::Signer;
+use solana_sdk::signature::KeypairUtil;
 
 fn main() {
     solana_logger::setup();

bench-exchange/tests/bench_exchange.rs

@@ -10,13 +10,12 @@ use solana_local_cluster::local_cluster::{ClusterConfig, LocalCluster};
 use solana_runtime::bank::Bank;
 use solana_runtime::bank_client::BankClient;
 use solana_sdk::genesis_config::create_genesis_config;
-use solana_sdk::signature::{Keypair, Signer};
+use solana_sdk::signature::{Keypair, KeypairUtil};
 use std::process::exit;
 use std::sync::mpsc::channel;
 use std::time::Duration;
 
 #[test]
-#[ignore]
 fn test_exchange_local_cluster() {
     solana_logger::setup();
 

bench-streamer/Cargo.toml

@@ -2,14 +2,14 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-streamer"
-version = "1.0.0"
+version = "0.22.0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
 
 [dependencies]
 clap = "2.33.0"
-solana-clap-utils = { path = "../clap-utils", version = "1.0.0" }
-solana-core = { path = "../core", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-net-utils = { path = "../net-utils", version = "1.0.0" }
+solana-clap-utils = { path = "../clap-utils", version = "0.22.0" }
+solana-core = { path = "../core", version = "0.22.0" }
+solana-logger = { path = "../logger", version = "0.22.0" }
+solana-net-utils = { path = "../net-utils", version = "0.22.0" }

bench-streamer/src/main.rs

@@ -1,5 +1,6 @@
 use clap::{crate_description, crate_name, App, Arg};
 use solana_core::packet::{Packet, Packets, PacketsRecycler, 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};
@@ -7,7 +8,7 @@ use std::sync::atomic::{AtomicBool, AtomicUsize, Ordering};
 use std::sync::mpsc::channel;
 use std::sync::Arc;
 use std::thread::sleep;
-use std::thread::{spawn, JoinHandle, Result};
+use std::thread::{spawn, JoinHandle};
 use std::time::Duration;
 use std::time::SystemTime;
 

bench-tps/Cargo.toml

@@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-tps"
-version = "1.0.0"
+version = "0.22.0"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
@@ -12,26 +12,28 @@ bincode = "1.2.1"
 clap = "2.33.0"
 log = "0.4.8"
 rayon = "1.2.0"
-serde_json = "1.0.46"
+serde = "1.0.104"
+serde_derive = "1.0.103"
+serde_json = "1.0.44"
 serde_yaml = "0.8.11"
-solana-clap-utils = { path = "../clap-utils", version = "1.0.0" }
-solana-core = { path = "../core", version = "1.0.0" }
-solana-genesis = { path = "../genesis", version = "1.0.0" }
-solana-client = { path = "../client", version = "1.0.0" }
-solana-faucet = { path = "../faucet", version = "1.0.0" }
-solana-librapay = { path = "../programs/librapay", version = "1.0.0", optional = true }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-metrics = { path = "../metrics", version = "1.0.0" }
-solana-measure = { path = "../measure", version = "1.0.0" }
-solana-net-utils = { path = "../net-utils", version = "1.0.0" }
-solana-runtime = { path = "../runtime", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
-solana-move-loader-program = { path = "../programs/move_loader", version = "1.0.0", optional = true }
+solana-clap-utils = { path = "../clap-utils", version = "0.22.0" }
+solana-core = { path = "../core", version = "0.22.0" }
+solana-genesis = { path = "../genesis", version = "0.22.0" }
+solana-client = { path = "../client", version = "0.22.0" }
+solana-faucet = { path = "../faucet", version = "0.22.0" }
+solana-librapay = { path = "../programs/librapay", version = "0.22.0", optional = true }
+solana-logger = { path = "../logger", version = "0.22.0" }
+solana-metrics = { path = "../metrics", version = "0.22.0" }
+solana-measure = { path = "../measure", version = "0.22.0" }
+solana-net-utils = { path = "../net-utils", version = "0.22.0" }
+solana-runtime = { path = "../runtime", version = "0.22.0" }
+solana-sdk = { path = "../sdk", version = "0.22.0" }
+solana-move-loader-program = { path = "../programs/move_loader", version = "0.22.0", optional = true }
 
 [dev-dependencies]
 serial_test = "0.3.2"
-serial_test_derive = "0.4.0"
-solana-local-cluster = { path = "../local-cluster", version = "1.0.0" }
+serial_test_derive = "0.3.1"
+solana-local-cluster = { path = "../local-cluster", version = "0.22.0" }
 
 [features]
 move = ["solana-librapay", "solana-move-loader-program"]

bench-tps/src/bench.rs

@@ -7,7 +7,7 @@ use solana_faucet::faucet::request_airdrop_transaction;
 #[cfg(feature = "move")]
 use solana_librapay::{create_genesis, upload_mint_script, upload_payment_script};
 use solana_measure::measure::Measure;
-use solana_metrics::{self, datapoint_info};
+use solana_metrics::{self, datapoint_debug};
 use solana_sdk::{
     client::Client,
     clock::{DEFAULT_TICKS_PER_SECOND, DEFAULT_TICKS_PER_SLOT, MAX_PROCESSING_AGE},
@@ -15,13 +15,14 @@ use solana_sdk::{
     fee_calculator::FeeCalculator,
     hash::Hash,
     pubkey::Pubkey,
-    signature::{Keypair, Signer},
+    signature::{Keypair, KeypairUtil},
     system_instruction, system_transaction,
     timing::{duration_as_ms, duration_as_s, duration_as_us, timestamp},
     transaction::Transaction,
 };
 use std::{
-    collections::{HashSet, VecDeque},
+    cmp,
+    collections::VecDeque,
     net::SocketAddr,
     process::exit,
     sync::{
@@ -65,9 +66,10 @@ fn get_recent_blockhash<T: Client>(client: &T) -> (Hash, FeeCalculator) {
 }
 
 pub fn do_bench_tps<T>(
-    client: Arc<T>,
+    clients: Vec<T>,
     config: Config,
     gen_keypairs: Vec<Keypair>,
+    keypair0_balance: u64,
     libra_args: Option<LibraKeys>,
 ) -> u64
 where
@@ -80,9 +82,13 @@ where
         duration,
         tx_count,
         sustained,
+        num_lamports_per_account,
         ..
     } = config;
 
+    let clients: Vec<_> = clients.into_iter().map(Arc::new).collect();
+    let client = &clients[0];
+
     let mut source_keypair_chunks: Vec<Vec<&Keypair>> = Vec::new();
     let mut dest_keypair_chunks: Vec<VecDeque<&Keypair>> = Vec::new();
     assert!(gen_keypairs.len() >= 2 * tx_count);
@@ -109,17 +115,20 @@ where
     let maxes = Arc::new(RwLock::new(Vec::new()));
     let sample_period = 1; // in seconds
     info!("Sampling TPS every {} second...", sample_period);
-    let sample_thread = {
-        let exit_signal = exit_signal.clone();
-        let maxes = maxes.clone();
-        let client = client.clone();
-        Builder::new()
-            .name("solana-client-sample".to_string())
-            .spawn(move || {
-                sample_txs(&exit_signal, &maxes, sample_period, &client);
-            })
-            .unwrap()
-    };
+    let v_threads: Vec<_> = clients
+        .iter()
+        .map(|client| {
+            let exit_signal = exit_signal.clone();
+            let maxes = maxes.clone();
+            let client = client.clone();
+            Builder::new()
+                .name("solana-client-sample".to_string())
+                .spawn(move || {
+                    sample_txs(&exit_signal, &maxes, sample_period, &client);
+                })
+                .unwrap()
+        })
+        .collect();
 
     let shared_txs: SharedTransactions = Arc::new(RwLock::new(VecDeque::new()));
 
@@ -165,10 +174,11 @@ where
 
     // generate and send transactions for the specified duration
     let start = Instant::now();
-    let keypair_chunks = source_keypair_chunks.len();
+    let keypair_chunks = source_keypair_chunks.len() as u64;
     let mut reclaim_lamports_back_to_source_account = false;
-    let mut chunk_index = 0;
+    let mut i = keypair0_balance;
     while start.elapsed() < duration {
+        let chunk_index = (i % keypair_chunks) as usize;
         generate_txs(
             &shared_txs,
             &recent_blockhash,
@@ -187,9 +197,7 @@ where
                 sleep(Duration::from_millis(1));
             }
         } else {
-            while !shared_txs.read().unwrap().is_empty()
-                || shared_tx_active_thread_count.load(Ordering::Relaxed) > 0
-            {
+            while shared_tx_active_thread_count.load(Ordering::Relaxed) > 0 {
                 sleep(Duration::from_millis(1));
             }
         }
@@ -198,11 +206,8 @@ where
         // transaction signatures even when blockhash is reused.
         dest_keypair_chunks[chunk_index].rotate_left(1);
 
-        // Move on to next chunk
-        chunk_index = (chunk_index + 1) % keypair_chunks;
-
-        // Switch directions after transfering for each "chunk"
-        if chunk_index == 0 {
+        i += 1;
+        if should_switch_directions(num_lamports_per_account, keypair_chunks, i) {
             reclaim_lamports_back_to_source_account = !reclaim_lamports_back_to_source_account;
         }
     }
@@ -210,9 +215,11 @@ where
     // Stop the sampling threads so it will collect the stats
     exit_signal.store(true, Ordering::Relaxed);
 
-    info!("Waiting for sampler threads...");
-    if let Err(err) = sample_thread.join() {
-        info!("  join() failed with: {:?}", err);
+    info!("Waiting for validator threads...");
+    for t in v_threads {
+        if let Err(err) = t.join() {
+            info!("  join() failed with: {:?}", err);
+        }
     }
 
     // join the tx send threads
@@ -244,7 +251,7 @@ where
 
 fn metrics_submit_lamport_balance(lamport_balance: u64) {
     info!("Token balance: {}", lamport_balance);
-    datapoint_info!(
+    datapoint_debug!(
         "bench-tps-lamport_balance",
         ("balance", lamport_balance, i64)
     );
@@ -375,7 +382,7 @@ fn generate_txs(
         duration_as_ms(&duration),
         blockhash,
     );
-    datapoint_info!(
+    datapoint_debug!(
         "bench-tps-generate_txs",
         ("duration", duration_as_us(&duration), i64)
     );
@@ -481,7 +488,7 @@ fn do_tx_transfers<T: Client>(
                 duration_as_ms(&transfer_start.elapsed()),
                 tx_len as f32 / duration_as_s(&transfer_start.elapsed()),
             );
-            datapoint_info!(
+            datapoint_debug!(
                 "bench-tps-do_tx_transfers",
                 ("duration", duration_as_us(&transfer_start.elapsed()), i64),
                 ("count", tx_len, i64)
@@ -493,218 +500,177 @@ fn do_tx_transfers<T: Client>(
     }
 }
 
-fn verify_funding_transfer<T: Client>(client: &Arc<T>, tx: &Transaction, amount: u64) -> bool {
+fn verify_funding_transfer<T: Client>(client: &T, tx: &Transaction, amount: u64) -> bool {
     for a in &tx.message().account_keys[1..] {
-        match client.get_balance_with_commitment(a, CommitmentConfig::recent()) {
-            Ok(balance) => return balance >= amount,
-            Err(err) => error!("failed to get balance {:?}", err),
+        if client
+            .get_balance_with_commitment(a, CommitmentConfig::recent())
+            .unwrap_or(0)
+            >= amount
+        {
+            return true;
         }
     }
     false
 }
 
-trait FundingTransactions<'a> {
-    fn fund<T: 'static + Client + Send + Sync>(
-        &mut self,
-        client: &Arc<T>,
-        to_fund: &[(&'a Keypair, Vec<(Pubkey, u64)>)],
-        to_lamports: u64,
-    );
-    fn make(&mut self, to_fund: &[(&'a Keypair, Vec<(Pubkey, u64)>)]);
-    fn sign(&mut self, blockhash: Hash);
-    fn send<T: Client>(&self, client: &Arc<T>);
-    fn verify<T: 'static + Client + Send + Sync>(&mut self, client: &Arc<T>, to_lamports: u64);
-}
-
-impl<'a> FundingTransactions<'a> for Vec<(&'a Keypair, Transaction)> {
-    fn fund<T: 'static + Client + Send + Sync>(
-        &mut self,
-        client: &Arc<T>,
-        to_fund: &[(&'a Keypair, Vec<(Pubkey, u64)>)],
-        to_lamports: u64,
-    ) {
-        self.make(to_fund);
-
-        let mut tries = 0;
-        while !self.is_empty() {
-            info!(
-                "{} {} each to {} accounts in {} txs",
-                if tries == 0 {
-                    "transferring"
-                } else {
-                    " retrying"
-                },
-                to_lamports,
-                self.len() * MAX_SPENDS_PER_TX as usize,
-                self.len(),
-            );
-
-            let (blockhash, _fee_calculator) = get_recent_blockhash(client.as_ref());
-
-            // re-sign retained to_fund_txes with updated blockhash
-            self.sign(blockhash);
-            self.send(&client);
-
-            // Sleep a few slots to allow transactions to process
-            sleep(Duration::from_secs(1));
-
-            self.verify(&client, to_lamports);
-
-            // retry anything that seems to have dropped through cracks
-            //  again since these txs are all or nothing, they're fine to
-            //  retry
-            tries += 1;
-        }
-        info!("transferred");
-    }
-
-    fn make(&mut self, to_fund: &[(&'a Keypair, Vec<(Pubkey, u64)>)]) {
-        let mut make_txs = Measure::start("make_txs");
-        let to_fund_txs: Vec<(&Keypair, Transaction)> = to_fund
-            .par_iter()
-            .map(|(k, t)| {
-                let tx = Transaction::new_unsigned_instructions(system_instruction::transfer_many(
-                    &k.pubkey(),
-                    &t,
-                ));
-                (*k, tx)
-            })
-            .collect();
-        make_txs.stop();
-        debug!(
-            "make {} unsigned txs: {}us",
-            to_fund_txs.len(),
-            make_txs.as_us()
-        );
-        self.extend(to_fund_txs);
-    }
-
-    fn sign(&mut self, blockhash: Hash) {
-        let mut sign_txs = Measure::start("sign_txs");
-        self.par_iter_mut().for_each(|(k, tx)| {
-            tx.sign(&[*k], blockhash);
-        });
-        sign_txs.stop();
-        debug!("sign {} txs: {}us", self.len(), sign_txs.as_us());
-    }
-
-    fn send<T: Client>(&self, client: &Arc<T>) {
-        let mut send_txs = Measure::start("send_txs");
-        self.iter().for_each(|(_, tx)| {
-            client.async_send_transaction(tx.clone()).expect("transfer");
-        });
-        send_txs.stop();
-        debug!("send {} txs: {}us", self.len(), send_txs.as_us());
-    }
-
-    fn verify<T: 'static + Client + Send + Sync>(&mut self, client: &Arc<T>, to_lamports: u64) {
-        let starting_txs = self.len();
-        let verified_txs = Arc::new(AtomicUsize::new(0));
-        let too_many_failures = Arc::new(AtomicBool::new(false));
-        let loops = if starting_txs < 1000 { 3 } else { 1 };
-        // Only loop multiple times for small (quick) transaction batches
-        for _ in 0..loops {
-            let failed_verify = Arc::new(AtomicUsize::new(0));
-            let client = client.clone();
-            let verified_txs = &verified_txs;
-            let failed_verify = &failed_verify;
-            let too_many_failures = &too_many_failures;
-            let verified_set: HashSet<Pubkey> = self
-                .par_iter()
-                .filter_map(move |(k, tx)| {
-                    if too_many_failures.load(Ordering::Relaxed) {
-                        return None;
-                    }
-
-                    let verified = if verify_funding_transfer(&client, &tx, to_lamports) {
-                        verified_txs.fetch_add(1, Ordering::Relaxed);
-                        Some(k.pubkey())
-                    } else {
-                        failed_verify.fetch_add(1, Ordering::Relaxed);
-                        None
-                    };
-
-                    let verified_txs = verified_txs.load(Ordering::Relaxed);
-                    let failed_verify = failed_verify.load(Ordering::Relaxed);
-                    let remaining_count = starting_txs.saturating_sub(verified_txs + failed_verify);
-                    if failed_verify > 100 && failed_verify > verified_txs {
-                        too_many_failures.store(true, Ordering::Relaxed);
-                        warn!(
-                            "Too many failed transfers... {} remaining, {} verified, {} failures",
-                            remaining_count, verified_txs, failed_verify
-                        );
-                    }
-                    if remaining_count % 100 == 0 {
-                        info!(
-                            "Verifying transfers... {} remaining, {} verified, {} failures",
-                            remaining_count, verified_txs, failed_verify
-                        );
-                    }
-
-                    verified
-                })
-                .collect();
-
-            self.retain(|(k, _)| !verified_set.contains(&k.pubkey()));
-            if self.is_empty() {
-                break;
-            }
-            info!("Looping verifications");
-
-            let verified_txs = verified_txs.load(Ordering::Relaxed);
-            let failed_verify = failed_verify.load(Ordering::Relaxed);
-            let remaining_count = starting_txs.saturating_sub(verified_txs + failed_verify);
-            info!(
-                "Verifying transfers... {} remaining, {} verified, {} failures",
-                remaining_count, verified_txs, failed_verify
-            );
-            sleep(Duration::from_millis(100));
-        }
-    }
-}
-
 /// fund the dests keys by spending all of the source keys into MAX_SPENDS_PER_TX
 /// on every iteration.  This allows us to replay the transfers because the source is either empty,
 /// or full
-pub fn fund_keys<T: 'static + Client + Send + Sync>(
-    client: Arc<T>,
+pub fn fund_keys<T: Client>(
+    client: &T,
     source: &Keypair,
     dests: &[Keypair],
     total: u64,
     max_fee: u64,
-    lamports_per_account: u64,
+    mut extra: u64,
 ) {
-    let mut funded: Vec<&Keypair> = vec![source];
-    let mut funded_funds = total;
-    let mut not_funded: Vec<&Keypair> = dests.iter().collect();
-    while !not_funded.is_empty() {
-        // Build to fund list and prepare funding sources for next iteration
-        let mut new_funded: Vec<&Keypair> = vec![];
-        let mut to_fund: Vec<(&Keypair, Vec<(Pubkey, u64)>)> = vec![];
-        let to_lamports = (funded_funds - lamports_per_account - max_fee) / MAX_SPENDS_PER_TX;
-        for f in funded {
-            let start = not_funded.len() - MAX_SPENDS_PER_TX as usize;
-            let dests: Vec<_> = not_funded.drain(start..).collect();
-            let spends: Vec<_> = dests.iter().map(|k| (k.pubkey(), to_lamports)).collect();
-            to_fund.push((f, spends));
-            new_funded.extend(dests.into_iter());
+    let mut funded: Vec<(&Keypair, u64)> = vec![(source, total)];
+    let mut notfunded: Vec<&Keypair> = dests.iter().collect();
+    let lamports_per_account = (total - (extra * max_fee)) / (notfunded.len() as u64 + 1);
+
+    info!(
+        "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![];
+        info!("creating from... {}", funded.len());
+        let mut build_to_fund = Measure::start("build_to_fund");
+        for f in &mut funded {
+            let max_units = cmp::min(notfunded.len() as u64, MAX_SPENDS_PER_TX);
+            if max_units == 0 {
+                break;
+            }
+            let start = notfunded.len() - max_units as usize;
+            let fees = if extra > 0 { max_fee } else { 0 };
+            let per_unit = (f.1 - lamports_per_account - fees) / max_units;
+            let moves: Vec<_> = notfunded[start..]
+                .iter()
+                .map(|k| (k.pubkey(), per_unit))
+                .collect();
+            notfunded[start..]
+                .iter()
+                .for_each(|k| new_funded.push((k, per_unit)));
+            notfunded.truncate(start);
+            if !moves.is_empty() {
+                to_fund.push((f.0, moves));
+            }
+            extra -= 1;
         }
+        build_to_fund.stop();
+        debug!("build to_fund vec: {}us", build_to_fund.as_us());
 
         // try to transfer a "few" at a time with recent blockhash
         //  assume 4MB network buffers, and 512 byte packets
         const FUND_CHUNK_LEN: usize = 4 * 1024 * 1024 / 512;
 
         to_fund.chunks(FUND_CHUNK_LEN).for_each(|chunk| {
-            Vec::<(&Keypair, Transaction)>::with_capacity(chunk.len()).fund(
-                &client,
-                chunk,
-                to_lamports,
-            );
-        });
+            let mut tries = 0;
 
-        info!("funded: {} left: {}", new_funded.len(), not_funded.len());
+            let mut make_txs = Measure::start("make_txs");
+            // this set of transactions just initializes us for bookkeeping
+            #[allow(clippy::clone_double_ref)] // sigh
+            let mut to_fund_txs: Vec<_> = chunk
+                .par_iter()
+                .map(|(k, m)| {
+                    let tx = Transaction::new_unsigned_instructions(
+                        system_instruction::transfer_many(&k.pubkey(), &m),
+                    );
+                    (k.clone(), tx)
+                })
+                .collect();
+            make_txs.stop();
+            debug!(
+                "make {} unsigned txs: {}us",
+                to_fund_txs.len(),
+                make_txs.as_us()
+            );
+
+            let amount = chunk[0].1[0].1;
+
+            while !to_fund_txs.is_empty() {
+                let receivers = to_fund_txs
+                    .iter()
+                    .fold(0, |len, (_, tx)| len + tx.message().instructions.len());
+
+                info!(
+                    "{} {} to {} in {} txs",
+                    if tries == 0 {
+                        "transferring"
+                    } else {
+                        " retrying"
+                    },
+                    amount,
+                    receivers,
+                    to_fund_txs.len(),
+                );
+
+                let (blockhash, _fee_calculator) = get_recent_blockhash(client);
+
+                // re-sign retained to_fund_txes with updated blockhash
+                let mut sign_txs = Measure::start("sign_txs");
+                to_fund_txs.par_iter_mut().for_each(|(k, tx)| {
+                    tx.sign(&[*k], blockhash);
+                });
+                sign_txs.stop();
+                debug!("sign {} txs: {}us", to_fund_txs.len(), sign_txs.as_us());
+
+                let mut send_txs = Measure::start("send_txs");
+                to_fund_txs.iter().for_each(|(_, tx)| {
+                    client.async_send_transaction(tx.clone()).expect("transfer");
+                });
+                send_txs.stop();
+                debug!("send {} txs: {}us", to_fund_txs.len(), send_txs.as_us());
+
+                let mut verify_txs = Measure::start("verify_txs");
+                let mut starting_txs = to_fund_txs.len();
+                let mut verified_txs = 0;
+                let mut failed_verify = 0;
+                // Only loop multiple times for small (quick) transaction batches
+                for _ in 0..(if starting_txs < 1000 { 3 } else { 1 }) {
+                    let mut timer = Instant::now();
+                    to_fund_txs.retain(|(_, tx)| {
+                        if timer.elapsed() >= Duration::from_secs(5) {
+                            if failed_verify > 0 {
+                                debug!("total txs failed verify: {}", failed_verify);
+                            }
+                            info!(
+                                "Verifying transfers... {} remaining",
+                                starting_txs - verified_txs
+                            );
+                            timer = Instant::now();
+                        }
+                        let verified = verify_funding_transfer(client, &tx, amount);
+                        if verified {
+                            verified_txs += 1;
+                        } else {
+                            failed_verify += 1;
+                        }
+                        !verified
+                    });
+                    if to_fund_txs.is_empty() {
+                        break;
+                    }
+                    debug!("Looping verifications");
+                    info!("Verifying transfers... {} remaining", to_fund_txs.len());
+                    sleep(Duration::from_millis(100));
+                }
+                starting_txs -= to_fund_txs.len();
+                verify_txs.stop();
+                debug!("verified {} txs: {}us", starting_txs, verify_txs.as_us());
+
+                // retry anything that seems to have dropped through cracks
+                //  again since these txs are all or nothing, they're fine to
+                //  retry
+                tries += 1;
+            }
+            info!("transferred");
+        });
+        info!("funded: {} left: {}", new_funded.len(), notfunded.len());
         funded = new_funded;
-        funded_funds = to_lamports;
     }
 }
 
@@ -712,14 +678,14 @@ pub fn airdrop_lamports<T: Client>(
     client: &T,
     faucet_addr: &SocketAddr,
     id: &Keypair,
-    desired_balance: u64,
+    tx_count: u64,
 ) -> Result<()> {
     let starting_balance = client.get_balance(&id.pubkey()).unwrap_or(0);
     metrics_submit_lamport_balance(starting_balance);
     info!("starting balance {}", starting_balance);
 
-    if starting_balance < desired_balance {
-        let airdrop_amount = desired_balance - starting_balance;
+    if starting_balance < tx_count {
+        let airdrop_amount = tx_count - starting_balance;
         info!(
             "Airdropping {:?} lamports from {} for {}",
             airdrop_amount,
@@ -844,6 +810,17 @@ fn compute_and_report_stats(
     );
 }
 
+// First transfer 2/3 of the lamports to the dest accounts
+// then ping-pong 1/3 of the lamports back to the other account
+// this leaves 1/3 lamport buffer in each account
+fn should_switch_directions(num_lamports_per_account: u64, keypair_chunks: u64, i: u64) -> bool {
+    if i < keypair_chunks * (2 * num_lamports_per_account) / 3 {
+        return false;
+    }
+
+    i % (keypair_chunks * num_lamports_per_account / 3) == 0
+}
+
 pub fn generate_keypairs(seed_keypair: &Keypair, count: u64) -> (Vec<Keypair>, u64) {
     let mut seed = [0u8; 32];
     seed.copy_from_slice(&seed_keypair.to_bytes()[..32]);
@@ -1027,25 +1004,23 @@ fn fund_move_keys<T: Client>(
     info!("done funding keys, took {} ms", funding_time.as_ms());
 }
 
-pub fn generate_and_fund_keypairs<T: 'static + Client + Send + Sync>(
-    client: Arc<T>,
+pub fn generate_and_fund_keypairs<T: Client>(
+    client: &T,
     faucet_addr: Option<SocketAddr>,
     funding_key: &Keypair,
     keypair_count: usize,
     lamports_per_account: u64,
     use_move: bool,
-) -> Result<(Vec<Keypair>, Option<LibraKeys>)> {
+) -> Result<(Vec<Keypair>, Option<LibraKeys>, u64)> {
     info!("Creating {} keypairs...", keypair_count);
     let (mut keypairs, extra) = generate_keypairs(funding_key, keypair_count as u64);
     info!("Get lamports...");
 
-    // Sample the first keypair, to prevent lamport loss on repeated solana-bench-tps executions
-    let first_key = keypairs[0].pubkey();
-    let first_keypair_balance = client.get_balance(&first_key).unwrap_or(0);
-
-    // Sample the last keypair, to check if funding was already completed
-    let last_key = keypairs[keypair_count - 1].pubkey();
-    let last_keypair_balance = client.get_balance(&last_key).unwrap_or(0);
+    // Sample the first keypair, see if it has lamports, if so then resume.
+    // This logic is to prevent lamport loss on repeated solana-bench-tps executions
+    let last_keypair_balance = client
+        .get_balance(&keypairs[keypair_count - 1].pubkey())
+        .unwrap_or(0);
 
     #[cfg(feature = "move")]
     let mut move_keypairs_ret = None;
@@ -1053,38 +1028,31 @@ pub fn generate_and_fund_keypairs<T: 'static + Client + Send + Sync>(
     #[cfg(not(feature = "move"))]
     let move_keypairs_ret = None;
 
-    // Repeated runs will eat up keypair balances from transaction fees. In order to quickly
-    //   start another bench-tps run without re-funding all of the keypairs, check if the
-    //   keypairs still have at least 80% of the expected funds. That should be enough to
-    //   pay for the transaction fees in a new run.
-    let enough_lamports = 8 * lamports_per_account / 10;
-    if first_keypair_balance < enough_lamports || last_keypair_balance < enough_lamports {
-        let (_blockhash, fee_calculator) = get_recent_blockhash(client.as_ref());
-        let max_fee = fee_calculator.max_lamports_per_signature;
-        let extra_fees = extra * max_fee;
-        let total_keypairs = keypairs.len() as u64 + 1; // Add one for funding keypair
-        let mut total = lamports_per_account * total_keypairs + extra_fees;
+    if lamports_per_account > last_keypair_balance {
+        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 mut total = account_desired_balance * (1 + keypairs.len() as u64) + extra_fees;
         if use_move {
             total *= 3;
         }
 
-        let funding_key_balance = client.get_balance(&funding_key.pubkey()).unwrap_or(0);
-        info!(
-            "Funding keypair balance: {} max_fee: {} lamports_per_account: {} extra: {} total: {}",
-            funding_key_balance, max_fee, lamports_per_account, extra, total
-        );
+        info!("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.as_ref(), &faucet_addr.unwrap(), funding_key, total)?;
+            airdrop_lamports(client, &faucet_addr.unwrap(), funding_key, total)?;
         }
 
         #[cfg(feature = "move")]
         {
             if use_move {
-                let libra_genesis_keypair =
-                    create_genesis(&funding_key, client.as_ref(), 10_000_000);
-                let libra_mint_program_id = upload_mint_script(&funding_key, client.as_ref());
-                let libra_pay_program_id = upload_payment_script(&funding_key, client.as_ref());
+                let libra_genesis_keypair = create_genesis(&funding_key, client, 10_000_000);
+                let libra_mint_program_id = upload_mint_script(&funding_key, client);
+                let libra_pay_program_id = upload_payment_script(&funding_key, client);
 
                 // Generate another set of keypairs for move accounts.
                 // Still fund the solana ones which will be used for fees.
@@ -1092,7 +1060,7 @@ pub fn generate_and_fund_keypairs<T: 'static + Client + Send + Sync>(
                 let mut rnd = GenKeys::new(seed);
                 let move_keypairs = rnd.gen_n_keypairs(keypair_count as u64);
                 fund_move_keys(
-                    client.as_ref(),
+                    client,
                     funding_key,
                     &move_keypairs,
                     total / 3,
@@ -1117,15 +1085,15 @@ pub fn generate_and_fund_keypairs<T: 'static + Client + Send + Sync>(
             funding_key,
             &keypairs,
             total,
-            max_fee,
-            lamports_per_account,
+            fee_calculator.max_lamports_per_signature,
+            extra,
         );
     }
 
     // 'generate_keypairs' generates extra keys to be able to have size-aligned funding batches for fund_keys.
     keypairs.truncate(keypair_count);
 
-    Ok((keypairs, move_keypairs_ret))
+    Ok((keypairs, move_keypairs_ret, last_keypair_balance))
 }
 
 #[cfg(test)]
@@ -1137,11 +1105,30 @@ mod tests {
     use solana_sdk::fee_calculator::FeeCalculator;
     use solana_sdk::genesis_config::create_genesis_config;
 
+    #[test]
+    fn test_switch_directions() {
+        assert_eq!(should_switch_directions(30, 1, 0), false);
+        assert_eq!(should_switch_directions(30, 1, 1), false);
+        assert_eq!(should_switch_directions(30, 1, 20), true);
+        assert_eq!(should_switch_directions(30, 1, 21), false);
+        assert_eq!(should_switch_directions(30, 1, 30), true);
+        assert_eq!(should_switch_directions(30, 1, 90), true);
+        assert_eq!(should_switch_directions(30, 1, 91), false);
+
+        assert_eq!(should_switch_directions(30, 2, 0), false);
+        assert_eq!(should_switch_directions(30, 2, 1), false);
+        assert_eq!(should_switch_directions(30, 2, 20), false);
+        assert_eq!(should_switch_directions(30, 2, 40), true);
+        assert_eq!(should_switch_directions(30, 2, 90), false);
+        assert_eq!(should_switch_directions(30, 2, 100), true);
+        assert_eq!(should_switch_directions(30, 2, 101), false);
+    }
+
     #[test]
     fn test_bench_tps_bank_client() {
         let (genesis_config, id) = create_genesis_config(10_000);
         let bank = Bank::new(&genesis_config);
-        let client = Arc::new(BankClient::new(bank));
+        let clients = vec![BankClient::new(bank)];
 
         let mut config = Config::default();
         config.id = id;
@@ -1149,24 +1136,23 @@ mod tests {
         config.duration = Duration::from_secs(5);
 
         let keypair_count = config.tx_count * config.keypair_multiplier;
-        let (keypairs, _move_keypairs) =
-            generate_and_fund_keypairs(client.clone(), None, &config.id, keypair_count, 20, false)
+        let (keypairs, _move_keypairs, _keypair_balance) =
+            generate_and_fund_keypairs(&clients[0], None, &config.id, keypair_count, 20, false)
                 .unwrap();
 
-        do_bench_tps(client, config, keypairs, None);
+        do_bench_tps(clients, config, keypairs, 0, None);
     }
 
     #[test]
     fn test_bench_tps_fund_keys() {
         let (genesis_config, id) = create_genesis_config(10_000);
         let bank = Bank::new(&genesis_config);
-        let client = Arc::new(BankClient::new(bank));
+        let client = BankClient::new(bank);
         let keypair_count = 20;
         let lamports = 20;
 
-        let (keypairs, _move_keypairs) =
-            generate_and_fund_keypairs(client.clone(), None, &id, keypair_count, lamports, false)
-                .unwrap();
+        let (keypairs, _move_keypairs, _keypair_balance) =
+            generate_and_fund_keypairs(&client, None, &id, keypair_count, lamports, false).unwrap();
 
         for kp in &keypairs {
             assert_eq!(
@@ -1184,16 +1170,23 @@ mod tests {
         let fee_calculator = FeeCalculator::new(11, 0);
         genesis_config.fee_calculator = fee_calculator;
         let bank = Bank::new(&genesis_config);
-        let client = Arc::new(BankClient::new(bank));
+        let client = BankClient::new(bank);
         let keypair_count = 20;
         let lamports = 20;
 
-        let (keypairs, _move_keypairs) =
-            generate_and_fund_keypairs(client.clone(), None, &id, keypair_count, lamports, false)
-                .unwrap();
+        let (keypairs, _move_keypairs, _keypair_balance) =
+            generate_and_fund_keypairs(&client, None, &id, keypair_count, lamports, false).unwrap();
 
+        let max_fee = client
+            .get_recent_blockhash_with_commitment(CommitmentConfig::recent())
+            .unwrap()
+            .1
+            .max_lamports_per_signature;
         for kp in &keypairs {
-            assert_eq!(client.get_balance(&kp.pubkey()).unwrap(), lamports);
+            assert_eq!(
+                client.get_balance(&kp.pubkey()).unwrap(),
+                lamports + max_fee
+            );
         }
     }
 }

bench-tps/src/cli.rs

@@ -1,10 +1,10 @@
 use clap::{crate_description, crate_name, App, Arg, ArgMatches};
 use solana_faucet::faucet::FAUCET_PORT;
 use solana_sdk::fee_calculator::FeeCalculator;
-use solana_sdk::signature::{read_keypair_file, Keypair};
+use solana_sdk::signature::{read_keypair_file, Keypair, KeypairUtil};
 use std::{net::SocketAddr, process::exit, time::Duration};
 
-const NUM_LAMPORTS_PER_ACCOUNT_DEFAULT: u64 = solana_sdk::native_token::LAMPORTS_PER_SOL;
+const NUM_LAMPORTS_PER_ACCOUNT_DEFAULT: u64 = solana_sdk::native_token::SOL_LAMPORTS;
 
 /// Holds the configuration for a single run of the benchmark
 pub struct Config {

bench-tps/src/main.rs

@@ -4,15 +4,15 @@ use solana_bench_tps::cli;
 use solana_core::gossip_service::{discover_cluster, get_client, get_multi_client};
 use solana_genesis::Base64Account;
 use solana_sdk::fee_calculator::FeeCalculator;
-use solana_sdk::signature::{Keypair, Signer};
+use solana_sdk::signature::{Keypair, KeypairUtil};
 use solana_sdk::system_program;
-use std::{collections::HashMap, fs::File, io::prelude::*, path::Path, process::exit, sync::Arc};
+use std::{collections::HashMap, fs::File, io::prelude::*, path::Path, process::exit};
 
 /// Number of signatures for all transactions in ~1 week at ~100K TPS
 pub const NUM_SIGNATURES_FOR_TXS: u64 = 100_000 * 60 * 60 * 24 * 7;
 
 fn main() {
-    solana_logger::setup_with_default("solana=info");
+    solana_logger::setup_with_filter("solana=info");
     solana_metrics::set_panic_hook("bench-tps");
 
     let matches = cli::build_args(solana_clap_utils::version!()).get_matches();
@@ -82,12 +82,12 @@ fn main() {
             );
             exit(1);
         }
-        Arc::new(client)
+        client
     } else {
-        Arc::new(get_client(&nodes))
+        get_client(&nodes)
     };
 
-    let (keypairs, move_keypairs) = if *read_from_client_file && !use_move {
+    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();
 
@@ -117,10 +117,10 @@ fn main() {
         // 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, None)
+        (keypairs, None, last_balance)
     } else {
         generate_and_fund_keypairs(
-            client.clone(),
+            &client,
             Some(*faucet_addr),
             &id,
             keypair_count,
@@ -133,5 +133,11 @@ fn main() {
         })
     };
 
-    do_bench_tps(client, cli_config, keypairs, move_keypairs);
+    do_bench_tps(
+        vec![client],
+        cli_config,
+        keypairs,
+        keypair_balance,
+        move_keypairs,
+    );
 }

bench-tps/tests/bench_tps.rs

@@ -8,8 +8,8 @@ use solana_faucet::faucet::run_local_faucet;
 use solana_local_cluster::local_cluster::{ClusterConfig, LocalCluster};
 #[cfg(feature = "move")]
 use solana_sdk::move_loader::solana_move_loader_program;
-use solana_sdk::signature::{Keypair, Signer};
-use std::sync::{mpsc::channel, Arc};
+use solana_sdk::signature::{Keypair, KeypairUtil};
+use std::sync::mpsc::channel;
 use std::time::Duration;
 
 fn test_bench_tps_local_cluster(config: Config) {
@@ -36,10 +36,10 @@ fn test_bench_tps_local_cluster(config: Config) {
         100_000_000,
     );
 
-    let client = Arc::new(create_client(
+    let client = create_client(
         (cluster.entry_point_info.rpc, cluster.entry_point_info.tpu),
         VALIDATOR_PORT_RANGE,
-    ));
+    );
 
     let (addr_sender, addr_receiver) = channel();
     run_local_faucet(faucet_keypair, addr_sender, None);
@@ -48,8 +48,8 @@ fn test_bench_tps_local_cluster(config: Config) {
     let lamports_per_account = 100;
 
     let keypair_count = config.tx_count * config.keypair_multiplier;
-    let (keypairs, move_keypairs) = generate_and_fund_keypairs(
-        client.clone(),
+    let (keypairs, move_keypairs, _keypair_balance) = generate_and_fund_keypairs(
+        &client,
         Some(faucet_addr),
         &config.id,
         keypair_count,
@@ -58,7 +58,7 @@ fn test_bench_tps_local_cluster(config: Config) {
     )
     .unwrap();
 
-    let _total = do_bench_tps(client, config, keypairs, move_keypairs);
+    let _total = do_bench_tps(vec![client], config, keypairs, 0, move_keypairs);
 
     #[cfg(not(debug_assertions))]
     assert!(_total > 100);

book/README.md

@@ -1,7 +1,7 @@
 Building the Solana book
 ---
 
-Install the book's dependencies, build, and test the book:
+Install the book's dependnecies, build, and test the book:
 
 ```bash
 $ ./build.sh

book/art/passive-staking-callflow.msc

@@ -24,7 +24,7 @@ msc {
   ... ;
   Validator abox Validator [label="\nmax\nlockout\n"];
        |||;
-  Cluster box Cluster [label="credits redeemed (at epoch)"];
-
+  StakerX => Cluster [label="StakeState::RedeemCredits()"];
+  StakerY => Cluster [label="StakeState::RedeemCredits()"] ;
 
 }

book/art/spv-bank-hash.bob

@@ -1,19 +0,0 @@
-                                   +----------+
-                                   | Bank-Hash|
-                                   +----------+
-                                        ^
-                                        |
-                  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
-                  :                                              :
-                  :       +--------------+     +-------------+   :
-                  : Hash( | Accounts-Hash|  +  | Block-Merkle| ) :
-                  :       +--------------+     +-------------+   :
-                  :              ^                               :
-                  +~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
-                                 |
- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 
- :       +---------------+   +---------------+          +---------------+   : 
- : Hash( | Hash(Account1)| + | Hash(Account2)| +  ... + | Hash(AccountN)| ) : 
- :       +---------------+   +---------------+          +---------------+   : 
- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 
-

book/art/spv-bank-merkle.bob

@@ -0,0 +1,18 @@
+                             +------------+
+                             | Bank-Merkle|
+                             +------------+
+                                ^      ^
+                               /        \
+               +-----------------+    +-------------+
+               | Bank-Diff-Merkle|    | Block-Merkle|
+               +-----------------+    +-------------+
+                     ^     ^
+                    /       \
+               +------+   +--------------------------+
+               | Hash |   | Previous Bank-Diff-Merkle|
+               +------+   +--------------------------+
+               ^      ^
+              /        \
+ +---------------+   +---------------+
+ | Hash(Account1)|   | Hash(Account2)|
+ +---------------+   +---------------+

book/art/validator.bob

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

book/build-cli-usage.sh

@@ -5,9 +5,9 @@ cd "$(dirname "$0")"
 
 usage=$(cargo -q run -p solana-cli -- -C ~/.foo --help | sed 's|'"$HOME"'|~|g')
 
-out=${1:-src/cli/usage.md}
+out=${1:-src/api-reference/cli.md}
 
-cat src/cli/.usage.md.header > "$out"
+cat src/api-reference/.cli.md > "$out"
 
 section() {
   declare mark=${2:-"###"}

book/build.sh

@@ -3,14 +3,4 @@ set -e
 
 cd "$(dirname "$0")"
 
-# md check
-find src -name '*.md' -a \! -name SUMMARY.md |
- while read -r file; do
-   if ! grep -q '('"${file#src/}"')' src/SUMMARY.md; then
-       echo "Error: $file missing from SUMMARY.md"
-       exit 1
-   fi
- done
-
-
 make -j"$(nproc)" test

book/makefile

@@ -1,6 +1,6 @@
 BOB_SRCS=$(wildcard art/*.bob)
 MSC_SRCS=$(wildcard art/*.msc)
-MD_SRCS=$(wildcard src/*.md src/*/*.md)
+MD_SRCS=$(wildcard src/*.md)
 
 SVG_IMGS=$(BOB_SRCS:art/%.bob=src/.gitbook/assets/%.svg) $(MSC_SRCS:art/%.msc=src/.gitbook/assets/%.svg)
 

book/src/SUMMARY.md

@@ -1,31 +1,14 @@
 # Table of contents
 
 * [Introduction](introduction.md)
-* [Using Solana from the Command-line](cli/README.md)
-  * [Command-line Usage](cli/usage.md)
-  * [Paper Wallet](paper-wallet/README.md)
-    * [Installation](paper-wallet/installation.md)
-    * [Paper Wallet Usage](paper-wallet/usage.md)
-  * [Offline Signing](offline-signing/README.md)
-    * [Durable Transaction Nonces](offline-signing/durable-nonce.md)
-* [Developing Applications](apps/README.md)
-  * [Example: Web Wallet](apps/webwallet.md)
-  * [Example: Tic-Tac-Toe](apps/tictactoe.md)
-  * [Drones](apps/drones.md)
-  * [Anatomy of a Transaction](transaction.md)
-  * [JSON RPC API](apps/jsonrpc-api.md)
-  * [JavaScript API](apps/javascript-api.md)
-* [Running a Validator](running-validator/README.md)
-  * [Validator Requirements](running-validator/validator-reqs.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)
-* [Running an Archiver](running-archiver.md)
-* [Understanding Solana's Architecture](cluster/README.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)
@@ -37,13 +20,45 @@
   * [Performance Metrics](cluster/performance-metrics.md)
 * [Anatomy of a Validator](validator/README.md)
   * [TPU](validator/tpu.md)
-  * [TVU](validator/tvu.md)
-  * [Blockstore](validator/blockstore.md)
+  * [TVU](validator/tvu/README.md)
+    * [Blocktree](validator/tvu/blocktree.md)
   * [Gossip Service](validator/gossip.md)
   * [The Runtime](validator/runtime.md)
-* [Building from Source](building-from-source.md)
-* [Terminology](terminology.md)
+* [Anatomy of a Transaction](transaction.md)
+* [Running a Validator](running-validator/README.md)
+  * [Validator Requirements](running-validator/validator-reqs.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)
+* [Running an Archiver](running-archiver.md)
+* [Paper Wallet](paper-wallet/README.md)
+  * [Installation](paper-wallet/installation.md)
+  * [Paper Wallet Usage](paper-wallet/usage.md)
+* [Offline Signing](offline-signing/README.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)
+  * [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)
+  * [Inter-chain Transaction Verification](proposals/interchain-transaction-verification.md)
+  * [Snapshot Verification](proposals/snapshot-verification.md)
+  * [Bankless Leader](proposals/bankless-leader.md)
+  * [Slashing](proposals/slashing.md)
 * [Implemented Design Proposals](implemented-proposals/README.md)
+  * [Blocktree](implemented-proposals/blocktree.md)
   * [Cluster Software Installation and Updates](implemented-proposals/installer.md)
   * [Cluster Economics](implemented-proposals/ed_overview/README.md)
     * [Validation-client Economics](implemented-proposals/ed_overview/ed_validation_client_economics/README.md)
@@ -54,7 +69,6 @@
     * [Replication-client Economics](implemented-proposals/ed_overview/ed_replication_client_economics/README.md)
       * [Storage-replication Rewards](implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_storage_replication_rewards.md)
       * [Replication-client Reward Auto-delegation](implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md)
-    * [Storage Rent Economics](implemented-proposals/ed_overview/ed_storage_rent_economics.md)
     * [Economic Sustainability](implemented-proposals/ed_overview/ed_economic_sustainability.md)
     * [Attack Vectors](implemented-proposals/ed_overview/ed_attack_vectors.md)
     * [Economic Design MVP](implemented-proposals/ed_overview/ed_mvp.md)
@@ -73,19 +87,3 @@
   * [Rent](implemented-proposals/rent.md)
   * [Durable Transaction Nonces](implemented-proposals/durable-tx-nonces.md)
   * [Validator Timestamp Oracle](implemented-proposals/validator-timestamp-oracle.md)
-  * [Commitment](implemented-proposals/commitment.md)
-  * [Snapshot Verification](implemented-proposals/snapshot-verification.md)
-* [Accepted Design Proposals](proposals/README.md)
-  * [Ledger Replication](proposals/ledger-replication-to-implement.md)
-  * [Secure Vote Signing](proposals/vote-signing-to-implement.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)
-  * [Inter-chain Transaction Verification](proposals/interchain-transaction-verification.md)
-  * [Snapshot Verification](proposals/snapshot-verification.md)
-  * [Bankless Leader](proposals/bankless-leader.md)
-  * [Slashing](proposals/slashing.md)
-  * [Tick Verification](proposals/tick-verification.md)
-  * [Block Confirmation](proposals/block-confirmation.md)
-  * [ABI Management](proposals/abi-management.md)

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

@@ -22,6 +22,12 @@ $ solana airdrop 2
 
 // Return
 "2.00000000 SOL"
+
+// Command
+$ solana airdrop 123 --lamports
+
+// Return
+"123 lamports"
 ```
 
 ### Get Balance

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 validator 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
+  * `hash`, the [blockhash](terminology.md#blockhash), as base-58 encoded string
+

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/jsonrpc-api.md

@@ -0,0 +1,994 @@
+# 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)
+* [getBlockCommitment](jsonrpc-api.md#getblockcommitment)
+* [getBlockTime](jsonrpc-api.md#getblocktime)
+* [getClusterNodes](jsonrpc-api.md#getclusternodes)
+* [getConfirmedBlock](jsonrpc-api.md#getconfirmedblock)
+* [getConfirmedBlocks](jsonrpc-api.md#getconfirmedblocks)
+* [getEpochInfo](jsonrpc-api.md#getepochinfo)
+* [getEpochSchedule](jsonrpc-api.md#getepochschedule)
+* [getGenesisHash](jsonrpc-api.md#getgenesishash)
+* [getLeaderSchedule](jsonrpc-api.md#getleaderschedule)
+* [getMinimumBalanceForRentExemption](jsonrpc-api.md#getminimumbalanceforrentexemption)
+* [getNumBlocksSinceSignatureConfirmation](jsonrpc-api.md#getnumblockssincesignatureconfirmation)
+* [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)
+* [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.
+
+## Configuring State Commitment
+
+Solana nodes choose which bank state to query based on a commitment requirement
+set by the client. Clients may specify either:
+* `{"commitment":"max"}` - the node will query the most recent bank having reached `MAX_LOCKOUT_HISTORY` confirmations
+* `{"commitment":"recent"}` - the node will query its most recent bank state
+
+The commitment parameter should be included as the last element in the `params` array:
+
+```bash
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getBalance", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri",{"commitment":"max"}]}' 192.168.1.88:8899
+```
+
+#### Default:
+If commitment configuration is not provided, the node will default to `"commitment":"max"`
+
+Only methods that query bank state accept the commitment parameter. They are indicated in the API Reference below.
+
+#### RpcResponse Structure
+Many methods that take a commitment parameter return an RpcResponse JSON object comprised of two parts:
+
+* `context` : An RpcResponseContext JSON structure including a `slot` field at which the operation was evaluated.
+* `value` : The value returned by the operation itself.
+
+
+## JSON RPC API Reference
+
+### confirmTransaction
+
+Returns a transaction receipt
+
+#### Parameters:
+
+* `string` - Signature of Transaction to confirm, as base-58 encoded string
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+* `RpcResponse<boolean>` - RpcResponse JSON object with `value` field set to Transaction status, boolean 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":{"context":{"slot":1},"value":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
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+The result value will be an RpcResponse JSON object containing an AccountInfo JSON object.
+
+* `RpcResponse<AccountInfo>`, RpcResponse JSON object with `value` field set to AccountInfo, a JSON object containing:
+* `lamports`, number of lamports assigned to this account, as a u64
+* `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":{"context":{"slot":1},"value":{"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.22.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
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+* `RpcResponse<u64>` - RpcResponse JSON object with `value` field set to quantity
+
+#### 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":{"context":{"slot":1},"value":0},"id":1}
+```
+
+### getBlockCommitment
+
+Returns commitment for particular block
+
+#### Parameters:
+
+* `u64` - block, identified by Slot
+
+#### Results:
+
+The result field will be an array with two fields:
+
+* Commitment
+  * `null` - Unknown block
+  * `object` - BlockCommitment
+    * `array` - commitment, array of u64 integers logging the amount of cluster stake in lamports that has voted on the block at each depth from 0 to `MAX_LOCKOUT_HISTORY`
+* 'integer' - total active stake, in lamports, of the current epoch
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getBlockCommitment","params":[5]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":[{"commitment":[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,10,32]},42],"id":1}
+```
+
+### getBlockTime
+
+Returns the estimated production time of a block. Validators report their UTC
+time to the ledger on a regular interval. A block's time is calculated as an
+offset from the median value of the most recent validator time report.
+
+#### Parameters:
+
+* `u64` - block, identified by Slot
+
+#### Results:
+
+* `null` - block has not yet been produced
+* `i64` - estimated production time, as Unix timestamp (seconds since the Unix epoch)
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getBlockTime","params":[5]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":1574721591,"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}
+```
+
+### getConfirmedBlock
+
+Returns identity and transaction information about a confirmed block in the ledger
+
+#### Parameters:
+
+* `integer` - slot, as u64 integer
+
+#### Results:
+
+The result field will be an object with the following fields:
+
+* `blockhash` - the blockhash of this block
+* `previousBlockhash` - the blockhash of this block's parent
+* `parentSlot` - the slot index of this block's parent
+* `transactions` - an array of tuples containing:
+  * [Transaction](transaction-api.md) object, in JSON format
+  * Transaction status object, containing:
+     * `status` - 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)
+     * `fee` - fee this transaction was charged, as u64 integer
+     * `preBalances` - array of u64 account balances from before the transaction was processed
+     * `postBalances` - array of u64 account balances after the transaction was processed
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlock","params":[430]}' localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":{"blockhash":[165,245,120,183,32,205,89,222,249,114,229,49,250,231,149,122,156,232,181,83,238,194,157,153,7,213,180,54,177,6,25,101],"parentSlot":429,"previousBlockhash":[21,108,181,90,139,241,212,203,45,78,232,29,161,31,159,188,110,82,81,11,250,74,47,140,188,28,23,96,251,164,208,166],"transactions":[[{"message":{"accountKeys":[[5],[219,181,202,40,52,148,34,136,186,59,137,160,250,225,234,17,244,160,88,116,24,176,30,227,68,11,199,38,141,68,131,228],[233,48,179,56,91,40,254,206,53,48,196,176,119,248,158,109,121,77,11,69,108,160,128,27,228,122,146,249,53,184,68,87],[6,167,213,23,25,47,10,175,198,242,101,227,251,119,204,122,218,130,197,41,208,190,59,19,110,45,0,85,32,0,0,0],[6,167,213,23,24,199,116,201,40,86,99,152,105,29,94,182,139,94,184,163,155,75,109,92,115,85,91,33,0,0,0,0],[7,97,72,29,53,116,116,187,124,77,118,36,235,211,189,179,216,53,94,115,209,16,67,252,13,163,83,128,0,0,0,0]],"header":{"numReadonlySignedAccounts":0,"numReadonlyUnsignedAccounts":3,"numRequiredSignatures":2},"instructions":[[1],{"accounts":[[3],1,2,3],"data":[[52],2,0,0,0,1,0,0,0,0,0,0,0,173,1,0,0,0,0,0,0,86,55,9,248,142,238,135,114,103,83,247,124,67,68,163,233,55,41,59,129,64,50,110,221,234,234,27,213,205,193,219,50],"program_id_index":4}],"recentBlockhash":[21,108,181,90,139,241,212,203,45,78,232,29,161,31,159,188,110,82,81,11,250,74,47,140,188,28,23,96,251,164,208,166]},"signatures":[[2],[119,9,95,108,35,95,7,1,69,101,65,45,5,204,61,114,172,88,123,238,32,201,135,229,57,50,13,21,106,216,129,183,238,43,37,101,148,81,56,232,88,136,80,65,46,189,39,106,94,13,238,54,186,48,118,186,0,62,121,122,172,171,66,5],[78,40,77,250,10,93,6,157,48,173,100,40,251,9,7,218,7,184,43,169,76,240,254,34,235,48,41,175,119,126,75,107,106,248,45,161,119,48,174,213,57,69,111,225,245,60,148,73,124,82,53,6,203,126,120,180,111,169,89,64,29,23,237,13]]},{"fee":100000,"status":{"Ok":null},"preBalances":[499998337500,15298080,1,1,1],"postBalances":[499998237500,15298080,1,1,1]}]]},"id":1}
+```
+
+### getConfirmedBlocks
+
+Returns a list of confirmed blocks
+
+#### Parameters:
+
+* `integer` - start_slot, as u64 integer
+* `integer` - (optional) end_slot, as u64 integer
+
+#### Results:
+
+The result field will be an array of u64 integers listing confirmed blocks
+between start_slot and either end_slot, if provided, or latest confirmed block,
+inclusive.
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlocks","params":[5, 10]}' localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":[5,6,7,8,9,10],"id":1}
+```
+
+### getEpochInfo
+
+Returns information about the current epoch
+
+#### Parameters:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### 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}
+```
+
+### getEpochSchedule
+
+Returns epoch schedule information from this cluster's genesis config
+
+#### Parameters:
+
+None
+
+#### Results:
+
+The result field will be an object with the following fields:
+
+* `slots_per_epoch`, the maximum number of slots in each epoch
+* `leader_schedule_slot_offset`, the number of slots before beginning of an epoch to calculate a leader schedule for that epoch
+* `warmup`, whether epochs start short and grow
+* `first_normal_epoch`, first normal-length epoch, log2(slots_per_epoch) - log2(MINIMUM_SLOTS_PER_EPOCH)
+* `first_normal_slot`, MINIMUM_SLOTS_PER_EPOCH * (2.pow(first_normal_epoch) - 1)
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochSchedule"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":{"first_normal_epoch":8,"first_normal_slot":8160,"leader_schedule_slot_offset":8192,"slots_per_epoch":8192,"warmup":true},"id":1}
+```
+
+### getGenesisHash
+
+Returns the genesis 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":"getGenesisHash"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC","id":1}
+```
+
+### getLeaderSchedule
+
+Returns the leader schedule for an epoch
+
+#### Parameters:
+
+* `slot` - (optional) Fetch the leader schedule for the epoch that corresponds to the provided slot.  If unspecified, the leader schedule for the current epoch is fetched
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+The result field will be a dictionary of leader public keys \(as base-58 encoded
+strings\) and their corresponding leader slot indices as values (indices are to
+the first slot in the requested 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":{"4Qkev8aNZcqFNSRhQzwyLMFSsi94jHqE8WNVTJzTP99F":[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63]},"id":1}
+```
+
+### getMinimumBalanceForRentExemption
+
+Returns minimum balance required to make account rent exempt.
+
+#### Parameters:
+
+* `u64` - account data length
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+* `u64` - minimum lamports required in account
+
+#### Example:
+
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getMinimumBalanceForRentExemption", "params":[50]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":500,"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
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+* `u64` - count
+
+#### 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}
+```
+
+### getProgramAccounts
+
+Returns all accounts owned by the provided program Pubkey
+
+#### Parameters:
+
+* `string` - Pubkey of program, as base-58 encoded string
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### 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 u64
+* `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:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+An RpcResponse containing an array consisting of a string blockhash and FeeCalculator JSON object.
+
+* `RpcResponse<array>` - RpcResponse JSON object with `value` field set to an array including:
+* `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":{"context":{"slot":1},"value":["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
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### 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:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### 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:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### 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:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### 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}
+```
+
+### getTransactionCount
+
+Returns the current Transaction count from the ledger
+
+#### Parameters:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+* `u64` - count
+
+#### 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:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### Results:
+
+* `u64` - Total supply
+
+#### 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:
+
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+
+#### 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`, percentage (0-100) of rewards payout owed to the vote account
+* `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 u64
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment) (used for retrieving blockhash and verifying airdrop success)
+
+#### 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.22.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.22.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,62 @@
+# 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_readonly_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_readonly_unsigned_accounts` public keys in `account_keys` refer
+
+        to non-signing credit only accounts
+
+    * **account\_keys:** List of public keys used by the transaction, including
+
+      by the instructions and for signatures. The first
+
+      `num_required_signatures` public keys 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/aacead62c0eb052068172eba6b53fc85874d6d54/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 public key 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 public key 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/cli/README.md

@@ -1,5 +0,0 @@
-# Using Solana from the Command-line
-
-This chapter describes the command-line tools for interacting with Solana. One
-could use these tools to send payments, stake validators, and check account
-balances.

book/src/cluster/README.md

@@ -4,7 +4,7 @@ A Solana cluster is a set of validators working together to serve client transac
 
 ## Creating a Cluster
 
-Before starting any validators, one first needs to create a _genesis config_. The config references two public keys, a _mint_ and a _bootstrap validator_. The validator holding the bootstrap validator'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 config. The second validator then contacts the bootstrap validator to register as a _validator_ or _archiver_. Additional validators then register with any registered member of the cluster.
+Before starting any validators, one first needs to create a _genesis config_. The config references two public keys, a _mint_ and a _bootstrap leader_. The validator 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 config. The second validator then contacts the bootstrap leader to register as a _validator_ or _archiver_. Additional validators 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 archiver nodes submit proofs that they have stored copies of it. Once the validator observes a sufficient number of copies exist, it deletes its copy.
 
@@ -37,4 +37,4 @@ Solana rotates leaders at fixed intervals, called _slots_. Each leader may only
 
 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 [_Turbine Block Propogation_](turbine-block-propagation.md).
+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/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/data-plane-fanout.md) section.

book/src/cluster/managing-forks.md

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

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

@@ -1,6 +1,6 @@
 # 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](../implemented-proposals/staking-rewards.md). This chapter, on the other hand, describes the underlying mechanics of its implementation.
+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
 
@@ -29,7 +29,11 @@ VoteState is the current state of all the votes the validator has submitted to t
 * Account::lamports - The accumulated lamports from the commission. These do not count as stakes.
 * `authorized_voter` - Only this identity is authorized to submit votes. This field can only modified by this identity.
 * `node_pubkey` - The Solana node that votes in this account.
-* `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's address and the authorized vote signer
+* `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's
+
+  ```text
+                       address and the authorized vote signer
+  ```
 
 ### VoteInstruction::Initialize\(VoteInit\)
 
@@ -44,11 +48,13 @@ VoteState is the current state of all the votes the validator has submitted to t
 Updates the account with a new authorized voter or withdrawer, according to the VoteAuthorize parameter \(`Voter` or `Withdrawer`\). The transaction must be by signed by the Vote account's current `authorized_voter` or `authorized_withdrawer`.
 
 * `account[0]` - RW - The VoteState
+
   `VoteState::authorized_voter` or `authorized_withdrawer` is set to to `Pubkey`.
 
 ### VoteInstruction::Vote\(Vote\)
 
 * `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 - `sysvar::slot_hashes` A list of some N most recent slots and their hashes for the vote to be verified against.
@@ -67,10 +73,18 @@ StakeState::Stake is the current delegation preference of the **staker** and con
 * `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 was de-activated, some cool down epochs are required before the account is fully deactivated, and the stake available for withdrawal
+* `deactivated` - the epoch at which this stake was de-activated, some cool down epochs are required before the account
+
+  ```text
+              is fully deactivated, and the stake available for withdrawal
+  ```
 
 * `authorized_staker` - the pubkey of the entity that must sign delegation, activation, and deactivation transactions
-* `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's address, and the authorized staker
+* `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's
+
+  ```text
+                       address, and the authorized staker
+  ```
 
 ### StakeState::RewardsPool
 
@@ -80,22 +94,42 @@ The Stakes and the RewardsPool are accounts that are owned by the same `Stake` p
 
 ### StakeInstruction::DelegateStake
 
-The Stake account is moved from Initialized to StakeState::Stake form, or from a deactivated (i.e. fully cooled-down) StakeState::Stake to activated StakeState::Stake. This is how stakers choose the vote account and validator node to which their stake account lamports are delegated. The transaction must be signed by the stake's `authorized_staker`.
+The Stake account is moved from Ininitialized to StakeState::Stake form. This is how stakers choose their initial delegate validator node and activate their stake account lamports. The transaction must be signed by the stake's `authorized_staker`.  If the stake account is already StakeState::Stake \(i.e. already activated\), the stake is re-delegated.  Stakes may be re-delegated at any time, and updated stakes are reflected immediately, but only one re-delegation is permitted per epoch.
 
 * `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]`.  If this is the initial delegation of stake, `StakeState::Stake::stake` is initialized to the account's balance in lamports,  `StakeState::Stake::activated` is initialized to the current Bank epoch, and  `StakeState::Stake::deactivated` is initialized to std::u64::MAX
 * `account[1]` - R - The VoteState instance.
 * `account[2]` - R - sysvar::clock account, carries information about current Bank epoch
-* `account[3]` - R - sysvar::stakehistory account, carries information about stake history
-* `account[4]` - R - stake::Config accoount, carries warmup, cooldown, and slashing configuration
+* `account[3]` - R - stake::Config accoount, carries warmup, cooldown, and slashing configuration
 
 ### StakeInstruction::Authorize\(Pubkey, StakeAuthorize\)
 
-Updates the account with a new authorized staker or withdrawer, according to the StakeAuthorize parameter \(`Staker` or `Withdrawer`\). The transaction must be by signed by the Stakee account's current `authorized_staker` or `authorized_withdrawer`.  Any stake lock-up must have expired, or the lock-up custodian must also sign the transaction.
+Updates the account with a new authorized staker or withdrawer, according to the StakeAuthorize parameter \(`Staker` or `Withdrawer`\). The transaction must be by signed by the Stakee account's current `authorized_staker` or `authorized_withdrawer`.
 
 * `account[0]` - RW - The StakeState
 
   `StakeState::authorized_staker` or `authorized_withdrawer` is set to to `Pubkey`.
 
+### 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 and the stake account's `stake` is increased by the same amount \(re-invested\).
+
+```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.
@@ -128,11 +162,11 @@ Lamports build up over time in a Stake account and any excess over activated sta
 
 ## 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](../proposals/slashing.md).
+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/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/staking-and-rewards.md).
 
 ### Basics
 
-The network pays rewards from a portion of network [inflation](../terminology.md#inflation). 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).
+The network pays rewards from a portion of network [inflation](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/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.
 
@@ -154,7 +188,7 @@ Stakers who have delegated to that validator earn points in proportion to their
 
 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` \(set to 25% per epoch in the current implementation\).
+The stake program limits the rate of change to total network stake, reflected in the stake program's `config::warmup_rate` \(typically 25% 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.
 
@@ -194,4 +228,4 @@ Only lamports in excess of effective+activating stake may be withdrawn at any ti
 
 ### Lock-up
 
-Stake accounts support the notion of lock-up, wherein the stake account balance is unavailable for withdrawal until a specified time. Lock-up is specified as an epoch height, i.e. the minimum epoch height that must be reached by the network before the stake account balance is available for withdrawal, unless the transaction is also signed by a specified custodian. This information is gathered when the stake account is created, and stored in the Lockup field of the stake account's state.  Changing the authorized staker or withdrawer is also subject to lock-up, as such an operation is effectively a transfer.
+Stake accounts support the notion of lock-up, wherein the stake account balance is unavailable for withdrawal until a specified time. Lock-up is specified as an epoch height, i.e. the minimum epoch height that must be reached by the network before the stake account balance is available for withdrawal, unless the transaction is also signed by a specified custodian. This information is gathered when the stake account is created, and stored in the Lockup field of the stake account's state.

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

@@ -8,7 +8,7 @@ During its slot, the leader node distributes shreds between the validator nodes
 
 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 shred 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 shred using a seed derived from the leader id, slot and shred index.
+To reduce the possibility of attack vectors, each shred 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 shred using randomness derived from the shred 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
 

book/src/getting-started/README.md

@@ -1,4 +1,4 @@
-# Building from Source
+# 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.
 
@@ -52,12 +52,12 @@ $ NDEBUG=1 ./multinode-demo/faucet.sh
 
 ### Singlenode Testnet
 
-Before you start a validator, make sure you know the IP address of the machine you want to be the bootstrap validator for the demo, and make sure that udp ports 8000-10000 are open on all the machines you want to test with.
+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 validator in a separate shell:
+Now start the bootstrap leader in a separate shell:
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/bootstrap-validator.sh
+$ NDEBUG=1 ./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 faucet if it doesn't have any. The faucet does not need to be running for subsequent leader starts.
@@ -74,7 +74,7 @@ To run a performance-enhanced validator on Linux, [CUDA 10.0](https://developer.
 
 ```bash
 $ ./fetch-perf-libs.sh
-$ NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/bootstrap-validator.sh
+$ NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/bootstrap-leader.sh
 $ NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/validator.sh
 ```
 
@@ -121,40 +121,12 @@ thread apply all bt
 
 This will dump all the threads stack traces into gdb.txt
 
-### Blockstreamer
-
-Solana supports a node type called an _blockstreamer_. This validator 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
-$ NDEBUG=1 ./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
-  * `hash`, the [blockhash](terminology.md#blockhash), as base-58 encoded string
-
 ## 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
-$ NDEBUG=1 ./multinode-demo/bench-tps.sh --entrypoint devnet.solana.com:8001 --faucet devnet.solana.com:9900 --duration 60 --tx_count 50
+$ NDEBUG=1 ./multinode-demo/bench-tps.sh --entrypoint testnet.solana.com:8001 --faucet 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 an Archiver](../running-archiver.md)
+

book/src/implemented-proposals/blocktree.md

@@ -0,0 +1,90 @@
+# 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 shred it observes on the network, in any order, as long as the shred is signed by the expected leader for a given slot.
+
+Shreds are moved to a fork-able key space the tuple of `leader slot` + `shred index` \(within the slot\). This permits the skip-list structure of the Solana protocol to be stored in its entirety, without a-priori choosing which fork to follow, which Entries to persist or when to persist them.
+
+Repair requests for recent shreds are served out of RAM or recent files and out of deeper storage for less recent shreds, as implemented by the store backing Blocktree.
+
+## 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
+
+   shred received is consistent with the leader schedule \(i.e. was signed by the
+
+   leader for the indicated slot\), it is immediately stored.
+
+2. Repair: repair is the same as window repair above, but able to serve any
+
+   shred that's been received. Blocktree stores shreds with signatures,
+
+   preserving the chain of origination.
+
+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
+
+   \(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 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 shred index `n`, such that for all `m < n`, there exists a shred in this slot with shred index equal to `n` \(i.e. the highest consecutive shred index\).
+   * `received` - The highest received shred index for the slot
+   * `next_slots` - A list of future slots this slot could chain to. Used when rebuilding
+
+     the ledger to find possible fork points.
+
+   * `last_index` - The index of the shred that is flagged as the last shred for this slot. This flag on a shred will be set by the leader for a slot when they are transmitting the last shred for a slot.
+   * `is_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 shred for a new slot `x` arrives, we check the number of blocks \(`num_blocks`\) for that new slot \(this information is encoded in the shred\). We then know that this new slot chains to slot `x - num_blocks`.
+4. Subscriptions - The Blocktree records a set of slots that have been "subscribed" to. This means entries that chain to these slots will be sent on the Blocktree channel for consumption by the ReplayStage. See the `Blocktree APIs` for details.
+5. Update notifications - The Blocktree notifies listeners when slot\(n\).is\_rooted is flipped from false to true for any `n`.
+
+## 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.
+
+Archiver nodes will be responsible for storing really old ledger contents, and validators need only persist their bank periodically.
+

book/src/implemented-proposals/commitment.md

@@ -28,7 +28,7 @@ lockout on a bank `b`.
 
 This computation is performed on a votable candidate bank `b` as follows.
 
-```text
+```
    let output: HashMap<b, StakeLockout> = HashMap::new();
    for vote_account in b.vote_accounts {
        for v in vote_account.vote_stack {
@@ -62,7 +62,7 @@ votes > v as the number of confirmations will be lower).
 
 Now more specifically, we augment the above computation to:
 
-```text
+```
    let output: HashMap<b, StakeLockout> = HashMap::new();
    let fork_commitment_cache = ForkCommitmentCache::default();
    for vote_account in b.vote_accounts {
@@ -76,7 +76,7 @@ Now more specifically, we augment the above computation to:
 ```
 
 where `f'` is defined as:
-```text
+```
     fn f`(
         stake_lockout: &mut StakeLockout,
         some_ancestor: &mut BlockCommitment,

book/src/implemented-proposals/durable-tx-nonces.md

@@ -26,7 +26,10 @@ account data. A transaction is now constructed in the normal way, but with the
 following additional requirements:
 
   1) The durable nonce value is used in the `recent_blockhash` field
-  2) An `AdvanceNonceAccount` instruction is the first issued in the transaction
+  2) A `Nonce` instruction is issued (first?)
+  3) The appropriate transaction flag is set, signaling that the usual
+hash age check should be skipped and the previous requirements enforced. This
+may be unnecessary, see [Runtime Support](#runtime-support) below
 
 ### Contract Mechanics
 
@@ -63,43 +66,21 @@ WithdrawInstruction(to, lamports)
   success
 ```
 
-A client wishing to use this feature starts by creating a nonce account under 
-the system program. This account will be in the `Uninitialized` state with no
-stored hash, and thus unusable.
+A client wishing to use this feature starts by creating a nonce account and
+depositing sufficient lamports as to make it rent-exempt. The resultant account
+will be in the `Uninitialized` state with no stored hash and thus unusable.
 
-To initialize a newly created account, an `InitializeNonceAccount` instruction must be
-issued. This instruction takes one parameter, the `Pubkey` of the account's
-[authority](../offline-signing/durable-nonce.md#nonce-authority). Nonce accounts
-must be [rent-exempt](rent.md#two-tiered-rent-regime) to meet the data-persistence
-requirements of the feature, and as such, require that sufficient lamports be
-deposited before they can be initialized. Upon successful initialization, the
-cluster's most recent blockhash is stored along with specified nonce authority
-`Pubkey`.
+The `Nonce` instruction is used to request that a new nonce be stored for the
+calling account. The first `Nonce` instruction run on a newly created account
+will drive the account's state to `Initialized`. As such, a `Nonce` instruction
+MUST be issued before the account can be used.
 
-The `AdvanceNonceAccount` instruction is used to manage the account's stored nonce
-value. It stores the cluster's most recent blockhash in the account's state data,
-failing if that matches the value already stored there. This check prevents
-replaying transactions within the same block.
+To discard a `NonceAccount`, the client should issue a `Withdraw` instruction
+which withdraws all lamports, leaving a zero balance and making the account
+eligible for deletion.
 
-Due to nonce accounts' [rent-exempt](rent.md#two-tiered-rent-regime) requirement,
-a custom withdraw instruction is used to move funds out of the account.
-The `WithdrawNonceAccount` instruction takes a single argument, lamports to withdraw,
-and enforces rent-exemption by preventing the account's balance from falling
-below the rent-exempt minimum. An exception to this check is if the final balance
-would be zero lamports, which makes the account eligible for deletion. This
-account closure detail has an additional requirement that the stored nonce value
-must not match the cluster's most recent blockhash, as per `AdvanceNonceAccount`.
-
-The account's [nonce authority](../offline-signing/durable-nonce.md#nonce-authority)
-can be changed using the `AuthorizeNonceAccount` instruction. It takes one parameter,
-the `Pubkey` of the new authority. Executing this instruction grants full
-control over the account and its balance to the new authority.
-
-{% hint style="info" %}
-`AdvanceNonceAccount`, `WithdrawNonceAccount` and `AuthorizeNonceAccount` all require the current
-[nonce authority](../offline-signing/durable-nonce.md#nonce-authority) for the
-account to sign the transaction.
-{% endhint %}
+`Nonce` and `Withdraw` instructions each will only succeed if the stored
+blockhash is no longer resident in sysvar.recent_blockhashes.
 
 ### Runtime Support
 
@@ -108,11 +89,25 @@ an extant `recent_blockhash` on the transaction and prevent fee theft via
 failed transaction replay, runtime modifications are necessary.
 
 Any transaction failing the usual `check_hash_age` validation will be tested
-for a Durable Transaction Nonce. This is signaled by including a `AdvanceNonceAccount`
-instruction as the first instruction in the transaction.
+for a Durable Transaction Nonce. This specifics of this test are undecided, some
+options:
 
-If the runtime determines that a Durable Transaction Nonce is in use, it will
-take the following additional actions to validate the transaction:
+  1) Require that the `Nonce` instruction be the first in the transaction
+    * + No ABI changes
+    * + Fast and simple
+    * - Sets a precedent that may lead to incompatible instruction combinations
+  2) Blind search for a `Nonce` instruction over all instructions in the
+transaction
+    * + No ABI changes
+    * - Potentially slow
+  3) [2], but guarded by a transaction flag
+    * - ABI changes
+    * - Wire size increase
+    * + We'll probably end up with some sort of flags eventually anyway
+
+Current prototyping will use [1]. If it is determined that a Durable Transaction
+Nonce is in use, the runtime will take the following actions to validate the
+transaction:
 
   1) The `NonceAccount` specified in the `Nonce` instruction is loaded.
   2) The `NonceState` is deserialized from the `NonceAccount`'s data field and
@@ -123,11 +118,6 @@ one specified in the transaction's `recent_blockhash` field.
 If all three of the above checks succeed, the transaction is allowed to continue
 validation.
 
-Since transactions that fail with an `InstructionError` are charged a fee and
-changes to their state rolled back, there is an opportunity for fee theft if an
-`AdvanceNonceAccount` instruction is reverted. A malicious validator could replay the
-failed transaction until the stored nonce is successfully advanced. Runtime
-changes prevent this behavior. When a durable nonce transaction fails with an
-`InstructionError` aside from the `AdvanceNonceAccount` instruction, the nonce account
-is rolled back to its pre-execution state as usual. Then the runtime advances
-its nonce value and the advanced nonce account stored as if it succeeded.
+### Open Questions
+
+* Should this feature be restricted in the number of uses per transaction?

book/src/implemented-proposals/ed_overview/README.md

@@ -10,6 +10,7 @@ These protocol-based rewards, to be distributed to participating validation and
 
 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/), [State-validation Protocol-based Rewards](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_validation_client_economics/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/) chapter will review the Solana network design for global ledger storage/redundancy and archiver-client economics \([Storage-replication rewards](ed_replication_client_economics/ed_rce_storage_replication_rewards.md)\) along with an archiver-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md). 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/), [State-validation Protocol-based Rewards](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. Additionally, in [Storage Rent Economics](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/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/) chapter will review the Solana network design for global ledger storage/redundancy and archiver-client economics \([Storage-replication rewards](ed_replication_client_economics/ed_rce_storage_replication_rewards.md)\) along with an archiver-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md). 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.
 
 **Figure 1**: Schematic overview of Solana economic incentive design.
+

book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md

@@ -8,4 +8,5 @@ While replication-clients are incentivized and rewarded through protocol-based r
 
 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, also described in detail below in [Economic Sustainability](../ed_economic_sustainability/README.md). 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 archivers 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\).
+There are various attack vectors available for colluding validation and replication clients, also described in detail below in [Economic Sustainability](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_economic_sustainability/README.md). 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 archivers 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/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md

@@ -11,7 +11,7 @@ Validator-client rewards for these services are to be distributed at the end of
 
 The effective protocol-based annual interest rate \(%\) per epoch received by validation-clients is to be a function of:
 
-* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](.)\)
+* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_validartion_client_economics.md)\)
 * the fraction of staked SOLs out of the current total circulating supply,
 * the up-time/participation \[% of available slots that validator had opportunity to vote on\] of a given validator over the previous epoch.
 

book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md

@@ -13,6 +13,7 @@ Many current blockchain economies \(e.g. Bitcoin, Ethereum\), rely on protocol-b
 
 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.
 
-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\)[1](../ed_references.md).
+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\)[1](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_referenced.md).
 
 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/implemented-proposals/installer.md

@@ -77,7 +77,7 @@ pub struct UpdateManifest {
     pub download_sha256: String, // SHA256 digest of the release tar.bz2 file
 }
 
-/// Data of an Update Manifest program Account.
+/// Userdata of an Update Manifest program Account.
 #[derive(Serialize, Deserialize, Default, Debug, PartialEq)]
 pub struct SignedUpdateManifest {
     pub manifest: UpdateManifest,
@@ -154,7 +154,7 @@ FLAGS:
 
 OPTIONS:
     -d, --data_dir <PATH>    Directory to store install data [default: .../Library/Application Support/solana]
-    -u, --url <URL>          JSON RPC URL for the solana cluster [default: http://devnet.solana.com:8899]
+    -u, --url <URL>          JSON RPC URL for the solana cluster [default: http://testnet.solana.com:8899]
     -p, --pubkey <PUBKEY>    Public key of the update manifest [default: 9XX329sPuskWhH4DQh6k16c87dHKhXLBZTL3Gxmve8Gp]
 ```
 

book/src/implemented-proposals/rent.md

@@ -18,9 +18,9 @@ Accounts whose balance is insufficient to satisfy the rent that would be due sim
 
 A percentage of the rent collected is destroyed. The rest is distributed to validator accounts by stake weight, a la transaction fees, at the end of every slot.
 
-## Read-only accounts
+## Credit only
 
-Read-only accounts are not being charged rent in current implementation.
+Credit only accounts are treated as a special case. They are loaded as if rent were due, but updates to their state may be delayed until the end of the slot, when credits are paid.
 
 ## Design considerations, others considered
 

book/src/implemented-proposals/repair-service.md

@@ -2,103 +2,48 @@
 
 ## Repair Service
 
-The RepairService is in charge of retrieving missing shreds that failed to be
-delivered by primary communication protocols like Turbine. It is in charge of
-managing the protocols described below in the `Repair Protocols` section below.
+The RepairService is in charge of retrieving missing shreds that failed to be delivered by primary communication protocols like Avalanche. It is in charge of managing the protocols described below in the `Repair Protocols` section below.
 
 ## Challenges:
 
 1\) Validators can fail to receive particular shreds due to network failures
 
-2\) Consider a scenario where blockstore contains the set of slots {1, 3, 5}.
-Then Blockstore receives shreds for some slot 7, where for each of the shreds
-b, b.parent == 6, so then the parent-child relation 6 -> 7 is stored in
-blockstore. However, there is no way to chain these slots to any of the
-existing banks in Blockstore, and thus the `Shred Repair` protocol will not
-repair these slots. If these slots happen to be part of the main chain, this
-will halt replay progress on this node.
+2\) Consider a scenario where blocktree contains the set of slots {1, 3, 5}. Then Blocktree receives shreds for some slot 7, where for each of the shreds b, b.parent == 6, so then the parent-child relation 6 -> 7 is stored in blocktree. However, there is no way to chain these slots to any of the existing banks in Blocktree, and thus the `Shred Repair` protocol will not repair these slots. If these slots happen to be part of the main chain, this will halt replay progress on this node.
 
-## Repair-related primitives
-Epoch Slots:
-   Each validator advertises separately on gossip thhe various parts of an
-   `Epoch Slots`:
-   * The `stash`: An epoch-long compressed set of all completed slots.
-   * The `cache`: The Run-length Encoding (RLE) of the latest `N` completed
-     slots starting from some some slot `M`, where `N` is the number of slots
-     that will fit in an MTU-sized packet.
+3\) Validators that find themselves behind the cluster by an entire epoch struggle/fail to catch up because they do not have a leader schedule for future epochs. If nodes were to blindly accept repair shreds in these future epochs, this exposes nodes to spam.
 
-   `Epoch Slots` in gossip are updated every time a validator receives a
-   complete slot within the epoch. Completed slots are detected by blockstore
-   and sent over a channel to RepairService. It is important to note that we
-   know that by the time a slot `X` is complete, the epoch schedule must exist
-   for the epoch that contains slot `X` because WindowService will reject
-   shreds for unconfirmed epochs.
+## Repair Protocols
 
-   Every `N/2` completed slots, the oldest `N/2` slots are moved from the
-   `cache` into the `stash`. The base value `M` for the RLE should also
-   be updated.
-   
-## Repair Request Protocols
-
-The repair protocol makes best attempts to progress the forking structure of
-Blockstore.
+The repair protocol makes best attempts to progress the forking structure of Blocktree.
 
 The different protocol strategies to address the above challenges:
 
-1. Shred Repair \(Addresses Challenge \#1\): This is the most basic repair
-protocol, with the purpose of detecting and filling "holes" in the ledger.
-Blockstore tracks the latest root slot. RepairService will then periodically
-iterate every fork in blockstore starting from the root slot, sending repair
-requests to validators for any missing shreds. It will send at most some `N`
-repair reqeusts per iteration. Shred repair should prioritize repairing
-forks based on the leader's fork weight. Validators should only send repair
-requests to validators who have marked that slot as completed in their
-EpochSlots. Validators should prioritize repairing shreds in each slot
-that they are responsible for retransmitting through turbine. Validators can
-compute which shreds they are responsible for retransmitting because the
-seed for turbine is based on leader id, slot, and shred index.
+1. Shred Repair \(Addresses Challenge \#1\): This is the most basic repair protocol, with the purpose of detecting and filling "holes" in the ledger. Blocktree tracks the latest root slot. RepairService will then periodically iterate every fork in blocktree starting from the root slot, sending repair requests to validators for any missing shreds. It will send at most some `N` repair reqeusts per iteration.
 
-   Note: Validators will only accept shreds within the current verifiable
-   epoch \(epoch the validator has a leader schedule for\).
+   Note: Validators will only accept shreds within the current verifiable epoch \(epoch the validator has a leader schedule for\).
 
-2. Preemptive Slot Repair \(Addresses Challenge \#2\): The goal of this
-protocol is to discover the chaining relationship of "orphan" slots that do not
-currently chain to any known fork. Shred repair should prioritize repairing
-orphan slots based on the leader's fork weight.
-   * Blockstore will track the set of "orphan" slots in a separate column family.
-   * RepairService will periodically make `Orphan` requests for each of
-   the orphans in blockstore.
+2. Preemptive Slot Repair \(Addresses Challenge \#2\): The goal of this protocol is to discover the chaining relationship of "orphan" slots that do not currently chain to any known fork.
+   * Blocktree will track the set of "orphan" slots in a separate column family.
+   * RepairService will periodically make `RequestOrphan` requests for each of the orphans in blocktree.
 
-     `Orphan(orphan)` request - `orphan` is the orphan slot that the
-     requestor wants to know the parents of `Orphan(orphan)` response -
-     The highest shreds for each of the first `N` parents of the requested
-     `orphan`
+     `RequestOrphan(orphan)` request - `orphan` is the orphan slot that the requestor wants to know the parents of `RequestOrphan(orphan)` response - The highest shreds for each of the first `N` parents of the requested `orphan`
 
-     On receiving the responses `p`, where `p` is some shred in a parent slot,
-     validators will:
+     On receiving the responses `p`, where `p` is some shred in a parent slot, validators will:
 
-     * Insert an empty `SlotMeta` in blockstore for `p.slot` if it doesn't
-     already exist.
+     * Insert an empty `SlotMeta` in blocktree for `p.slot` if it doesn't already exist.
      * If `p.slot` does exist, update the parent of `p` based on `parents`
 
-     Note: that once these empty slots are added to blockstore, the
-     `Shred Repair` protocol should attempt to fill those slots.
+     Note: that once these empty slots are added to blocktree, the `Shred Repair` protocol should attempt to fill those slots.
 
-     Note: Validators will only accept responses containing shreds within the
-     current verifiable epoch \(epoch the validator has a leader schedule
-     for\).
+     Note: Validators will only accept responses containing shreds within the current verifiable epoch \(epoch the validator has a leader schedule for\).
+3. Repairmen \(Addresses Challenge \#3\): This part of the repair protocol is the primary mechanism by which new nodes joining the cluster catch up after loading a snapshot. This protocol works in a "forward" fashion, so validators can verify every shred that they receive against a known leader schedule.
 
-Validators should try to send orphan requests to validators who have marked that
-orphan as completed in their EpochSlots. If no such validators exist, then
-randomly select a validator in a stake-weighted fashion.
+   Each validator advertises in gossip:
 
-## Repair Response Protocol
+   * Current root
+   * The set of all completed slots in the confirmed epochs \(an epoch that was calculated based on a bank <= current root\) past the current root
 
-When a validator receives a request for a shred `S`, they respond with the
-shred if they have it. 
+     Observers of this gossip message with higher epochs \(repairmen\) send shreds to catch the lagging node up with the rest of the cluster. The repairmen are responsible for sending the slots within the epochs that are confrimed by the advertised `root` in gossip. The repairmen divide the responsibility of sending each of the missing slots in these epochs based on a random seed \(simple shred.index iteration by N, seeded with the repairman's node\_pubkey\). Ideally, each repairman in an N node cluster \(N nodes whose epochs are higher than that of the repairee\) sends 1/N of the missing shreds. Both data and coding shreds for missing slots are sent. Repairmen do not send shreds again to the same validator until they see the message in gossip updated, at which point they perform another iteration of this protocol.
 
-When a validator receives a shred through a repair response, they check
-`EpochSlots` to see if <= `1/3` of the network has marked this slot as
-completed. If so, they resubmit this shred through its associated turbine
-path, but only if this validator has not retransmitted this shred before.
+     Gossip messages are updated every time a validator receives a complete slot within the epoch. Completed slots are detected by blocktree and sent over a channel to RepairService. It is important to note that we know that by the time a slot X is complete, the epoch schedule must exist for the epoch that contains slot X because WindowService will reject shreds for unconfirmed epochs. When a newly completed slot is detected, we also update the current root if it has changed since the last update. The root is made available to RepairService through Blocktree, which holds the latest root.
 

book/src/implemented-proposals/staking-rewards.md

@@ -52,5 +52,5 @@ Solana's trustless sense of time and ordering provided by its PoH data structure
 
 As discussed in the [Economic Design](../implemented-proposals/ed_overview/) section, annual validator interest rates are to be specified as a function of total percentage of circulating supply that has been staked. The cluster rewards validators who are online and actively participating in the validation process throughout the entirety of their _validation period_. For validators that go offline/fail to validate transactions during this period, their annual reward is effectively reduced.
 
-Similarly, we may consider an algorithmic reduction in a validator's active amount staked amount in the case that they are offline. I.e. if a validator is inactive for some amount of time, either due to a partition or otherwise, the amount of their stake that is considered ‘active’ \(eligible to earn rewards\) may be reduced. This design would be structured to help long-lived partitions to eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a supermajority can be achieved by the active validators in each partition. Similarly, upon re-engaging, the ‘active’ amount staked will come back online at some defined rate. Different rates of stake reduction may be considered depending on the size of the partition/active set.
+Similarly, we may consider an algorithmic reduction in a validator's active amount staked amount in the case that they are offline. I.e. if a validator is inactive for some amount of time, either due to a partition or otherwise, the amount of their stake that is considered ‘active’ \(eligible to earn rewards\) may be reduced. This design would be structured to help long-lived partitions to eventually reach finality on their respective chains as the % of non-voting total stake is reduced over time until a super-majority can be achieved by the active validators in each partition. Similarly, upon re-engaging, the ‘active’ amount staked will come back online at some defined rate. Different rates of stake reduction may be considered depending on the size of the partition/active set.
 

book/src/implemented-proposals/tower-bft.md

@@ -2,7 +2,7 @@
 
 This design describes Solana's _Tower BFT_ algorithm. It addresses the following problems:
 
-* Some forks may not end up accepted by the supermajority of the cluster, and voters need to recover from voting on such forks.
+* Some forks may not end up accepted by the super-majority of the cluster, and voters need to recover from voting on such forks.
 * Many forks may be votable by different voters, and each voter may see a different set of votable forks. The selected forks should eventually converge for the cluster.
 * Reward based votes have an associated risk. Voters should have the ability to configure how much risk they take on.
 * The [cost of rollback](tower-bft.md#cost-of-rollback) needs to be computable. It is important to clients that rely on some measurable form of Consistency. The costs to break consistency need to be computable, and increase super-linearly for older votes.
@@ -12,7 +12,7 @@ For brevity this design assumes that a single voter with a stake is deployed as
 
 ## Time
 
-The Solana cluster generates a source of time via a Verifiable Delay Function we are calling [Proof of History](../cluster/synchronization.md).
+The Solana cluster generates a source of time via a Verifiable Delay Function we are calling [Proof of History](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/synchronization.md).
 
 Proof of History is used to create a deterministic round robin schedule for all the active leaders. At any given time only 1 leader, which can be computed from the ledger itself, can propose a fork. For more details, see [fork generation](../cluster/fork-generation.md) and [leader rotation](../cluster/leader-rotation.md).
 
@@ -109,7 +109,7 @@ When evaluating multiple forks, each validator should use the following rules:
 3. Pick the fork that has the greatest amount of cluster transaction fees.
 4. Pick the latest fork in terms of PoH.
 
-Cluster transaction fees are fees that are deposited to the mining pool as described in the [Staking Rewards](staking-rewards.md) section.
+Cluster transaction fees are fees that are deposited to the mining pool as described in the [Staking Rewards](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/staking-rewards.md) section.
 
 ## PoH ASIC Resistance
 
@@ -134,3 +134,4 @@ An attacker generates a concurrent fork from an older block to try to rollback t
 * 3 votes have a lockout of 8 slots. Concurrent fork must be at least 8 slots ahead and produced in 3 slots. Therefore requires an ASIC 2.6x faster.
 * 10 votes have a lockout of 1024 slots. 1024/10, or 102.4x faster ASIC.
 * 20 votes have a lockout of 2^20 slots. 2^20/20, or 52,428.8x faster ASIC.
+

book/src/implemented-proposals/validator-timestamp-oracle.md

@@ -84,7 +84,7 @@ let timestamp_slot = floor(current_slot / timestamp_interval);
 ```
 
 Then the validator needs to gather all Vote WithTimestamp transactions from the
-ledger that reference that slot, using `Blockstore::get_slot_entries()`. As these
+ledger that reference that slot, using `Blocktree::get_slot_entries()`. As these
 transactions could have taken some time to reach and be processed by the leader,
 the validator needs to scan several completed blocks after the timestamp\_slot to
 get a reasonable set of Timestamps. The exact number of slots will need to be

book/src/offline-signing/README.md

@@ -22,7 +22,7 @@ At present, the following commands support offline signing:
 
 To sign a transaction offline, pass the following arguments on the command line
 1) `--sign-only`, prevents the client from submitting the signed transaction
-to the network. Instead, the pubkey/signature pairs are printed to stdout.
+to the network. Instead, the pubkey/signature pairs are printed to stdout. 
 2) `--blockhash BASE58_HASH`, allows the caller to specify the value used to
 fill the transaction's `recent_blockhash` field. This serves a number of
 purposes, namely:
@@ -37,7 +37,7 @@ Command
 
 ```bash
 solana@offline$ solana pay --sign-only --blockhash 5Tx8F3jgSHx21CbtjwmdaKPLM5tWmreWAnPrbqHomSJF \
-    recipient-keypair.json 1
+    recipient-keypair.json 1 SOL
 ```
 
 Output
@@ -67,7 +67,7 @@ Command
 ```bash
 solana@online$ solana pay --blockhash 5Tx8F3jgSHx21CbtjwmdaKPLM5tWmreWAnPrbqHomSJF \
     --signer FhtzLVsmcV7S5XqGD79ErgoseCLhZYmEZnz9kQg1Rp7j=4vC38p4bz7XyiXrk6HtaooUqwxTWKocf45cstASGtmrD398biNJnmTcUCVEojE7wVQvgdYbjHJqRFZPpzfCQpmUN
-    recipient-keypair.json 1
+    recipient-keypair.json 1 SOL
 ```
 
 Output
@@ -75,11 +75,3 @@ Output
 ```text
 4vC38p4bz7XyiXrk6HtaooUqwxTWKocf45cstASGtmrD398biNJnmTcUCVEojE7wVQvgdYbjHJqRFZPpzfCQpmUN
 ```
-
-## Buying More Time to Sign
-
-Typically a Solana transaction must be signed and accepted by the network within
-a number of slots from the blockhash in its `recent_blockhash` field (~2min at
-the time of this writing). If your signing procedure takes longer than this, a
-[Durable Transaction Nonce](durable-nonce.md) can give you the extra time you
-need.

book/src/offline-signing/durable-nonce.md

@@ -1,263 +0,0 @@
-# Durable Transaction Nonces
-
-Durable transaction nonces are a mechanism for getting around the typical
-short lifetime of a transaction's [`recent_blockhash`](../transaction.md#recent-blockhash).
-They are implemented as a Solana Program, the mechanics of which can be read
-about in the [proposal](../implemented-proposals/durable-tx-nonces.md).
-
-## Usage Examples
-
-Full usage details for durable nonce CLI commands can be found in the
-[CLI reference](../api-reference/cli.md).
-
-### Nonce Authority
-
-Authority over a nonce account can optionally be assigned to another account. In
-doing so the new authority inherits full control over the nonce account from the
-previous authority, including the account creator. This feature enables the
-creation of more complex account ownership arrangements and derived account
-addresses not associated with a keypair. The `--nonce-authority <AUTHORITY_KEYPAIR>`
-argument is used to specify this account and is supported by the following
-commands
-* `create-nonce-account`
-* `new-nonce`
-* `withdraw-from-nonce-account`
-* `authorize-nonce-account`
-
-### Nonce Account Creation
-
-The durable transaction nonce feature uses an account to store the next nonce
-value.  Durable nonce accounts must be [rent-exempt](../implemented-proposals/rent.md#two-tiered-rent-regime),
-so need to carry the minimum balance to achieve this.
-
-A nonce account is created by first generating a new keypair, then create the account on chain
-
-- Command
-
-```bash
-solana-keygen new -o nonce-keypair.json
-solana create-nonce-account nonce-keypair.json 1
-```
-
-- Output
-
-```text
-2SymGjGV4ksPdpbaqWFiDoBz8okvtiik4KE9cnMQgRHrRLySSdZ6jrEcpPifW4xUpp4z66XM9d9wM48sA7peG2XL
-```
-
-{% hint style="info" %}
-To keep the keypair entirely offline, use the [Paper Wallet](../paper-wallet/README.md)
-keypair generation [instructions](../paper-wallet/usage.md#seed-phrase-generation.md)
-instead
-{% endhint %}
-
-{% hint style="info" %}
-[Full usage documentation](../api-reference/cli.md#solana-create-nonce-account)
-{% endhint %}
-
-### Querying the Stored Nonce Value
-
-Creating a durable nonce transaction requires passing the stored nonce value as
-the value to the `--blockhash` argument upon signing and submission. Obtain the
-presently stored nonce value with
-
-- Command
-
-```bash
-solana nonce nonce-keypair.json
-```
-
-- Output
-
-```text
-8GRipryfxcsxN8mAGjy8zbFo9ezaUsh47TsPzmZbuytU
-```
-
-{% hint style="info" %}
-[Full usage documentation](../api-reference/cli.md#solana-get-nonce)
-{% endhint %}
-
-### Advancing the Stored Nonce Value
-
-While not typically needed outside a more useful transaction, the stored nonce
-value can be advanced by
-
-- Command
-
-```bash
-solana new-nonce nonce-keypair.json
-```
-
-- Output
-
-```text
-44jYe1yPKrjuYDmoFTdgPjg8LFpYyh1PFKJqm5SC1PiSyAL8iw1bhadcAX1SL7KDmREEkmHpYvreKoNv6fZgfvUK
-```
-
-{% hint style="info" %}
-[Full usage documentation](../api-reference/cli.md#solana-new-nonce)
-{% endhint %}
-
-### Display Nonce Account
-
-Inspect a nonce account in a more human friendly format with
-
-- Command
-
-```bash
-solana nonce-account nonce-keypair.json
-```
-
-- Output
-
-```text
-balance: 0.5 SOL
-minimum balance required: 0.00136416 SOL
-nonce: DZar6t2EaCFQTbUP4DHKwZ1wT8gCPW2aRfkVWhydkBvS
-```
-
-{% hint style="info" %}
-[Full usage documentation](../api-reference/cli.md#solana-nonce-account)
-{% endhint %}
-
-### Withdraw Funds from a Nonce Account
-
-Withdraw funds from a nonce account with
-
-- Command
-
-```bash
-solana withdraw-from-nonce-account nonce-keypair.json ~/.config/solana/id.json 0.5
-```
-
-- Output
-
-```text
-3foNy1SBqwXSsfSfTdmYKDuhnVheRnKXpoPySiUDBVeDEs6iMVokgqm7AqfTjbk7QBE8mqomvMUMNQhtdMvFLide
-```
-
-{% hint style="info" %}
-Close a nonce account by withdrawing the full balance
-{% endhint %}
-
-{% hint style="info" %}
-[Full usage documentation](../api-reference/cli.md#solana-withdraw-from-nonce-account)
-{% endhint %}
-
-### Assign a New Authority to a Nonce Account
-
-Reassign the authority of a nonce account after creation with
-
-- Command
-
-```bash
-solana authorize-nonce-account nonce-keypair.json nonce-authority.json
-```
-
-- Output
-
-```text
-3F9cg4zN9wHxLGx4c3cUKmqpej4oa67QbALmChsJbfxTgTffRiL3iUehVhR9wQmWgPua66jPuAYeL1K2pYYjbNoT
-```
-
-{% hint style="info" %}
-[Full usage documentation](../api-reference/cli.md#solana-authorize-nonce-account)
-{% endhint %}
-
-## Other Commands Supporting Durable Nonces
-
-To make use of durable nonces with other CLI subcommands, two arguments must be
-supported.
-* `--nonce`, specifies the account storing the nonce value
-* `--nonce-authority`, specifies an optional [nonce authority](#nonce-authority)
-
-The following subcommands have received this treatment so far
-* [`pay`](../api-reference/cli.md#solana-pay)
-* [`delegate-stake`](../api-reference/cli.md#solana-delegate-stake)
-* [`deactivate-stake`](../api-reference/cli.md#solana-deactivate-stake)
-
-### Example Pay Using Durable Nonce
-
-Here we demonstrate Alice paying Bob 1 SOL using a durable nonce. The procedure
-is the same for all subcommands supporting durable nonces
-
-#### - Create accounts
-
-First we need some accounts for Alice, Alice's nonce and Bob
-
-```bash
-$ solana-keygen new -o alice.json
-$ solana-keygen new -o nonce.json
-$ solana-keygen new -o bob.json
-```
-
-#### - Fund Alice's account
-
-Alice will need some funds to create a nonce account and send to Bob. Airdrop
-her some SOL
-
-```bash
-$ solana airdrop -k alice.json 10
-10 SOL
-```
-
-#### - Create Alice's nonce account
-
-Now Alice needs a nonce account. Create one
-
-{% hint style="info" %}
-Here, no separate [nonce authority](#nonce-authority) is employed, so `alice.json`
-has full authority over the nonce account
-{% endhint %}
-
-```bash
-$ solana create-nonce-account -k alice.json nonce.json 1
-3KPZr96BTsL3hqera9up82KAU462Gz31xjqJ6eHUAjF935Yf8i1kmfEbo6SVbNaACKE5z6gySrNjVRvmS8DcPuwV
-```
-
-#### - A failed first attempt to pay Bob
-
-Alice attempts to pay Bob, but takes too long to sign. The specified blockhash
-expires and the transaction fails
-
-```bash
-$ solana pay -k alice.json --blockhash expiredDTaxfagttWjQweib42b6ZHADSx94Tw8gHx3W7 bob.json 1
-[2020-01-02T18:48:28.462911000Z ERROR solana_cli::cli] Io(Custom { kind: Other, error: "Transaction \"33gQQaoPc9jWePMvDAeyJpcnSPiGUAdtVg8zREWv4GiKjkcGNufgpcbFyRKRrA25NkgjZySEeKue5rawyeH5TzsV\" failed: None" })
-Error: Io(Custom { kind: Other, error: "Transaction \"33gQQaoPc9jWePMvDAeyJpcnSPiGUAdtVg8zREWv4GiKjkcGNufgpcbFyRKRrA25NkgjZySEeKue5rawyeH5TzsV\" failed: None" })
-```
-
-#### - Nonce to the rescue!
-
-Alice retries the transaction, this time specifying her nonce account and the
-blockhash stored there
-
-{% hint style="info" %}
-Remember, `alice.json` is the [nonce authority](#nonce-authority) in this example
-{% endhint %}
-
-```bash
-$ solana nonce-account nonce.json
-balance: 1 SOL
-minimum balance required: 0.00136416 SOL
-nonce: F7vmkY3DTaxfagttWjQweib42b6ZHADSx94Tw8gHx3W7
-```
-```bash
-$ solana pay -k alice.json --blockhash F7vmkY3DTaxfagttWjQweib42b6ZHADSx94Tw8gHx3W7 --nonce nonce.json bob.json 1
-HR1368UKHVZyenmH7yVz5sBAijV6XAPeWbEiXEGVYQorRMcoijeNAbzZqEZiH8cDB8tk65ckqeegFjK8dHwNFgQ
-```
-
-#### - Success!
-
-The transaction succeeds!  Bob receives 1 SOL from Alice and Alice's stored
-nonce advances to a new value
-
-```bash
-$ solana balance -k bob.json
-1 SOL
-```
-```bash
-$ solana nonce-account nonce.json
-balance: 1 SOL
-minimum balance required: 0.00136416 SOL
-nonce: 6bjroqDcZgTv6Vavhqf81oBHTv3aMnX19UTB51YhAZnN
-```

book/src/paper-wallet/installation.md

@@ -2,7 +2,7 @@
 Follow this guide to setup Solana's key generation tool called `solana-keygen`
 
 {% hint style="warn" %}
-After installation, ensure your version is `0.23.1` or higher by running `solana-keygen -V`
+After installation, ensure your version is `0.21.1` or higher by running `solana-keygen -V`
 {% endhint %}
 
 ## Download

book/src/paper-wallet/usage.md

@@ -30,10 +30,6 @@ command will generate a random seed phrase, ask you to enter an optional
 passphrase, and then will display the derived public key and the generated seed
 phrase for your paper wallet.
 
-After copying down your seed phrase, you can use the
-[public key derivation](#public-key-derivation) instructions to verify that you
-have not made any errors.
-
 ```bash
 solana-keygen new --no-outfile
 ```
@@ -94,91 +90,6 @@ For full usage details run:
 ```bash
 solana-keygen pubkey --help
 ```
-
-## Verifying the Keypair
-
-A keypair can be verified by following a variation on the
-[offline signing](../offline-signing/README.md) procedure with a dummy transaction.
-
-### Create and Sign a Dummy Transaction
-
-Use offline signing to acquire the signature of a dummy transaction that can
-be verified in the next step. A 0 Lamport [transfer](../cli/usage.md#solana-transfer)
-is used to prevent inadvertent loss of funds. Additionally, an improbable _blockhash_
-value is specified, as well as using the address of the _system program_ for the `TO`
-argument, to ensure the transaction would be rejected by the _cluster_ should
-it be submitted in error.
-
-Command
-
-```text
-solana transfer 11111111111111111111111111111111 0 --sign-only \
-    --ask-seed-phrase keypair --blockhash 11111111111111111111111111111111
-```
-
-Prompt for seed phrase
-
-```text
-[keypair] seed phrase:
-[keypair] If this seed phrase has an associated passphrase, enter it now. Otherwise, press ENTER to continue:
-Recovered pubkey `AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi`. Continue? (y/n): y
-```
-
-Output
-
-```text
-Blockhash: 11111111111111111111111111111111
-Signers (Pubkey=Signature):
-  AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi=3uZndChSmPoYfaCihC993E7EAHKDsuu53Ge6Dk1K6ULwhJkgcgiHNm9J1Geqq2azW6PKxQTFjC8rMm5bGxRcYWA
-
-{"blockhash":"11111111111111111111111111111111","signers":["AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi=3uZndChSmPoYfaCihC993E7EAHKDsuu53Ge6Dk1K6ULwhJkgcgiHNm9J1Geqq2azW6PKxQTFjC8rMm5bGxRcYWA"]}
-```
-
-### Verify the Signature
-
-Using the _Signers_ output from the [previous step](#create-and-sign-a-dummy-transaction)
-to reconstruct the transaction, this time specifying the _pubkey_ and _signature_
-as in the submission step of [offline signing](../offline-signing/README.md). That is, the `--from` and
-`--fee-payer` are explicitly set to the _pubkey_ rather than being taken from
-the keypair (which is not queried this time).
-
-Command
-
-```text
-solana transfer 11111111111111111111111111111111 0 --sign-only --from AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi \
---signer AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi=3uZndChSmPoYfaCihC993E7EAHKDsuu53Ge6Dk1K6ULwhJkgcgiHNm9J1Geqq2azW6PKxQTFjC8rMm5bGxRcYWA \
---blockhash 11111111111111111111111111111111 --fee-payer AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi
-```
-
-Output
-
-```text
-Blockhash: 11111111111111111111111111111111
-Signers (Pubkey=Signature):
-  AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi=3uZndChSmPoYfaCihC993E7EAHKDsuu53Ge6Dk1K6ULwhJkgcgiHNm9J1Geqq2azW6PKxQTFjC8rMm5bGxRcYWA
-
-{"blockhash":"11111111111111111111111111111111","signers":["AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi=3uZndChSmPoYfaCihC993E7EAHKDsuu53Ge6Dk1K6ULwhJkgcgiHNm9J1Geqq2azW6PKxQTFjC8rMm5bGxRcYWA"]}
-```
-
-### An Example of Failure
-
-To simulate an error the [verification step](#verify-the-signature) is repeated,
-but with a corrupted _signature_ (the last letter is changed from "A" to "B").
-
-Command
-
-```text
-solana transfer 11111111111111111111111111111111 0 --sign-only --from AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi \
---signer AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi=3uZndChSmPoYfaCihC993E7EAHKDsuu53Ge6Dk1K6ULwhJkgcgiHNm9J1Geqq2azW6PKxQTFjC8rMm5bGxRcYWB \
---blockhash 11111111111111111111111111111111 --fee-payer AjTz9EX6vXB6EboKpFm7SwrbDannb6icjvEE632D3rfi
-```
-
-Output (Error)
-
-```text
-Error: BadParameter("Transaction construction failed, incorrect signature or public key provided")
-```
-
 ## Checking Account Balance
 
 All that is needed to check an account balance is the public key of an account.
@@ -191,7 +102,7 @@ networked machine.
 Next, configure the `solana` CLI tool to connect to a particular cluster:
 
 ```bash
-solana config set --url <CLUSTER URL> # (i.e. http://devnet.solana.com:8899)
+solana set --url <CLUSTER URL> # (i.e. http://testnet.solana.com:8899)
 ```
 
 Finally, to check the balance, run the following command:
@@ -251,10 +162,10 @@ Refer to the following page for a comprehensive guide on running a validator:
 Solana CLI tooling supports secure keypair input for stake delegation. To do so,
 first create a stake account with some SOL. Use the special `ASK` keyword to
 trigger a seed phrase input prompt for the stake account and use
-`--keypair ASK` to securely input the funding keypair.
+`--ask-seed-phrase keypair` to securely input the funding keypair.
 
 ```bash
-solana create-stake-account ASK 1 --keypair ASK
+solana create-stake-account ASK 1 SOL --ask-seed-phrase keypair
 
 [stake_account] seed phrase: 🔒
 [stake_account] If this seed phrase has an associated passphrase, enter it now. Otherwise, press ENTER to continue:
@@ -262,11 +173,11 @@ solana create-stake-account ASK 1 --keypair ASK
 [keypair] If this seed phrase has an associated passphrase, enter it now. Otherwise, press ENTER to continue:
 ```
 
-Then, to delegate that stake to a validator, use `--keypair ASK` to
+Then, to delegate that stake to a validator, use `--ask-seed-phrase keypair` to
 securely input the funding keypair.
 
 ```bash
-solana delegate-stake --keypair ASK <STAKE_ACCOUNT_PUBKEY> <VOTE_ACCOUNT_PUBKEY>
+solana delegate-stake --ask-seed-phrase keypair <STAKE_ACCOUNT_PUBKEY> <VOTE_ACCOUNT_PUBKEY>
 
 [keypair] seed phrase: 🔒
 [keypair] If this seed phrase has an associated passphrase, enter it now. Otherwise, press ENTER to continue:

book/src/programs/README.md

@@ -1,20 +1,6 @@
 # Programming Model
 
-An _app_ interacts with a Solana cluster by sending it _transactions_ with one or more _instructions_. The Solana _runtime_ passes those instructions to user-contributed _programs_. An instruction might, for example, tell a program to transfer _lamports_ from one _account_ to another or create an interactive contract that governs how lamports are transfered. Instructions are executed sequentially and atomically. If any instruction is invalid, any changes made within the transaction are discarded.
-
-### Accounts and Signatures
-
-Each transaction explicitly lists all account public keys referenced by the transaction's instructions. A subset of those public keys are each accompanied by a transaction signature. Those signatures signal on-chain programs that the account holder has authorized the transaction. Typically, the program uses the authorization to permit debiting the account or modifying its data.
-
-The transaction also marks some accounts as _read-only accounts_. The runtime permits read-only accounts to be read concurrently. If a program attempts to modify a read-only account, the transaction is rejected by the runtime.
-
-### Recent Blockhash
-
-A Transaction includes a recent blockhash to prevent duplication and to give transactions lifetimes. Any transaction that is completely identical to a previous one is rejected, so adding a newer blockhash allows multiple transactions to repeat the exact same action. Transactions also have lifetimes that are defined by the blockhash, as any transaction whose blockhash is too old will be rejected.
-
-### Instructions
-
-Each instruction specifies a single program account \(which must be marked executable\), a subset of the transaction's accounts that should be passed to the program, and a data byte array instruction that is passed to the program. The program interprets the data array and operates on the accounts specified by the instructions. The program can return successfully, or with an error code. An error return causes the entire transaction to fail immediately.
+A client _app_ interacts with a Solana cluster by sending it _transactions_ with one or more _instructions_. The Solana _runtime_ passes those instructions to user-contributed _programs_. An instruction might, for example, tell a program to transfer _lamports_ from one _account_ to another or create an interactive contract that governs how lamports are transfered. Instructions are executed atomically. If any instruction is invalid, any changes made within the transaction are discarded.
 
 ## Deploying Programs to a Cluster
 

book/src/programs/drones.md

@@ -16,8 +16,6 @@ Creator of on-chain game tic-tac-toe hosts a drone that responds to airdrop requ
 
 Creator of a new on-chain token \(ERC-20 interface\), may wish to do a worldwide airdrop to distribute its tokens to millions of users over just a few seconds. That drone cannot spend resources interacting with the Solana cluster. Instead, the drone should only verify the client is unique and human, and then return the signature. It may also want to listen to the Solana cluster for recent entry IDs to support client retries and to ensure the airdrop is targeting the desired cluster.
 
-Note: the Solana cluster will not parallelize transactions funded by the same fee-paying account. This means that the max throughput of a single fee-paying account is limited to the number of _ticks_ processed per second by the current leader. Add additional fee-paying accounts to improve throughput.
-
 ## Attack vectors
 
 ### Invalid recent\_blockhash

book/src/proposals/abi-management.md

@@ -1,90 +0,0 @@
-# Solana ABI management process
-
-This document proposes the Solana ABI management process. The ABI management
-process is an engineering practice and a supporting technical framework to avoid
-introducing unintended incompatible ABI changes.
-
-# Problem
-
-The Solana ABI (binary interface to the cluster) is currently only defined
-implicitly by the implementation and requires a very careful eye to notice
-breaking changes. This makes it extremely difficult to upgrade the software
-on an existing cluster without rebooting the ledger.
-
-# Requirements and objectives
-
-- Unintended ABI changes can be detected as CI failures mechanically.
-- Newer implementation must be able to process the oldest data (since genesis)
-  once we go mainnet.
-- The objective of this proposal is to protect the ABI while sustaining rather
-  rapid development by opting for a mechanical process rather than a very long
-  human-driven auditing process.
-- Once signed cryptographically, data blob must be identical, so no
-  in-place data format update is possible regardless of inbound and outbound of
-  the online system. Also, considering the sheer volume of transactions we're
-  aiming to handle, retrospective in-place update is undesirable at best.
-
-# Solution
-
-Instead of natural human's eye due-diligence, which should be assumed to fail
-regularly, we need a systematic assurance of not breaking the cluster when
-changing the source code.
-
-For that purpose, we introduce a mechanism of marking every ABI-related things
-in source code (`struct`s, `enum`s) with the new `#[frozen_abi]` attribute. This
-takes hard-coded digest value derived from types of its fields via
-`ser::Serialize`. And the attribute automatically generates a unit test to try
-to detect any unsanctioned changes to the marked ABI-related things.
-
-However, the detection cannot be complete; no matter how hard we statically
-analyze the source code, it's still possible to break ABI. For example, this
-includes not-`derive`d hand-written `ser::Serialize`, underlying library's
-implementation changes (for example `bincode`), CPU architecture differences.
-The detection of these possible ABI incompatibilities is out-of-scope for this
-ABI management.
-
-# Definitions
-
-ABI item/type: various types to be used for serialization, which collectively
-comprises the whole ABI for any system components. For example, those types
-include `struct`s and `enum`s.
-
-ABI item digest: Some fixed hash derived from type information of ABI item's
-fields.
-
-# Example
-
-```patch
-+#[frozen_abi(digest="1c6a53e9")]
- #[derive(Serialize, Default, Deserialize, Debug, PartialEq, Eq, Clone)]
- pub struct Vote {
-     /// A stack of votes starting with the oldest vote
-     pub slots: Vec<Slot>,
-     /// signature of the bank's state at the last slot
-     pub hash: Hash,
- }
-```
-
-# Developer's workflow
-
-To know the digest for new ABI items, developers can add `frozen_abi` with a
-random digest value and run the unit tests and replace it with the correct
-digest from the assertion test error message.
-
-In general, once we add `frozen_abi` and its change is published in the stable
-release channel, its digest should never change. If such a change is needed, we
-should opt for defining a new struct like `FooV1`. And special release flow like
-hard forks should be approached.
-
-# Implementation remarks
-
-We use some degree of macro machinery to automatically generate unit tests
-and calculate a digest from ABI items. This is doable by clever use of
-`serde::Serialize` ([1]) and `any::typename` ([2]). For a precedent for similar
-implementation, `ink` from the Parity Technologies [3] could be informational.
-
-# References
-
-1. [(De)Serialization with type info · Issue #1095 · serde-rs/serde](https://github.com/serde-rs/serde/issues/1095#issuecomment-345483479)
-2. [`std::any::type_name` - Rust](https://doc.rust-lang.org/std/any/fn.type_name.html)
-3. [Parity's ink to write smart contracts](https://github.com/paritytech/ink)

book/src/proposals/bankless-leader.md

@@ -10,7 +10,7 @@ When replay stage starts processing the same transactions, it can assume that Po
 
 ## Fee Account
 
-The [fee account](../terminology.md#fee_account) pays for the transaction to be included in the block. The leader only needs to validate that the fee account has the balance to pay for the fee.
+The [fee account](https://github.com/solana-labs/solana/tree/b5f7a4bff9953415b1f3d385bd59bc65c1ec11a4/book/src/proposals/terminology.md#fee_account) pays for the transaction to be included in the block. The leader only needs to validate that the fee account has the balance to pay for the fee.
 
 ## Balance Cache
 
@@ -53,3 +53,4 @@ The same fee account can be reused many times in the same block until it is used
 Clients that transmit a large number of transactions per second should use a dedicated fee account that is not used as Credit-Debit in any instruction.
 
 Once an account fee is used as Credit-Debit, it will fail the balance check until the balance cache is reset.
+

book/src/proposals/cluster-test-framework.md

@@ -22,7 +22,7 @@ Each CTF test starts with an opaque entry point and a funded keypair. The test s
 
 ```text
 use crate::contact_info::ContactInfo;
-use solana_sdk::signature::{Keypair, Signer};
+use solana_sdk::signature::{Keypair, KeypairUtil};
 pub fn test_this_behavior(
     entry_point_info: &ContactInfo,
     funding_keypair: &Keypair,

book/src/proposals/simple-payment-and-state-verification.md

@@ -1,108 +1,74 @@
 # Simple Payment and State Verification
 
-It is often useful to allow low resourced clients to participate in a Solana
-cluster. Be this participation economic or contract execution, verification
-that a client's activity has been accepted by the network is typically
-expensive. This proposal lays out a mechanism for such clients to confirm that
-their actions have been committed to the ledger state with minimal resource
-expenditure and third-party trust.
+It is often useful to allow low resourced clients to participate in a Solana cluster. Be this participation economic or contract execution, verification that a client's activity has been accepted by the network is typically expensive. This proposal lays out a mechanism for such clients to confirm that their actions have been committed to the ledger state with minimal resource expenditure and third-party trust.
 
 ## A Naive Approach
 
-Validators store the signatures of recently confirmed transactions for a short
-period of time to ensure that they are not processed more than once. Validators
-provide a JSON RPC endpoint, which clients can use to query the cluster if a
-transaction has been recently processed. Validators also provide a PubSub
-notification, whereby a client registers to be notified when a given signature
-is observed by the validator. While these two mechanisms allow a client to
-verify a payment, they are not a proof and rely on completely trusting a
-validator.
+Validators store the signatures of recently confirmed transactions for a short period of time to ensure that they are not processed more than once. Validators provide a JSON RPC endpoint, which clients can use to query the cluster if a transaction has been recently processed. Validators also provide a PubSub notification, whereby a client registers to be notified when a given signature is observed by the validator. While these two mechanisms allow a client to verify a payment, they are not a proof and rely on completely trusting a validator.
 
-We will describe a way to minimize this trust using Merkle Proofs to anchor the
-validator's response in the ledger, allowing the client to confirm on their own
-that a sufficient number of their preferred validators have confirmed a
-transaction. Requiring multiple validator attestations further reduces trust in
-the validator, as it increases both the technical and economic difficulty of
-compromising several other network participants.
+We will describe a way to minimize this trust using Merkle Proofs to anchor the validator's response in the ledger, allowing the client to confirm on their own that a sufficient number of their preferred validators have confirmed a transaction. Requiring multiple validator attestations further reduces trust in the validator, as it increases both the technical and economic difficulty of compromising several other network participants.
 
 ## Light Clients
 
-A 'light client' is a cluster participant that does not itself run a validator.
-This light client would provide a level of security greater than trusting a
-remote validator, without requiring the light client to spend a lot of resources
-verifying the ledger.
+A 'light client' is a cluster participant that does not itself run a validator. This light client would provide a level of security greater than trusting a remote validator, without requiring the light client to spend a lot of resources verifying the ledger.
 
-Rather than providing transaction signatures directly to a light client, the
-validator instead generates a Merkle Proof from the transaction of interest to
-the root of a Merkle Tree of all transactions in the including block. This
-Merkle Root is stored in a ledger entry which is voted on by validators,
-providing it consensus legitimacy. The additional level of security for a light
-client depends on an initial canonical set of validators the light client
-considers to be the stakeholders of the cluster. As that set is changed, the
-client can update its internal set of known validators with
-[receipts](simple-payment-and-state-verification.md#receipts). This may become
-challenging with a large number of delegated stakes.
+Rather than providing transaction signatures directly to a light client, the validator instead generates a Merkle Proof from the transaction of interest to the root of a Merkle Tree of all transactions in the including block. This Merkle Root is stored in a ledger entry which is voted on by validators, providing it consensus legitimacy. The additional level of security for a light client depends on an initial canonical set of validators the light client considers to be the stakeholders of the cluster. As that set is changed, the client can update its internal set of known validators with [receipts](simple-payment-and-state-verification.md#receipts). This may become challenging with a large number of delegated stakes.
 
-Validators themselves may want to use light client APIs for performance reasons.
-For example, during the initial launch of a validator, the validator may use a
-cluster provided checkpoint of the state and verify it with a receipt.
+Validators themselves may want to use light client APIs for performance reasons. For example, during the initial launch of a validator, the validator may use a cluster provided checkpoint of the state and verify it with a receipt.
 
 ## Receipts
 
-A receipt is a minimal proof that; a transaction has been included in a block,
-that the block has been voted on by the client's preferred set of validators
-and that the votes have reached the desired confirmation depth.
+A receipt is a minimal proof that; a transaction has been included in a block, that the block has been voted on by the client's preferred set of validators and that the votes have reached the desired confirmation depth.
 
-### Transaction Inclusion Proof
+The receipts for both state and payments start with a Merkle Path from the value into a Bank-Merkle that has been voted on and included in the ledger. A chain of PoH Entries containing subsequent validator votes, deriving from the Bank-Merkle, is the confirmation proof.
 
-A transaction inclusion proof is a data structure that contains a Merkle Path
-from a transaction, through an Entry-Merkle to a Block-Merkle, which is included
-in a Bank-Hash with the required set of validator votes. A chain of PoH Entries
-containing subsequent validator votes, deriving from the Bank-Hash, is the proof
-of confirmation. Clients can examine this ledger data and compute finality using
-Solana's fork selection rules.
+Clients can examine this ledger data and compute the finality using Solana's fork selection rules.
 
-An Entry-Merkle is a Merkle Root including all transactions in a given entry,
-sorted by signature.
+### Payment Merkle Path
 
-A Block-Merkle is the Merkle Root of all the Entry-Merkles sequenced in the block.
+A payment receipt is a data structure that contains a Merkle Path from a transaction to the required set of validator votes.
+
+An Entry-Merkle is a Merkle Root including all transactions in the entry, sorted by signature.
 
 ![Block Merkle Diagram](../.gitbook/assets/spv-block-merkle.svg)
 
-A Bank-Hash is the hash of the concatenation of the Block-Merkle and Accounts-Hash
+A Block-Merkle is a Merkle root of all the Entry-Merkles sequenced in the block. Transaction status is necessary for the receipt because the state receipt is constructed for the block. Two transactions over the same state can appear in the block, and therefore, there is no way to infer from just the state whether a transaction that is committed to the ledger has succeeded or failed in modifying the intended state. It may not be necessary to encode the full status code, but a single status bit to indicate the transaction's success.
 
-<img alt="Bank Hash Diagram" src="img/spv-bank-hash.svg" class="center"/>
+### State Merkle Path
 
-An Accounts-Hash is the hash of the concatentation of the state hashes of each
-account modified during the current slot.
+A state receipt provides a confirmation that a specific state is committed at the end of the block. Inter-block state transitions do not generate a receipt.
 
-Transaction status is necessary for the receipt because the state receipt is
-constructed for the block. Two transactions over the same state can appear in
-the block, and therefore, there is no way to infer from just the state whether
-a transaction that is committed to the ledger has succeeded or failed in
-modifying the intended state. It may not be necessary to encode the full status
-code, but a single status bit to indicate the transaction's success.
+For example:
 
-### Account State Verification
+* A sends 5 Lamports to B
+* B spends 5 Lamports
+* C sends 5 Lamports to A
 
-An account's state (balance or other data) can be verified by submitting a
-transaction with a ___TBD___ Instruction to the cluster. The client can then
-use a [Transaction Inclusion Proof](#transaction-inclusion-proof) to verify
-whether the cluster agrees that the acount has reached the expected state.
+At the end of the block, A and B are in the exact same starting state, and any state receipt would point to the same value for A or B.
+
+The Bank-Merkle is computed from the Merkle Tree of the new state changes, along with the Previous Bank-Merkle, and the Block-Merkle.
+
+![Bank Merkle Diagram](../.gitbook/assets/spv-bank-merkle.svg)
+
+A state receipt contains only the state changes occurring in the block. A direct Merkle Path to the current Bank-Merkle guarantees the state value at that bank hash, but it cannot be used to generate a “current” receipt to the latest state if the state modification occurred in some previous block. There is no guarantee that the path provided by the validator is the latest one available out of all the previous Bank-Merkles.
+
+Clients that want to query the chain for a receipt of the "latest" state would need to create a transaction that would update the Merkle Path for that account, such as a credit of 0 Lamports.
 
 ### Validator Votes
 
-Leaders should coalesce the validator votes by stake weight into a single entry.
-This will reduce the number of entries necessary to create a receipt.
+Leaders should coalesce the validator votes by stake weight into a single entry. This will reduce the number of entries necessary to create a receipt.
 
 ### Chain of Entries
 
-A receipt has a PoH link from the payment or state Merkle Path root to a list
-of consecutive validation votes.
+A receipt has a PoH link from the payment or state Merkle Path root to a list of consecutive validation votes.
 
 It contains the following:
 
-* Transaction -&gt; Entry-Merkle -&gt; Block-Merkle -&gt; Bank-Hash
+* State -&gt; Bank-Merkle
+
+  or
+
+* Transaction -&gt; Entry-Merkle -&gt; Block-Merkle -&gt; Bank-Merkle
 
 And a vector of PoH entries:
 
@@ -123,33 +89,21 @@ LightEntry {
 }
 ```
 
-The light entries are reconstructed from Entries and simply show the entry
-Merkle Root that was mixed in to the PoH hash, instead of the full transaction
-set.
+The light entries are reconstructed from Entries and simply show the entry Merkle Root that was mixed in to the PoH hash, instead of the full transaction set.
 
-Clients do not need the starting vote state. The
-[fork selection](../implemented-proposals/tower-bft.md) algorithm is defined
-such that only votes that appear after the transaction provide finality for the
-transaction, and finality is independent of the starting state.
+Clients do not need the starting vote state. The [fork selection](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/fork-selection.md) algorithm is defined such that only votes that appear after the transaction provide finality for the transaction, and finality is independent of the starting state.
 
 ### Verification
 
-A light client that is aware of the supermajority set validators can verify a
-receipt by following the Merkle Path to the PoH chain. The Block-Merkle is the
-Merkle Root and will appear in votes included in an Entry. The light client can
-simulate [fork selection](../implemented-proposals/tower-bft.md) for the
-consecutive votes and verify that the receipt is confirmed at the desired
-lockout threshold.
+A light client that is aware of the supermajority set validators can verify a receipt by following the Merkle Path to the PoH chain. The Bank-Merkle is the Merkle Root and will appear in votes included in an Entry. The light client can simulate [fork selection](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/book/src/fork-selection.md) for the consecutive votes and verify that the receipt is confirmed at the desired lockout threshold.
 
 ### Synthetic State
 
-Synthetic state should be computed into the Bank-Hash along with the bank
-generated state.
+Synthetic state should be computed into the Bank-Merkle along with the bank generated state.
 
 For example:
 
 * Epoch validator accounts and their stakes and weights.
 * Computed fee rates
 
-These values should have an entry in the Bank-Hash. They should live under known
-accounts, and therefore have an index into the hash concatenation.
+These values should have an entry in the Bank-Merkle. They should live under known accounts, and therefore have an exact address in the Merkle Path.

book/src/proposals/tick_verification.md

@@ -28,17 +28,17 @@ slashing proof to punish this bad behavior.
 2) Otherwise, we can simply mark the slot as dead and not playable. A slashing
 proof may or may not be necessary depending on feasibility.
 
-# Blockstore receiving shreds
+# Blocktree receiving shreds
 
-When blockstore receives a new shred `s`, there are two cases:
+When blocktree receives a new shred `s`, there are two cases:
 
 1) `s` is marked as `LAST_SHRED_IN_SLOT`, then check if there exists a shred 
-`s'` in blockstore for that slot where `s'.index > s.index` If so, together `s`
+`s'` in blocktree for that slot where `s'.index > s.index` If so, together `s`
 and `s'` constitute a slashing proof.
 
-2) Blockstore has already received a shred `s'` marked as `LAST_SHRED_IN_SLOT`
+2) Blocktree has already received a shred `s'` marked as `LAST_SHRED_IN_SLOT`
 with index `i`. If `s.index > i`, then together `s` and `s'`constitute a 
-slashing proof. In this case, blockstore will also not insert `s`.
+slashing proof. In this case, blocktree will also not insert `s`.
 
 3) Duplicate shreds for the same index are ignored. Non-duplicate shreds for
 the same index are a slashable condition. Details for this case are covered
@@ -47,7 +47,7 @@ in the `Leader Duplicate Block Slashing` section.
 
 # Replaying and validating ticks
 
-1) Replay stage replays entries from blockstore, keeping track of the number of
+1) Replay stage replays entries from blocktree, keeping track of the number of
 ticks it has seen per slot, and verifying there are `hashes_per_tick` number of
 hashes between ticcks. After the tick from this last shred has been played, 
 replay stage then checks the total number of ticks.

book/src/proposals/validator-proposal.md

@@ -2,51 +2,34 @@
 
 ## History
 
-When we first started Solana, the goal was to de-risk our TPS claims. We knew
-that between optimistic concurrency control and sufficiently long leader slots,
-that PoS consensus was not the biggest risk to TPS. It was GPU-based signature
-verification, software pipelining and concurrent banking. Thus, the TPU was
-born. After topping 100k TPS, we split the team into one group working toward
-710k TPS and another to flesh out the validator pipeline. Hence, the TVU was
-born. The current architecture is a consequence of incremental development with
-that ordering and project priorities. It is not a reflection of what we ever
-believed was the most technically elegant cross-section of those technologies.
-In the context of leader rotation, the strong distinction between leading and
-validating is blurred.
+When we first started Solana, the goal was to de-risk our TPS claims. We knew that between optimistic concurrency control and sufficiently long leader slots, that PoS consensus was not the biggest risk to TPS. It was GPU-based signature verification, software pipelining and concurrent banking. Thus, the TPU was born. After topping 100k TPS, we split the team into one group working toward 710k TPS and another to flesh out the validator pipeline. Hence, the TVU was born. The current architecture is a consequence of incremental development with that ordering and project priorities. It is not a reflection of what we ever believed was the most technically elegant cross-section of those technologies. In the context of leader rotation, the strong distinction between leading and validating is blurred.
 
 ## Difference between validating and leading
 
-The fundamental difference between the pipelines is when the PoH is present. In
-a leader, we process transactions, removing bad ones, and then tag the result
-with a PoH hash. In the validator, we verify that hash, peel it off, and
-process the transactions in exactly the same way. The only difference is that
-if a validator sees a bad transaction, it can't simply remove it like the
-leader does, because that would cause the PoH hash to change. Instead, it
-rejects the whole block. The other difference between the pipelines is what
-happens _after_ banking. The leader broadcasts entries to downstream validators
-whereas the validator will have already done that in RetransmitStage, which is
-a confirmation time optimization. The validation pipeline, on the other hand,
-has one last step. Any time it finishes processing a block, it needs to weigh
-any forks it's observing, possibly cast a vote, and if so, reset its PoH hash
-to the block hash it just voted on.
+The fundamental difference between the pipelines is when the PoH is present. In a leader, we process transactions, removing bad ones, and then tag the result with a PoH hash. In the validator, we verify that hash, peel it off, and process the transactions in exactly the same way. The only difference is that if a validator sees a bad transaction, it can't simply remove it like the leader does, because that would cause the PoH hash to change. Instead, it rejects the whole block. The other difference between the pipelines is what happens _after_ banking. The leader broadcasts entries to downstream validators whereas the validator will have already done that in RetransmitStage, which is a confirmation time optimization. The validation pipeline, on the other hand, has one last step. Any time it finishes processing a block, it needs to weigh any forks it's observing, possibly cast a vote, and if so, reset its PoH hash to the block hash it just voted on.
 
 ## Proposed Design
 
-We unwrap the many abstraction layers and build a single pipeline that can
-toggle leader mode on whenever the validator's ID shows up in the leader
-schedule.
+We unwrap the many abstraction layers and build a single pipeline that can toggle leader mode on whenever the validator's ID shows up in the leader schedule.
 
 ![Validator block diagram](../.gitbook/assets/validator-proposal.svg)
 
 ## Notable changes
 
+* No threads are shut down to switch out of leader mode. Instead, FetchStage
+
+  should forward transactions to the next leader.
+
 * Hoist FetchStage and BroadcastStage out of TPU
+* Blocktree renamed to Blockstore
 * BankForks renamed to Banktree
 * TPU moves to new socket-free crate called solana-tpu.
 * TPU's BankingStage absorbs ReplayStage
 * TVU goes away
 * New RepairStage absorbs Shred Fetch Stage and repair requests
 * JSON RPC Service is optional - used for debugging. It should instead be part
+
   of a separate `solana-blockstreamer` executable.
+
 * New MulticastStage absorbs retransmit part of RetransmitStage
 * MulticastStage downstream of Blockstore

book/src/running-archiver.md

@@ -8,9 +8,9 @@ Please note some of the information and instructions described here may change i
 
 Archivers are specialized light clients. They download a part of the ledger \(a.k.a Segment\) and store it. They earn rewards for storing segments.
 
-The testnet features a validator running at devnet.solana.com, which serves as the entrypoint to the cluster for your archiver node.
+The testnet features a validator running at testnet.solana.com, which serves as the entrypoint to the cluster for your archiver node.
 
-Additionally there is a blockexplorer available at [http://devnet.solana.com/](http://devnet.solana.com/).
+Additionally there is a blockexplorer available at [http://testnet.solana.com/](http://testnet.solana.com/).
 
 The testnet is configured to reset the ledger daily, or sooner should the hourly automated cluster sanity test fail.
 
@@ -29,10 +29,10 @@ Before starting an archiver node, sanity check that the cluster is accessible to
 Fetch the current transaction count over JSON RPC:
 
 ```bash
-curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1, "method":"getTransactionCount"}' http://devnet.solana.com:8899
+curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1, "method":"getTransactionCount"}' http://testnet.solana.com:8899
 ```
 
-Inspect the blockexplorer at [http://devnet.solana.com/](http://devnet.solana.com/) for activity.
+Inspect the blockexplorer at [http://testnet.solana.com/](http://testnet.solana.com/) for activity.
 
 View the [metrics dashboard](https://metrics.solana.com:3000/d/testnet-beta/testnet-monitor-beta?var-testnet=testnet) for more detail on cluster activity.
 
@@ -95,7 +95,7 @@ Download the binaries by navigating to [https://github.com/solana-labs/solana/re
 Try running following command to join the gossip network and view all the other nodes in the cluster:
 
 ```bash
-solana-gossip spy --entrypoint devnet.solana.com:8001
+solana-gossip --entrypoint testnet.solana.com:8001 spy
 # Press ^C to exit
 ```
 
@@ -129,7 +129,7 @@ Use solana-keygen to show the public keys for each of the keypairs, they will be
 ```text
 Then set up the storage accounts for your archiver by running:
 ```bash
-solana --keypair archiver-keypair.json airdrop .0001
+solana --keypair archiver-keypair.json airdrop 100000 lamports
 solana --keypair archiver-keypair.json create-archiver-storage-account $ARCHIVER_IDENTITY $STORAGE_IDENTITY
 ```
 
@@ -138,7 +138,7 @@ Note: Every time the testnet restarts, run the steps to setup the archiver accou
 To start the archiver:
 
 ```bash
-solana-archiver --entrypoint devnet.solana.com:8001 --identity-keypair archiver-keypair.json --storage-keypair storage-keypair.json --ledger archiver-ledger
+solana-archiver --entrypoint testnet.solana.com:8001 --identity-keypair archiver-keypair.json --storage-keypair storage-keypair.json --ledger archiver-ledger
 ```
 
 ## Verify Archiver Setup
@@ -146,11 +146,11 @@ solana-archiver --entrypoint devnet.solana.com:8001 --identity-keypair archiver-
 From another console, confirm the IP address and **identity pubkey** of your archiver is visible in the gossip network by running:
 
 ```bash
-solana-gossip spy --entrypoint devnet.solana.com:8001
+solana-gossip --entrypoint testnet.solana.com:8001 spy
 ```
 
-Provide the **storage account pubkey** to the `solana storage-account` command to view the recent mining activity from your archiver:
+Provide the **storage account pubkey** to the `solana show-storage-account` command to view the recent mining activity from your archiver:
 
 ```bash
-solana --keypair storage-keypair.json storage-account $STORAGE_IDENTITY
+solana --keypair storage-keypair.json show-storage-account $STORAGE_IDENTITY
 ```

book/src/running-validator/README.md

@@ -13,7 +13,9 @@ serve as the entrypoint to the cluster for your validator.
 
 Current testnet entrypoints:
 
-* Developer testnet, devnet.solana.com
+* Stable, testnet.solana.com
+* Beta, beta.testnet.solana.com
+* Edge, edge.testnet.solana.com
 
 Solana may launch special testnets for validator participation; we will provide
 you with a specific entrypoint URL to use.

book/src/running-validator/validator-monitor.md

@@ -6,7 +6,7 @@ Confirm the IP address and **identity pubkey** of your validator is visible in
 the gossip network by running:
 
 ```bash
-solana-gossip spy --entrypoint devnet.solana.com:8001
+solana-gossip --entrypoint testnet.solana.com:8001 spy
 ```
 
 ## Check Your Balance
@@ -21,11 +21,11 @@ solana balance --lamports
 
 ## Check Vote Activity
 
-The `solana vote-account` command displays the recent voting activity from
+The `solana show-vote-account` command displays the recent voting activity from
 your validator:
 
 ```bash
-solana vote-account ~/validator-vote-keypair.json
+solana show-vote-account ~/validator-vote-keypair.json
 ```
 
 ## Get Cluster Info
@@ -35,13 +35,13 @@ cluster, as well as the health of the cluster:
 
 ```bash
 # Similar to solana-gossip, you should see your validator in the list of cluster nodes
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getClusterNodes"}' http://devnet.solana.com:8899
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getClusterNodes"}' http://testnet.solana.com:8899
 # If your validator is properly voting, it should appear in the list of `current` vote accounts. If staked, `stake` should be > 0
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getVoteAccounts"}' http://devnet.solana.com:8899
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getVoteAccounts"}' http://testnet.solana.com:8899
 # Returns the current leader schedule
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getLeaderSchedule"}' http://devnet.solana.com:8899
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getLeaderSchedule"}' http://testnet.solana.com:8899
 # Returns info about the current epoch. slotIndex should progress on subsequent calls.
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochInfo"}' http://devnet.solana.com:8899
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochInfo"}' http://testnet.solana.com:8899
 ```
 
 

book/src/running-validator/validator-software.md

@@ -1,14 +1,14 @@
 # Installing the Validator Software
 
 Install the Solana release
-[v0.23.1](https://github.com/solana-labs/solana/releases/tag/v0.23.1) on your
+[v0.21.0](https://github.com/solana-labs/solana/releases/tag/v0.21.0) on your
 machine by running:
 
 ```bash
-curl -sSf https://raw.githubusercontent.com/solana-labs/solana/v0.23.1/install/solana-install-init.sh | sh -s - 0.23.1
+curl -sSf https://raw.githubusercontent.com/solana-labs/solana/v0.21.0/install/solana-install-init.sh | sh -s - 0.21.0
 ```
 
-If you are connecting to a different testnet, you can replace `0.23.1` with the
+If you are connecting to a different testnet, you can replace `0.21.0` with the
 release tag matching the software version of your desired testnet, or replace it
 with the named channel `stable`, `beta`, or `edge`.
 
@@ -16,11 +16,11 @@ The following output indicates a successful update:
 
 ```text
 looking for latest release
-downloading v0.23.1 installer
+downloading v0.21.0 installer
 Configuration: /home/solana/.config/solana/install/config.yml
 Active release directory: /home/solana/.local/share/solana/install/active_release
-* Release version: 0.23.1
-* Release URL: https://github.com/solana-labs/solana/releases/download/v0.23.1/solana-release-x86_64-unknown-linux-gnu.tar.bz2
+* Release version: 0.21.0
+* Release URL: https://github.com/solana-labs/solana/releases/download/v0.21.0/solana-release-x86_64-unknown-linux-gnu.tar.bz2
 Update successful
 ```
 

book/src/running-validator/validator-stake.md

@@ -35,7 +35,7 @@ solana-keygen new -o ~/validator-stake-keypair.json
 Now delegate 1 SOL to your validator by first creating your stake account:
 
 ```bash
-solana create-stake-account ~/validator-stake-keypair.json 1
+solana create-stake-account ~/validator-stake-keypair.json 1 SOL
 ```
 
 and then delegating that stake to your validator:
@@ -54,7 +54,11 @@ solana delegate-stake ~/validator-stake-keypair.json ~/some-other-validator-vote
 ```
 
 Assuming the node is voting, now you're up and running and generating validator
-rewards. Rewards are paid automatically on epoch boundaries.
+rewards. You'll want to periodically redeem/claim your rewards:
+
+```bash
+solana redeem-vote-credits ~/validator-stake-keypair.json ~/validator-vote-keypair.json
+```
 
 The rewards lamports earned are split between your stake account and the vote
 account according to the commission rate set in the vote account. Rewards can
@@ -81,10 +85,11 @@ so it can take an hour or more for stake to come fully online.
 
 To monitor your validator during its warmup period:
 
-* View your vote account:`solana vote-account ~/validator-vote-keypair.json` This displays the current state of all the votes the validator has submitted to the network.
-* View your stake account, the delegation preference and details of your stake:`solana stake-account ~/validator-stake-keypair.json`
-* `solana validators` displays the current active stake of all validators, including yours
-* `solana stake-history ` shows the history of stake warming up and cooling down over recent epochs
+* View your vote account:`solana show-vote-account ~/validator-vote-keypair.json` This displays the current state of all the votes the validator has submitted to the network.
+* View your stake account, the delegation preference and details of your stake:`solana show-stake-account ~/validator-stake-keypair.json`
+* `solana uptime ~/validator-vote-keypair.json` will display the voting history \(aka, uptime\) of your validator over recent Epochs
+* `solana show-validators` displays the current active stake of all validators, including yours
+* `solana show-show-stake-history ` shows the history of stake warming up and cooling down over recent epochs
 * Look for log messages on your validator indicating your next leader slot: `[2019-09-27T20:16:00.319721164Z INFO solana_core::replay_stage] <VALIDATOR_IDENTITY_PUBKEY> voted and reset PoH at tick height ####. My next leader slot is ####`
 * Once your stake is warmed up, you will see a stake balance listed for your validator on the [Solana Network Explorer](http://explorer.solana.com/validators)
 
@@ -127,3 +132,6 @@ depending on active stake and the size of your stake.
 
 Note that a stake account may only be used once, so after deactivation, use the
 cli's `withdraw-stake` command to recover the previously staked lamports.
+
+Be sure and redeem your credits before withdrawing all your lamports. Once the
+account is fully withdrawn, the account is destroyed.

book/src/running-validator/validator-start.md

@@ -6,11 +6,11 @@ The solana cli includes `get` and `set` configuration commands to automatically
 set the `--url` argument for cli commands. For example:
 
 ```bash
-solana config set --url http://devnet.solana.com:8899
+solana set --url http://testnet.solana.com:8899
 ```
 
 \(You can always override the set configuration by explicitly passing the
-`--url` argument with a command, eg: `solana --url http://beta.devnet.solana.com:8899 balance`\)
+`--url` argument with a command, eg: `solana --url http://beta.testnet.solana.com:8899 balance`\)
 
 ## Confirm The Testnet Is Reachable
 
@@ -18,7 +18,7 @@ Before attaching a validator node, sanity check that the cluster is accessible
 to your machine by fetching the transaction count:
 
 ```bash
-solana transaction-count
+solana get-transaction-count
 ```
 
 Inspect the network explorer at
@@ -33,7 +33,7 @@ Try running following command to join the gossip network and view all the other
 nodes in the cluster:
 
 ```bash
-solana-gossip spy --entrypoint devnet.solana.com:8001
+solana-gossip --entrypoint testnet.solana.com:8001 spy
 # Press ^C to exit
 ```
 
@@ -100,14 +100,14 @@ Now that you have a keypair, set the solana configuration to use your validator
 keypair for all following commands:
 
 ```bash
-solana config set --keypair ~/validator-keypair.json
+solana set --keypair ~/validator-keypair.json
 ```
 
 You should see the following output:
 
 ```text
 Wallet Config Updated: /home/solana/.config/solana/wallet/config.yml
-* url: http://devnet.solana.com:8899
+* url: http://testnet.solana.com:8899
 * keypair: /home/solana/validator-keypair.json
 ```
 
@@ -155,7 +155,7 @@ Connect to a testnet cluster by running:
 
 ```bash
 solana-validator --identity-keypair ~/validator-keypair.json --voting-keypair ~/validator-vote-keypair.json \
-    --ledger ~/validator-ledger --rpc-port 8899 --entrypoint devnet.solana.com:8001 \
+    --ledger ~/validator-ledger --rpc-port 8899 --entrypoint testnet.solana.com:8001 \
     --limit-ledger-size
 ```
 
@@ -166,7 +166,7 @@ Confirm your validator connected to the network by opening a new terminal and
 running:
 
 ```bash
-solana-gossip spy --entrypoint devnet.solana.com:8001
+solana-gossip spy --entrypoint testnet.solana.com:8001
 ```
 
 If your validator is connected, its public key and IP address will appear in the list.

book/src/running-validator/validator-testnet.md

@@ -5,7 +5,8 @@ that serves as an entrypoint to the cluster.
 
 Current testnet entrypoints:
 
-* Stable: devnet.solana.com
+* Stable: testnet.solana.com
+* Beta: beta.testnet.solana.com
 
 Application developers should target the Stable testnet. Key differences
 between the Stable testnet and what will be mainnet:
@@ -27,13 +28,13 @@ You can submit a JSON-RPC request to see the specific software version of the
 cluster. Use this to specify [the software version to install](validator-software.md).
 
 ```bash
-curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1, "method":"getVersion"}' devnet.solana.com:8899
+curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1, "method":"getVersion"}' testnet.solana.com:8899
 ```
 Example result:
 `{"jsonrpc":"2.0","result":{"solana-core":"0.21.0"},"id":1}`
 
 ## Using a Different Testnet
 
-This guide is written in the context of devnet.solana.com, our most stable
+This guide is written in the context of testnet.solana.com, our most stable
 cluster. To participate in another testnet, modify the commands in the following
-pages, replacing `devnet.solana.com` with your desired testnet.
+pages, replacing `testnet.solana.com` with your desired testnet.

book/src/terminology.md

@@ -26,7 +26,7 @@ A preimage resistant [hash](terminology.md#hash) of the [ledger](terminology.md#
 
 The number of [blocks](terminology.md#block) beneath the current block. The first block after the [genesis block](terminology.md#genesis-block) has height one.
 
-## bootstrap validator
+## bootstrap leader
 
 The first [validator](terminology.md#validator) to produce a [block](terminology.md#block).
 
@@ -112,10 +112,6 @@ The configuration file that prepares the [ledger](terminology.md#ledger) for the
 
 A digital fingerprint of a sequence of bytes.
 
-## inflation
-
-An increase in token supply over time used to fund rewards for validation and replication and to fund continued development of Solana.
-
 ## instruction
 
 The smallest unit of a [program](terminology.md#program) that a [client](terminology.md#client) can include in a [transaction](terminology.md#instruction).

book/src/transaction.md

@@ -1,79 +1,17 @@
 # Anatomy of a Transaction
 
-This chapter documents the binary format of a transaction.
+Transactions encode lists of instructions that are executed sequentially, and only committed if all the instructions complete successfully. All account updates are reverted upon the failure of a transaction. Each transaction details the accounts used, including which must sign and which are read only, a recent blockhash, the instructions, and any signatures.
 
-## Transaction Format
+## Accounts and Signatures
 
-A transaction contains a [compact-array](#compact-array-format) of signatures,
-followed by a [message](#message-format).  Each item in the signatures array is
-a [digital signature](#signature-format) of the given message. The Solana
-runtime verifies that the number of signatures matches the number in the first
-8 bits of the [message header](#message-header-format). It also verifies that
-each signature was signed by the private key corresponding to the public key at
-the same index in the message's account addresses array.
+Each transaction explicitly lists all account public keys referenced by the transaction's instructions. A subset of those public keys are each accompanied by a transaction signature. Those signatures signal on-chain programs that the account holder has authorized the transaction. Typically, the program uses the authorization to permit debiting the account or modifying its data.
 
-### Signature Format
+The transaction also marks some accounts as _read-only accounts_. The runtime permits read-only accounts to be read concurrently. If a program attempts to modify a read-only account, the transaction is rejected by the runtime.
 
-Each digital signature is in the ed25519 binary format and consumes 64 bytes.
+## Recent Blockhash
 
+A Transaction includes a recent blockhash to prevent duplication and to give transactions lifetimes. Any transaction that is completely identical to a previous one is rejected, so adding a newer blockhash allows multiple transactions to repeat the exact same action. Transactions also have lifetimes that are defined by the blockhash, as any transaction whose blockhash is too old will be rejected.
 
-## Message Format
+## Instructions
 
-A message contains a [header](#message-header-format), followed by a
-compact-array of [account addresses](#account-addresses-format), followed by a
-recent [blockhash](#blockhash-format), followed by a compact-array of
-[instructions](#instruction-format).
-
-### Message Header Format
-
-The message header contains three unsigned 8-bit values. The first value is the
-number of required signatures in the containing transaction. The second value
-is the number of those corresponding account addresses that are read-only.  The
-third value in the message header is the number of read-only account addresses
-not requiring signatures.
-
-### Account Addresses Format
-
-The addresses that require signatures appear at the beginning of the account
-address array, with addresses requesting write access first and read-only
-accounts following. The addresses that do not require signatures follow the
-addresses that do, again with read-write accounts first and read-only accounts
-following.
-
-
-### Blockhash Format
-
-A blockhash contains a 32-byte SHA-256 hash. It is used to indicate when a
-client last observed the ledger. Validators will reject transactions when the
-blockhash is too old.
-
-
-## Instruction Format
-
-An instruction contains a program ID index, followed by a compact-array of
-account address indexes, followed by a compact-array of opaque 8-bit data. The
-program ID index is used to identify an on-chain program that can interpret the
-opaque data.  The program ID index is an unsigned 8-bit index to an account
-address in the message's array of account addresses. The account address
-indexes are each an unsigned 8-bit index into that same array.
-
-
-## Compact-Array Format
-
-A compact-array is serialized as the array length, followed by each array item.
-The array length is a special multi-byte encoding called compact-u16.
-
-### Compact-u16 Format
-
-A compact-u16 is a multi-byte encoding of 16 bits. The first byte contains the
-lower 7 bits of the value in its lower 7 bits.  If the value is above 0x7f, the
-high bit is set and the next 7 bits of the value are placed into the lower 7
-bits of a second byte. If the value is above 0x3fff, the high bit is set and
-the remaining 2 bits of the value are placed into the lower 2 bits of a third
-byte.
-
-## Account Address Format
-
-An account address is 32-bytes of arbitrary data. When the address requires a
-digital signature, the runtime interprets it as the public key of an ed25519
-keypair.
+Each instruction specifies a single program account \(which must be marked executable\), a subset of the transaction's accounts that should be passed to the program, and a data byte array instruction that is passed to the program. The program interprets the data array and operates on the accounts specified by the instructions. The program can return successfully, or with an error code. An error return causes the entire transaction to fail immediately.

book/src/validator/tvu/blocktree.md

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

chacha-cuda/Cargo.toml

@@ -1,24 +0,0 @@
-[package]
-name = "solana-chacha-cuda"
-version = "1.0.0"
-description = "Solana Chacha Cuda APIs"
-authors = ["Solana Maintainers <maintainers@solana.com>"]
-repository = "https://github.com/solana-labs/solana"
-license = "Apache-2.0"
-homepage = "https://solana.com/"
-edition = "2018"
-
-[dependencies]
-log = "0.4.8"
-solana-archiver-utils = { path = "../archiver-utils", version = "1.0.0" }
-solana-chacha = { path = "../chacha", version = "1.0.0" }
-solana-ledger = { path = "../ledger", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-perf = { path = "../perf", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
-
-[dev-dependencies]
-hex-literal = "0.2.1"
-
-[lib]
-name = "solana_chacha_cuda"

chacha-cuda/src/lib.rs

@@ -1,8 +0,0 @@
-#[macro_use]
-extern crate log;
-
-#[cfg(test)]
-#[macro_use]
-extern crate hex_literal;
-
-pub mod chacha_cuda;

chacha-sys/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "solana-chacha-sys"
-version = "1.0.0"
+version = "0.22.0"
 description = "Solana chacha-sys"
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 repository = "https://github.com/solana-labs/solana"
@@ -9,4 +9,4 @@ license = "Apache-2.0"
 edition = "2018"
 
 [build-dependencies]
-cc = "1.0.49"
+cc = "1.0.48"

chacha/.gitignore

@@ -1 +0,0 @@
-/farf/

chacha/Cargo.toml

@@ -1,25 +0,0 @@
-[package]
-name = "solana-chacha"
-version = "1.0.0"
-description = "Solana Chacha APIs"
-authors = ["Solana Maintainers <maintainers@solana.com>"]
-repository = "https://github.com/solana-labs/solana"
-license = "Apache-2.0"
-homepage = "https://solana.com/"
-edition = "2018"
-
-[dependencies]
-log = "0.4.8"
-rand = "0.6.5"
-rand_chacha = "0.1.1"
-solana-chacha-sys = { path = "../chacha-sys", version = "1.0.0" }
-solana-ledger = { path = "../ledger", version = "1.0.0" }
-solana-logger = { path = "../logger", version = "1.0.0" }
-solana-perf = { path = "../perf", version = "1.0.0" }
-solana-sdk = { path = "../sdk", version = "1.0.0" }
-
-[dev-dependencies]
-hex-literal = "0.2.1"
-
-[lib]
-name = "solana_chacha"

chacha/src/lib.rs

@@ -1,8 +0,0 @@
-#[macro_use]
-extern crate log;
-
-#[cfg(test)]
-#[macro_use]
-extern crate hex_literal;
-
-pub mod chacha;

ci/docker-run.sh

@@ -72,16 +72,10 @@ ARGS+=(
   --env CI_JOB_ID
   --env CI_PULL_REQUEST
   --env CI_REPO_SLUG
+  --env CODECOV_TOKEN
   --env CRATES_IO_TOKEN
 )
 
-# Also propagate environment variables needed for codecov
-# https://docs.codecov.io/docs/testing-with-docker#section-codecov-inside-docker
-# We normalize CI to `1`; but codecov expects it to be `true` to detect Buildkite...
-# Unfortunately, codecov.io fails sometimes:
-#   curl: (7) Failed to connect to codecov.io port 443: Connection timed out
-CODECOV_ENVS=$(CI=true bash <(while ! curl -sS --retry 5 --retry-delay 2 --retry-connrefused https://codecov.io/env; do sleep 10; done))
-
 if $INTERACTIVE; then
   if [[ -n $1 ]]; then
     echo
@@ -89,10 +83,8 @@ if $INTERACTIVE; then
     echo
   fi
   set -x
-  # shellcheck disable=SC2086
-  exec docker run --interactive --tty "${ARGS[@]}" $CODECOV_ENVS "$IMAGE" bash
+  exec docker run --interactive --tty "${ARGS[@]}" "$IMAGE" bash
 fi
 
 set -x
-# shellcheck disable=SC2086
-exec docker run "${ARGS[@]}" $CODECOV_ENVS "$IMAGE" "$@"
+exec docker run "${ARGS[@]}" "$IMAGE" "$@"

ci/docker-rust-nightly/Dockerfile

@@ -1,4 +1,4 @@
-FROM solanalabs/rust:1.41.0
+FROM solanalabs/rust:1.40.0
 ARG date
 
 RUN set -x \

ci/docker-rust/Dockerfile

@@ -1,6 +1,6 @@
 # Note: when the rust version is changed also modify
 # ci/rust-version.sh to pick up the new image tag
-FROM rust:1.41.0
+FROM rust:1.40.0
 
 # Add Google Protocol Buffers for Libra's metrics library.
 ENV PROTOC_VERSION 3.8.0
@@ -17,7 +17,6 @@ RUN set -x \
       clang-7 \
       cmake \
       lcov \
-      libudev-dev \
       libclang-common-7-dev \
       mscgen \
       net-tools \