Datapoints overwhelm the metrics queue and blow up ram usage. (#8272 ) (#8282 )

automerge
Cargo.lock
2020-02-14 21:49:26 -08:00 · 2020-02-14 21:24:05 -07:00 · 2020-02-14 19:58:16 -07:00 · 2020-02-14 10:21:26 -08:00 · 2020-02-10 12:52:16 -08:00 · 2020-02-03 21:08:54 -07:00
449 changed files with 12710 additions and 22028 deletions
--- a/.mergify.yml
+++ b/.mergify.yml
@ -19,6 +19,14 @@ 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
@ -35,11 +43,3 @@ pull_request_rules:
      backport:
        branches:
          - v0.23
-  - name: v0.24 backport
-    conditions:
-      - base=master
-      - label=v0.24
-    actions:
-      backport:
-        branches:
-          - v0.24
--- a/Cargo.lock
+++ b/Cargo.lock
--- a/Cargo.toml
+++ b/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",
--- a/README.md
+++ b/README.md
@ -126,7 +126,10 @@ Remote Testnets
 ---

 We maintain several testnets:
-* `testnet` - public stable testnet accessible via devnet.solana.com. Runs 24/7
+
+* `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

--- a/RELEASE.md
+++ b/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
--- a/archiver-lib/Cargo.toml
+++ b/archiver-lib/Cargo.toml
@ -1,39 +0,0 @@
-[package]
-name = "solana-archiver-lib"
-version = "0.23.6"
-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 = "0.23.6" }
-solana-storage-program = { path = "../programs/storage", version = "0.23.6" }
-thiserror = "1.0"
-serde = "1.0.104"
-serde_json = "1.0.44"
-serde_derive = "1.0.103"
-solana-net-utils = { path = "../net-utils", version = "0.23.6" }
-solana-chacha = { path = "../chacha", version = "0.23.6" }
-solana-chacha-sys = { path = "../chacha-sys", version = "0.23.6" }
-solana-ledger = { path = "../ledger", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-perf = { path = "../perf", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
-solana-core = { path = "../core", version = "0.23.6" }
-solana-archiver-utils = { path = "../archiver-utils", version = "0.23.6" }
-solana-metrics = { path = "../metrics", version = "0.23.6" }
-
-[dev-dependencies]
-hex = "0.4.0"
-
-[lib]
-name = "solana_archiver_lib"
--- a/archiver-lib/src/lib.rs
+++ b/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;
--- a/archiver-lib/src/result.rs
+++ b/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)
-    }
-}
--- a/archiver-utils/Cargo.toml
+++ b/archiver-utils/Cargo.toml
@ -1,26 +0,0 @@
-[package]
-name = "solana-archiver-utils"
-version = "0.23.6"
-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"
-rand_chacha = "0.1.1"
-solana-chacha = { path = "../chacha", version = "0.23.6" }
-solana-chacha-sys = { path = "../chacha-sys", version = "0.23.6" }
-solana-ledger = { path = "../ledger", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-perf = { path = "../perf", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
-
-[dev-dependencies]
-hex = "0.4.0"
-
-[lib]
-name = "solana_archiver_utils"
--- a/archiver-utils/src/lib.rs
+++ b/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());
-    }
-}
--- a/archiver/Cargo.toml
+++ b/archiver/Cargo.toml
@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-archiver"
-version = "0.23.6"
+version = "0.22.9"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
@ -10,11 +10,10 @@ homepage = "https://solana.com/"
 [dependencies]
 clap = "2.33.0"
 console = "0.9.1"
-solana-clap-utils = { path = "../clap-utils", version = "0.23.6" }
-solana-core = { path = "../core", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-metrics = { path = "../metrics", version = "0.23.6" }
-solana-archiver-lib = { path = "../archiver-lib", version = "0.23.6" }
-solana-net-utils = { path = "../net-utils", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
+solana-clap-utils = { path = "../clap-utils", version = "0.22.9" }
+solana-core = { path = "../core", version = "0.22.9" }
+solana-logger = { path = "../logger", version = "0.22.9" }
+solana-metrics = { path = "../metrics", version = "0.22.9" }
+solana-net-utils = { path = "../net-utils", version = "0.22.9" }
+solana-sdk = { path = "../sdk", version = "0.22.9" }

--- a/archiver/src/main.rs
+++ b/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() {
--- a/banking-bench/Cargo.toml
+++ b/banking-bench/Cargo.toml
@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-banking-bench"
-version = "0.23.6"
+version = "0.22.9"
 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 = "0.23.6" }
-solana-ledger = { path = "../ledger", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-runtime = { path = "../runtime", version = "0.23.6" }
-solana-measure = { path = "../measure", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
+solana-core = { path = "../core", version = "0.22.9" }
+solana-ledger = { path = "../ledger", version = "0.22.9" }
+solana-logger = { path = "../logger", version = "0.22.9" }
+solana-runtime = { path = "../runtime", version = "0.22.9" }
+solana-measure = { path = "../measure", version = "0.22.9" }
+solana-sdk = { path = "../sdk", version = "0.22.9" }
 rand = "0.6.5"
 crossbeam-channel = "0.3"
--- a/banking-bench/src/main.rs
+++ b/banking-bench/src/main.rs
@ -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);
--- a/bench-exchange/Cargo.toml
+++ b/bench-exchange/Cargo.toml
@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-exchange"
-version = "0.23.6"
+version = "0.22.9"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
@ -23,19 +23,19 @@ 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 = "0.23.6" }
-solana-core = { path = "../core", version = "0.23.6" }
-solana-genesis = { path = "../genesis", version = "0.23.6" }
-solana-client = { path = "../client", version = "0.23.6" }
-solana-faucet = { path = "../faucet", version = "0.23.6" }
-solana-exchange-program = { path = "../programs/exchange", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-metrics = { path = "../metrics", version = "0.23.6" }
-solana-net-utils = { path = "../net-utils", version = "0.23.6" }
-solana-runtime = { path = "../runtime", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
+solana-clap-utils = { path = "../clap-utils", version = "0.22.9" }
+solana-core = { path = "../core", version = "0.22.9" }
+solana-genesis = { path = "../genesis", version = "0.22.9" }
+solana-client = { path = "../client", version = "0.22.9" }
+solana-faucet = { path = "../faucet", version = "0.22.9" }
+solana-exchange-program = { path = "../programs/exchange", version = "0.22.9" }
+solana-logger = { path = "../logger", version = "0.22.9" }
+solana-metrics = { path = "../metrics", version = "0.22.9" }
+solana-net-utils = { path = "../net-utils", version = "0.22.9" }
+solana-runtime = { path = "../runtime", version = "0.22.9" }
+solana-sdk = { path = "../sdk", version = "0.22.9" }
 untrusted = "0.7.0"
 ws = "0.9.1"

 [dev-dependencies]
-solana-local-cluster = { path = "../local-cluster", version = "0.23.6" }
+solana-local-cluster = { path = "../local-cluster", version = "0.22.9" }
--- a/bench-exchange/src/bench.rs
+++ b/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 {
--- a/bench-exchange/src/cli.rs
+++ b/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;
--- a/bench-exchange/src/main.rs
+++ b/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();
--- a/bench-exchange/tests/bench_exchange.rs
+++ b/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();

--- a/bench-streamer/Cargo.toml
+++ b/bench-streamer/Cargo.toml
@ -2,14 +2,14 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-streamer"
-version = "0.23.6"
+version = "0.22.9"
 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 = "0.23.6" }
-solana-core = { path = "../core", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-net-utils = { path = "../net-utils", version = "0.23.6" }
+solana-clap-utils = { path = "../clap-utils", version = "0.22.9" }
+solana-core = { path = "../core", version = "0.22.9" }
+solana-logger = { path = "../logger", version = "0.22.9" }
+solana-net-utils = { path = "../net-utils", version = "0.22.9" }
--- a/bench-streamer/src/main.rs
+++ b/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;

--- a/bench-tps/Cargo.toml
+++ b/bench-tps/Cargo.toml
@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-tps"
-version = "0.23.6"
+version = "0.22.9"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
@ -16,24 +16,24 @@ 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 = "0.23.6" }
-solana-core = { path = "../core", version = "0.23.6" }
-solana-genesis = { path = "../genesis", version = "0.23.6" }
-solana-client = { path = "../client", version = "0.23.6" }
-solana-faucet = { path = "../faucet", version = "0.23.6" }
-solana-librapay = { path = "../programs/librapay", version = "0.23.6", optional = true }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-metrics = { path = "../metrics", version = "0.23.6" }
-solana-measure = { path = "../measure", version = "0.23.6" }
-solana-net-utils = { path = "../net-utils", version = "0.23.6" }
-solana-runtime = { path = "../runtime", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
-solana-move-loader-program = { path = "../programs/move_loader", version = "0.23.6", optional = true }
+solana-clap-utils = { path = "../clap-utils", version = "0.22.9" }
+solana-core = { path = "../core", version = "0.22.9" }
+solana-genesis = { path = "../genesis", version = "0.22.9" }
+solana-client = { path = "../client", version = "0.22.9" }
+solana-faucet = { path = "../faucet", version = "0.22.9" }
+solana-librapay = { path = "../programs/librapay", version = "0.22.9", optional = true }
+solana-logger = { path = "../logger", version = "0.22.9" }
+solana-metrics = { path = "../metrics", version = "0.22.9" }
+solana-measure = { path = "../measure", version = "0.22.9" }
+solana-net-utils = { path = "../net-utils", version = "0.22.9" }
+solana-runtime = { path = "../runtime", version = "0.22.9" }
+solana-sdk = { path = "../sdk", version = "0.22.9" }
+solana-move-loader-program = { path = "../programs/move_loader", version = "0.22.9", optional = true }

 [dev-dependencies]
 serial_test = "0.3.2"
 serial_test_derive = "0.3.1"
-solana-local-cluster = { path = "../local-cluster", version = "0.23.6" }
+solana-local-cluster = { path = "../local-cluster", version = "0.22.9" }

 [features]
 move = ["solana-librapay", "solana-move-loader-program"]
--- a/bench-tps/src/bench.rs
+++ b/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,7 +15,7 @@ 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,
@ -187,9 +187,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));
            }
        }
@ -244,7 +242,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 +373,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 +479,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)
--- a/bench-tps/src/cli.rs
+++ b/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 {
--- a/bench-tps/src/main.rs
+++ b/bench-tps/src/main.rs
@ -4,7 +4,7 @@ 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};

@ -12,7 +12,7 @@ use std::{collections::HashMap, fs::File, io::prelude::*, path::Path, process::e
 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();
--- a/bench-tps/tests/bench_tps.rs
+++ b/bench-tps/tests/bench_tps.rs
@ -8,7 +8,7 @@ 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 solana_sdk::signature::{Keypair, KeypairUtil};
 use std::sync::{mpsc::channel, Arc};
 use std::time::Duration;

--- a/book/art/passive-staking-callflow.msc
+++ b/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()"] ;

 }
--- a/book/art/spv-bank-hash.bob
+++ b/book/art/spv-bank-hash.bob
@ -1,19 +0,0 @@
-                                   +----------+
-                                   | Bank-Hash|
-                                   +----------+
-                                        ^
-                                        |
-                  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
-                  :                                              :
-                  :       +--------------+     +-------------+   :
-                  : Hash( | Accounts-Hash|  +  | Block-Merkle| ) :
-                  :       +--------------+     +-------------+   :
-                  :              ^                               :
-                  +~~~~~~~~~~~~~ | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
-                                 |
- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 
- :       +---------------+   +---------------+          +---------------+   : 
- : Hash( | Hash(Account1)| + | Hash(Account2)| +  ... + | Hash(AccountN)| ) : 
- :       +---------------+   +---------------+          +---------------+   : 
- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ 
-
--- a/book/art/spv-bank-merkle.bob
+++ b/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)|
+ +---------------+   +---------------+
--- a/book/build-cli-usage.sh
+++ b/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:-"###"}
--- a/book/build.sh
+++ b/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
--- a/book/makefile
+++ b/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)

--- a/book/src/SUMMARY.md
+++ b/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,46 @@
  * [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)
+    * [Blockstore](validator/tvu/blockstore.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)
+  * [Durable Transaction Nonces](offline-signing/durable-nonce.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)
+  * [Blockstore](implemented-proposals/blockstore.md)
  * [Cluster Software Installation and Updates](implemented-proposals/installer.md)
  * [Cluster Economics](implemented-proposals/ed_overview/README.md)
    * [Validation-client Economics](implemented-proposals/ed_overview/ed_validation_client_economics/README.md)
@ -54,7 +70,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 +88,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)
--- a/book/src/api-reference/.cli.md
+++ b/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
--- a/book/src/api-reference/README.md
+++ b/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.
+
--- a/book/src/api-reference/blockstreamer.md
+++ b/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
+
--- a/book/src/api-reference/cli.md
+++ b/book/src/api-reference/cli.md
--- a/book/src/api-reference/instruction-api.md
+++ b/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
+
--- a/book/src/api-reference/javascript-api.md
+++ b/book/src/api-reference/javascript-api.md
--- a/book/src/api-reference/jsonrpc-api.md
+++ b/book/src/api-reference/jsonrpc-api.md
@ -25,18 +25,15 @@ To interact with a Solana node inside a JavaScript application, use the [solana-
 * [getEpochInfo](jsonrpc-api.md#getepochinfo)
 * [getEpochSchedule](jsonrpc-api.md#getepochschedule)
 * [getGenesisHash](jsonrpc-api.md#getgenesishash)
-* [getInflation](jsonrpc-api.md#getinflation)
 * [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)
-* [getSignatureConfirmation](jsonrpc-api.md#getsignatureconfirmation)
 * [getSignatureStatus](jsonrpc-api.md#getsignaturestatus)
 * [getSlot](jsonrpc-api.md#getslot)
 * [getSlotLeader](jsonrpc-api.md#getslotleader)
 * [getSlotsPerSegment](jsonrpc-api.md#getslotspersegment)
-* [getStoragePubkeysForSlot](jsonrpc-api.md#getstoragepubkeysforslot)
 * [getStorageTurn](jsonrpc-api.md#getstorageturn)
 * [getStorageTurnRate](jsonrpc-api.md#getstorageturnrate)
 * [getTransactionCount](jsonrpc-api.md#gettransactioncount)
@ -46,8 +43,7 @@ To interact with a Solana node inside a JavaScript application, use the [solana-
 * [minimumLedgerSlot](jsonrpc-api.md#minimumledgerslot)
 * [requestAirdrop](jsonrpc-api.md#requestairdrop)
 * [sendTransaction](jsonrpc-api.md#sendtransaction)
-* [setLogFilter](jsonrpc-api.md#setlogfilter)
-* [validatorExit](jsonrpc-api.md#validatorexit)
+* [startSubscriptionChannel](jsonrpc-api.md#startsubscriptionchannel)
 * [Subscription Websocket](jsonrpc-api.md#subscription-websocket)
  * [accountSubscribe](jsonrpc-api.md#accountsubscribe)
  * [accountUnsubscribe](jsonrpc-api.md#accountunsubscribe)
@ -55,17 +51,15 @@ To interact with a Solana node inside a JavaScript application, use the [solana-
  * [programUnsubscribe](jsonrpc-api.md#programunsubscribe)
  * [signatureSubscribe](jsonrpc-api.md#signaturesubscribe)
  * [signatureUnsubscribe](jsonrpc-api.md#signatureunsubscribe)
-  * [slotSubscribe](jsonrpc-api.md#slotsubscribe)
-  * [slotUnsubscribe](jsonrpc-api.md#slotunsubscribe)

 ## 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: <string>`, set to `"2.0"`
-* `id: <number>`, a unique client-generated identifying integer
-* `method: <string>`, a string containing the method to be invoked
-* `params: <array>`, a JSON array of ordered parameter values
+* `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:

@ -75,9 +69,9 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "

 The response output will be a JSON object with the following fields:

-* `jsonrpc: <string>`, matching the request specification
-* `id: <number>`, matching the request identifier
-* `result: <array|number|object|string>`, requested data or success confirmation
+* `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.

@ -121,12 +115,12 @@ 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)
+* `string` - Signature of Transaction to confirm, as base-58 encoded string
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `RpcResponse<bool>` - RpcResponse JSON object with `value` field set to Transaction status, boolean true if Transaction is confirmed
+* `RpcResponse<boolean>` - RpcResponse JSON object with `value` field set to Transaction status, boolean true if Transaction is confirmed

 #### Example:

