Revert "Initialize stopNetwork var"

This reverts commit ecfe655ba3.

.buildkite/env/secrets.ejson

@@ -1,10 +1,12 @@
 {
     "_public_key": "ae29f4f7ad2fc92de70d470e411c8426d5d48db8817c9e3dae574b122192335f",
     "environment": {
-      "CODECOV_TOKEN": "EJ[1:Kqnm+k1Z4p8nr7GqMczXnzh6azTk39tj3bAbCKPitUc=:EzVa4Gpj2Qn5OhZQlVfGFchuROgupvnW:CbWc6sNh1GCrAbrncxDjW00zUAD/Sa+ccg7CFSz8Ua6LnCYnSddTBxJWcJEbEs0MrjuZRQ==]",
-      "CRATES_IO_TOKEN": "EJ[1:Kqnm+k1Z4p8nr7GqMczXnzh6azTk39tj3bAbCKPitUc=:qF7QrUM8j+19mptcE1YS71CqmrCM13Ah:TZCatJeT1egCHiufE6cGFC1VsdJkKaaqV6QKWkEsMPBKvOAdaZbbVz9Kl+lGnIsF]",
-      "INFLUX_DATABASE": "EJ[1:Kqnm+k1Z4p8nr7GqMczXnzh6azTk39tj3bAbCKPitUc=:PetD/4c/EbkQmFEcK21g3cBBAPwFqHEw:wvYmDZRajy2WngVFs9AlwyHk]",
-      "INFLUX_USERNAME": "EJ[1:Kqnm+k1Z4p8nr7GqMczXnzh6azTk39tj3bAbCKPitUc=:WcnqZdmDFtJJ01Zu5LbeGgbYGfRzBdFc:a7c5zDDtCOu5L1Qd2NKkxT6kljyBcbck]",
-      "INFLUX_PASSWORD": "EJ[1:Kqnm+k1Z4p8nr7GqMczXnzh6azTk39tj3bAbCKPitUc=:LIZgP9Tp9yE9OlpV8iogmLOI7iW7SiU3:x0nYdT1A6sxu+O+MMLIN19d2t6rrK1qJ3+HnoWG3PDodsXjz06YJWQKU/mx6saqH+QbGtGV5mk0=]"
+      "CODECOV_TOKEN": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:rHBSqXK7uSnveA4qwUxARZjTNZcA0hXU:ko8lLGwPECpVm19znWBRxKEpMF7xpTHBCEzVOxRar2wDThw4lNDAKqTS61vtkJLtdkHtug==]",
+      "CRATES_IO_TOKEN": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:NzN6y0ooXJBYvxB589khepthSxhKFkLB:ZTTFZh2A/kB2SAgjJJAMbwAfanRlzxOCNMVcA2MXBCpQHJeeZGULg+0MLACYswfS]",
+      "GITHUB_TOKEN": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:iy0Fnxeo0aslTCvgXc5Ddj2ly6ZsQ8gK:GNOOj/kZUJ2rYKxTbLyVKtajWNoGQ3PcChwfEB4HdN18qDHlB96Z7gx01Pcf0qeIHODOWRtxlH4=]",
+      "INFLUX_DATABASE": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:Ly/TpIRF0oCxmiBWv225S3mX8s6pfQR+:+tXGB2c9rRCVDcgNO1IDOo89]",
+      "INFLUX_PASSWORD": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:ycrq1uQLoSfI932czD+krUOaJeLWpeq6:2iS7ukp/C7wVD3IT0GvQVcwccWGyLr4UocStF/XiDi0OB/N3YKIKN8SQU4ob1b6StAPZ/XOHmag=]",
+      "INFLUX_USERNAME": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:35hBKofakZ4Db/u0TOW53RXoNWzJTIcl:HWREcMTrgZ8DGB0ZupgSzNWr/tVyE06P]",
+      "SOLANA_INSTALL_UPDATE_MANIFEST_KEYPAIR_x86_64_unknown_linux_gnu": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:kRz8CyJYKAg/AiwgLrcRNDJAmlRX2zvX:uV1XV6y2Fb+dN4Z9BIMPBRiNS3n+NL8GlJXyu1i7meIsph1DzfLg4Thcp5Mj9nUsFNLgqQgjnsa5C4XNY/h5AgMSzRrJxVj7RhVTRmDJ5/Vjq6v7wCMRfBOvF3rITsV4zTwWSV8yafFmS+ZQ+QJTRgtYsuoYAUNZ06IEebfDHcuNwws72hEGoD9w43hOLSpyEOmXbtZ9h1lIRxrgsrhYDpBlU5LkhDeTXAX5M5dwYxyquJFRwd5quGDV5DYsCh9bAkbjAyjWYymVJ78U9YJIQHT9izzQqTDlMQN49EbLo7MDIaC7O7HVtb7unDJs+DRejbHacoyWVulqVVwu3GRiZezu8zdjwzGHphMMxOtKQaidnqYgflNp/O01I8wZRgR1alsGcmIhEhI8YV/IvQ==]"
     }
 }

.buildkite/hooks/post-checkout

@@ -1,2 +1,33 @@
 CI_BUILD_START=$(date +%s)
 export CI_BUILD_START
+
+#
+# Kill any running docker containers, which are potentially left over from the
+# previous CI job
+#
+(
+  containers=$(docker ps -q)
+  if [[ $(hostname) != metrics-solana-com && -n $containers ]]; then
+    echo "+++ Killing stale docker containers"
+    docker ps
+
+    # shellcheck disable=SC2086 # Don't want to double quote $containers
+    docker kill $containers
+  fi
+)
+
+# Processes from previously aborted CI jobs seem to loiter, unclear why as one
+# would expect the buildkite-agent to clean up all child processes of the
+# aborted CI job.
+# But as a workaround for now manually kill some known loiterers.  These
+# processes will all have the `init` process as their PPID:
+(
+  victims=
+  for name in bash cargo docker solana; do
+    victims="$victims $(pgrep -u "$(id -u)" -P 1 -d \  $name)"
+  done
+  for victim in $victims; do
+    echo "Killing pid $victim"
+    kill -9 "$victim" || true
+  done
+)

.codecov.yml

@@ -1,5 +1,12 @@
-ignore:
-  - "src/bin" 
 coverage:
+  range: 50..100
+  round: down
+  precision: 1
   status:
+    project: off
     patch: off
+
+comment:
+  layout: "diff"
+  behavior: default
+  require_changes: no

.gitignore

@@ -1,4 +1,7 @@
 /target/
+/ledger-tool/target/
+/wallet/target/
+/core/target/
 /book/html/
 /book/src/img/
 /book/src/tests.ok

CONTRIBUTING.md

@@ -8,6 +8,56 @@ don't agree with a convention, submit a PR patching this document and let's disc
 the PR is accepted, *all* code should be updated as soon as possible to reflect the new
 conventions.
 
+Pull Requests
+---
+
+Small, frequent PRs are much preferred to large, infrequent ones. A large PR is difficult
+to review, can block others from making progress, and can quickly get its author into
+"rebase hell". A large PR oftentimes arises when one change requires another, which requires
+another, and then another. When you notice those dependencies, put the fix into a commit of
+its own, then checkout a new branch, and cherrypick it. Open a PR to start the review
+process and then jump back to your original branch to keep making progress. Once the commit
+is merged, you can use git-rebase to purge it from your original branch.
+
+```bash
+$ git pull --rebase upstream master
+```
+
+### How big is too big?
+
+If there are no functional changes, PRs can be very large and that's no problem. If,
+however, your changes are making meaningful changes or additions, then about 1,000 lines of
+changes is about the most you should ask a Solana maintainer to review.
+
+### Should I send small PRs as I develop large, new components?
+
+Add only code to the codebase that is ready to be deployed. If you are building a large
+library, consider developing it in a separate git repository. When it is ready to be
+integrated, the Solana maintainers will work with you to decide on a path forward. Smaller
+libraries may be copied in whereas very large ones may be pulled in with a package manager.
+
+### When will my PR be reviewed?
+
+PRs are typically reviewed and merged in under 7 days. If your PR has been open for longer,
+it's a strong indicator that the reviewers aren't confident the change meets the quality
+standards of the codebase. You might consider closing it and coming back with smaller PRs
+and longer descriptions detailing what problem it solves and how it solves it.
+
+Draft Pull Requests
+---
+
+If you want early feedback on your PR, use GitHub's "Draft Pull Request"
+mechanism. Draft PRs are a convenient way to collaborate with the Solana
+maintainers without triggering notifications as you make changes. When you feel
+your PR is ready for a broader audience, you can transition your draft PR to a
+standard PR with the click of a button.
+
+Do not add reviewers to draft PRs.  GitHub doesn't automatically clear approvals
+when you click "Ready for Review", so a review that meant "I approve of the
+direction" suddenly has the appearance of "I approve of these changes." Instead,
+add a comment that mentions the usernames that you would like a review from. Ask
+explicitly what you would like feedback on.
+
 Rust coding conventions
 ---
 
@@ -46,24 +96,23 @@ understood. Avoid introducing new 3-letter terms, which can be confused with 3-l
 [Terms currently in use](book/src/terminology.md)
 
 
-Proposing architectural changes
+Design Proposals
 ---
 
 Solana's architecture is described by a book generated from markdown files in
 the `book/src/` directory, maintained by an *editor* (currently @garious). To
