Fix compute_shred_version() (#7989)

automerge

(cherry picked from commit fd7d5cbe0d)

.mergify.yml

@@ -19,14 +19,6 @@ 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
@@ -43,3 +35,11 @@ pull_request_rules:
       backport:
         branches:
           - v0.23
+  - name: v0.24 backport
+    conditions:
+      - base=master
+      - label=v0.24
+    actions:
+      backport:
+        branches:
+          - v0.24

Cargo.toml

@@ -4,6 +4,8 @@ members = [
     "bench-streamer",
     "bench-tps",
     "banking-bench",
+    "chacha",
+    "chacha-cuda",
     "chacha-sys",
     "client",
     "core",
@@ -38,6 +40,8 @@ members = [
     "programs/vest",
     "programs/vote",
     "archiver",
+    "archiver-lib",
+    "archiver-utils",
     "runtime",
     "sdk",
     "sdk-c",
@@ -45,7 +49,6 @@ members = [
     "sys-tuner",
     "upload-perf",
     "net-utils",
-    "fixed-buf",
     "vote-signer",
     "cli",
     "rayon-threadlimit",

RELEASE.md

@@ -140,25 +140,6 @@ 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.
 
-#### Publish updated Book
-We maintain three copies of the "book" as official documentation:
-
-1) "Book" is the documentation for the latest official release.  This should get manually updated whenever a new release is made.  It is published here:
-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

archiver-lib/Cargo.toml

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

archiver-lib/src/archiver.rs

@@ -1,36 +1,40 @@
-use crate::{
-    chacha::{chacha_cbc_encrypt_ledger, CHACHA_BLOCK_SIZE},
+use crate::result::ArchiverError;
+use crossbeam_channel::unbounded;
+use ed25519_dalek;
+use rand::{thread_rng, Rng, SeedableRng};
+use rand_chacha::ChaChaRng;
+use solana_archiver_utils::sample_file;
+use solana_chacha::chacha::{chacha_cbc_encrypt_ledger, CHACHA_BLOCK_SIZE};
+use solana_client::{
+    rpc_client::RpcClient, rpc_request::RpcRequest, rpc_response::RpcStorageTurn,
+    thin_client::ThinClient,
+};
+use solana_core::{
     cluster_info::{ClusterInfo, Node, VALIDATOR_PORT_RANGE},
     contact_info::ContactInfo,
     gossip_service::GossipService,
     packet::{limited_deserialize, PACKET_DATA_SIZE},
     repair_service,
     repair_service::{RepairService, RepairSlotRange, RepairStrategy},
-    result::{Error, Result},
     shred_fetch_stage::ShredFetchStage,
     sigverify_stage::{DisabledSigVerifier, SigVerifyStage},
     storage_stage::NUM_STORAGE_SAMPLES,
     streamer::{receiver, responder, PacketReceiver},
     window_service::WindowService,
 };
-use crossbeam_channel::unbounded;
-use ed25519_dalek;
-use rand::{thread_rng, Rng, SeedableRng};
-use rand_chacha::ChaChaRng;
-use solana_client::{rpc_client::RpcClient, rpc_request::RpcRequest, thin_client::ThinClient};
 use solana_ledger::{
-    blocktree::Blocktree, leader_schedule_cache::LeaderScheduleCache, shred::Shred,
+    blockstore::Blockstore, leader_schedule_cache::LeaderScheduleCache, shred::Shred,
 };
 use solana_net_utils::bind_in_range;
 use solana_perf::packet::Packets;
 use solana_perf::recycler::Recycler;
 use solana_sdk::packet::Packet;
 use solana_sdk::{
-    account_utils::State,
+    account_utils::StateMut,
     client::{AsyncClient, SyncClient},
     clock::{get_complete_segment_from_slot, get_segment_from_slot, Slot},
     commitment_config::CommitmentConfig,
-    hash::{Hash, Hasher},
+    hash::Hash,
     message::Message,
     signature::{Keypair, KeypairUtil, Signature},
     timing::timestamp,
@@ -42,9 +46,7 @@ use solana_storage_program::{
     storage_instruction::{self, StorageAccountType},
 };
 use std::{
-    fs::File,
-    io::{self, BufReader, ErrorKind, Read, Seek, SeekFrom},
-    mem::size_of,
+    io::{self, ErrorKind},
     net::{SocketAddr, UdpSocket},
     path::{Path, PathBuf},
     result,
@@ -55,6 +57,8 @@ use std::{
     time::Duration,
 };
 
+type Result<T> = std::result::Result<T, ArchiverError>;
+
 static ENCRYPTED_FILENAME: &str = "ledger.enc";
 
 #[derive(Serialize, Deserialize)]
@@ -82,41 +86,6 @@ struct ArchiverMeta {
     client_commitment: CommitmentConfig,
 }
 
-pub(crate) 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())
-}
-
 fn get_slot_from_signature(
     signature: &ed25519_dalek::Signature,
     storage_turn: u64,
@@ -222,13 +191,13 @@ impl Archiver {
         // Note for now, this ledger will not contain any of the existing entries
         // in the ledger located at ledger_path, and will only append on newly received
         // entries after being passed to window_service
-        let blocktree = Arc::new(
-            Blocktree::open(ledger_path).expect("Expected to be able to open database ledger"),
+        let blockstore = Arc::new(
+            Blockstore::open(ledger_path).expect("Expected to be able to open database ledger"),
         );
 
         let gossip_service = GossipService::new(
             &cluster_info,
-            Some(blocktree.clone()),
+            Some(blockstore.clone()),
             None,
             node.sockets.gossip,
             &exit,
@@ -236,16 +205,16 @@ impl Archiver {
 
         info!("Connecting to the cluster via {:?}", cluster_entrypoint);
         let (nodes, _) =
-            match crate::gossip_service::discover_cluster(&cluster_entrypoint.gossip, 1) {
+            match solana_core::gossip_service::discover_cluster(&cluster_entrypoint.gossip, 1) {
                 Ok(nodes_and_archivers) => nodes_and_archivers,
                 Err(e) => {
                     //shutdown services before exiting
                     exit.store(true, Ordering::Relaxed);
                     gossip_service.join()?;
-                    return Err(Error::from(e));
+                    return Err(e.into());
                 }
             };
-        let client = crate::gossip_service::get_client(&nodes);
+        let client = solana_core::gossip_service::get_client(&nodes);
 
         info!("Setting up mining account...");
         if let Err(e) = Self::setup_mining_account(
@@ -294,7 +263,7 @@ impl Archiver {
                 let window_service = match Self::setup(
                     &mut meta,
                     cluster_info.clone(),
-                    &blocktree,
+                    &blockstore,
                     &exit,
                     &node_info,
                     &storage_keypair,
@@ -320,7 +289,7 @@ impl Archiver {
                 // run archiver
                 Self::run(
                     &mut meta,
-                    &blocktree,
+                    &blockstore,
                     cluster_info,
                     &keypair,
                     &storage_keypair,
@@ -344,14 +313,14 @@ impl Archiver {
 
     fn run(
         meta: &mut ArchiverMeta,
-        blocktree: &Arc<Blocktree>,
+        blockstore: &Arc<Blockstore>,
         cluster_info: Arc<RwLock<ClusterInfo>>,
         archiver_keypair: &Arc<Keypair>,
         storage_keypair: &Arc<Keypair>,
         exit: &Arc<AtomicBool>,
     ) {
         // encrypt segment
-        Self::encrypt_ledger(meta, blocktree).expect("ledger encrypt not successful");
+        Self::encrypt_ledger(meta, blockstore).expect("ledger encrypt not successful");
         let enc_file_path = meta.ledger_data_file_encrypted.clone();
         // do replicate
         loop {
@@ -408,7 +377,7 @@ impl Archiver {
         client_commitment: CommitmentConfig,
     ) {
         let nodes = cluster_info.read().unwrap().tvu_peers();
-        let client = crate::gossip_service::get_client(&nodes);
+        let client = solana_core::gossip_service::get_client(&nodes);
 
         if let Ok(Some(account)) =
             client.get_account_with_commitment(&storage_keypair.pubkey(), client_commitment.clone())
@@ -443,7 +412,7 @@ impl Archiver {
     fn setup(
         meta: &mut ArchiverMeta,
         cluster_info: Arc<RwLock<ClusterInfo>>,
-        blocktree: &Arc<Blocktree>,
+        blockstore: &Arc<Blockstore>,
         exit: &Arc<AtomicBool>,
         node_info: &ContactInfo,
         storage_keypair: &Arc<Keypair>,
@@ -498,7 +467,7 @@ impl Archiver {
         );
 
         let window_service = WindowService::new(
-            blocktree.clone(),
+            blockstore.clone(),
             cluster_info.clone(),
             verified_receiver,
             retransmit_sender,
@@ -512,7 +481,7 @@ impl Archiver {
         Self::wait_for_segment_download(
             slot,
             slots_per_segment,
-            &blocktree,
+            &blockstore,
             &exit,
             &node_info,
             cluster_info,
@@ -523,7 +492,7 @@ impl Archiver {
     fn wait_for_segment_download(
         start_slot: Slot,
         slots_per_segment: u64,
-        blocktree: &Arc<Blocktree>,
+        blockstore: &Arc<Blockstore>,
         exit: &Arc<AtomicBool>,
         node_info: &ContactInfo,
         cluster_info: Arc<RwLock<ClusterInfo>>,
@@ -534,7 +503,7 @@ impl Archiver {
         );
         let mut current_slot = start_slot;
         'outer: loop {
-            while blocktree.is_full(current_slot) {
+            while blockstore.is_full(current_slot) {
                 current_slot += 1;
                 info!("current slot: {}", current_slot);
                 if current_slot >= start_slot + slots_per_segment {
@@ -559,7 +528,7 @@ impl Archiver {
         }
     }
 
-    fn encrypt_ledger(meta: &mut ArchiverMeta, blocktree: &Arc<Blocktree>) -> Result<()> {
+    fn encrypt_ledger(meta: &mut ArchiverMeta, blockstore: &Arc<Blockstore>) -> Result<()> {
         meta.ledger_data_file_encrypted = meta.ledger_path.join(ENCRYPTED_FILENAME);
 
         {
@@ -567,7 +536,7 @@ impl Archiver {
             ivec.copy_from_slice(&meta.signature.as_ref());
 
             let num_encrypted_bytes = chacha_cbc_encrypt_ledger(
-                blocktree,
+                blockstore,
                 meta.slot,
                 meta.slots_per_segment,
                 &meta.ledger_data_file_encrypted,
@@ -619,9 +588,7 @@ impl Archiver {
             client_commitment.clone(),
         )? == 0
         {
-            return Err(
-                io::Error::new(io::ErrorKind::Other, "keypair account has no balance").into(),
-            );
+            return Err(ArchiverError::EmptyStorageAccountBalance);
         }
 
         info!("checking storage account keypair...");
@@ -632,11 +599,8 @@ impl Archiver {
             let blockhash =
                 match client.get_recent_blockhash_with_commitment(client_commitment.clone()) {
                     Ok((blockhash, _)) => blockhash,
-                    Err(_) => {
-                        return Err(Error::IO(<io::Error>::new(
-                            io::ErrorKind::Other,
-                            "unable to get recent blockhash, can't submit proof",
-                        )));
+                    Err(e) => {
+                        return Err(ArchiverError::TransportError(e));
                     }
                 };
 
@@ -670,7 +634,7 @@ impl Archiver {
     ) {
         // No point if we've got no storage account...
         let nodes = cluster_info.read().unwrap().tvu_peers();
-        let client = crate::gossip_service::get_client(&nodes);
+        let client = solana_core::gossip_service::get_client(&nodes);
         let storage_balance = client.poll_get_balance_with_commitment(
             &storage_keypair.pubkey(),
             meta.client_commitment.clone(),
@@ -734,7 +698,7 @@ impl Archiver {
     fn get_segment_config(
         cluster_info: &Arc<RwLock<ClusterInfo>>,
         client_commitment: CommitmentConfig,
-    ) -> result::Result<u64, Error> {
+    ) -> Result<u64> {
         let rpc_peers = {
             let cluster_info = cluster_info.read().unwrap();
             cluster_info.rpc_peers()
@@ -753,12 +717,12 @@ impl Archiver {
                 )
                 .map_err(|err| {
                     warn!("Error while making rpc request {:?}", err);
-                    Error::IO(io::Error::new(ErrorKind::Other, "rpc error"))
+                    ArchiverError::ClientError(err)
                 })?
                 .as_u64()
                 .unwrap())
         } else {
-            Err(io::Error::new(io::ErrorKind::Other, "No RPC peers...".to_string()).into())
+            Err(ArchiverError::NoRpcPeers)
         }
     }
 
@@ -768,7 +732,7 @@ impl Archiver {
         slots_per_segment: u64,
         previous_blockhash: &Hash,
         exit: &Arc<AtomicBool>,
-    ) -> result::Result<(Hash, u64), Error> {
+    ) -> Result<(Hash, u64)> {
         loop {
             let (blockhash, turn_slot) = Self::poll_for_blockhash_and_slot(
                 cluster_info,
@@ -788,7 +752,7 @@ impl Archiver {
         slots_per_segment: u64,
         previous_blockhash: &Hash,
         exit: &Arc<AtomicBool>,
-    ) -> result::Result<(Hash, u64), Error> {
+    ) -> Result<(Hash, u64)> {
         info!("waiting for the next turn...");
         loop {
             let rpc_peers = {
@@ -809,15 +773,13 @@ impl Archiver {
                     )
                     .map_err(|err| {
                         warn!("Error while making rpc request {:?}", err);
-                        Error::IO(io::Error::new(ErrorKind::Other, "rpc error"))
-                    })?;
-                let (storage_blockhash, turn_slot) =
-                    serde_json::from_value::<(String, u64)>(response).map_err(|err| {
-                        io::Error::new(
-                            io::ErrorKind::Other,
-                            format!("Couldn't parse response: {:?}", err),
-                        )
+                        ArchiverError::ClientError(err)
                     })?;
+                let RpcStorageTurn {
+                    blockhash: storage_blockhash,
+                    slot: turn_slot,
+                } = serde_json::from_value::<RpcStorageTurn>(response)
+                    .map_err(ArchiverError::JsonError)?;
                 let turn_blockhash = storage_blockhash.parse().map_err(|err| {
                     io::Error::new(
                         io::ErrorKind::Other,
@@ -835,7 +797,7 @@ impl Archiver {
                 }
             }
             if exit.load(Ordering::Relaxed) {
-                return Err(Error::IO(io::Error::new(
+                return Err(ArchiverError::IO(io::Error::new(
                     ErrorKind::Other,
                     "exit signalled...",
                 )));
@@ -844,15 +806,15 @@ impl Archiver {
         }
     }
 
-    /// Ask an archiver to populate a given blocktree with its segment.
+    /// Ask an archiver to populate a given blockstore with its segment.
     /// Return the slot at the start of the archiver's segment
     ///
-    /// It is recommended to use a temporary blocktree for this since the download will not verify
+    /// It is recommended to use a temporary blockstore for this since the download will not verify
     /// shreds received and might impact the chaining of shreds across slots
     pub fn download_from_archiver(
         cluster_info: &Arc<RwLock<ClusterInfo>>,
         archiver_info: &ContactInfo,
-        blocktree: &Arc<Blocktree>,
+        blockstore: &Arc<Blockstore>,
         slots_per_segment: u64,
     ) -> Result<u64> {
         // Create a client which downloads from the archiver and see that it
@@ -884,7 +846,7 @@ impl Archiver {
         for _ in 0..120 {
             // Strategy used by archivers
             let repairs = RepairService::generate_repairs_in_range(
-                blocktree,
+                blockstore,
                 repair_service::MAX_REPAIR_LENGTH,
                 &repair_slot_range,
             );
@@ -930,10 +892,10 @@ impl Archiver {
                     .into_iter()
                     .filter_map(|p| Shred::new_from_serialized_shred(p.data.to_vec()).ok())
                     .collect();
-                blocktree.insert_shreds(shreds, None, false)?;
+                blockstore.insert_shreds(shreds, None, false)?;
             }
             // check if all the slots in the segment are complete
-            if Self::segment_complete(start_slot, slots_per_segment, blocktree) {
+            if Self::segment_complete(start_slot, slots_per_segment, blockstore) {
                 break;
             }
             sleep(Duration::from_millis(500));
@@ -942,10 +904,8 @@ impl Archiver {
         t_receiver.join().unwrap();
 
         // check if all the slots in the segment are complete
-        if !Self::segment_complete(start_slot, slots_per_segment, blocktree) {
-            return Err(
-                io::Error::new(ErrorKind::Other, "Unable to download the full segment").into(),
-            );
+        if !Self::segment_complete(start_slot, slots_per_segment, blockstore) {
+            return Err(ArchiverError::SegmentDownloadError);
         }
         Ok(start_slot)
     }
@@ -953,10 +913,10 @@ impl Archiver {
     fn segment_complete(
         start_slot: Slot,
         slots_per_segment: u64,
-        blocktree: &Arc<Blocktree>,
+        blockstore: &Arc<Blockstore>,
     ) -> bool {
         for slot in start_slot..(start_slot + slots_per_segment) {
-            if !blocktree.is_full(slot) {
+            if !blockstore.is_full(slot) {
                 return false;
             }
         }
@@ -988,74 +948,3 @@ impl Archiver {
         panic!("Couldn't get segment slot from archiver!");
     }
 }
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-    use std::fs::{create_dir_all, remove_file};
-    use std::io::Write;
-
-    fn tmp_file_path(name: &str) -> PathBuf {
-        use std::env;
-        let out_dir = env::var("FARF_DIR").unwrap_or_else(|_| "farf".to_string());
-        let keypair = Keypair::new();
-
-        let mut path = PathBuf::new();
-        path.push(out_dir);
-        path.push("tmp");
-        create_dir_all(&path).unwrap();
-
-        path.push(format!("{}-{}", name, keypair.pubkey()));
-        path
-    }
-
-    #[test]
-    fn test_sample_file() {
-        solana_logger::setup();
-        let in_path = tmp_file_path("test_sample_file_input.txt");
-        let num_strings = 4096;
-        let string = "12foobar";
-        {
-            let mut in_file = File::create(&in_path).unwrap();
-            for _ in 0..num_strings {
-                in_file.write(string.as_bytes()).unwrap();
-            }
-        }
-        let num_samples = (string.len() * num_strings / size_of::<Hash>()) as u64;
-        let samples: Vec<_> = (0..num_samples).collect();
-        let res = sample_file(&in_path, samples.as_slice());
-        let ref_hash: Hash = Hash::new(&[
-            173, 251, 182, 165, 10, 54, 33, 150, 133, 226, 106, 150, 99, 192, 179, 1, 230, 144,
-            151, 126, 18, 191, 54, 67, 249, 140, 230, 160, 56, 30, 170, 52,
-        ]);
-        let res = res.unwrap();
-        assert_eq!(res, ref_hash);
-
-        // Sample just past the end
-        assert!(sample_file(&in_path, &[num_samples]).is_err());
-        remove_file(&in_path).unwrap();
-    }
-
-    #[test]
-    fn test_sample_file_invalid_offset() {
-        let in_path = tmp_file_path("test_sample_file_invalid_offset_input.txt");
-        {
-            let mut in_file = File::create(&in_path).unwrap();
-            for _ in 0..4096 {
-                in_file.write("123456foobar".as_bytes()).unwrap();
-            }
-        }
-        let samples = [0, 200000];
-        let res = sample_file(&in_path, &samples);
-        assert!(res.is_err());
-        remove_file(in_path).unwrap();
-    }
-
-    #[test]
-    fn test_sample_file_missing_file() {
-        let in_path = tmp_file_path("test_sample_file_that_doesnt_exist.txt");
-        let samples = [0, 5];
-        let res = sample_file(&in_path, &samples);
-        assert!(res.is_err());
-    }
-}

archiver-lib/src/lib.rs

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

archiver-lib/src/result.rs

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

archiver-utils/Cargo.toml

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

archiver-utils/src/lib.rs

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

archiver/Cargo.toml

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

archiver/src/main.rs

@@ -1,5 +1,6 @@
 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::{
@@ -8,7 +9,6 @@ use solana_clap_utils::{
     },
 };
 use solana_core::{
-    archiver::Archiver,
     cluster_info::{Node, VALIDATOR_PORT_RANGE},
     contact_info::ContactInfo,
 };

banking-bench/Cargo.toml

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

banking-bench/src/main.rs

@@ -10,7 +10,7 @@ use solana_core::packet::to_packets_chunked;
 use solana_core::poh_recorder::PohRecorder;
 use solana_core::poh_recorder::WorkingBankEntry;
 use solana_ledger::bank_forks::BankForks;
-use solana_ledger::{blocktree::Blocktree, get_tmp_ledger_path};
+use solana_ledger::{blockstore::Blockstore, get_tmp_ledger_path};
 use solana_measure::measure::Measure;
 use solana_runtime::bank::Bank;
 use solana_sdk::hash::Hash;
@@ -139,11 +139,11 @@ fn main() {
     let mut verified: Vec<_> = to_packets_chunked(&transactions.clone(), PACKETS_PER_BATCH);
     let ledger_path = get_tmp_ledger_path!();
     {
-        let blocktree = Arc::new(
-            Blocktree::open(&ledger_path).expect("Expected to be able to open database ledger"),
+        let blockstore = Arc::new(
+            Blockstore::open(&ledger_path).expect("Expected to be able to open database ledger"),
         );
         let (exit, poh_recorder, poh_service, signal_receiver) =
-            create_test_recorder(&bank, &blocktree, None);
+            create_test_recorder(&bank, &blockstore, None);
         let cluster_info = ClusterInfo::new_with_invalid_keypair(Node::new_localhost().info);
         let cluster_info = Arc::new(RwLock::new(cluster_info));
         let banking_stage = BankingStage::new(
@@ -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 = 0;
-        let mut tx_total = 0;
+        let mut total_us = 0;
+        let mut tx_total_us = 0;
         let mut txs_processed = 0;
         let mut root = 1;
         let collector = Pubkey::new_rand();
@@ -173,6 +173,7 @@ fn main() {
             chunk_len,
             num_threads,
         };
+        let mut total_sent = 0;
         for _ in 0..ITERS {
             let now = Instant::now();
             let mut sent = 0;
@@ -223,7 +224,7 @@ fn main() {
                 );
                 assert!(txs_processed < bank.transaction_count());
                 txs_processed = bank.transaction_count();
-                tx_total += duration_as_us(&now.elapsed());
+                tx_total_us += duration_as_us(&now.elapsed());
 
                 let mut poh_time = Measure::start("poh_time");
                 poh_recorder.lock().unwrap().reset(
@@ -255,20 +256,21 @@ fn main() {
                     poh_time.as_us(),
                 );
             } else {
-                tx_total += duration_as_us(&now.elapsed());
+                tx_total_us += duration_as_us(&now.elapsed());
             }
 
             // This signature clear may not actually clear the signatures
             // in this chunk, but since we rotate between CHUNKS then
             // we should clear them by the time we come around again to re-use that chunk.
             bank.clear_signatures();
-            total += duration_as_us(&now.elapsed());
+            total_us += 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() {
@@ -284,11 +286,11 @@ fn main() {
         }
         eprintln!(
             "{{'name': 'banking_bench_total', 'median': '{}'}}",
-            total / ITERS as u64,
+            (1000.0 * 1000.0 * total_sent as f64) / (total_us as f64),
         );
         eprintln!(
             "{{'name': 'banking_bench_tx_total', 'median': '{}'}}",
-            tx_total / ITERS as u64,
+            (1000.0 * 1000.0 * total_sent as f64) / (tx_total_us as f64),
         );
 
         drop(verified_sender);
@@ -300,5 +302,5 @@ fn main() {
         sleep(Duration::from_secs(1));
         debug!("waited for poh_service");
     }
-    let _unused = Blocktree::destroy(&ledger_path);
+    let _unused = Blockstore::destroy(&ledger_path);
 }

bench-exchange/Cargo.toml

@@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-exchange"
-version = "0.22.0"
+version = "0.23.0"
 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.22.0" }
-solana-core = { path = "../core", version = "0.22.0" }
-solana-genesis = { path = "../genesis", version = "0.22.0" }
-solana-client = { path = "../client", version = "0.22.0" }
-solana-faucet = { path = "../faucet", version = "0.22.0" }
-solana-exchange-program = { path = "../programs/exchange", version = "0.22.0" }
-solana-logger = { path = "../logger", version = "0.22.0" }
-solana-metrics = { path = "../metrics", version = "0.22.0" }
-solana-net-utils = { path = "../net-utils", version = "0.22.0" }
-solana-runtime = { path = "../runtime", version = "0.22.0" }
-solana-sdk = { path = "../sdk", version = "0.22.0" }
+solana-clap-utils = { path = "../clap-utils", version = "0.23.0" }
+solana-core = { path = "../core", version = "0.23.0" }
+solana-genesis = { path = "../genesis", version = "0.23.0" }
+solana-client = { path = "../client", version = "0.23.0" }
+solana-faucet = { path = "../faucet", version = "0.23.0" }
+solana-exchange-program = { path = "../programs/exchange", version = "0.23.0" }
+solana-logger = { path = "../logger", version = "0.23.0" }
+solana-metrics = { path = "../metrics", version = "0.23.0" }
+solana-net-utils = { path = "../net-utils", version = "0.23.0" }
+solana-runtime = { path = "../runtime", version = "0.23.0" }
+solana-sdk = { path = "../sdk", version = "0.23.0" }
 untrusted = "0.7.0"
 ws = "0.9.1"
 
 [dev-dependencies]
-solana-local-cluster = { path = "../local-cluster", version = "0.22.0" }
+solana-local-cluster = { path = "../local-cluster", version = "0.23.0" }

bench-streamer/Cargo.toml

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

bench-streamer/src/main.rs

@@ -1,6 +1,5 @@
 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};
@@ -8,7 +7,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};
+use std::thread::{spawn, JoinHandle, Result};
 use std::time::Duration;
 use std::time::SystemTime;
 

bench-tps/Cargo.toml

@@ -2,7 +2,7 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-tps"
-version = "0.22.0"
+version = "0.23.0"
 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.22.0" }
-solana-core = { path = "../core", version = "0.22.0" }
-solana-genesis = { path = "../genesis", version = "0.22.0" }
-solana-client = { path = "../client", version = "0.22.0" }
-solana-faucet = { path = "../faucet", version = "0.22.0" }
-solana-librapay = { path = "../programs/librapay", version = "0.22.0", optional = true }
-solana-logger = { path = "../logger", version = "0.22.0" }
-solana-metrics = { path = "../metrics", version = "0.22.0" }
-solana-measure = { path = "../measure", version = "0.22.0" }
-solana-net-utils = { path = "../net-utils", version = "0.22.0" }
-solana-runtime = { path = "../runtime", version = "0.22.0" }
-solana-sdk = { path = "../sdk", version = "0.22.0" }
-solana-move-loader-program = { path = "../programs/move_loader", version = "0.22.0", optional = true }
+solana-clap-utils = { path = "../clap-utils", version = "0.23.0" }
+solana-core = { path = "../core", version = "0.23.0" }
+solana-genesis = { path = "../genesis", version = "0.23.0" }
+solana-client = { path = "../client", version = "0.23.0" }
+solana-faucet = { path = "../faucet", version = "0.23.0" }
+solana-librapay = { path = "../programs/librapay", version = "0.23.0", optional = true }
+solana-logger = { path = "../logger", version = "0.23.0" }
+solana-metrics = { path = "../metrics", version = "0.23.0" }
+solana-measure = { path = "../measure", version = "0.23.0" }
+solana-net-utils = { path = "../net-utils", version = "0.23.0" }
+solana-runtime = { path = "../runtime", version = "0.23.0" }
+solana-sdk = { path = "../sdk", version = "0.23.0" }
+solana-move-loader-program = { path = "../programs/move_loader", version = "0.23.0", optional = true }
 
 [dev-dependencies]
 serial_test = "0.3.2"
 serial_test_derive = "0.3.1"
-solana-local-cluster = { path = "../local-cluster", version = "0.22.0" }
+solana-local-cluster = { path = "../local-cluster", version = "0.23.0" }
 
 [features]
 move = ["solana-librapay", "solana-move-loader-program"]

bench-tps/src/bench.rs

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

bench-tps/src/cli.rs

@@ -4,7 +4,7 @@ use solana_sdk::fee_calculator::FeeCalculator;
 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::SOL_LAMPORTS;
+const NUM_LAMPORTS_PER_ACCOUNT_DEFAULT: u64 = solana_sdk::native_token::LAMPORTS_PER_SOL;
 
 /// Holds the configuration for a single run of the benchmark
 pub struct Config {

bench-tps/src/main.rs

@@ -6,13 +6,13 @@ use solana_genesis::Base64Account;
 use solana_sdk::fee_calculator::FeeCalculator;
 use solana_sdk::signature::{Keypair, KeypairUtil};
 use solana_sdk::system_program;
-use std::{collections::HashMap, fs::File, io::prelude::*, path::Path, process::exit};
+use std::{collections::HashMap, fs::File, io::prelude::*, path::Path, process::exit, sync::Arc};
 
 /// Number of signatures for all transactions in ~1 week at ~100K TPS
 pub const NUM_SIGNATURES_FOR_TXS: u64 = 100_000 * 60 * 60 * 24 * 7;
 
 fn main() {
-    solana_logger::setup_with_filter("solana=info");
+    solana_logger::setup_with_default("solana=info");
     solana_metrics::set_panic_hook("bench-tps");
 
     let matches = cli::build_args(solana_clap_utils::version!()).get_matches();
@@ -82,12 +82,12 @@ fn main() {
             );
             exit(1);
         }
-        client
+        Arc::new(client)
     } else {
-        get_client(&nodes)
+        Arc::new(get_client(&nodes))
     };
 
-    let (keypairs, move_keypairs, keypair_balance) = if *read_from_client_file && !use_move {
+    let (keypairs, move_keypairs) = if *read_from_client_file && !use_move {
         let path = Path::new(&client_ids_and_stake_file);
         let file = File::open(path).unwrap();
 
@@ -117,10 +117,10 @@ fn main() {
         // This prevents the amount of storage needed for bench-tps accounts from creeping up
         // across multiple runs.
         keypairs.sort_by(|x, y| x.pubkey().to_string().cmp(&y.pubkey().to_string()));
-        (keypairs, None, last_balance)
+        (keypairs, None)
     } else {
         generate_and_fund_keypairs(
-            &client,
+            client.clone(),
             Some(*faucet_addr),
             &id,
             keypair_count,
@@ -133,11 +133,5 @@ fn main() {
         })
     };
 
-    do_bench_tps(
-        vec![client],
-        cli_config,
-        keypairs,
-        keypair_balance,
-        move_keypairs,
-    );
+    do_bench_tps(client, cli_config, keypairs, move_keypairs);
 }

bench-tps/tests/bench_tps.rs

@@ -9,7 +9,7 @@ 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, KeypairUtil};
-use std::sync::mpsc::channel;
+use std::sync::{mpsc::channel, Arc};
 use std::time::Duration;
 
 fn test_bench_tps_local_cluster(config: Config) {
@@ -36,10 +36,10 @@ fn test_bench_tps_local_cluster(config: Config) {
         100_000_000,
     );
 
-    let client = create_client(
+    let client = Arc::new(create_client(
         (cluster.entry_point_info.rpc, cluster.entry_point_info.tpu),
         VALIDATOR_PORT_RANGE,
-    );
+    ));
 
     let (addr_sender, addr_receiver) = channel();
     run_local_faucet(faucet_keypair, addr_sender, None);
@@ -48,8 +48,8 @@ fn test_bench_tps_local_cluster(config: Config) {
     let lamports_per_account = 100;
 
     let keypair_count = config.tx_count * config.keypair_multiplier;
-    let (keypairs, move_keypairs, _keypair_balance) = generate_and_fund_keypairs(
-        &client,
+    let (keypairs, move_keypairs) = generate_and_fund_keypairs(
+        client.clone(),
         Some(faucet_addr),
         &config.id,
         keypair_count,
@@ -58,7 +58,7 @@ fn test_bench_tps_local_cluster(config: Config) {
     )
     .unwrap();
 
-    let _total = do_bench_tps(vec![client], config, keypairs, 0, move_keypairs);
+    let _total = do_bench_tps(client, config, keypairs, move_keypairs);
 
     #[cfg(not(debug_assertions))]
     assert!(_total > 100);

book/art/passive-staking-callflow.msc

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

book/art/spv-bank-hash.bob

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

book/art/spv-bank-merkle.bob

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

book/art/validator.bob

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

book/build-cli-usage.sh

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

book/build.sh

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

book/makefile

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

book/src/SUMMARY.md

@@ -1,14 +1,31 @@
 # Table of contents
 
 * [Introduction](introduction.md)
-* [Terminology](terminology.md)
-* [Getting Started](getting-started/README.md)
-  * [Testnet Participation](getting-started/testnet-participation.md)
-  * [Example Client: Web Wallet](getting-started/webwallet.md)
-* [Programming Model](programs/README.md)
-  * [Example: Tic-Tac-Toe](programs/tictactoe.md)
-  * [Drones](programs/drones.md)
-* [A Solana Cluster](cluster/README.md)
+* [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)
   * [Synchronization](cluster/synchronization.md)
   * [Leader Rotation](cluster/leader-rotation.md)
   * [Fork Generation](cluster/fork-generation.md)
@@ -20,45 +37,13 @@
   * [Performance Metrics](cluster/performance-metrics.md)
 * [Anatomy of a Validator](validator/README.md)
   * [TPU](validator/tpu.md)
-  * [TVU](validator/tvu/README.md)
-    * [Blocktree](validator/tvu/blocktree.md)
+  * [TVU](validator/tvu.md)
+  * [Blockstore](validator/blockstore.md)
   * [Gossip Service](validator/gossip.md)
   * [The Runtime](validator/runtime.md)
-* [Anatomy of a Transaction](transaction.md)
-* [Running a Validator](running-validator/README.md)
-  * [Validator Requirements](running-validator/validator-reqs.md)
-  * [Choosing a Testnet](running-validator/validator-testnet.md)
-  * [Installing the Validator Software](running-validator/validator-software.md)
-  * [Starting a Validator](running-validator/validator-start.md)
-  * [Staking](running-validator/validator-stake.md)
-  * [Monitoring a Validator](running-validator/validator-monitor.md)
-  * [Publishing Validator Info](running-validator/validator-info.md)
-  * [Troubleshooting](running-validator/validator-troubleshoot.md)
-* [Running an Archiver](running-archiver.md)
-* [Paper Wallet](paper-wallet/README.md)
-  * [Installation](paper-wallet/installation.md)
-  * [Paper Wallet Usage](paper-wallet/usage.md)
-* [Offline Signing](offline-signing/README.md)
-* [API Reference](api-reference/README.md)
-  * [Transaction](api-reference/transaction-api.md)
-  * [Instruction](api-reference/instruction-api.md)
-  * [Blockstreamer](api-reference/blockstreamer.md)
-  * [JSON RPC API](api-reference/jsonrpc-api.md)
-  * [JavaScript API](api-reference/javascript-api.md)
-  * [solana CLI](api-reference/cli.md)
-* [Accepted Design Proposals](proposals/README.md)
-  * [Ledger Replication](proposals/ledger-replication-to-implement.md)
-  * [Secure Vote Signing](proposals/vote-signing-to-implement.md)
-  * [Cluster Test Framework](proposals/cluster-test-framework.md)
-  * [Validator](proposals/validator-proposal.md)
-  * [Simple Payment and State Verification](proposals/simple-payment-and-state-verification.md)
-  * [Cross-Program Invocation](proposals/cross-program-invocation.md)
-  * [Inter-chain Transaction Verification](proposals/interchain-transaction-verification.md)
-  * [Snapshot Verification](proposals/snapshot-verification.md)
-  * [Bankless Leader](proposals/bankless-leader.md)
-  * [Slashing](proposals/slashing.md)
+* [Building from Source](building-from-source.md)
+* [Terminology](terminology.md)
 * [Implemented Design Proposals](implemented-proposals/README.md)
-  * [Blocktree](implemented-proposals/blocktree.md)
   * [Cluster Software Installation and Updates](implemented-proposals/installer.md)
   * [Cluster Economics](implemented-proposals/ed_overview/README.md)
     * [Validation-client Economics](implemented-proposals/ed_overview/ed_validation_client_economics/README.md)
@@ -69,6 +54,7 @@
     * [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)
@@ -87,3 +73,19 @@
   * [Rent](implemented-proposals/rent.md)
   * [Durable Transaction Nonces](implemented-proposals/durable-tx-nonces.md)
   * [Validator Timestamp Oracle](implemented-proposals/validator-timestamp-oracle.md)
+  * [Commitment](implemented-proposals/commitment.md)
+  * [Snapshot Verification](implemented-proposals/snapshot-verification.md)
+* [Accepted Design Proposals](proposals/README.md)
+  * [Ledger Replication](proposals/ledger-replication-to-implement.md)
+  * [Secure Vote Signing](proposals/vote-signing-to-implement.md)
+  * [Cluster Test Framework](proposals/cluster-test-framework.md)
+  * [Validator](proposals/validator-proposal.md)
+  * [Simple Payment and State Verification](proposals/simple-payment-and-state-verification.md)
+  * [Cross-Program Invocation](proposals/cross-program-invocation.md)
+  * [Inter-chain Transaction Verification](proposals/interchain-transaction-verification.md)
+  * [Snapshot Verification](proposals/snapshot-verification.md)
+  * [Bankless Leader](proposals/bankless-leader.md)
+  * [Slashing](proposals/slashing.md)
+  * [Tick Verification](proposals/tick-verification.md)
+  * [Block Confirmation](proposals/block-confirmation.md)
+  * [ABI Management](proposals/abi-management.md)

book/src/api-reference/README.md

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

book/src/api-reference/blockstreamer.md

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

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

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

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

@@ -1,994 +0,0 @@
-# JSON RPC API
-
-Solana nodes accept HTTP requests using the [JSON-RPC 2.0](https://www.jsonrpc.org/specification) specification.
-
-To interact with a Solana node inside a JavaScript application, use the [solana-web3.js](https://github.com/solana-labs/solana-web3.js) library, which gives a convenient interface for the RPC methods.
-
-## RPC HTTP Endpoint
-
-**Default port:** 8899 eg. [http://localhost:8899](http://localhost:8899), [http://192.168.1.88:8899](http://192.168.1.88:8899)
-
-## RPC PubSub WebSocket Endpoint
-
-**Default port:** 8900 eg. ws://localhost:8900, [http://192.168.1.88:8900](http://192.168.1.88:8900)
-
-## Methods
-
-* [confirmTransaction](jsonrpc-api.md#confirmtransaction)
-* [getAccountInfo](jsonrpc-api.md#getaccountinfo)
-* [getBalance](jsonrpc-api.md#getbalance)
-* [getBlockCommitment](jsonrpc-api.md#getblockcommitment)
-* [getBlockTime](jsonrpc-api.md#getblocktime)
-* [getClusterNodes](jsonrpc-api.md#getclusternodes)
-* [getConfirmedBlock](jsonrpc-api.md#getconfirmedblock)
-* [getConfirmedBlocks](jsonrpc-api.md#getconfirmedblocks)
-* [getEpochInfo](jsonrpc-api.md#getepochinfo)
-* [getEpochSchedule](jsonrpc-api.md#getepochschedule)
-* [getGenesisHash](jsonrpc-api.md#getgenesishash)
-* [getLeaderSchedule](jsonrpc-api.md#getleaderschedule)
-* [getMinimumBalanceForRentExemption](jsonrpc-api.md#getminimumbalanceforrentexemption)
-* [getNumBlocksSinceSignatureConfirmation](jsonrpc-api.md#getnumblockssincesignatureconfirmation)
-* [getProgramAccounts](jsonrpc-api.md#getprogramaccounts)
-* [getRecentBlockhash](jsonrpc-api.md#getrecentblockhash)
-* [getSignatureStatus](jsonrpc-api.md#getsignaturestatus)
-* [getSlot](jsonrpc-api.md#getslot)
-* [getSlotLeader](jsonrpc-api.md#getslotleader)
-* [getSlotsPerSegment](jsonrpc-api.md#getslotspersegment)
-* [getStorageTurn](jsonrpc-api.md#getstorageturn)
-* [getStorageTurnRate](jsonrpc-api.md#getstorageturnrate)
-* [getTransactionCount](jsonrpc-api.md#gettransactioncount)
-* [getTotalSupply](jsonrpc-api.md#gettotalsupply)
-* [getVersion](jsonrpc-api.md#getversion)
-* [getVoteAccounts](jsonrpc-api.md#getvoteaccounts)
-* [requestAirdrop](jsonrpc-api.md#requestairdrop)
-* [sendTransaction](jsonrpc-api.md#sendtransaction)
-* [startSubscriptionChannel](jsonrpc-api.md#startsubscriptionchannel)
-* [Subscription Websocket](jsonrpc-api.md#subscription-websocket)
-  * [accountSubscribe](jsonrpc-api.md#accountsubscribe)
-  * [accountUnsubscribe](jsonrpc-api.md#accountunsubscribe)
-  * [programSubscribe](jsonrpc-api.md#programsubscribe)
-  * [programUnsubscribe](jsonrpc-api.md#programunsubscribe)
-  * [signatureSubscribe](jsonrpc-api.md#signaturesubscribe)
-  * [signatureUnsubscribe](jsonrpc-api.md#signatureunsubscribe)
-
-## Request Formatting
-
-To make a JSON-RPC request, send an HTTP POST request with a `Content-Type: application/json` header. The JSON request data should contain 4 fields:
-
-* `jsonrpc`, set to `"2.0"`
-* `id`, a unique client-generated identifying integer
-* `method`, a string containing the method to be invoked
-* `params`, a JSON array of ordered parameter values
-
-Example using curl:
-
-```bash
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getBalance", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"]}' 192.168.1.88:8899
-```
-
-The response output will be a JSON object with the following fields:
-
-* `jsonrpc`, matching the request specification
-* `id`, matching the request identifier
-* `result`, requested data or success confirmation
-
-Requests can be sent in batches by sending an array of JSON-RPC request objects as the data for a single POST.
-
-## Definitions
-
-* Hash: A SHA-256 hash of a chunk of data.
-* Pubkey: The public key of a Ed25519 key-pair.
-* Signature: An Ed25519 signature of a chunk of data.
-* Transaction: A Solana instruction signed by a client key-pair.
-
-## Configuring State Commitment
-
-Solana nodes choose which bank state to query based on a commitment requirement
-set by the client. Clients may specify either:
-* `{"commitment":"max"}` - the node will query the most recent bank having reached `MAX_LOCKOUT_HISTORY` confirmations
-* `{"commitment":"recent"}` - the node will query its most recent bank state
-
-The commitment parameter should be included as the last element in the `params` array:
-
-```bash
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getBalance", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri",{"commitment":"max"}]}' 192.168.1.88:8899
-```
-
-#### Default:
-If commitment configuration is not provided, the node will default to `"commitment":"max"`
-
-Only methods that query bank state accept the commitment parameter. They are indicated in the API Reference below.
-
-#### RpcResponse Structure
-Many methods that take a commitment parameter return an RpcResponse JSON object comprised of two parts:
-
-* `context` : An RpcResponseContext JSON structure including a `slot` field at which the operation was evaluated.
-* `value` : The value returned by the operation itself.
-
-
-## JSON RPC API Reference
-
-### confirmTransaction
-
-Returns a transaction receipt
-
-#### Parameters:
-
-* `string` - Signature of Transaction to confirm, as base-58 encoded string
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `RpcResponse<boolean>` - RpcResponse JSON object with `value` field set to Transaction status, boolean true if Transaction is confirmed
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"confirmTransaction", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"context":{"slot":1},"value":true},"id":1}
-```
-
-### getAccountInfo
-
-Returns all information associated with the account of provided Pubkey
-
-#### Parameters:
-
-* `string` - Pubkey of account to query, as base-58 encoded string
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-The result value will be an RpcResponse JSON object containing an AccountInfo JSON object.
-
-* `RpcResponse<AccountInfo>`, RpcResponse JSON object with `value` field set to AccountInfo, a JSON object containing:
-* `lamports`, number of lamports assigned to this account, as a u64
-* `owner`, array of 32 bytes representing the program this account has been assigned to
-* `data`, array of bytes representing any data associated with the account
-* `executable`, boolean indicating if the account contains a program \(and is strictly read-only\)
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getAccountInfo", "params":["2gVkYWexTHR5Hb2aLeQN3tnngvWzisFKXDUPrgMHpdST"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"context":{"slot":1},"value":{"executable":false,"owner":[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"lamports":1,"data":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0.22.0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]}},"id":1}
-```
-
-### getBalance
-
-Returns the balance of the account of provided Pubkey
-
-#### Parameters:
-
-* `string` - Pubkey of account to query, as base-58 encoded string
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `RpcResponse<u64>` - RpcResponse JSON object with `value` field set to quantity
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getBalance", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"context":{"slot":1},"value":0},"id":1}
-```
-
-### getBlockCommitment
-
-Returns commitment for particular block
-
-#### Parameters:
-
-* `u64` - block, identified by Slot
-
-#### Results:
-
-The result field will be an array with two fields:
-
-* Commitment
-  * `null` - Unknown block
-  * `object` - BlockCommitment
-    * `array` - commitment, array of u64 integers logging the amount of cluster stake in lamports that has voted on the block at each depth from 0 to `MAX_LOCKOUT_HISTORY`
-* 'integer' - total active stake, in lamports, of the current epoch
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getBlockCommitment","params":[5]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":[{"commitment":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,10,32]},42],"id":1}
-```
-
-### getBlockTime
-
-Returns the estimated production time of a block. Validators report their UTC
-time to the ledger on a regular interval. A block's time is calculated as an
-offset from the median value of the most recent validator time report.
-
-#### Parameters:
-
-* `u64` - block, identified by Slot
-
-#### Results:
-
-* `null` - block has not yet been produced
-* `i64` - estimated production time, as Unix timestamp (seconds since the Unix epoch)
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getBlockTime","params":[5]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":1574721591,"id":1}
-```
-
-### getClusterNodes
-
-Returns information about all the nodes participating in the cluster
-
-#### Parameters:
-
-None
-
-#### Results:
-
-The result field will be an array of JSON objects, each with the following sub fields:
-
-* `pubkey` - Node public key, as base-58 encoded string
-* `gossip` - Gossip network address for the node
-* `tpu` - TPU network address for the node
-* `rpc` - JSON RPC network address for the node, or `null` if the JSON RPC service is not enabled
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getClusterNodes"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":[{"gossip":"10.239.6.48:8001","pubkey":"9QzsJf7LPLj8GkXbYT3LFDKqsj2hHG7TA3xinJHu8epQ","rpc":"10.239.6.48:8899","tpu":"10.239.6.48:8856"}],"id":1}
-```
-
-### getConfirmedBlock
-
-Returns identity and transaction information about a confirmed block in the ledger
-
-#### Parameters:
-
-* `integer` - slot, as u64 integer
-
-#### Results:
-
-The result field will be an object with the following fields:
-
-* `blockhash` - the blockhash of this block
-* `previousBlockhash` - the blockhash of this block's parent
-* `parentSlot` - the slot index of this block's parent
-* `transactions` - an array of tuples containing:
-  * [Transaction](transaction-api.md) object, in JSON format
-  * Transaction status object, containing:
-     * `status` - Transaction status:
-       * `"Ok": null` - Transaction was successful
-       * `"Err": <ERR>` - Transaction failed with TransactionError  [TransactionError definitions](https://github.com/solana-labs/solana/blob/master/sdk/src/transaction.rs#L14)
-     * `fee` - fee this transaction was charged, as u64 integer
-     * `preBalances` - array of u64 account balances from before the transaction was processed
-     * `postBalances` - array of u64 account balances after the transaction was processed
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlock","params":[430]}' localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"blockhash":[165,245,120,183,32,205,89,222,249,114,229,49,250,231,149,122,156,232,181,83,238,194,157,153,7,213,180,54,177,6,25,101],"parentSlot":429,"previousBlockhash":[21,108,181,90,139,241,212,203,45,78,232,29,161,31,159,188,110,82,81,11,250,74,47,140,188,28,23,96,251,164,208,166],"transactions":[[{"message":{"accountKeys":[[5],[219,181,202,40,52,148,34,136,186,59,137,160,250,225,234,17,244,160,88,116,24,176,30,227,68,11,199,38,141,68,131,228],[233,48,179,56,91,40,254,206,53,48,196,176,119,248,158,109,121,77,11,69,108,160,128,27,228,122,146,249,53,184,68,87],[6,167,213,23,25,47,10,175,198,242,101,227,251,119,204,122,218,130,197,41,208,190,59,19,110,45,0,85,32,0,0,0],[6,167,213,23,24,199,116,201,40,86,99,152,105,29,94,182,139,94,184,163,155,75,109,92,115,85,91,33,0,0,0,0],[7,97,72,29,53,116,116,187,124,77,118,36,235,211,189,179,216,53,94,115,209,16,67,252,13,163,83,128,0,0,0,0]],"header":{"numReadonlySignedAccounts":0,"numReadonlyUnsignedAccounts":3,"numRequiredSignatures":2},"instructions":[[1],{"accounts":[[3],1,2,3],"data":[[52],2,0,0,0,1,0,0,0,0,0,0,0,173,1,0,0,0,0,0,0,86,55,9,248,142,238,135,114,103,83,247,124,67,68,163,233,55,41,59,129,64,50,110,221,234,234,27,213,205,193,219,50],"program_id_index":4}],"recentBlockhash":[21,108,181,90,139,241,212,203,45,78,232,29,161,31,159,188,110,82,81,11,250,74,47,140,188,28,23,96,251,164,208,166]},"signatures":[[2],[119,9,95,108,35,95,7,1,69,101,65,45,5,204,61,114,172,88,123,238,32,201,135,229,57,50,13,21,106,216,129,183,238,43,37,101,148,81,56,232,88,136,80,65,46,189,39,106,94,13,238,54,186,48,118,186,0,62,121,122,172,171,66,5],[78,40,77,250,10,93,6,157,48,173,100,40,251,9,7,218,7,184,43,169,76,240,254,34,235,48,41,175,119,126,75,107,106,248,45,161,119,48,174,213,57,69,111,225,245,60,148,73,124,82,53,6,203,126,120,180,111,169,89,64,29,23,237,13]]},{"fee":100000,"status":{"Ok":null},"preBalances":[499998337500,15298080,1,1,1],"postBalances":[499998237500,15298080,1,1,1]}]]},"id":1}
-```
-
-### getConfirmedBlocks
-
-Returns a list of confirmed blocks
-
-#### Parameters:
-
-* `integer` - start_slot, as u64 integer
-* `integer` - (optional) end_slot, as u64 integer
-
-#### Results:
-
-The result field will be an array of u64 integers listing confirmed blocks
-between start_slot and either end_slot, if provided, or latest confirmed block,
-inclusive.
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc": "2.0","id":1,"method":"getConfirmedBlocks","params":[5, 10]}' localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":[5,6,7,8,9,10],"id":1}
-```
-
-### getEpochInfo
-
-Returns information about the current epoch
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-The result field will be an object with the following fields:
-
-* `epoch`, the current epoch
-* `slotIndex`, the current slot relative to the start of the current epoch
-* `slotsInEpoch`, the number of slots in this epoch
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochInfo"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"epoch":3,"slotIndex":126,"slotsInEpoch":256},"id":1}
-```
-
-### getEpochSchedule
-
-Returns epoch schedule information from this cluster's genesis config
-
-#### Parameters:
-
-None
-
-#### Results:
-
-The result field will be an object with the following fields:
-
-* `slots_per_epoch`, the maximum number of slots in each epoch
-* `leader_schedule_slot_offset`, the number of slots before beginning of an epoch to calculate a leader schedule for that epoch
-* `warmup`, whether epochs start short and grow
-* `first_normal_epoch`, first normal-length epoch, log2(slots_per_epoch) - log2(MINIMUM_SLOTS_PER_EPOCH)
-* `first_normal_slot`, MINIMUM_SLOTS_PER_EPOCH * (2.pow(first_normal_epoch) - 1)
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getEpochSchedule"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"first_normal_epoch":8,"first_normal_slot":8160,"leader_schedule_slot_offset":8192,"slots_per_epoch":8192,"warmup":true},"id":1}
-```
-
-### getGenesisHash
-
-Returns the genesis hash
-
-#### Parameters:
-
-None
-
-#### Results:
-
-* `string` - a Hash as base-58 encoded string
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getGenesisHash"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":"GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC","id":1}
-```
-
-### getLeaderSchedule
-
-Returns the leader schedule for an epoch
-
-#### Parameters:
-
-* `slot` - (optional) Fetch the leader schedule for the epoch that corresponds to the provided slot.  If unspecified, the leader schedule for the current epoch is fetched
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-The result field will be a dictionary of leader public keys \(as base-58 encoded
-strings\) and their corresponding leader slot indices as values (indices are to
-the first slot in the requested epoch)
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getLeaderSchedule"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"4Qkev8aNZcqFNSRhQzwyLMFSsi94jHqE8WNVTJzTP99F":[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63]},"id":1}
-```
-
-### getMinimumBalanceForRentExemption
-
-Returns minimum balance required to make account rent exempt.
-
-#### Parameters:
-
-* `u64` - account data length
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `u64` - minimum lamports required in account
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getMinimumBalanceForRentExemption", "params":[50]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":500,"id":1}
-```
-
-### getNumBlocksSinceSignatureConfirmation
-
-Returns the current number of blocks since signature has been confirmed.
-
-#### Parameters:
-
-* `string` - Signature of Transaction to confirm, as base-58 encoded string
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `u64` - count
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getNumBlocksSinceSignatureConfirmation", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":8,"id":1}
-```
-
-### getProgramAccounts
-
-Returns all accounts owned by the provided program Pubkey
-
-#### Parameters:
-
-* `string` - Pubkey of program, as base-58 encoded string
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-The result field will be an array of arrays. Each sub array will contain:
-
-* `string` - the account Pubkey as base-58 encoded string and a JSON object, with the following sub fields:
-* `lamports`, number of lamports assigned to this account, as a u64
-* `owner`, array of 32 bytes representing the program this account has been assigned to
-* `data`, array of bytes representing any data associated with the account
-* `executable`, boolean indicating if the account contains a program \(and is strictly read-only\)
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getProgramAccounts", "params":["8nQwAgzN2yyUzrukXsCa3JELBYqDQrqJ3UyHiWazWxHR"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":[["BqGKYtAKu69ZdWEBtZHh4xgJY1BYa2YBiBReQE3pe383", {"executable":false,"owner":[50,28,250,90,221,24,94,136,147,165,253,136,1,62,196,215,225,34,222,212,99,84,202,223,245,13,149,99,149,231,91,96],"lamports":1,"data":[]], ["4Nd1mBQtrMJVYVfKf2PJy9NZUZdTAsp7D4xWLs4gDB4T", {"executable":false,"owner":[50,28,250,90,221,24,94,136,147,165,253,136,1,62,196,215,225,34,222,212,99,84,202,223,245,13,149,99,149,231,91,96],"lamports":10,"data":[]]]},"id":1}
-```
-
-### getRecentBlockhash
-
-Returns a recent block hash from the ledger, and a fee schedule that can be used to compute the cost of submitting a transaction using it.
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-An RpcResponse containing an array consisting of a string blockhash and FeeCalculator JSON object.
-
-* `RpcResponse<array>` - RpcResponse JSON object with `value` field set to an array including:
-* `string` - a Hash as base-58 encoded string
-* `FeeCalculator object` - the fee schedule for this block hash
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getRecentBlockhash"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"context":{"slot":1},"value":["GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC",{"lamportsPerSignature": 0}]},"id":1}
-```
-
-### getSignatureStatus
-
-Returns the status of a given signature. This method is similar to [confirmTransaction](jsonrpc-api.md#confirmtransaction) but provides more resolution for error events.
-
-#### Parameters:
-
-* `string` - Signature of Transaction to confirm, as base-58 encoded string
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `null` - Unknown transaction
-* `object` - Transaction status:
-  * `"Ok": null` - Transaction was successful
-  * `"Err": <ERR>` - Transaction failed with TransactionError  [TransactionError definitions](https://github.com/solana-labs/solana/blob/master/sdk/src/transaction.rs#L14)
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getSignatureStatus", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":"SignatureNotFound","id":1}
-```
-
-### getSlot
-
-Returns the current slot the node is processing
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `u64` - Current slot
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getSlot"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":"1234","id":1}
-```
-
-### getSlotLeader
-
-Returns the current slot leader
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `string` - Node Id as base-58 encoded string
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getSlotLeader"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":"ENvAW7JScgYq6o4zKZwewtkzzJgDzuJAFxYasvmEQdpS","id":1}
-```
-
-### getSlotsPerSegment
-
-Returns the current storage segment size in terms of slots
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `u64` - Number of slots in a storage segment
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getSlotsPerSegment"}' http://localhost:8899
-// Result
-{"jsonrpc":"2.0","result":"1024","id":1}
-```
-
-### getStorageTurn
-
-Returns the current storage turn's blockhash and slot
-
-#### Parameters:
-
-None
-
-#### Results:
-
-An array consisting of
-
-* `string` - a Hash as base-58 encoded string indicating the blockhash of the turn slot
-* `u64` - the current storage turn slot
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getStorageTurn"}' http://localhost:8899
- // Result
-{"jsonrpc":"2.0","result":["GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC", "2048"],"id":1}
-```
-
-### getStorageTurnRate
-
-Returns the current storage turn rate in terms of slots per turn
-
-#### Parameters:
-
-None
-
-#### Results:
-
-* `u64` - Number of slots in storage turn
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getStorageTurnRate"}' http://localhost:8899
- // Result
-{"jsonrpc":"2.0","result":"1024","id":1}
-```
-
-### getTransactionCount
-
-Returns the current Transaction count from the ledger
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `u64` - count
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getTransactionCount"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":268,"id":1}
-```
-
-### getTotalSupply
-
-Returns the current total supply in Lamports
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-* `u64` - Total supply
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getTotalSupply"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":10126,"id":1}
-```
-
-### getVersion
-
-Returns the current solana versions running on the node
-
-#### Parameters:
-
-None
-
-#### Results:
-
-The result field will be a JSON object with the following sub fields:
-
-* `solana-core`, software version of solana-core
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getVersion"}' http://localhost:8899
-// Result
-{"jsonrpc":"2.0","result":{"solana-core": "0.17.2"},"id":1}
-```
-
-### getVoteAccounts
-
-Returns the account info and associated stake for all the voting accounts in the current bank.
-
-#### Parameters:
-
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment)
-
-#### Results:
-
-The result field will be a JSON object of `current` and `delinquent` accounts, each containing an array of JSON objects with the following sub fields:
-
-* `votePubkey` - Vote account public key, as base-58 encoded string
-* `nodePubkey` - Node public key, as base-58 encoded string
-* `activatedStake` - the stake, in lamports, delegated to this vote account and active in this epoch
-* `epochVoteAccount` - bool, whether the vote account is staked for this epoch
-* `commission`, percentage (0-100) of rewards payout owed to the vote account
-* `lastVote` - Most recent slot voted on by this vote account
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getVoteAccounts"}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":{"current":[{"commission":0,"epochVoteAccount":true,"nodePubkey":"B97CCUW3AEZFGy6uUg6zUdnNYvnVq5VG8PUtb2HayTDD","lastVote":147,"activatedStake":42,"votePubkey":"3ZT31jkAGhUaw8jsy4bTknwBMP8i4Eueh52By4zXcsVw"}],"delinquent":[{"commission":127,"epochVoteAccount":false,"nodePubkey":"6ZPxeQaDo4bkZLRsdNrCzchNQr5LN9QMc9sipXv9Kw8f","lastVote":0,"activatedStake":0,"votePubkey":"CmgCk4aMS7KW1SHX3s9K5tBJ6Yng2LBaC8MFov4wx9sm"}]},"id":1}
-```
-
-### requestAirdrop
-
-Requests an airdrop of lamports to a Pubkey
-
-#### Parameters:
-
-* `string` - Pubkey of account to receive lamports, as base-58 encoded string
-* `integer` - lamports, as a u64
-* `object` - (optional) [Commitment](jsonrpc-api.md#configuring-state-commitment) (used for retrieving blockhash and verifying airdrop success)
-
-#### Results:
-
-* `string` - Transaction Signature of airdrop, as base-58 encoded string
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"requestAirdrop", "params":["83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri", 50]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":"5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW","id":1}
-```
-
-### sendTransaction
-
-Creates new transaction
-
-#### Parameters:
-
-* `array` - array of octets containing a fully-signed Transaction
-
-#### Results:
-
-* `string` - Transaction Signature, as base-58 encoded string
-
-#### Example:
-
-```bash
-// Request
-curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"sendTransaction", "params":[[61, 98, 55, 49, 15, 187, 41, 215, 176, 49, 234, 229, 228, 77, 129, 221, 239, 88, 145, 227, 81, 158, 223, 123, 14, 229, 235, 247, 191, 115, 199, 71, 121, 17, 32, 67, 63, 209, 239, 160, 161, 2, 94, 105, 48, 159, 235, 235, 93, 98, 172, 97, 63, 197, 160, 164, 192, 20, 92, 111, 57, 145, 251, 6, 40, 240, 124, 194, 149, 155, 16, 138, 31, 113, 119, 101, 212, 128, 103, 78, 191, 80, 182, 234, 216, 21, 121, 243, 35, 100, 122, 68, 47, 57, 13, 39, 0, 0, 0, 0, 50, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 50, 0, 0, 0, 0, 0, 0, 0, 40, 240, 124, 194, 149, 155, 16, 138, 31, 113, 119, 101, 212, 128, 103, 78, 191, 80, 182, 234, 216, 21, 121, 243, 35, 100, 122, 68, 47, 57, 11, 12, 106, 49, 74, 226, 201, 16, 161, 192, 28, 84, 124, 97, 190, 201, 171, 186, 6, 18, 70, 142, 89, 185, 176, 154, 115, 61, 26, 163, 77, 1, 88, 98, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]}' http://localhost:8899
-
-// Result
-{"jsonrpc":"2.0","result":"2EBVM6cB8vAAD93Ktr6Vd8p67XPbQzCJX47MpReuiCXJAtcjaxpvWpcg9Ege1Nr5Tk3a2GFrByT7WPBjdsTycY9b","id":1}
-```
-
-### Subscription Websocket
-
-After connect to the RPC PubSub websocket at `ws://<ADDRESS>/`:
-
-* Submit subscription requests to the websocket using the methods below
-* Multiple subscriptions may be active at once
-* All subscriptions take an optional `confirmations` parameter, which defines
-
-  how many confirmed blocks the node should wait before sending a notification.
-
-  The greater the number, the more likely the notification is to represent
-
-  consensus across the cluster, and the less likely it is to be affected by
-
-  forking or rollbacks. If unspecified, the default value is 0; the node will
-
-  send a notification as soon as it witnesses the event. The maximum
-
-  `confirmations` wait length is the cluster's `MAX_LOCKOUT_HISTORY`, which
-
-  represents the economic finality of the chain.
-
-### accountSubscribe
-
-Subscribe to an account to receive notifications when the lamports or data for a given account public key changes
-
-#### Parameters:
-
-* `string` - account Pubkey, as base-58 encoded string
-* `integer` - optional, number of confirmed blocks to wait before notification.
-
-  Default: 0, Max: `MAX_LOCKOUT_HISTORY` \(greater integers rounded down\)
-
-#### Results:
-
-* `integer` - Subscription id \(needed to unsubscribe\)
-
-#### Example:
-
-```bash
-// Request
-{"jsonrpc":"2.0", "id":1, "method":"accountSubscribe", "params":["CM78CPUeXjn8o3yroDHxUtKsZZgoy4GPkPPXfouKNH12"]}
-
-{"jsonrpc":"2.0", "id":1, "method":"accountSubscribe", "params":["CM78CPUeXjn8o3yroDHxUtKsZZgoy4GPkPPXfouKNH12", 15]}
-
-// Result
-{"jsonrpc": "2.0","result": 0,"id": 1}
-```
-
-#### Notification Format:
-
-```bash
-{"jsonrpc": "2.0","method": "accountNotification", "params": {"result": {"executable":false,"owner":[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"lamports":1,"data":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0.22.0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]},"subscription":0}}
-```
-
-### accountUnsubscribe
-
-Unsubscribe from account change notifications
-
-#### Parameters:
-
-* `integer` - id of account Subscription to cancel
-
-#### Results:
-
-* `bool` - unsubscribe success message
-
-#### Example:
-
-```bash
-// Request
-{"jsonrpc":"2.0", "id":1, "method":"accountUnsubscribe", "params":[0]}
-
-// Result
-{"jsonrpc": "2.0","result": true,"id": 1}
-```
-
-### programSubscribe
-
-Subscribe to a program to receive notifications when the lamports or data for a given account owned by the program changes
-
-#### Parameters:
-
-* `string` - program\_id Pubkey, as base-58 encoded string
-* `integer` - optional, number of confirmed blocks to wait before notification.
-
-  Default: 0, Max: `MAX_LOCKOUT_HISTORY` \(greater integers rounded down\)
-
-#### Results:
-
-* `integer` - Subscription id \(needed to unsubscribe\)
-
-#### Example:
-
-```bash
-// Request
-{"jsonrpc":"2.0", "id":1, "method":"programSubscribe", "params":["9gZbPtbtHrs6hEWgd6MbVY9VPFtS5Z8xKtnYwA2NynHV"]}
-
-{"jsonrpc":"2.0", "id":1, "method":"programSubscribe", "params":["9gZbPtbtHrs6hEWgd6MbVY9VPFtS5Z8xKtnYwA2NynHV", 15]}
-
-// Result
-{"jsonrpc": "2.0","result": 0,"id": 1}
-```
-
-#### Notification Format:
-
-* `string` - account Pubkey, as base-58 encoded string
-* `object` - account info JSON object \(see [getAccountInfo](jsonrpc-api.md#getaccountinfo) for field details\)
-
-  ```bash
-  {"jsonrpc":"2.0","method":"programNotification","params":{{"result":["8Rshv2oMkPu5E4opXTRyuyBeZBqQ4S477VG26wUTFxUM",{"executable":false,"lamports":1,"owner":[129,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"data":[1,1,1,0,0,0,0,0,0,0.22.0,0,0,0,0,0,0,50,48,49,56,45,49,50,45,50,52,84,50,51,58,53,57,58,48,48,90,235,233,39,152,15,44,117,176,41,89,100,86,45,61,2,44,251,46,212,37,35,118,163,189,247,84,27,235,178,62,55,89,0,0,0,0,50,0,0,0,0,0,0,0,235,233,39,152,15,44,117,176,41,89,100,86,45,61,2,44,251,46,212,37,35,118,163,189,247,84,27,235,178,62,45,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}],"subscription":0}}
-  ```
-
-### programUnsubscribe
-
-Unsubscribe from program-owned account change notifications
-
-#### Parameters:
-
-* `integer` - id of account Subscription to cancel
-
-#### Results:
-
-* `bool` - unsubscribe success message
-
-#### Example:
-
-```bash
-// Request
-{"jsonrpc":"2.0", "id":1, "method":"programUnsubscribe", "params":[0]}
-
-// Result
-{"jsonrpc": "2.0","result": true,"id": 1}
-```
-
-### signatureSubscribe
-
-Subscribe to a transaction signature to receive notification when the transaction is confirmed On `signatureNotification`, the subscription is automatically cancelled
-
-#### Parameters:
-
-* `string` - Transaction Signature, as base-58 encoded string
-* `integer` - optional, number of confirmed blocks to wait before notification.
-
-  Default: 0, Max: `MAX_LOCKOUT_HISTORY` \(greater integers rounded down\)
-
-#### Results:
-
-* `integer` - subscription id \(needed to unsubscribe\)
-
-#### Example:
-
-```bash
-// Request
-{"jsonrpc":"2.0", "id":1, "method":"signatureSubscribe", "params":["2EBVM6cB8vAAD93Ktr6Vd8p67XPbQzCJX47MpReuiCXJAtcjaxpvWpcg9Ege1Nr5Tk3a2GFrByT7WPBjdsTycY9b"]}
-
-{"jsonrpc":"2.0", "id":1, "method":"signatureSubscribe", "params":["2EBVM6cB8vAAD93Ktr6Vd8p67XPbQzCJX47MpReuiCXJAtcjaxpvWpcg9Ege1Nr5Tk3a2GFrByT7WPBjdsTycY9b", 15]}
-
-// Result
-{"jsonrpc": "2.0","result": 0,"id": 1}
-```
-
-#### Notification Format:
-
-```bash
-{"jsonrpc": "2.0","method": "signatureNotification", "params": {"result": "Confirmed","subscription":0}}
-```
-
-### signatureUnsubscribe
-
-Unsubscribe from signature confirmation notification
-
-#### Parameters:
-
-* `integer` - subscription id to cancel
-
-#### Results:
-
-* `bool` - unsubscribe success message
-
-#### Example:
-
-```bash
-// Request
-{"jsonrpc":"2.0", "id":1, "method":"signatureUnsubscribe", "params":[0]}
-
-// Result
-{"jsonrpc": "2.0","result": true,"id": 1}
-```

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

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

book/src/apps/README.md

@@ -1,6 +1,20 @@
 # Programming Model
 
-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.
+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.
 
 ## Deploying Programs to a Cluster
 

book/src/apps/drones.md

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

book/src/building-from-source.md

@@ -1,4 +1,4 @@
-# Getting Started
+# Building from Source
 
 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 leader 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 validator for the demo, and make sure that udp ports 8000-10000 are open on all the machines you want to test with.
 
-Now start the bootstrap leader in a separate shell:
+Now start the bootstrap validator in a separate shell:
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/bootstrap-leader.sh
+$ NDEBUG=1 ./multinode-demo/bootstrap-validator.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-leader.sh
+$ NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/bootstrap-validator.sh
 $ NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/validator.sh
 ```
 
@@ -121,6 +121,34 @@ 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`.

book/src/cli/README.md

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

book/src/cluster/README.md

@@ -4,7 +4,7 @@ A Solana cluster is a set of validators working together to serve client transac
 
 ## Creating a Cluster
 
-Before starting any validators, one first needs to create a _genesis config_. The config references two public keys, a _mint_ and a _bootstrap 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.
+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.
 
 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 _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 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).

book/src/cluster/managing-forks.md

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

book/src/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](../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](../implemented-proposals/staking-rewards.md). This chapter, on the other hand, describes the underlying mechanics of its implementation.
 
 ## Basic Design
 
@@ -103,33 +103,12 @@ The Stake account is moved from Ininitialized to StakeState::Stake form. This is
 
 ### 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`.
+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.
 
 * `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.
@@ -162,11 +141,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](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/staking-and-rewards.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](../proposals/slashing.md).
 
 ### Basics
 
-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).
+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).
 
 Rewards for an epoch are not available until the end of that epoch.
 
@@ -228,4 +207,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.
+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.

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

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

book/src/implemented-proposals/blocktree.md

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

book/src/implemented-proposals/commitment.md

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

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

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

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

@@ -10,7 +10,6 @@ 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](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.
+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.
 
 **Figure 1**: Schematic overview of Solana economic incentive design.
-

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

@@ -8,5 +8,4 @@ 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](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\).
-
+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\).

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](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_validartion_client_economics.md)\)
+* the current global inflation rate, derived from the pre-determined dis-inflationary issuance schedule \(see [Validation-client Economics](.)\)
 * the fraction of staked SOLs out of the current total circulating supply,
 * the up-time/participation \[% of available slots that validator had opportunity to vote on\] of a given validator over the previous epoch.
 

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

@@ -13,7 +13,6 @@ 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](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_referenced.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](../ed_references.md).
 
 Additionally, the burnt fees can be a consideration in fork selection. In the case of a PoH fork with a malicious, censoring leader, we would expect the total fees destroyed to be less than a comparable honest fork, due to the fees lost from censoring. If the censoring leader is to compensate for these lost protocol fees, they would have to replace the burnt fees on their fork themselves, thus potentially reducing the incentive to censor in the first place.
-

book/src/implemented-proposals/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.
 
-## Credit only
+## Read-only accounts
 
-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.
+Read-only accounts are not being charged rent in current implementation.
 
 ## Design considerations, others considered
 

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

@@ -8,32 +8,32 @@ The RepairService is in charge of retrieving missing shreds that failed to be de
 
 1\) Validators can fail to receive particular shreds due to network failures
 
-2\) Consider a scenario where blocktree contains the set of slots {1, 3, 5}. Then Blocktree receives shreds for some slot 7, where for each of the shreds b, b.parent == 6, so then the parent-child relation 6 -> 7 is stored in blocktree. However, there is no way to chain these slots to any of the existing banks in Blocktree, and thus the `Shred Repair` protocol will not repair these slots. If these slots happen to be part of the main chain, this will halt replay progress on this node.
+2\) Consider a scenario where blockstore contains the set of slots {1, 3, 5}. Then Blockstore receives shreds for some slot 7, where for each of the shreds b, b.parent == 6, so then the parent-child relation 6 -> 7 is stored in blockstore. However, there is no way to chain these slots to any of the existing banks in Blockstore, and thus the `Shred Repair` protocol will not repair these slots. If these slots happen to be part of the main chain, this will halt replay progress on this node.
 
 3\) Validators that find themselves behind the cluster by an entire epoch struggle/fail to catch up because they do not have a leader schedule for future epochs. If nodes were to blindly accept repair shreds in these future epochs, this exposes nodes to spam.
 
 ## Repair Protocols
 
-The repair protocol makes best attempts to progress the forking structure of Blocktree.
+The repair protocol makes best attempts to progress the forking structure of Blockstore.
 
 The different protocol strategies to address the above challenges:
 
-1. Shred Repair \(Addresses Challenge \#1\): This is the most basic repair protocol, with the purpose of detecting and filling "holes" in the ledger. Blocktree tracks the latest root slot. RepairService will then periodically iterate every fork in blocktree starting from the root slot, sending repair requests to validators for any missing shreds. It will send at most some `N` repair reqeusts per iteration.
+1. Shred Repair \(Addresses Challenge \#1\): This is the most basic repair protocol, with the purpose of detecting and filling "holes" in the ledger. Blockstore tracks the latest root slot. RepairService will then periodically iterate every fork in blockstore starting from the root slot, sending repair requests to validators for any missing shreds. It will send at most some `N` repair reqeusts per iteration.
 
    Note: Validators will only accept shreds within the current verifiable epoch \(epoch the validator has a leader schedule for\).
 
 2. Preemptive Slot Repair \(Addresses Challenge \#2\): The goal of this protocol is to discover the chaining relationship of "orphan" slots that do not currently chain to any known fork.
-   * Blocktree will track the set of "orphan" slots in a separate column family.
-   * RepairService will periodically make `RequestOrphan` requests for each of the orphans in blocktree.
+   * Blockstore will track the set of "orphan" slots in a separate column family.
+   * RepairService will periodically make `RequestOrphan` requests for each of the orphans in blockstore.
 
      `RequestOrphan(orphan)` request - `orphan` is the orphan slot that the requestor wants to know the parents of `RequestOrphan(orphan)` response - The highest shreds for each of the first `N` parents of the requested `orphan`
 
      On receiving the responses `p`, where `p` is some shred in a parent slot, validators will:
 
-     * Insert an empty `SlotMeta` in blocktree for `p.slot` if it doesn't already exist.
+     * Insert an empty `SlotMeta` in blockstore for `p.slot` if it doesn't already exist.
      * If `p.slot` does exist, update the parent of `p` based on `parents`
 
-     Note: that once these empty slots are added to blocktree, the `Shred Repair` protocol should attempt to fill those slots.
+     Note: that once these empty slots are added to blockstore, the `Shred Repair` protocol should attempt to fill those slots.
 
      Note: Validators will only accept responses containing shreds within the current verifiable epoch \(epoch the validator has a leader schedule for\).
 3. Repairmen \(Addresses Challenge \#3\): This part of the repair protocol is the primary mechanism by which new nodes joining the cluster catch up after loading a snapshot. This protocol works in a "forward" fashion, so validators can verify every shred that they receive against a known leader schedule.
@@ -45,5 +45,5 @@ The different protocol strategies to address the above challenges:
 
      Observers of this gossip message with higher epochs \(repairmen\) send shreds to catch the lagging node up with the rest of the cluster. The repairmen are responsible for sending the slots within the epochs that are confrimed by the advertised `root` in gossip. The repairmen divide the responsibility of sending each of the missing slots in these epochs based on a random seed \(simple shred.index iteration by N, seeded with the repairman's node\_pubkey\). Ideally, each repairman in an N node cluster \(N nodes whose epochs are higher than that of the repairee\) sends 1/N of the missing shreds. Both data and coding shreds for missing slots are sent. Repairmen do not send shreds again to the same validator until they see the message in gossip updated, at which point they perform another iteration of this protocol.
 
-     Gossip messages are updated every time a validator receives a complete slot within the epoch. Completed slots are detected by blocktree and sent over a channel to RepairService. It is important to note that we know that by the time a slot X is complete, the epoch schedule must exist for the epoch that contains slot X because WindowService will reject shreds for unconfirmed epochs. When a newly completed slot is detected, we also update the current root if it has changed since the last update. The root is made available to RepairService through Blocktree, which holds the latest root.
+     Gossip messages are updated every time a validator receives a complete slot within the epoch. Completed slots are detected by blockstore and sent over a channel to RepairService. It is important to note that we know that by the time a slot X is complete, the epoch schedule must exist for the epoch that contains slot X because WindowService will reject shreds for unconfirmed epochs. When a newly completed slot is detected, we also update the current root if it has changed since the last update. The root is made available to RepairService through Blockstore, which holds the latest root.
 

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

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

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

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

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

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

book/src/offline-signing/README.md

@@ -75,3 +75,11 @@ Output
 ```text
 4vC38p4bz7XyiXrk6HtaooUqwxTWKocf45cstASGtmrD398biNJnmTcUCVEojE7wVQvgdYbjHJqRFZPpzfCQpmUN
 ```
+
+## Buying More Time to Sign
+
+Typically a Solana transaction must be signed and accepted by the network within
+a number of slots from the blockhash in its `recent_blockhash` field (~2min at
+the time of this writing). If your signing procedure takes longer than this, a
+[Durable Transaction Nonce](durable-nonce.md) can give you the extra time you
+need.

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

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

book/src/paper-wallet/usage.md

@@ -102,7 +102,7 @@ networked machine.
 Next, configure the `solana` CLI tool to connect to a particular cluster:
 
 ```bash
-solana set --url <CLUSTER URL> # (i.e. http://testnet.solana.com:8899)
+solana config set --url <CLUSTER URL> # (i.e. http://testnet.solana.com:8899)
 ```
 
 Finally, to check the balance, run the following command:

book/src/proposals/abi-management.md

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

book/src/proposals/bankless-leader.md

@@ -10,7 +10,7 @@ When replay stage starts processing the same transactions, it can assume that Po
 
 ## Fee Account
 
-The [fee account](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.
+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.
 
 ## Balance Cache
 
@@ -53,4 +53,3 @@ The same fee account can be reused many times in the same block until it is used
 Clients that transmit a large number of transactions per second should use a dedicated fee account that is not used as Credit-Debit in any instruction.
 
 Once an account fee is used as Credit-Debit, it will fail the balance check until the balance cache is reset.
-

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

@@ -1,74 +1,108 @@
 # 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.
 
-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.
+### Transaction Inclusion Proof
 
-Clients can examine this ledger data and compute the finality using Solana's fork selection rules.
+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.
 
-### Payment Merkle Path
+An Entry-Merkle is a Merkle Root including all transactions in a given entry,
+sorted by signature.
 
-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.
+A Block-Merkle is the Merkle Root of all the Entry-Merkles sequenced in the block.
 
 ![Block Merkle Diagram](../.gitbook/assets/spv-block-merkle.svg)
 
-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.
+A Bank-Hash is the hash of the concatenation of the Block-Merkle and Accounts-Hash
 
-### State Merkle Path
+<img alt="Bank Hash Diagram" src="img/spv-bank-hash.svg" class="center"/>
 
-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.
+An Accounts-Hash is the hash of the concatentation of the state hashes of each
+account modified during the current slot.
 
-For example:
+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.
 
-* A sends 5 Lamports to B
-* B spends 5 Lamports
-* C sends 5 Lamports to A
+### Account State Verification
 
-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.
+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.
 
 ### 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:
 
-* State -&gt; Bank-Merkle
-
-  or
-
-* Transaction -&gt; Entry-Merkle -&gt; Block-Merkle -&gt; Bank-Merkle
+* Transaction -&gt; Entry-Merkle -&gt; Block-Merkle -&gt; Bank-Hash
 
 And a vector of PoH entries:
 
@@ -89,21 +123,33 @@ 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](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.
+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.
 
 ### 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 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.
+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.
 
 ### Synthetic State
 
-Synthetic state should be computed into the Bank-Merkle along with the bank generated state.
+Synthetic state should be computed into the Bank-Hash 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-Merkle. They should live under known accounts, and therefore have an exact address in the Merkle Path.
+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.

book/src/proposals/tick-verification.md

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

book/src/proposals/validator-proposal.md

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

book/src/running-archiver.md

@@ -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 --entrypoint testnet.solana.com:8001 spy
+solana-gossip spy --entrypoint testnet.solana.com:8001
 # Press ^C to exit
 ```
 
@@ -146,11 +146,11 @@ solana-archiver --entrypoint testnet.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 --entrypoint testnet.solana.com:8001 spy
+solana-gossip spy --entrypoint testnet.solana.com:8001
 ```
 
-Provide the **storage account pubkey** to the `solana show-storage-account` command to view the recent mining activity from your archiver:
+Provide the **storage account pubkey** to the `solana storage-account` command to view the recent mining activity from your archiver:
 
 ```bash
-solana --keypair storage-keypair.json show-storage-account $STORAGE_IDENTITY
+solana --keypair storage-keypair.json storage-account $STORAGE_IDENTITY
 ```

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 --entrypoint testnet.solana.com:8001 spy
+solana-gossip spy --entrypoint testnet.solana.com:8001
 ```
 
 ## Check Your Balance
@@ -21,11 +21,11 @@ solana balance --lamports
 
 ## Check Vote Activity
 
-The `solana show-vote-account` command displays the recent voting activity from
+The `solana vote-account` command displays the recent voting activity from
 your validator:
 
 ```bash
-solana show-vote-account ~/validator-vote-keypair.json
+solana vote-account ~/validator-vote-keypair.json
 ```
 
 ## Get Cluster Info

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

@@ -54,11 +54,7 @@ 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. You'll want to periodically redeem/claim your rewards:
-
-```bash
-solana redeem-vote-credits ~/validator-stake-keypair.json ~/validator-vote-keypair.json
-```
+rewards. Rewards are paid automatically on epoch boundaries.
 
 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
@@ -85,11 +81,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 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`
+* 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 uptime ~/validator-vote-keypair.json` will display the voting history \(aka, uptime\) of your validator over recent Epochs
-* `solana show-validators` displays the current active stake of all validators, including yours
-* `solana show-show-stake-history ` shows the history of stake warming up and cooling down over recent epochs
+* `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
 * 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)
 
@@ -132,6 +128,3 @@ depending on active stake and the size of your stake.
 
 Note that a stake account may only be used once, so after deactivation, use the
 cli's `withdraw-stake` command to recover the previously staked lamports.
-
-Be sure and redeem your credits before withdrawing all your lamports. Once the
-account is fully withdrawn, the account is destroyed.

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

@@ -6,7 +6,7 @@ The solana cli includes `get` and `set` configuration commands to automatically
 set the `--url` argument for cli commands. For example:
 
 ```bash
-solana set --url http://testnet.solana.com:8899
+solana config set --url http://testnet.solana.com:8899
 ```
 
 \(You can always override the set configuration by explicitly passing the
@@ -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 get-transaction-count
+solana 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 --entrypoint testnet.solana.com:8001 spy
+solana-gossip spy --entrypoint testnet.solana.com:8001
 # Press ^C to exit
 ```
 
@@ -42,10 +42,6 @@ solana-gossip --entrypoint testnet.solana.com:8001 spy
 If your machine has a GPU with CUDA installed \(Linux-only currently\), include
 the `--cuda` argument to `solana-validator`.
 
-```bash
-export SOLANA_CUDA=1
-```
-
 When your validator is started look for the following log message to indicate
 that CUDA is enabled: `"[<timestamp> solana::validator] CUDA is enabled"`
 
@@ -104,7 +100,7 @@ Now that you have a keypair, set the solana configuration to use your validator
 keypair for all following commands:
 
 ```bash
-solana set --keypair ~/validator-keypair.json
+solana config set --keypair ~/validator-keypair.json
 ```
 
 You should see the following output:

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 leader
+## bootstrap validator
 
 The first [validator](terminology.md#validator) to produce a [block](terminology.md#block).
 
@@ -112,6 +112,10 @@ The configuration file that prepares the [ledger](terminology.md#ledger) for the
 
 A digital fingerprint of a sequence of bytes.
 
+## inflation
+
+An increase in token supply over time used to fund rewards for validation and replication and to fund continued development of Solana.
+
 ## instruction
 
 The smallest unit of a [program](terminology.md#program) that a [client](terminology.md#client) can include in a [transaction](terminology.md#instruction).

book/src/transaction.md

@@ -1,17 +1,79 @@
 # Anatomy 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.
+This chapter documents the binary format of a transaction.
 
-## Accounts and Signatures
+## Transaction Format
 
-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.
+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.
 
-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.
+### Signature Format
 
-## Recent Blockhash
+Each digital signature is in the ed25519 binary format and consumes 64 bytes.
 
-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
+## Message Format
 
-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 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.

book/src/validator/blockstore.md

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

chacha-cuda/Cargo.toml

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

chacha-cuda/src/chacha_cuda.rs

@@ -1,7 +1,7 @@
 // Module used by validators to approve storage mining proofs in parallel using the GPU
 
-use crate::chacha::{CHACHA_BLOCK_SIZE, CHACHA_KEY_SIZE};
-use solana_ledger::blocktree::Blocktree;
+use solana_chacha::chacha::{CHACHA_BLOCK_SIZE, CHACHA_KEY_SIZE};
+use solana_ledger::blockstore::Blockstore;
 use solana_perf::perf_libs;
 use solana_sdk::hash::Hash;
 use std::io;
@@ -13,7 +13,7 @@ use std::sync::Arc;
 // Then sample each block at the offsets provided by samples argument with sha256
 // and return the vec of sha states
 pub fn chacha_cbc_encrypt_file_many_keys(
-    blocktree: &Arc<Blocktree>,
+    blockstore: &Arc<Blockstore>,
     segment: u64,
     slots_per_segment: u64,
     ivecs: &mut [u8],
@@ -46,7 +46,7 @@ pub fn chacha_cbc_encrypt_file_many_keys(
         (api.chacha_init_sha_state)(int_sha_states.as_mut_ptr(), num_keys as u32);
     }
     loop {
-        match blocktree.get_data_shreds(current_slot, start_index, std::u64::MAX, &mut buffer) {
+        match blockstore.get_data_shreds(current_slot, start_index, std::u64::MAX, &mut buffer) {
             Ok((last_index, mut size)) => {
                 debug!(
                     "chacha_cuda: encrypting segment: {} num_shreds: {} data_len: {}",
@@ -113,8 +113,8 @@ pub fn chacha_cbc_encrypt_file_many_keys(
 #[cfg(test)]
 mod tests {
     use super::*;
-    use crate::archiver::sample_file;
-    use crate::chacha::chacha_cbc_encrypt_ledger;
+    use solana_archiver_utils::sample_file;
+    use solana_chacha::chacha::chacha_cbc_encrypt_ledger;
     use solana_ledger::entry::create_ticks;
     use solana_ledger::get_tmp_ledger_path;
     use solana_sdk::clock::DEFAULT_SLOTS_PER_SEGMENT;
@@ -134,9 +134,9 @@ mod tests {
         let entries = create_ticks(slots_per_segment, 0, Hash::default());
         let ledger_path = get_tmp_ledger_path!();
         let ticks_per_slot = 16;
-        let blocktree = Arc::new(Blocktree::open(&ledger_path).unwrap());
+        let blockstore = Arc::new(Blockstore::open(&ledger_path).unwrap());
 
-        blocktree
+        blockstore
             .write_entries(
                 0,
                 0,
@@ -160,7 +160,7 @@ mod tests {
 
         let mut cpu_iv = ivecs.clone();
         chacha_cbc_encrypt_ledger(
-            &blocktree,
+            &blockstore,
             0,
             slots_per_segment as u64,
             out_path,
@@ -171,7 +171,7 @@ mod tests {
         let ref_hash = sample_file(&out_path, &samples).unwrap();
 
         let hashes = chacha_cbc_encrypt_file_many_keys(
-            &blocktree,
+            &blockstore,
             0,
             slots_per_segment as u64,
             &mut ivecs,
@@ -196,8 +196,8 @@ mod tests {
         let ledger_path = get_tmp_ledger_path!();
         let ticks_per_slot = 90;
         let entries = create_ticks(2 * ticks_per_slot, 0, Hash::default());
-        let blocktree = Arc::new(Blocktree::open(&ledger_path).unwrap());
-        blocktree
+        let blockstore = Arc::new(Blockstore::open(&ledger_path).unwrap());
+        blockstore
             .write_entries(
                 0,
                 0,
@@ -224,7 +224,7 @@ mod tests {
             ivec[0] = i;
             ivecs.extend(ivec.clone().iter());
             chacha_cbc_encrypt_ledger(
-                &blocktree.clone(),
+                &blockstore.clone(),
                 0,
                 DEFAULT_SLOTS_PER_SEGMENT,
                 out_path,
@@ -242,7 +242,7 @@ mod tests {
         }
 
         let hashes = chacha_cbc_encrypt_file_many_keys(
-            &blocktree,
+            &blockstore,
             0,
             DEFAULT_SLOTS_PER_SEGMENT,
             &mut ivecs,
@@ -267,9 +267,9 @@ mod tests {
         let mut keys = hex!("abc123");
         let ledger_path = get_tmp_ledger_path!();
         let samples = [0];
-        let blocktree = Arc::new(Blocktree::open(&ledger_path).unwrap());
+        let blockstore = Arc::new(Blockstore::open(&ledger_path).unwrap());
         assert!(chacha_cbc_encrypt_file_many_keys(
-            &blocktree,
+            &blockstore,
             0,
             DEFAULT_SLOTS_PER_SEGMENT,
             &mut keys,

chacha-cuda/src/lib.rs

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

chacha-sys/Cargo.toml

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

chacha/.gitignore

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

chacha/Cargo.toml

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

chacha/src/chacha.rs

@@ -1,4 +1,4 @@
-use solana_ledger::blocktree::Blocktree;
+use solana_ledger::blockstore::Blockstore;
 use solana_sdk::clock::Slot;
 use std::fs::File;
 use std::io;
@@ -12,7 +12,7 @@ pub const CHACHA_BLOCK_SIZE: usize = 64;
 pub const CHACHA_KEY_SIZE: usize = 32;
 
 pub fn chacha_cbc_encrypt_ledger(
-    blocktree: &Arc<Blocktree>,
+    blockstore: &Arc<Blockstore>,
     start_slot: Slot,
     slots_per_segment: u64,
     out_path: &Path,
@@ -28,7 +28,7 @@ pub fn chacha_cbc_encrypt_ledger(
     let mut current_slot = start_slot;
     let mut start_index = 0;
     loop {
-        match blocktree.get_data_shreds(current_slot, start_index, std::u64::MAX, &mut buffer) {
+        match blockstore.get_data_shreds(current_slot, start_index, std::u64::MAX, &mut buffer) {
             Ok((last_index, mut size)) => {
                 debug!(
                     "chacha: encrypting slice: {} num_shreds: {} data_len: {}",
@@ -74,13 +74,14 @@ pub fn chacha_cbc_encrypt_ledger(
 #[cfg(test)]
 mod tests {
     use crate::chacha::chacha_cbc_encrypt_ledger;
-    use crate::gen_keys::GenKeys;
-    use solana_ledger::blocktree::Blocktree;
+    use rand::SeedableRng;
+    use rand_chacha::ChaChaRng;
+    use solana_ledger::blockstore::Blockstore;
     use solana_ledger::entry::Entry;
     use solana_ledger::get_tmp_ledger_path;
     use solana_sdk::hash::{hash, Hash, Hasher};
     use solana_sdk::pubkey::Pubkey;
-    use solana_sdk::signature::KeypairUtil;
+    use solana_sdk::signature::{Keypair, KeypairUtil};
     use solana_sdk::system_transaction;
     use std::fs::remove_file;
     use std::fs::File;
@@ -92,8 +93,9 @@ mod tests {
         let one = hash(&zero.as_ref());
 
         let seed = [2u8; 32];
-        let mut rnd = GenKeys::new(seed);
-        let keypair = rnd.gen_keypair();
+
+        let mut generator = ChaChaRng::from_seed(seed);
+        let keypair = Keypair::generate(&mut generator);
 
         let mut id = one;
         let mut num_hashes = 0;
@@ -131,15 +133,16 @@ mod tests {
         let ledger_path = get_tmp_ledger_path!();
         let ticks_per_slot = 16;
         let slots_per_segment = 32;
-        let blocktree = Arc::new(Blocktree::open(&ledger_path).unwrap());
+        let blockstore = Arc::new(Blockstore::open(&ledger_path).unwrap());
         let out_path = tmp_file_path("test_encrypt_ledger");
 
         let seed = [2u8; 32];
-        let mut rnd = GenKeys::new(seed);
-        let keypair = rnd.gen_keypair();
+
+        let mut generator = ChaChaRng::from_seed(seed);
+        let keypair = Keypair::generate(&mut generator);
 
         let entries = make_tiny_deterministic_test_entries(slots_per_segment);
-        blocktree
+        blockstore
             .write_entries(
                 0,
                 0,
@@ -157,8 +160,14 @@ mod tests {
             "abcd1234abcd1234abcd1234abcd1234 abcd1234abcd1234abcd1234abcd1234
                             abcd1234abcd1234abcd1234abcd1234 abcd1234abcd1234abcd1234abcd1234"
         );
-        chacha_cbc_encrypt_ledger(&blocktree, 0, slots_per_segment as u64, &out_path, &mut key)
-            .unwrap();
+        chacha_cbc_encrypt_ledger(
+            &blockstore,
+            0,
+            slots_per_segment as u64,
+            &out_path,
+            &mut key,
+        )
+        .unwrap();
         let mut out_file = File::open(&out_path).unwrap();
         let mut buf = vec![];
         let size = out_file.read_to_end(&mut buf).unwrap();

chacha/src/lib.rs

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

ci/buildkite.yml

@@ -20,7 +20,7 @@ steps:
     timeout_in_minutes: 30
   - command: ". ci/rust-version.sh; ci/docker-run.sh $$rust_stable_docker_image ci/test-stable.sh"
     name: "stable"
-    timeout_in_minutes: 40
+    timeout_in_minutes: 60
     artifact_paths: "log-*.txt"
   - command: ". ci/rust-version.sh; ci/docker-run.sh $$rust_stable_docker_image ci/test-move.sh"
     name: "move"

ci/docker-run.sh

@@ -72,10 +72,14 @@ ARGS+=(
   --env CI_JOB_ID
   --env CI_PULL_REQUEST
   --env CI_REPO_SLUG
-  --env CODECOV_TOKEN
   --env CRATES_IO_TOKEN
 )
 
+# Also propagate environment variables needed for codecov
+# https://docs.codecov.io/docs/testing-with-docker#section-codecov-inside-docker
+# We normalize CI to `1`; but codecov expects it to be `true` to detect Buildkite...
+CODECOV_ENVS=$(CI=true bash <(curl -s https://codecov.io/env))
+
 if $INTERACTIVE; then
   if [[ -n $1 ]]; then
     echo
@@ -83,8 +87,10 @@ if $INTERACTIVE; then
     echo
   fi
   set -x
-  exec docker run --interactive --tty "${ARGS[@]}" "$IMAGE" bash
+  # shellcheck disable=SC2086
+  exec docker run --interactive --tty "${ARGS[@]}" $CODECOV_ENVS "$IMAGE" bash
 fi
 
 set -x
-exec docker run "${ARGS[@]}" "$IMAGE" "$@"
+# shellcheck disable=SC2086
+exec docker run "${ARGS[@]}" $CODECOV_ENVS "$IMAGE" "$@"

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 leader will be used.
+                 the bootstrap validator 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-leader.sh \
+  "multinode-demo/bootstrap-validator.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 leader, wait until it boots before starting
+    # 1 == bootstrap validator, 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-leader/identity-keypair.json \
-          --url http://127.0.0.1:8899 get-genesis-hash
+        $solana_cli --keypair config/bootstrap-validator/identity-keypair.json \
+          --url http://127.0.0.1:8899 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-leader validator; do
+  for ledger in bootstrap-validator 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-leader getTransactionCount ($iteration)"
+  echo "--- RPC API: bootstrap-validator 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-leader node is advancing
+  # Verify transaction count as reported by the bootstrap-validator 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"

ci/nits.sh

@@ -20,6 +20,7 @@ declare prints=(
 declare print_free_tree=(
   'core/src'
   'faucet/src'
+  'ledger/src'
   'metrics/src'
   'net-utils/src'
   'runtime/src'

ci/publish-book.sh

@@ -5,95 +5,27 @@ cd "$(dirname "$0")/.."
 
 me=$(basename "$0")
 
-BOOK="book"
-
-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
+echo --- update gitbook-cage
+if [[ -n $CI_BRANCH ]]; then
+  (
+    set -x
     (
-      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
+      . ci/rust-version.sh stable
+      ci/docker-run.sh "$rust_stable_docker_image" make -Cbook -B svg
+    )
+    # make a local commit for the svgs
+    git add -A -f book/src/.gitbook/assets/.
+    if ! git diff-index --quiet HEAD; then
+      git config user.email maintainers@solana.com
+      git config user.name "$me"
+      git commit -m "gitbook-cage update $(date -Is)"
+      git push -f git@github.com:solana-labs/solana-gitbook-cage.git HEAD:refs/heads/"$CI_BRANCH"
+      # pop off the local commit
+      git reset --hard HEAD~
+    fi
+  )
 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
+  echo CI_BRANCH not set
 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
-)
-
-echo --- update gitbook-cage
-(
-  if [[ -z $CI_BRANCH ]]; then
-    exit 0
-  fi
-
-  set -x
-  (
-    . ci/rust-version.sh
-    ci/docker-run.sh $rust_stable_docker_image make -Cbook -B svg
-  )
-  # make a local commit for the svgs
-  git add -A -f book/src/.gitbook/assets/.
-  if ! git diff-index --quiet HEAD; then
-    git config user.email maintainers@solana.com
-    git config user.name "$me"
-    git commit -m "gitbook-cage update $(date -Is)"
-    git push -f git@github.com:solana-labs/solana-gitbook-cage.git HEAD:refs/heads/"$CI_BRANCH"
-    # pop off the local commit
-    git reset --hard HEAD~
-  fi
-)
-
 exit 0

ci/publish-bpf-sdk.sh

@@ -4,7 +4,12 @@ set -e
 cd "$(dirname "$0")/.."
 eval "$(ci/channel-info.sh)"
 
-echo --- Creating tarball
+if [[ -n "$CI_TAG" ]]; then
+  CHANNEL_OR_TAG=$CI_TAG
+else
+  CHANNEL_OR_TAG=$CHANNEL
+fi
+
 (
   set -x
   sdk/bpf/scripts/package.sh
@@ -12,7 +17,7 @@ echo --- Creating tarball
 )
 
 echo --- AWS S3 Store
-if [[ -z $CHANNEL ]]; then
+if [[ -z $CHANNEL_OR_TAG ]]; then
   echo Skipped
 else
   (
@@ -24,7 +29,7 @@ else
       --volume "$PWD:/solana" \
       eremite/aws-cli:2018.12.18 \
       /usr/bin/s3cmd --acl-public put /solana/bpf-sdk.tar.bz2 \
-      s3://solana-sdk/"$CHANNEL"/bpf-sdk.tar.bz2
+      s3://solana-sdk/"$CHANNEL_OR_TAG"/bpf-sdk.tar.bz2
   )
 fi
 

ci/publish-tarball.sh

@@ -53,7 +53,7 @@ windows)
   ;;
 esac
 
-echo --- Creating tarball
+echo --- Creating release tarball
 (
   set -x
   rm -rf solana-release/
@@ -89,15 +89,21 @@ echo --- Creating tarball
 )
 
 # Metrics tarball is platform agnostic, only publish it from Linux
-MAYBE_METRICS_TARBALL=
+MAYBE_TARBALLS=
 if [[ "$CI_OS_NAME" = linux ]]; then
   metrics/create-metrics-tarball.sh
-  MAYBE_METRICS_TARBALL=solana-metrics.tar.bz2
+  (
+    set -x
+    sdk/bpf/scripts/package.sh
+    [[ -f bpf-sdk.tar.bz2 ]]
+
+  )
+  MAYBE_TARBALLS="bpf-sdk.tar.bz2 solana-metrics.tar.bz2"
 fi
 
 source ci/upload-ci-artifact.sh
 
-for file in solana-release-$TARGET.tar.bz2 solana-release-$TARGET.yml solana-install-init-"$TARGET"* $MAYBE_METRICS_TARBALL; do
+for file in solana-release-$TARGET.tar.bz2 solana-release-$TARGET.yml solana-install-init-"$TARGET"* $MAYBE_TARBALLS; do
   upload-ci-artifact "$file"
 
   if [[ -n $DO_NOT_PUBLISH_TAR ]]; then

ci/test-checks.sh

@@ -10,6 +10,9 @@ source ci/rust-version.sh nightly
 export RUST_BACKTRACE=1
 export RUSTFLAGS="-D warnings"
 
+# Look for failed mergify.io backports
+_ git show HEAD --check --oneline
+
 _ cargo +"$rust_stable" fmt --all -- --check
 
 # Clippy gets stuck for unknown reasons if sdk-c is included in the build, so check it separately.
@@ -19,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-2019-0013 --ignore RUSTSEC-2018-0015 --ignore RUSTSEC-2019-0031
+_ cargo +"$rust_stable" audit --ignore RUSTSEC-2020-0002
 _ ci/nits.sh
 _ ci/order-crates-for-publishing.py
 _ book/build.sh
@@ -27,7 +30,7 @@ _ ci/check-ssh-keys.sh
 
 {
   cd programs/bpf
-  _ cargo +"$rust_stable" audit --ignore RUSTSEC-2019-0031
+  _ cargo +"$rust_stable" audit
   for project in rust/*/ ; do
     echo "+++ do_bpf_checks $project"
     (

ci/test-coverage.sh

@@ -41,7 +41,8 @@ if [[ -z "$CODECOV_TOKEN" ]]; then
   echo "^^^ +++"
   echo CODECOV_TOKEN undefined, codecov.io upload skipped
 else
-  bash <(curl -s https://codecov.io/bash) -X gcov -f target/cov/lcov.info
+  # We normalize CI to `1`; but codecov expects it to be `true` to detect Buildkite...
+  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}"

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-perf --package solana-ledger --package solana-core --lib ${V:+--verbose} -- --nocapture
+  _ cargo +"$rust_stable" test --package solana-chacha-cuda --package solana-perf --package solana-ledger --package solana-core --lib ${V:+--verbose} -- --nocapture
   ;;
 test-move)
   ci/affects-files.sh \
@@ -111,7 +111,7 @@ test-move)
   ;;
 test-local-cluster)
   _ cargo +"$rust_stable" build --release --bins ${V:+--verbose}
-  _ cargo +"$rust_stable" test --release --package solana-local-cluster ${V:+--verbose} -- --nocapture
+  _ cargo +"$rust_stable" test --release --package solana-local-cluster ${V:+--verbose} -- --nocapture --test-threads=1
   exit 0
   ;;
 *)

ci/testnet-manager.sh

@@ -142,6 +142,7 @@ testnet-beta|testnet-beta-perf)
 testnet)
   CHANNEL_OR_TAG=$STABLE_CHANNEL_LATEST_TAG
   CHANNEL_BRANCH=$STABLE_CHANNEL
+  export CLOUDSDK_CORE_PROJECT=testnet-solana-com
   ;;
 testnet-perf)
   CHANNEL_OR_TAG=$STABLE_CHANNEL_LATEST_TAG
@@ -157,6 +158,7 @@ tds)
   : "${TDS_CHANNEL_OR_TAG:=edge}"
   CHANNEL_OR_TAG="$TDS_CHANNEL_OR_TAG"
   CHANNEL_BRANCH="$CI_BRANCH"
+  export CLOUDSDK_CORE_PROJECT=tour-de-sol
   ;;
 *)
   echo "Error: Invalid TESTNET=$TESTNET"
@@ -204,6 +206,7 @@ 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
@@ -375,7 +378,7 @@ deploy() {
     (
       set -x
       ci/testnet-deploy.sh -p testnet-solana-com -C gce -z us-west1-b \
-        -t "$CHANNEL_OR_TAG" -n 3 -c 0 -u -P \
+        -t "$CHANNEL_OR_TAG" -n 1 -c 0 -u -P \
         -a testnet-solana-com --letsencrypt testnet.solana.com \
         --limit-ledger-size \
         ${skipCreate:+-e} \
@@ -460,6 +463,14 @@ deploy() {
         maybeGpu=(-G "${ENABLE_GPU}")
       fi
 
+      if [[ -z $HASHES_PER_TICK ]]; then
+        maybeHashesPerTick="--hashes-per-tick auto"
+      elif [[ $HASHES_PER_TICK == skip ]]; then
+        maybeHashesPerTick=""
+      else
+        maybeHashesPerTick="--hashes-per-tick ${HASHES_PER_TICK}"
+      fi
+
       if [[ -z $DISABLE_AIRDROPS ]]; then
         DISABLE_AIRDROPS="true"
       fi
@@ -470,6 +481,22 @@ deploy() {
         maybeDisableAirdrops=""
       fi
 
+      if [[ -z $INTERNAL_NODES_STAKE_LAMPORTS ]]; then
+        maybeInternalNodesStakeLamports="--internal-nodes-stake-lamports 1000000000" # 1 SOL
+      elif [[ $INTERNAL_NODES_STAKE_LAMPORTS == skip ]]; then
+        maybeInternalNodesStakeLamports=""
+      else
+        maybeInternalNodesStakeLamports="--internal-nodes-stake-lamports ${INTERNAL_NODES_STAKE_LAMPORTS}"
+      fi
+
+      if [[ -z $INTERNAL_NODES_LAMPORTS ]]; then
+        maybeInternalNodesLamports="--internal-nodes-lamports 500000000000" # 500 SOL
+      elif [[ $INTERNAL_NODES_LAMPORTS == skip ]]; then
+        maybeInternalNodesLamports=""
+      else
+        maybeInternalNodesLamports="--internal-nodes-lamports ${INTERNAL_NODES_LAMPORTS}"
+      fi
+
       EXTERNAL_ACCOUNTS_FILE=/tmp/validator.yml
       if [[ -z $EXTERNAL_ACCOUNTS_FILE_URL ]]; then
         EXTERNAL_ACCOUNTS_FILE_URL=https://raw.githubusercontent.com/solana-labs/tour-de-sol/master/validators/all.yml
@@ -503,11 +530,14 @@ deploy() {
         --idle-clients \
         -P -u \
         -a tds-solana-com --letsencrypt tds.solana.com \
+        ${maybeHashesPerTick} \
         ${skipCreate:+-e} \
         ${skipStart:+-s} \
         ${maybeStop:+-S} \
         ${maybeDelete:+-D} \
         ${maybeDisableAirdrops} \
+        ${maybeInternalNodesStakeLamports} \
+        ${maybeInternalNodesLamports} \
         ${maybeExternalAccountsFile} \
         --target-lamports-per-signature 0 \
         --slots-per-epoch 4096 \

ci/testnet-sanity.sh

@@ -60,7 +60,7 @@ trap shutdown EXIT INT
 set -x
 for zone in "$@"; do
   echo "--- $cloudProvider config [$zone]"
-  timeout 5m net/"$cloudProvider".sh config $maybePublicNetwork -p "$netName" -z "$zone"
+  timeout 5m net/"$cloudProvider".sh config $maybePublicNetwork -n 1 -p "$netName" -z "$zone"
   net/init-metrics.sh -e
   echo "+++ $cloudProvider.sh info"
   net/"$cloudProvider".sh info

clap-utils/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "solana-clap-utils"
-version = "0.22.0"
+version = "0.23.0"
 description = "Solana utilities for the clap"
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 repository = "https://github.com/solana-labs/solana"
@@ -12,8 +12,8 @@ edition = "2018"
 clap = "2.33.0"
 rpassword = "4.0"
 semver = "0.9.0"
-solana-sdk = { path = "../sdk", version = "0.22.0" }
-tiny-bip39 = "0.6.2"
+solana-sdk = { path = "../sdk", version = "0.23.0" }
+tiny-bip39 = "0.7.0"
 url = "2.1.0"
 chrono = "0.4"