@ -144,19 +138,18 @@ 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)
+* `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: <u64>`, number of lamports assigned to this account, as a u64
-* `owner: <string>`, base-58 encoded Pubkey of the program this account has been assigned to
-* `data: <string>`, base-58 encoded data associated with the account
-* `executable: <bool>`, boolean indicating if the account contains a program \(and is strictly read-only\)
-* `rentEpoch`: <u64>, the epoch at which this account will next owe rent, as u64
+* `lamports`, number of lamports assigned to this account, as a u64
+* `owner`, base-58 encoded pubkey of the program this account has been assigned to
+* `data`, base-58 encoded data associated with the account
+* `executable`, boolean indicating if the account contains a program \(and is strictly read-only\)

 #### Example:

@ -165,7 +158,7 @@ The result value will be an RpcResponse JSON object containing an AccountInfo JS
 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":"4uQeVj5tqViQh7yWWGStvkEG1Zmhx6uasJtWCJziofM","lamports":1,"data":"Joig2k8Ax4JPMpWhXRyc2jMa7Wejz4X1xqVi3i7QRkmVj1ChUgNc4VNpGUQePJGBAui3c6886peU9GEbjsyeANN8JGStprwLbLwcw5wpPjuQQb9mwrjVmoDQBjj3MzZKgeHn6wmnQ5k8DBFuoCYKWWsJfH2gv9FvCzrN6K1CRcQZzF","rentEpoch":2}},"id":1}
+{"jsonrpc":"2.0","result":{"context":{"slot":1},"value":{"executable":false,"owner":"4uQeVj5tqViQh7yWWGStvkEG1Zmhx6uasJtWCJziofM","lamports":1,"data":"Joig2k8Ax4JPMpWhXRyc2jMa7Wejz4X1xqVi3i7QRkmVj1ChUgNc4VNpGUQePJGBAui3c6886peU9GEbjsyeANN8JGStprwLbLwcw5wpPjuQQb9mwrjVmoDQBjj3MzZKgeHn6wmnQ5k8DBFuoCYKWWsJfH2gv9FvCzrN6K1CRcQZzF"}},"id":1}
 ```

 ### getBalance
@ -174,12 +167,12 @@ 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)
+* `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 the balance
+* `RpcResponse<u64>` - RpcResponse JSON object with `value` field set to quantity

 #### Example:

@ -197,15 +190,16 @@ Returns commitment for particular block

 #### Parameters:

-* `<u64>` - block, identified by Slot
+* `u64` - block, identified by Slot

 #### Results:

 The result field will be a JSON object containing:

 * `commitment` - commitment, comprising either:
-  * `<null>` - Unknown block
-  * `<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`
+  * `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`
 * `totalStake` - total active stake, in lamports, of the current epoch

 #### Example:
@ -215,7 +209,7 @@ The result field will be a JSON object containing:
 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],"totalStake": 42},"id":1}