-change the architecture, you'll need to at least propose a change the content
-under the [Proposed
-Changes](https://solana-labs.github.io/solana/proposals.html) chapter. Here's
-the full process:
+add a design proposal, you'll need to at least propose a change the content
+under the [Accepted Design
+Proposals](https://solana-labs.github.io/book-edge/proposals.html) chapter.
+Here's the full process:
 
-1. Propose to a change to the architecture by creating a PR that adds a
-   markdown document to the directory `book/src/` and references it from the
-   [table of contents](book/src/SUMMARY.md). Add the editor and any relevant
-   *maintainers* to the PR review.
+1. Propose a design by creating a PR that adds a markdown document to the
+   directory `book/src/` and references it from the [table of
+   contents](book/src/SUMMARY.md). Add any relevant *maintainers* to the PR review.
 2. The PR being merged indicates your proposed change was accepted and that the
-   editor and maintainers support your plan of attack.
+   maintainers support your plan of attack.
 3. Submit PRs that implement the proposal. When the implementation reveals the
-   need for tweaks to the architecture, be sure to update the proposal and have
+   need for tweaks to the proposal, be sure to update the proposal and have
    that change reviewed by the same people as in step 1.
-4. Once the implementation is complete, the editor will then work to integrate
-   the document into the book.
+4. Once the implementation is complete, submit a PR that moves the link from
+   the Accepted Proposals to the Implemented Proposals section.

Cargo.toml

@@ -1,91 +1,3 @@
-[package]
-name = "solana"
-description = "Blockchain, Rebuilt for Scale"
-version = "0.11.0"
-documentation = "https://docs.rs/solana"
-homepage = "https://solana.com/"
-readme = "README.md"
-repository = "https://github.com/solana-labs/solana"
-authors = ["Solana Maintainers <maintainers@solana.com>"]
-license = "Apache-2.0"
-edition = "2018"
-
-[badges]
-codecov = { repository = "solana-labs/solana", branch = "master", service = "github" }
-
-[features]
-bpf_c = ["solana-bpfloader/bpf_c"]
-chacha = []
-cuda = []
-erasure = []
-ipv6 = []
-test = []
-unstable = []
-
-[dependencies]
-bincode = "1.0.0"
-bs58 = "0.2.0"
-bv = { version = "0.10.0", features = ["serde"] }
-byteorder = "1.2.1"
-chrono = { version = "0.4.0", features = ["serde"] }
-hashbrown = "0.1.7"
-indexmap = "1.0"
-itertools = "0.8.0"
-libc = "0.2.45"
-log = "0.4.2"
-nix = "0.12.0"
-rand = "0.6.1"
-rand_chacha = "0.1.0"
-rayon = "1.0.0"
-reqwest = "0.9.0"
-ring = "0.13.2"
-rocksdb = "0.10.1"
-serde = "1.0.82"
-serde_derive = "1.0.82"
-serde_json = "1.0.10"
-solana-bpfloader = { path = "programs/native/bpf_loader", version = "0.11.0" }
-solana-drone = { path = "drone", version = "0.11.0" }
-solana-jsonrpc-core = "0.4.0"
-solana-jsonrpc-http-server = "0.4.0"
-solana-jsonrpc-macros = "0.4.0"
-solana-jsonrpc-pubsub = "0.4.0"
-solana-jsonrpc-ws-server = "0.4.0"
-solana-logger = { path = "logger", version = "0.11.0" }
-solana-metrics = { path = "metrics", version = "0.11.0" }
-solana-native-loader = { path = "programs/native/native_loader", version = "0.11.0" }
-solana-netutil = { path = "netutil", version = "0.11.0" }
-solana-sdk = { path = "sdk", version = "0.11.0" }
-solana-system-program = { path = "programs/native/system", version = "0.11.0" }
-tokio = "0.1"
-tokio-codec = "0.1"
-untrusted = "0.6.2"
-
-[dev-dependencies]
-hex-literal = "0.1.1"
-matches = "0.1.6"
-
-[[bench]]
-name = "bank"
-
-[[bench]]
-name = "banking_stage"
-
-[[bench]]
-name = "db_ledger"
-
-[[bench]]
-name = "ledger"
-
-[[bench]]
-name = "signature"
-
-[[bench]]
-name = "sigverify"
-
-[[bench]]
-required-features = ["chacha"]
-name = "chacha"
-
 [workspace]
 members = [
     ".",
@@ -93,25 +5,36 @@ members = [
     "bench-tps",
     "drone",
     "fullnode",
-    "fullnode-config",
     "genesis",
+    "gossip",
+    "install",
     "keygen",
+    "kvstore",
     "ledger-tool",
     "logger",
     "metrics",
-    "programs/bpf/rust/noop",
-    "programs/native/bpf_loader",
-    "programs/native/budget",
-    "programs/native/erc20",
-    "programs/native/lua_loader",
-    "programs/native/native_loader",
-    "programs/native/noop",
-    "programs/native/storage",
-    "programs/native/system",
-    "programs/native/vote",
+    "programs/bpf",
+    "programs/bpf_loader",
+    "programs/budget_api",
+    "programs/budget_program",
+    "programs/config_api",
+    "programs/config_program",
+    "programs/exchange_api",
+    "programs/exchange_program",
+    "programs/token_api",
+    "programs/token_program",
+    "programs/failure_program",
+    "programs/noop_program",
+    "programs/stake_api",
+    "programs/stake_program",
+    "programs/storage_api",
+    "programs/storage_program",
+    "programs/vote_api",
+    "programs/vote_program",
     "replicator",
     "sdk",
     "upload-perf",
     "vote-signer",
     "wallet",
 ]
+exclude = ["programs/bpf/rust/noop"]

README.md

@@ -26,7 +26,9 @@ Furthermore, and much to our surprise, it can be implemented using a mechanism t
 Architecture
 ===
 
-Before you jump into the code, review the online book [Solana: Blockchain Rebuilt for Scale](https://solana-labs.github.io/solana/).
+Before you jump into the code, review the online book [Solana: Blockchain Rebuilt for Scale](https://solana-labs.github.io/book/).
+
+(The _latest_ development version of the online book is also [available here](https://solana-labs.github.io/book-edge/).)
 
 Developing
 ===
@@ -42,7 +44,7 @@ $ source $HOME/.cargo/env
 $ rustup component add rustfmt-preview
 ```
 
-If your rustc version is lower than 1.31.0, please update it:
+If your rustc version is lower than 1.34.0, please update it:
 
 ```bash
 $ rustup update
@@ -67,6 +69,11 @@ Build
 $ cargo build --all
 ```
 
+Then to run a minimal local cluster
+```bash
+$ ./run.sh
+```
+
 Testing
 ---
 
@@ -76,16 +83,10 @@ Run the test suite:
 $ cargo test --all
 ```
 
-To emulate all the tests that will run on a Pull Request, run:
-
-```bash
-$ ./ci/run-local.sh
-```
-
 Local Testnet
 ---
 
-Start your own testnet locally, instructions are in the book [Solana: Blockchain Rebuild for Scale: Getting Started](https://solana-labs.github.io/solana/getting-started.html).
+Start your own testnet locally, instructions are in the book [Solana: Blockchain Rebuild for Scale: Getting Started](https://solana-labs.github.io/book/getting-started.html).
 
 Remote Testnets
 ---
@@ -103,10 +104,7 @@ We maintain several testnets:
 
 They are deployed with the `ci/testnet-manager.sh` script through a list of [scheduled
 buildkite jobs](https://buildkite.com/solana-labs/testnet-management/settings/schedules).
-Each testnet can be manually manipulated from buildkite as well.  The `-perf`
-testnets use a release tarball while the non`-perf` builds use the snap build
-(we've observed that the snap build runs slower than a tarball but this has yet
-to be root caused).
+Each testnet can be manually manipulated from buildkite as well.
 
 ## How do I reset the testnet?
 Manually trigger the [testnet-management](https://buildkite.com/solana-labs/testnet-management) pipeline
@@ -127,10 +125,52 @@ can run your own testnet using the scripts in the `net/` directory.
 Edit `ci/testnet-manager.sh`
 
 
+## Metrics Server Maintenance
+Sometimes the dashboard becomes unresponsive. This happens due to glitch in the metrics server.
+The current solution is to reset the metrics server. Use the following steps.
+
+1. The server is hosted in a GCP VM instance. Check if the VM instance is down by trying to SSH
+ into it from the GCP console. The name of the VM is ```metrics-solana-com```.
+2. If the VM is inaccessible, reset it from the GCP console.
+3. Once VM is up (or, was already up), the metrics services can be restarted from build automation.
+    1. Navigate to https://buildkite.com/solana-labs/metrics-dot-solana-dot-com in your web browser
+    2. Click on ```New Build```
+    3. This will show a pop up dialog. Click on ```options``` drop down.
+    4. Type in ```FORCE_START=true``` in ```Environment Variables``` text box.
+    5. Click ```Create Build```
+    6. This will restart the metrics services, and the dashboards should be accessible afterwards.
+
+## Debugging Testnet
+Testnet may exhibit different symptoms of failures. Primary statistics to check are
+1. Rise in Confirmation Time
+2. Nodes are not voting
+3. Panics, and OOM notifications
+
+Check the following if there are any signs of failure.
+1. Did testnet deployment fail?
+    1. View buildkite logs for the last deployment: https://buildkite.com/solana-labs/testnet-management
+    2. Use the relevant branch
+    3. If the deployment failed, look at the build logs. The build artifacts for each remote node is uploaded.
+       It's a good first step to triage from these logs.
+2. You may have to log into remote node if the deployment succeeded, but something failed during runtime.
+    1. Get the private key for the testnet deployment from ```metrics-solana-com``` GCP instance.
+    2. SSH into ```metrics-solana-com``` using GCP console and do the following.
+    ```bash
+    sudo bash
+    cd ~buildkite-agent/.ssh
+    ls
+    ```
+    3. Copy the relevant private key to your local machine
+    4. Find the public IP address of the AWS instance for the remote node using AWS console
+    5. ```ssh -i <private key file> ubuntu@<ip address of remote node>```
+    6. The logs are in ```~solana\solana``` folder
+
+
 Benchmarking
 ---
 
-First install the nightly build of rustc. `cargo bench` requires unstable features:
+First install the nightly build of rustc. `cargo bench` requires use of the
+unstable features only available in the nightly build.
 
 ```bash
 $ rustup install nightly
@@ -139,7 +179,7 @@ $ rustup install nightly
 Run the benchmarks:
 
 ```bash
-$ cargo +nightly bench --features="unstable"
+$ cargo +nightly bench
 ```
 
 Release Process

RELEASE.md

@@ -43,8 +43,7 @@ the `master` branch as late as possible prior to the milestone release.
 
 ### v*X.Y.Z* release tag
 The release tags are created as desired by the owner of the given stabilization
-branch, and cause that *X.Y.Z* release to be shipped to https://crates.io,
-https://snapcraft.io/, and elsewhere.
+branch, and cause that *X.Y.Z* release to be shipped to https://crates.io
 
 Immediately after a new v*X.Y.Z* branch tag has been created, the `Cargo.toml`
 patch version number (*Z*) of the stabilization branch is incremented by the
@@ -64,27 +63,49 @@ There are three release channels that map to branches as follows:
 
 ### Changing channels
 
-When cutting a new channel branch these pre-steps are required:
-
+#### Create the new branch
 1. Pick your branch point for release on master.
-2. Create the branch.  The name should be "v" + the first 2 "version" fields from Cargo.toml.  For example, a Cargo.toml with version = "0.9.0" implies the next branch name is "v0.9".
-4. Push the new branch to the solana repository
-3. Update Cargo.toml on master to the next semantic version (e.g. 0.9.0 -> 0.10.0) by running `./scripts/increment-cargo-version.sh`.
-5. Land your Cargo.toml change as a master PR.
+1. Create the branch.  The name should be "v" + the first 2 "version" fields
+   from Cargo.toml.  For example, a Cargo.toml with version = "0.9.0" implies
+   the next branch name is "v0.9".
+    1.  Note the Cargo.toml in the repo root directory does not contain a version.  Look at any other Cargo.toml file.
+1. Create a new branch and push this branch to the solana repository.
+    1. `git checkout -b <branchname>`
+    1. `git push -u origin <branchname>`
 
-At this point, ci/channel-info.sh should show your freshly cut release branch as "BETA_CHANNEL" and the previous release branch as "STABLE_CHANNEL".
+#### Update master with the next version
+
+1. After the new branch has been created and pushed, update Cargo.toml on **master** to the next semantic version (e.g. 0.9.0 -> 0.10.0)
+   by running `./scripts/increment-cargo-version.sh`, then rebuild with
+   `cargo build` to cause a refresh of `Cargo.lock`.
+1. Push your Cargo.toml change and the autogenerated Cargo.lock changes to the
+   master branch
+
+At this point, `ci/channel-info.sh` should show your freshly cut release branch as
+"BETA_CHANNEL" and the previous release branch as "STABLE_CHANNEL".
 
 ### Updating channels (i.e. "making a release")
 
 We use [github's Releases UI](https://github.com/solana-labs/solana/releases) for tagging a release.
 
 1. Go [there ;)](https://github.com/solana-labs/solana/releases).
-2. Click "Draft new release".  The release tag must exactly match the `version` field in `/Cargo.toml` prefixed by `v` (ie, `<branchname>.X`).
-3. If the first major release on the branch (e.g. v0.8.0), paste in [this template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md) and fill it in.
-4. Test the release by generating a tag using semver's rules.  First try at a release should be `<branchname>.X-rc.0`.
-5. Verify release automation:
+1. Click "Draft new release".  The release tag must exactly match the `version`
+   field in `/Cargo.toml` prefixed by `v` (ie, `<branchname>.X`).
+   1.  If the Cargo.toml verion field is **0.12.3**, then the release tag must be **v0.12.3**
+1. If this is the first release on the branch (e.g. v0.13.**0**), paste in [this
+   template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md)
+   and fill it in.
+1. Test the release by generating a tag using semver's rules.  First try at a
+   release should be `<branchname>.X-rc.0`.
+1. Verify release automation:
    1. [Crates.io](https://crates.io/crates/solana) should have an updated Solana version.
-   2. ...
-6. After testnet deployment, verify that testnets are running correct software.  http://metrics.solana.com should show testnet running on a hash from your newly created branch.
-7. Once the release has been made, update Cargo.toml on release to the next semantic version (e.g. 0.9.0 -> 0.9.1) by running `./scripts/increment-cargo-version.sh patch`.
-
+   1. ...
+1. After testnet deployment, verify that testnets are running correct software.
+   http://metrics.solana.com should show testnet running on a hash from your
+   newly created branch.
+1. Once the release has been made, update Cargo.toml on the release branch to the next
+   semantic version (e.g. 0.9.0 -> 0.9.1) by running
+   `./scripts/increment-cargo-version.sh patch`, then rebuild with `cargo
+   build` to cause a refresh of `Cargo.lock`.
+1. Push your Cargo.toml change and the autogenerated Cargo.lock changes to the
+   release branch.

bench-streamer/Cargo.toml

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

bench-streamer/src/main.rs

@@ -1,4 +1,4 @@
-use clap::{App, Arg};
+use clap::{crate_description, crate_name, crate_version, App, Arg};
 use solana::packet::{Packet, SharedPackets, BLOB_SIZE, PACKET_DATA_SIZE};
 use solana::result::Result;
 use solana::streamer::{receiver, PacketReceiver};
@@ -51,7 +51,9 @@ fn sink(exit: Arc<AtomicBool>, rvs: Arc<AtomicUsize>, r: PacketReceiver) -> Join
 fn main() -> Result<()> {
     let mut num_sockets = 1usize;
 
-    let matches = App::new("solana-bench-streamer")
+    let matches = App::new(crate_name!())
+        .about(crate_description!())
+        .version(crate_version!())
         .arg(
             Arg::with_name("num-recv-sockets")
                 .long("num-recv-sockets")
@@ -81,12 +83,7 @@ fn main() -> Result<()> {
 
         let (s_reader, r_reader) = channel();
         read_channels.push(r_reader);
-        read_threads.push(receiver(
-            Arc::new(read),
-            exit.clone(),
-            s_reader,
-            "bench-streamer",
-        ));
+        read_threads.push(receiver(Arc::new(read), &exit, s_reader, "bench-streamer"));
     }
 
     let t_producer1 = producer(&addr, exit.clone());

bench-tps/Cargo.toml

@@ -2,20 +2,23 @@
 authors = ["Solana Maintainers <maintainers@solana.com>"]
 edition = "2018"
 name = "solana-bench-tps"
-version = "0.11.0"
+version = "0.13.3"
 repository = "https://github.com/solana-labs/solana"
 license = "Apache-2.0"
 homepage = "https://solana.com/"
 
 [dependencies]
-clap = "2.32.0"
+clap = "2.33.0"
 rayon = "1.0.3"
-serde_json = "1.0.10"
-solana = { path = "..", version = "0.11.0" }
-solana-drone = { path = "../drone", version = "0.11.0" }
-solana-logger = { path = "../logger", version = "0.11.0" }
-solana-metrics = { path = "../metrics", version = "0.11.0" }
-solana-sdk = { path = "../sdk", version = "0.11.0" }
+serde_json = "1.0.39"
+solana = { path = "../core", version = "0.13.3"    }
+solana-client = { path = "../client", version = "0.13.3"    }
+solana-drone = { path = "../drone", version = "0.13.3"    }
+solana-logger = { path = "../logger", version = "0.13.3"    }
+solana-metrics = { path = "../metrics", version = "0.13.3"    }
+solana-netutil = { path = "../netutil", version = "0.13.3"    }
+solana-sdk = { path = "../sdk", version = "0.13.3"    }
 
 [features]
-cuda = []
+cuda = ["solana/cuda"]
+erasure = []

bench-tps/src/bench.rs

@@ -1,14 +1,21 @@
 use solana_metrics;
 
+use crate::cli::Config;
 use rayon::prelude::*;
-use solana::client::mk_client;
-use solana::cluster_info::NodeInfo;
-use solana::thin_client::ThinClient;
+use solana::cluster_info::FULLNODE_PORT_RANGE;
+use solana::contact_info::ContactInfo;
+use solana::gen_keys::GenKeys;
+use solana::gossip_service::discover_nodes;
+use solana_client::thin_client::create_client;
+use solana_client::thin_client::ThinClient;
 use solana_drone::drone::request_airdrop_transaction;
 use solana_metrics::influxdb;
+use solana_sdk::client::{AsyncClient, SyncClient};
 use solana_sdk::hash::Hash;
+use solana_sdk::pubkey::Pubkey;
 use solana_sdk::signature::{Keypair, KeypairUtil};
-use solana_sdk::system_transaction::SystemTransaction;
+use solana_sdk::system_instruction;
+use solana_sdk::system_transaction;
 use solana_sdk::timing::timestamp;
 use solana_sdk::timing::{duration_as_ms, duration_as_s};
 use solana_sdk::transaction::Transaction;
@@ -19,6 +26,7 @@ use std::process::exit;
 use std::sync::atomic::{AtomicBool, AtomicIsize, AtomicUsize, Ordering};
 use std::sync::{Arc, RwLock};
 use std::thread::sleep;
+use std::thread::Builder;
 use std::time::Duration;
 use std::time::Instant;
 
@@ -33,33 +41,227 @@ pub const MAX_SPENDS_PER_TX: usize = 4;
 
 pub type SharedTransactions = Arc<RwLock<VecDeque<Vec<(Transaction, u64)>>>>;
 
-pub fn metrics_submit_token_balance(token_balance: u64) {
-    println!("Token balance: {}", token_balance);
+pub fn do_bench_tps(config: Config) {
+    let Config {
+        network_addr: network,
+        drone_addr,
+        id,
+        threads,
+        thread_batch_sleep_ms,
+        num_nodes,
+        duration,
+        tx_count,
+        sustained,
+    } = config;
+
+    let nodes = discover_nodes(&network, num_nodes).unwrap_or_else(|err| {
+        eprintln!("Failed to discover {} nodes: {:?}", num_nodes, err);
+        exit(1);
+    });
+    if nodes.len() < num_nodes {
+        eprintln!(
+            "Error: Insufficient nodes discovered.  Expecting {} or more",
+            num_nodes
+        );
+        exit(1);
+    }
+    let cluster_entrypoint = nodes[0].clone(); // Pick the first node, why not?
+
+    let client = create_client(cluster_entrypoint.client_facing_addr(), FULLNODE_PORT_RANGE);
+    let mut barrier_client =
+        create_client(cluster_entrypoint.client_facing_addr(), FULLNODE_PORT_RANGE);
+
+    let mut seed = [0u8; 32];
+    seed.copy_from_slice(&id.public_key_bytes()[..32]);
+    let mut rnd = GenKeys::new(seed);
+
+    println!("Creating {} keypairs...", tx_count * 2);
+    let mut total_keys = 0;
+    let mut target = tx_count * 2;
+    while target > 0 {
+        total_keys += target;
+        target /= MAX_SPENDS_PER_TX;
+    }
+    let gen_keypairs = rnd.gen_n_keypairs(total_keys as u64);
+    let barrier_source_keypair = Keypair::new();
+    let barrier_dest_id = Pubkey::new_rand();
+
+    println!("Get lamports...");
+    let num_lamports_per_account = 20;
+
+    // Sample the first keypair, see if it has lamports, if so then resume
+    // to avoid lamport loss
+    let keypair0_balance = client
+        .poll_get_balance(&gen_keypairs.last().unwrap().pubkey())
+        .unwrap_or(0);
+
+    if num_lamports_per_account > keypair0_balance {
+        let extra = num_lamports_per_account - keypair0_balance;
+        let total = extra * (gen_keypairs.len() as u64);
+        airdrop_lamports(&client, &drone_addr, &id, total);
+        println!("adding more lamports {}", extra);
+        fund_keys(&client, &id, &gen_keypairs, extra);
+    }
+    let start = gen_keypairs.len() - (tx_count * 2) as usize;
+    let keypairs = &gen_keypairs[start..];
+    airdrop_lamports(&barrier_client, &drone_addr, &barrier_source_keypair, 1);
+
+    println!("Get last ID...");
+    let mut blockhash = client.get_recent_blockhash().unwrap();
+    println!("Got last ID {:?}", blockhash);
+
+    let first_tx_count = client.get_transaction_count().expect("transaction count");
+    println!("Initial transaction count {}", first_tx_count);
+
+    let exit_signal = Arc::new(AtomicBool::new(false));
+
+    // Setup a thread per validator to sample every period
+    // collect the max transaction rate and total tx count seen
+    let maxes = Arc::new(RwLock::new(Vec::new()));
+    let sample_period = 1; // in seconds
+    println!("Sampling TPS every {} second...", sample_period);
+    let v_threads: Vec<_> = nodes
+        .into_iter()
+        .map(|v| {
+            let exit_signal = exit_signal.clone();
+            let maxes = maxes.clone();
+            Builder::new()
+                .name("solana-client-sample".to_string())
+                .spawn(move || {
+                    sample_tx_count(&exit_signal, &maxes, first_tx_count, &v, sample_period);
+                })
+                .unwrap()
+        })
+        .collect();
+
+    let shared_txs: SharedTransactions = Arc::new(RwLock::new(VecDeque::new()));
+
+    let shared_tx_active_thread_count = Arc::new(AtomicIsize::new(0));
+    let total_tx_sent_count = Arc::new(AtomicUsize::new(0));
+
+    let s_threads: Vec<_> = (0..threads)
+        .map(|_| {
+            let exit_signal = exit_signal.clone();
+            let shared_txs = shared_txs.clone();
+            let cluster_entrypoint = cluster_entrypoint.clone();
+            let shared_tx_active_thread_count = shared_tx_active_thread_count.clone();
+            let total_tx_sent_count = total_tx_sent_count.clone();
+            Builder::new()
+                .name("solana-client-sender".to_string())
+                .spawn(move || {
+                    do_tx_transfers(
+                        &exit_signal,
+                        &shared_txs,
+                        &cluster_entrypoint,
+                        &shared_tx_active_thread_count,
+                        &total_tx_sent_count,
+                        thread_batch_sleep_ms,
+                    );
+                })
+                .unwrap()
+        })
+        .collect();
+
+    // generate and send transactions for the specified duration
+    let start = Instant::now();
+    let mut reclaim_lamports_back_to_source_account = false;
+    let mut i = keypair0_balance;
+    while start.elapsed() < duration {
+        let balance = client.poll_get_balance(&id.pubkey()).unwrap_or(0);
+        metrics_submit_lamport_balance(balance);
+
+        // ping-pong between source and destination accounts for each loop iteration
+        // this seems to be faster than trying to determine the balance of individual
+        // accounts
+        let len = tx_count as usize;
+        generate_txs(
+            &shared_txs,
+            &keypairs[..len],
+            &keypairs[len..],
+            threads,
+            reclaim_lamports_back_to_source_account,
+            &cluster_entrypoint,
+        );
+        // In sustained mode overlap the transfers with generation
+        // this has higher average performance but lower peak performance
+        // in tested environments.
+        if !sustained {
+            while shared_tx_active_thread_count.load(Ordering::Relaxed) > 0 {
+                sleep(Duration::from_millis(100));
+            }
+        }
+        // It's not feasible (would take too much time) to confirm each of the `tx_count / 2`
+        // transactions sent by `generate_txs()` so instead send and confirm a single transaction
+        // to validate the network is still functional.
+        send_barrier_transaction(
+            &mut barrier_client,
+            &mut blockhash,
+            &barrier_source_keypair,
+            &barrier_dest_id,
+        );
+
+        i += 1;
+        if should_switch_directions(num_lamports_per_account, i) {
+            reclaim_lamports_back_to_source_account = !reclaim_lamports_back_to_source_account;
+        }
+    }
+
+    // Stop the sampling threads so it will collect the stats
+    exit_signal.store(true, Ordering::Relaxed);
+
+    println!("Waiting for validator threads...");
+    for t in v_threads {
+        if let Err(err) = t.join() {
+            println!("  join() failed with: {:?}", err);
+        }
+    }
+
+    // join the tx send threads
+    println!("Waiting for transmit threads...");
+    for t in s_threads {
+        if let Err(err) = t.join() {
+            println!("  join() failed with: {:?}", err);
+        }
+    }
+
+    let balance = client.poll_get_balance(&id.pubkey()).unwrap_or(0);
+    metrics_submit_lamport_balance(balance);
+
+    compute_and_report_stats(
+        &maxes,
+        sample_period,
+        &start.elapsed(),
+        total_tx_sent_count.load(Ordering::Relaxed),
+    );
+}
+
+fn metrics_submit_lamport_balance(lamport_balance: u64) {
+    println!("Token balance: {}", lamport_balance);
     solana_metrics::submit(
         influxdb::Point::new("bench-tps")
-            .add_tag("op", influxdb::Value::String("token_balance".to_string()))
-            .add_field("balance", influxdb::Value::Integer(token_balance as i64))
+            .add_tag("op", influxdb::Value::String("lamport_balance".to_string()))
+            .add_field("balance", influxdb::Value::Integer(lamport_balance as i64))
             .to_owned(),
     );
 }
 
-pub fn sample_tx_count(
+fn sample_tx_count(
     exit_signal: &Arc<AtomicBool>,
     maxes: &Arc<RwLock<Vec<(SocketAddr, NodeStats)>>>,
     first_tx_count: u64,
-    v: &NodeInfo,
+    v: &ContactInfo,
     sample_period: u64,
 ) {
-    let mut client = mk_client(&v);
+    let client = create_client(v.client_facing_addr(), FULLNODE_PORT_RANGE);
     let mut now = Instant::now();
-    let mut initial_tx_count = client.transaction_count();
+    let mut initial_tx_count = client.get_transaction_count().expect("transaction count");
     let mut max_tps = 0.0;
     let mut total;
 
     let log_prefix = format!("{:21}:", v.tpu.to_string());
 
     loop {
-        let tx_count = client.transaction_count();
+        let tx_count = client.get_transaction_count().expect("transaction count");
         assert!(
             tx_count >= initial_tx_count,
             "expected tx_count({}) >= initial_tx_count({})",
@@ -99,8 +301,13 @@ pub fn sample_tx_count(
     }
 }
 
-/// Send loopback payment of 0 tokens and confirm the network processed it
-pub fn send_barrier_transaction(barrier_client: &mut ThinClient, last_id: &mut Hash, id: &Keypair) {
+/// Send loopback payment of 0 lamports and confirm the network processed it
+fn send_barrier_transaction(
+    barrier_client: &mut ThinClient,
+    blockhash: &mut Hash,
+    source_keypair: &Keypair,
+    dest_id: &Pubkey,
+) {
     let transfer_start = Instant::now();
 
     let mut poll_count = 0;
@@ -112,9 +319,12 @@ pub fn send_barrier_transaction(barrier_client: &mut ThinClient, last_id: &mut H
             );
         }
 
-        *last_id = barrier_client.get_last_id();
+        *blockhash = barrier_client.get_recent_blockhash().unwrap();
+
+        let transaction =
+            system_transaction::create_user_account(&source_keypair, dest_id, 0, *blockhash, 0);
         let signature = barrier_client
-            .transfer(0, &id, id.pubkey(), last_id)
+            .async_send_transaction(transaction)
             .expect("Unable to send barrier transaction");
 
         let confirmatiom = barrier_client.poll_for_signature(&signature);
@@ -136,7 +346,7 @@ pub fn send_barrier_transaction(barrier_client: &mut ThinClient, last_id: &mut H
             // Sanity check that the client balance is still 1
             let balance = barrier_client
                 .poll_balance_with_timeout(
-                    &id.pubkey(),
+                    &source_keypair.pubkey(),
                     &Duration::from_millis(100),
                     &Duration::from_secs(10),
                 )
@@ -154,29 +364,29 @@ pub fn send_barrier_transaction(barrier_client: &mut ThinClient, last_id: &mut H
             exit(1);
         }
 
-        let new_last_id = barrier_client.get_last_id();
-        if new_last_id == *last_id {
+        let new_blockhash = barrier_client.get_recent_blockhash().unwrap();
+        if new_blockhash == *blockhash {
             if poll_count > 0 && poll_count % 8 == 0 {
-                println!("last_id is not advancing, still at {:?}", *last_id);
+                println!("blockhash is not advancing, still at {:?}", *blockhash);
             }
         } else {
-            *last_id = new_last_id;
+            *blockhash = new_blockhash;
         }
 
         poll_count += 1;
     }
 }
 
-pub fn generate_txs(
+fn generate_txs(
     shared_txs: &SharedTransactions,
     source: &[Keypair],
     dest: &[Keypair],
     threads: usize,
     reclaim: bool,
-    leader: &NodeInfo,
+    contact_info: &ContactInfo,
 ) {
-    let mut client = mk_client(leader);
-    let last_id = client.get_last_id();
+    let client = create_client(contact_info.client_facing_addr(), FULLNODE_PORT_RANGE);
+    let blockhash = client.get_recent_blockhash().unwrap();
     let tx_count = source.len();
     println!("Signing transactions... {} (reclaim={})", tx_count, reclaim);
     let signing_start = Instant::now();
@@ -190,7 +400,7 @@ pub fn generate_txs(
         .par_iter()
         .map(|(id, keypair)| {
             (
-                Transaction::system_new(id, keypair.pubkey(), 1, last_id),
+                system_transaction::create_user_account(id, &keypair.pubkey(), 1, blockhash, 0),
                 timestamp(),
             )
         })
@@ -205,7 +415,7 @@ pub fn generate_txs(
         bsps * 1_000_000_f64,
         nsps / 1_000_f64,
         duration_as_ms(&duration),
-        last_id,
+        blockhash,
     );
     solana_metrics::submit(
         influxdb::Point::new("bench-tps")
@@ -227,15 +437,19 @@ pub fn generate_txs(
     }
 }
 
-pub fn do_tx_transfers(
+fn do_tx_transfers(
     exit_signal: &Arc<AtomicBool>,
     shared_txs: &SharedTransactions,
-    leader: &NodeInfo,
+    contact_info: &ContactInfo,
     shared_tx_thread_count: &Arc<AtomicIsize>,
     total_tx_sent_count: &Arc<AtomicUsize>,
+    thread_batch_sleep_ms: usize,
 ) {
-    let client = mk_client(&leader);
+    let client = create_client(contact_info.client_facing_addr(), FULLNODE_PORT_RANGE);
     loop {
+        if thread_batch_sleep_ms > 0 {
+            sleep(Duration::from_millis(thread_batch_sleep_ms as u64));
+        }
         let txs;
         {
             let mut shared_txs_wl = shared_txs.write().unwrap();
@@ -246,7 +460,7 @@ pub fn do_tx_transfers(
             println!(
                 "Transferring 1 unit {} times... to {}",
                 txs0.len(),
-                leader.tpu
+                contact_info.tpu
             );
             let tx_len = txs0.len();
             let transfer_start = Instant::now();
@@ -255,7 +469,7 @@ pub fn do_tx_transfers(
                 if now > tx.1 && now - tx.1 > 1000 * 30 {
                     continue;
                 }
-                client.transfer_signed(&tx.0).unwrap();
+                client.async_send_transaction(tx.0).unwrap();
             }
             shared_tx_thread_count.fetch_add(-1, Ordering::Relaxed);
             total_tx_sent_count.fetch_add(tx_len, Ordering::Relaxed);
@@ -281,8 +495,8 @@ pub fn do_tx_transfers(
     }
 }
 
-pub fn verify_funding_transfer(client: &mut ThinClient, tx: &Transaction, amount: u64) -> bool {
-    for a in &tx.account_keys[1..] {
+fn verify_funding_transfer(client: &ThinClient, tx: &Transaction, amount: u64) -> bool {
+    for a in &tx.message().account_keys[1..] {
         if client.get_balance(a).unwrap_or(0) >= amount {
             return true;
         }
@@ -294,8 +508,8 @@ pub fn verify_funding_transfer(client: &mut ThinClient, tx: &Transaction, amount
 /// 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(client: &mut ThinClient, source: &Keypair, dests: &[Keypair], tokens: u64) {
-    let total = tokens * dests.len() as u64;
+fn fund_keys(client: &ThinClient, source: &Keypair, dests: &[Keypair], lamports: u64) {
+    let total = lamports * dests.len() as u64;
     let mut funded: Vec<(&Keypair, u64)> = vec![(source, total)];
     let mut notfunded: Vec<&Keypair> = dests.iter().collect();
 
@@ -324,7 +538,7 @@ pub fn fund_keys(client: &mut ThinClient, source: &Keypair, dests: &[Keypair], t
             }
         }
 
-        // try to transfer a "few" at a time with recent last_id
+        // 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;
 
@@ -338,7 +552,10 @@ pub fn fund_keys(client: &mut ThinClient, source: &Keypair, dests: &[Keypair], t
                 .map(|(k, m)| {
                     (
                         k.clone(),
-                        Transaction::system_move_many(k, &m, Default::default(), 0),
+                        Transaction::new_unsigned_instructions(system_instruction::transfer_many(
+                            &k.pubkey(),
+                            &m,
+                        )),
                     )
                 })
                 .collect();
@@ -348,7 +565,7 @@ pub fn fund_keys(client: &mut ThinClient, source: &Keypair, dests: &[Keypair], t
             while !to_fund_txs.is_empty() {
                 let receivers = to_fund_txs
                     .iter()
-                    .fold(0, |len, (_, tx)| len + tx.instructions.len());
+                    .fold(0, |len, (_, tx)| len + tx.message().instructions.len());
 
                 println!(
                     "{} {} to {} in {} txs",
@@ -362,21 +579,27 @@ pub fn fund_keys(client: &mut ThinClient, source: &Keypair, dests: &[Keypair], t
                     to_fund_txs.len(),
                 );
 
-                let last_id = client.get_last_id();
+                let blockhash = client.get_recent_blockhash().unwrap();
 
-                // re-sign retained to_fund_txes with updated last_id
+                // re-sign retained to_fund_txes with updated blockhash
                 to_fund_txs.par_iter_mut().for_each(|(k, tx)| {
-                    tx.sign(&[k], last_id);
+                    tx.sign(&[*k], blockhash);
                 });
 
                 to_fund_txs.iter().for_each(|(_, tx)| {
-                    client.transfer_signed(&tx).expect("transfer");
+                    client.async_send_transaction(tx.clone()).expect("transfer");
                 });
 
                 // retry anything that seems to have dropped through cracks
                 //  again since these txs are all or nothing, they're fine to
                 //  retry
-                to_fund_txs.retain(|(_, tx)| !verify_funding_transfer(client, &tx, amount));
+                for _ in 0..10 {
+                    to_fund_txs.retain(|(_, tx)| !verify_funding_transfer(client, &tx, amount));
+                    if to_fund_txs.is_empty() {
+                        break;
+                    }
+                    sleep(Duration::from_millis(100));
+                }
 
                 tries += 1;
             }
@@ -387,29 +610,24 @@ pub fn fund_keys(client: &mut ThinClient, source: &Keypair, dests: &[Keypair], t
     }
 }
 
-pub fn airdrop_tokens(
-    client: &mut ThinClient,
-    drone_addr: &SocketAddr,
-    id: &Keypair,
-    tx_count: u64,
-) {
+fn airdrop_lamports(client: &ThinClient, drone_addr: &SocketAddr, id: &Keypair, tx_count: u64) {
     let starting_balance = client.poll_get_balance(&id.pubkey()).unwrap_or(0);
-    metrics_submit_token_balance(starting_balance);
+    metrics_submit_lamport_balance(starting_balance);
     println!("starting balance {}", starting_balance);
 
     if starting_balance < tx_count {
         let airdrop_amount = tx_count - starting_balance;
         println!(
-            "Airdropping {:?} tokens from {} for {}",
+            "Airdropping {:?} lamports from {} for {}",
             airdrop_amount,
             drone_addr,
             id.pubkey(),
         );
 
-        let last_id = client.get_last_id();
-        match request_airdrop_transaction(&drone_addr, &id.pubkey(), airdrop_amount, last_id) {
+        let blockhash = client.get_recent_blockhash().unwrap();
+        match request_airdrop_transaction(&drone_addr, &id.pubkey(), airdrop_amount, blockhash) {
             Ok(transaction) => {
-                let signature = client.transfer_signed(&transaction).unwrap();
+                let signature = client.async_send_transaction(transaction).unwrap();
                 client.poll_for_signature(&signature).unwrap();
             }
             Err(err) => {
@@ -426,7 +644,7 @@ pub fn airdrop_tokens(
         });
         println!("current balance {}...", current_balance);
 
-        metrics_submit_token_balance(current_balance);
+        metrics_submit_lamport_balance(current_balance);
         if current_balance - starting_balance != airdrop_amount {
             println!(
                 "Airdrop failed! {} {} {}",
@@ -439,7 +657,7 @@ pub fn airdrop_tokens(
     }
 }
 
-pub fn compute_and_report_stats(
+fn compute_and_report_stats(
     maxes: &Arc<RwLock<Vec<(SocketAddr, NodeStats)>>>,
     sample_period: u64,
     tx_send_elapsed: &Duration,
@@ -503,16 +721,21 @@ pub fn compute_and_report_stats(
     );
 }
 
-// First transfer 3/4 of the tokens to the dest accounts
-// then ping-pong 1/4 of the tokens back to the other account
-// this leaves 1/4 token buffer in each account
-pub fn should_switch_directions(num_tokens_per_account: u64, i: u64) -> bool {
-    i % (num_tokens_per_account / 4) == 0 && (i >= (3 * num_tokens_per_account) / 4)
+// First transfer 3/4 of the lamports to the dest accounts
+// then ping-pong 1/4 of the lamports back to the other account
+// this leaves 1/4 lamport buffer in each account
+fn should_switch_directions(num_lamports_per_account: u64, i: u64) -> bool {
+    i % (num_lamports_per_account / 4) == 0 && (i >= (3 * num_lamports_per_account) / 4)
 }
 
 #[cfg(test)]
 mod tests {
     use super::*;
+    use solana::fullnode::FullnodeConfig;
+    use solana::local_cluster::{ClusterConfig, LocalCluster};
+    use solana_drone::drone::run_local_drone;
+    use std::sync::mpsc::channel;
+
     #[test]
     fn test_switch_directions() {
         assert_eq!(should_switch_directions(20, 0), false);
@@ -527,4 +750,33 @@ mod tests {
         assert_eq!(should_switch_directions(20, 100), true);
         assert_eq!(should_switch_directions(20, 101), false);
     }
+
+    #[test]
+    #[ignore]
+    fn test_bench_tps() {
+        let fullnode_config = FullnodeConfig::default();
+        const NUM_NODES: usize = 1;
+        let cluster = LocalCluster::new(&ClusterConfig {
+            node_stakes: vec![999_990; NUM_NODES],
+            cluster_lamports: 2_000_000,
+            fullnode_config,
+            ..ClusterConfig::default()
+        });
+
+        let drone_keypair = Keypair::new();
+        cluster.transfer(&cluster.funding_keypair, &drone_keypair.pubkey(), 1_000_000);
+
+        let (addr_sender, addr_receiver) = channel();
+        run_local_drone(drone_keypair, addr_sender, None);
+        let drone_addr = addr_receiver.recv_timeout(Duration::from_secs(2)).unwrap();
+
+        let mut cfg = Config::default();
+        cfg.network_addr = cluster.entry_point_info.gossip;
+        cfg.drone_addr = drone_addr;
+        cfg.tx_count = 100;
+        cfg.duration = Duration::from_secs(5);
+        cfg.num_nodes = NUM_NODES;
+
+        do_bench_tps(cfg);
+    }
 }

bench-tps/src/cli.rs

@@ -2,7 +2,7 @@ use std::net::SocketAddr;
 use std::process::exit;
 use std::time::Duration;
 
-use clap::{crate_version, App, Arg, ArgMatches};
+use clap::{crate_description, crate_name, crate_version, App, Arg, ArgMatches};
 use solana_drone::drone::DRONE_PORT;
 use solana_sdk::signature::{read_keypair, Keypair, KeypairUtil};
 
@@ -15,9 +15,8 @@ pub struct Config {
     pub num_nodes: usize,
     pub duration: Duration,
     pub tx_count: usize,
+    pub thread_batch_sleep_ms: usize,
     pub sustained: bool,
-    pub reject_extra_nodes: bool,
-    pub converge_only: bool,
 }
 
 impl Default for Config {
@@ -30,16 +29,15 @@ impl Default for Config {
             num_nodes: 1,
             duration: Duration::new(std::u64::MAX, 0),
             tx_count: 500_000,
+            thread_batch_sleep_ms: 0,
             sustained: false,
-            reject_extra_nodes: false,
-            converge_only: false,
         }
     }
 }
 
 /// Defines and builds the CLI args for a run of the benchmark
 pub fn build_args<'a, 'b>() -> App<'a, 'b> {
-    App::new("solana-bench-tps")
+    App::new(crate_name!()).about(crate_description!())
         .version(crate_version!())
         .arg(
             Arg::with_name("network")
@@ -73,11 +71,6 @@ pub fn build_args<'a, 'b>() -> App<'a, 'b> {
                 .takes_value(true)
                 .help("Wait for NUM nodes to converge"),
         )
-        .arg(
-            Arg::with_name("reject-extra-nodes")
-                .long("reject-extra-nodes")
-                .help("Require exactly `num-nodes` on convergence. Appropriate only for internal networks"),
-        )
         .arg(
             Arg::with_name("threads")
                 .short("t")
@@ -93,11 +86,6 @@ pub fn build_args<'a, 'b>() -> App<'a, 'b> {
                 .takes_value(true)
                 .help("Seconds to run benchmark, then exit; default is forever"),
         )
-        .arg(
-            Arg::with_name("converge-only")
-                .long("converge-only")
-                .help("Exit immediately after converging"),
-        )
         .arg(
             Arg::with_name("sustained")
                 .long("sustained")
@@ -110,6 +98,14 @@ pub fn build_args<'a, 'b>() -> App<'a, 'b> {
                 .takes_value(true)
                 .help("Number of transactions to send per batch")
         )
+        .arg(
+            Arg::with_name("thread-batch-sleep-ms")
+                .short("z")
+                .long("thread-batch-sleep-ms")
+                .value_name("NUM")
+                .takes_value(true)
+                .help("Per-thread-per-iteration sleep in ms"),
+        )
 }
 
 /// Parses a clap `ArgMatches` structure into a `Config`
@@ -121,14 +117,14 @@ pub fn extract_args<'a>(matches: &ArgMatches<'a>) -> Config {
     let mut args = Config::default();
 
     if let Some(addr) = matches.value_of("network") {
-        args.network_addr = addr.parse().unwrap_or_else(|e| {
-            eprintln!("failed to parse network: {}", e);
+        args.network_addr = solana_netutil::parse_host_port(addr).unwrap_or_else(|e| {
+            eprintln!("failed to parse network address: {}", e);
             exit(1)
         });
     }
 
     if let Some(addr) = matches.value_of("drone") {
-        args.drone_addr = addr.parse().unwrap_or_else(|e| {
+        args.drone_addr = solana_netutil::parse_host_port(addr).unwrap_or_else(|e| {
             eprintln!("failed to parse drone address: {}", e);
             exit(1)
         });
@@ -158,9 +154,14 @@ pub fn extract_args<'a>(matches: &ArgMatches<'a>) -> Config {
         args.tx_count = s.to_string().parse().expect("can't parse tx_account");
     }
 
+    if let Some(t) = matches.value_of("thread-batch-sleep-ms") {
+        args.thread_batch_sleep_ms = t
+            .to_string()
+            .parse()
+            .expect("can't parse thread-batch-sleep-ms");
+    }
+
     args.sustained = matches.is_present("sustained");
-    args.converge_only = matches.is_present("converge-only");
-    args.reject_extra_nodes = matches.is_present("reject-extra-nodes");
 
     args
 }

bench-tps/src/main.rs

@@ -1,73 +1,7 @@
 mod bench;
 mod cli;
 
-use solana::client::mk_client;
-use solana::cluster_info::{ClusterInfo, NodeInfo};
-use solana::gossip_service::GossipService;
-
-use solana::service::Service;
-use solana::signature::GenKeys;
-use solana::thin_client::poll_gossip_for_leader;
-use solana_metrics;
-use solana_sdk::signature::KeypairUtil;
-
-use std::collections::VecDeque;
-use std::process::exit;
-use std::sync::atomic::{AtomicBool, AtomicIsize, AtomicUsize, Ordering};
-use std::sync::{Arc, RwLock};
-use std::thread::sleep;
-use std::thread::Builder;
-use std::time::Duration;
-use std::time::Instant;
-
-use crate::bench::*;
-
-/// Creates a cluster and waits for the network to converge, returning the peers, leader, and gossip service
-/// # Arguments
-/// `leader` - the input leader node
-/// `exit_signal` - atomic bool used to signal early exit to cluster
-/// `num_nodes` - the number of nodes
-/// # Panics
-/// Panics if the spy node `RwLock` somehow ends up unreadable
-fn converge(
-    leader: &NodeInfo,
-    exit_signal: &Arc<AtomicBool>,
-    num_nodes: usize,
-) -> (Vec<NodeInfo>, Option<NodeInfo>, GossipService) {
-    //lets spy on the network
-    let (node, gossip_socket) = ClusterInfo::spy_node();
-    let mut spy_cluster_info = ClusterInfo::new(node);
-    spy_cluster_info.insert_info(leader.clone());
-    spy_cluster_info.set_leader(leader.id);
-    let spy_ref = Arc::new(RwLock::new(spy_cluster_info));
-    let gossip_service = GossipService::new(&spy_ref, None, gossip_socket, exit_signal.clone());
-    let mut v: Vec<NodeInfo> = vec![];
-    // wait for the network to converge, 30 seconds should be plenty
-    for _ in 0..30 {
-        {
-            let spy_ref = spy_ref.read().unwrap();
-
-            println!("{}", spy_ref.node_info_trace());
-
-            if spy_ref.leader_data().is_some() {
-                v = spy_ref.rpc_peers();
-                if v.len() >= num_nodes {
-                    println!("CONVERGED!");
-                    break;
-                } else {
-                    println!(
-                        "{} node(s) discovered (looking for {} or more)",
-                        v.len(),
-                        num_nodes
-                    );
-                }
-            }
-        }
-        sleep(Duration::new(1, 0));
-    }
-    let leader = spy_ref.read().unwrap().leader_data().cloned();
-    (v, leader, gossip_service)
-}
+use crate::bench::do_bench_tps;
 
 fn main() {
     solana_logger::setup();
@@ -77,228 +11,5 @@ fn main() {
 
     let cfg = cli::extract_args(&matches);
 
-    let cli::Config {
-        network_addr: network,
-        drone_addr,
-        id,
-        threads,
-        num_nodes,
-        duration,
-        tx_count,
-        sustained,
-        reject_extra_nodes,
-        converge_only,
-    } = cfg;
-
-    println!("Looking for leader at {:?}", network);
-    let leader = poll_gossip_for_leader(network, None).expect("unable to find leader on network");
-
-    let exit_signal = Arc::new(AtomicBool::new(false));
-    let (nodes, leader, gossip_service) = converge(&leader, &exit_signal, num_nodes);
-
-    if nodes.len() < num_nodes {
-        println!(
-            "Error: Insufficient nodes discovered.  Expecting {} or more",
-            num_nodes
-        );
-        exit(1);
-    }
-    if reject_extra_nodes && nodes.len() > num_nodes {
-        println!(
-            "Error: Extra nodes discovered.  Expecting exactly {}",
-            num_nodes
-        );
-        exit(1);
-    }
-
-    if leader.is_none() {
-        println!("no leader");
-        exit(1);
-    }
-
-    if converge_only {
-        return;
-    }
-
-    let leader = leader.unwrap();
-
-    println!("leader RPC is at {} {}", leader.rpc, leader.id);
-    let mut client = mk_client(&leader);
-    let mut barrier_client = mk_client(&leader);
-
-    let mut seed = [0u8; 32];
-    seed.copy_from_slice(&id.public_key_bytes()[..32]);
-    let mut rnd = GenKeys::new(seed);
-
-    println!("Creating {} keypairs...", tx_count * 2);
-    let mut total_keys = 0;
-    let mut target = tx_count * 2;
-    while target > 0 {
-        total_keys += target;
-        target /= MAX_SPENDS_PER_TX;
-    }
-    let gen_keypairs = rnd.gen_n_keypairs(total_keys as u64);
-    let barrier_id = rnd.gen_n_keypairs(1).pop().unwrap();
-
-    println!("Get tokens...");
-    let num_tokens_per_account = 20;
-
-    // Sample the first keypair, see if it has tokens, if so then resume
-    // to avoid token loss
-    let keypair0_balance = client
-        .poll_get_balance(&gen_keypairs.last().unwrap().pubkey())
-        .unwrap_or(0);
-
-    if num_tokens_per_account > keypair0_balance {
-        let extra = num_tokens_per_account - keypair0_balance;
-        let total = extra * (gen_keypairs.len() as u64);
-        airdrop_tokens(&mut client, &drone_addr, &id, total);
-        println!("adding more tokens {}", extra);
-        fund_keys(&mut client, &id, &gen_keypairs, extra);
-    }
-    let start = gen_keypairs.len() - (tx_count * 2) as usize;
-    let keypairs = &gen_keypairs[start..];
-    airdrop_tokens(&mut barrier_client, &drone_addr, &barrier_id, 1);
-
-    println!("Get last ID...");
-    let mut last_id = client.get_last_id();
-    println!("Got last ID {:?}", last_id);
-
-    let first_tx_count = client.transaction_count();
-    println!("Initial transaction count {}", first_tx_count);
-
-    // Setup a thread per validator to sample every period
-    // collect the max transaction rate and total tx count seen
-    let maxes = Arc::new(RwLock::new(Vec::new()));
-    let sample_period = 1; // in seconds
-    println!("Sampling TPS every {} second...", sample_period);
-    let v_threads: Vec<_> = nodes
-        .into_iter()
-        .map(|v| {
-            let exit_signal = exit_signal.clone();
-            let maxes = maxes.clone();
-            Builder::new()
-                .name("solana-client-sample".to_string())
-                .spawn(move || {
-                    sample_tx_count(&exit_signal, &maxes, first_tx_count, &v, sample_period);
-                })
-                .unwrap()
-        })
-        .collect();
-
-    let shared_txs: SharedTransactions = Arc::new(RwLock::new(VecDeque::new()));
-
-    let shared_tx_active_thread_count = Arc::new(AtomicIsize::new(0));
-    let total_tx_sent_count = Arc::new(AtomicUsize::new(0));
-
-    let s_threads: Vec<_> = (0..threads)
-        .map(|_| {
-            let exit_signal = exit_signal.clone();
-            let shared_txs = shared_txs.clone();
-            let leader = leader.clone();
-            let shared_tx_active_thread_count = shared_tx_active_thread_count.clone();
-            let total_tx_sent_count = total_tx_sent_count.clone();
-            Builder::new()
-                .name("solana-client-sender".to_string())
-                .spawn(move || {
-                    do_tx_transfers(
-                        &exit_signal,
-                        &shared_txs,
-                        &leader,
-                        &shared_tx_active_thread_count,
-                        &total_tx_sent_count,
-                    );
-                })
-                .unwrap()
-        })
-        .collect();
-
-    // generate and send transactions for the specified duration
-    let start = Instant::now();
-    let mut reclaim_tokens_back_to_source_account = false;
-    let mut i = keypair0_balance;
-    while start.elapsed() < duration {
-        let balance = client.poll_get_balance(&id.pubkey()).unwrap_or(0);
-        metrics_submit_token_balance(balance);
-
-        // ping-pong between source and destination accounts for each loop iteration
-        // this seems to be faster than trying to determine the balance of individual
-        // accounts
-        let len = tx_count as usize;
-        generate_txs(
-            &shared_txs,
-            &keypairs[..len],
-            &keypairs[len..],
-            threads,
-            reclaim_tokens_back_to_source_account,
-            &leader,
-        );
-        // In sustained mode overlap the transfers with generation
-        // this has higher average performance but lower peak performance
-        // in tested environments.
-        if !sustained {
-            while shared_tx_active_thread_count.load(Ordering::Relaxed) > 0 {
-                sleep(Duration::from_millis(100));
-            }
-        }
-        // It's not feasible (would take too much time) to confirm each of the `tx_count / 2`
-        // transactions sent by `generate_txs()` so instead send and confirm a single transaction
-        // to validate the network is still functional.
-        send_barrier_transaction(&mut barrier_client, &mut last_id, &barrier_id);
-
-        i += 1;
-        if should_switch_directions(num_tokens_per_account, i) {
-            reclaim_tokens_back_to_source_account = !reclaim_tokens_back_to_source_account;
-        }
-    }
-
-    // Stop the sampling threads so it will collect the stats
-    exit_signal.store(true, Ordering::Relaxed);
-
-    println!("Waiting for validator threads...");
-    for t in v_threads {
-        if let Err(err) = t.join() {
-            println!("  join() failed with: {:?}", err);
-        }
-    }
-
-    // join the tx send threads
-    println!("Waiting for transmit threads...");
-    for t in s_threads {
-        if let Err(err) = t.join() {
-            println!("  join() failed with: {:?}", err);
-        }
-    }
-
-    let balance = client.poll_get_balance(&id.pubkey()).unwrap_or(0);
-    metrics_submit_token_balance(balance);
-
-    compute_and_report_stats(
-        &maxes,
-        sample_period,
-        &start.elapsed(),
-        total_tx_sent_count.load(Ordering::Relaxed),
-    );
-
-    // join the cluster_info client threads
-    gossip_service.join().unwrap();
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-    #[test]
-    fn test_switch_directions() {
-        assert_eq!(should_switch_directions(20, 0), false);
-        assert_eq!(should_switch_directions(20, 1), false);
-        assert_eq!(should_switch_directions(20, 14), false);
-        assert_eq!(should_switch_directions(20, 15), true);
-        assert_eq!(should_switch_directions(20, 16), false);
-        assert_eq!(should_switch_directions(20, 19), false);
-        assert_eq!(should_switch_directions(20, 20), true);
-        assert_eq!(should_switch_directions(20, 21), false);
-        assert_eq!(should_switch_directions(20, 99), false);
-        assert_eq!(should_switch_directions(20, 100), true);
-        assert_eq!(should_switch_directions(20, 101), false);
-    }
+    do_bench_tps(cfg);
 }

benches/banking_stage.rs

@@ -1,232 +0,0 @@
-#![feature(test)]
-
-extern crate test;
-
-use rand::{thread_rng, Rng};
-use rayon::prelude::*;
-use solana::bank::Bank;
-use solana::banking_stage::{BankingStage, NUM_THREADS};
-use solana::entry::Entry;
-use solana::mint::Mint;
-use solana::packet::to_packets_chunked;
-use solana::status_deque::MAX_ENTRY_IDS;
-use solana_sdk::hash::hash;
-use solana_sdk::pubkey::Pubkey;
-use solana_sdk::signature::{Keypair, KeypairUtil, Signature};
-use solana_sdk::system_transaction::SystemTransaction;
-use solana_sdk::transaction::Transaction;
-use std::iter;
-use std::sync::mpsc::{channel, Receiver};
-use std::sync::Arc;
-use std::time::Duration;
-use test::Bencher;
-
-fn check_txs(receiver: &Receiver<Vec<Entry>>, ref_tx_count: usize) {
-    let mut total = 0;
-    loop {
-        let entries = receiver.recv_timeout(Duration::new(1, 0));
-        if let Ok(entries) = entries {
-            for entry in &entries {
-                total += entry.transactions.len();
-            }
-        } else {
-            break;
-        }
-        if total >= ref_tx_count {
-            break;
-        }
-    }
-    assert_eq!(total, ref_tx_count);
-}
-
-#[bench]
-fn bench_banking_stage_multi_accounts(bencher: &mut Bencher) {
-    let txes = 1000 * NUM_THREADS;
-    let mint_total = 1_000_000_000_000;
-    let mint = Mint::new(mint_total);
-
-    let (verified_sender, verified_receiver) = channel();
-    let bank = Arc::new(Bank::new(&mint));
-    let dummy_leader_id = Keypair::new().pubkey();
-    let dummy = Transaction::system_move(
-        &mint.keypair(),
-        mint.keypair().pubkey(),
-        1,
-        mint.last_id(),
-        0,
-    );
-    let transactions: Vec<_> = (0..txes)
-        .into_par_iter()
-        .map(|_| {
-            let mut new = dummy.clone();
-            let from: Vec<u8> = (0..64).map(|_| thread_rng().gen()).collect();
-            let to: Vec<u8> = (0..64).map(|_| thread_rng().gen()).collect();
-            let sig: Vec<u8> = (0..64).map(|_| thread_rng().gen()).collect();
-            new.account_keys[0] = Pubkey::new(&from[0..32]);
-            new.account_keys[1] = Pubkey::new(&to[0..32]);
-            new.signatures = vec![Signature::new(&sig[0..64])];
-            new
-        })
-        .collect();
-    // fund all the accounts
-    transactions.iter().for_each(|tx| {
-        let fund = Transaction::system_move(
-            &mint.keypair(),
-            tx.account_keys[0],
-            mint_total / txes as u64,
-            mint.last_id(),
-            0,
-        );
-        let x = bank.process_transaction(&fund);
-        assert!(x.is_ok());
-    });
-    //sanity check, make sure all the transactions can execute sequentially
-    transactions.iter().for_each(|tx| {
-        let res = bank.process_transaction(&tx);
-        assert!(res.is_ok(), "sanity test transactions");
-    });
-    bank.clear_signatures();
-    //sanity check, make sure all the transactions can execute in parallel
-    let res = bank.process_transactions(&transactions);
-    for r in res {
-        assert!(r.is_ok(), "sanity parallel execution");
-    }
-    bank.clear_signatures();
-    let verified: Vec<_> = to_packets_chunked(&transactions.clone(), 192)
-        .into_iter()
-        .map(|x| {
-            let len = x.read().unwrap().packets.len();
-            (x, iter::repeat(1).take(len).collect())
-        })
-        .collect();
-    let (_stage, signal_receiver) = BankingStage::new(
-        &bank,
-        verified_receiver,
-        Default::default(),
-        &mint.last_id(),
-        None,
-        dummy_leader_id,
-    );
-
-    let mut id = mint.last_id();
-    for _ in 0..MAX_ENTRY_IDS {
-        id = hash(&id.as_ref());
-        bank.register_tick(&id);
-    }
-
-    bencher.iter(move || {
-        // make sure the tx last id is still registered
-        if bank.count_valid_ids(&[mint.last_id()]).len() == 0 {
-            bank.register_tick(&mint.last_id());
-        }
-        for v in verified.chunks(verified.len() / NUM_THREADS) {
-            verified_sender.send(v.to_vec()).unwrap();
-        }
-        check_txs(&signal_receiver, txes);
-        bank.clear_signatures();
-    });
-}
-
-#[bench]
-fn bench_banking_stage_multi_programs(bencher: &mut Bencher) {
-    let progs = 4;
-    let txes = 1000 * NUM_THREADS;
-    let mint_total = 1_000_000_000_000;
-    let mint = Mint::new(mint_total);
-
-    let (verified_sender, verified_receiver) = channel();
-    let bank = Arc::new(Bank::new(&mint));
-    let dummy_leader_id = Keypair::new().pubkey();
-    let dummy = Transaction::system_move(
-        &mint.keypair(),
-        mint.keypair().pubkey(),
-        1,
-        mint.last_id(),
-        0,
-    );
-    let transactions: Vec<_> = (0..txes)
-        .into_par_iter()
-        .map(|_| {
-            let mut new = dummy.clone();
-            let from: Vec<u8> = (0..32).map(|_| thread_rng().gen()).collect();
-            let sig: Vec<u8> = (0..64).map(|_| thread_rng().gen()).collect();
-            let to: Vec<u8> = (0..32).map(|_| thread_rng().gen()).collect();
-            new.account_keys[0] = Pubkey::new(&from[0..32]);
-            new.account_keys[1] = Pubkey::new(&to[0..32]);
-            let prog = new.instructions[0].clone();
-            for i in 1..progs {
-                //generate programs that spend to random keys
-                let to: Vec<u8> = (0..32).map(|_| thread_rng().gen()).collect();
-                let to_key = Pubkey::new(&to[0..32]);
-                new.account_keys.push(to_key);
-                assert_eq!(new.account_keys.len(), i + 2);
-                new.instructions.push(prog.clone());
-                assert_eq!(new.instructions.len(), i + 1);
-                new.instructions[i].accounts[1] = 1 + i as u8;
-                assert_eq!(new.key(i, 1), Some(&to_key));
-                assert_eq!(
-                    new.account_keys[new.instructions[i].accounts[1] as usize],
-                    to_key
-                );
-            }
-            assert_eq!(new.instructions.len(), progs);
-            new.signatures = vec![Signature::new(&sig[0..64])];
-            new
-        })
-        .collect();
-    transactions.iter().for_each(|tx| {
-        let fund = Transaction::system_move(
-            &mint.keypair(),
-            tx.account_keys[0],
-            mint_total / txes as u64,
-            mint.last_id(),
-            0,
-        );
-        assert!(bank.process_transaction(&fund).is_ok());
-    });
-    //sanity check, make sure all the transactions can execute sequentially
-    transactions.iter().for_each(|tx| {
-        let res = bank.process_transaction(&tx);
-        assert!(res.is_ok(), "sanity test transactions");
-    });
-    bank.clear_signatures();
-    //sanity check, make sure all the transactions can execute in parallel
-    let res = bank.process_transactions(&transactions);
-    for r in res {
-        assert!(r.is_ok(), "sanity parallel execution");
-    }
-    bank.clear_signatures();
-    let verified: Vec<_> = to_packets_chunked(&transactions.clone(), 96)
-        .into_iter()
-        .map(|x| {
-            let len = x.read().unwrap().packets.len();
-            (x, iter::repeat(1).take(len).collect())
-        })
-        .collect();
-    let (_stage, signal_receiver) = BankingStage::new(
-        &bank,
-        verified_receiver,
-        Default::default(),
-        &mint.last_id(),
-        None,
-        dummy_leader_id,
-    );
-
-    let mut id = mint.last_id();
-    for _ in 0..MAX_ENTRY_IDS {
-        id = hash(&id.as_ref());
-        bank.register_tick(&id);
-    }
-
-    bencher.iter(move || {
-        // make sure the transactions are still valid
-        if bank.count_valid_ids(&[mint.last_id()]).len() == 0 {
-            bank.register_tick(&mint.last_id());
-        }
-        for v in verified.chunks(verified.len() / NUM_THREADS) {
-            verified_sender.send(v.to_vec()).unwrap();
-        }
-        check_txs(&signal_receiver, txes);
-        bank.clear_signatures();
-    });
-}

benches/db_ledger.rs

@@ -1,199 +0,0 @@
-#![feature(test)]
-use rand;
-
-extern crate test;
-
-use rand::seq::SliceRandom;
-use rand::{thread_rng, Rng};
-use rocksdb::{Options, DB};
-use solana::db_ledger::{DataCf, DbLedger, LedgerColumnFamilyRaw};
-use solana::ledger::{get_tmp_ledger_path, make_large_test_entries, make_tiny_test_entries, Block};
-use solana::packet::{Blob, BLOB_HEADER_SIZE};
-use test::Bencher;
-
-// Given some blobs and a ledger at ledger_path, benchmark writing the blobs to the ledger
-fn bench_write_blobs(bench: &mut Bencher, blobs: &mut [&mut Blob], ledger_path: &str) {
-    let db_ledger =
-        DbLedger::open(&ledger_path).expect("Expected to be able to open database ledger");
-    let slot = 0;
-    let num_blobs = blobs.len();
-    bench.iter(move || {
-        for blob in blobs.iter_mut() {
-            let index = blob.index().unwrap();
-            let key = DataCf::key(slot, index);
-            let size = blob.size().unwrap();
-            db_ledger
-                .data_cf
-                .put(&db_ledger.db, &key, &blob.data[..BLOB_HEADER_SIZE + size])
-                .unwrap();
-            blob.set_index(index + num_blobs as u64).unwrap();
-        }
-    });
-
-    DB::destroy(&Options::default(), &ledger_path)
-        .expect("Expected successful database destruction");
-}
-
-// Insert some blobs into the ledger in preparation for read benchmarks
-fn setup_read_bench(
-    db_ledger: &mut DbLedger,
-    num_small_blobs: u64,
-    num_large_blobs: u64,
-    slot: u64,
-) {
-    // Make some big and small entries
-    let mut entries = make_large_test_entries(num_large_blobs as usize);
-    entries.extend(make_tiny_test_entries(num_small_blobs as usize));
-
-    // Convert the entries to blobs, write the blobs to the ledger
-    let shared_blobs = entries.to_blobs();
-    for b in shared_blobs.iter() {
-        b.write().unwrap().set_slot(slot).unwrap();
-    }
-    db_ledger
-        .write_shared_blobs(&shared_blobs)
-        .expect("Expectd successful insertion of blobs into ledger");
-}
-
-// Write small blobs to the ledger
-#[bench]
-#[ignore]
-fn bench_write_small(bench: &mut Bencher) {
-    let ledger_path = get_tmp_ledger_path("bench_write_small");
-    let num_entries = 32 * 1024;
-    let entries = make_tiny_test_entries(num_entries);
-    let shared_blobs = entries.to_blobs();
-    let mut blob_locks: Vec<_> = shared_blobs.iter().map(|b| b.write().unwrap()).collect();
-    let mut blobs: Vec<&mut Blob> = blob_locks.iter_mut().map(|b| &mut **b).collect();
-    bench_write_blobs(bench, &mut blobs, &ledger_path);
-}
-
-// Write big blobs to the ledger
-#[bench]
-#[ignore]
-fn bench_write_big(bench: &mut Bencher) {
-    let ledger_path = get_tmp_ledger_path("bench_write_big");
-    let num_entries = 32 * 1024;
-    let entries = make_tiny_test_entries(num_entries);
-    let shared_blobs = entries.to_blobs();
-    let mut blob_locks: Vec<_> = shared_blobs.iter().map(|b| b.write().unwrap()).collect();
-    let mut blobs: Vec<&mut Blob> = blob_locks.iter_mut().map(|b| &mut **b).collect();
-    bench_write_blobs(bench, &mut blobs, &ledger_path);
-}
-
-#[bench]
-#[ignore]
-fn bench_read_sequential(bench: &mut Bencher) {
-    let ledger_path = get_tmp_ledger_path("bench_read_sequential");
-    let mut db_ledger =
-        DbLedger::open(&ledger_path).expect("Expected to be able to open database ledger");
-
-    // Insert some big and small blobs into the ledger
-    let num_small_blobs = 32 * 1024;
-    let num_large_blobs = 32 * 1024;
-    let total_blobs = num_small_blobs + num_large_blobs;
-    let slot = 0;
-    setup_read_bench(&mut db_ledger, num_small_blobs, num_large_blobs, slot);
-
-    let num_reads = total_blobs / 15;
-    let mut rng = rand::thread_rng();
-    bench.iter(move || {
-        // Generate random starting point in the range [0, total_blobs - 1], read num_reads blobs sequentially
-        let start_index = rng.gen_range(0, num_small_blobs + num_large_blobs);
-        for i in start_index..start_index + num_reads {
-            let _ =
-                db_ledger
-                    .data_cf
-                    .get_by_slot_index(&db_ledger.db, slot, i as u64 % total_blobs);
-        }
-    });
-
-    DB::destroy(&Options::default(), &ledger_path)
-        .expect("Expected successful database destruction");
-}
-
-#[bench]
-#[ignore]
-fn bench_read_random(bench: &mut Bencher) {
-    let ledger_path = get_tmp_ledger_path("bench_read_random");
-    let mut db_ledger =
-        DbLedger::open(&ledger_path).expect("Expected to be able to open database ledger");
-
-    // Insert some big and small blobs into the ledger
-    let num_small_blobs = 32 * 1024;
-    let num_large_blobs = 32 * 1024;
-    let total_blobs = num_small_blobs + num_large_blobs;
-    let slot = 0;
-    setup_read_bench(&mut db_ledger, num_small_blobs, num_large_blobs, slot);
-
-    let num_reads = total_blobs / 15;
-
-    // Generate a num_reads sized random sample of indexes in range [0, total_blobs - 1],
-    // simulating random reads
-    let mut rng = rand::thread_rng();
-    let indexes: Vec<usize> = (0..num_reads)
-        .map(|_| rng.gen_range(0, total_blobs) as usize)
-        .collect();
-    bench.iter(move || {
-        for i in indexes.iter() {
-            let _ = db_ledger
-                .data_cf
-                .get_by_slot_index(&db_ledger.db, slot, *i as u64);
-        }
-    });
-
-    DB::destroy(&Options::default(), &ledger_path)
-        .expect("Expected successful database destruction");
-}
-
-#[bench]
-#[ignore]
-fn bench_insert_data_blob_small(bench: &mut Bencher) {
-    let ledger_path = get_tmp_ledger_path("bench_insert_data_blob_small");
-    let db_ledger =
-        DbLedger::open(&ledger_path).expect("Expected to be able to open database ledger");
-    let num_entries = 32 * 1024;
-    let entries = make_tiny_test_entries(num_entries);
-    let mut shared_blobs = entries.to_blobs();
-    shared_blobs.shuffle(&mut thread_rng());
-
-    bench.iter(move || {
-        for blob in shared_blobs.iter_mut() {
-            let index = blob.read().unwrap().index().unwrap();
-            db_ledger.write_shared_blobs(vec![blob.clone()]).unwrap();
-            blob.write()
-                .unwrap()
-                .set_index(index + num_entries as u64)
-                .unwrap();
-        }
-    });
-
-    DB::destroy(&Options::default(), &ledger_path)
-        .expect("Expected successful database destruction");
-}
-
-#[bench]
-#[ignore]
-fn bench_insert_data_blob_big(bench: &mut Bencher) {
-    let ledger_path = get_tmp_ledger_path("bench_insert_data_blob_big");
-    let db_ledger =
-        DbLedger::open(&ledger_path).expect("Expected to be able to open database ledger");
-    let num_entries = 32 * 1024;
-    let entries = make_large_test_entries(num_entries);
-    let mut shared_blobs = entries.to_blobs();
-    shared_blobs.shuffle(&mut thread_rng());
-
-    bench.iter(move || {
-        for blob in shared_blobs.iter_mut() {
-            let index = blob.read().unwrap().index().unwrap();
-            db_ledger.write_shared_blobs(vec![blob.clone()]).unwrap();
-            blob.write()
-                .unwrap()
-                .set_index(index + num_entries as u64)
-                .unwrap();
-        }
-    });
-
-    DB::destroy(&Options::default(), &ledger_path)
-        .expect("Expected successful database destruction");
-}

book/.gitattributes

@@ -0,0 +1 @@
+theme/highlight.js binary

book/art/data-plane-neighborhood.bob

@@ -0,0 +1,25 @@
++---------------------------------------------------------------------------------------------------------+
+|                                           Neighborhood Above                                            |
+|                                                                                                         |
+|      +----------------+       +----------------+       +----------------+       +----------------+      |
+|      |                +------>+                +------>+                +------>+                |      |
+|      |   Neighbor 1   |       |   Neighbor 2   |       |   Neighbor 3   |       |   Neighbor 4   |      |
+|      |                +<------+                +<------+                +<------+                |      |
+|      +--+-------------+       +--+-------------+       +-----+----------+       +--+-------------+      |
+|         |                        |                           |                     |                    |
++---------------------------------------------------------------------------------------------------------+
+          |                        |                           |                     |
+          |                        |                           |                     |
+          |                        |                           |                     |
+          |                        |                           |                     |
+          |                        |                           |                     |
++---------------------------------------------------------------------------------------------------------+
+|         |                        |        Neighborhood Below |                     |                    |
+|         v                        v                           v                     v                    |
+|      +--+-------------+       +--+-------------+       +-----+----------+       +--+-------------+      |
+|      |                +------>+                +------>+                +------>+                |      |
+|      |   Neighbor 1   |       |   Neighbor 2   |       |   Neighbor 3   |       |   Neighbor 4   |      |
+|      |                +<------+                +<------+                +<------+                |      |
+|      +----------------+       +----------------+       +----------------+       +----------------+      |
+|                                                                                                         |
++---------------------------------------------------------------------------------------------------------+

book/art/data-plane.bob

@@ -1,25 +1,28 @@
-                                     .-------------.
-                                     |             |
-                       .-------------+   Leader    +══════════════╗
-                       |             |             |              ║
-                       |             `-------------`              ║
-                       v                                          v
-                .-------------.                            .-------------.
-                |             +--------------------------->|             |
-           .----+ Validator 1 |                            | Validator 2 +═══╗
-           |    |             |<═══════════════════════════+             |   ║
-           |    `------+------`                            `------+------`   ║
-           |           |                                          ║          ║
-           |           `------------------------------.           ║          ║
-           |                                          |           ║          ║
-           |                     ╔════════════════════════════════╝          ║
-           |                     ║                    |                      ║
-           V                     v                    V                      v
-    .-------------.       .-------------.       .-------------.       .-------------.
-    |             |       |             |       |             |       |             |
-    | Validator 3 +------>| Validator 4 +══════>| Validator 5 +------>| Validator 6 |
-    |             |       |             |       |             |       |             |
-    `-------------`       `-------------`       `-------------`       `------+------`
-           ^                                                                 ║
-           ║                                                                 ║
-           ╚═════════════════════════════════════════════════════════════════╝
+
+                                          +--------------+
+                                          |              |
+                             +------------+    Leader    +------------+
+                             |            |              |            |
+                             |            +--------------+            |
+                             v                                        v
+                    +--------+--------+                      +--------+--------+
+                    |                 +--------------------->+                 |
+  +-----------------+   Validator 1   |                      |   Validator 2   +-------------+
+  |                 |                 +<---------------------+                 |             |
+  |                 +------+-+-+------+                      +---+-+-+---------+             |
+  |                        | | |                                 | | |                       |
+  |                        | | |                                 | | |                       |
+  |                +---------------------------------------------+ | |                       |
+  |                |       | | |                                   | |                       |
+  |                |       | | |            +----------------------+ |                       |
+  |                |       | | |            |                        |                       |
+  |                |       | | +--------------------------------------------+                |
+  |                |       | |              |                        |      |                |
+  |                |       | +----------------------+                |      |                |
+  |                |       |                |       |                |      |                |
+  v                v       v                v       v                v      v                v
++--------------------+   +--------------------+   +--------------------+  +--------------------+
+|                    |   |                    |   |                    |  |                    |
+|   Neighborhood 1   |   |   Neighborhood 2   |   |   Neighborhood 3   |  |   Neighborhood 4   |
+|                    |   |                    |   |                    |  |                    |
++--------------------+   +--------------------+   +--------------------+  +--------------------+

book/art/forks-pruned.bob

@@ -0,0 +1,9 @@
+     1
+     |
+     2
+    /|
+   / |
+  |  |
+  |  4
+  |
+  5

book/art/forks-pruned2.bob

@@ -0,0 +1,11 @@
+ 1
+ |
+ 3
+ |\
+ | \
+ |  |
+ |  |
+ |  |
+ 6  |
+    |
+    7

book/art/forks.bob

@@ -0,0 +1,13 @@
+     1
+     |\
+     2 \
+    /|  |
+   / |  3
+  |  |  |\
+  |  4  | \
+  |     |  |
+  5     |  |
+        |  |
+        6  |
+           |
+           7

book/art/fullnode.bob

@@ -1,27 +1,30 @@
-             .---------------------------.
-             |  Fullnode                 |
-             |                           |
- .--------.  |  .------------------.     |
- |        |---->|                  |     |
- | Client |  |  | JSON RPC Service |     |
- |        |<----|                  |     |
- `----+---`  |  `------------------`     |
-      |      |     ^                     |    .------------------.
-      |      |     |  .----------------. |    | Validators       |
-      |      |     |  | Gossip Service +----->|                  |
-      |      |     |  `--------+-------` |    |  .------------.  |
-      |      |     |         ^ |         |    |  |            |  |
-      |      |     |         | v         |    |  | Upstream   |  |
-      |      |  .--+---.   .-+---.       |    |  | Validators |  |
-      |      |  | Bank |<--| TVU |<--------------+            |  |
-      |      |  `------`   `-----`       |    |  `------------`  |
-      |      |     ^                     |    |                  |
-      |      |     |                     |    |  .------------.  |
-      |      |  .--+--.   .-----------.  |    |  |            |  |
-      `-------->| TPU +-->| Broadcast +--------->| Downstream |  |
-             |  `-----`   | Service   |  |    |  | Validators |  |
-             |            `-----------`  |    |  |            |  |
-             |                           |    |  `------------`  |
-             `---------------------------`    |                  |
-                                              `------------------`
-
+             .--------------------------------------.
+             |  Fullnode                            |
+             |                                      |
+ .--------.  |  .-------------------.               |
+ |        |---->|                   |               |
+ | Client |  |  | JSON RPC Service  |               |
+ |        |<----|                   |               |
+ `----+---`  |  `-------------------`               |
+      |      |     ^                                |
+      |      |     |     .----------------.         | .------------------.
+      |      |     |     | Gossip Service |<----------| Validators       |
+      |      |     |     `----------------`         | |                  |
+      |      |     |           ^                    | |                  |
+      |      |     |           |                    | |  .------------.  |
+      |      | .---+---.  .----+---. .-----------.  | |  |            |  |
+      |      | | Bank  |<-+ Replay | | BlobFetch |<------+ Upstream   |  |
+      |      | | Forks |  | Stage  | |  Stage    |  | |  | Validators |  |
+      |      | `-------`  `--------` `--+--------`  | |  |            |  |
+      |      |     ^              ^     |           | |  `------------`  |
+      |      |     |              |     v           | |                  |
+      |      |     |           .--+--------.        | |                  |
+      |      |     |           | Blocktree |        | |                  |
+      |      |     |           `-----------`        | |  .------------.  |
+      |      |     |                ^               | |  |            |  |
+      |      |     |                |               | |  | Downstream |  |
+      |      |  .--+--.     .-------+---.           | |  | Validators |  |
+      `-------->| TPU +---->| Broadcast +--------------->|            |  |
+             |  `-----`     | Stage     |           | |  `------------`  |
+             |              `-----------`           | `------------------`
+             `--------------------------------------`

book/art/passive-staking-callflow.msc

@@ -0,0 +1,30 @@
+msc {
+  hscale="2.2";
+   VoteSigner,
+   Validator,
+   Cluster,
+   StakerX,
+   StakerY;
+
+   |||;
+  Validator box Validator [label="boot.."];
+
+  VoteSigner <:> Validator [label="register\n\n(optional)"];
+  Validator => Cluster [label="VoteState::Initialize(VoteSigner)"];
+  StakerX => Cluster [label="StakeState::Delegate(Validator)"];
+  StakerY => Cluster [label="StakeState::Delegate(Validator)"];
+
+     |||;
+  Validator box Cluster [label="\nvalidate\n"];
+  Validator => VoteSigner [label="sign(vote)"];
+  VoteSigner >> Validator [label="signed vote"];
+
+  Validator => Cluster [label="gossip(vote)"];
+  ...;
+  ... ;
+  Validator abox Validator [label="\nmax\nlockout\n"];
+       |||;
+  StakerX => Cluster [label="StakeState::RedeemCredits()"];
+  StakerY => Cluster [label="StakeState::RedeemCredits()"] ;
+
+}

book/art/runtime.bob

@@ -1,9 +1,10 @@
+.------------.     .-----------.    .---------------.    .--------------.    .-----------------------.
+| PoH verify +---> | sigverify +--->| lock accounts +--->| validate fee +--->| allocate new accounts +--->
+|     TVU    |     `-----------`    `---------------`    `--------------`    `-----------------------`
+`------------`
 
-.-----------.    .-------------.    .--------------.    .--------------------.    
-| sigverify +--->| lock memory +--->| validate fee +--->| allocate accounts  +--->
-`-----------`    `-------------`    `--------------`    `--------------------`    
-                                
-    .------------.    .---------.    .--------------.   .--------------.
---->| load data  +--->| execute +--->| commit data  +-->|unlock memory |
-    `------------`    `---------`    `--------------`   `--------------`
+    .---------------.    .---------.    .------------.    .-----------------.   .-----------------.
+--->| load accounts +--->| execute +--->| PoH record +--->| commit accounts +-->| unlock accounts |
+    `---------------`    `---------`    |    TPU     |    `-----------------`   `-----------------`
+                                        `------------`
 

book/art/tpu.bob

@@ -1,16 +1,17 @@
-             .------------------------------------------------------.
-             |  TPU                     .-------------.             |
-             |                          | PoH Service |             |
-             |                          `--------+----`             |
-             |                              ^    |                  |
-             |                              |    v                  |
-             |  .-------.  .-----------.  .-+-------.   .--------.  |  .------------.
- .---------. |  | Fetch |  | SigVerify |  | Banking |   | Ledger |  |  | Broadcast  |
- | Clients |--->| Stage |->| Stage     |->| Stage   |-->| Write  +---->| Service    |
- `---------` |  |       |  |           |  |         |   | Stage  |  |  |            |
-             |  `-------`  `-----------`  `----+----`   `--------`  |  `------------`
-             |                                 |                    |
-             `---------------------------------|--------------------`
+
+                                        .-------------.
+                                        | PoH Service |
+                                        `--------+----`
+                                            ^    |
+             .------------------------------|----|--------------------.
+             | TPU                          |    v                    |
+             |  .-------.  .-----------.  .-+-------.  .-----------.  |  .------------.
+ .---------. |  | Fetch |  | SigVerify |  | Banking |  | Broadcast |  |  | Downstream |
+ | Clients |--->| Stage |->| Stage     |->| Stage   |->| Stage     |---->| Validators |
+ `---------` |  |       |  |           |  |         |  |           |  |  |            |
+             |  `-------`  `-----------`  `----+----`  `-----------`  |  `------------`
+             |                                 |                      |
+             `---------------------------------|----------------------`
                                                |
                                                v
                                             .------.

book/art/tvu.bob

@@ -3,17 +3,17 @@
                                                   `--------`
                                                        ^
                                                        |
-                  .------------------------------------|---------------------------------.
-                  |  TVU                               |                                 |
-                  |                                    |                                 |
-                  |  .-------.   .------------.   .----+---.   .--------.   .---------.  |
- .------------.   |  | Blob  |   | Retransmit |   | Replay |   | Ledger |   | Storage |  |
- | Upstream   +----->| Fetch |-->| Stage      |-->| Stage  |-->| Write  |-->| Stage   |  |
- | Validators |   |  | Stage |   |            |   |        |   | Stage  |   |         |  |
- `------------`   |  `-------`   `----+-------`   `----+---`   `--------`   `---------`  |
-                  |        ^          |                |                                 |
-                  |        |          |                |                                 |
-                  `--------|----------|----------------|---------------------------------`
+                  .------------------------------------|--------------------.
+                  |  TVU                               |                    |
+                  |                                    |                    |
+                  |  .-------.   .------------.   .----+---.   .---------.  |
+ .------------.   |  | Blob  |   | Retransmit |   | Replay |   | Storage |  |
+ | Upstream   +----->| Fetch +-->| Stage      +-->| Stage  +-->| Stage   |  |
+ | Validators |   |  | Stage |   |            |   |        |   |         |  |
+ `------------`   |  `-------`   `----+-------`   `----+---`   `---------`  |
+                  |        ^          |                |                    |
+                  |        |          |                |                    |
+                  `--------|----------|----------------|--------------------`
                            |          |                |
                            |          V                v
                           .+-----------.            .------.

book/src/SUMMARY.md

@@ -15,23 +15,53 @@
   - [Synchronization](synchronization.md)
   - [Leader Rotation](leader-rotation.md)
   - [Fork Generation](fork-generation.md)
+  - [Managing Forks](managing-forks.md)
+  - [Data Plane Fanout](data-plane-fanout.md)
+  - [Ledger Replication](ledger-replication.md)
+  - [Secure Vote Signing](vote-signing.md)
+  - [Staking Delegation and Rewards](stake-delegation-and-rewards.md)
 
 - [Anatomy of a Fullnode](fullnode.md)
   - [TPU](tpu.md)
   - [TVU](tvu.md)
+    - [Blocktree](blocktree.md)
   - [Gossip Service](gossip.md)
   - [The Runtime](runtime.md)
 
-- [Proposed Architectural Changes](proposals.md)
-  - [Ledger Replication](ledger-replication.md)
-  - [Secure Enclave](enclave.md)
-  - [Staking Rewards](staking-rewards.md)
-  - [Fork Selection](fork-selection.md)
-  - [Entry Tree](entry-tree.md)
-
-## Appendix
-
-- [Appendix](appendix.md)
+- [API Reference](api-reference.md)
+  - [Blockstreamer](blockstreamer.md)
   - [JSON RPC API](jsonrpc-api.md)
   - [JavaScript API](javascript-api.md)
   - [solana-wallet CLI](wallet.md)
+
+- [Accepted Design Proposals](proposals.md)
+  - [Ledger Replication](ledger-replication-to-implement.md)
+  - [Secure Vote Signing](vote-signing-to-implement.md)
+  - [Staking Rewards](staking-rewards.md)
+  - [Passive Stake Delegation and Rewards](passive-stake-delegation-and-rewards.md)
+  - [Reliable Vote Transmission](reliable-vote-transmission.md)
+  - [Persistent Account Storage](persistent-account-storage.md)
+  - [Cluster Economics](ed_overview.md)
+    - [Validation-client Economics](ed_validation_client_economics.md)
+      - [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md)
+      - [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md)
+      - [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md)
+      - [Validation Stake Delegation](ed_vce_validation_stake_delegation.md)
+    - [Replication-client Economics](ed_replication_client_economics.md)
+      - [Storage-replication Rewards](ed_rce_storage_replication_rewards.md)
+      - [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md)
+    - [Economic Sustainability](ed_economic_sustainability.md)
+    - [Attack Vectors](ed_attack_vectors.md)
+	- [Economic Design MVP](ed_mvp.md)
+    - [References](ed_references.md)
+  - [Cluster Test Framework](cluster-test-framework.md)
+  - [Testing Programs](testing-programs.md)
+  - [Credit-only Accounts](credit-only-credit-debit-accounts.md)
+  - [Cluster Software Installation and Updates](installer.md)
+  - [Deterministic Transaction Fees](transaction-fees.md)
+
+- [Implemented Design Proposals](implemented-proposals.md)
+  - [Fork Selection](fork-selection.md)
+  - [Leader-to-Leader Transition](leader-leader-transition.md)
+  - [Leader-to-Validator Transition](leader-validator-transition.md)
+  - [Testnet Participation](testnet-participation.md)

book/src/api-reference.md

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

book/src/appendix.md

@@ -1,4 +0,0 @@
-# Appendix
-
-The following sections contain reference material you may find useful in your
-Solana journey.

book/src/block-confirmation.md

@@ -0,0 +1,84 @@
+# Block Confirmation
+
+A validator votes on a PoH hash for two purposes. First, the vote indicates it
+believes the ledger is valid up until that point in time. Second, since many
+valid forks may exist at a given height, the vote also indicates exclusive
+support for the fork. This document describes only the former. The latter is
+described in [fork selection](fork-selection.md).
+
+## Current Design
+
+To start voting, a validator first registers an account to which it will send
+its votes. It then sends votes to that account. The vote contains the tick
+height of the block it is voting on. The account stores the 32 highest heights.
+
+### Problems
+
+* Only the validator knows how to find its own votes directly.
+
+  Other components, such as the one that calculates confirmation time, needs to
+  be baked into the fullnode code. The fullnode code queries the bank for all
+  accounts owned by the vote program.
+
+* Voting ballots do not contain a PoH hash. The validator is only voting that
+  it has observed an arbitrary block at some height.
+
+* Voting ballots do not contain a hash of the bank state. Without that hash,
+  there is no evidence that the validator executed the transactions and
+  verified there were no double spends.
+
+## Proposed Design
+
+### No Cross-block State Initially
+
+At the moment a block is produced, the leader shall add a NewBlock transaction
+to the ledger with a number of tokens that represents the validation reward.
+It is effectively an incremental multisig transaction that sends tokens from
+the mining pool to the validators. The account should allocate just enough
+space to collect the votes required to achieve a supermajority. When a
+validator observes the NewBlock transaction, it has the option to submit a vote
+that includes a hash of its ledger state (the bank state). Once the account has
+sufficient votes, the vote program should disperse the tokens to the
+validators, which causes the account to be deleted.
+
+#### Logging Confirmation Time
+
+The bank will need to be aware of the vote program. After each transaction, it
+should check if it is a vote transaction and if so, check the state of that
+account. If the transaction caused the supermajority to be achieved, it should
+log the time since the NewBlock transaction was submitted.
+
+### Finality and Payouts
+
+Locktower is the proposed [fork selection](fork-selection.md) algorithm. It
+proposes that payment to miners be postponed until the *stack* of validator
+votes reaches a certain depth, at which point rollback is not economically
+feasible. The vote program may therefore implement locktower. Vote instructions
+would need to reference a global locktower account so that it can track
+cross-block state.
+
+## Challenges
+
+### On-chain voting
+
+Using programs and accounts to implement this is a bit tedious. The hardest
+part is figuring out how much space to allocate in NewBlock. The two variables
+are the *active set* and the stakes of those validators. If we calculate the
+active set at the time NewBlock is submitted, the number of validators to
+allocate space for is known upfront. If, however, we allow new validators to
+vote on old blocks, then we'd need a way to allocate space dynamically.
+
+Similar in spirit, if the leader caches stakes at the time of NewBlock, the
+vote program doesn't need to interact with the bank when it processes votes. If
+we don't, then we have the option to allow stakes to float until a vote is
+submitted. A validator could conceivably reference its own staking account, but
+that'd be the current account value instead of the account value of the most
+recently finalized bank state. The bank currently doesn't offer a means to
+reference accounts from particular points in time.
+
+### Voting Implications on Previous Blocks
+
+Does a vote on one height imply a vote on all blocks of lower heights of
+that fork? If it does, we'll need a way to lookup the accounts of all
+blocks that haven't yet reached supermajority. If not, the validator could
+send votes to all blocks explicitly to get the block rewards.

book/src/blockstreamer.md

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

book/src/blocktree.md

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

book/src/cluster-test-framework.md

@@ -0,0 +1,122 @@
+# Cluster Test Framework
+
+This document proposes the Cluster Test Framework (CTF).  CTF is a test harness
+that allows tests to execute against a local, in-process cluster or a
+deployed cluster.
+
+## Motivation
+
+The goal of CTF is to provide a framework for writing tests independent of where
+and how the cluster is deployed. Regressions can be captured in these tests and
+the tests can be run against deployed clusters to verify the deployment.  The
+focus of these tests should be on cluster stability, consensus, fault tolerance,
+API stability.
+
+Tests should verify a single bug or scenario, and should be written with the
+least amount of internal plumbing exposed to the test.
+
+## Design Overview
+
+Tests are provided an entry point, which is a `contact_info::ContactInfo`
+structure, and a keypair that has already been funded.
+
+Each node in the cluster is configured with a `fullnode::FullnodeConfig` at boot
+time.  At boot time this configuration specifies any extra cluster configuration
+required for the test. The cluster should boot with the configuration when it
+is run in-process or in a data center.
+
+Once booted, the test will discover the cluster through a gossip entry point and
+configure any runtime behaviors via fullnode RPC.
+
+## Test Interface
+
+Each CTF test starts with an opaque entry point and a funded keypair.  The test
+should not depend on how the cluster is deployed, and should be able to exercise
+all the cluster functionality through the publicly available interfaces.
+
+```rust,ignore
+use crate::contact_info::ContactInfo;
+use solana_sdk::signature::{Keypair, KeypairUtil};
+pub fn test_this_behavior(
+    entry_point_info: &ContactInfo,
+    funding_keypair: &Keypair,
+    num_nodes: usize,
+)
+```
+
+
+## Cluster Discovery
+
+At test start, the cluster has already been established and is fully connected.
+The test can discover most of the available nodes over a few second.
+
+```rust,ignore
+use crate::gossip_service::discover_nodes;
+
+// Discover the cluster over a few seconds.
+let cluster_nodes = discover_nodes(&entry_point_info, num_nodes);
+```
+
+## Cluster Configuration
+
+To enable specific scenarios, the cluster needs to be booted with special
+configurations.  These configurations can be captured in
+`fullnode::FullnodeConfig`.
+
+For example:
+
+```rust,ignore
+let mut fullnode_config = FullnodeConfig::default();
+fullnode_config.rpc_config.enable_fullnode_exit = true;
+let local = LocalCluster::new_with_config(
+                num_nodes,
+                10_000,
+                100,
+                &fullnode_config
+                );
+```
+
+## How to design a new test
+
+For example, there is a bug that shows that the cluster fails when it is flooded
+with invalid advertised gossip nodes.  Our gossip library and protocol may
+change, but the cluster still needs to stay resilient to floods of invalid
+advertised gossip nodes.
+
+Configure the RPC service:
+
+```rust,ignore
+let mut fullnode_config = FullnodeConfig::default();
+fullnode_config.rpc_config.enable_rpc_gossip_push = true;
+fullnode_config.rpc_config.enable_rpc_gossip_refresh_active_set = true;
+```
+
+Wire the RPCs and write a new test:
+
+```rust,ignore
+pub fn test_large_invalid_gossip_nodes(
+    entry_point_info: &ContactInfo,
+    funding_keypair: &Keypair,
+    num_nodes: usize,
+) {
+    let cluster = discover_nodes(&entry_point_info, num_nodes);
+
+    // Poison the cluster.
+    let client = create_client(entry_point_info.client_facing_addr(), FULLNODE_PORT_RANGE);
+    for _ in 0..(num_nodes * 100) {
+        client.gossip_push(
+            cluster_info::invalid_contact_info()
+        );
+    }
+    sleep(Durration::from_millis(1000));
+
+    // Force refresh of the active set.
+    for node in &cluster {
+        let client = create_client(node.client_facing_addr(), FULLNODE_PORT_RANGE);
+        client.gossip_refresh_active_set();
+    }
+
+    // Verify that spends still work.
+    verify_spends(&cluster);
+}
+```

book/src/cluster.md

@@ -96,4 +96,5 @@ 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*, but it is not yet implemented.
+size. We call the technique *data plane fanout*; learn more in the [data plan
+fanout](data-plane-fanout.md) section.

book/src/credit-only-credit-debit-accounts.md

@@ -0,0 +1,140 @@
+# Credit-Only Accounts
+
+This design covers the handling of credit-only and credit-debit accounts in the
+[runtime](runtime.md).  Accounts already distinguish themselves as credit-only or
+credit-debit based on the program ID specified by the transaction's instruction.
+Programs must treat accounts that are not owned by them as credit-only.
+
+To identify credit-only accounts by program id would require the account to be
+fetched and loaded from disk.  This operation is expensive, and while it is
+occurring, the runtime would have to reject any transactions referencing the same
+account.
+
+The proposal introduces a `num_readonly_accounts` field to the transaction
+structure, and removes the `program_ids` dedicated vector for program accounts.
+
+This design doesn't change the runtime transaction processing rules.
+Programs still can't write or spend accounts that they do not own, but it
+allows the runtime to optimistically take the correct lock for each account
+specified in the transaction before loading the accounts from storage.
+
+Accounts selected as credit-debit by the transaction can still be treated as
+credit-only by the instructions.
+
+## Runtime handling
+
+credit-only accounts have the following properties:
+
+* Can be deposited into:  Deposits can be implemented as a simple `atomic_add`.
+* read-only access to account data.
+
+Instructions that debit or modify the credit-only account data will fail.
+
+## Account Lock Optimizations
+
+The Accounts module keeps track of current locked accounts in the runtime,
+which separates credit-only accounts from the credit-debit accounts.  The credit-only
+accounts can be cached in memory and shared between all the threads executing
+transactions.
+
+The current runtime can't predict whether an account is credit-only or credit-debit when
+the transaction account keys are locked at the start of the transaction
+processing pipeline.  Accounts referenced by the transaction have not been
+loaded from the disk yet.
+
+An ideal design would cache the credit-only accounts while they are referenced by
+any transaction moving through the runtime, and release the cache when the last
+transaction exits the runtime.
+
+## Credit-only accounts and read-only account data
+
+Credit-only account data can be treated as read-only. Credit-debit
+account data is treated as read-write.
+
+## Transaction changes
+
+To enable the possibility of caching accounts only while they are in the
+runtime, the Transaction structure should be changed in the following way:
+
+* `program_ids: Vec<Pubkey>` - This vector is removed.  Program keys can be
+placed at the end of the `account_keys` vector within the `num_readonly_accounts`
+number set to the number of programs.
+
+* `num_readonly_accounts: u8` - The number of keys from the **end** of the
+transaction's `account_keys` array that is credit-only.
+
+The following possible accounts are present in an transaction:
+
+* paying account
+* RW accounts
+* R accounts
+* Program IDs
+
+The paying account must be credit-debit, and program IDs must be credit-only.  The
+first account in the `account_keys` array is always the account that pays for
+the transaction fee, therefore it cannot be credit-only.  For these reasons the
+credit-only accounts are all grouped together at the end of the `account_keys`
+vector.  Counting credit-only accounts from the end allow for the default `0`
+value to still be functionally correct, since a transaction will succeed with
+all credit-debit accounts.
+
+Since accounts can only appear once in the transaction's `account_keys` array,
+an account can only be credit-only or credit-debit in a single transaction, not
+both.  The runtime treats a transaction as one atomic unit of execution. If any
+instruction needs credit-debit access to an account, a copy needs to be made. The
+write lock is held for the entire time the transaction is being processed by
+the runtime.
+
+## Starvation
+
+Read locks for credit-only accounts can keep the runtime from executing
+transactions requesting a write lock to a credit-debit account.
+
+When a request for a write lock is made while a read lock is open, the
+transaction requesting the write lock should be cached.  Upon closing the read
+lock, the pending transactions can be pushed through the runtime.
+
+While a pending write transaction exists, any additional read lock requests for
+that account should fail.  It follows that any other write lock requests will also 
+fail.  Currently, clients must retransmit when a transaction fails because of 
+a pending transaction.  This approach would mimic that behavior as closely as
+possible while preventing write starvation.
+
+## Program execution with credit-only accounts
+
+Before handing off the accounts to program execution, the runtime can mark each
+account in each instruction as a credit-only account.  The credit-only accounts can
+be passed as references without an extra copy.  The transaction will abort on a
+write to credit-only.
+
+An alternative is to detect writes to credit-only accounts and fail the
+transactions before commit.
+
+## Alternative design
+
+This design attempts to cache a credit-only account after loading without the use
+of a transaction-specified credit-only accounts list.  Instead, the credit-only
+accounts are held in a reference-counted table inside the runtime as the
+transactions are processed.
+
+1. Transaction accounts are locked.
+    a. If the account is present in the ‘credit-only' table, the TX does not fail.
+       The pending state for this TX is marked NeedReadLock.
+2. Transaction accounts are loaded.
+    a. Transaction accounts that are credit-only increase their reference
+       count in the `credit-only` table.
+    b. Transaction accounts that need a write lock and are present in the
+       `credit-only` table fail.
+3. Transaction accounts are unlocked.
+    a. Decrement the `credit-only` lock table reference count; remove if its 0
+    b. Remove from the `lock` set if the account is not in the `credit-only`
+       table.
+
+The downside with this approach is that if the `lock` set mutex is released
+between lock and load to allow better pipelining of transactions, a request for
+a credit-only account may fail. Therefore, this approach is not suitable for
+treating programs as credit-only accounts.
+
+Holding the accounts lock mutex while fetching the account from disk would
+potentially have a significant performance hit on the runtime. Fetching from
+disk is expected to be slow, but can be parallelized between multiple disks.

book/src/data-plane-fanout.md

@@ -0,0 +1,84 @@
+# Data Plane Fanout
+
+A Solana cluster uses a multi-layer mechanism called *data plane fanout* to
+broadcast transaction blobs to all nodes in a very quick and efficient manner.
+In order to establish the fanout, the cluster divides itself into small
+collections of nodes, called *neighborhoods*. Each node is responsible for
+sharing any data it receives with the other nodes in its neighborhood, as well
+as propagating the data on to a small set of nodes in other neighborhoods.
+
+During its slot, the leader node distributes blobs between the validator nodes
+in one neighborhood (layer 1). Each validator shares its data within its
+neighborhood, but also retransmits the blobs to one node in each of multiple
+neighborhoods in the next layer (layer 2). The layer-2 nodes each share their
+data with their neighborhood peers, and retransmit to nodes in the next layer,
+etc, until all nodes in the cluster have received all the blobs.
+
+<img alt="Two layer cluster" src="img/data-plane.svg" class="center"/>
+
+## Neighborhood Assignment - Weighted Selection
+
+In order for data plane fanout to work, the entire cluster must agree on how the
+cluster is divided into neighborhoods. To achieve this, all the recognized
+validator nodes (the TVU peers) are sorted by stake and stored in a list. This
+list is then indexed in different ways to figure out neighborhood boundaries and
+retransmit peers. For example, the leader will simply select the first nodes to
+make up layer 1. These will automatically be the highest stake holders, allowing
+the heaviest votes to come back to the leader first. Layer-1 and lower-layer
+nodes use the same logic to find their neighbors and lower layer peers.
+
+## Layer and Neighborhood Structure
+
+The current leader makes its initial broadcasts to at most `DATA_PLANE_FANOUT`
+nodes. If this layer 1 is smaller than the number of nodes in the cluster, then
+the data plane fanout mechanism adds layers below. Subsequent layers follow
+these constraints to determine layer-capacity: Each neighborhood contains
+`NEIGHBORHOOD_SIZE` nodes and each layer may have up to `DATA_PLANE_FANOUT/2`
+neighborhoods.
+
+As mentioned above, each node in a layer only has to broadcast its blobs to its
+neighbors and to exactly 1 node in each next-layer neighborhood, instead of to
+every TVU peer in the cluster. In the default mode, each layer contains
+`DATA_PLANE_FANOUT/2` neighborhoods. The retransmit mechanism also supports a
+second, `grow`, mode of operation that squares the number of neighborhoods
+allowed each layer. This dramatically reduces the number of layers needed to
+support a large cluster, but can also have a negative impact on the network
+pressure on each node in the lower layers. A good way to think of the default
+mode (when `grow` is disabled) is to imagine it as chain of layers, where the
+leader sends blobs to layer-1 and then layer-1 to layer-2 and so on, the `layer
+capacities` remain constant, so all layers past layer-2 will have the same
+number of nodes until the whole cluster is covered. When `grow` is enabled, this
+becomes a traditional fanout where layer-3 will have the square of the number of
+nodes in layer-2 and so on.
+
+#### Configuration Values
+
+`DATA_PLANE_FANOUT` - Determines the size of layer 1. Subsequent
+layers have `DATA_PLANE_FANOUT/2` neighborhoods when `grow` is inactive.
+
+`NEIGHBORHOOD_SIZE` - The number of nodes allowed in a neighborhood.
+Neighborhoods will fill to capacity before new ones are added, i.e if a
+neighborhood isn't full, it _must_ be the last one.
+
+`GROW_LAYER_CAPACITY` - Whether or not retransmit should be behave like a
+_traditional fanout_, i.e if each additional layer should have growing
+capacities. When this mode is disabled (default), all layers after layer 1 have
+the same capacity, keeping the network pressure on all nodes equal.
+
+Currently, configuration is set when the cluster is launched. In the future,
+these parameters may be hosted on-chain, allowing modification on the fly as the
+cluster sizes change.
+
+## Neighborhoods
+
+The following diagram shows how two neighborhoods in different layers interact.
+What this diagram doesn't capture is that each neighbor actually receives
+blobs from one validator per neighborhood above it. This means that, to
+cripple a neighborhood, enough nodes (erasure codes +1 per neighborhood) from
+the layer above need to fail.  Since multiple neighborhoods exist in the upper
+layer and a node will receive blobs from a node in each of those neighborhoods,
+we'd need a big network failure in the upper layers to end up with incomplete
+data.
+
+<img alt="Inner workings of a neighborhood"
+src="img/data-plane-neighborhood.svg" class="center"/>

book/src/drones.md

@@ -46,7 +46,7 @@ desired cluster.
 
 ## Attack vectors
 
-### Invalid last_id
+### Invalid recent_blockhash
 
 The drone may prefer its airdrops only target a particular Solana cluster.  To
 do that, it listens to the cluster for new entry IDs and ensure any requests
@@ -68,8 +68,8 @@ A client may request multiple airdrops before the first has been submitted to
 the ledger. The client may do this maliciously or simply because it thinks the
 first request was dropped. The drone should not simply query the cluster to
 ensure the client has not already received an airdrop. Instead, it should use
-`last_id` to ensure the previous request is expired before signing another.
-Note that the Solana cluster will reject any transaction with a `last_id`
+`recent_blockhash` to ensure the previous request is expired before signing another.
+Note that the Solana cluster will reject any transaction with a `recent_blockhash`
 beyond a certain *age*.
 
 ### Denial of Service

book/src/ed_attack_vectors.md

@@ -0,0 +1,11 @@
+## Attack Vectors
+
+### Colluding validation and replication clients
+
+A colluding validation-client, may take the strategy to mark PoReps from non-colluding replicator nodes as invalid as an attempt to maximize the rewards for the colluding replicator nodes. In this case, it isn’t feasible for the offended-against replicator nodes to petition the network for resolution as this would result in a network-wide vote on each offending PoRep and create too much overhead for the network to progress adequately. Also, this mitigation attempt would still be vulnerable to a >= 51% staked colluder.
+
+Alternatively, transaction fees from submitted PoReps are pooled and distributed across validation-clients in proportion to the number of valid PoReps discounted by the number of invalid PoReps as voted by each validator-client. Thus invalid votes are directly dis-incentivized through this reward channel. Invalid votes that are revealed by replicator nodes as fishing PoReps, will not be discounted from the payout PoRep count.
+
+Another collusion attack involves a validator-client who may take the strategy to ignore invalid PoReps from colluding replicator and vote them as valid. In this case, colluding replicator-clients would not have to store the data while still receiving rewards for validated PoReps. Additionally, colluding validator nodes would also receive rewards for validating these PoReps. To mitigate this attack, validators must randomly sample PoReps corresponding to the ledger block they are validating and because of this, there will be multiple validators that will receive the colluding replicator’s invalid submissions. These non-colluding validators will be incentivized to mark these PoReps as invalid as they have no way to determine whether the proposed invalid PoRep is actually a fishing PoRep, for which a confirmation vote would result in the validator’s stake being slashed.
+
+In this case, the proportion of time a colluding pair will be successful has an upper limit determined by the % of stake of the network claimed by the colluding validator. This also sets bounds to the value of such an attack. For example, if a colluding validator controls 10% of the total validator stake, transaction fees will be lost (likely sent to mining pool) by the colluding replicator 90% of the time and so the attack vector is only profitable if the per-PoRep reward at least 90% higher than the average PoRep transaction fee. While, probabilistically, some colluding replicator-client PoReps will find their way to colluding validation-clients, the network can also monitor rates of paired (validator + replicator) discrepancies in voting patterns and censor identified colluders in these cases.

book/src/ed_economic_sustainability.md

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

book/src/ed_mvp.md

@@ -0,0 +1,12 @@
+## Proposed MVP of Economic Design
+
+The preceeding sections, outlined in the [Economic Design Overview](ed_overview.md), describe a long-term vision of a sustainable Solana economy. Of course, we don't expect the final implementation to perfectly match what has been described above. We intend to fully engage with network stakeholders throughout the implementation phases (i.e. pre-testnet, testnet, mainnet) to ensure the system supports, and is representative of, the various network participants' interests. The first step toward this goal, however, is outlining a some desired MVP economic features to be available for early pre-testnet and testnet participants. Below is a rough sketch outlining basic economic functionality from which a more complete and functional system can be developed.
+
+### MVP Economic Features
+
+* Faucet to deliver testnet SOLs to validators for staking and dapp development.
+* Mechanism by which validators are rewarded in proportion to their stake. Interest rate mechansism (i.e. to be determined by total % staked) to come later.
+* Ability to delegate tokens to validator nodes.
+* Replicators to receive fixed, arbitrary reward for submitting validated PoReps. Reward size mechanism (i.e. PoRep reward as a function of total ledger redundancy) to come later.
+* Pooling of replicator PoRep transaction fees and weighted distribution to validators based on PoRep verification (see [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md). It will be useful to test this protection against attacks on testnet.
+* Nice-to-have: auto-delegation of replicator rewards to validator.

book/src/ed_overview.md

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

book/src/ed_rce_replication_client_reward_auto_delegation.md

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

book/src/ed_rce_storage_replication_rewards.md

@@ -0,0 +1,5 @@
+### Storage-replication Rewards
+
+Replicator-clients download, encrypt and submit PoReps for ledger block sections.3  PoReps submitted to the PoH stream, and subsequently validated, function as evidence that the submitting replicator client is indeed storing the assigned ledger block sections on local hard drive space as a service to the network. Therefore, replicator clients should earn protocol rewards proportional to the amount of storage, and the number of successfully validated PoReps, that they are verifiably providing to the network.
+
+Additionally, replicator clients have the opportunity to capture a portion of slashed bounties [TBD] of dishonest validator clients. This can be accomplished by a replicator client submitting a verifiably false PoRep for which a dishonest validator client receives and signs as a valid PoRep. This reward incentive is to prevent lazy validators and minimize validator-replicator collusion attacks, more on this below.

book/src/ed_references.md

@@ -0,0 +1,7 @@
+## References
+
+1. [https://blog.ethereum.org/2016/07/27/inflation-transaction-fees-cryptocurrency-monetary-policy/](https://blog.ethereum.org/2016/07/27/inflation-transaction-fees-cryptocurrency-monetary-policy/)
+
+2. [https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281](https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281)
+
+3. [https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281](https://medium.com/solana-labs/how-to-create-decentralized-storage-for-a-multi-petabyte-digital-ledger-2499a3a8c281)

book/src/ed_replication_client_economics.md

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

book/src/ed_validation_client_economics.md

@@ -0,0 +1,3 @@
+## Validation-client Economics
+
+Validator-clients are eligible to receive protocol-based (i.e. via mining pool) rewards issued via stake-based annual interest rates by providing compute (CPU+GPU) resources to validate and vote on a given PoH state. These protocol-based rewards are determined through an algorithmic schedule as a function of total amount of Solana tokens staked in the system and duration since network launch (genesis block). Additionally, these clients may earn revenue through two types of transaction fees: state-validation transaction fees and pooled Proof-of-Replication (PoRep) transaction fees. The distribution of these two types of transaction fees to the participating validation set are designed independently as economic goals and attack vectors are unique between the state- generation/validation mechanism and the ledger replication/validation mechanism. For clarity, we separately describe the design and motivation of the three types of potential revenue streams for validation-clients below: state-validation protocol-based rewards, state-validation transaction fees and PoRep-validation transaction fees.

book/src/ed_vce_replication_validation_transaction_fees.md

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

book/src/ed_vce_state_validation_protocol_based_rewards.md

@@ -0,0 +1,46 @@
+### State-validation protocol-based rewards
+
+Validator-clients have two functional roles in the Solana network
+
+* Validate (vote) the current global state of that PoH along with any Proofs-of-Replication (see [Replication Client Economics](ed_replication_client_economics.md)) that they are eligible to validate
+
+* Be elected as ‘leader’ on a stake-weighted round-robin schedule during which time they are responsible for collecting outstanding transactions and Proofs-of-Replication and incorporating them into the PoH, thus updating the global state of the network and providing chain continuity.
+
+Validator-client rewards for these services are to be distributed at the end of each Solana epoch. Compensation for validator-clients is provided via a protocol-based annual interest rate dispersed in proportion to the stake-weight of each validator (see below) along with leader-claimed transaction fees available during each leader rotation. I.e. during the time a given validator-client is elected as leader, it has the opportunity to keep a portion of each non-PoRep transaction fee, less a protocol-specified amount that is returned to the mining pool (see [Validation-client State Transaction Fees](ed_vce_state_validation_transaction_fees.md)). PoRep transaction fees are not collected directly by the leader client but pooled and returned to the validator set in proportion to the number of successfully validated PoReps. (see [Replication-client Transaction Fees](ed_vce_replication_validation_transaction_fees.md))
+
+
+The protocol-based annual interest-rate (%) per epoch to be distributed to validation-clients is to be a function of:
+
+* the current fraction of staked SOLs out of the current total circulating supply,
+
+* the global time since the genesis block instantiation
+
+* the up-time/participation [% of available slots/blocks that validator had opportunity to vote on?] of a given validator over the previous epoch.
+
+The first two factors are protocol parameters only (i.e. independent of validator behavior in a given epoch) and describe a global validation reward schedule designed to both incentivize early participation and optimal security in the network. This schedule sets a maximum annual validator-client interest rate per epoch.
+
+At any given point in time, this interest rate is pegged to a defined value given a specific % staked SOL out of the circulating supply (e.g. 10% interest rate when 66% of circulating SOL is staked). The interest rate adjusts as the square-root [TBD] of the % staked, leading to higher validation-client interest rates as the % staked drops below the targeted goal, thus incentivizing more participation leading to more security in the network. An example of such a schedule, for a specified point in time (e.g. network launch) is shown in **Table 1**.
+
+| Percentage circulating supply staked [%] | Annual validator-client interest rate [%] |
+| ---:    | ---:      |
+| 5       | 13.87     |
+| 15      | 13.31     |
+| 25      | 12.73     |
+| 35      | 12.12     |
+| 45      | 11.48     |
+| 55      | 10.80     |
+| **66**  | **10.00** |
+| 75      | 9.29      |
+| 85      | 8.44      |    
+
+**Table 1:** Example interest rate schedule based on % SOL staked out of circulating supply. In this case, interest rates are fixed at 10% for 66% of staked circulating supply
+
+Over time, the interest rate, at any network staked percentage, will drop as described by an algorithmic schedule. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. This mining-pool provided interest rate will reduce over time until a network-chosen baseline value is reached. This is a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for both state-validation and ledger storage replication (PoReps) are not accounted for here. A validation-client interest rate schedule as a function of % network staked and time is shown in** Figure 2**.
+
+<!-- ![== Validation Client Interest Rates Figure ==](validation_client_interest_rates.png =250x) -->
+
+<p style="text-align:center;"><img src="img/validation_client_interest_rates.png" alt="drawing" width="800"/></p>
+
+**Figure 2:** In this example schedule, the annual interest rate [%] reduces at around 16.7% per year, until it reaches the long-term, fixed, 4% rate.
+
+This epoch-specific protocol-defined interest rate sets an upper limit of *protocol-generated* annual interest rate (not absolute total interest rate) possible to be delivered to any validator-client per epoch. The distributed interest rate per epoch is then discounted from this value based on the participation of the validator-client during the previous epoch. Each epoch is comprised of XXX slots. The protocol-defined interest rate is then discounted by the log [TBD] of the % of slots a given validator submitted a vote on a PoH branch during that epoch, see **Figure XX**

book/src/ed_vce_state_validation_transaction_fees.md

@@ -0,0 +1,20 @@
+### State-validation Transaction Fees
+
+Each message sent through the network, to be processed by the current leader validation-client and confirmed as a global state transaction, must contain a transaction fee. Transaction fees offer many benefits in the Solana economic design, for example they:
+
+* provide unit compensation to the validator network for the CPU/GPU resources necessary to process the state transaction,
+
+* reduce network spam by introducing real cost to transactions,
+
+* open avenues for a transaction market to incentivize validation-client to collect and process submitted transactions in their function as leader,
+
+* and provide potential long-term economic stability of the network through a protocol-captured minimum fee amount per transaction, as described below.
+
+Many current blockchain economies (e.g. Bitcoin, Ethereum), rely on protocol-based rewards to support the economy in the short term, with the assumption that the revenue generated through transaction fees will support the economy in the long term, when the protocol derived rewards expire. In an attempt to create a sustainable economy through protocol-based rewards and transaction fees, a fixed portion of each transaction fee is sent to the mining pool, with the resulting fee going to the current leader processing the transaction. These pooled fees, then re-enter the system through rewards distributed to validation-clients, through the process described above, and replication-clients, as discussed below.
+
+The intent of this design is to retain leader incentive to include as many transactions as possible within the leader-slot time, while providing a redistribution avenue that protects against "tax evasion" attacks (i.e. side-channel fee payments)<sup>[1](ed_referenced.md)</sup>. Constraints on the fixed portion of transaction fees going to the mining pool, to establish long-term economic sustainability, are established and discussed in detail in the [Economic Sustainability](ed_economic_sustainability.md) section.
+
+This minimum, protocol-earmarked, portion of each transaction fee can be dynamically adjusted depending on historical gas usage. In this way, the protocol can use the minimum fee to target a desired hardware utilisation. By monitoring a protocol specified gas usage with respect to a desired, target usage amount (e.g. 50% of a block's capacity), the minimum fee can be raised/lowered which should, in turn, lower/raise the actual gas usage per block until it reaches the target amount. This adjustment process can be thought of as similar to the difficulty adjustment algorithm in the Bitcoin protocol, however in this case it is adjusting the minimum transaction fee to guide the transaction processing hardware usage to a desired level.
+
+Additionally, the minimum protocol captured fee can be a consideration in fork selection. In the case of a PoH fork with a  malicious, censoring leader, we would expect the total procotol captured fee to be less than a comparable honest fork, due to the fees lost from censoring. If the censoring leader is to compensate for these lost protocol fees, they would have to replace the fees on their fork themselves, thus potentially reducing the incentive to censor in the first place. 
+

book/src/ed_vce_validation_stake_delegation.md

@@ -0,0 +1,29 @@
+### Validation Stake Delegation
+
+Running a Solana validation-client required relatively modest upfront hardware capital investment. **Table 2** provides an example hardware configuration to support ~1M tx/s with estimated ‘off-the-shelf’ costs:
+
+|Component|Example|Estimated Cost|
+|--- |--- |--- |
+|GPU|2x 2080 Ti|$2500|
+|or|4x 1080 Ti|$2800|
+|OS/Ledger Storage|Samsung 860 Evo 2TB|$370|
+|Accounts storage|2x Samsung 970 Pro M.2 512GB|$340|
+|RAM|32 Gb|$300|
+|Motherboard|AMD x399|$400|
+|CPU|AMD Threadripper 2920x|$650|
+|Case||$100|
+|Power supply|EVGA 1600W|$300|
+|Network|> 500 mbps||
+|Network (1)|Google webpass business bay area 1gbps unlimited|$5500/mo|
+|Network (2)|Hurricane Electric bay area colo 1gbps|$500/mo|
+**Table 2** example high-end hardware setup for running a Solana client.
+
+Despite the low-barrier to entry as a validation-client, from a capital investment perspective, as in any developing economy, there will be much opportunity and need for trusted validation services as evidenced by node reliability, UX/UI, APIs and other software accessibility tools. Additionally, although Solana’s validator node startup costs are nominal when compared to similar networks, they may still be somewhat restrictive for some potential participants. In the spirit of developing a true decentralized, permissionless network, these interested parties still have two options to become involved in the Solana network/economy:
+
+1. Delegation of previously acquired tokens with a reliable validation node to earn a portion of interest generated
+
+2. Provide local storage space as a replication-client and receive rewards by submitting Proof-of-Replication (see [Replication-client Economics](ed_replication_client_economics.md)).
+
+    a. This participant has the additional option to directly delegate their earned storage rewards ([Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md))
+
+Delegation of tokens to validation-clients, via option 1, provides a way for passive Solana token holders to become part of the active Solana economy and earn interest rates proportional to the interest rate generated by the delegated validation-client. Additionally, this feature creates a healthy validation-client market, with potential validation-client nodes competing to build reliable, transparent and profitable delegation services.

book/src/entry-tree.md

@@ -1,121 +0,0 @@
-# Entry Tree
-
-This document proposes a change to ledger and window to support Solana's [fork
-generation](fork-generation.md) behavior.
-
-## Current Design
-
-### Functionality of Window And Ledger
-
-The basic responsibilities of the window and the ledger in a Solana fullnode
-are:
-
- 1. Window: serve as a temporary, RAM-backed store of blobs of the PoH chain
-    for re-ordering and assembly into contiguous blocks to be sent to the bank
-    for verification.
- 2. Window: serve as a RAM-backed repair facility for other validator nodes,
-    which may query the network for as-yet unreceived blobs.
- 3. Ledger: provide disk-based storage of the PoH chain in case of node
-    restart.
- 4. Ledger: provide disk-backed repair facility for when the (smaller)
-    RAM-backed window doesn't cover the repair request.
-
-The window is at the front of a validator node's processing pipeline, blobs are
-received, cached, re-ordered before being deserialized into Entries, passed to
-the bank for verification, and finally on to the ledger, which is at the back
-of a validator node's pipeline.
-
-The window holds blobs (the over-the-air format, serialized Entries,
-one-per-blob).  The ledger holds serialized Entries without any blob
-information.
-
-### Limitations
-
-#### One-dimensional key space
-
-The window and the ledger are indexed by ledger height, which is number of
-Entries ever generated in the PoH chain until the current blob.  This
-limitation prevents the window and the ledger from storing the overlapping
-histories possible in Solana's consensus protocol.
-
-#### Limited caching
-
-The window is a circular buffer.  It cannot accept blobs that are farther in
-the future than the window is currently working.  If a blob arrives that is too
-far ahead, it is dropped and will subsequently need to be repaired, incurring
-further delay for the node.
-
-#### Loss of blob signatures
-
-Because the blob signatures are stripped before being stored by the ledger,
-repair requests served from the ledger can't be verified to the original
-leader.
-
-#### Rollback and checkpoint, switching forks, separate functions
-
-The window and the ledger can't handle replay of alternate forks.  Once a Blob
-has passed through the window, it's in the past.  The replay stage of a
-validator will need to roll back to a previous checkpoint and decode an
-alternate set of Blobs to the Bank.  The separated and one-way nature of window
-and ledger makes this hard.
-
-## New Design
-
-A unified window and ledger allows a validator to record every blob it observes
-on the network, in any order, as long as the blob is consistent with the
-network's leader schedule.
-
-Blobs are moved to a fork-able key space the tuple of `leader slot` + `blob
-index` (within the slot).  This permits the skip-list structure of the Solana
-protocol to be stored in its entirety, without a-priori choosing which fork to
-follow, which Entries to persist or when to persist them.
-
-Repair requests for recent blobs are served out of RAM or recent files and out
-of deeper storage for less recent blobs, as implemented by the store backing
-EntryTree.
-
-### Functionalities of EntryTree
-
-1. Persistence: the EntryTree lives in the front of the nodes verification
-   pipeline, right behind network receive and signature verification.  If the
-blob received is consistent with the leader schedule (i.e. was signed by the
-leader for the indicated slot), it is immediately stored.
-2. Repair: repair is the same as window repair above, but able to serve any
-   blob that's been received. EntryTree stores blobs with signatures,
-preserving the chain of origination.
-3. Forks: EntryTree supports random access of blobs, so can support a
-   validator's need to rollback and replay from a Bank checkpoint.
-4. Restart: with proper pruning/culling, the EntryTree 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 EntryTree.
-
-### Interfacing with Bank
-
-The bank exposes to replay stage:
-
- 1. prev_id: which PoH chain it's working on as indicated by the id 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_ids: 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 EntryTree 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 EntryTree
-
-Once EntryTree 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 EntryTree contents
-that are not on the PoH chain for that vote for can be pruned, expunged.
-
-Replicator nodes will be responsible for storing really old ledger contents,
-and validators need only persist their bank periodically.

book/src/fork-generation.md

@@ -59,9 +59,11 @@ Validators vote based on a greedy choice to maximize their reward described in
 
 ### Validator's View
 
-#### Time Progression The diagram below represents a validator's view of the
-PoH stream with possible forks over time.  L1, L2, etc. are leader slot, and
-`E`s represent entries from that leader during that leader's slot.  The 'x's
+#### Time Progression
+
+The diagram below represents a validator's view of the
+PoH stream with possible forks over time.  L1, L2, etc. are leader slots, and
+`E`s represent entries from that leader during that leader's slot.  The `x`s
 represent ticks only, and time flows downwards in the diagram.
 
 

book/src/fork-selection.md

@@ -1,53 +1,75 @@
 # Fork Selection
-This article describes Solana's *Nakomoto Fork Selection* algorithm based on time
-locks. It satisfies the following properties:
 
+This design describes a *Fork Selection* algorithm. It addresses the following
+problems:
 
-* A voter can eventually recover from voting on a fork that doesn't become the
-  fork with the desired network finality.
-* If the voters share a common ancestor then they will converge to a fork
-  containing that ancestor no matter how they are partitioned. The converged
-  ancestor may not be the latest possible ancestor at the start of the fork.
-* Rollback requires exponentially more time for older votes than for newer
-  votes.
-* Voters have the freedom to set a minimum network confirmation threshold
-  before committing a vote to a higher lockout.  This allows each voter to make
-  a trade-off between risk and reward. See [cost of rollback](#cost-of-rollback).
+* Some forks may not end up accepted by the super-majority of the cluster, and
+voters need to recover from voting on such forks.
+
+* Many forks may be votable by different voters, and each voter may see a
+different set of votable forks.  The selected forks should eventually converge
+for the cluster.
+
+* Reward based votes have an associated risk.  Voters should have the ability to
+configure how much risk they take on.
+
+* The [cost of rollback](#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.
+
+* ASIC speeds are different between nodes, and attackers could employ Proof of
+History ASICS that are much faster than the rest of the cluster.  Consensus
+needs to be resistant to attacks that exploit the variability in Proof of
+History ASIC speed.
+
+For brevity this design assumes that a single voter with a stake is deployed as
+an individual validator in the cluster.
 
 ## Time
 
-For networks like Solana, time can be the PoH hash count, which is a VDF that
-provides a source of time before consensus. Other networks adopting this
-approach would need to consider a global source of time.
+The Solana cluster generates a source of time via a Verifiable Delay Function we
+are calling [Proof of History](book/src/synchronization.md).
 
-For Solana, time uniquely identifies a specific leader for fork generation.  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](fork-generation.md)
-and [leader rotation](leader-rotation.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](fork-generation.md) and [leader rotation](leader-rotation.md).
+
+## Lockouts
+
+The purpose of the lockout is to force a validator to commit opportunity cost to
+a specific fork.  Lockouts are measured in slots, and therefor represent a
+real-time forced delay that a validator needs to wait before breaking the
+commitment to a fork.
+
+Validators that violate the lockouts and vote for a diverging fork within the
+lockout should be punished. The proposed punishment is to slash the validator
+stake if a concurrent vote within a lockout for a non-descendant fork can be
+proven to the cluster.
 
 ## Algorithm
 
-The basic idea to this approach is to stack consensus votes.  Each vote in the
-stack is a confirmation of a fork.  Each confirmed fork is an ancestor of the
-fork above it.  Each consensus vote has a `lockout` in units of time before the
-validator can submit a vote that does not contain the confirmed fork as an
-ancestor.
+The basic idea to this approach is to stack consensus votes and double lockouts.
+Each vote in the stack is a confirmation of a fork.  Each confirmed fork is an
+ancestor of the fork above it.  Each vote has a `lockout` in units of slots
+before the validator can submit a vote that does not contain the confirmed fork
+as an ancestor.
 
-When a vote is added to the stack, the lockouts of all the previous votes in
-the stack are doubled (more on this in [Rollback](#Rollback)).  With each new
-vote, a voter commits the previous votes to an ever-increasing lockout.  At 32
+When a vote is added to the stack, the lockouts of all the previous votes in the
+stack are doubled (more on this in [Rollback](#Rollback)).  With each new vote,
+a validator commits the previous votes to an ever-increasing lockout.  At 32
 votes we can consider the vote to be at `max lockout` any votes with a lockout
 equal to or above `1<<32` are dequeued (FIFO).  Dequeuing a vote is the trigger
 for a reward.  If a vote expires before it is dequeued, it and all the votes
-above it are popped (LIFO) from the vote stack.  The voter needs to start
+above it are popped (LIFO) from the vote stack.  The validator needs to start
 rebuilding the stack from that point.
 
-
 ### Rollback
 
 Before a vote is pushed to the stack, all the votes leading up to vote with a
 lower lock time than the new vote are popped.  After rollback lockouts are not
-doubled until the voter catches up to the rollback height of votes.
+doubled until the validator catches up to the rollback height of votes.
 
 For example, a vote stack with the following state:
 
@@ -89,67 +111,123 @@ votes.
 
 ### Slashing and Rewards
 
-The purpose of the lockout is to force a voter to commit opportunity cost to a
-specific fork.  Voters that violate the lockouts and vote for a diverging fork
-within the lockout should be punished.  Slashing or simply freezing the voter
-from rewards for a long period of time can be used as punishment.
-
-Voters should be rewarded for selecting the fork that the rest of the network
-selected as often as possible.  This is well-aligned with generating a reward
-when the vote stack is full and the oldest vote needs to be dequeued.  Thus a
-reward should be generated for each successful dequeue.
+Validators should be rewarded for selecting the fork that the rest of the
+cluster selected as often as possible.  This is well-aligned with generating a
+reward when the vote stack is full and the oldest vote needs to be dequeued.
+Thus a reward should be generated for each successful dequeue.
 
 ### Cost of Rollback
 
 Cost of rollback of *fork A* is defined as the cost in terms of lockout time to
-the validators to confirm any other fork that does not include *fork A* as an
+the validator to confirm any other fork that does not include *fork A* as an
 ancestor.
 
 The **Economic Finality** of *fork A* can be calculated as the loss of all the
-rewards from rollback of *fork A* and its descendants, plus the opportunity
-cost of reward due to the exponentially growing lockout of the votes that have
+rewards from rollback of *fork A* and its descendants, plus the opportunity cost
+of reward due to the exponentially growing lockout of the votes that have
 confirmed *fork A*.
 
 ### Thresholds
 
-Each voter can independently set a threshold of network commitment to a fork
-before that voter commits to a fork.  For example, at vote stack index 7, the
-lockout is 256 time units.  A voter may withhold votes and let votes 0-7 expire
-unless the vote at index 7 has at greater than 50% commitment in the network.
-This allows each voter to independently control how much risk to commit to a
-fork.  Committing to forks at a higher frequency would allow the voter to earn
-more rewards.
+Each validator can independently set a threshold of cluster commitment to a fork
+before that validator commits to a fork.  For example, at vote stack index 7,
+the lockout is 256 time units.  A validator may withhold votes and let votes 0-7
+expire unless the vote at index 7 has at greater than 50% commitment in the
+cluster.  This allows each validator to independently control how much risk to
+commit to a fork.  Committing to forks at a higher frequency would allow the
+validator to earn more rewards.
 
 ### Algorithm parameters
 
-These parameters need to be tuned.
+The following parameters need to be tuned:
 
 * Number of votes in the stack before dequeue occurs (32).
+
 * Rate of growth for lockouts in the stack (2x).
+
 * Starting default lockout (2).
-* Threshold depth for minimum network commitment before committing to the fork
-  (8).
-* Minimum network commitment size at threshold depth (50%+).
+
+* Threshold depth for minimum cluster commitment before committing to the fork
+(8).
+
+* Minimum cluster commitment size at threshold depth (50%+).
 
 ### Free Choice
 
-A "Free Choice" is an unenforcible voter action.  A voter that maximizes
-self-reward over all possible futures should behave in such a way that the
-system is stable, and the local greedy choice should result in a greedy choice
-over all possible futures.  A set of voter that are engaging in choices to
-disrupt the protocol should be bound by their stake weight to the denial of
-service.  Two options exits for voter:
+A "Free Choice" is an unenforcible validator action.  There is no way for the
+protocol to encode and enforce these actions since each validator can modify the
+code and adjust the algorithm.  A validator that maximizes self-reward over all
+possible futures should behave in such a way that the system is stable, and the
+local greedy choice should result in a greedy choice over all possible futures.
+A set of validator that are engaging in choices to disrupt the protocol should
+be bound by their stake weight to the denial of service.  Two options exits for
+validator:
 
-* a voter can outrun previous voters in virtual generation and submit a
+* a validator can outrun previous validator in virtual generation and submit a
   concurrent fork
-* a voter can withhold a vote to observe multiple forks before voting
 
-In both cases, the voters in the network have several forks to pick from
+* a validator can withhold a vote to observe multiple forks before voting
+
+In both cases, the validator in the cluster have several forks to pick from
 concurrently, even though each fork represents a different height.  In both
-cases it is impossible for the protocol to detect if the voter behavior is
+cases it is impossible for the protocol to detect if the validator behavior is
 intentional or not.
 
 ### Greedy Choice for Concurrent Forks
 
-When evaluating multiple forks, each voter should pick the fork that will
-maximize economic finality for the network, or the latest fork if all are equal.
+When evaluating multiple forks, each validator should use the following rules:
+
+1. Forks must satisfy the *Threshold* rule.
+
+2. Pick the fork that maximizes the total cluster lockout time for all the
+ancestor forks.
+
+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](book/src/staking-rewards.md) section.
+
+## PoH ASIC Resistance
+
+Votes and lockouts grow exponentially while ASIC speed up is linear.  There are
+two possible attack vectors involving a faster ASIC.
+
+### ASIC censorship
+
+An attacker generates a concurrent fork that outruns previous leaders in an
+effort to censor them. A fork proposed by this attacker will be available
+concurrently with the next available leader.  For nodes to pick this fork it
+must satisfy the *Greedy Choice* rule.
+
+1. Fork must have equal number of votes for the ancestor fork.
+
+2. Fork cannot be so far a head as to cause expired votes.
+
+3. Fork must have a greater amount of cluster transaction fees.
+
+This attack is then limited to censoring the previous leaders fees, and
+individual transactions.  But it cannot halt the cluster, or reduce the
+validator set compared to the concurrent fork.  Fee censorship is limited to
+access fees going to the leaders but not the validators.
+
+### ASIC Rollback
+
+An attacker generates a concurrent fork from an older block to try to rollback
+the cluster.  In this attack the concurrent fork is competing with forks that
+have already been voted on.  This attack is limited by the exponential growth of
+the lockouts.
+
+* 1 vote has a lockout of 2 slots.  Concurrent fork must be at least 2 slots
+ahead, and be produced in 1 slot. Therefore requires an ASIC 2x faster.
+
+* 2 votes have a lockout of 4 slots.  Concurrent fork must be at least 4 slots
+ahead and produced in 2 slots. Therefore requires an ASIC 2x faster.
+
+* 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/getting-started.md

@@ -41,6 +41,12 @@ $ git checkout $TAG
 
 ### Configuration Setup
 
+Ensure important programs such as the vote program are built before any
+nodes are started
+```bash
+$ cargo build --all
+```
+
 The network is initialized with a genesis ledger and fullnode configuration files.
 These files can be generated by running the following script.
 
@@ -155,100 +161,8 @@ This will dump all the threads stack traces into gdb.txt
 In this example the client connects to our public testnet. To run validators on the testnet you would need to open udp ports `8000-10000`.
 
 ```bash
-$ ./multinode-demo/client.sh --network $(dig +short testnet.solana.com):8001 --duration 60
+$ ./multinode-demo/client.sh --network testnet.solana.com:8001 --duration 60
 ```
 
 You can observe the effects of your client's transactions on our [dashboard](https://metrics.solana.com:3000/d/testnet/testnet-hud?orgId=2&from=now-30m&to=now&refresh=5s&var-testnet=testnet)
 
-## Linux Snap
-
-A Linux [Snap](https://snapcraft.io/) is available, which can be used to easily
-get Solana running on supported Linux systems without building anything from
-source for evaluation.  Note that CUDA is not supported by the Snap so
-performance will be limited.
-
-The `edge` Snap channel is updated daily with the latest
-development from the `master` branch.  To install:
-
-```bash
-$ sudo snap install solana --edge --devmode
-```
-
-Once installed the usual Solana programs will be available as `solona.*` instead
-of `solana-*`.  For example, `solana.fullnode` instead of `solana-fullnode`.
-
-Update to the latest version at any time with:
-
-```bash
-$ snap info solana
-$ sudo snap refresh solana --devmode
-```
-
-### Daemon Support
-The snap supports running fullnodes and a drone as system daemons.
-
-Run `sudo snap get solana` to view the current daemon configuration.  To view
-daemon logs:
-1. Run `sudo snap logs -n=all solana` to view the daemon initialization log
-2. Runtime logging can be found under `/var/snap/solana/current/bootstrap-leader/`,
-`/var/snap/solana/current/fullnode/`, or `/var/snap/solana/current/drone/` depending
-on which `mode=` was selected.  Within each log directory the file `current`
-contains the latest log, and the files `*.s` (if present) contain older rotated
-logs.
-
-Disable the daemon at any time by running:
-
-```bash
-$ sudo snap set solana mode=
-```
-
-Runtime configuration files for the daemon can be found in
-`/var/snap/solana/current/config`.
-
-#### Leader Daemon
-
-```bash
-$ sudo snap set solana mode=bootstrap-leader
-```
-
-`rsync` must be configured and running on the leader.
-
-1. Ensure rsync is installed with `sudo apt-get -y install rsync`
-2. Edit `/etc/rsyncd.conf` to include the following
-```ini
-[config]
-path = /var/snap/solana/current/config
-hosts allow = *
-read only = true
-```
-3. Run `sudo systemctl enable rsync; sudo systemctl start rsync`
-4. Test by running `rsync -Pzravv rsync://<ip-address-of-leader>/config
-solana-config` from another machine.  **If the leader is running on a cloud
-provider it may be necessary to configure the Firewall rules to permit ingress
-to port tcp:873, tcp:9900 and the port range udp:8000-udp:10000**
-
-
-To run both the Leader and Drone:
-
-```bash
-$ sudo snap set solana mode=bootstrap-leader+drone
-
-```
-
-#### Validator daemon
-
-```bash
-$ sudo snap set solana mode=fullnode
-
-```
-
-By default the node will attempt to connect to **testnet.solana.com**, override the
-cluster entrypoint IP address by running:
-
-```bash
-$ sudo snap set solana mode=fullnode entrypoint-ip=127.0.0.1 #<-- change IP address
-```
-
-It's assumed that the node at the entrypoint IP will be running `rsync`
-configured as described in the previous **Leader daemon** section.
-

book/src/gossip.md

@@ -77,3 +77,52 @@ Nodes retain prior versions of values (those updated by a pull or push) and
 expired values (those older than `GOSSIP_PULL_CRDS_TIMEOUT_MS`) in
 `purged_values` (things I recently had).  Nodes purge `purged_values` that are
 older than `5 * GOSSIP_PULL_CRDS_TIMEOUT_MS`.
+
+## Eclipse Attacks
+
+An eclipse attack is an attempt to take over the set of node connections with
+adversarial endpoints.
+
+This is relevant to our implementation in the following ways.
+
+* Pull messages select a random node from the network.  An eclipse attack on
+*pull* would require an attacker to influence the random selection in such a way
+that only adversarial nodes are selected for pull.
+
+* Push messages maintain an active set of nodes and select a random fanout for
+every push message.  An eclipse attack on *push* would influence the active set
+selection, or the random fanout selection.
+
+### Time and Stake based weights
+
+Weights are calculated based on `time since last picked` and the `natural log` of the `stake weight`.
+
+Taking the `ln` of the stake weight allows giving all nodes a fairer chance of network
+coverage in a reasonable amount of time. It helps normalize the large possible `stake weight` differences between nodes.
+This way a node with low `stake weight`, compared to a node with large `stake weight` will only have to wait a
+few multiples of ln(`stake`) seconds before it gets picked.
+
+There is no way for an adversary to influence these parameters.
+
+### Pull Message
+
+A node is selected as a pull target based on the weights described above.
+
+### Push Message
+
+A prune message can only remove an adversary from a potential connection.
+
+Just like *pull message*, nodes are selected into the active set based on weights.
+
+## Notable differences from PlumTree
+
+The active push protocol described here is based on (Plum
+Tree)[https://haslab.uminho.pt/jop/files/lpr07a.pdf].  The main differences are:
+
+* Push messages have a wallclock that is signed by the originator.  Once the
+wallclock expires the message is dropped.  A hop limit is difficult to implement
+in an adversarial setting.
+
+* Lazy Push is not implemented because its not obvious how to prevent an
+adversary from forging the message fingerprint.  A naive approach would allow an
+adversary to be prioritized for pull based on their input.

book/src/implemented-proposals.md

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

book/src/installer.md

@@ -0,0 +1,213 @@
+## Cluster Software Installation and Updates
+Currently users are required to build the solana cluster software themselves
+from the git repository and manually update it, which is error prone and
+inconvenient.
+
+This document proposes an easy to use software install and updater that can be
+used to deploy pre-built binaries for supported platforms.  Users may elect to
+use binaries supplied by Solana or any other party they trust.  Deployment of
+updates is managed using an on-chain update manifest program.
+
+### Motivating Examples
+#### Fetch and run a pre-built installer using a bootstrap curl/shell script
+The easiest install method for supported platforms:
+```bash
+$ curl -sSf https://raw.githubusercontent.com/solana-labs/solana/v0.13.0/install/solana-install-init.sh | sh
+```
+
+This script will check github for the latest tagged release and download and run the
+`solana-install` binary from there.
+
+
+If additional arguments need to be specified during the installation, the
+following shell syntax is used:
+```bash
+$ init_args=.... # arguments for `solana-installer init ...`
+$ curl -sSf https://raw.githubusercontent.com/solana-labs/solana/v0.13.0/install/solana-install-init.sh | sh -s - ${init_args}
+```
+
+#### Fetch and run a pre-built installer from a Github release
+With a well-known release URL, a pre-built binary can be obtained for supported
+platforms:
+
+```bash
+$ curl -o solana-install https://github.com/solana-labs/solana/releases/download/v0.13.0/solana-install-x86_64-apple-darwin
+$ chmod +x ./solana-install
+$ ./solana-install --help
+```
+
+#### Build and run the installer from source
+If a pre-built binary is not available for a given platform, building the
+installer from source is always an option:
+```bash
+$ git clone https://github.com/solana-labs/solana.git
+$ cd solana/install
+$ cargo run -- --help
+```
+
+#### Deploy a new update to a cluster
+Given a solana release tarball (as created by `ci/publish-tarball.sh`) that has already been uploaded to a publicly accessible URL,
+the following commands will deploy the update:
+```bash
+$ solana-keygen -o update-manifest.json  # <-- only generated once, the public key is shared with users
+$ solana-install deploy http://example.com/path/to/solana-release.tar.bz2 update-manifest.json
+```
+
+#### Run a validator node that auto updates itself
+```bash
+$ solana-install init --pubkey 92DMonmBYXwEMHJ99c9ceRSpAmk9v6i3RdvDdXaVcrfj  # <-- pubkey is obtained from whoever is deploying the updates
+$ export PATH=~/.local/share/solana-install/bin:$PATH
+$ solana-keygen ...  # <-- runs the latest solana-keygen
+$ solana-install run solana-fullnode ...  # <-- runs a fullnode, restarting it as necesary when an update is applied
+```
+
+### On-chain Update Manifest
+An update manifest is used to advertise the deployment of new release tarballs
+on a solana cluster.  The update manifest is stored using the `config` program,
+and each update manifest account describes a logical update channel for a given
+target triple (eg, `x86_64-apple-darwin`).  The account public key is well-known
+between the entity deploying new updates and users consuming those updates.
+
+The update tarball itself is hosted elsewhere, off-chain and can be fetched from
+the specified `download_url`.
+
+```rust,ignore
+use solana_sdk::signature::Signature;
+
+/// Information required to download and apply a given update
+pub struct UpdateManifest {
+    pub timestamp_secs: u64, // When the release was deployed in seconds since UNIX EPOCH
+    pub download_url: String, // Download URL to the release tar.bz2
+    pub download_sha256: String, // SHA256 digest of the release tar.bz2 file
+}
+
+/// Userdata of an Update Manifest program Account.
+#[derive(Serialize, Deserialize, Default, Debug, PartialEq)]
+pub struct SignedUpdateManifest {
+    pub manifest: UpdateManifest,
+    pub manifest_signature: Signature,
+}
+
+```
+
+Note that the `manifest` field itself contains a corresponding signature
+(`manifest_signature`) to guard against man-in-the-middle attacks between the
+`solana-install` tool and the solana cluster RPC API.
+
+To guard against rollback attacks, `solana-install` will refuse to install an
+update with an older `timestamp_secs` than what is currently installed.
+
+### Release Archive Contents
+A release archive is expected to be a tar file compressed with
+bzip2 with the following internal structure:
+
+* `/version.yml` - a simple YAML file containing the field `"target"` - the
+  target tuple.  Any additional fields are ignored.
+* `/bin/` -- directory containing available programs in the release.
+  `solana-install` will symlink this directory to
+  `~/.local/share/solana-install/bin` for use by the `PATH` environment
+  variable.
+* `...` -- any additional files and directories are permitted
+
+### solana-install Tool
+The `solana-install` tool is used by the user to install and update their cluster software.
+
+It manages the following files and directories in the user's home directory:
+* `~/.config/solana/install/config.yml` - user configuration and information about currently installed software version
+* `~/.local/share/solana/install/bin` - a symlink to the current release. eg, `~/.local/share/solana-update/<update-pubkey>-<manifest_signature>/bin`
+* `~/.local/share/solana/install/releases/<download_sha256>/` - contents of a release
+
+#### Command-line Interface
+```manpage
+solana-install 0.13.0
+The solana cluster software installer
+
+USAGE:
+    solana-install [OPTIONS] <SUBCOMMAND>
+
+FLAGS:
+    -h, --help       Prints help information
+    -V, --version    Prints version information
+
+OPTIONS:
+    -c, --config <PATH>    Configuration file to use [default: /Users/mvines/Library/Preferences/solana/install.yml]
+
+SUBCOMMANDS:
+    deploy    deploys a new update
+    help      Prints this message or the help of the given subcommand(s)
+    info      displays information about the current installation
+    init      initializes a new installation
+    run       Runs a program while periodically checking and applying software updates
+    update    checks for an update, and if available downloads and applies it
+```
+
+```manpage
+solana-install-init
+initializes a new installation
+
+USAGE:
+    solana-install init [OPTIONS]
+
+FLAGS:
+    -h, --help    Prints help information
+
+OPTIONS:
+    -d, --data_dir <PATH>    Directory to store install data [default: /Users/mvines/Library/Application Support/solana]
+    -u, --url <URL>          JSON RPC URL for the solana cluster [default: https://api.testnet.solana.com/]
+    -p, --pubkey <PUBKEY>    Public key of the update manifest [default: 9XX329sPuskWhH4DQh6k16c87dHKhXLBZTL3Gxmve8Gp]
+```
+
+```manpage
+solana-install-info
+displays information about the current installation
+
+USAGE:
+    solana-install info [FLAGS]
+
+FLAGS:
+    -h, --help     Prints help information
+    -l, --local    only display local information, don't check the cluster for new updates
+```
+
+```manpage
+solana-install-deploy
+deploys a new update
+
+USAGE:
+    solana-install deploy <download_url> <update_manifest_keypair>
+
+FLAGS:
+    -h, --help    Prints help information
+
+ARGS:
+    <download_url>               URL to the solana release archive
+    <update_manifest_keypair>    Keypair file for the update manifest (/path/to/keypair.json)
+```
+
+```manpage
+solana-install-update
+checks for an update, and if available downloads and applies it
+
+USAGE:
+    solana-install update
+
+FLAGS:
+    -h, --help    Prints help information
+```
+
+```manpage
+solana-install-run
+Runs a program while periodically checking and applying software updates
+
+USAGE:
+    solana-install run <program_name> [program_arguments]...
+
+FLAGS:
+    -h, --help    Prints help information
+
+ARGS:
+    <program_name>            program to run
+    <program_arguments>...    arguments to supply to the program
+
+The program will be restarted upon a successful software update
+```

book/src/introduction.md

@@ -1,20 +1,20 @@
 # What is Solana?
 
-Solana is the name of an open source project that is implementing a new
+Solana is the name of an open source project that is implementing a new,
 high-performance, permissionless blockchain. Solana is also the name of a
 company headquartered in San Francisco that maintains the open source project.
 
 # About this Book
 
 This book describes the Solana open source project, a blockchain built from the
-ground up for scale. The book covers why to use it, how to use it, how it
+ground up for scale. The book covers why it's useful, how to use it, how it
 works, and why it will continue to work long after the company Solana closes
 its doors. The goal of the Solana architecture is to demonstrate there exists a
 set of software algorithms that when used in combination to implement a
 blockchain, removes software as a performance bottleneck, allowing transaction
 throughput to scale proportionally with network bandwidth. The architecture
-goes on to satisfy all three desirable properties of a proper blockchain: that
-it not only be scalable, but that it is also secure and decentralized.
+goes on to satisfy all three desirable properties of a proper blockchain: 
+it is scalable, secure and decentralized.
 
 The architecture describes a theoretical upper bound of 710 thousand
 transactions per second (tps) on a standard gigabit network and 28.4 million
@@ -32,7 +32,7 @@ solicitation for investment.
 
 # History of the Solana Codebase
 
-In November of 2017 Anatoly Yakovenko published a whitepaper describing Proof
+In November of 2017, Anatoly Yakovenko published a whitepaper describing Proof
 of History, a technique for keeping time between computers that do not trust
 one another. From Anatoly's previous experience designing distributed systems
 at Qualcomm, Mesosphere and Dropbox, he knew that a reliable clock makes
@@ -41,13 +41,13 @@ resulting network can be blazing fast, bound only by network bandwidth.
 
 Anatoly watched as blockchain systems without clocks, such as Bitcoin and
 Ethereum, struggled to scale beyond 15 transactions per second worldwide when
-centralized payment systems such as Visa required peaks of 65,000. Without a
+centralized payment systems such as Visa required peaks of 65,000 tps. Without a
 clock, it was clear they'd never graduate to being the global payment system or
-global supercomputer they had dreamed to be. When Anatoly solved the problem of
+global supercomputer most had dreamed them to be. When Anatoly solved the problem of
 getting computers that don’t trust each other to agree on time, he knew he had
 the key to bring 40 years of distributed systems research to the world of
 blockchain. The resulting cluster wouldn't be just 10 times faster, or a 100
-times, or a 1,000 times, but 10,000 times faster right out of the gate!
+times, or a 1,000 times, but 10,000 times faster, right out of the gate!
 
 Anatoly's implementation began in a private codebase and was implemented in the
 C programming language. Greg Fitzgerald, who had previously worked with Anatoly
@@ -72,7 +72,7 @@ Anatoly recruited Greg, Stephen and three others to co-found a company, then
 called Loom.
 
 Around the same time, Ethereum-based project Loom Network sprung up and many
-people were confused if they were the same project. The Loom team decided it
+people were confused about whether they were the same project. The Loom team decided it
 would rebrand. They chose the name Solana, a nod to a small beach town North of
 San Diego called Solana Beach, where Anatoly, Greg and Stephen lived and surfed
 for three years when they worked for Qualcomm. On March 28th, the team created
@@ -81,13 +81,13 @@ Solana.
 
 In June of 2018, the team scaled up the technology to run on cloud-based
 networks and on July 19th, published a 50-node, permissioned, public testnet
-consistently supporting bursts of 250,000 transactions per second. In the most
-recent release, v0.10 Pillbox, the team published a permissioned testnet
+consistently supporting bursts of 250,000 transactions per second. In a later release in 
+December, called v0.10 Pillbox, the team published a permissioned testnet
 running 150 nodes on a gigabit network and demonstrated soak tests processing
 an *average* of 200 thousand transactions per second with bursts over 500
 thousand. The project was also extended to support on-chain programs written in
 the C programming language and run concurrently in a safe execution environment
-called BPF. Next step: going permissionless.
+called BPF. 
 
 # What is a Solana Cluster?
 
@@ -110,7 +110,7 @@ organization that launched it.
 A sol is the name of Solana's native token, which can be passed to nodes in a
 Solana cluster in exchange for running an on-chain program or validating its
 output. The Solana protocol defines that only 1 billion sols will ever exist,
-but that the system may perform micropayments of fractional sols and that a sol
+but that the system may perform micropayments of fractional sols, and that a sol
 may be split as many as 34 times. The fractional sol is called a *lamport*. It
 is named in honor of Solana's biggest technical influence, [Leslie
 Lamport](https://en.wikipedia.org/wiki/Leslie_Lamport). A lamport has a value

book/src/jsonrpc-api.md

@@ -22,10 +22,13 @@ Methods
 ---
 
 * [confirmTransaction](#confirmtransaction)
-* [getBalance](#getbalance)
 * [getAccountInfo](#getaccountinfo)
-* [getLastId](#getlastid)
+* [getBalance](#getbalance)
+* [getClusterNodes](#getclusternodes)
+* [getRecentBlockhash](#getrecentblockhash)
 * [getSignatureStatus](#getsignaturestatus)
+* [getSlotLeader](#getslotleader)
+* [getNumBlocksSinceSignatureConfirmation](#getnumblockssincesignatureconfirmation)
 * [getTransactionCount](#gettransactioncount)
 * [requestAirdrop](#requestairdrop)
 * [sendTransaction](#sendtransaction)
@@ -34,6 +37,8 @@ Methods
 * [Subscription Websocket](#subscription-websocket)
   * [accountSubscribe](#accountsubscribe)
   * [accountUnsubscribe](#accountunsubscribe)
+  * [programSubscribe](#programsubscribe)
+  * [programUnsubscribe](#programunsubscribe)
   * [signatureSubscribe](#signaturesubscribe)
   * [signatureUnsubscribe](#signatureunsubscribe)
 
@@ -111,6 +116,30 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "
 
 ---
 
+### getClusterNodes
+Returns information about all the nodes participating in the cluster
+
+##### Parameters:
+None
+
+##### Results:
+The result field will be an array of JSON objects, each with the following sub fields:
+* `id` - Node identifier, 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","id":"9QzsJf7LPLj8GkXbYT3LFDKqsj2hHG7TA3xinJHu8epQ","rpc":"10.239.6.48:8899","tpu":"10.239.6.48:8856"}],"id":1}
+```
+
+---
+
 ### getAccountInfo
 Returns all information associated with the account of provided Pubkey
 
@@ -120,9 +149,9 @@ Returns all information associated with the account of provided Pubkey
 ##### Results:
 The result field will be a JSON object with the following sub fields:
 
-* `tokens`, number of tokens assigned to this account, as a signed 64-bit integer
+* `lamports`, number of lamports assigned to this account, as a signed 64-bit integer
 * `owner`, array of 32 bytes representing the program this account has been assigned to
-* `userdata`, array of bytes representing any userdata associated with the account
+* `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)
 * `loader`, array of 32 bytes representing the loader for this program (if `executable`), otherwise all
 
@@ -132,24 +161,24 @@ The result field will be a JSON object with the following sub fields:
 curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getAccountInfo", "params":["2gVkYWexTHR5Hb2aLeQN3tnngvWzisFKXDUPrgMHpdST"]}' http://localhost:8899
 
 // Result
-{"jsonrpc":"2.0","result":{"executable":false,"loader":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"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],"tokens":1,"userdata":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]},"id":1}
+{"jsonrpc":"2.0","result":{"executable":false,"loader":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"owner":[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"lamports":1,"data":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]},"id":1}
 ```
 
 ---
 
-### getLastId
-Returns the last entry ID from the ledger
+### getRecentBlockhash
+Returns a recent block hash from the ledger
 
 ##### Parameters:
 None
 
 ##### Results:
-* `string` - the ID of last entry, a Hash as base-58 encoded string
+* `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":"getLastId"}' http://localhost:8899
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getRecentBlockhash"}' http://localhost:8899
 
 // Result
 {"jsonrpc":"2.0","result":"GH7ome3EiwEr7tu9JuTh2dpYWBJK3z69Xm1ZE3MEE6JC","id":1}
@@ -166,12 +195,10 @@ events.
 * `string` - Signature of Transaction to confirm, as base-58 encoded string
 
 ##### Results:
-* `string` - Transaction status:
-    * `Confirmed` - Transaction was successful
-    * `SignatureNotFound` - Unknown transaction
-    * `ProgramRuntimeError` - An error occurred in the program that processed this Transaction
-    * `AccountInUse` - Another Transaction had a write lock one of the Accounts specified in this Transaction.  The Transaction may succeed if retried
-    * `GenericFailure` - Some other error occurred.  **Note**: In the future new Transaction statuses may be added to this list.  It's safe to assume that all new statuses will be more specific error conditions that previously presented as `GenericFailure`
+* `null` - Unknown transaction
+* `object` - Transaction status:
+    * `"Ok": null` - Transaction was successful
+    * `"Err": <ERR>` - Transaction failed with TransactionError <ERR> [TransactionError definitions](https://github.com/solana-labs/solana/blob/master/sdk/src/transaction.rs#L14)
 
 ##### Example:
 ```bash
@@ -182,7 +209,48 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "
 {"jsonrpc":"2.0","result":"SignatureNotFound","id":1}
 ```
 
+-----
+
+### getSlotLeader
+Returns the current slot leader
+
+##### Parameters:
+None
+
+##### Results:
+* `string` - Node Id as base-58 encoded string
+
+##### Example:
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "method":"getSlotLeader"}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":"ENvAW7JScgYq6o4zKZwewtkzzJgDzuJAFxYasvmEQdpS","id":1}
+```
+
+-----
+
+### getNumBlocksSinceSignatureConfirmation
+Returns the current number of blocks since signature has been confirmed.
+
+##### Parameters:
+* `string` - Signature of Transaction to confirm, as base-58 encoded string
+
+##### Results:
+* `integer` - count, as unsigned 64-bit integer
+
+##### Example:
+```bash
+// Request
+curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0", "id":1, "method":"getNumBlocksSinceSignatureConfirmation", "params":["5VERv8NMvzbJMEkV8xnrLkEaWRtSz9CosKDYjCJjBRnbJLgp8uirBgmQpjKhoR4tjF3ZpRzrFmBV6UjKdiSZkQUW"]}' http://localhost:8899
+
+// Result
+{"jsonrpc":"2.0","result":8,"id":1}
+```
+
 ---
+
 ### getTransactionCount
 Returns the current Transaction count from the ledger
 
@@ -204,11 +272,11 @@ curl -X POST -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1, "m
 ---
 
 ### requestAirdrop
-Requests an airdrop of tokens to a Pubkey
+Requests an airdrop of lamports to a Pubkey
 
 ##### Parameters:
-* `string` - Pubkey of account to receive tokens, as base-58 encoded string
-* `integer` - token quantity, as a signed 64-bit integer
+* `string` - Pubkey of account to receive lamports, as base-58 encoded string
+* `integer` - lamports, as a signed 64-bit integer
 
 ##### Results:
 * `string` - Transaction Signature of airdrop, as base-58 encoded string
@@ -252,7 +320,8 @@ After connect to the RPC PubSub websocket at `ws://<ADDRESS>/`:
 ---
 
 ### accountSubscribe
-Subscribe to an account to receive notifications when the userdata for a given account public key changes
+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
@@ -271,13 +340,13 @@ Subscribe to an account to receive notifications when the userdata for a given a
 
 ##### Notification Format:
 ```bash
-{"jsonrpc": "2.0","method": "accountNotification", "params": {"result": {"executable":false,"loader":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"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],"tokens":1,"userdata":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]},"subscription":0}}
+{"jsonrpc": "2.0","method": "accountNotification", "params": {"result": {"executable":false,"loader":[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"owner":[1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"lamports":1,"data":[3,0,0,0,0,0,0,0,1,0,0,0,0,0,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,53,48,45,48,49,45,48,49,84,48,48,58,48,48,58,48,48,90,252,10,7,28,246,140,88,177,98,82,10,227,89,81,18,30,194,101,199,16,11,73,133,20,246,62,114,39,20,113,189,32,50,0,0,0,0,0,0,0,247,15,36,102,167,83,225,42,133,127,82,34,36,224,207,130,109,230,224,188,163,33,213,13,5,117,211,251,65,159,197,51,0,0,0,0,0,0]},"subscription":0}}
 ```
 
 ---
 
 ### accountUnsubscribe
-Unsubscribe from account userdata change notifications
+Unsubscribe from account change notifications
 
 ##### Parameters:
 * `integer` - id of account Subscription to cancel
@@ -296,6 +365,54 @@ Unsubscribe from account userdata change notifications
 
 ---
 
+### 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
+
+##### Results:
+* `integer` - Subscription id (needed to unsubscribe)
+
+##### Example:
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"programSubscribe", "params":["9gZbPtbtHrs6hEWgd6MbVY9VPFtS5Z8xKtnYwA2NynHV"]}
+
+// 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](#getaccountinfo) for field details)
+```bash
+{"jsonrpc":"2.0","method":"programNotification","params":{{"result":["8Rshv2oMkPu5E4opXTRyuyBeZBqQ4S477VG26wUTFxUM",{"executable":false,"lamports":1,"owner":[129,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],"data":[1,1,1,0,0,0,0,0,0,0,20,0,0,0,0,0,0,0,50,48,49,56,45,49,50,45,50,52,84,50,51,58,53,57,58,48,48,90,235,233,39,152,15,44,117,176,41,89,100,86,45,61,2,44,251,46,212,37,35,118,163,189,247,84,27,235,178,62,55,89,0,0,0,0,50,0,0,0,0,0,0,0,235,233,39,152,15,44,117,176,41,89,100,86,45,61,2,44,251,46,212,37,35,118,163,189,247,84,27,235,178,62,45,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]}],"subscription":0}}
+```
+
+---
+
+### programUnsubscribe
+Unsubscribe from program-owned account change notifications
+
+##### Parameters:
+* `integer` - id of account Subscription to cancel
+
+##### Results:
+* `bool` - unsubscribe success message
+
+##### Example:
+```bash
+// Request
+{"jsonrpc":"2.0", "id":1, "method":"programUnsubscribe", "params":[0]}
+
+// Result
+{"jsonrpc": "2.0","result": true,"id": 1}
+```
+
+---
+
 ### signatureSubscribe
 Subscribe to a transaction signature to receive notification when the transaction is confirmed
 On `signatureNotification`, the subscription is automatically cancelled
@@ -323,10 +440,10 @@ On `signatureNotification`, the subscription is automatically cancelled
 ---
 
 ### signatureUnsubscribe
-Unsubscribe from account userdata change notifications
+Unsubscribe from signature confirmation notification
 
 ##### Parameters:
-* `integer` - id of account subscription to cancel
+* `integer` - subscription id to cancel
 
 ##### Results:
 * `bool` - unsubscribe success message

book/src/leader-leader-transition.md

@@ -0,0 +1,101 @@
+# Leader to Leader Transition
+
+This design describes how leaders transition production of the PoH ledger
+between each other as each leader generates its own slot.
+
+## Challenges
+
+Current leader and the next leader are both racing to generate the final tick
+for the current slot.  The next leader may arrive at that slot while still
+processing the current leader's entries.
+
+The ideal scenario would be that the next leader generated its own slot right
+after it was able to vote for the current leader.  It is very likely that the
+next leader will arrive at their PoH slot height before the current leader
+finishes broadcasting the entire block.
+
+The next leader has to make the decision of attaching its own block to the last
+completed block, or wait to finalize the pending block.  It is possible that the
+next leader will produce a block that proposes that the current leader failed,
+even though the rest of the network observes that block succeeding.
+
+The current leader has incentives to start its slot as early as possible to
+capture economic rewards.  Those incentives need to be balanced by the leader's
+need to attach its block to a block that has the most commitment from the rest
+of the network.
+
+## Leader timeout
+
+While a leader is actively receiving entries for the previous slot, the leader
+can delay broadcasting the start of its block in real time.  The delay is
+locally configurable by each leader, and can be dynamically based on the
+previous leader's behavior.  If the previous leader's block is confirmed by the
+leader's TVU before the timeout, the PoH is reset to the start of the slot and
+this leader produces its block immediately.
+
+The downsides:
+
+* Leader delays its own slot, potentially allowing the next leader more time to
+catch up.
+
+The upsides compared to guards:
+
+* All the space in a block is used for entries.
+
+* The timeout is not fixed.
+
+* The timeout is local to the leader, and therefore can be clever.  The leader's
+heuristic can take into account avalanche performance.
+
+* This design doesn't require a ledger hard fork to update.
+
+* The previous leader can redundantly transmit the last entry in the block to
+the next leader, and the next leader can speculatively decide to trust it to
+generate its block without verification of the previous block.
+
+* The leader can speculatively generate the last tick from the last received
+entry.
+
+* The leader can speculatively process transactions and guess which ones are not
+going to be encoded by the previous leader.  This is also a censorship attack
+vector.  The current leader may withhold transactions that it receives from the
+clients so it can encode them into its own slot. Once processed, entries can be
+replayed into PoH quickly.
+
+## Alternative design options
+
+### Guard tick at the end of the slot
+
+A leader does not produce entries in its block after the *penultimate tick*,
+which is the last tick before the first tick of the next slot.  The network
+votes on the *last tick*, so the time difference between the *penultimate tick*
+and the *last tick* is the forced delay for the entire network, as well as the
+next leader before a new slot can be generated.  The network can produce the
+*last tick* from the *penultimate tick*.
+
+If the next leader receives the *penultimate tick* before it produces its own
+*first tick*, it will reset its PoH and produce the *first tick* from the
+previous leader's *penultimate tick*.  The rest of the network will also reset
+its PoH to produce the *last tick* as the id to vote on.
+
+The downsides:
+
+* Every vote, and therefore confirmation, is delayed by a fixed timeout. 1 tick,
+or around 100ms.
+
+* Average case confirmation time for a transaction would be at least 50ms worse.
+
+* It is part of the ledger definition, so to change this behavior would require
+a hard fork.
+
+* Not all the available space is used for entries.
+
+The upsides compared to leader timeout:
+
+* The next leader has received all the previous entries, so it can start
+processing transactions without recording them into PoH.
+
+* The previous leader can redundantly transmit the last entry containing the
+*penultimate tick* to the next leader.  The next leader can speculatively
+generate the *last tick* as soon as it receives the *penultimate tick*, even
+before verifying it.

book/src/leader-rotation.md

@@ -3,17 +3,102 @@
 At any given moment, a cluster expects only one fullnode to produce ledger
 entries. By having only one leader at a time, all validators are able to replay
 identical copies of the ledger. The drawback of only one leader at a time,
-however, is that a malicious leader is cabable of censoring votes and
+however, is that a malicious leader is capable of censoring votes and
 transactions. Since censoring cannot be distinguished from the network dropping
 packets, the cluster cannot simply elect a single node to hold the leader role
-indefinitely. Instead, the cluster minimizes the influence of a malcioius
+indefinitely. Instead, the cluster minimizes the influence of a malicious
 leader by rotating which node takes the lead.
 
 Each validator selects the expected leader using the same algorithm, described
 below. When the validator receives a new signed ledger entry, it can be certain
-that entry was produced by the expected leader.
+that entry was produced by the expected leader.  The order of slots which each
+leader is assigned a slot is called a *leader schedule*.
 
-## Leader Schedule Generation
+## Leader Schedule Rotation
+
+A validator rejects blocks that are not signed by the *slot leader*.  The list
+of identities of all slot leaders is called a *leader schedule*. The leader
+schedule is recomputed locally and periodically. It assigns slot leaders for a
+duration of time called an _epoch_. The schedule must be computed far in advance
+of the slots it assigns, such that the ledger state it uses to compute the
+schedule is finalized. That duration is called the *leader schedule offset*.
+Solana sets the offset to the duration of slots until the next epoch. That is,
+the leader schedule for an epoch is calculated from the ledger state at the
+start of the previous epoch. The offset of one epoch is fairly arbitrary and
+assumed to be sufficiently long such that all validators will have finalized
+their ledger state before the next schedule is generated. A cluster may choose
+to shorten the offset to reduce the time between stake changes and leader
+schedule updates.
+
+While operating without partitions lasting longer than an epoch, the schedule
+only needs to be generated when the root fork crosses the epoch boundary.  Since
+the schedule is for the next epoch, any new stakes committed to the root fork
+will not be active until the next epoch.  The block used for generating the
+leader schedule is the first block to cross the epoch boundary.
+
+Without a partition lasting longer than an epoch, the cluster will work as
+follows:
+
+1. A validator continuously updates its own root fork as it votes.
+
+2. The validator updates its leader schedule each time the slot height crosses
+an epoch boundary.
+
+For example:
+
+The epoch duration is 100 slots. The root fork is updated from fork computed at
+slot height 99 to a fork computed at slot height 102. Forks with slots at height
+100,101 were skipped because of failures.  The new leader schedule is computed
+using fork at slot height 102.  It is active from slot 200 until it is updated
+again.
+
+No inconsistency can exist because every validator that is voting with the
+cluster has skipped 100 and 101 when its root passes 102.  All validators,
+regardless of voting pattern, would be committing to a root that is either 102,
+or a descendant of 102.
+
+### Leader Schedule Rotation with Epoch Sized Partitions.
+
+The duration of the leader schedule offset has a direct relationship to the
+likelihood of a cluster having an inconsistent view of the correct leader
+schedule.
+
+Consider the following scenario:
+
+Two partitions that are generating half of the blocks each.  Neither is coming
+to a definitive supermajority fork.  Both will cross epoch 100 and 200 without
+actually committing to a root and therefore a cluster wide commitment to a new
+leader schedule.
+
+In this unstable scenario, multiple valid leader schedules exist.
+
+* A leader schedule is generated for every fork whose direct parent is in the
+previous epoch.
+
+* The leader schedule is valid after the start of the next epoch for descendant
+forks until it is updated.
+
+Each partition's schedule will diverge after the partition lasts more than an
+epoch.  For this reason, the epoch duration should be selected to be much much
+larger then slot time and the expected length for a fork to be committed to
+root.
+
+After observing the cluster for a sufficient amount of time, the leader schedule
+offset can be selected based on the median partition duration and its standard
+deviation.  For example, an offset longer then the median partition duration
+plus six standard deviations would reduce the likelihood of an inconsistent
+ledger schedule in the cluster to 1 in 1 million.
+ 
+## Leader Schedule Generation at Genesis
+
+The genesis block declares the first leader for the first epoch.  This leader
+ends up scheduled for the first two epochs because the leader schedule is also
+generated at slot 0 for the next epoch.  The length of the first two epochs can
+be specified in the genesis block as well.  The minimum length of the first
+epochs must be greater than or equal to the maximum rollback depth as defined in
+[fork selection](fork-selection.md).
+
+## Leader Schedule Generation Algorithm
 
 Leader schedule is generated using a predefined seed.  The process is as follows:
 
@@ -27,12 +112,42 @@ Leader schedule is generated using a predefined seed.  The process is as follows
    stake-weighted ordering.
 5. This ordering becomes valid after a cluster-configured number of ticks.
 
+## Schedule Attack Vectors
+
+### Seed
+
 The seed that is selected is predictable but unbiasable.  There is no grinding
-attack to influence its outcome. The active set, however, can be biased by a
-leader by censoring validator votes. To reduce the likelihood of censorship,
-the active set is sampled many slots in advance, such that votes will have been
-collected by multiple leaders. If even one node is honest, the malicious
-leaders will not be able to use censorship to influence the leader schedule.
+attack to influence its outcome. 
+
+### Active Set
+
+A leader can bias the active set by censoring validator votes.  Two possible
+ways exist for leaders to censor the active set:
+
+* Ignore votes from validators 
+* Refuse to vote for blocks with votes from validators
+
+To reduce the likelihood of censorship, the active set is calculated at the
+leader schedule offset boundary over an *active set sampling duration*. The
+active set sampling duration is long enough such that votes will have been
+collected by multiple leaders.
+
+### Staking
+
+Leaders can censor new staking transactions or refuse to validate blocks with
+new stakes.  This attack is similar to censorship of validator votes.
+
+### Validator operational key loss
+
+Leaders and validators are expected to use ephemeral keys for operation, and
+stake owners authorize the validators to do work with their stake via
+delegation.
+
+The cluster should be able to recover from the loss of all the ephemeral keys
+used by leaders and validators, which could occur through a common software
+vulnerability shared by all the nodes.  Stake owners should be able to vote
+directly co-sign a validator vote even though the stake is currently delegated
+to a validator.
 
 ## Appending Entries
 

book/src/leader-validator-transition.md

@@ -0,0 +1,84 @@
+# Leader-to-Validator Transition
+
+A fullnode typically operates as a validator. If, however, a staker delegates
+its stake to a fullnode, it will occasionally be selected as a *slot leader*.
+As a slot leader, the fullnode is responsible for producing blocks during an
+assigned *slot*. A slot has a duration of some number of preconfigured *ticks*.
+The duration of those ticks are estimated with a *PoH Recorder* described later
+in this document.
+
+## BankFork
+
+BankFork tracks changes to the bank state over a specific slot.  Once the final
+tick has been registered the state is frozen. Any attempts to write to are
+rejected.
+
+## Validator
+
+A validator operates on many different concurrent forks of the bank state until
+it generates a PoH hash with a height within its leader slot.
+
+## Slot Leader
+
+A slot leader builds blocks on top of only one fork, the one it last voted on.
+
+## PoH Recorder
+
+Slot leaders and validators use a PoH Recorder for both estimating slot height
+and for recording transactions.
+
+### PoH Recorder when Validating
+
+The PoH Recorder acts as a simple VDF when validating. It tells the validator
+when it needs to switch to the slot leader role. Every time the validator votes
+on a fork, it should use the fork's latest block id to re-seed the VDF.
+Re-seeding solves two problems. First, it synchronizes its VDF to the leader's,
+allowing it to more accurately determine when its leader slot begins. Second,
+if the previous leader goes down, all wallclock time is accounted for in the
+next leader's PoH stream. For example, if one block is missing when the leader
+starts, the block it produces should have a PoH duration of two blocks. The
+longer duration ensures the following leader isn't attempting to snip all the
+transactions from the previous leader's slot.
+
+### PoH Recorder when Leading
+
+A slot leader use the PoH Recorder to record transactions, locking their
+positions in time. The PoH hash must be derived from a previous leader's last
+block.  If it isn't, its block will fail PoH verification and be rejected by
+the cluster.
+
+The PoH Recorder also serves to inform the slot leader when its slot is over.
+The leader needs to take care not to modify its bank if recording the
+transaction would generate a PoH height outside its designated slot.  The
+leader, therefore, should not commit account changes until after it generates
+the entry's PoH hash. When the PoH height falls outside its slot any
+transactions in its pipeline may be dropped or forwarded to the next leader.
+Forwarding is preferred, as it would minimize network congestion, allowing the
+cluster to advertise higher TPS capacity.
+
+
+## Fullnode Loop
+
+The PoH Recorder manages the transition between modes. Once a ledger is
+replayed, the validator can run until the recorder indicates it should be
+the slot leader. As a slot leader, the node can then execute and record
+transactions.
+
+The loop is synchronized to PoH and does a synchronous start and stop of the
+slot leader functionality. After stopping, the validator's TVU should find
+itself in the same state as if a different leader had sent it the same block.
+The following is pseudocode for the loop:
+
+1. Query the LeaderScheduler for the next assigned slot.
+2. Run the TVU over all the forks.
+   1. TVU will send votes to what it believes is the "best" fork.
+   2. After each vote, restart the PoH Recorder to run until the next assigned
+slot.
+3. When time to be a slot leader, start the TPU. Point it to the last fork the
+   TVU voted on.
+4. Produce entries until the end of the slot.
+   1. For the duration of the slot, the TVU must not vote on other forks.
+   2. After the slot ends, the TPU freezes its BankFork. After freezing,
+      the TVU may resume voting.
+5. Goto 1.
+

book/src/ledger-replication-to-implement.md

@@ -0,0 +1,39 @@
+# Ledger Replication
+
+Replication behavior yet to be implemented.
+
+### Validator behavior
+
+3. Every NUM\_KEY\_ROTATION\_TICKS it also validates samples received from
+replicators. It signs the PoH hash at that point and uses the following
+algorithm with the signature as the input:
+     - The low 5 bits of the first byte of the signature creates an index into
+       another starting byte of the signature.
+     - The validator then looks at the set of storage proofs where the byte of
+       the proof's sha state vector starting from the low byte matches exactly
+with the chosen byte(s) of the signature.
+     - If the set of proofs is larger than the validator can handle, then it
+       increases to matching 2 bytes in the signature.
+     - Validator continues to increase the number of matching bytes until a
+       workable set is found.
+     - It then creates a mask of valid proofs and fake proofs and sends it to
+       the leader. This is a storage proof confirmation transaction.
+5. After a lockout period of NUM\_SECONDS\_STORAGE\_LOCKOUT seconds, the
+validator then submits a storage proof claim transaction which then causes the
+distribution of the storage reward if no challenges were seen for the proof to
+the validators and replicators party to the proofs.
+
+### Replicator behavior
+
+9. The replicator then generates another set of offsets which it submits a fake
+proof with an incorrect sha state. It can be proven to be fake by providing the
+seed for the hash result.
+     - A fake proof should consist of a replicator hash of a signature of a PoH
+       value. That way when the replicator reveals the fake proof, it can be
+verified on chain.
+10. The replicator monitors the ledger, if it sees a fake proof integrated, it
+creates a challenge transaction and submits it to the current leader. The
+transacation proves the validator incorrectly validated a fake storage proof.
+The replicator is rewarded and the validator's staking balance is slashed or
+frozen.
+

book/src/ledger-replication.md

@@ -15,55 +15,6 @@ proof and it also requires the validator to have the entirety of the encrypted
 data present for verification of every proof of every identity. So the space
 required to validate is `number_of_proofs * data_size`
 
-## Terminology
-
-#### replicator
-
-Storage mining client, stores some part of the ledger enumerated in blocks and
-submits storage proofs to the chain. Not a full-node.
-
-#### ledger segment
-
-Portion of the ledger which is downloaded by the replicator where storage proof
-data is derived.
-
-#### CBC block
-
-Smallest encrypted chunk of ledger, an encrypted ledger segment would be made of
-many CBC blocks. `ledger_segment_size / cbc_block_size` to be exact.
-
-#### storage proof
-
-A set of sha hash state which is constructed by sampling the encrypted version
-of the stored ledger segment at certain offsets.
-
-#### fake storage proof
-
-A proof which has the same format as a storage proof, but the sha state is
-actually from hashing a known ledger value which the storage client can reveal
-and is also easily verifiable by the network on-chain.
-
-#### storage proof confirmation
-
-A transaction by a validator which indicates the set of real and fake proofs
-submitted by a storage miner. The transaction would contain a list of proof
-hash values and a bit which says if this hash is valid or fake.
-
-#### storage proof challenge
-
-A transaction from a replicator that verifiably proves that a validator
-confirmed a fake proof.
-
-#### storage proof claim
-
-A transaction from a validator which is after the timeout period given from the
-storage proof confirmation and which no successful challenges have been
-observed which rewards the parties of the storage proofs and confirmations.
-
-#### storage validation capacity
-
-The number of keys and samples that a validator can verify each storage epoch.
-
 ## Optimization with PoH
 
 Our improvement on this approach is to randomly sample the encrypted segments
@@ -72,7 +23,7 @@ PoH ledger. Thus the segments stay in the exact same order for every PoRep and
 verification can stream the data and verify all the proofs in a single batch.
 This way we can verify multiple proofs concurrently, each one on its own CUDA
 core. The total space required for verification is `1_ledger_segment +
-2_cbc_blocks * number_of_identities` with core count of equal to
+2_cbc_blocks * number_of_identities` with core count equal to
 `number_of_identities`. We use a 64-byte chacha CBC block size.
 
 ## Network
@@ -123,25 +74,8 @@ transaction which tells the network how many proofs it can process in a given
 period defined by NUM\_KEY\_ROTATION\_TICKS.
 2. Every NUM\_KEY\_ROTATION\_TICKS the validator stores the PoH value at that
 height.
-3. Every NUM\_KEY\_ROTATION\_TICKS it also validates samples received from
-replicators. It signs the PoH hash at that point and uses the following
-algorithm with the signature as the input:
-     - The low 5 bits of the first byte of the signature creates an index into
-       another starting byte of the signature.
-     - The validator then looks at the set of storage proofs where the byte of
-       the proof's sha state vector starting from the low byte matches exactly
-with the chosen byte(s) of the signature.
-     - If the set of proofs is larger than the validator can handle, then it
-       increases to matching 2 bytes in the signature.
-     - Validator continues to increase the number of matching bytes until a
-       workable set is found.
-     - It then creates a mask of valid proofs and fake proofs and sends it to
-       the leader. This is a storage proof confirmation transaction.
+3. Validator generates a storage proof confirmation transaction.
 4. The storage proof confirmation transaction is integrated into the ledger.
-5. After a lockout period of NUM\_SECONDS\_STORAGE\_LOCKOUT seconds, the
-validator then submits a storage proof claim transaction which then causes the
-distribution of the storage reward if no challenges were seen for the proof to
-the validators and replicators party to the proofs.
 6. Validator responds to RPC interfaces for what the last storage epoch PoH
 value is and its entry\_height.
 
@@ -152,7 +86,7 @@ ledger data, they have to rely on other full nodes (validators) for
 information. Any given validator may or may not be malicious and give incorrect
 information, although there are not any obvious attack vectors that this could
 accomplish besides having the replicator do extra wasted work.  For many of the
-operations there are number of options depending on how paranoid a replicator
+operations there are a number of options depending on how paranoid a replicator
 is:
     - (a) replicator can ask a validator
     - (b) replicator can ask multiple validators
@@ -179,17 +113,7 @@ segment.
 8. The replicator sends a PoRep proof transaction which contains its sha state
 at the end of the sampling operation, its seed and the samples it used to the
 current leader and it is put onto the ledger.
-9. The replicator then generates another set of offsets which it submits a fake
-proof with an incorrect sha state. It can be proven to be fake by providing the
-seed for the hash result.
-     - A fake proof should consist of a replicator hash of a signature of a PoH
-       value. That way when the replicator reveals the fake proof, it can be
-verified on chain.
-10. The replicator monitors the ledger, if it sees a fake proof integrated, it
-creates a challenge transaction and submits it to the current leader. The
-transacation proves the validator incorrectly validated a fake storage proof.
-The replicator is rewarded and the validator's staking balance is slashed or
-frozen.
+
 
 ### Finding who has a given block of ledger
 

book/src/managing-forks.md

@@ -0,0 +1,63 @@
+# Managing Forks in the Ledger
+
+The ledger is permitted to fork at slot boundaries. The resulting data
+structure forms a tree called a *blocktree*. When the fullnode interprets the
+blocktree, it must maintain state for each fork in the chain. We call each
+instance an *active fork*.  It is the responsibility of a fullnode to weigh
+those forks, such that it may eventually select a fork.
+
+A fullnode selects a fork by submiting a vote to a slot leader on that fork.
+The vote commits the fullnode for a duration of time called a *lockout period*.
+The fullnode is not permitted to vote on a different fork until that lockout
+period expires. Each subsequent vote on the same fork doubles the length of the
+lockout period. After some cluster-configured number of votes (currently 32),
+the length of the lockout period reaches what's called *max lockout*. Until the
+max lockout is reached, the fullnode has the option to wait until the lockout
+period is over and then vote on another fork. When it votes on another fork, it
+performs a operation called *rollback*, whereby the state rolls back in time to
+a shared checkpoint and then jumps forward to the tip of the fork that it just
+voted on. The maximum distance that a fork may roll back is called the
+*rollback depth*. Rollback depth is the number of votes required to achieve
+max lockout. Whenever a fullnode votes, any checkpoints beyond the rollback
+depth become unreachable. That is, there is no scenario in which the fullnode
+will need to roll back beyond rollback depth. It therefore may safely *prune*
+unreachable forks and *squash* all checkpoints beyond rollback depth into the
+root checkpoint.
+
+## Active Forks
+
+An active fork is as a sequence of checkpoints that has a length at least one
+longer than the rollback depth. The shortest fork will have a length exactly
+one longer than the rollback depth.  For example:
+
+<img alt="Forks" src="img/forks.svg" class="center"/>
+
+The following sequences are *active forks*:
+
+* {4, 2, 1}
+* {5, 2, 1}
+* {6, 3, 1}
+* {7, 3, 1}
+
+## Pruning and Squashing
+
+A fullnode may vote on any checkpoint in the tree.  In the diagram above,
+that's every node except the leaves of the tree.  After voting, the fullnode
+prunes nodes that fork from a distance farther than the rollback depth and then
+takes the opportunity to minimize its memory usage by squashing any nodes it
+can into the root.
+
+Starting from the example above, wth a rollback depth of 2, consider a vote on
+5 versus a vote on 6. First, a vote on 5:
+
+<img alt="Forks after pruning" src="img/forks-pruned.svg" class="center"/>
+
+The new root is 2, and any active forks that are not descendants from 2 are
+pruned.
+
+Alternatively, a vote on 6:
+
+<img alt="Forks" src="img/forks-pruned2.svg" class="center"/>
+
+The tree remains with a root of 1, since the active fork starting at 6 is only
+2 checkpoints from the root.

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

@@ -0,0 +1,212 @@
+# Stake Delegation and Reward
+
+This design proposal focuses on the software architecture for the on-chain
+voting and staking programs.  Incentives for staking is covered in [staking
+rewards](staking-rewards.md).
+
+The current architecture requires a vote for each delegated stake from the
+validator, and therefore does not scale to allow replicator clients to
+automatically delegate their rewards.
+
+The design proposes a new set of programs for voting and stake delegation, The
+proposed programs allow many stake accounts to passively earn rewards with a
+single validator vote without permission or active involvement from the
+validator.
+
+## Current Design Problems
+
+In the current design each staker creates their own VoteState, and assigns a
+**delegate** in the VoteState that can submit votes.  Since the validator has to
+actively vote for each stake delegated to it, validators can censor stakes by
+not voting for them.
+
+The number of votes is equal to the number of stakers, and not the number of
+validators.  Replicator clients are expected to delegate their replication
+rewards as they are earned, and therefore the number of stakes is expected to be
+large compared to the number of validators in a long running cluster.
+
+## Proposed changes to the current design.
+
+The general idea is that instead of the staker, the validator will own the
+VoteState program. In this proposal the VoteState program is there to track
+validator votes, count validator generated credits and to provide any
+additional validator specific state.  The VoteState program is not aware of any
+stakes delegated to it, and has no staking weight.
+
+The rewards generated are proportional to the amount of lamports staked.  In
+this proposal stake state is stored as part of the StakeState program. This
+program is owned by the staker only.  Lamports stored in this program are the
+stake.  Unlike the current design, this program contains a new field to indicate
+which VoteState program the stake is delegated to.
+
+### VoteState
+
+VoteState is the current state of all the votes the **delegate** has submitted
+to the bank.  VoteState contains the following state information:
+
+* votes - The submitted votes data structure.
+
+* credits - The total number of rewards this vote program has generated over its
+lifetime.
+
+* root\_slot - The last slot to reach the full lockout commitment necessary for
+rewards.
+
+* commission - The commission taken by this VoteState for any rewards claimed by
+staker's StakeState accounts.  This is the percentage ceiling of the reward.
+
+* Account::lamports - The accumulated lamports from the commission.  These do not
+count as stakes.
+
+* `authorized_vote_signer` - Only this identity is authorized to submit votes, and
+this field can only modified by this entity
+
+### VoteInstruction::Initialize
+
+* `account[0]` - RW - The VoteState
+  `VoteState::authorized_vote_signer` is initialized to `account[0]`
+   other VoteState members defaulted
+
+### VoteInstruction::AuthorizeVoteSigner(Pubkey)
+
+* `account[0]` - RW - The VoteState
+  `VoteState::authorized_vote_signer` is set to to `Pubkey`, instruction must by
+   signed by Pubkey
+
+
+### StakeState
+
+A StakeState takes one of two forms, StakeState::Delegate and StakeState::MiningPool.
+
+### StakeState::Delegate
+
+StakeState is the current delegation preference of the **staker**. StakeState
+contains the following state information:
+
+* Account::lamports - The staked lamports.
+
+* `voter_id` - The pubkey of the VoteState instance the lamports are
+delegated to.
+
+* `credits_observed` - The total credits claimed over the lifetime of the
+program.
+
+### StakeState::MiningPool
+
+There are two approaches to the mining pool.  The bank could allow the
+StakeState program to bypass the token balance check, or a program representing
+the mining pool could run on the network.  To avoid a single network wide lock,
+the pool can be split into several mining pools.  This design focuses on using a
+StakeState::MiningPool as the cluster wide mining pools.
+
+* 256 StakeState::MiningPool are initialized, each with 1/256 number of mining pool
+tokens stored as `Account::lamports`.
+
+The stakes and the MiningPool are accounts that are owned by the same `Stake`
+program.
+
+### StakeInstruction::Initialize
+
+* `account[0]` - RW - The StakeState::Delegate instance.
+  `StakeState::Delegate::credits_observed` is initialized to `VoteState::credits`.
+  `StakeState::Delegate::voter_id` is initialized to `account[1]`
+
+* `account[1]` - R - The VoteState instance.
+
+### StakeInstruction::RedeemVoteCredits
+
+The VoteState program and the StakeState programs maintain a lifetime counter
+of total rewards generated and claimed.  Therefore an explicit `Clear`
+instruction is not necessary.  When claiming rewards, the total lamports
+deposited into the StakeState and as validator commission is proportional to
+`VoteState::credits - StakeState::credits_observed`.
+
+
+* `account[0]` - RW - The StakeState::MiningPool instance that will fulfill the
+reward.
+* `account[1]` - RW - The StakeState::Delegate instance that is redeeming votes
+credits.
+* `account[2]` - R - The VoteState instance, must be the same as
+`StakeState::voter_id`
+
+Reward is payed out for the difference between `VoteState::credits` to
+`StakeState::Delgate.credits_observed`, and `credits_observed` is updated to
+`VoteState::credits`.  The commission is deposited into the `VoteState` token
+balance, and the reward is deposited to the `StakeState::Delegate` token balance.  The
+reward and the commission is weighted by the `StakeState::lamports` divided by total lamports staked.
+
+The Staker or the owner of the Stake program sends a transaction with this
+instruction to claim the reward.
+
+Any random MiningPool can be used to redeem the credits.
+
+```rust,ignore
+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::Delegate::credits_observed` is updated to the latest
+`VoteState::credits` value.
+
+### Collecting network fees into the MiningPool
+
+At the end of the block, before the bank is frozen, but after it processed all
+the transactions for the block, a virtual instruction is executed to collect
+the transaction fees.
+
+* A portion of the fees are deposited into the leader's account.
+* A portion of the fees are deposited into the smallest StakeState::MiningPool
+account.
+
+### Benefits
+
+* Single vote for all the stakers.
+
+* Clearing of the credit variable is not necessary for claiming rewards.
+
+* Each delegated stake can claim its rewards independently.
+
+* Commission for the work is deposited when a reward is claimed by the delegated
+stake.
+
+This proposal would benefit from the `read-only` accounts proposal to allow for
+many rewards to be claimed concurrently.
+
+## Passive Delegation
+
+Any number of instances of StakeState::Delegate programs can delegate to a single
+VoteState program without an interactive action from the identity controlling
+the VoteState program or submitting votes to the program.
+
+The total stake allocated to a VoteState program can be calculated by the sum of
+all the StakeState programs that have the VoteState pubkey as the
+`StakeState::Delegate::voter_id`.
+
+## Example Callflow
+
+<img alt="Passive Staking Callflow" src="img/passive-staking-callflow.svg" class="center"/>
+
+## Future work
+
+Validators may want to split the stake delegated to them amongst many validator
+nodes since stake is used as weight in the network control and data planes.  One
+way to implement this would be for the StakeState to delegate to a pool of
+validators instead of a single one.
+
+Instead of a single `vote_id` and `credits_observed` entry in the StakeState
+program, the program can be initialized with a vector of tuples.
+
+```rust,ignore
+Voter {
+    voter_id: Pubkey,
+    credits_observed: u64,
+    weight: u8,
+}
+```
+
+* voters: Vec<Voter> - Array of VoteState accounts that are voting rewards with
+this stake.
+
+A StakeState program would claim a fraction of the reward from each voter in
+the `voters` array, and each voter would be delegated a fraction of the stake.

book/src/persistent-account-storage.md

@@ -0,0 +1,153 @@
+# Persistent Account Storage
+
+The set of Accounts represent the current computed state of all the transactions
+that have been processed by a fullnode.  Each fullnode needs to maintain this
+entire set.  Each block that is proposed by the network represents a change to
+this set, and since each block is a potential rollback point the changes need to
+be reversible.
+
+Persistent storage like NVMEs are 20 to 40 times cheaper than DDR.  The problem
+with persistent storage is that write and read performance is much slower than
+DDR and care must be taken in how data is read or written to.  Both reads and
+writes can be split between multiple storage drives and accessed in parallel.
+This design proposes a data structure that allows for concurrent reads and
+concurrent writes of storage.   Writes are optimized by using an AppendVec data
+structure, which allows a single writer to append while allowing access to many
+concurrent readers.  The accounts index maintains a pointer to a spot where the
+account was appended to every fork, thus removing the need for explicit
+checkpointing of state.
+
+# AppendVec
+
+AppendVec is a data structure that allows for random reads concurrent with a
+single append-only writer.  Growing or resizing the capacity of the AppendVec
+requires exclusive access.  This is implemented with an atomic `offset`, which
+is updated at the end of a completed append.
+
+The underlying memory for an AppendVec is a memory-mapped file.  Memory-mapped
+files allow for fast random access and paging is handled by the OS.
+
+# Account Index
+
+The account index is designed to support a single index for all the currently
+forked Accounts.
+
+```rust,ignore
+type AppendVecId = usize;
+
+type Fork = u64;
+
+struct AccountMap(Hashmap<Fork, (AppendVecId, u64)>);
+
+type AccountIndex = HashMap<Pubkey, AccountMap>;
+
+```
+
+The index is a map of account Pubkeys to a map of Forks and the location of the
+Account data in an AppendVec.  To get the version of an account for a specific Fork:
+
+```rust,ignore
+/// Load the account for the pubkey.
+/// This function will load the account from the specified fork, falling back to the fork's parents
+/// * fork - a virtual Accounts instance, keyed by Fork.  Accounts keep track of their parents with Forks,
+///       the persistent store
+/// * pubkey - The Account's public key.
+pub fn load_slow(&self, id: Fork, pubkey: &Pubkey) -> Option<&Account>
+```
+
+The read is satisfied by pointing to a memory-mapped location in the
+`AppendVecId` at the stored offset.  A reference can be returned without a copy.
+
+## Root Forks
+
+The [fork selection algorithm](fork-selection.md) eventually selects a fork as a
+root fork and the fork is squashed.  A squashed/root fork cannot be rolled back.
+
+When a fork is squashed, all accounts in its parents not already present in the
+fork are pulled up into the fork by updating the indexes.  Accounts with zero
+balance in the squashed fork are removed from fork by updating the indexes.
+
+An account can be *garbage-collected* when squashing makes it unreachable.
+
+Three possible options exist:
+
+* Maintain a HashSet<u64> of root forks.  One is expected to be created every
+second.  The entire tree can be garbage-collected later. Alternatively, if
+every fork keeps a reference count of accounts, garbage collection could occur
+any time an index location is updated.
+
+* Remove any pruned forks from the index.  Any remaining forks lower in number
+than the root are can be considered root.
+
+* Scan the index, migrate any old roots into the new one.   Any remaining forks
+lower than the new root can be deleted later.
+
+# Append-only Writes
+
+All the updates to Accounts occur as append-only updates.  For every account
+update, a new version is stored in the AppendVec.
+
+It is possible to optimize updates within a single fork by returning a mutable
+reference to an already stored account in a fork.  The Bank already tracks
+concurrent access of accounts and guarantees that a write to a specific account
+fork will not be concurrent with a read to an account at that fork. To support
+this operation, AppendVec should implement this function:
+
+```rust,ignore
+fn get_mut(&self, index: u64) -> &mut T;
+```
+
+This API allows for concurrent mutable access to a memory region at `index`.  It
+relies on the Bank to guarantee exclusive access to that index.
+
+# Garbage collection
+
+As accounts get updated, they move to the end of the AppendVec.  Once capacity
+has run out, a new AppendVec can be created and updates can be stored there.
+Eventually references to an older AppendVec will disappear because all the
+accounts have been updated, and the old AppendVec can be deleted.
+
+To speed up this process, it's possible to move Accounts that have not been
+recently updated to the front of a new AppendVec.  This form of garbage
+collection can be done without requiring exclusive locks to any of the data
+structures except for the index update.
+
+The initial implementation for garbage collection is that once all the accounts in
+an AppendVec become stale versions, it gets reused. The accounts are not updated
+or moved around once appended.
+
+# Index Recovery
+
+Each bank thread has exclusive access to the accounts during append, since the
+accounts locks cannot be released until the data is committed. But there is no
+explicit order of writes between the separate AppendVec files.  To create an
+ordering, the index maintains an atomic write version counter.  Each append to
+the AppendVec records the index write version number for that append in the
+entry for the Account in the AppendVec.
+
+To recover the index, all the AppendVec files can be read in any order, and the
+latest write version for every fork should be stored in the index.
+
+# Snapshots
+
+To snapshot, the underlying memory-mapped files in the AppendVec need to be
+flushed to disk.  The index can be written out to disk as well.
+
+# Performance
+
+* Append-only writes are fast.  SSDs and NVMEs, as well as all the OS level
+kernel data structures, allow for appends to run as fast as PCI or NVMe bandwidth
+will allow (2,700 MB/s).
+
+* Each replay and banking thread writes concurrently to its own AppendVec.
+
+* Each AppendVec could potentially be hosted on a separate NVMe.
+
+* Each replay and banking thread has concurrent read access to all the
+AppendVecs without blocking writes.
+
+* Index requires an exclusive write lock for writes.  Single-thread performance
+for HashMap updates is on the order of 10m per second.
+
+* Banking and Replay stages should use 32 threads per NVMe.  NVMes have
+optimal performance with 32 concurrent readers or writers.

book/src/programs.md

@@ -3,8 +3,8 @@
 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 move *tokens* from one *account* to another or create an interactive
-contract that governs how tokens are moved. Instructions are executed
+program to move *lamports* from one *account* to another or create an interactive
+contract that governs how lamports are moved. Instructions are executed
 atomically. If any instruction is invalid, any changes made within the
 transaction are discarded.
 
@@ -21,9 +21,7 @@ used to reference the program in subsequent transactions.
 A program may be written in any programming language that can target the
 Berkley Packet Filter (BPF) safe execution environment. The Solana SDK offers
 the best support for C programs, which is compiled to BPF using the [LLVM
-compiler infrastructure](https://llvm.org). Alternatively, a client might
-choose to bypass LLVM and use Python, Lua or C++ to generate BPF directly via
-the [BPF Compiler Collection](https://github.com/iovisor/bcc) (BCC).
+compiler infrastructure](https://llvm.org).
 
 ## Storing State between Transactions
 

book/src/reliable-vote-transmission.md

@@ -0,0 +1,124 @@
+# Reliable Vote Transmission
+
+Validator votes are messages that have a critical function for consensus and
+continuous operation of the network. Therefore it is critical that they are
+reliably delivered and encoded into the ledger.
+
+## Challenges
+
+1. Leader rotation is triggered by PoH, which is clock with high drift.  So many
+nodes are likely to have an incorrect view if the next leader is active in
+realtime or not.
+
+2. The next leader may be easily be flooded.  Thus a DDOS would not only prevent
+delivery of regular transactions, but also consensus messages.
+
+3. UDP is unreliable, and our asynchronous protocol requires any message that is
+transmitted to be retransmitted until it is observed in the ledger.
+Retransmittion could potentially cause an unintentional *thundering herd*
+against the leader with a large number of validators.  Worst case flood would be
+`(num_nodes * num_retransmits)`.
+
+4. Tracking if the vote has been transmitted or not via the ledger does not
+guarantee it will appear in a confirmed block.  The current observed block may
+be unrolled. Validators would need to maintain state for each vote and fork.
+
+
+## Design
+
+1. Send votes as a push message through gossip.  This ensures delivery of the
+vote to all the next leaders, not just the next future one.
+
+2. Leaders will read the Crds table for new votes and encode any new received
+votes into the blocks they propose.  This allows for validator votes to be
+included in rollback forks by all the future leaders.
+
+3. Validators that receive votes in the ledger will add them to their local crds
+table, not as a push request, but simply add them to the table.  This shortcuts
+the push message protocol, so the validation messages do not need to be
+retransmitted twice around the network.
+
+4. CrdsValue for vote should look like this ``` Votes(Vec<Transaction>) ```
+
+Each vote transaction should maintain a `wallclock` in its data.  The merge
+strategy for Votes will keep the last N set of votes as configured by the local
+client.  For push/pull the vector is traversed recursively and each Transaction
+is treated as an individual CrdsValue with its own local wallclock and
+signature.
+
+Gossip is designed for efficient propagation of state.  Messages that are sent
+through gossip-push are batched and propagated with a minimum spanning tree to
+the rest of the network. Any partial failures in the tree are actively repaired
+with the gossip-pull protocol while minimizing the amount of data transfered
+between any nodes.
+
+
+## How this design solves the Challenges
+
+1. Because there is no easy way for validators to be in sync with leaders on the
+leader's "active" state, gossip allows for eventual delivery regardless of that
+state.
+
+2. Gossip will deliver the messages to all the subsequent leaders, so if the
+current leader is flooded the next leader would have already received these
+votes and is able to encode them.
+
+3. Gossip minimizes the number of requests through the network by maintaining an
+efficient spanning tree, and using bloom filters to repair state.  So retransmit
+back-off is not necessary and messages are batched.
+
+4. Leaders that read the crds table for votes will encode all the new valid
+votes that appear in the table.  Even if this leader's block is unrolled, the
+next leader will try to add the same votes without any additional work done by
+the validator.  Thus ensuring not only eventual delivery, but eventual encoding
+into the ledger.
+
+
+## Performance
+
+1. Worst case propagation time to the next leader is Log(N) hops with a base
+depending on the fanout.  With our current default fanout of 6, it is about 6
+hops to 20k nodes.
+
+2. The leader should receive 20k validation votes aggregated by gossip-push into
+64kb blobs. Which would reduce the number of packets for 20k network to 80
+blobs.
+
+3. Each validators votes is replicated across the entire network.  To maintain a
+queue of 5 previous votes the Crds table would grow by 25 megabytes.  `(20,000
+nodes * 256 bytes * 5)`.
+
+## Two step implementation rollout
+
+Initially the network can perform reliably with just 1 vote transmitted and
+maintained through the network with the current Vote implementation.  For small
+networks a fanout of 6 is sufficient.  With small network the memory and push
+overhead is minor.
+
+### Sub 1k validator network
+
+1. Crds just maintains the validators latest vote.
+
+2. Votes are pushed and retransmitted regardless if they are appearing in the
+ledger.
+
+3. Fanout of 6.
+
+* Worst case 256kb memory overhead per node.
+* Worst case 4 hops to propagate to every node.
+* Leader should receive the entire validator vote set in 4 push message blobs.
+
+### Sub 20k network
+
+Everything above plus the following:
+
+1. CRDS table maintains a vector of 5 latest validator votes.
+
+2. Votes encode a wallclock.  CrdsValue::Votes is a type that recurses into the
+transaction vector for all the gossip protocols.
+
+3. Increase fanout to 20.
+
+* Worst case 25mb memory overhead per node.
+* Sub 4 hops worst case to deliver to the entire network.
+* 80 blobs received by the leader for all the validator messages.

book/src/runtime.md

@@ -6,7 +6,7 @@ separating program code from the state it operates on, the runtime is able to
 choreograph concurrent access. Transactions accessing only credit-only
 accounts are executed in parallel whereas transactions accessing writable
 accounts are serialized.  The runtime interacts with the program through an
-entrypoint with a well-defined interface.  The userdata stored in an account is
+entrypoint with a well-defined interface.  The data stored in an account is
 an opaque type, an array of bytes. The program has full control over its
 contents.
 
@@ -18,7 +18,7 @@ transaction fails to commit.
 
 ### Account Structure
 
-Accounts maintain a token balance and program-specific memory.
+Accounts maintain a lamport balance and program-specific memory.
 
 # Transaction Engine
 
@@ -27,58 +27,90 @@ entrypoint.
 
 ## Execution
 
-Transactions are batched and processed in a pipeline
+Transactions are batched and processed in a pipeline.  The TPU and TVU follow a
+slightly different path.  The TPU runtime ensures that PoH record occurs before
+memory is committed.
+
+The TVU runtime ensures that PoH verification occurs before the runtime
+processes any transactions.
 
 <img alt="Runtime pipeline" src="img/runtime.svg" class="center"/>
 
-At the *execute* stage, the loaded pages have no data dependencies, so all the
+At the *execute* stage, the loaded accounts have no data dependencies, so all the
 programs can be executed in parallel.
 
 The runtime enforces the following rules:
 
 1. Only the *owner* program may modify the contents of an account.  This means
-   that upon assignment userdata vector is guaranteed to be zero.
+that upon assignment data vector is guaranteed to be zero.
+
 2. Total balances on all the accounts is equal before and after execution of a
-   transaction.
+transaction.
+
 3. After the transaction is executed, balances of credit-only accounts must be
-   greater than or equal to the balances before the transaction.
+greater than or equal to the balances before the transaction.
+
 4. All instructions in the transaction executed atomically. If one fails, all
-   account modifications are discarded.
+account modifications are discarded.
 
 Execution of the program involves mapping the program's public key to an
 entrypoint which takes a pointer to the transaction, and an array of loaded
-pages.
+accounts.
 
 ## SystemProgram Interface
 
-The interface is best described by the `Instruction::userdata` that the user
+The interface is best described by the `Instruction::data` that the user
 encodes.
 
-* `CreateAccount` - This allows the user to create and assign an account to a
-  Program.
-* `Assign` - allows the user to assign an existing account to a program.
-* `Move`  - moves tokens between account's that are associated with
-* `Spawn` - spawn a new program from an account
+* `CreateAccount` - This allows the user to create an account with an allocated
+data array and assign it to a Program.
+
+* `Assign` - Allows the user to assign an existing account to a program.
+
+* `Move`  - Moves lamports between accounts.
+
+## Program State Security
+
+For blockchain to function correctly, the program code must be resilient to user
+inputs.  That is why in this design the program specific code is the only code
+that can change the state of the data byte array in the Accounts that are
+assigned to it.  It is also the reason why `Assign` or `CreateAccount` must zero
+out the data.  Otherwise there would be no possible way for the program to
+distinguish the recently assigned account data from a natively generated
+state transition without some additional metadata from the runtime to indicate
+that this memory is assigned instead of natively generated.
+
+To pass messages between programs, the receiving program must accept the message
+and copy the state over.  But in practice a copy isn't needed and is
+undesirable. The receiving program can read the state belonging to other
+Accounts without copying it, and during the read it has a guarantee of the
+sender program's state.
 
 ## Notes
 
-1. There is no dynamic memory allocation.  Client's need to use `CreateAccount`
+* There is no dynamic memory allocation.  Client's need to use `CreateAccount`
 instructions to create memory before passing it to another program.  This
 instruction can be composed into a single transaction with the call to the
 program itself.
-2. Runtime guarantees that when memory is assigned to the program it is zero
-initialized.
-3. Runtime guarantees that a program's code is the only thing that can modify
-memory that its assigned to
-4. Runtime guarantees that the program can only spend tokens that are in
-accounts that are assigned to it
-5. Runtime guarantees the balances belonging to accounts are balanced before
-and after the transaction
-6. Runtime guarantees that multiple instructions all executed successfully when
-a transaction is committed.
+
+* `CreateAccount` and `Assign` guarantee that when account is assigned to the
+program, the Account's data is zero initialized.
+
+* Once assigned to program an Account cannot be reassigned.
+
+* Runtime guarantees that a program's code is the only code that can modify
+Account data that the Account is assigned to.
+
+* Runtime guarantees that the program can only spend lamports that are in
+accounts that are assigned to it.
+
+* Runtime guarantees the balances belonging to accounts are balanced before
+and after the transaction.
+
+* Runtime guarantees that instructions all executed successfully when a
+transaction is committed.
 
 # Future Work
 
 * [Continuations and Signals for long running
   Transactions](https://github.com/solana-labs/solana/issues/1485)
-

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

@@ -0,0 +1,68 @@
+# Stake Delegation and Rewards
+
+Stakers are rewarded for helping validate the ledger. They do it by delegating
+their stake to fullnodes. Those fullnodes do the legwork and send votes to the
+stakers' staking accounts. The rest of the cluster uses those stake-weighted
+votes to select a block when forks arise. Both the fullnode and staker need
+some economic incentive to play their part. The fullnode needs to be
+compensated for its hardware and the staker needs to be compensated for risking
+getting its stake slashed.  The economics are covered in [staking
+rewards](staking-rewards.md).  This chapter, on the other hand, describes the
+underlying mechanics of its implementation.
+
+## Vote and Rewards accounts
+
+The rewards process is split into two on-chain programs. The Vote program
+solves the problem of making stakes slashable. The Rewards account acts as
+custodian of the rewards pool. It is responsible for paying out each staker
+once the staker proves to the Rewards program that it participated in
+validating the ledger.
+
+The Vote account contains the following state information:
+
+* votes - The submitted votes.
+
+* `delegate_id` - An identity that may operate with the weight of this
+  account's stake. It is typically the identity of a fullnode, but may be any
+identity involved in stake-weighted computations.
+
+* `authorized_voter_id` - Only this identity is authorized to submit votes.
+
+* `credits` - The amount of unclaimed rewards.
+
+* `root_slot` - The last slot to reach the full lockout commitment necessary
+  for rewards.
+
+The Rewards program is stateless and pays out reward when a staker submits its
+Vote account to the program. Claiming a reward requires a transaction that
+includes the following instructions:
+
+1. `RewardsInstruction::RedeemVoteCredits`
+2. `VoteInstruction::ClearCredits`
+
+The Rewards program transfers lamports from the Rewards account to the Vote
+account's public key. The Rewards program also ensures that the `ClearCredits`
+instruction follows the `RedeemVoteCredits` instruction, such that a staker may
+not claim rewards for the same work more than once.
+
+
+### Delegating Stake
+
+`VoteInstruction::DelegateStake` allows the staker to choose a fullnode to
+validate the ledger on its behalf. By being a delegate, the fullnode is
+entitled to collect transaction fees when its is leader. The larger the stake,
+the more often the fullnode will be able to collect those fees.
+
+### Authorizing a Vote Signer
+
+`VoteInstruction::AuthorizeVoter` allows a staker to choose a signing service
+for its votes. That service is responsible for ensuring the vote won't cause
+the staker to be slashed.
+
+## Limitations
+
+Many stakers may delegate their stakes to the same fullnode. The fullnode must
+send a separate vote to each staking account. If there are far more stakers
+than fullnodes, that's a lot of network traffic. An alternative design might
+have fullnodes submit each vote to just one account and then have each staker
+submit that account along with their own to collect its reward.

book/src/staking-rewards.md

@@ -22,8 +22,7 @@ specific attributes to be modified as is allowed by Solana's Proof of History
 
 ### General Overview
 
-Solana's ledger validation design is based on a rotating, stake-weighted
-randomly selected leader broadcasting transactions in a PoH data
+Solana's ledger validation design is based on a rotating, stake-weighted selected leader broadcasting transactions in a PoH data
 structure to validating nodes. These nodes, upon receiving the leader's
 broadcast, have the opportunity to vote on the current state and PoH height by
 signing a transaction into the PoH stream.
@@ -50,43 +49,12 @@ specific parameters will be necessary:
 Solana's trustless sense of time and ordering provided by its PoH data
 structure, along with its
 [avalanche](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast
-and transmission design, should provide subsecond confirmation times that scale
+and transmission design, should provide sub-second transaction confirmation times that scale
 with the log of the number of nodes in the cluster. This means we shouldn't
 have to restrict the number of validating nodes with a prohibitive 'minimum
 deposits' and expect nodes to be able to become validators with nominal amounts
-of SOL staked. This should also render validation pools, a proposed solution
-for economic censorship imposed by minimum staking amounts currently described
-in Casper, unnecessary and remove the concern for needing to put slashable
-stake at risk while relying on others to play by the rules.
+of SOL staked. At the same time, Solana's focus on high-throughput should create incentive for validation clients to provide high-performant and reliable hardware. Combined with potential a minimum network speed threshold to join as a validation-client, we expect a healthy validation delegation market to emerge. To this end, Solana's testnet will lead into a "Tour de SOL" validation-client competition, focusing on throughput and uptime to rank and reward testnet validators.
 
-### Stake-weighted Rewards
-
-Rewards are expected to be paid out to active validators as a function of
-validator activity and as a proportion of the percentage of SOL they have at
-stake out of the entirety of the staking pool.
-
-We expect to define a baseline annual validator payout/inflation rate based on
-the total SOL deposited. E.g. 10% annual interest on SOL deposited with X total
-SOL deposited as slashable on the cluster. This is the same design as currently
-proposed in Casper FFG which has additionally specifies how inflation rates
-adjust as a function of total ETH deposited. Specifically, Casper validator
-returns are proportional to the inverse square root of the total deposits and
-initial annual rates are estimated as:
-
-| Deposit Size | Annual Validator Interest |
-|-------------:|--------------------------:|
-| 2.5M ETH     | 10.12%                    |
-| 10M ETH      | 5.00%                     |
-| 20M ETH      | 3.52%                     |
-| 40M ETH      | 2.48%                     |
-
-This has the nice property of potentially incentivizing participation around a
-target deposit size. Incentivisation of specific participation rates more
-directly (rather than deposit size) may something also worth exploring.
-
-The specifics of the Solana validator reward scheme are to be worked out in
-parallel with a design for transaction fee assignment as well as our storage
-mining reward scheme.
 
 ### Slashing rules
 
@@ -149,8 +117,8 @@ This is an area currently under exploration
 
 ### Penalties
 
-As previously discussed, annual validator reward rates are to be specified as a
-function of total amount staked. The cluster rewards validators who are online
+As discussed in the [Economic Design](ed_overview.md) 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.

book/src/synchronization.md

@@ -54,9 +54,9 @@ function](https://eprint.iacr.org/2018/601.pdf) or *VDF*.
 A desirable property of a VDF is that verification time is very fast. Solana's
 approach to verifying its delay function is proportional to the time it took to
 create it. Split over a 4000 core GPU, it is sufficiently fast for Solana's
-needs, but if you asked the authors the paper cited above, they might tell you
+needs, but if you asked the authors of the paper cited above, they might tell you
 ([and have](https://github.com/solana-labs/solana/issues/388)) that Solana's
-approach is algorithmically slow it shouldn't be called a VDF. We argue the
+approach is algorithmically slow and it shouldn't be called a VDF. We argue the
 term VDF should represent the category of verifiable delay functions and not
 just the subset with certain performance characteristics. Until that's
 resolved, Solana will likely continue using the term PoH for its

book/src/terminology.md

@@ -19,18 +19,27 @@ A fraction of a [block](#block); the smallest unit sent between
 #### block
 
 A contiguous set of [entries](#entry) on the ledger covered by a
-[vote](#ledger-vote).  The duration of a block is some cluster-configured
-number of [ticks](#tick).  Also called [voting period](#voting-period).
+[vote](#ledger-vote). A [leader](#leader) produces at most one block per
+[slot](#slot).
 
 #### block height
 
-The number of [blocks](#block) beneath the current block plus one. The [genesis
-block](#genesis-block), for example, has block height 1.
+The number of [blocks](#block) beneath the current block. The first block after
+the [genesis block](#genesis-block) has height zero.
+
+#### block id
+
+The [entry id](#entry-id) of the last entry in a [block](#block).
 
 #### bootstrap leader
 
 The first [fullnode](#fullnode) to take the [leader](#leader) role.
 
+#### CBC block
+
+Smallest encrypted chunk of ledger, an encrypted ledger segment would be made of
+many CBC blocks. `ledger_segment_size / cbc_block_size` to be exact.
+
 #### client
 
 A [node](#node) that utilizes the [cluster](#cluster).
@@ -59,11 +68,24 @@ consensus.
 An off-chain service that acts as a custodian for a user's private key. It
 typically serves to validate and sign transactions.
 
+#### fake storage proof
+
+A proof which has the same format as a storage proof, but the sha state is
+actually from hashing a known ledger value which the storage client can reveal
+and is also easily verifiable by the network on-chain.
+
 #### entry
 
 An entry on the [ledger](#ledger) either a [tick](#tick) or a [transactions
 entry](#transactions-entry).
 
+#### entry id
+
+A globally unique identifier that is also a proof that the [entry](#entry) was
+generated after a duration of time, all [transactions](#transaction) included
+in the entry, and all previous entries on the [ledger](#ledger). See [Proof of
+History](#proof-of-history).
+
 #### epoch
 
 The time, i.e. number of [slots](#slot), for which a [leader
@@ -80,13 +102,13 @@ A full participant in the [cluster](#cluster) either a [leader](#leader) or
 
 #### fullnode state
 
-The result of interpreting all programs on the ledger a given [tick
+The result of interpreting all programs on the ledger at a given [tick
 height](#tick-height). It includes at least the set of all [accounts](#account)
 holding nonzero [native tokens](#native-tokens).
 
 #### genesis block
 
-The first [block](#block) of the [ledger](#ledger).
+The configuration file that prepares the [ledger](#ledger) for the first [block](#block).
 
 #### hash
 
@@ -99,7 +121,7 @@ in a [transaction](#instruction).
 
 #### keypair
 
-A [public key](#public-key) and coesponding [secret key](#secret-key).
+A [public key](#public-key) and corresponding [secret key](#secret-key).
 
 #### lamport
 
@@ -127,6 +149,11 @@ at any moment in time.
 A list of [entries](#entry) containing [transactions](#transaction) signed by
 [clients](#client).
 
+#### ledger segment
+
+Portion of the ledger which is downloaded by the replicator where storage proof
+data is derived.
+
 #### ledger vote
 
 A [hash](#hash) of the [fullnode's state](#fullnode-state) at a given [tick
@@ -152,7 +179,7 @@ The [token](#token) used to track work done by [nodes](#node) in a cluster.
 
 #### node
 
-A computer particpating in a [cluster](#cluster).
+A computer participating in a [cluster](#cluster).
 
 #### node count
 
@@ -166,7 +193,7 @@ See [Proof of History](#proof-of-history).
 
 The code that interprets [instructions](#instruction).
 
-#### program ID
+#### program id
 
 The public key of the [account](#account) containing a [program](#program).
 
@@ -181,6 +208,11 @@ verified in less time than it took to produce.
 
 The public key of a [keypair](#keypair).
 
+#### replicator
+
+Storage mining client, stores some part of the ledger enumerated in blocks and
+submits storage proofs to the chain. Not a full-node.
+
 #### runtime
 
 The component of a [fullnode](#fullnode) responsible for [program](#program)
@@ -192,8 +224,8 @@ The private key of a [keypair](#keypair).
 
 #### slot
 
-The time (i.e. number of [blocks](#block)) for which a [leader](#leader)
-ingests transactions and produces [entries](#entry).
+The period of time for which a [leader](#leader) ingests transactions and
+produces a [block](#block).
 
 #### sol
 
@@ -205,6 +237,32 @@ by the company Solana.
 Tokens forfeit to the [cluster](#cluster) if malicious [fullnode](#fullnode)
 behavior can be proven.
 
+#### storage proof
+
+A set of sha hash state which is constructed by sampling the encrypted version
+of the stored ledger segment at certain offsets.
+
+#### storage proof challenge
+
+A transaction from a replicator that verifiably proves that a validator
+confirmed a fake proof.
+
+#### storage proof claim
+
+A transaction from a validator which is after the timeout period given from the
+storage proof confirmation and which no successful challenges have been
+observed which rewards the parties of the storage proofs and confirmations.
+
+#### storage proof confirmation
+
+A transaction by a validator which indicates the set of real and fake proofs
+submitted by a storage miner. The transaction would contain a list of proof
+hash values and a bit which says if this hash is valid or fake.
+
+#### storage validation capacity
+
+The number of keys and samples that a validator can verify each storage epoch.
+
 #### thin client
 
 A type of [client](#client) that trusts it is communicating with a valid
@@ -252,8 +310,3 @@ that it ran, which can then be verified in less time than it took to produce.
 #### vote
 
 See [ledger vote](#ledger-vote).
-
-#### voting period
-
-The duration of a [block](#block).
-

book/src/testing-programs.md

@@ -0,0 +1,64 @@
+## Testing Programs
+
+Applications send transactions to a Solana cluster and query validators to
+confirm the transactions were processed and to check each transaction's result.
+When the cluster doesn't behave as anticipated, it could be for a number of
+reasons:
+
+* The program is buggy
+* The BPF loader rejected an unsafe program instruction
+* The transaction was too big
+* The transaction was invalid
+* The Runtime tried to execute the transaction when another one was accessing
+  the same account
+* The network dropped the transaction
+* The cluster rolled back the ledger
+* A validator responded to queries maliciously
+
+### The Transact Trait
+
+To troubleshoot, the application should retarget a lower-level component, where
+fewer errors are possible. Retargeting can be done with different
+implementations of the Transact trait.
+
+When Futures 0.3.0 is released, the Transact trait may look like this:
+
+```rust,ignore
+trait Transact {
+    async fn send_transactions(txs: &[Transaction]) -> Vec<Result<(), TransactionError>>;
+}
+```
+
+Users send transactions and asynchrounously await their results.
+
+#### Transact with Clusters
+
+The highest level implementation targets a Solana cluster, which may be a
+deployed testnet or a local cluster running on a development machine.
+
+#### Transact with the TPU
+
+The next level is the TPU implementation of Transact. At the TPU level, the
+application sends transactions over Rust channels, where there can be no
+surprises from network queues or dropped packets. The TPU implements all
+"normal" transaction errors. It does signature verification, may report
+account-in-use errors, and otherwise results in the ledger, complete with proof
+of history hashes.
+
+### Low-level testing
+
+### Testing with the Bank
+
+Below the TPU level is the Bank. The Bank doesn't do signature verification or
+generate a ledger. The Bank is a convenient layer at which to test new on-chain
+programs. It allows developers to toggle between native program implementations
+and BPF-compiled variants. No need for the Transact trait here. The Bank's API
+is synchronous.
+
+### Unit-testing with the Runtime
+
+Below the Bank is the Runtime. The Runtime is the ideal test environment for
+unit-testing. By statically linking the Runtime into a native program
+implementation, the developer gains the shortest possible edit-compile-run
+loop. Without any dynamic linking, stack traces include debug symbols and
+program errors are straightforward to troubleshoot.

book/src/testnet-participation.md

@@ -0,0 +1,141 @@
+## Testnet Participation
+This document describes how to participate in the testnet as a
+validator node.
+
+Please note some of the information and instructions described here may change
+in future releases.
+
+### Testnet Overview
+The testnet features a validator running at .testnet.solana.com, which
+serves as the entrypoint to the cluster for your validator.
+
+Additionally there is a blockexplorer available at
+[http://testnet.solana.com/](http://testnet.solana.com/).
+
+The testnet is configured to reset the ledger every 24hours, or sooner
+should an hourly automated sanity test fail.
+
+### Machine Requirements
+Since the testnet is not intended for stress testing of max transaction
+throughput, a higher-end machine with a GPU is not necessary to participate.
+
+However ensure the machine used is not behind a residential NAT to avoid NAT
+traversal issues.  A cloud-hosted machine works best.  Ensure that IP ports
+8000 through 10000 are not blocked for Internet traffic.
+
+Prebuilt binaries are available for Linux x86_64 (Ubuntu 18.04 recommended).
+MacOS or WSL users may build from source.
+
+#### Confirm The Testnet Is Reachable
+Before attaching a validator node, sanity check that the cluster is accessible
+to your machine by running some simple wallet commands.  If any of these
+commands fail, please retry 5-10 minutes later to confirm the testnet is not
+just restarting itself before debugging further.
+
+Fetch the current testnet transaction count over JSON RPC:
+```bash
+$ curl -X POST -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1, "method":"getTransactionCount"}' http://testnet.solana.com:8899
+```
+
+Inspect the blockexplorer at [http://testnet.solana.com/](http://testnet.solana.com/) for activity.
+
+Run the following command to join the gossip network and view all the other nodes in the cluster:
+```bash
+$ solana-gossip --network testnet.solana.com:8001
+```
+
+View the [metrics dashboard](https://metrics.solana.com:3000/d/testnet-edge/testnet-monitor-edge?var-testnet=testnet)
+for more detail on cluster activity.
+
+### Validator Setup
+#### Obtaining The Software
+##### Bootstrap with `solana-install`
+
+The `solana-install` tool can be used to easily install and upgrade the cluster
+software on Linux x86_64 systems.
+
+Install the latest release with a single shell command:
+```bash
+$ curl -sSf https://raw.githubusercontent.com/solana-labs/solana/v0.13.0/install/solana-install-init.sh | \
+  sh -s - --url https://api.testnet.solana.com
+```
+
+Alternatively build the `solana-install` program from source and run the
+following command to obtain the same result:
+```bash
+$ solana-install init --url https://api.testnet.solana.com
+```
+
+After a successful install, `solana-install update` may be used to easily update the cluster
+software to a newer version.
+
+##### Download Prebuilt Binaries
+Binaries are available for Linux x86_64 systems.
+
+Download the binaries by navigating to https://github.com/solana-labs/solana/releases/latest, download
+**solana-release-x86_64-unknown-linux-gnu.tar.bz2**, then extract the archive:
+```bash
+$ tar jxf solana-release-x86_64-unknown-linux-gnu.tar.bz2
+$ cd solana-release/
+$ export PATH=$PWD/bin:$PATH
+```
+##### Build From Source
+If you are unable to use the prebuilt binaries or prefer to build it yourself from source, navigate to:
+> https://github.com/solana-labs/solana/releases/latest
+
+Download the source code tarball (solana-*[release]*.tar.gz) from our latest release tag.  Extract the code and build the binaries with:
+```bash
+$ ./scripts/cargo-install-all.sh .
+$ export PATH=$PWD/bin:$PATH
+```
+
+### Starting The Validator
+
+Sanity check that you are able to interact with the cluster by receiving a small
+airdrop of lamports from the testnet drone:
+```bash
+$ solana-wallet -n testnet.solana.com airdrop 123
+$ solana-wallet -n testnet.solana.com balance
+```
+
+Then the following command will start a new validator node.
+
+If this is a `solana-install`-installation:
+```bash
+$ fullnode-x.sh --public-address --poll-for-new-genesis-block testnet.solana.com
+```
+
+Alternatively, the `solana-install run` command can be used to run the validator
+node while periodically checking for and applying software updates:
+```bash
+$ solana-install run fullnode-x.sh -- --public-address --poll-for-new-genesis-block testnet.solana.com
+```
+
+When not using `solana-install`:
+```bash
+$ USE_INSTALL=1 ./multinode-demo/fullnode-x.sh --public-address --poll-for-new-genesis-block testnet.solana.com
+```
+
+Then from another console, confirm the IP address if your node is now visible in
+the gossip network by running:
+```bash
+$ solana-gossip --network testnet.solana.com:8001
+```
+
+Congratulations, you're now participating in the testnet cluster!
+
+#### Controlling local network port allocation
+By default the validator will dynamically select available network ports in the
+8000-10000 range, and may be overridden with `--dynamic-port-range`.  For
+example, `fullnode-x.sh --dynamic-port-range 11000-11010 ...` will restrict the
+validator to ports 11000-11011.
+
+### Sharing Metrics From Your Validator
+If you'd like to share metrics perform the following steps before starting the
+validator node:
+```bash
+export u="username obtained from the Solana maintainers"
+export p="password obtained from the Solana maintainers"
+export SOLANA_METRICS_CONFIG="db=testnet,u=${u:?},p=${p:?}"
+source scripts/configure-metrics.sh
+```

book/src/tictactoe.md

@@ -23,13 +23,13 @@ Next, follow the steps in the git repository's
 [README](https://github.com/solana-labs/example-tictactoe/blob/master/README.md).
 
 
-## Getting tokens to users
+## Getting lamports to users
 
 You may have noticed you interacted with the Solana cluster without first
-needing to aquire tokens to pay transaction fees. Under the hood, the web
+needing to acquire lamports to pay transaction fees. Under the hood, the web
 app creates a new ephemeral identity and sends a request to an off-chain
-service for a signed transation authorizes a user to start a new game.
+service for a signed transaction authorizing a user to start a new game.
 The service is called a *drone*. When the app sends the signed transaction
-to the Solana cluster, the drone's tokens are spent to pay the transaction
+to the Solana cluster, the drone's lamports are spent to pay the transaction
 fee and start the game. In a real world app, the drone might request the user
-watch an ad or pass a CAPTCHA before signing over its tokens.
+watch an ad or pass a CAPTCHA before signing over its lamports.

book/src/transaction-fees.md

@@ -0,0 +1,59 @@
+# Deterministic Transaction Fees
+
+Transactions currently include a fee field that indicates the maximum fee field
+a slot leader is permitted to charge to process a transaction. The cluster, on
+the other hand, agrees on a minimum fee. If the network is congested, the slot
+leader may prioritize the transactions offering higher fees. That means the
+client won't know how much was collected until the transaction is confirmed by
+the cluster and the remaining balance is checked. It smells of exactly what we
+dislike about Ethereum's "gas", non-determinism.
+
+## Implementation Status
+
+This design is not yet implemented, but is written as though it has been.  Once
+implemented, delete this comment.
+
+### Congestion-driven fees
+
+Each validator uses *signatures per slot* (SPS) to estimate network congestion
+and *SPS target* to estimate the desired processing capacity of the cluster.
+The validator learns the SPS target from the genesis block, whereas it
+calculates SPS from the ledger data in the previous epoch.
+
+### Calculating fees
+
+The client uses the JSON RPC API to query the cluster for the current fee
+parameters.  Those parameters are tagged with a blockhash and remain valid
+until that blockhash is old enough to be rejected by the slot leader.
+
+Before sending a transaction to the cluster, a client may submit the
+transaction and fee account data to an SDK module called the *fee calculator*.
+So long as the client's SDK version matches the slot leader's version, the
+client is assured that its account will be changed exactly the same number of
+lamports as returned by the fee calculator.
+
+### Fee Parameters
+
+In the first implementation of this design, the only fee parameter is
+`lamports_per_signature`. The more signatures the cluster needs to verify, the
+higher the fee. The exact number of lamports is determined by the ratio of SPS
+to the SPS target. The cluster lowers `lamports_per_signature` when SPS is
+below the target and raises it when at or above the target.
+
+Future parameters might include:
+
+* `lamports_per_pubkey` - cost to load an account
+* `lamports_per_slot_distance` - higher cost to load very old accounts
+* `lamports_per_byte` - cost per size of account loaded
+* `lamports_per_bpf_instruction` - cost to run a program
+
+### Attacks
+
+#### Hijacking the SPS Target
+
+A group of validators can centralize the cluster if they can convince it to
+raise the SPS Target above a point where the rest of the validators can keep
+up. Raising the target will cause fees to drop, presumably creating more demand
+and therefore higher TPS. If the validator doesn't have hardware that can
+process that many transactions that fast, its confirmation votes will
+eventually get so long that the cluster will be forced to boot it.

book/src/vote-signing-to-implement.md

@@ -1,18 +1,17 @@
-# Signing using Secure Enclave
+# Secure Vote Signing
 
-This document defines the security mechanism of signing keys used by the
-fullnodes. Every node contains an asymmetric key that's used for signing
-and verifying the votes. The node signs the vote transactions using its private
-key. Other entities can verify the signature using the node's public key.
+This design describes additional vote signing behavior that will make the
+process more secure.
 
-The node's stake or its resources could be compromised if its private key is
-used to sign incorrect data (e.g. voting on multiple forks of the ledger). So,
-it's important to safeguard the private key.
+Currently, Solana implements a vote-signing service that evaluates each vote to
+ensure it does not violate a slashing condition. The service could potentially
+have different variations, depending on the hardware platform capabilities. In
+particular, it could be used in conjunction with a secure enclave (such as SGX).
+The enclave could generate an asymmetric key, exposing an API for user
+(untrusted) code to sign the vote transactions, while keeping the vote-signing
+private key in its protected memory.
 
-Secure Enclaves (such as SGX) provide a layer of memory and computation
-protection. An enclave can be used to generate an asymmetric key and keep the
-private key in its protected memory. It can expose an API that user (untrusted)
-code can use for signing the transactions.
+The following sections outline how this architecture would work:
 
 ## Message Flow
 
@@ -26,13 +25,13 @@ code can use for signing the transactions.
 2. The node performs attestation of the enclave (e.g using Intel's IAS APIs)
     * The node ensures that the Secure Enclave is running on a TPM and is
       signed by a trusted party
-3. The owner of the node grants ephemeral key permission to use its stake. This
-   process is TBD.
+3. The stakeholder of the node grants ephemeral key permission to use its stake.
+   This process is TBD.
 4. The node's untrusted, non-enclave software calls trusted enclave software
    using its interface to sign transactions and other data.
     * In case of vote signing, the node needs to verify the PoH. The PoH
      verification is an integral part of signing. The enclave would be
-     presented with some verifiable data that it'll check before signing the vote.
+     presented with some verifiable data to check before signing the vote.
     * The process of generating the verifiable data in untrusted space is TBD
 
 ## PoH Verification
@@ -101,81 +100,8 @@ confirming that it has observed some probability of economic finality of the
 submitted fork at a depth where an additional vote would create a lockout for
 an undesirable amount of time if that fork turns out not to be live.
 
-## Signing service
-
-The signing service consists of a a JSON RPC server, and a request processor.
-At startup, it starts the RPC server at a configured port and waits for
-client/validator requests. It expects the following type of requests.
-1. Register a new validator node
-    * The request contains validator's identity (public key)
-    * The request is signed with validator's private key
-    * The service will drop the request if signature of the request cannot be
-      verified
-    * The service will create a new voting asymmetric key for the validator,
-      and return the public key as a response
-    * If a validator retries to register, it'll return the public key from the
-      pre-existing keypair
-2. Sign a vote
-    * The request contains voting transaction, and all verification data (as
-      described in Ancestor Verification)
-    * The request is signed with validator's private key
-    * The service will drop the request if signature of the request cannot be
-      verified
-    * The service will verify the voting data
-    * The service will return a signed transaction (or signature for the
-      transaction)
-
-The service could potentially have different variations, depending on the
-hardware platform capabilities. For example, if the hardware supports a secure
-enclave, the service can offload asymmetric key generation, and private key
-protection to the enclave. A less secure implementation of the service could
-simply carry the keypair in the process memory.
-
-## Validator voting
-
-A validator node, at startup, creates a new vote account and registers it with
-the cluster. This is done by submitting a new "vote register" transaction. The
-transaction contains validator's keypair, it's vote signing public key, and
-some additional information. The other nodes on the cluster process this
-transaction and include the new validator in the active set.
-
-Subsequently, the validator submits a "new vote" transaction on a voting event.
-This vote is signed with validator's voting private key.
-
-The validator code will change to interface with Signing service for "vote
-register" and "new vote" use cases.
-
-### Configuration
-
-The validator node will be configured with Signing service's network endpoint
-(IP/Port).
-
-### Register
-
-At startup, the validator will call Signing service using JSON RPC to register
-itself. The RPC call will return the voting public key for the validator node.
-The validator will create a new "vote register" transaction including this
-public key in it, and submit it to the cluster.
-
-### Collect votes for last period
-
-The validator will look up the votes submitted by all the nodes in the cluster
-for the last voting period. This information will be submitted to signing
-service with new vote signing request.
-
-### New Vote Signing
-
-The validator will create a "new vote" transaction and send it to the signing
-service using JSON RPC. The RPC request will also include the vote verification
-data. On success, RPC call will return the signature for the vote. On failure,
-RPC call will return the failure code.
-
 ## Challenges
 
-1. The nodes are currently being configured with asymmetric keys that are
-   generated and stored in PKCS8 files.
-2. The genesis block contains an entry that's signed with leader's private key.
-   This entry is used to identify the primordial leader.
-3. Generation of verifiable data in untrusted space for PoH verification in the
+1. Generation of verifiable data in untrusted space for PoH verification in the
    enclave.
-4. Need infrastructure for granting stake to an ephemeral key.
+2. Need infrastructure for granting stake to an ephemeral key.

book/src/vote-signing.md

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

book/src/wallet.md

@@ -14,7 +14,7 @@ $ solana-wallet address
 <PUBKEY>
 ```
 
-#### Airdrop Tokens
+#### Airdrop Lamports
 
 ```sh
 // Command
@@ -41,7 +41,7 @@ $ solana-wallet balance
 $ solana-wallet confirm <TX_SIGNATURE>
 
 // Return
-"Confirmed" / "Not found"
+"Confirmed" / "Not found" / "Transaction failed with error <ERR>"
 ```
 
 #### Deploy program
@@ -78,7 +78,7 @@ $ solana-wallet pay <PUBKEY> 123 \
 
 #### Authorized Transfer
 
-A third party must send a signature to unlock the tokens.
+A third party must send a signature to unlock the lamports.
 ```sh
 // Command
 $ solana-wallet pay <PUBKEY> 123 \
@@ -168,25 +168,27 @@ $ solana-wallet send-timestamp <PUBKEY> <PROCESS_ID> --date 2018-12-24T23:59:00
 ### Usage
 
 ```manpage
-solana-wallet 0.11.0
+solana-wallet 0.12.0
 
 USAGE:
-    solana-wallet [OPTIONS] [SUBCOMMAND]
+    solana-wallet [FLAGS] [OPTIONS] [SUBCOMMAND]
 
 FLAGS:
     -h, --help       Prints help information
+        --rpc-tls    Enable TLS for the RPC endpoint
     -V, --version    Prints version information
 
 OPTIONS:
-    -k, --keypair <PATH>         /path/to/id.json
-    -n, --network <HOST:PORT>    Rendezvous with the network at this gossip entry point; defaults to 127.0.0.1:8001
-        --proxy <URL>            Address of TLS proxy
-        --port <NUM>             Optional rpc-port configuration to connect to non-default nodes
-        --timeout <SECS>         Max seconds to wait to get necessary gossip from the network
+        --drone-host <IP ADDRESS>    Drone host to use [default: same as --host]
+        --drone-port <PORT>          Drone port to use [default: 9900]
+    -n, --host <IP ADDRESS>          Host to use for both RPC and drone [default: 127.0.0.1]
+    -k, --keypair <PATH>             /path/to/id.json
+        --rpc-host <IP ADDRESS>      RPC host to use [default: same as --host]
+        --rpc-port <PORT>            RPC port to use [default: 8899]
 
 SUBCOMMANDS:
     address                  Get your public key
-    airdrop                  Request a batch of tokens
+    airdrop                  Request a batch of lamports
     balance                  Get your balance
     cancel                   Cancel a transfer
     confirm                  Confirm transaction by signature
@@ -199,7 +201,7 @@ SUBCOMMANDS:
 ```
 
 ```manpage
-solana-wallet-address 
+solana-wallet-address
 Get your public key
 
 USAGE:
@@ -211,8 +213,8 @@ FLAGS:
 ```
 
 ```manpage
-solana-wallet-airdrop 
-Request a batch of tokens
+solana-wallet-airdrop
+Request a batch of lamports
 
 USAGE:
     solana-wallet airdrop <NUM>
@@ -222,11 +224,11 @@ FLAGS:
     -V, --version    Prints version information
 
 ARGS:
-    <NUM>    The number of tokens to request
+    <NUM>    The number of lamports to request
 ```
 
 ```manpage
-solana-wallet-balance 
+solana-wallet-balance
 Get your balance
 
 USAGE:
@@ -238,7 +240,7 @@ FLAGS:
 ```
 
 ```manpage
-solana-wallet-cancel 
+solana-wallet-cancel
 Cancel a transfer
 
 USAGE:
@@ -253,7 +255,7 @@ ARGS:
 ```
 
 ```manpage
-solana-wallet-confirm 
+solana-wallet-confirm
 Confirm transaction by signature
 
 USAGE:
@@ -268,7 +270,7 @@ ARGS:
 ```
 
 ```manpage
-solana-wallet-deploy 
+solana-wallet-deploy
 Deploy a program
 
 USAGE:
@@ -283,7 +285,7 @@ ARGS:
 ```
 
 ```manpage
-solana-wallet-get-transaction-count 
+solana-wallet-get-transaction-count
 Get current transaction count
 
 USAGE:
@@ -295,29 +297,29 @@ FLAGS:
 ```
 
 ```manpage
-solana-wallet-pay 
+solana-wallet-pay
 Send a payment
 
 USAGE:
     solana-wallet pay [FLAGS] [OPTIONS] <PUBKEY> <NUM>
 
 FLAGS:
-        --cancelable    
+        --cancelable
     -h, --help          Prints help information
     -V, --version       Prints version information
 
 OPTIONS:
         --after <DATETIME>                      A timestamp after which transaction will execute
         --require-timestamp-from <PUBKEY>       Require timestamp from this third party
-        --require-signature-from <PUBKEY>...    Any third party signatures required to unlock the tokens
+        --require-signature-from <PUBKEY>...    Any third party signatures required to unlock the lamports
 
 ARGS:
     <PUBKEY>    The pubkey of recipient
-    <NUM>       The number of tokens to send
+    <NUM>       The number of lamports to send
 ```
 
 ```manpage
-solana-wallet-send-signature 
+solana-wallet-send-signature
 Send a signature to authorize a transfer
 
 USAGE:
@@ -333,7 +335,7 @@ ARGS:
 ```
 
 ```manpage
-solana-wallet-send-timestamp 
+solana-wallet-send-timestamp
 Send a timestamp to unlock a transfer
 
 USAGE:
@@ -350,4 +352,3 @@ ARGS:
     <PUBKEY>        The pubkey of recipient
     <PROCESS_ID>    The process id of the transfer to unlock
 ```
-

book/src/webwallet.md

@@ -7,6 +7,9 @@ First fetch the example code:
 ```sh
 $ git clone https://github.com/solana-labs/example-webwallet.git
 $ cd example-webwallet
+$ TAG=$(git describe --tags $(git rev-list --tags
+--max-count=1))
+$ git checkout $TAG
 ```
 
 Next, follow the steps in the git repository's

book/theme/css/chrome.css

@@ -318,7 +318,7 @@ ul#searchresults span.teaser em {
 .sidebar img {
     display: block;
     max-width: 70%;
-    margin: 0 auto;
+    margin: 20px auto;
 }
 .js .sidebar {
     transition: transform 0.3s; /* Animation: slide away */
@@ -443,6 +443,12 @@ ul#searchresults span.teaser em {
     border-top-right-radius: inherit;
 }
 
+.content p {
+    line-height: 1.6;
+    margin-top: 0;
+    padding: 0 28px;
+}
+
 .content h1 {
     font-size: 25px;
     font-weight: 300;
@@ -457,14 +463,10 @@ ul#searchresults span.teaser em {
     font-family: Poppins, sans-serif;
     
 }
-.content p {
-    line-height: 1.6;
-    margin-top: 0;
-    padding: 0 28px;
-}
+
 .content h2 {
     font-family: Poppins, sans-serif;
-    font-size: 15px;
+    font-size: 20px;
     font-weight: 300;
     margin-top: 2em;
     margin-bottom: 0;
@@ -473,12 +475,13 @@ ul#searchresults span.teaser em {
     padding-bottom: 1.2em;
 }
 
-.content h3 {
+.content h3, h4, h5 {
     font-size: 15px;
     margin-top: 2.5em;
     margin-bottom: 0.8em;
     padding: 0 28px;
 }
+
 .content code {
     background-color: rgba(0,0,0,0.05);
     padding: 3px;
@@ -501,15 +504,6 @@ ul#searchresults span.teaser em {
     padding: 2em 28px;
 }
 
-
-.content h4,
-.content h5 {
-    font-size: 15px;
-    margin-top: 2.5em;
-    margin-bottom: 0.8em;
-    padding: 0 28px;
-}
-
 .content table {
     margin-bottom: 1em;
 }

book/theme/css/general.css

@@ -16,7 +16,7 @@ body {
     font-size: 1rem;
     overflow-x: hidden;
     font-family: Lato, 'Helvetica Neue', 'Arial', sans-serif;
-    font-size: 14px;
+    font-size: 16px;
     font-weight: 300;
     -webkit-font-smoothing: antialiased;
     -moz-osx-font-smoothing: grayscale;

book/theme/index.hbs

@@ -76,7 +76,8 @@
         </script>
 
         <nav id="sidebar" class="sidebar" aria-label="Table of contents">
-            <img src="https://manuel-calavera.github.io/images/logo.png" alt="">
+            <img 
+                src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHdpZHRoPSI3NTQiIGhlaWdodD0iMTUxIiB2aWV3Qm94PSIwIDAgNzU0IDE1MSI+PGcgZmlsbD0iI0ZGRiIgZmlsbC1ydWxlPSJldmVub2RkIj48cGF0aCBkPSJNMjY4IDMxaDE2LjQxOXY3NC4yNTVIMzQ5TDMzNS41NjYgMTIwSDI2OHpNNjQuMDAyIDg0LjExM0gyOC4xMjV2LS4wMWMtLjIzNC4wMDctLjQ2OC4wMS0uNzAzLjAxLTE0LjM2OCAwLTI2LjAxNi0xMS44OS0yNi4wMTYtMjYuNTU3QzEuNDA2IDQyLjg5IDEzLjA1NCAzMSAyNy40MjIgMzFjLjIzNSAwIC40Ny4wMDMuNzAzLjAxVjMxSDkwTDcxLjcxOSA0OC4yMjZIMjcuNDA1Yy01LjAzOSAwLTkuMTI0IDQuMTc3LTkuMTI0IDkuMzMgMCA1LjE1NCA0LjA4NSA5LjMzMSA5LjEyNCA5LjMzMWgzOC42ODl2LjA4NkM3OS40NzUgNjguMDcgOTAgNzkuNTAyIDkwIDkzLjQ0MyA5MCAxMDguMTEgNzguMzUyIDEyMCA2My45ODQgMTIwYy0uNzEgMC0xLjQxMy0uMDI5LTIuMTA5LS4wODZWMTIwSDBsMTkuNjg4LTE3LjIyNmg0NC4zMTRjNS4wMzggMCA5LjEyMy00LjE3NyA5LjEyMy05LjMzIDAtNS4xNTQtNC4wODUtOS4zMzEtOS4xMjMtOS4zMzF6TTE1MC40NjkgMzEuMDE1VjMxaDU5LjA2MnYuMDE1YzguMzcyLjM2NiAxNS4wOTYgNy4yMyAxNS40NTQgMTUuNzc1SDIyNXY1NS45ODRoLS4wMTVjLjAxLjIzOC4wMTUuNDc3LjAxNS43MTggMCA4Ljg3Ny02Ljg2MyAxNi4xMTctMTUuNDY5IDE2LjQ5M1YxMjBIMTUwLjQ3di0uMDE1Yy04LjYwNi0uMzc2LTE1LjQ2OS03LjYxNi0xNS40NjktMTYuNDkzIDAtLjI0LjAwNS0uNDguMDE1LS43MThIMTM1VjQ2Ljc5aC4wMTVjLjM1OC04LjU0NiA3LjA4Mi0xNS40MSAxNS40NTQtMTUuNzc1ek0xNjEuNTQzIDQ2LjhjLTUuMjMzLjIzLTkuNDM1IDQuNTQ3LTkuNjU5IDkuOTIzaC0uMDA5djM1LjIxNmguMDFjLS4wMDcuMTUtLjAxLjMtLjAxLjQ1MSAwIDUuNTg0IDQuMjkgMTAuMTM4IDkuNjY4IDEwLjM3NXYuMDFoMzYuOTE0di0uMDFjNS4zNzgtLjIzNyA5LjY2OC00Ljc5MSA5LjY2OC0xMC4zNzUgMC0uMTUxLS4wMDMtLjMwMi0uMDEtLjQ1MWguMDFWNTYuNzIzaC0uMDFjLS4yMjMtNS4zNzYtNC40MjUtOS42OTMtOS42NTgtOS45MjN2LS4wMWgtMzYuOTE0di4wMXpNNDA5Ljg3NSA1NS40MDNWNzIuNjNoNTYuMjVWNTUuNDAzYzAtNS41NS00LjQwNy0xMC4wNDgtOS44NDQtMTAuMDQ4SDQxOS43MmMtNS40MzcgMC05Ljg0NCA0LjQ5OS05Ljg0NCAxMC4wNDh6TTQ2Ni4xMjUgMTIwVjg1LjU0OGgtNTYuMjVWMTIwSDM5M1Y0OC4yMjZoLjAxNWExNy4xNCAxNy4xNCAwIDAgMS0uMDE1LS43MThDMzkzIDM4LjM5MSA0MDAuMjQgMzEgNDA5LjE3MiAzMWMuMjM1IDAgLjQ3LjAwNS43MDMuMDE1VjMxaDU3LjY1NnYuMDE1YzguNjA2LjM3NiAxNS40NjkgNy42MTYgMTUuNDY5IDE2LjQ5MyAwIC4yNC0uMDA1LjQ4LS4wMTUuNzE4SDQ4M1YxMjBoLTE2Ljg3NXpNNjc3Ljg3NSA1NS40MDNWNzIuNjNoNTYuMjVWNTUuNDAzYzAtNS41NS00LjQwNy0xMC4wNDgtOS44NDQtMTAuMDQ4SDY4Ny43MmMtNS40MzcgMC05Ljg0NCA0LjQ5OS05Ljg0NCAxMC4wNDh6TTczNC4xMjUgMTIwVjg1LjU0OGgtNTYuMjVWMTIwSDY2MVY0OC4yMjZoLjAxNWExNy4xNCAxNy4xNCAwIDAgMS0uMDE1LS43MThDNjYxIDM4LjM5MSA2NjguMjQgMzEgNjc3LjE3MiAzMWMuMjM1IDAgLjQ3LjAwNS43MDMuMDE1VjMxaDU3LjY1NnYuMDE1YzguNjA2LjM3NiAxNS40NjkgNy42MTYgMTUuNDY5IDE2LjQ5MyAwIC4yNC0uMDA1LjQ4LS4wMTUuNzE4SDc1MVYxMjBoLTE2Ljg3NXpNNjAxLjEyNSA5OC40NTdWMzFINjE4djg5aC0xNi44NzV2LS4xNDlsLTU2LjI1LTY1Ljg4M1YxMjBINTI4VjMxaDE2Ljg3NXoiLz48L2c+PC9zdmc+" width="150" height="30" alt="Solana">
             {{#toc}}{{/toc}}
         </nav>
 

build-perf-libs.sh

@@ -0,0 +1,19 @@
+#!/usr/bin/env bash
+#
+# Builds perf-libs from the upstream source and installs them into the correct
+# location in the tree
+#
+set -e
+cd "$(dirname "$0")"
+
+if [[ -d target/perf-libs ]]; then
+  echo "target/perf-libs/ already exists, to continue run:"
+  echo "$ rm -rf target/perf-libs"
+  exit 1
+fi
+
+set -x
+git clone git@github.com:solana-labs/solana-perf-libs.git target/perf-libs
+cd target/perf-libs
+make -j"$(nproc)"
+make DESTDIR=. install

build.rs

@@ -1,46 +0,0 @@
-use std::env;
-use std::fs;
-
-fn main() {
-    println!("cargo:rerun-if-changed=build.rs");
-
-    // Ensure target/perf-libs/ exists.  It's been observed that
-    // a cargo:rerun-if-changed= directive with a non-existent
-    // directory triggers a rebuild on every |cargo build| invocation
-    fs::create_dir_all("target/perf-libs").unwrap_or_else(|err| {
-        if err.kind() != std::io::ErrorKind::AlreadyExists {
-            panic!("Unable to create target/perf-libs: {:?}", err);
-        }
-    });
-
-    let chacha = !env::var("CARGO_FEATURE_CHACHA").is_err();
-    let cuda = !env::var("CARGO_FEATURE_CUDA").is_err();
-    let erasure = !env::var("CARGO_FEATURE_ERASURE").is_err();
-
-    if chacha || cuda || erasure {
-        println!("cargo:rerun-if-changed=target/perf-libs");
-        println!("cargo:rustc-link-search=native=target/perf-libs");
-    }
-    if chacha {
-        println!("cargo:rerun-if-changed=target/perf-libs/libcpu-crypt.a");
-    }
-    if cuda {
-        let cuda_home = match env::var("CUDA_HOME") {
-            Ok(cuda_home) => cuda_home,
-            Err(_) => String::from("/usr/local/cuda"),
-        };
-
-        println!("cargo:rerun-if-changed=target/perf-libs/libcuda-crypt.a");
-        println!("cargo:rustc-link-lib=static=cuda-crypt");
-        println!("cargo:rustc-link-search=native={}/lib64", cuda_home);
-        println!("cargo:rustc-link-lib=dylib=cudart");
-        println!("cargo:rustc-link-lib=dylib=cuda");
-        println!("cargo:rustc-link-lib=dylib=cudadevrt");
-    }
-    if erasure {
-        println!("cargo:rerun-if-changed=target/perf-libs/libgf_complete.so");
-        println!("cargo:rerun-if-changed=target/perf-libs/libJerasure.so");
-        println!("cargo:rustc-link-lib=dylib=Jerasure");
-        println!("cargo:rustc-link-lib=dylib=gf_complete");
-    }
-}

ci/buildkite-secondary.yml

@@ -1,12 +1,9 @@
 steps:
-  #- command: "ci/snap.sh"
-  #  timeout_in_minutes: 40
-  #  name: "snap"
   - command: "sdk/docker-solana/build.sh"
     timeout_in_minutes: 20
     name: "publish docker"
   - command: "ci/publish-crate.sh"
-    timeout_in_minutes: 20
+    timeout_in_minutes: 40
     name: "publish crate"
     branches: "!master"
   - command: "ci/publish-bpf-sdk.sh"

ci/buildkite.yml

@@ -1,35 +1,33 @@
 steps:
   - command: "ci/shellcheck.sh"
     name: "shellcheck"
-    timeout_in_minutes: 20
-  - command: "ci/docker-run.sh solanalabs/rust:1.31.0 ci/test-checks.sh"
+    timeout_in_minutes: 5
+  - command: ". ci/rust-version.sh; ci/docker-run.sh $$rust_stable_docker_image ci/test-checks.sh"
     name: "checks"
-    timeout_in_minutes: 30
+    timeout_in_minutes: 15
   - wait
   - command: "ci/test-stable-perf.sh"
     name: "stable-perf"
     timeout_in_minutes: 20
+    artifact_paths: "log-*.txt"
     agents:
       - "queue=cuda"
   - command: "ci/test-bench.sh"
     name: "bench"
-    timeout_in_minutes: 30
-  - command: "ci/docker-run.sh solanalabs/rust:1.31.0 ci/test-stable.sh"
+    timeout_in_minutes: 20
+  - command: ". ci/rust-version.sh; ci/docker-run.sh $$rust_stable_docker_image ci/test-stable.sh"
     name: "stable"
-    timeout_in_minutes: 30
-  - command: "ci/docker-run.sh solanalabs/rust-nightly:2018-12-18 ci/test-coverage.sh"
+    timeout_in_minutes: 25
+    artifact_paths: "log-*.txt"
+  - command: ". ci/rust-version.sh; ci/docker-run.sh $$rust_nightly_docker_image ci/test-coverage.sh"
     name: "coverage"
-    timeout_in_minutes: 30
+    timeout_in_minutes: 20
   # TODO: Fix and re-enable test-large-network.sh
   # - command: "ci/test-large-network.sh || true"
   #   name: "large-network [ignored]"
   #   timeout_in_minutes: 20
   #   agents:
   #     - "queue=large"
-  - command: "ci/pr-snap.sh"
-    timeout_in_minutes: 20
-    name: "snap"
-    branches: "pull/*"
   - wait
   - trigger: "solana-secondary"
     branches: "!pull/*"

ci/channel-info.sh

@@ -82,10 +82,26 @@ for tag in "${tags[@]}"; do
   fi
 done
 
-echo EDGE_CHANNEL=master
-echo BETA_CHANNEL="${beta:+v$beta}"
-echo STABLE_CHANNEL="${stable:+v$stable}"
-echo BETA_CHANNEL_LATEST_TAG="${beta_tag:+v$beta_tag}"
-echo STABLE_CHANNEL_LATEST_TAG="${stable_tag:+v$stable_tag}"
+EDGE_CHANNEL=master
+BETA_CHANNEL=${beta:+v$beta}
+STABLE_CHANNEL=${stable:+v$stable}
+BETA_CHANNEL_LATEST_TAG=${beta_tag:+v$beta_tag}
+STABLE_CHANNEL_LATEST_TAG=${stable_tag:+v$stable_tag}
+
+
+if [[ $BUILDKITE_BRANCH = "$STABLE_CHANNEL" ]]; then
+  CHANNEL=stable
+elif [[ $BUILDKITE_BRANCH = "$EDGE_CHANNEL" ]]; then
+  CHANNEL=edge
+elif [[ $BUILDKITE_BRANCH = "$BETA_CHANNEL" ]]; then
+  CHANNEL=beta
+fi
+
+echo EDGE_CHANNEL="$EDGE_CHANNEL"
+echo BETA_CHANNEL="$BETA_CHANNEL"
+echo BETA_CHANNEL_LATEST_TAG="$BETA_CHANNEL_LATEST_TAG"
+echo STABLE_CHANNEL="$STABLE_CHANNEL"
+echo STABLE_CHANNEL_LATEST_TAG="$STABLE_CHANNEL_LATEST_TAG"
+echo CHANNEL="$CHANNEL"
 
 exit 0

ci/crate-version.sh

@@ -1,17 +1,26 @@
 #!/usr/bin/env bash
 #
-# Outputs the current crate version
+# Outputs the current crate version from a given Cargo.toml
 #
 set -e
 
-cd "$(dirname "$0")"/..
+Cargo_toml=$1
+[[ -n $Cargo_toml ]] || {
+  echo "Usage: $0 path/to/Cargo.toml"
+  exit 0
+}
+
+[[ -r $Cargo_toml ]] || {
+  echo "Error: unable to read $Cargo_toml"
+  exit 1
+}
 
 while read -r name equals value _; do
   if [[ $name = version && $equals = = ]]; then
     echo "${value//\"/}"
     exit 0
   fi
-done < <(cat Cargo.toml)
+done < <(cat "$Cargo_toml")
 
 echo Unable to locate version in Cargo.toml 1>&2
 exit 1

ci/docker-run.sh

@@ -71,7 +71,6 @@ ARGS+=(
   --env CI
   --env CODECOV_TOKEN
   --env CRATES_IO_TOKEN
-  --env SNAPCRAFT_CREDENTIALS_KEY
 )
 
 if $INTERACTIVE; then

ci/docker-rust-nightly/Dockerfile

@@ -4,11 +4,9 @@ ARG date
 RUN set -x \
  && rustup install nightly-$date \
  && rustup show \
- && mv /usr/local/rustup/toolchains/nightly-$date-* \
-       /usr/local/rustup/toolchains/nightly-x86_64-unknown-linux-gnu \
  && rustup show \
  && rustc --version \
  && cargo --version \
- && rustc +nightly --version \
- && cargo +nightly --version
+ && rustc +nightly-$date --version \
+ && cargo +nightly-$date --version
 

ci/docker-rust-nightly/README.md

@@ -15,11 +15,11 @@ To update the pinned version:
 1. Run `ci/docker-rust-nightly/build.sh` to rebuild the nightly image locally,
    or potentially `ci/docker-rust-nightly/build.sh YYYY-MM-DD` if there's a
    specific YYYY-MM-DD that is desired (default is today's build).
-1. Run `SOLANA_DOCKER_RUN_NOSETUID=1 ci/docker-run.sh --nopull solanalabs/rust-nightly:YYYY-MM-DD ci/test-nightly.sh`
+1. Run `SOLANA_DOCKER_RUN_NOSETUID=1 ci/docker-run.sh --nopull solanalabs/rust-nightly:YYYY-MM-DD ci/test-coverage.sh`
    to confirm the new nightly image builds.  Fix any issues as needed
 1. Run `docker login` to enable pushing images to Docker Hub, if you're authorized.
 1. Run `CI=true ci/docker-rust-nightly/build.sh YYYY-MM-DD` to push the new nightly image to dockerhub.com.
-1. Modify the `solanalabs/rust-nightly:YYYY-MM-DD` reference in `ci/buildkite.yml` from the previous to
+1. Modify the `solanalabs/rust-nightly:YYYY-MM-DD` reference in `ci/rust-version.sh` from the previous to
    new *YYYY-MM-DD* value, send a PR with this change and any codebase adjustments needed.
 
 ## Troubleshooting

ci/docker-rust/Dockerfile

@@ -1,6 +1,6 @@
 # Note: when the rust version is changed also modify
 # ci/buildkite.yml to pick up the new image tag
-FROM rust:1.31.0
+FROM rust:1.34.0
 
 RUN set -x \
  && apt update \
@@ -17,6 +17,7 @@ RUN set -x \
       lcov \
       libclang-common-7-dev \
       llvm-7 \
+      mscgen \
       rsync \
       sudo \
       \