+{"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
@ -234,12 +228,12 @@ query a node that is built from genesis and retains the entire ledger.

 #### Parameters:

-* `<u64>` - block, identified by Slot
+* `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)
+* `null` - block has not yet been produced
+* `i64` - estimated production time, as Unix timestamp (seconds since the Unix epoch)

 #### Example:

@ -263,10 +257,10 @@ None

 The result field will be an array of JSON objects, each with the following sub fields:

-* `pubkey: <string>` - Node public key, as base-58 encoded string
-* `gossip: <string>` - Gossip network address for the node
-* `tpu: <string>` - TPU network address for the node
-* `rpc: <string>` - JSON RPC network address for the node, or `null` if the JSON RPC service is not enabled
+* `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:

@ -284,28 +278,25 @@ Returns identity and transaction information about a confirmed block in the ledg

 #### Parameters:

-* `<u64>` - slot, as u64 integer
-* `<string>` - (optional) encoding for each returned Transaction, either "json" or "binary". If not provided, the default encoding is JSON.
+* `integer` - slot, as u64 integer
+* `string` - (optional) encoding for each returned Transaction, either "json" or "binary". If not provided, the default encoding is JSON.

 #### Results:

 The result field will be an object with the following fields:

-* `blockhash: <string>` - the blockhash of this block, as base-58 encoded string
-* `previousBlockhash: <string>` - the blockhash of this block's parent, as base-58 encoded string
-* `parentSlot: <u64>` - the slot index of this block's parent
-* `transactions: <array>` - an array of JSON objects containing:
-  * `transaction: <object|string>` - [Transaction](transaction-api.md) object, either in JSON format or base-58 encoded binary data, depending on encoding parameter
-  * `meta: <object>` - transaction status metadata object, containing `null` or:
-     * `status: <object>` - Transaction status:
+* `blockhash` - the blockhash of this block, as base-58 encoded string
+* `previousBlockhash` - the blockhash of this block's parent, as base-58 encoded string
+* `parentSlot` - the slot index of this block's parent
+* `transactions` - an array of JSON objects containing:
+  * `transaction` - [Transaction](transaction-api.md) object, either in JSON format or base-58 encoded binary data, depending on encoding parameter
+  * `meta` - transaction status metadata object, containing `null` or:
+     * `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: <u64>` - fee this transaction was charged, as u64 integer
-     * `preBalances: <array>` - array of u64 account balances from before the transaction was processed
-     * `postBalances: <array>` - array of u64 account balances after the transaction was processed
-* `rewards: <array>` - an array of JSON objects containing:
-  * `pubkey: <string>` - The public key, as base-58 encoded string, of the account that received the reward
-  * `lamports: <i64>`- number of reward lamports credited or debited by the account, as a i64
+     * `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:

@ -314,13 +305,13 @@ The result field will be an object with the following fields:
 curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlock","params":[430, "json"]}' localhost:8899

 // Result
-{"jsonrpc":"2.0","result":{"blockhash":"Gp3t5bfDsJv1ovP8cB1SuRhXVuoTqDv7p3tymyubYg5","parentSlot":429,"previousBlockhash":"EFejToxii1L5aUF2NrK9dsbAEmZSNyN5nsipmZHQR1eA","transactions":[{"transaction":{"message":{"accountKeys":["6H94zdiaYfRfPfKjYLjyr2VFBg6JHXygy84r3qhc3NsC","39UAy8hsoYPywGPGdmun747omSr79zLSjqvPJN3zetoH","SysvarS1otHashes111111111111111111111111111","SysvarC1ock11111111111111111111111111111111","Vote111111111111111111111111111111111111111"],"header":{"numReadonlySignedAccounts":0,"numReadonlyUnsignedAccounts":3,"numRequiredSignatures":2},"instructions":[{"accounts":[1,2,3],"data":"29z5mr1JoRmJYQ6ynmk3pf31cGFRziAF1M3mT3L6sFXf5cKLdkEaMXMT8AqLpD4CpcupHmuMEmtZHpomrwfdZetSomNy3d","programIdIndex":4}],"recentBlockhash":"EFejToxii1L5aUF2NrK9dsbAEmZSNyN5nsipmZHQR1eA"},"signatures":["35YGay1Lwjwgxe9zaH6APSHbt9gYQUCtBWTNL3aVwVGn9xTFw2fgds7qK5AL29mP63A9j3rh8KpN1TgSR62XCaby","4vANMjSKiwEchGSXwVrQkwHnmsbKQmy9vdrsYxWdCup1bLsFzX8gKrFTSVDCZCae2dbxJB9mPNhqB2sD1vvr4sAD"]},"meta":{"fee":18000,"postBalances":[499999972500,15298080,1,1,1],"preBalances":[499999990500,15298080,1,1,1],"status":{"Ok":null}}}]},"id":1}
+{"jsonrpc":"2.0","result":{"blockhash":"Gp3t5bfDsJv1ovP8cB1SuRhXVuoTqDv7p3tymyubYg5","parentSlot":429,"previousBlockhash":"EFejToxii1L5aUF2NrK9dsbAEmZSNyN5nsipmZHQR1eA","transactions":[[{"message":{"accountKeys":["6H94zdiaYfRfPfKjYLjyr2VFBg6JHXygy84r3qhc3NsC","39UAy8hsoYPywGPGdmun747omSr79zLSjqvPJN3zetoH","SysvarS1otHashes111111111111111111111111111","SysvarC1ock11111111111111111111111111111111","Vote111111111111111111111111111111111111111"],"header":{"numReadonlySignedAccounts":0,"numReadonlyUnsignedAccounts":3,"numRequiredSignatures":2},"instructions":[{"accounts":[1,2,3],"data":"29z5mr1JoRmJYQ6ynmk3pf31cGFRziAF1M3mT3L6sFXf5cKLdkEaMXMT8AqLpD4CpcupHmuMEmtZHpomrwfdZetSomNy3d","programIdIndex":4}],"recentBlockhash":"EFejToxii1L5aUF2NrK9dsbAEmZSNyN5nsipmZHQR1eA"},"signatures":["35YGay1Lwjwgxe9zaH6APSHbt9gYQUCtBWTNL3aVwVGn9xTFw2fgds7qK5AL29mP63A9j3rh8KpN1TgSR62XCaby","4vANMjSKiwEchGSXwVrQkwHnmsbKQmy9vdrsYxWdCup1bLsFzX8gKrFTSVDCZCae2dbxJB9mPNhqB2sD1vvr4sAD"]},{"fee":18000,"postBalances":[499999972500,15298080,1,1,1],"preBalances":[499999990500,15298080,1,1,1],"status":{"Ok":null}}]]},"id":1}

 // Request
 curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlock","params":[430, "binary"]}' localhost:8899

 // Result
-{"jsonrpc":"2.0","result":{"blockhash":"Gp3t5bfDsJv1ovP8cB1SuRhXVuoTqDv7p3tymyubYg5","parentSlot":429,"previousBlockhash":"EFejToxii1L5aUF2NrK9dsbAEmZSNyN5nsipmZHQR1eA","transactions":[{"transaction":"81UZJt4dh4Do66jDhrgkQudS8J2N6iG3jaVav7gJrqJSFY4Ug53iA9JFJZh2gxKWcaFdLJwhHx9mRdg9JwDAWB4ywiu5154CRwXV4FMdnPLg7bhxRLwhhYaLsVgMF5AyNRcTzjCVoBvqFgDU7P8VEKDEiMvD3qxzm1pLZVxDG1LTQpT3Dz4Uviv4KQbFQNuC22KupBoyHFB7Zh6KFdMqux4M9PvhoqcoJsJKwXjWpKu7xmEKnnrSbfLadkgjBmmjhW3fdTrFvnhQdTkhtdJxUL1xS9GMuJQer8YgSKNtUXB1eXZQwXU8bU2BjYkZE6Q5Xww8hu9Z4E4Mo4QsooVtHoP6BM3NKw8zjVbWfoCQqxTrwuSzrNCWCWt58C24LHecH67CTt2uXbYSviixvrYkK7A3t68BxTJcF1dXJitEPTFe2ceTkauLJqrJgnER4iUrsjr26T8YgWvpY9wkkWFSviQW6wV5RASTCUasVEcrDiaKj8EQMkgyDoe9HyKitSVg67vMWJFpUXpQobseWJUs5FTWWzmfHmFp8FZ","meta":{"fee":18000,"postBalances":[499999972500,15298080,1,1,1],"preBalances":[499999990500,15298080,1,1,1],"status":{"Ok":null}}}]},"id":1}
+{"jsonrpc":"2.0","result":{"blockhash":"Gp3t5bfDsJv1ovP8cB1SuRhXVuoTqDv7p3tymyubYg5","parentSlot":429,"previousBlockhash":"EFejToxii1L5aUF2NrK9dsbAEmZSNyN5nsipmZHQR1eA","transactions":[["81UZJt4dh4Do66jDhrgkQudS8J2N6iG3jaVav7gJrqJSFY4Ug53iA9JFJZh2gxKWcaFdLJwhHx9mRdg9JwDAWB4ywiu5154CRwXV4FMdnPLg7bhxRLwhhYaLsVgMF5AyNRcTzjCVoBvqFgDU7P8VEKDEiMvD3qxzm1pLZVxDG1LTQpT3Dz4Uviv4KQbFQNuC22KupBoyHFB7Zh6KFdMqux4M9PvhoqcoJsJKwXjWpKu7xmEKnnrSbfLadkgjBmmjhW3fdTrFvnhQdTkhtdJxUL1xS9GMuJQer8YgSKNtUXB1eXZQwXU8bU2BjYkZE6Q5Xww8hu9Z4E4Mo4QsooVtHoP6BM3NKw8zjVbWfoCQqxTrwuSzrNCWCWt58C24LHecH67CTt2uXbYSviixvrYkK7A3t68BxTJcF1dXJitEPTFe2ceTkauLJqrJgnER4iUrsjr26T8YgWvpY9wkkWFSviQW6wV5RASTCUasVEcrDiaKj8EQMkgyDoe9HyKitSVg67vMWJFpUXpQobseWJUs5FTWWzmfHmFp8FZ",{"fee":18000,"postBalances":[499999972500,15298080,1,1,1],"preBalances":[499999990500,15298080,1,1,1],"status":{"Ok":null}}]]},"id":1}
 ```

 ### getConfirmedBlocks
@ -329,8 +320,8 @@ Returns a list of confirmed blocks

 #### Parameters:

-* `<u64>` - start_slot, as u64 integer
-* `<u64>` - (optional) end_slot, as u64 integer
+* `integer` - start_slot, as u64 integer
+* `integer` - (optional) end_slot, as u64 integer

 #### Results:

@ -354,16 +345,15 @@ Returns information about the current epoch

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

 The result field will be an object with the following fields:

-* `absoluteSlot: <u64>`, the current slot
-* `epoch: <u64>`, the current epoch
-* `slotIndex: <u64>`, the current slot relative to the start of the current epoch
-* `slotsInEpoch: <u64>`, the number of slots in this epoch
+* `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:

@ -372,7 +362,7 @@ The result field will be an object with the following fields:
 curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochInfo"}' http://localhost:8899

 // Result
-{"jsonrpc":"2.0","result":{"absoluteSlot":166598,"epoch":27,"slotIndex":2790,"slotsInEpoch":8192},"id":1}
+{"jsonrpc":"2.0","result":{"epoch":3,"slotIndex":126,"slotsInEpoch":256},"id":1}
 ```

 ### getEpochSchedule
@ -387,11 +377,11 @@ None

 The result field will be an object with the following fields:

-* `slotsPerEpoch: <u64>`, the maximum number of slots in each epoch
-* `leaderScheduleSlotOffset: <u64>`, the number of slots before beginning of an epoch to calculate a leader schedule for that epoch
-* `warmup: <bool>`, whether epochs start short and grow
-* `firstNormalEpoch: <u64>`, first normal-length epoch, log2(slotsPerEpoch) - log2(MINIMUM_SLOTS_PER_EPOCH)
-* `firstNormalSlot: <u64>`, MINIMUM_SLOTS_PER_EPOCH * (2.pow(firstNormalEpoch) - 1)
+* `slotsPerEpoch`, the maximum number of slots in each epoch
+* `leaderScheduleSlotOffset`, the number of slots before beginning of an epoch to calculate a leader schedule for that epoch
+* `warmup`, whether epochs start short and grow
+* `firstNormalEpoch`, first normal-length epoch, log2(slotsPerEpoch) - log2(MINIMUM_SLOTS_PER_EPOCH)
+* `firstNormalSlot`, MINIMUM_SLOTS_PER_EPOCH * (2.pow(firstNormalEpoch) - 1)

 #### Example:

@ -413,7 +403,7 @@ None

 #### Results:

-* `<string>` - a Hash as base-58 encoded string
+* `string` - a Hash as base-58 encoded string

 #### Example:

@ -425,43 +415,14 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "m
 {"jsonrpc":"2.0","result":"GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC","id":1}
 ```

-### getInflation
-
-Returns the inflation configuration of the cluster
-
-#### Parameters:
-
-None
-
-#### Results:
-
-The result field will be an Inflation object with the following fields:
-
-* `initial: <f64>`, the initial inflation percentage from time 0
-* `terminal: <f64>`, terminal inflation percentage
-* `taper: <f64>`, rate per year at which inflation is lowered
-* `foundation: <f64>`, percentage of total inflation allocated to the foundation
-* `foundationTerm: <f64>`, duration of foundation pool inflation in years
-* `storage: <f64>`, percentage of total inflation allocated to storage rewards
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getInflation"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"foundation":0.05,"foundationTerm":7.0,"initial":0.15,"storage":0.1,"taper":0.15,"terminal":0.015},"id":1}
-```
-
 ### getLeaderSchedule

 Returns the leader schedule for an epoch

 #### Parameters:

-* `<u64>` - (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)
+* `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:

@ -485,12 +446,12 @@ Returns minimum balance required to make account rent exempt.

 #### Parameters:

-* `<usize>` - account data length
-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `u64` - account data length
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `<u64>` - minimum lamports required in account
+* `u64` - minimum lamports required in account

 #### Example:

@ -508,12 +469,12 @@ 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)
+* `string` - Signature of Transaction to confirm, as base-58 encoded string
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `<u64>` - count, or null if signature not found
+* `u64` - count

 #### Example:

@ -531,20 +492,18 @@ 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)
+* `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 JSON objects, which will contain:
+The result field will be an array of arrays. Each sub array will contain:

-* `pubkey: <string>` - the account Pubkey as base-58 encoded string
-* `account: <object>` - a JSON object, with the following sub fields:
-   * `lamports: <u64>`, number of lamports assigned to this account, as a u64
-   * `owner: <string>`, base-58 encoded Pubkey of the program this account has been assigned to
-   * `data: <string>`, base-58 encoded data associated with the account
-   * `executable: <bool>`, boolean indicating if the account contains a program \(and is strictly read-only\)
-   * `rentEpoch`: <u64>, the epoch at which this account will next owe rent, as u64
+* `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`, base-58 encoded pubkey of the program this account has been assigned to
+* `data`, base-58 encoded data associated with the account
+* `executable`, boolean indicating if the account contains a program \(and is strictly read-only\)

 #### Example:

@ -553,7 +512,7 @@ The result field will be an array of JSON objects, which will contain:
 curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getProgramAccounts", "params":["4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T"]}' http://localhost:8899

 // Result
-{"jsonrpc":"2.0","result":[{"account":{"data":"2R9jLfiAQ9bgdcw6h8s44439","executable":false,"lamports":15298080,"owner":"4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T","rentEpoch":28},"pubkey":"CxELquR1gPP8wHe33gZ4QxqGB3sZ9RSwsJ2KshVewkFY"}],"id":1}
+{"jsonrpc":"2.0","result":[["BqGKYtAKu69ZdWEBtZHh4xgJY1BYa2YBiBReQE3pe383", {"executable":false,"owner":"4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T","lamports":1,"data":"", ["8nQwAgzN2yyUzrukXsCa3JELBYqDQrqJ3UyHiWazWxHR", {"executable":false,"owner":"4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T","lamports":10,"data":[]]]},"id":1}
 ```

 ### getRecentBlockhash
@ -562,15 +521,15 @@ Returns a recent block hash from the ledger, and a fee schedule that can be used

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

 An RpcResponse containing a JSON object consisting of a string blockhash and FeeCalculator JSON object.

-* `RpcResponse<object>` - RpcResponse JSON object with `value` field set to a JSON object including:
-* `blockhash: <string>` - a Hash as base-58 encoded string
-* `feeCalculator: <object>` - FeeCalculator object, the fee schedule for this block hash
+* `RpcResponse<array>` - RpcResponse JSON object with `value` field set to a JSON object including:
+* `blockhash` - a Hash as base-58 encoded string
+* `feeCalculator` - FeeCalculator object, the fee schedule for this block hash

 #### Example:

@ -579,34 +538,7 @@ An RpcResponse containing a JSON object consisting of a string blockhash and Fee
 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":{"blockhash":"CSymwgTNX1j3E4qhKfJAUE41nBWEwXufoYryPbkde5RR","feeCalculator":{"burnPercent":50,"lamportsPerSignature":5000,"maxLamportsPerSignature":100000,"minLamportsPerSignature":5000,"targetLamportsPerSignature":10000,"targetSignaturesPerSlot":20000}}},"id":1}
-```
-
-### getSignatureConfirmation
-
-Returns the status and number of confirmations of a given signature.
-#### 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 confirmations and status:
-  * `confirmations: <u64>` - count of confirmations since transaction was processed
-  * `status: <object>` -
-    * `"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":"getSignatureConfirmation", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"confirmations":12,"status":{"Ok": null}},"id":1}
+{"jsonrpc":"2.0","result":{"context":{"slot":1},"value":{"blockhash": "GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC","feeCalculator":{"lamportsPerSignature": 0}}},"id":1}
 ```

 ### getSignatureStatus
@ -615,14 +547,14 @@ Returns the status of a given signature. This method is similar to [confirmTrans

 #### Parameters:

-* `<string>` - Signature of Transaction to confirm, as base-58 encoded string
-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `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
+* `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:
@ -632,7 +564,7 @@ Returns the status of a given signature. This method is similar to [confirmTrans
 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":{"Ok": null},"id":1}
+{"jsonrpc":"2.0","result":"SignatureNotFound","id":1}
 ```

 ### getSlot
@ -641,11 +573,11 @@ Returns the current slot the node is processing

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `<u64>` - Current slot
+* `u64` - Current slot

 #### Example:

@ -663,11 +595,11 @@ Returns the current slot leader

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `<string>` - Node identity Pubkey as base-58 encoded string
+* `string` - Node Id as base-58 encoded string

 #### Example:

@ -685,11 +617,11 @@ Returns the current storage segment size in terms of slots

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `<u64>` - Number of slots in a storage segment
+* `u64` - Number of slots in a storage segment

 #### Example:

@ -700,27 +632,6 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "m
 {"jsonrpc":"2.0","result":1024,"id":1}
 ```

-### getStoragePubkeysForSlot
-
-Returns the storage Pubkeys for a particular slot
-
-#### Parameters:
-
-None
-
-#### Results:
-
-An array of Pubkeys, as base-58 encoded strings
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getStoragePubkeysForSlot","params":[1]}' http://localhost:8899
- // Result
-{"jsonrpc":"2.0","result":["GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC"],"id":1}
-```
-
 ### getStorageTurn

 Returns the current storage turn's blockhash and slot
@ -733,8 +644,8 @@ None

 A JSON object consisting of

-* `blockhash: <string>` - a Hash as base-58 encoded string indicating the blockhash of the turn slot
-* `slot: <u64>` - the current storage turn slot
+* `blockhash` - a Hash as base-58 encoded string indicating the blockhash of the turn slot
+* `slot` - the current storage turn slot

 #### Example:

@ -742,7 +653,7 @@ A JSON object consisting of
 // 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":{"blockhash": "GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC", "slot": 2048},"id":1}
+{"jsonrpc":"2.0","result":{"blockhash": "GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC", "slot": "2048"},"id":1}
 ```

 ### getStorageTurnRate
@ -755,7 +666,7 @@ None

 #### Results:

-* `<u64>` - Number of slots in storage turn
+* `u64` - Number of slots in storage turn

 #### Example:

@ -772,11 +683,11 @@ Returns the current Transaction count from the ledger

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `<u64>` - count
+* `u64` - count

 #### Example:

@ -790,15 +701,15 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "m

 ### getTotalSupply

-Returns the current total supply in lamports
+Returns the current total supply in Lamports

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)

 #### Results:

-* `<u64>` - Total supply
+* `u64` - Total supply

 #### Example:

@ -820,7 +731,7 @@ None

 #### Results:

-The result field will be a JSON object with the following fields:
+The result field will be a JSON object with the following sub fields:

 * `solana-core`, software version of solana-core

@ -830,7 +741,7 @@ The result field will be a JSON object with the following fields:
 // 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.23.6"},"id":1}
+{"jsonrpc":"2.0","result":{"solana-core": "0.17.2"},"id":1}
 ```

 ### getVoteAccounts
@ -839,19 +750,18 @@ Returns the account info and associated stake for all the voting accounts in the

 #### Parameters:

-* `<object>` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
+* `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: <string>` - Vote account public key, as base-58 encoded string
-* `nodePubkey: <string>` - Node public key, as base-58 encoded string
-* `activatedStake: <u64>` - the stake, in lamports, delegated to this vote account and active in this epoch
-* `epochVoteAccount: <bool>` - bool, whether the vote account is staked for this epoch
-* `commission: <number>`, percentage (0-100) of rewards payout owed to the vote account
-* `lastVote: <u64>` - Most recent slot voted on by this vote account
-* `epochCredits: <array>` - History of how many credits earned by the end of each epoch, as an array of arrays containing: [epoch, credits, previousCredits]
+* `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:

@ -860,7 +770,7 @@ The result field will be a JSON object of `current` and `delinquent` accounts, e
 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,"epochCredits":[[1,64,0],[2,192,64]],"nodePubkey":"B97CCUW3AEZFGy6uUg6zUdnNYvnVq5VG8PUtb2HayTDD","lastVote":147,"activatedStake":42,"votePubkey":"3ZT31jkAGhUaw8jsy4bTknwBMP8i4Eueh52By4zXcsVw"}],"delinquent":[{"commission":127,"epochVoteAccount":false,"epochCredits":[],"nodePubkey":"6ZPxeQaDo4bkZLRsdNrCzchNQr5LN9QMc9sipXv9Kw8f","lastVote":0,"activatedStake":0,"votePubkey":"CmgCk4aMS7KW1SHX3s9K5tBJ6Yng2LBaC8MFov4wx9sm"}]},"id":1}
+{"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}
 ```

 ### minimumLedgerSlot
@ -892,13 +802,13 @@ 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)
+* `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
+* `string` - Transaction Signature of airdrop, as base-58 encoded string

 #### Example:

@ -916,66 +826,22 @@ Creates new transaction

 #### Parameters:

-* `<array>` - array of octets containing a fully-signed Transaction
+* `array` - array of octets containing a fully-signed Transaction

 #### Results:

-* `<string>` - Transaction Signature, as base-58 encoded string
+* `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":["3gKEMTuxvm3DKEJc4UyiyoNz1sxwdVRW2pyDDXqaCvUjGApnsazGh2y4W92zuaSSdJhBbWLYAkZokBt4N5oW27R7zCVaLLpLxvATL2GgheEh9DmmDR1P9r1ZqirVXM2fF3z5cafmc4EtwWc1UErFdCWj1qYvy4bDGMLXRYLURxaKytEEqrxz6JXj8rUHhDpjTZeFxmC6iAW3hZr6cmaAzewQCQfiEv2HfydriwHDtN95u3Y1EF6SuXxcRqox2aTjGye2Ln9zFj4XbnAtjCmkZhR"]}' http://localhost:8899
+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}
 ```

-### setLogFilter
-
-Sets the log filter on the validator
-
-#### Parameters:
-
-* `<string>` - the new log filter to use
-
-#### Results:
-
-* `<null>`
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"setLogFilter", "params":["solana_core=debug"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":null,"id":1}
-```
-
-### validatorExit
-
-If a validator boots with RPC exit enabled (`--enable-rpc-exit` parameter), this request causes the validator to exit.
-
-#### Parameters:
-
-None
-
-#### Results:
-
-* `<bool>` - Whether the validator exit operation was successful
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"validatorExit"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":true,"id":1}
-```
-
 ### Subscription Websocket

 After connect to the RPC PubSub websocket at `ws://<ADDRESS>/`:
@ -1004,14 +870,14 @@ Subscribe to an account to receive notifications when the lamports or data for a

 #### Parameters:

-* `<string>` - account Pubkey, as base-58 encoded string
-* `<u64>` - optional, number of confirmed blocks to wait before notification.
+* `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:

-* `<number>` - Subscription id \(needed to unsubscribe\)
+* `integer` - Subscription id \(needed to unsubscribe\)

 #### Example:

@ -1028,7 +894,7 @@ Subscribe to an account to receive notifications when the lamports or data for a
 #### Notification Format:

 ```bash
-{"jsonrpc": "2.0","method": "accountNotification", "params": {"result": {"executable":false,"owner":"4uQeVj5tqViQh7yWWGStvkEG1Zmhx6uasJtWCJziofM","lamports":1,"data":"Joig2k8Ax4JPMpWhXRyc2jMa7Wejz4X1xqVi3i7QRkmVj1ChUgNc4VNpGUQePJGBAui3c6886peU9GEbjsyeANN8JGStprwLbLwcw5wpPjuQQb9mwrjVmoDQBjj3MzZKgeHn6wmnQ5k8DBFuoCYKWWsJfH2gv9FvCzrN6K1CRcQZzF","rentEpoch":28},"subscription":0}}
+{"jsonrpc": "2.0","method": "accountNotification", "params": {"result": {"executable":false,"owner":"4uQeVj5tqViQh7yWWGStvkEG1Zmhx6uasJtWCJziofM","lamports":1,"data":"Joig2k8Ax4JPMpWhXRyc2jMa7Wejz4X1xqVi3i7QRkmVj1ChUgNc4VNpGUQePJGBAui3c6886peU9GEbjsyeANN8JGStprwLbLwcw5wpPjuQQb9mwrjVmoDQBjj3MzZKgeHn6wmnQ5k8DBFuoCYKWWsJfH2gv9FvCzrN6K1CRcQZzF"},"subscription":0}}
 ```

 ### accountUnsubscribe
@ -1037,11 +903,11 @@ Unsubscribe from account change notifications

 #### Parameters:

-* `<number>` - id of account Subscription to cancel
+* `integer` - id of account Subscription to cancel

 #### Results:

-* `<bool>` - unsubscribe success message
+* `bool` - unsubscribe success message

 #### Example:

@ -1059,14 +925,14 @@ Subscribe to a program to receive notifications when the lamports or data for a

 #### Parameters:

-* `<string>` - program\_id Pubkey, as base-58 encoded string
-* `<u64>` - optional, number of confirmed blocks to wait before notification.
+* `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\)
+* `integer` - Subscription id \(needed to unsubscribe\)

 #### Example:

@ -1082,11 +948,11 @@ Subscribe to a program to receive notifications when the lamports or data for a

 #### Notification Format:

-* `<string>` - account Pubkey, as base-58 encoded string
-* `<object>` - account info JSON object \(see [getAccountInfo](jsonrpc-api.md#getaccountinfo) for field details\)
+* `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":"9gZbPtbtHrs6hEWgd6MbVY9VPFtS5Z8xKtnYwA2NynHV","data":"4SZWhnbSt3njU4QHVgPrWeekz1BudU4ttmdr9ezmrL4X6XeLeL83xVAo6ZdxwU3oXgHNeF2q6tWZbnVnBXmvNyeLVEGt8ZQ4ZmgjHfVNCEwBtzh2aDrHgQSjBFLYAdmM3uwBhcm1EyHJLeUiFqpsoAUhn6Vphwrpf44dWRAGsAJZbzvVrUW9bfucpR7xudHHg2MxQ2CdqsfS3TfWUJY3vaf2A4AUNzfAmNPHBGi99nU2hYubGSVSPcpVPpdRWQkydgqasBmTosd","rentEpoch":28}],"subscription":0}}
+  {"jsonrpc":"2.0","method":"programNotification","params":{{"result":{"pubkey": "8Rshv2oMkPu5E4opXTRyuyBeZBqQ4S477VG26wUTFxUM","account":{"executable":false,"lamports":1,"owner":"9gZbPtbtHrs6hEWgd6MbVY9VPFtS5Z8xKtnYwA2NynHV","data":"4SZWhnbSt3njU4QHVgPrWeekz1BudU4ttmdr9ezmrL4X6XeLeL83xVAo6ZdxwU3oXgHNeF2q6tWZbnVnBXmvNyeLVEGt8ZQ4ZmgjHfVNCEwBtzh2aDrHgQSjBFLYAdmM3uwBhcm1EyHJLeUiFqpsoAUhn6Vphwrpf44dWRAGsAJZbzvVrUW9bfucpR7xudHHg2MxQ2CdqsfS3TfWUJY3vaf2A4AUNzfAmNPHBGi99nU2hYubGSVSPcpVPpdRWQkydgqasBmTosd"}},"subscription":0}}
  ```

 ### programUnsubscribe
@ -1095,11 +961,11 @@ Unsubscribe from program-owned account change notifications

 #### Parameters:

-* `<integer>` - id of account Subscription to cancel
+* `integer` - id of account Subscription to cancel

 #### Results:

-* `<bool>` - unsubscribe success message
+* `bool` - unsubscribe success message

 #### Example:

@ -1117,8 +983,8 @@ Subscribe to a transaction signature to receive notification when the transactio

 #### Parameters:

-* `<string>` - Transaction Signature, as base-58 encoded string
-* `<integer>` - optional, number of confirmed blocks to wait before notification.
+* `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\)

@ -1150,11 +1016,11 @@ Unsubscribe from signature confirmation notification

 #### Parameters:

-* `<integer>` - subscription id to cancel
+* `integer` - subscription id to cancel

 #### Results:

-* `<bool>` - unsubscribe success message
+* `bool` - unsubscribe success message

 #### Example:

@ -1165,53 +1031,3 @@ Unsubscribe from signature confirmation notification
 // Result
 {"jsonrpc": "2.0","result": true,"id": 1}
 ```
-
-### slotSubscribe
-
-Subscribe to receive notification anytime a slot is processed by the validator
-
-#### Parameters:
-
-None
-
-#### Results:
-
-* `integer` - subscription id \(needed to unsubscribe\)
-
-#### Example:
-
-```bash
-// Request
-{"jsonrpc":"2.0", "id":1, "method":"slotSubscribe"}
-
-// Result
-{"jsonrpc": "2.0","result": 0,"id": 1}
-```
-
-#### Notification Format:
-
-```bash
-{"jsonrpc": "2.0","method": "slotNotification", "params": {"result":{"parent":75,"root":44,"slot":76},"subscription":0}}
-```
-
-### slotUnsubscribe
-
-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":"slotUnsubscribe", "params":[0]}
-
-// Result
-{"jsonrpc": "2.0","result": true,"id": 1}
-```
--- a/book/src/api-reference/transaction-api.md
+++ b/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).
--- a/book/src/proposals/block-confirmation.md
+++ b/book/src/proposals/block-confirmation.md
--- a/book/src/cli/README.md
+++ b/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.
--- a/book/src/cluster/README.md
+++ b/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.
--- a/book/src/cluster/stake-delegation-and-rewards.md
+++ b/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

@ -94,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.
@ -142,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.

@ -208,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.
--- a/book/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md
+++ b/book/src/implemented-proposals/ed_overview/ed_storage_rent_economics.md
--- a/book/src/getting-started/README.md
+++ b/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)
--- a/book/src/getting-started/testnet-participation.md
+++ b/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)
+
--- a/book/src/getting-started/webwallet.md
+++ b/book/src/getting-started/webwallet.md
--- a/book/src/implemented-proposals/blockstore.md
+++ b/book/src/implemented-proposals/blockstore.md
@ -0,0 +1,90 @@
+# Blockstore
+
+After a block reaches finality, all blocks from that one on down to the genesis block form a linear chain with the familiar name blockchain. Until that point, however, the validator must maintain all potentially valid chains, called _forks_. The process by which forks naturally form as a result of leader rotation is described in [fork generation](../cluster/fork-generation.md). The _blockstore_ data structure described here is how a validator copes with those forks until blocks are finalized.
+
+The blockstore allows a validator to record every shred it observes on the network, in any order, as long as the shred is signed by the expected leader for a given slot.
+
+Shreds are moved to a fork-able key space the tuple of `leader slot` + `shred index` \(within the slot\). This permits the skip-list structure of the Solana protocol to be stored in its entirety, without a-priori choosing which fork to follow, which Entries to persist or when to persist them.
+
+Repair requests for recent shreds are served out of RAM or recent files and out of deeper storage for less recent shreds, as implemented by the store backing Blockstore.
+
+## Functionalities of Blockstore
+
+1. Persistence: the Blockstore lives in the front of the nodes verification
+
+   pipeline, right behind network receive and signature verification. If the
+
+   shred received is consistent with the leader schedule \(i.e. was signed by the
+
+   leader for the indicated slot\), it is immediately stored.
+
+2. Repair: repair is the same as window repair above, but able to serve any
+
+   shred that's been received. Blockstore stores shreds with signatures,
+
+   preserving the chain of origination.
+
+3. Forks: Blockstore supports random access of shreds, so can support a
+
+   validator's need to rollback and replay from a Bank checkpoint.
+
+4. Restart: with proper pruning/culling, the Blockstore can be replayed by
+
+   ordered enumeration of entries from slot 0. The logic of the replay stage
+
+   \(i.e. dealing with forks\) will have to be used for the most recent entries in
+
+   the Blockstore.
+
+## Blockstore Design
+
+1. Entries in the Blockstore are stored as key-value pairs, where the key is the concatenated slot index and shred index for an entry, and the value is the entry data. Note shred indexes are zero-based for each slot \(i.e. they're slot-relative\).
+2. The Blockstore maintains metadata for each slot, in the `SlotMeta` struct containing:
+   * `slot_index` - The index of this slot
+   * `num_blocks` - The number of blocks in the slot \(used for chaining to a previous slot\)
+   * `consumed` - The highest shred index `n`, such that for all `m < n`, there exists a shred in this slot with shred index equal to `n` \(i.e. the highest consecutive shred index\).
+   * `received` - The highest received shred index for the slot
+   * `next_slots` - A list of future slots this slot could chain to. Used when rebuilding
+
+     the ledger to find possible fork points.
+
+   * `last_index` - The index of the shred that is flagged as the last shred for this slot. This flag on a shred will be set by the leader for a slot when they are transmitting the last shred for a slot.
+   * `is_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 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`.
+
+## Blockstore APIs
+
+The Blockstore offers a subscription based API that ReplayStage uses to ask for entries it's interested in. The entries will be sent on a channel exposed by the Blockstore. These subscription API's are as follows: 1. `fn get_slots_since(slot_indexes: &[u64]) -> Vec<SlotMeta>`: Returns new slots connecting to any element of the list `slot_indexes`.
+
+1. `fn get_slot_entries(slot_index: u64, entry_start_index: usize, max_entries: Option<u64>) -> Vec<Entry>`: Returns the entry vector for the slot starting with `entry_start_index`, capping the result at `max` if `max_entries == Some(max)`, otherwise, no upper limit on the length of the return vector is imposed.
+
+Note: Cumulatively, this means that the replay stage will now have to know when a slot is finished, and subscribe to the next slot it's interested in to get the next set of entries. Previously, the burden of chaining slots fell on the Blockstore.
+
+## Interfacing with Bank
+
+The bank exposes to replay stage:
+
+1. `prev_hash`: which PoH chain it's working on as indicated by the hash of the last
+
+   entry it processed
+
+2. `tick_height`: the ticks in the PoH chain currently being verified by this
+
+   bank
+
+3. `votes`: a stack of records that contain: 1. `prev_hashes`: what anything after this vote must chain to in PoH 2. `tick_height`: the tick height at which this vote was cast 3. `lockout period`: how long a chain must be observed to be in the ledger to
+
+   be able to be chained below this vote
+
+Replay stage uses Blockstore APIs to find the longest chain of entries it can hang off a previous vote. If that chain of entries does not hang off the latest vote, the replay stage rolls back the bank to that vote and replays the chain from there.
+
+## Pruning Blockstore
+
+Once Blockstore entries are old enough, representing all the possible forks becomes less useful, perhaps even problematic for replay upon restart. Once a validator's votes have reached max lockout, however, any Blockstore contents that are not on the PoH chain for that vote for can be pruned, expunged.
+
+Archiver nodes will be responsible for storing really old ledger contents, and validators need only persist their bank periodically.
+
--- a/book/src/implemented-proposals/commitment.md
+++ b/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,
--- a/book/src/implemented-proposals/ed_overview/README.md
+++ b/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.
+
--- a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md
+++ b/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\).
+
--- a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md
+++ b/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.

--- a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md
+++ b/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.
+
--- a/book/src/implemented-proposals/installer.md
+++ b/book/src/implemented-proposals/installer.md
@ -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]
 ```

--- a/book/src/implemented-proposals/rent.md
+++ b/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

--- a/book/src/implemented-proposals/tower-bft.md
+++ b/book/src/implemented-proposals/tower-bft.md
@ -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.
+
--- a/book/src/offline-signing/README.md
+++ b/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
--- a/book/src/offline-signing/durable-nonce.md
+++ b/book/src/offline-signing/durable-nonce.md
@ -36,7 +36,7 @@ A nonce account is created by first generating a new keypair, then create the ac

 ```bash
 solana-keygen new -o nonce-keypair.json
-solana create-nonce-account nonce-keypair.json 1
+solana create-nonce-account nonce-keypair.json 1 SOL
 ```

 - Output
@ -64,7 +64,7 @@ presently stored nonce value with
 - Command

 ```bash
-solana nonce nonce-keypair.json
+solana get-nonce nonce-keypair.json 
 ```

 - Output
@ -105,7 +105,7 @@ Inspect a nonce account in a more human friendly format with
 - Command

 ```bash
-solana nonce-account nonce-keypair.json
+solana show-nonce-account nonce-keypair.json 
 ```

 - Output
@ -117,7 +117,7 @@ nonce: DZar6t2EaCFQTbUP4DHKwZ1wT8gCPW2aRfkVWhydkBvS
 ```

 {% hint style="info" %}
-[Full usage documentation](../api-reference/cli.md#solana-nonce-account)
+[Full usage documentation](../api-reference/cli.md#solana-show-nonce-account)
 {% endhint %}

 ### Withdraw Funds from a Nonce Account
@ -127,7 +127,7 @@ Withdraw funds from a nonce account with
 - Command

 ```bash
-solana withdraw-from-nonce-account nonce-keypair.json ~/.config/solana/id.json 0.5
+solana withdraw-from-nonce-account nonce-keypair.json ~/.config/solana/id.json 0.5 SOL
 ```

 - Output
@ -151,7 +151,7 @@ Reassign the authority of a nonce account after creation with
 - Command

 ```bash
-solana authorize-nonce-account nonce-keypair.json nonce-authority.json
+solana authorize-nonce-account nonce-keypair.json nonce-authority.json 
 ```

 - Output
@ -197,7 +197,7 @@ 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
+$ solana airdrop -k alice.json 10 SOL
 10 SOL
 ```

@ -211,7 +211,7 @@ has full authority over the nonce account
 {% endhint %}

 ```bash
-$ solana create-nonce-account -k alice.json nonce.json 1
+$ solana create-nonce-account -k alice.json nonce.json 1 SOL
 3KPZr96BTsL3hqera9up82KAU462Gz31xjqJ6eHUAjF935Yf8i1kmfEbo6SVbNaACKE5z6gySrNjVRvmS8DcPuwV
 ```

@ -221,7 +221,7 @@ 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
+$ solana pay -k alice.json --blockhash expiredDTaxfagttWjQweib42b6ZHADSx94Tw8gHx3W7 bob.json 1 SOL
 [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" })
 ```
@ -236,13 +236,13 @@ Remember, `alice.json` is the [nonce authority](#nonce-authority) in this exampl
 {% endhint %}

 ```bash
-$ solana nonce-account nonce.json
+$ solana show-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
+$ solana pay -k alice.json --blockhash F7vmkY3DTaxfagttWjQweib42b6ZHADSx94Tw8gHx3W7 --nonce nonce.json bob.json 1 SOL
 HR1368UKHVZyenmH7yVz5sBAijV6XAPeWbEiXEGVYQorRMcoijeNAbzZqEZiH8cDB8tk65ckqeegFjK8dHwNFgQ
 ```

@ -256,7 +256,7 @@ $ solana balance -k bob.json
 1 SOL
 ```
 ```bash
-$ solana nonce-account nonce.json
+$ solana show-nonce-account nonce.json 
 balance: 1 SOL
 minimum balance required: 0.00136416 SOL
 nonce: 6bjroqDcZgTv6Vavhqf81oBHTv3aMnX19UTB51YhAZnN
--- a/book/src/paper-wallet/installation.md
+++ b/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
--- a/book/src/paper-wallet/usage.md
+++ b/book/src/paper-wallet/usage.md
@ -90,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.
@ -187,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:
@ -250,7 +165,7 @@ trigger a seed phrase input prompt for the stake account and use
 `--ask-seed-phrase keypair` to securely input the funding keypair.

 ```bash
-solana create-stake-account ASK 1 --ask-seed-phrase keypair
+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:
--- a/book/src/programs/README.md
+++ b/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

--- a/book/src/programs/drones.md
+++ b/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
--- a/book/src/programs/tictactoe.md
+++ b/book/src/programs/tictactoe.md
--- a/book/src/proposals/abi-management.md
+++ b/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)
--- a/book/src/proposals/bankless-leader.md
+++ b/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.
+
--- a/book/src/proposals/cluster-test-framework.md
+++ b/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,
--- a/book/src/proposals/simple-payment-and-state-verification.md
+++ b/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.
--- a/book/src/proposals/tick_verification.md
+++ b/book/src/proposals/tick_verification.md
--- a/book/src/proposals/validator-proposal.md
+++ b/book/src/proposals/validator-proposal.md
@ -2,44 +2,24 @@

 ## 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
 * BankForks renamed to Banktree
 * TPU moves to new socket-free crate called solana-tpu.
@ -47,6 +27,8 @@ schedule.
 * 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
--- a/book/src/running-archiver.md
+++ b/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 spy --entrypoint testnet.solana.com:8001
 # 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 spy --entrypoint testnet.solana.com:8001
 ```

-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
 ```
--- a/book/src/running-validator/README.md
+++ b/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.
--- a/book/src/running-validator/validator-monitor.md
+++ b/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 spy --entrypoint testnet.solana.com:8001
 ```

 ## 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
 ```


--- a/book/src/running-validator/validator-software.md
+++ b/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
 ```

--- a/book/src/running-validator/validator-stake.md
+++ b/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-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.
--- a/book/src/running-validator/validator-start.md
+++ b/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 spy --entrypoint testnet.solana.com:8001
 # 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.
--- a/book/src/running-validator/validator-testnet.md
+++ b/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.
--- a/book/src/terminology.md
+++ b/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).
--- a/book/src/transaction.md
+++ b/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.
--- a/book/src/validator/tvu/README.md
+++ b/book/src/validator/tvu/README.md
--- a/book/src/validator/tvu/blockstore.md
+++ b/book/src/validator/tvu/blockstore.md
--- a/chacha-cuda/Cargo.toml
+++ b/chacha-cuda/Cargo.toml
@ -1,24 +0,0 @@
-[package]
-name = "solana-chacha-cuda"
-version = "0.23.6"
-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 = "0.23.6" }
-solana-chacha = { path = "../chacha", version = "0.23.6" }
-solana-ledger = { path = "../ledger", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-perf = { path = "../perf", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
-
-[dev-dependencies]
-hex-literal = "0.2.1"
-
-[lib]
-name = "solana_chacha_cuda"
--- a/chacha-cuda/src/lib.rs
+++ b/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;
--- a/chacha-sys/Cargo.toml
+++ b/chacha-sys/Cargo.toml
@ -1,6 +1,6 @@
 [package]
 name = "solana-chacha-sys"
-version = "0.23.6"
+version = "0.22.9"
 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"
--- a/chacha/.gitignore
+++ b/chacha/.gitignore
@ -1 +0,0 @@
-/farf/
--- a/chacha/Cargo.toml
+++ b/chacha/Cargo.toml
@ -1,25 +0,0 @@
-[package]
-name = "solana-chacha"
-version = "0.23.6"
-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 = "0.23.6" }
-solana-ledger = { path = "../ledger", version = "0.23.6" }
-solana-logger = { path = "../logger", version = "0.23.6" }
-solana-perf = { path = "../perf", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
-
-[dev-dependencies]
-hex-literal = "0.2.1"
-
-[lib]
-name = "solana_chacha"
--- a/chacha/src/lib.rs
+++ b/chacha/src/lib.rs
@ -1,8 +0,0 @@
-#[macro_use]
-extern crate log;
-
-#[cfg(test)]
-#[macro_use]
-extern crate hex_literal;
-
-pub mod chacha;
--- a/ci/docker-run.sh
+++ b/ci/docker-run.sh
@ -78,9 +78,7 @@ ARGS+=(
 # 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))
+CODECOV_ENVS=$(CI=true bash <(curl -s https://codecov.io/env))

 if $INTERACTIVE; then
  if [[ -n $1 ]]; then
--- a/ci/docker-rust-nightly/Dockerfile
+++ b/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 \
--- a/ci/docker-rust/Dockerfile
+++ b/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 \
--- a/ci/localnet-sanity.sh
+++ b/ci/localnet-sanity.sh
@ -29,7 +29,7 @@ Start a local cluster and run sanity on it
   -x          - Add an extra validator (may be supplied multiple times)
   -r          - Select the RPC endpoint hosted by a node that starts as
                 a validator node.  If unspecified the RPC endpoint hosted by
-                 the bootstrap validator will be used.
+                 the bootstrap leader will be used.
   -c          - Reuse existing node/ledger configuration from a previous sanity
                 run

@ -74,7 +74,7 @@ source multinode-demo/common.sh

 nodes=(
  "multinode-demo/faucet.sh"
-  "multinode-demo/bootstrap-validator.sh \
+  "multinode-demo/bootstrap-leader.sh \
    --no-restart \
    --init-complete-file init-complete-node1.log \
    --dynamic-port-range 8000-8050"
@ -170,7 +170,7 @@ startNodes() {
      logs+=("$(getNodeLogFile "$i" "$cmd")")
    fi

-    # 1 == bootstrap validator, wait until it boots before starting
+    # 1 == bootstrap leader, wait until it boots before starting
    # other validators
    if [[ "$i" -eq 1 ]]; then
      SECONDS=
@ -178,8 +178,8 @@ startNodes() {

      (
        set -x
-        $solana_cli --keypair config/bootstrap-validator/identity-keypair.json \
-          --url http://127.0.0.1:8899 genesis-hash
+        $solana_cli --keypair config/bootstrap-leader/identity-keypair.json \
+          --url http://127.0.0.1:8899 get-genesis-hash
      ) | tee genesis-hash.log
      maybeExpectedGenesisHash="--expected-genesis-hash $(tail -n1 genesis-hash.log)"
    fi
@ -277,7 +277,7 @@ rollingNodeRestart() {
 }

 verifyLedger() {
-  for ledger in bootstrap-validator validator; do
+  for ledger in bootstrap-leader validator; do
    echo "--- $ledger ledger verification"
    (
      set -x
@ -331,7 +331,7 @@ while [[ $iteration -le $iterations ]]; do
    rm -rf $client_keypair
  ) || flag_error

-  echo "--- RPC API: bootstrap-validator getTransactionCount ($iteration)"
+  echo "--- RPC API: bootstrap-leader getTransactionCount ($iteration)"
  (
    set -x
    curl --retry 5 --retry-delay 2 --retry-connrefused \
@ -351,7 +351,7 @@ while [[ $iteration -le $iterations ]]; do
      http://localhost:18899
  ) || flag_error

-  # Verify transaction count as reported by the bootstrap-validator node is advancing
+  # Verify transaction count as reported by the bootstrap-leader node is advancing
  transactionCount=$(sed -e 's/{"jsonrpc":"2.0","result":\([0-9]*\),"id":1}/\1/' log-transactionCount.txt)
  if [[ -n $lastTransactionCount ]]; then
    echo "--- Transaction count check: $lastTransactionCount < $transactionCount"
--- a/ci/nits.sh
+++ b/ci/nits.sh
@ -20,7 +20,6 @@ declare prints=(
 declare print_free_tree=(
  'core/src'
  'faucet/src'
-  'ledger/src'
  'metrics/src'
  'net-utils/src'
  'runtime/src'
--- a/ci/publish-book.sh
+++ b/ci/publish-book.sh
@ -8,6 +8,7 @@ me=$(basename "$0")
 echo --- update gitbook-cage
 if [[ -n $CI_BRANCH ]]; then
  (
+
    set -x
    (
      . ci/rust-version.sh stable
@ -24,8 +25,74 @@ if [[ -n $CI_BRANCH ]]; then
      git reset --hard HEAD~
    fi
  )
-else
-  echo CI_BRANCH not set
 fi

+
+source ci/rust-version.sh stable
+eval "$(ci/channel-info.sh)"
+
+if [[ -n $PUBLISH_BOOK_TAG ]]; then
+  CURRENT_TAG="$(git describe --tags)"
+  COMMIT_TO_PUBLISH="$(git rev-list -n 1 "${PUBLISH_BOOK_TAG}")"
+
+  # book is manually published at a specified release tag
+  if [[ $PUBLISH_BOOK_TAG != "$CURRENT_TAG" ]]; then
+    (
+      cat <<EOF
+steps:
+  - trigger: "$BUILDKITE_PIPELINE_SLUG"
+    async: true
+    build:
+      message: "$BUILDKITE_MESSAGE"
+      commit: "$COMMIT_TO_PUBLISH"
+      env:
+        PUBLISH_BOOK_TAG: "$PUBLISH_BOOK_TAG"
+EOF
+    ) | buildkite-agent pipeline upload
+    exit 0
+  fi
+  repo=git@github.com:solana-labs/book.git
+  BOOK="book"
+else
+  # book-edge and book-beta are published automatically on the tip of the branch
+  case $CHANNEL in
+  edge)
+    repo=git@github.com:solana-labs/book-edge.git
+    ;;
+  beta)
+    repo=git@github.com:solana-labs/book-beta.git
+    ;;
+  *)
+   echo "--- publish skipped"
+   exit 0
+   ;;
+  esac
+  BOOK=$CHANNEL
+fi
+
+ci/docker-run.sh "$rust_stable_docker_image" bash -exc "book/build.sh"
+
+echo --- create book repo
+(
+  set -x
+  cd book/html/
+  git init .
+  git add ./* ./.nojekyll
+  git config user.email maintainers@solana.com
+  git config user.name "$me"
+  git commit -m "${CI_COMMIT:-local}"
+)
+
+echo "--- publish $BOOK"
+(
+  cd book/html/
+  git remote add origin $repo
+  git fetch origin master
+  if ! git diff HEAD origin/master --quiet; then
+    git push -f origin HEAD:master
+  else
+    echo "Content unchanged, publish skipped"
+  fi
+)
+
 exit 0
--- a/ci/rust-version.sh
+++ b/ci/rust-version.sh
@ -16,13 +16,13 @@
 if [[ -n $RUST_STABLE_VERSION ]]; then
  stable_version="$RUST_STABLE_VERSION"
 else
-  stable_version=1.41.0
+  stable_version=1.40.0
 fi

 if [[ -n $RUST_NIGHTLY_VERSION ]]; then
  nightly_version="$RUST_NIGHTLY_VERSION"
 else
-  nightly_version=2020-02-06
+  nightly_version=2019-12-19
 fi


--- a/ci/test-checks.sh
+++ b/ci/test-checks.sh
@ -22,7 +22,7 @@ _ cargo +"$rust_stable" clippy --all --exclude solana-sdk-c -- --deny=warnings
 _ cargo +"$rust_stable" clippy --manifest-path sdk-c/Cargo.toml -- --deny=warnings

 _ cargo +"$rust_stable" audit --version
-_ cargo +"$rust_stable" audit --ignore RUSTSEC-2020-0002
+_ cargo +"$rust_stable" audit --ignore RUSTSEC-2019-0013 --ignore RUSTSEC-2018-0015 --ignore RUSTSEC-2019-0031 --ignore RUSTSEC-2020-0002
 _ ci/nits.sh
 _ ci/order-crates-for-publishing.py
 _ book/build.sh
@ -30,7 +30,7 @@ _ ci/check-ssh-keys.sh

 {
  cd programs/bpf
-  _ cargo +"$rust_stable" audit
+  _ cargo +"$rust_stable" audit --ignore RUSTSEC-2019-0031
  for project in rust/*/ ; do
    echo "+++ do_bpf_checks $project"
    (
--- a/ci/test-coverage.sh
+++ b/ci/test-coverage.sh
@ -42,9 +42,7 @@ if [[ -z "$CODECOV_TOKEN" ]]; then
  echo CODECOV_TOKEN undefined, codecov.io upload skipped
 else
  # 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
-  CI=true bash <(while ! curl -sS --retry 5 --retry-delay 2 --retry-connrefused https://codecov.io/bash; do sleep 10; done) -Z -X gcov -f target/cov/lcov.info
+  CI=true bash <(curl -s https://codecov.io/bash) -X gcov -f target/cov/lcov.info

  annotate --style success --context codecov.io \
    "CodeCov report: https://codecov.io/github/solana-labs/solana/commit/${CI_COMMIT:0:9}"
--- a/ci/test-stable.sh
+++ b/ci/test-stable.sh
@ -86,7 +86,7 @@ test-stable-perf)
  fi

  _ cargo +"$rust_stable" build --bins ${V:+--verbose}
-  _ cargo +"$rust_stable" test --package solana-chacha-cuda --package solana-perf --package solana-ledger --package solana-core --lib ${V:+--verbose} -- --nocapture
+  _ cargo +"$rust_stable" test --package solana-perf --package solana-ledger --package solana-core --lib ${V:+--verbose} -- --nocapture
  ;;
 test-move)
  ci/affects-files.sh \
--- a/ci/testnet-manager.sh
+++ b/ci/testnet-manager.sh
@ -206,7 +206,6 @@ steps:
        TESTNET_DB_HOST: "$TESTNET_DB_HOST"
        GCE_NODE_COUNT: "$GCE_NODE_COUNT"
        GCE_LOW_QUOTA_NODE_COUNT: "$GCE_LOW_QUOTA_NODE_COUNT"
-        RUST_LOG: "$RUST_LOG"
 EOF
    ) | buildkite-agent pipeline upload
    exit 0
@ -234,7 +233,7 @@ sanity() {
    (
      set -x
      NO_INSTALL_CHECK=1 \
-        ci/testnet-sanity.sh edge-devnet-solana-com gce -P us-west1-b
+        ci/testnet-sanity.sh edge-testnet-solana-com gce -P us-west1-b
      maybe_deploy_software
    )
    ;;
@ -249,7 +248,7 @@ sanity() {
    (
      set -x
      NO_INSTALL_CHECK=1 \
-        ci/testnet-sanity.sh beta-devnet-solana-com gce -P us-west1-b
+        ci/testnet-sanity.sh beta-testnet-solana-com gce -P us-west1-b
      maybe_deploy_software --deploy-if-newer
    )
    ;;
@ -263,7 +262,7 @@ sanity() {
  testnet)
    (
      set -x
-      ci/testnet-sanity.sh devnet-solana-com gce -P us-west1-b
+      ci/testnet-sanity.sh testnet-solana-com gce -P us-west1-b
    )
    ;;
  testnet-perf)
@ -327,9 +326,9 @@ deploy() {
  testnet-edge)
    (
      set -x
-      ci/testnet-deploy.sh -p edge-devnet-solana-com -C gce -z us-west1-b \
+      ci/testnet-deploy.sh -p edge-testnet-solana-com -C gce -z us-west1-b \
        -t "$CHANNEL_OR_TAG" -n 3 -c 0 -u -P \
-        -a edge-devnet-solana-com --letsencrypt edge.devnet.solana.com \
+        -a edge-testnet-solana-com --letsencrypt edge.testnet.solana.com \
        --limit-ledger-size \
        ${skipCreate:+-e} \
        ${skipStart:+-s} \
@ -352,9 +351,9 @@ deploy() {
  testnet-beta)
    (
      set -x
-      ci/testnet-deploy.sh -p beta-devnet-solana-com -C gce -z us-west1-b \
+      ci/testnet-deploy.sh -p beta-testnet-solana-com -C gce -z us-west1-b \
        -t "$CHANNEL_OR_TAG" -n 3 -c 0 -u -P \
-        -a beta-devnet-solana-com --letsencrypt beta.devnet.solana.com \
+        -a beta-testnet-solana-com --letsencrypt beta.testnet.solana.com \
        --limit-ledger-size \
        ${skipCreate:+-e} \
        ${skipStart:+-s} \
@ -377,9 +376,9 @@ deploy() {
  testnet)
    (
      set -x
-      ci/testnet-deploy.sh -p devnet-solana-com -C gce -z us-west1-b \
-        -t "$CHANNEL_OR_TAG" -n 0 -c 0 -u -P \
-        -a testnet-solana-com --letsencrypt devnet.solana.com \
+      ci/testnet-deploy.sh -p testnet-solana-com -C gce -z us-west1-b \
+        -t "$CHANNEL_OR_TAG" -n 1 -c 0 -u -P \
+        -a testnet-solana-com --letsencrypt testnet.solana.com \
        --limit-ledger-size \
        ${skipCreate:+-e} \
        ${skipStart:+-s} \
@ -389,7 +388,7 @@ deploy() {
    (
      echo "--- net.sh update"
      set -x
-      time net/net.sh update -t "$CHANNEL_OR_TAG" --platform linux --platform osx #--platform windows
+      time net/net.sh update -t "$CHANNEL_OR_TAG" --platform linux --platform osx --platform windows
    )
    ;;
  testnet-perf)
@ -455,10 +454,6 @@ deploy() {
        TDS_CLIENT_COUNT="1"
      fi

-      if [[ -n $TDS_SLOTS_PER_EPOCH ]]; then
-        maybeSlotsPerEpoch=(--slots-per-epoch "$TDS_SLOTS_PER_EPOCH")
-      fi
-
      if [[ -z $ENABLE_GPU ]]; then
        maybeGpu=(-G "--machine-type n1-standard-16 --accelerator count=2,type=nvidia-tesla-v100")
      elif [[ $ENABLE_GPU == skip ]]; then
@ -544,7 +539,7 @@ deploy() {
        ${maybeInternalNodesLamports} \
        ${maybeExternalAccountsFile} \
        --target-lamports-per-signature 0 \
-        "${maybeSlotsPerEpoch[@]}" \
+        --slots-per-epoch 4096 \
        ${maybeAdditionalDisk}
    )
    ;;
--- a/clap-utils/Cargo.toml
+++ b/clap-utils/Cargo.toml
@ -1,6 +1,6 @@
 [package]
 name = "solana-clap-utils"
-version = "0.23.6"
+version = "0.22.9"
 description = "Solana utilities for the clap"
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 repository = "https://github.com/solana-labs/solana"
@ -11,9 +11,9 @@ edition = "2018"
 [dependencies]
 clap = "2.33.0"
 rpassword = "4.0"
-solana-remote-wallet = { path = "../remote-wallet", version = "0.23.6" }
-solana-sdk = { path = "../sdk", version = "0.23.6" }
-tiny-bip39 = "0.7.0"
+semver = "0.9.0"
+solana-sdk = { path = "../sdk", version = "0.22.9" }
+tiny-bip39 = "0.6.2"
 url = "2.1.0"
 chrono = "0.4"

--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
mergify[bot]	3534a7cbc7	Datapoints overwhelm the metrics queue and blow up ram usage. (#8272 ) (#8282 ) automerge	2020-02-14 21:49:26 -08:00
Michael Vines	e2f5a63316	Cargo.lock	2020-02-14 21:24:05 -07:00
Michael Vines	6475314ede	Bump version to 0.22.9	2020-02-14 19:58:16 -07:00
mergify[bot]	535ee281e8	Filter old CrdsValues received via Pull Responses in Gossip (#8150 ) (#8277 ) automerge	2020-02-14 10:21:26 -08:00
mergify[bot]	da843a7ace	Fix larger than necessary allocations in streamer (#8187 ) (#8191 ) automerge	2020-02-10 12:52:16 -08:00
Michael Vines	772cf8288c	Bump version to 0.22.8	2020-02-03 21:08:54 -07:00
Michael Vines	e81a40ba55	Lock snapshot version to 0.22.6	2020-02-03 17:06:29 -07:00
Michael Vines	a52359a6be	Cargo.lock	2020-02-03 17:05:35 -07:00
sakridge	2fe0853fba	Fix consensus threshold when new root is created (#8093 ) When a new root is created, the oldest slot is popped off but when the logic checks for identical slots, it assumes that any difference means a slot was popped off the front.	2020-02-03 16:47:02 -07:00
Sagar Dhawan	de3630f76c	Filter repairman peers based on shred_version (#8069 ) (cherry picked from commit `b9988b62e4`)	2020-02-01 08:58:26 -07:00
carllin	ff9e388843	Fix stale gossip entrypoint (#8053 ) (cherry picked from commit `fd207b6907`)	2020-01-31 00:34:29 -07:00
Michael Vines	67a7995f04	Bump version to 0.22.7	2020-01-30 15:47:22 -07:00
Michael Vines	f9d793023c	Only error if --expected-shred-version was not provided	2020-01-30 13:25:25 -07:00
Michael Vines	99b2504b38	Rename rpc_peers() to all_rpc_peers() for consistency	2020-01-30 13:21:04 -07:00
Michael Vines	3f3aec29d1	Add different shred test to test_tvu_peers_and_stakes (cherry picked from commit `0c55b37976`)	2020-01-30 11:28:18 -07:00
Justin Starry	7be8124b9e	Ignore slow archiver tests (#8032 ) automerge (cherry picked from commit `400412d76c`)	2020-01-30 09:38:53 -07:00
Sagar Dhawan	81259daa3f	Add shred version filters to Crds Accessors (#8027 ) * Add shred version filters to Crds Accessors * Adopt entrypoint shred_version if one isn't provided (cherry picked from commit `64c42e28dc`)	2020-01-30 08:59:00 -07:00
Michael Vines	136fa5b561	Add leader-schedule subcommand	2020-01-29 20:08:32 -07:00
Michael Vines	63ca6118fa	Add --expected-shred-version option	2020-01-29 20:08:32 -07:00
Michael Vines	850d729739	Wait for supermajority by default, add --no-wait-for-supermajority flag to override	2020-01-29 20:08:32 -07:00
Michael Vines	62f9183d17	getClusterNodes now excludes validators with a different shred version	2020-01-29 20:08:32 -07:00
Justin Starry	cfe3481ba4	Log solana-validator args on startup to aid debugging (cherry picked from commit `effe6e3ff3`)	2020-01-29 09:40:18 -07:00
Michael Vines	788e9f321c	Bump version to v0.22.6	2020-01-28 08:44:44 -07:00
Michael Vines	265e88e734	Fix compute_shred_version()	2020-01-27 19:05:17 -07:00
Michael Vines	e80c74d955	Drop v prefix	2020-01-27 19:05:17 -07:00
Michael Vines	d3efe2317b	Remove stray key	2020-01-26 14:36:00 -07:00
Michael Vines	05a661dd88	Bump version to v0.22.5	2020-01-24 21:52:01 -07:00
Michael Vines	84090df770	Bump perf libs to v0.18.0 for CUDA 10.2 support	2020-01-24 21:38:51 -07:00
Stephen Akridge	3f7fe04124	Consensus fix, don't consider threshold check if lockouts are not increased	2020-01-24 21:34:16 -07:00
mergify[bot]	ac4e3c2426	Add ability to hard fork at any slot (#7801 ) (#7970 ) automerge	2020-01-24 18:57:08 -08:00
Jack May	13af049988	Install move-loader binaries (#7768 ) (cherry picked from commit `5cb23c814d`)	2020-01-24 18:13:03 -07:00
Michael Vines	bd07f9bdcb	Move testnet.solana.com and TdS to their own GCP projects	2020-01-24 16:28:04 -07:00
mergify[bot]	82927fee20	Increase --wait-for-supermajority to wait for 75% online stake (#7957 ) automerge	2020-01-23 23:03:13 -08:00
Michael Vines	57d5534bab	Add create-snapshot command	2020-01-23 22:21:36 -07:00
Michael Vines	d2c15b596f	Add BlockstoreProcessorResult	2020-01-23 21:03:57 -07:00
Michael Vines	5d8dc78718	Move snapshot archive generation out of the SnapshotPackagerService	2020-01-23 15:58:59 -07:00
Michael Vines	c945e80618	Type grooming	2020-01-23 15:58:59 -07:00
Michael Vines	0802793d37	Unify ledger_path arg handling with validator/	2020-01-23 15:58:59 -07:00
Michael Vines	a5c3750a58	Pass bank_forks by reference	2020-01-23 15:58:59 -07:00
Michael Vines	dc1c5f8b1e	--halt-at-slot 1 now halts at slot 1	2020-01-23 15:58:59 -07:00
Michael Vines	653bec01f0	Set BankRc slot correctly when restoring a bank snapshot	2020-01-23 15:58:59 -07:00
Michael Vines	49c94fad60	add_snapshot now returns SlotSnapshotPaths	2020-01-23 15:58:59 -07:00
Michael Vines	98fd1b3fcb	Remove superfluous accounts arg	2020-01-23 15:58:59 -07:00
mergify[bot]	93301d1c81	Make run.sh not overwrite genesis if existing (#7837 ) (#7939 ) automerge	2020-01-22 23:38:41 -08:00
mergify[bot]	5aa8ee8ede	Uninteresting cleanup (#7938 ) automerge	2020-01-22 21:16:25 -08:00
mergify[bot]	28f81bd0a3	Avoid unsorted recent_blockhashes for determinism (#7918 ) (#7936 ) automerge	2020-01-22 18:52:39 -08:00
Michael Vines	1f4ae4318b	Reject CI on failed mergify.io backports (#7927 ) automerge (cherry picked from commit `9bd6be779f`)	2020-01-22 16:11:07 -07:00
mergify[bot]	bec1cf3145	CLI: Cleanup authority arg usage inconsistencies (#7922 ) (#7924 ) automerge	2020-01-22 14:09:26 -08:00
Michael Vines	5b4b086ebf	Add mechanism to load v0.22.3 snapshots on newer Solana versions	2020-01-22 13:19:07 -07:00
Michael Vines	0ef33b6462	don't put accounts in a weird location, use the defaults (#7921 ) automerge (cherry picked from commit `f9323c5273`)	2020-01-22 12:58:06 -07:00
mergify[bot]	e401bc6997	CLI: Support offline authorities (#7905 ) (#7920 ) automerge	2020-01-22 10:57:16 -08:00
mergify[bot]	8ffd2c12a3	Add and use minimumLedgerSlot RPC API in block-production command (bp #7901 ) (#7903 ) automerge	2020-01-21 14:07:32 -08:00
mergify[bot]	ec4134f26d	Revert "Generate MAX_DATA_SHREDS_PER_FEC_BLOCK coding shreds for each FEC block (#7474 )" (#7898 ) (#7899 ) automerge	2020-01-21 12:40:42 -08:00
mergify[bot]	35e7b2f975	Remove redundant threadpools in sigverify (bp #7888 ) (#7890 ) automerge	2020-01-20 21:31:56 -08:00
Michael Vines	3509f1158f	Assume 1 or more validators	2020-01-20 19:19:29 -07:00
mergify[bot]	1ca33d1967	--limit-ledger-size now accepts an optional slot count value (#7885 ) automerge	2020-01-20 14:22:37 -08:00
mergify[bot]	19474ecaae	Create ledger directory if it doesn't already exist (#7878 ) automerge	2020-01-20 10:41:40 -08:00
Michael Vines	e317940ebc	Try running testnet.solana.com with only two validators	2020-01-20 10:23:43 -07:00
mergify[bot]	fbbfa93524	Spy just for RPC to avoid premature supermajority (#7856 ) (#7875 ) automerge	2020-01-19 18:51:13 -08:00
mergify[bot]	c759a04fbc	If a bad RPC node is selected try another one instead of aborting (#7871 ) automerge	2020-01-18 10:52:15 -08:00
Michael Vines	d1d37db717	Abort if a snapshot download fails for any reason other than 404 (cherry picked from commit `e28508ad56`)	2020-01-18 09:35:43 -07:00
mergify[bot]	4904b6a532	CLI: Support offline and nonced stake subcommands (#7831 ) (#7861 ) automerge	2020-01-17 13:10:38 -08:00
mergify[bot]	f80a657764	Nonce: Rename instructions with VerbNoun scheme (#7775 ) (#7778 ) automerge	2020-01-17 10:48:33 -08:00
mergify[bot]	344c528b63	Reduce grace ticks, and ignore grace ticks for missing leaders (#7764 ) (#7779 ) automerge	2020-01-16 19:57:41 -08:00
mergify[bot]	ee1300a671	Improve bench-tps keypair generation (#7723 ) (#7853 ) automerge	2020-01-16 19:30:00 -08:00
mergify[bot]	6c2534a8be	Add logging surrounding failure in `get_slot_entries_with_shred_info()` (#7846 ) (#7851 ) automerge	2020-01-16 17:27:52 -08:00
Michael Vines	28a979c7d3	Cargo.lock	2020-01-16 16:34:33 -07:00
mergify[bot]	d071674b03	ignore prost is part of move (#7848 ) (#7850 ) automerge	2020-01-16 15:24:05 -08:00
Michael Vines	8c5f676df0	Bump version to 0.22.4	2020-01-15 18:55:50 -07:00
Tyera Eulberg	6f098e0145	Fix Rpc inconsistencies (#7826 ) * Update rpc account format: remove byte arrays * Base58-encode pubkeys in getStoragePubkeysForSlot * Update docs (cherry picked from commit `da165d6943`)	2020-01-15 16:56:14 -07:00
mergify[bot]	f90bc20a8b	CLI: Plumb stake authorities throughout (#7822 ) (#7830 ) automerge	2020-01-15 15:29:47 -08:00
mergify[bot]	60074c9d36	Remove tuple from programNotification (#7819 ) (#7821 ) automerge	2020-01-15 12:13:12 -08:00
Dan Albert	5d9354fca7	Remove word pair from address generator seed string (#7802 ) (#7823 ) * Remove word pair from address generator seed string	2020-01-15 14:48:21 -05:00
mergify[bot]	0ea09d75ed	Add new genesis validators (#7814 ) (#7817 ) automerge	2020-01-15 10:22:54 -08:00
mergify[bot]	f475a46df6	Prefer CUDA_HOME environment variable (#7813 ) automerge	2020-01-15 08:51:35 -08:00
mergify[bot]	5681a24896	Remove tuples from JSON RPC responses (#7806 ) (#7811 ) automerge	2020-01-15 00:32:03 -08:00
mergify[bot]	214aba6d2f	Set bootstrap leader and net/ validator vote account commission to 100% (#7810 ) automerge	2020-01-15 00:25:10 -08:00
mergify[bot]	fa551e5fc1	Fix cluster collapse due to no proper shifted read (#7797 ) (#7807 ) automerge	2020-01-14 19:48:36 -08:00
sakridge	d9a5a86d10	Add hash stats information to check hashes between validators (#7780 ) automerge	2020-01-14 17:55:46 -07:00
Ryo Onodera	83ad921ad6	Rename slot_hash => bank_hash in AcoountsDB (#7579 ) * Rename slot_hash => bank_hash in AcoountsDB	2020-01-14 17:55:46 -07:00
mergify[bot]	5753c719bd	Include shred version in gossip (#7800 ) automerge	2020-01-14 14:30:10 -08:00
mergify[bot]	322e2e0c6a	Improve KeypairFileNotFound error message (#7792 ) (#7794 ) automerge	2020-01-14 13:05:20 -08:00
mergify[bot]	371fdc6495	Book: Drop since-fixed nonce known issue (#7789 ) (#7790 ) automerge	2020-01-14 10:18:20 -08:00
mergify[bot]	d23f2b5754	Unignore advisories as affected ver. is corrected (#7730 ) (#7783 ) automerge	2020-01-13 19:01:23 -08:00
mergify[bot]	a50a015542	Rename blocktree to blockstore (bp #7757 ) (#7771 ) automerge	2020-01-13 16:15:22 -08:00
mergify[bot]	353cfb1980	Update getConfirmedBlock examples (#7772 ) (#7773 ) automerge	2020-01-13 14:35:31 -08:00
mergify[bot]	79d737e760	Book: Update durable nonce proposal entry (#7694 ) (#7770 ) automerge	2020-01-13 13:39:38 -08:00
mergify[bot]	8745034cec	getConfirmedBlock: add encoding optional parameter (#7756 ) (#7767 ) automerge	2020-01-12 22:27:09 -08:00
mergify[bot]	db979b30c4	Pick an RPC node at random to avoid getting stuck on a bad RPC node (#7763 ) automerge	2020-01-12 20:24:03 -08:00
mergify[bot]	a92855c995	Manage durable nonce stored value in runtime (#7684 ) (#7760 ) automerge	2020-01-10 17:11:47 -08:00
mergify[bot]	5b006eba57	Handle errors on replaying ledger properly (bp #7741 ) (#7755 ) automerge	2020-01-10 15:17:54 -08:00
mergify[bot]	32a728d585	Clarify account creation error messages in CLI (bp #7719 ) (#7745 ) automerge	2020-01-10 07:02:11 -08:00
mergify[bot]	1b3be91e3c	Update http crate in bpf program to fix security vulnerability (#7735 ) (#7743 ) automerge	2020-01-09 20:53:56 -08:00
mergify[bot]	2509002fe4	Print bank hash and hash inputs. (#7733 ) (#7734 ) automerge	2020-01-09 17:13:31 -08:00
mergify[bot]	9c9a690d0d	Correctly integrate buildkite with codecov (#7718 ) (#7727 ) automerge	2020-01-09 13:45:27 -08:00
mergify[bot]	216cc34224	Update http crate to fix security vulnerability (bp #7725 ) (#7729 ) automerge	2020-01-09 12:51:20 -08:00
mergify[bot]	71f1459ef9	Remove vote account from genesis validators (#7717 ) automerge	2020-01-08 22:40:36 -08:00
mergify[bot]	f84bdb7d81	Fix rooted slot iterator (#7695 ) (#7714 ) automerge	2020-01-08 13:23:55 -08:00
mergify[bot]	ed59c58a72	Account for stake held by the current node while waiting for the supermajority to join gossip (#7708 ) automerge	2020-01-07 22:13:44 -08:00
mergify[bot]	de941f4074	validator: Add --wait-for-super-majority to facilitate asynchronous cluster restarts (bp #7701 ) (#7704 ) automerge	2020-01-07 15:48:11 -08:00
mergify[bot]	b7fb050d09	Use commas to make a log message more readable (#7696 ) automerge	2020-01-06 22:12:03 -08:00
Michael Vines	9ee2e768d6	Bump version to 0.22.3	2020-01-06 08:17:56 -07:00
mergify[bot]	d6d3a3c3d8	getBlockTime: Fix RootedSlotIterator lowest root (#7681 ) (#7687 ) automerge	2020-01-05 23:24:34 -08:00
mergify[bot]	3e229b248f	Update getBlockTime rpc docs (#7688 ) (#7689 ) automerge	2020-01-05 23:16:04 -08:00
Tyera Eulberg	0470072436	Cli: fund validator-info accounts with rent-exempt lamports (cherry picked from commit `580ca36a62`)	2020-01-04 23:20:38 -07:00
Michael Vines	f74fa60c8b	Revert "Add a stand-alone gossip node on the blocksteamer instance" This reverts commit `a217920561`. This commit is causing trouble when the TdS cluster is reset and validators running an older genesis config are still present. Occasionally an RPC URL from an older validator will be selected, causing a new node to fail to boot.	2020-01-04 16:44:28 -07:00
Michael Vines	c189767090	Bump version to 0.22.2	2020-01-04 14:17:42 -07:00
mergify[bot]	c82c18353d	Don't panic if peer_addr() fails (#7678 ) (#7679 ) automerge	2020-01-04 10:39:22 -08:00
mergify[bot]	da58a272dd	Set default vote account commission to 100% (#7677 ) automerge	2020-01-04 09:52:33 -08:00
mergify[bot]	001f5fbb6b	bank: Prune older epoch stakes (bp #7668 ) (#7676 ) automerge	2020-01-04 09:32:16 -08:00
Michael Vines	63cd452ab5	Minor book fixes	2020-01-04 08:53:51 -07:00
mergify[bot]	6ee77e9754	Make validator timestamping more coincident, and increase timestamp sample range (#7673 ) (#7674 ) automerge	2020-01-03 23:30:12 -08:00
mergify[bot]	cee22262fc	Move nonce into system program (bp #7645 ) (#7671 ) automerge	2020-01-03 18:33:40 -08:00
mergify[bot]	0d13352916	CLI: Fix default nonce authority resolution (#7657 ) (#7672 ) automerge	2020-01-03 17:18:43 -08:00
mergify[bot]	78a9832f13	Measure heap usage while processing the ledger at validator startup (bp #7667 ) (#7670 ) automerge	2020-01-03 15:43:11 -08:00
Michael Vines	795cf14650	Publish bpf-sdk only in Linux build (cherry picked from commit `078e7246ac`)	2020-01-02 23:22:29 -07:00
mergify[bot]	8c112e8bc4	Publish bpf-sdk releases (#7655 ) (#7662 ) automerge	2020-01-02 21:25:59 -08:00
Michael Vines	8e6d213459	Revert "Remov dead code from TdS testnet manager config (#7414 )" This reverts commit `8920ac02f6`.	2020-01-02 21:07:23 -07:00
mergify[bot]	b33df42640	net: Add a stand-alone gossip node on the blocksteamer instance (bp #7654 ) (#7659 ) automerge	2020-01-02 17:26:40 -08:00
mergify[bot]	e0462e6933	Book - Document nonceable CLI subcommands (#7656 ) (#7660 ) automerge	2020-01-02 17:14:08 -08:00
mergify[bot]	1f5e30a366	Add input validation for --creation-time/--lockup-date args (#7646 ) (#7647 ) automerge	2019-12-30 22:39:51 -08:00
mergify[bot]	633eeb1586	Book: Document CLI durable nonce account management (#7595 ) (#7640 ) automerge	2019-12-30 10:17:23 -08:00
Dan Albert	c1148a6da3	Use lamports in genesis (#7631 ) (#7634 ) automerge	2019-12-29 10:22:28 -08:00
mergify[bot]	713e86670d	Use lamports in genesis (#7631 ) (#7633 ) automerge	2019-12-29 10:17:16 -08:00
mergify[bot]	c004c726e7	Support nonced transactions in the CLI (#7624 ) (#7630 ) automerge	2019-12-27 13:22:06 -08:00
mergify[bot]	5ffb8631e0	Account for rent (#7626 ) (#7627 ) automerge	2019-12-24 18:41:22 -08:00
Michael Vines	fd32a0280e	Cargo.lock	2019-12-24 09:12:11 -07:00
Michael Vines	e76f202eb3	Update gitbook-cage first	2019-12-23 18:17:43 -07:00
Dan Albert	ba4558cb92	Update cargo files to 0.22.1 (#7620 )	2019-12-23 19:42:33 -05:00
Dan Albert	74e5577dd4	Move cleanup to a script so it doesn't kill itself (#7603 ) (#7619 ) automerge	2019-12-23 15:23:47 -08:00
Jack May	b878002cf5	Specify version for solana-sdk-macro to enable crate.io publishing (#7616 )	2019-12-23 12:38:21 -08:00
mergify[bot]	f111250e3b	Groom log messages (#7610 ) (#7614 ) automerge	2019-12-23 10:29:15 -08:00
mergify[bot]	3d91f650db	Fix key in genesis (#7585 ) (#7608 ) automerge	2019-12-22 22:41:01 -08:00
mergify[bot]	91a88cda6a	show-block-production: Rename "missed" to "skipped" as not all skipped slots are missed slots (#7599 ) (#7607 ) (cherry picked from commit `419da18405`) Co-authored-by: Michael Vines <mvines@gmail.com>	2019-12-22 23:21:24 -07:00
mergify[bot]	2128c17ed0	Extend Stable CI job timeout to 60 minutes (#7604 ) (#7606 ) automerge	2019-12-22 19:57:43 -08:00
Michael Vines	7b819c9b74	MISSED -> SKIPPED	2019-12-22 10:19:12 -07:00
Michael Vines	eec5c661af	Remove stray SOLANA_CUDA=1	2019-12-22 10:09:26 -07:00
mergify[bot]	0398f6b87a	ledger-tool: Add --all option to bounds, to display all non-empty slots (#7592 ) (#7598 ) automerge	2019-12-20 21:30:47 -08:00