propagate TESTNET_DB_HOST env variable to next step in buildkite

* observed_locktower_stats

* fixup! observed_locktower_stats

.appveyor.yml

@@ -1,42 +0,0 @@
-version: '{build}'
-
-branches:
-  only:
-  - master
-  - /^v[0-9.]+\.[0-9.]+/
-
-cache:
-  - '%USERPROFILE%\.cargo'
-  - '%APPVEYOR_BUILD_FOLDER%\target'
-
-clone_folder: d:\projects\solana
-
-build_script:
-  - bash ci/publish-tarball.sh
-
-notifications:
-  - provider: Slack
-    incoming_webhook:
-      secure: GJsBey+F5apAtUm86MHVJ68Uqa6WN1SImcuIc4TsTZrDhA8K1QWUNw9FFQPybUWDyOcS5dly3kubnUqlGt9ux6Ad2efsfRIQYWv0tOVXKeY=
-    channel: ci-status
-    on_build_success: false
-    on_build_failure: true
-    on_build_status_changed: true
-
-deploy:
-  - provider: S3
-    access_key_id:
-      secure: fTbJl6JpFebR40J7cOWZ2mXBa3kIvEiXgzxAj6L3N7A=
-    secret_access_key:
-      secure: vItsBXb2rEFLvkWtVn/Rcxu5a5+2EwC+b7GsA0waJy9hXh6XuBAD0lnHd9re3g/4
-    bucket: release.solana.com
-    region: us-west-1
-    set_public: true
-
-  - provider: GitHub
-    auth_token:
-      secure: 81fEmPZ0cV1wLtNuUrcmtgxKF6ROQF1+/ft5m+fHX21z6PoeCbaNo8cTyLioWBj7
-    draft: false
-    prerelease: false
-    on:
-      appveyor_repo_tag: true

.buildkite/env/.gitignore

@@ -1 +0,0 @@
-/secrets_unencrypted.ejson

.buildkite/env/secrets.ejson

@@ -1,15 +1,12 @@
 {
     "_public_key": "ae29f4f7ad2fc92de70d470e411c8426d5d48db8817c9e3dae574b122192335f",
     "environment": {
-      "CODECOV_TOKEN": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:JnxhrIxh09AvqdJgrVSYmb7PxSrh19aE:07WzVExCHEd1lJ1m8QizRRthGri+WBNeZRKjjEvsy5eo4gv3HD7zVEm42tVTGkqITKkBNQ==]",
+      "CODECOV_TOKEN": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:rHBSqXK7uSnveA4qwUxARZjTNZcA0hXU:ko8lLGwPECpVm19znWBRxKEpMF7xpTHBCEzVOxRar2wDThw4lNDAKqTS61vtkJLtdkHtug==]",
-      "CRATES_IO_TOKEN": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:d0jJqC32/axwzq/N7kMRmpxKhnRrhtpt:zvcPHwkOzGnjhNkAQSejwdy1Jkr9wR1qXFFCnfIjyt/XQYubzB1tLkoly/qdmeb5]",
+      "CRATES_IO_TOKEN": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:NzN6y0ooXJBYvxB589khepthSxhKFkLB:ZTTFZh2A/kB2SAgjJJAMbwAfanRlzxOCNMVcA2MXBCpQHJeeZGULg+0MLACYswfS]",
-      "GEOLOCATION_API_KEY": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:R4gfB6Ey4i50HyfLt4UZDLBqg3qHEUye:UfZCOgt8XI6Y2g+ivCRVoS1fjFycFs7/GSevvCqh1B50mG0+hzpEyzXQLuKG5OeI]",
+      "GITHUB_TOKEN": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:iy0Fnxeo0aslTCvgXc5Ddj2ly6ZsQ8gK:GNOOj/kZUJ2rYKxTbLyVKtajWNoGQ3PcChwfEB4HdN18qDHlB96Z7gx01Pcf0qeIHODOWRtxlH4=]",
-      "GITHUB_TOKEN": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:Vq2dkGTOzfEpRht0BAGHFp/hDogMvXJe:tFXHg1epVt2mq9hkuc5sRHe+KAnVREi/p8S+IZu67XRyzdiA/nGak1k860FXYuuzuaE0QWekaEc=]",
+      "INFLUX_DATABASE": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:Ly/TpIRF0oCxmiBWv225S3mX8s6pfQR+:+tXGB2c9rRCVDcgNO1IDOo89]",
-      "INFLUX_DATABASE": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:5KI9WBkXx3R/W4m256mU5MJOE7N8aAT9:Cb8QFELZ9I60t5zhJ9h55Kcs]",
+      "INFLUX_PASSWORD": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:ycrq1uQLoSfI932czD+krUOaJeLWpeq6:2iS7ukp/C7wVD3IT0GvQVcwccWGyLr4UocStF/XiDi0OB/N3YKIKN8SQU4ob1b6StAPZ/XOHmag=]",
-      "INFLUX_PASSWORD": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:hQRMpLCrav+OYkNphkeM4hagdVoZv5Iw:AUO76rr6+gF1OLJA8ZLSG8wHKXgYCPNk6gRCV8rBhZBJ4KwDaxpvOhMl7bxxXG6jol7v4aRa/Lk=]",
+      "INFLUX_USERNAME": "EJ[1:+7nLVR8NlnN48zgaJPPXF9JOZDXVNHDZLeARlCFHyRk=:35hBKofakZ4Db/u0TOW53RXoNWzJTIcl:HWREcMTrgZ8DGB0ZupgSzNWr/tVyE06P]",
-      "INFLUX_USERNAME": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:R7BNmQjfeqoGDAFTJu9bYTGHol2NgnYN:Q2tOT/EBcFvhFk+DKLKmVU7tLCpVC3Ui]",
+      "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==]"
-      "SOLANA_INSTALL_UPDATE_MANIFEST_KEYPAIR_x86_64_unknown_linux_gnu": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:Egc2dMrHDU0NcZ71LwGv/V66shUhwYUE:04VoIb8CKy7KYhQ5W4cEW9SDKZltxWBL5Hob106lMBbUOD/yUvKYcG3Ep8JfTMwO3K8zowW5HpU/IdGoilX0XWLiJJ6t+p05WWK0TA16nOEtwrEG+UK8wm3sN+xCO20i4jDhpNpgg3FYFHT5rKTHW8+zaBTNUX/SFxkN67Lm+92IM28CXYE43SU1WV6H99hGFFVpTK5JVM3JuYU1ex/dHRE+xCzTr4MYUB/F+nGoNFW8HUDV/y0e1jxT9to3x0SmnytEEuk+5RUzFuEt9cKNFeNml3fOCi4qL+sfj/Y5pjH9xDiUxsvH/8NL35jbLP244aFHgWcp]",
-      "SOLANA_INSTALL_UPDATE_MANIFEST_KEYPAIR_x86_64_apple_darwin": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:NeOxSoWCvXB9AL4H6OK26l/7bmsKd/oz:Ijfoxtvk2CHlN1ZXHup3Gg/914kbbAkEGWJfvozA8UIe+aUzUObMyTrKkVOeNAH8Q8YH9tNzk7RRnrTcpnzeCCBLlWcVEeruMxHox3mPRzmSeDLxtbzCl9VePlRO3T7jg90K5hW+ZAkd5J/WJNzpAcmr93ts/of3MbvGHSujId/efCTzJEcP6JInnBb8Vrj7TlgKbzUlnqpq1+NjYPSXN3maKa9pKeo2JWxZlGBMoy6QWUUY5GbYEylw9smwh1LJcHZjlaZNMuOl4gNKtaSr38IXQkAXaRUJDPAmPras00YObKzXU8RkTrP4EoP/jx5LPR7f]",
-      "SOLANA_INSTALL_UPDATE_MANIFEST_KEYPAIR_x86_64_pc_windows_msvc": "EJ[1:yGpTmjdbyjW2kjgIHkFoJv7Ue7EbUvUbqHyw6anGgWg=:7t+56twjW+jR7fpFNNeRFLPd7E4lbmyN:JuviDpkQrfVcNUGRGsa2e/UhvH6tTYyk1s4cHHE5xZH1NByL7Kpqx36VG/+o1AUGEeSQdsBnKgzYdMoFYbO8o50DoRPc86QIEVXCupD6J9avxLFtQgOWgJp+/mCdUVXlqXiFs/vQgS/L4psrcKdF6WHd77BeUr6ll8DjH+9m5FC9Rcai2pXno6VbPpunHQ0oUdYzhFR64+LiRacBaefQ9igZ+nSEWDLqbaZSyfm9viWkijoVFTq8gAgdXXEh7g0QdxVE5T6bPristJhT6jWBhWunPUCDNFFErWIsbRGctepl4pbCWqh2hNTw9btSgVfeY6uGCOsdy9E=]"
     }
 }

.buildkite/hooks/post-checkout

@@ -1,8 +1,6 @@
 CI_BUILD_START=$(date +%s)
 export CI_BUILD_START
 
-source ci/env.sh
-
 #
 # Kill any running docker containers, which are potentially left over from the
 # previous CI job
@@ -33,10 +31,3 @@ source ci/env.sh
     kill -9 "$victim" || true
   done
 )
-
-# HACK: These are in our docker images, need to be removed from CARGO_HOME
-#  because we try to cache downloads across builds with CARGO_HOME
-# cargo lacks a facility for "system" tooling, always tries CARGO_HOME first
-cargo uninstall cargo-audit || true
-cargo uninstall svgbob_cli || true
-cargo uninstall mdbook || true

.buildkite/hooks/post-command

@@ -10,8 +10,6 @@
   set -x
   rsync -a --delete --link-dest="$PWD" target "$d"
   du -hs "$d"
-  read -r cacheSizeInGB _ < <(du -s --block-size=1800000000 "$d")
-  echo "--- ${cacheSizeInGB}GB: $d"
 )
 
 #

.buildkite/hooks/pre-command

@@ -14,18 +14,14 @@ export PS4="++"
 (
   set -x
   d=$HOME/cargo-target-cache/"$BUILDKITE_LABEL"
-  MAX_CACHE_SIZE=18 # gigabytes
 
   if [[ -d $d ]]; then
     du -hs "$d"
-    read -r cacheSizeInGB _ < <(du -s --block-size=1800000000 "$d")
+    read -r cacheSizeInGB _ < <(du -s --block-size=1000000000 "$d")
-    echo "--- ${cacheSizeInGB}GB: $d"
+    if [[ $cacheSizeInGB -gt 10 ]]; then
-    if [[ $cacheSizeInGB -gt $MAX_CACHE_SIZE ]]; then
+      echo "$d has gotten too large, removing it"
-      echo "--- $d is too large, removing it"
       rm -rf "$d"
     fi
-  else
-    echo "--- $d not present"
   fi
 
   mkdir -p "$d"/target

.buildkite/pipeline-upload.sh

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

.gitbook.yaml

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

.github/stale.yml

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

.gitignore

@@ -1,24 +1,23 @@
-/book/html/
-/book/src/tests.ok
-/book/src/.gitbook/assets/*.svg
-/farf/
-/solana-release/
-/solana-release.tar.bz2
-/solana-metrics/
-/solana-metrics.tar.bz2
 /target/
+/ledger-tool/target/
+/wallet/target/
+/core/target/
+/book/html/
+/book/src/img/
+/book/src/tests.ok
 
 **/*.rs.bk
 .cargo
 
+# node config that is rsynced
 /config/
+# node config that remains local
+/config-local/
 
 # log files
 *.log
 log-*.txt
-log-*/
 
 # intellij files
 /.idea/
 /solana.iml
-/.vscode/

.mergify.yml

@@ -1,45 +0,0 @@
-# Validate your changes with:
-#
-#   $ curl -F 'data=@.mergify.yml' https://gh.mergify.io/validate
-#
-# https://doc.mergify.io/
-pull_request_rules:
-  - name: remove outdated reviews
-    conditions:
-      - base=master
-    actions:
-      dismiss_reviews:
-        changes_requested: true
-  - name: set automerge label on mergify backport PRs
-    conditions:
-      - author=mergify[bot]
-      - head~=^mergify/bp/
-      - "#status-failure=0"
-    actions:
-      label:
-        add:
-          - automerge
-  - name: v0.22 backport
-    conditions:
-      - base=master
-      - label=v0.22
-    actions:
-      backport:
-        branches:
-          - v0.22
-  - name: v0.23 backport
-    conditions:
-      - base=master
-      - label=v0.23
-    actions:
-      backport:
-        branches:
-          - v0.23
-  - name: v0.24 backport
-    conditions:
-      - base=master
-      - label=v0.24
-    actions:
-      backport:
-        branches:
-          - v0.24

.travis.yml

@@ -1,42 +0,0 @@
-os:
-  - osx
-
-language: rust
-rust:
-  - stable
-
-install:
-  - source ci/rust-version.sh
-
-script:
-  - source ci/env.sh
-  - ci/publish-tarball.sh
-
-branches:
-  only:
-    - master
-    - /^v\d+\.\d+/
-
-notifications:
-  slack:
-    on_success: change
-    secure: F4IjOE05MyaMOdPRL+r8qhs7jBvv4yDM3RmFKE1zNXnfUOqV4X38oQM1EI+YVsgpMQLj/pxnEB7wcTE4Bf86N6moLssEULCpvAuMVoXj4QbWdomLX+01WbFa6fLVeNQIg45NHrz2XzVBhoKOrMNnl+QI5mbR2AlS5oqsudHsXDnyLzZtd4Y5SDMdYG1zVWM01+oNNjgNfjcCGmOE/K0CnOMl6GPi3X9C34tJ19P2XT7MTDsz1/IfEF7fro2Q8DHEYL9dchJMoisXSkem5z7IDQkGzXsWdWT4NnndUvmd1MlTCE9qgoXDqRf95Qh8sB1Dz08HtvgfaosP2XjtNTfDI9BBYS15Ibw9y7PchAJE1luteNjF35EOy6OgmCLw/YpnweqfuNViBZz+yOPWXVC0kxnPIXKZ1wyH9ibeH6E4hr7a8o9SV/6SiWIlbYF+IR9jPXyTCLP/cc3sYljPWxDnhWFwFdRVIi3PbVAhVu7uWtVUO17Oc9gtGPgs/GrhOMkJfwQPXaudRJDpVZowxTX4x9kefNotlMAMRgq+Drbmgt4eEBiCNp0ITWgh17BiE1U09WS3myuduhoct85+FoVeaUkp1sxzHVtGsNQH0hcz7WcpZyOM+AwistJA/qzeEDQao5zi1eKWPbO2xAhi2rV1bDH6bPf/4lDBwLRqSiwvlWU=
-
-deploy:
-  - provider: s3
-    access_key_id: $AWS_ACCESS_KEY_ID
-    secret_access_key: $AWS_SECRET_ACCESS_KEY
-    bucket: release.solana.com
-    region: us-west-1
-    skip_cleanup: true
-    acl: public_read
-    local_dir: travis-s3-upload
-    on:
-      all_branches: true
-  - provider: releases
-    api_key: $GITHUB_TOKEN
-    skip_cleanup: true
-    file_glob: true
-    file: travis-release-upload/*
-    on:
-      tags: true

CONTRIBUTING.md

@@ -1,41 +1,23 @@
-# Solana Coding Guidelines
+Solana Coding Guidelines
+===
 
-The goal of these guidelines is to improve developer productivity by allowing
+The goal of these guidelines is to improve developer productivity by allowing developers to
-developers to jump into any file in the codebase and not need to adapt to
+jump any file in the codebase and not need to adapt to inconsistencies in how the code is
-inconsistencies in how the code is written. The codebase should appear as if it
+written. The codebase should appear as if it had been authored by a single developer. If you
-had been authored by a single developer. If you don't agree with a convention,
+don't agree with a convention, submit a PR patching this document and let's discuss! Once
-submit a PR patching this document and let's discuss! Once the PR is accepted,
+the PR is accepted, *all* code should be updated as soon as possible to reflect the new
-*all* code should be updated as soon as possible to reflect the new
 conventions.
 
-## Pull Requests
+Pull Requests
+---
 
-Small, frequent PRs are much preferred to large, infrequent ones. A large PR is
+Small, frequent PRs are much preferred to large, infrequent ones. A large PR is difficult
-difficult to review, can block others from making progress, and can quickly get
+to review, can block others from making progress, and can quickly get its author into
-its author into "rebase hell". A large PR oftentimes arises when one change
+"rebase hell". A large PR oftentimes arises when one change requires another, which requires
-requires another, which requires another, and then another. When you notice
+another, and then another. When you notice those dependencies, put the fix into a commit of
-those dependencies, put the fix into a commit of its own, then checkout a new
+its own, then checkout a new branch, and cherrypick it. Open a PR to start the review
-branch, and cherry-pick it.
+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 commit -am "Fix foo, needed by bar"
-$ git checkout master
-$ git checkout -b fix-foo
-$ git cherry-pick fix-bar
-$ git push --set-upstream origin fix-foo
-```
-
-Open a PR to start the review process and then jump back to your original
-branch to keep making progress. Consider rebasing to make your fix the first
-commit:
-
-```bash
-$ git checkout fix-bar
-$ git rebase -i master <Move fix-foo to top>
-```
-
-Once the commit is merged, rebase the original branch to purge the
-cherry-picked commit:
 
 ```bash
 $ git pull --rebase upstream master
@@ -43,207 +25,88 @@ $ 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
+If there are no functional changes, PRs can be very large and that's no problem. If,
-problem. If, however, your changes are making meaningful changes or additions,
+however, your changes are making meaningful changes or additions, then about 1,000 lines of
-then about 1,000 lines of changes is about the most you should ask a Solana
+changes is about the most you should ask a Solana maintainer to review.
-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
+Add only code to the codebase that is ready to be deployed. If you are building a large
-a large library, consider developing it in a separate git repository. When it
+library, consider developing it in a separate git repository. When it is ready to be
-is ready to be integrated, the Solana maintainers will work with you to decide
+integrated, the Solana maintainers will work with you to decide on a path forward. Smaller
-on a path forward. Smaller libraries may be copied in whereas very large ones
+libraries may be copied in whereas very large ones may be pulled in with a package manager.
-may be pulled in with a package manager.
-
-## Getting Pull Requests Merged
-
-There is no single person assigned to watching GitHub PR queue and ushering you
-through the process. Typically, you will ask the person that wrote a component
-to review changes to it. You can find the author using `git blame` or asking on
-Discord.  When working to get your PR merged, it's most important to understand
-that changing the code is your priority and not necessarily a priority of the
-person you need an approval from. Also, while you may interact the most with
-the component author, you should aim to be inclusive of others. Providing a
-detailed problem description is the most effective means of engaging both the
-component author and other potentially interested parties.
-
-Consider opening all PRs as Draft Pull Requests first. Using a draft PR allows
-you to kickstart the CI automation, which typically takes between 10 and 30
-minutes to execute. Use that time to write a detailed problem description. Once
-the description is written and CI succeeds, click the "Ready to Review" button
-and add reviewers. Adding reviewers before CI succeeds is a fast path to losing
-reviewer engagement. Not only will they be notified and see the PR is not yet
-ready for them, they will also be bombarded them with additional notifications
-each time you push a commit to get past CI or until they "mute" the PR. Once
-muted, you'll need to reach out over some other medium, such as Discord, to
-request they have another look. When you use draft PRs, no notifications are
-sent when you push commits and edit the PR description. Use draft PRs
-liberally.  Don't bug the humans until you have gotten past the bots.
-
-### What should be in my PR description?
-
-Reviewing code is hard work and generally involves an attempt to guess the
-author's intent at various levels. Please assume reviewer time is scarce and do
-what you can to make your PR as consumable as possible. Inspired by techniques
-for writing good whitepapers, the guidance here aims to maximize reviewer
-engagement.
-
-Assume the reviewer will spend no more than a few seconds reading the PR title.
-If it doesn't describe a noteworthy change, don't expect the reviewer to click
-to see more.
-
-Next, like the abstract of a whitepaper, the reviewer will spend ~30 seconds
-reading the PR problem description. If what is described there doesn't look
-more important than competing issues, don't expect the reviewer to read on.
-
-Next, the reviewer will read the proposed changes. At this point, the reviewer
-needs to be convinced the proposed changes are a *good* solution to the problem
-described above.  If the proposed changes, not the code changes, generates
-discussion, consider closing the PR and returning with a design proposal
-instead.
-
-Finally, once the reviewer understands the problem and agrees with the approach
-to solving it, the reviewer will view the code changes. At this point, the
-reviewer is simply looking to see if the implementation actually implements
-what was proposed and if that implementation is maintainable. When a concise,
-readable test for each new code path is present, the reviewer can safely ignore
-the details of its implementation. When those tests are missing, expect to
-either lose engagement or get a pile of review comments as the reviewer
-attempts to consider every ambiguity in your implementation.
-
-### The PR Title
-
-The PR title should contain a brief summary of the change, from the perspective
-of the user. Examples of good titles:
-
-* Add rent to accounts
-* Fix out-of-memory error in validator
-* Clean up `process_message()` in runtime
-
-The conventions here are all the same as a good git commit title:
-
-* First word capitalized and in the imperative mood, not past tense ("add", not
-  "added")
-* No trailing period
-* What was done, whom it was done to, and in what context
-
-### The PR Problem Statement
-
-The git repo implements a product with various features. The problem statement
-should describe how the product is missing a feature, how a feature is
-incomplete, or how the implementation of a feature is somehow undesirable. If
-an issue being fixed already describes the problem, go ahead and copy-paste it.
-As mentioned above, reviewer time is scarce. Given a queue of PRs to review,
-the reviewer may ignore PRs that expect them to click through links to see if
-the PR warrants attention.
-
-### The Proposed Changes
-
-Typically the content under the "Proposed changes" section will be a bulleted
-list of steps taken to solve the problem. Oftentimes, the list is identical to
-the subject lines of the git commits contained in the PR. It's especially
-generous (and not expected) to rebase or reword commits such that each change
-matches the logical flow in your PR description.
 
 ### When will my PR be reviewed?
 
-PRs are typically reviewed and merged in under 7 days. If your PR has been open
+PRs are typically reviewed and merged in under 7 days. If your PR has been open for longer,
-for longer, it's a strong indicator that the reviewers aren't confident the
+it's a strong indicator that the reviewers aren't confident the change meets the quality
-change meets the quality standards of the codebase. You might consider closing
+standards of the codebase. You might consider closing it and coming back with smaller PRs
-it and coming back with smaller PRs and longer descriptions detailing what
+and longer descriptions detailing what problem it solves and how it solves it.
-problem it solves and how it solves it. Old PRs will be marked stale and then
-closed automatically 7 days later.
 
-### How to manage review feedback?
+Draft Pull Requests
+---
 
-After a reviewer provides feedback, you can quickly say "acknowledged, will
+If you want early feedback on your PR, use GitHub's "Draft Pull Request" mechanism. Draft
-fix" using a thumb's up emoji. If you're confident your fix is exactly as
+PRs are a convenient way to collaborate with the Solana maintainers without triggering
-prescribed, add a reply "Fixed in COMMIT\_HASH" and mark the comment as
+notifications as you make changes. When you feel your PR is ready for a broader audience,
-resolved. If you're not sure, reply "Is this what you had in mind?
+you can transition your draft PR to a standard PR with the click of a button.
-COMMIT\_HASH" and if so, the reviewer will reply and mark the conversation as
-resolved. Marking conversations as resolved is an excellent way to engage more
-reviewers. Leaving conversations open may imply the PR is not yet ready for
-additional review.
 
-### When will my PR be re-reviewed?
+Rust coding conventions
+---
 
-Recall that once your PR is opened, a notification is sent every time you push
+* All Rust code is formatted using the latest version of `rustfmt`. Once installed, it will be
-a commit.  After a reviewer adds feedback, they won't be checking on the status
+  updated automatically when you update the compiler with `rustup`.
-of that feedback after every new commit. Instead, directly mention the reviewer
-when you feel your PR is ready for another pass.
 
-## Draft Pull Requests
+* All Rust code is linted with Clippy. If you'd prefer to ignore its advice, do so explicitly:
 
-If you want early feedback on your PR, use GitHub's "Draft Pull Request"
+  ```rust
-mechanism. Draft PRs are a convenient way to collaborate with the Solana
+  #[allow(clippy::too_many_arguments)]
-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
-
-* All Rust code is formatted using the latest version of `rustfmt`. Once
-  installed, it will be updated automatically when you update the compiler with
-`rustup`.
-
-* All Rust code is linted with Clippy. If you'd prefer to ignore its advice, do
-  so explicitly:
-
-  ```rust #[allow(clippy::too_many_arguments)] ```
 
   Note: Clippy defaults can be overridden in the top-level file `.clippy.toml`.
 
-* For variable names, when in doubt, spell it out. The mapping from type names
+* For variable names, when in doubt, spell it out. The mapping from type names to variable names
-  to variable names is to lowercase the type name, putting an underscore before
+  is to lowercase the type name, putting an underscore before each capital letter. Variable names
-each capital letter. Variable names should *not* be abbreviated unless being
+  should *not* be abbreviated unless being used as closure arguments and the brevity improves
-used as closure arguments and the brevity improves readability. When a function
+  readability. When a function has multiple instances of the same type, qualify each with a
-has multiple instances of the same type, qualify each with a prefix and
+  prefix and underscore (i.e. alice_keypair) or a numeric suffix (i.e. tx0).
-underscore (i.e. alice\_keypair) or a numeric suffix (i.e. tx0).
 
-* For function and method names, use `<verb>_<subject>`. For unit tests, that
+* For function and method names, use `<verb>_<subject>`. For unit tests, that verb should
-  verb should always be `test` and for benchmarks the verb should always be
+  always be `test` and for benchmarks the verb should always be `bench`. Avoid namespacing
-`bench`. Avoid namespacing function names with some arbitrary word. Avoid
+  function names with some arbitrary word. Avoid abbreviating words in function names.
-abbreviating words in function names.
 
-* As they say, "When in Rome, do as the Romans do." A good patch should
+* As they say, "When in Rome, do as the Romans do." A good patch should acknowledge the coding
-  acknowledge the coding conventions of the code that surrounds it, even in the
+  conventions of the code that surrounds it, even in the case where that code has not yet been
-case where that code has not yet been updated to meet the conventions described
+  updated to meet the conventions described here.
-here.
 
 
-## Terminology
+Terminology
+---
 
-Inventing new terms is allowed, but should only be done when the term is widely
+Inventing new terms is allowed, but should only be done when the term is widely used and
-used and understood. Avoid introducing new 3-letter terms, which can be
+understood. Avoid introducing new 3-letter terms, which can be confused with 3-letter acronyms.
-confused with 3-letter acronyms.
 
 [Terms currently in use](book/src/terminology.md)
 
 
-## Design Proposals
+Proposing architectural changes
+---
 
 Solana's architecture is described by a book generated from markdown files in
 the `book/src/` directory, maintained by an *editor* (currently @garious). To
-add a design proposal, you'll need to at least propose a change the content
+change the architecture, you'll need to at least propose a change the content
-under the [Accepted Design
+under the [Proposed
-Proposals](https://docs.solana.com/book/v/master/proposals) chapter.  Here's
+Changes](https://solana-labs.github.io/book-edge/proposals.html) chapter. Here's
 the full process:
 
-1. Propose a design by creating a PR that adds a markdown document to the
+1. Propose to a change to the architecture by creating a PR that adds a
-   directory `book/src/` and references it from the [table of
+   markdown document to the directory `book/src/` and references it from the
-   contents](book/src/SUMMARY.md). Add any relevant *maintainers* to the PR
+   [table of contents](book/src/SUMMARY.md). Add the editor and any relevant
-   review.
+   *maintainers* to the PR review.
 2. The PR being merged indicates your proposed change was accepted and that the
-   maintainers support your plan of attack.
+   editor and maintainers support your plan of attack.
 3. Submit PRs that implement the proposal. When the implementation reveals the
-   need for tweaks to the proposal, be sure to update the proposal and have that
+   need for tweaks to the architecture, be sure to update the proposal and have
-   change reviewed by the same people as in step 1.
+   that change reviewed by the same people as in step 1.
-4. Once the implementation is complete, submit a PR that moves the link from
+4. Once the implementation is complete, the editor will then work to integrate
-   the Accepted Proposals to the Implemented Proposals section.
+   the document into the book.

Cargo.toml

@@ -1,64 +1,92 @@
+[package]
+name = "solana-workspace"
+description = "Blockchain, Rebuilt for Scale"
+version = "0.12.2"
+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]
+chacha = ["solana/chacha"]
+cuda = ["solana/cuda"]
+erasure = ["solana/erasure"]
+
+[dev-dependencies]
+bincode = "1.1.2"
+bs58 = "0.2.0"
+hashbrown = "0.1.8"
+log = "0.4.2"
+rand = "0.6.5"
+rayon = "1.0.0"
+reqwest = "0.9.11"
+serde_json = "1.0.39"
+solana = { path = "core", version = "0.12.2" }
+solana-budget-program = { path = "programs/budget", version = "0.12.2" }
+solana-client = { path = "client", version = "0.12.2" }
+solana-logger = { path = "logger", version = "0.12.2" }
+solana-netutil = { path = "netutil", version = "0.12.2" }
+solana-runtime = { path = "runtime", version = "0.12.2" }
+solana-sdk = { path = "sdk", version = "0.12.2" }
+solana-vote-api = { path = "programs/vote_api", version = "0.12.2" }
+sys-info = "0.5.6"
+
+[[bench]]
+name = "banking_stage"
+
+[[bench]]
+name = "blocktree"
+
+[[bench]]
+name = "ledger"
+
+[[bench]]
+name = "gen_keys"
+
+[[bench]]
+name = "sigverify"
+
+[[bench]]
+required-features = ["chacha"]
+name = "chacha"
+
 [workspace]
 members = [
-    "bench-exchange",
+    ".",
     "bench-streamer",
     "bench-tps",
-    "banking-bench",
-    "chacha",
-    "chacha-cuda",
-    "chacha-sys",
-    "cli-config",
-    "client",
     "core",
-    "faucet",
+    "drone",
-    "perf",
+    "fullnode",
-    "validator",
     "genesis",
-    "genesis-programs",
-    "gossip",
-    "install",
     "keygen",
-    "ledger",
     "ledger-tool",
-    "local-cluster",
     "logger",
-    "log-analyzer",
-    "merkle-tree",
-    "measure",
     "metrics",
-    "net-shaper",
+    "programs/bpf",
     "programs/bpf_loader",
     "programs/budget",
-    "programs/btc_spv",
+    "programs/budget_api",
-    "programs/btc_spv_bin",
+    "programs/token",
-    "programs/config",
+    "programs/token_api",
-    "programs/exchange",
     "programs/failure",
     "programs/noop",
-    "programs/ownable",
+    "programs/rewards",
-    "programs/stake",
+    "programs/rewards_api",
     "programs/storage",
-    "programs/vest",
+    "programs/storage_api",
     "programs/vote",
-    "archiver",
+    "programs/vote_api",
-    "archiver-lib",
+    "replicator",
-    "archiver-utils",
-    "remote-wallet",
-    "runtime",
     "sdk",
-    "sdk-c",
-    "scripts",
-    "sys-tuner",
     "upload-perf",
-    "net-utils",
     "vote-signer",
-    "cli",
+    "wallet",
-    "rayon-threadlimit",
-    "watchtower",
-]
-
-exclude = [
-    "programs/bpf",
-    "programs/move_loader",
-    "programs/librapay",
 ]
+exclude = ["programs/bpf/rust/noop"]

README.md

@@ -1,5 +1,5 @@
-[![Solana crate](https://img.shields.io/crates/v/solana-core.svg)](https://crates.io/crates/solana-core)
+[![Solana crate](https://img.shields.io/crates/v/solana.svg)](https://crates.io/crates/solana)
-[![Solana documentation](https://docs.rs/solana-core/badge.svg)](https://docs.rs/solana-core)
+[![Solana documentation](https://docs.rs/solana/badge.svg)](https://docs.rs/solana)
 [![Build status](https://badge.buildkite.com/8cc350de251d61483db98bdfc895b9ea0ac8ffa4a32ee850ed.svg?branch=master)](https://buildkite.com/solana-labs/solana/builds?branch=master)
 [![codecov](https://codecov.io/gh/solana-labs/solana/branch/master/graph/badge.svg)](https://codecov.io/gh/solana-labs/solana)
 
@@ -26,43 +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://docs.solana.com/book/).
+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://docs.solana.com/book/v/master/).)
+(The _latest_ development version of the online book is also [available here](https://solana-labs.github.io/book-edge/).)
-
-Release Binaries
-===
-Official release binaries are available at [Github Releases](https://github.com/solana-labs/solana/releases).
-
-Additionally we provide pre-release binaries for the latest code on the edge and
-beta channels.  Note that these pre-release binaries may be less stable than an
-official release.
-
-### Edge channel
-#### Linux (x86_64-unknown-linux-gnu)
-* [solana.tar.bz2](http://release.solana.com/edge/solana-release-x86_64-unknown-linux-gnu.tar.bz2)
-* [solana-install-init](http://release.solana.com/edge/solana-install-init-x86_64-unknown-linux-gnu) as a stand-alone executable
-#### mac OS (x86_64-apple-darwin)
-* [solana.tar.bz2](http://release.solana.com/edge/solana-release-x86_64-apple-darwin.tar.bz2)
-* [solana-install-init](http://release.solana.com/edge/solana-install-init-x86_64-apple-darwin) as a stand-alone executable
-#### Windows (x86_64-pc-windows-msvc)
-* [solana.tar.bz2](http://release.solana.com/edge/solana-release-x86_64-pc-windows-msvc.tar.bz2)
-* [solana-install-init.exe](http://release.solana.com/edge/solana-install-init-x86_64-pc-windows-msvc.exe) as a stand-alone executable
-#### All platforms
-* [solana-metrics.tar.bz2](http://release.solana.com.s3.amazonaws.com/edge/solana-metrics.tar.bz2)
-
-### Beta channel
-#### Linux (x86_64-unknown-linux-gnu)
-* [solana.tar.bz2](http://release.solana.com/beta/solana-release-x86_64-unknown-linux-gnu.tar.bz2)
-* [solana-install-init](http://release.solana.com/beta/solana-install-init-x86_64-unknown-linux-gnu) as a stand-alone executable
-#### mac OS (x86_64-apple-darwin)
-* [solana.tar.bz2](http://release.solana.com/beta/solana-release-x86_64-apple-darwin.tar.bz2)
-* [solana-install-init](http://release.solana.com/beta/solana-install-init-x86_64-apple-darwin) as a stand-alone executable
-#### Windows (x86_64-pc-windows-msvc)
-* [solana.tar.bz2](http://release.solana.com/beta/solana-release-x86_64-pc-windows-msvc.tar.bz2)
-* [solana-install-init.exe](http://release.solana.com/beta/solana-install-init-x86_64-pc-windows-msvc.exe) as a stand-alone executable
-#### All platforms
-* [solana-metrics.tar.bz2](http://release.solana.com.s3.amazonaws.com/beta/solana-metrics.tar.bz2)
 
 Developing
 ===
@@ -75,10 +41,10 @@ Install rustc, cargo and rustfmt:
 ```bash
 $ curl https://sh.rustup.rs -sSf | sh
 $ source $HOME/.cargo/env
-$ rustup component add rustfmt
+$ rustup component add rustfmt-preview
 ```
 
-If your rustc version is lower than 1.39.0, please update it:
+If your rustc version is lower than 1.31.0, please update it:
 
 ```bash
 $ rustup update
@@ -100,7 +66,7 @@ $ cd solana
 Build
 
 ```bash
-$ cargo build
+$ cargo build --all
 ```
 
 Then to run a minimal local cluster
@@ -114,22 +80,31 @@ Testing
 Run the test suite:
 
 ```bash
-$ cargo test
+$ 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://docs.solana.com/book/getting-started).
+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
 ---
 
 We maintain several testnets:
 
-* `testnet` - public stable testnet accessible via testnet.solana.com. Runs 24/7
+* `testnet` - public stable testnet accessible via testnet.solana.com, with an https proxy for web apps at api.testnet.solana.com. Runs 24/7
 * `testnet-beta` - public beta channel testnet accessible via beta.testnet.solana.com. Runs 24/7
 * `testnet-edge` - public edge channel testnet accessible via edge.testnet.solana.com. Runs 24/7
+* `testnet-perf` - permissioned stable testnet running a 24/7 soak test
+* `testnet-beta-perf` - permissioned beta channel testnet running a multi-hour soak test weekday mornings
+* `testnet-edge-perf` - permissioned edge channel testnet running a multi-hour soak test weekday mornings
 
 ## Deploy process
 
@@ -156,47 +131,6 @@ 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
 ---
 
@@ -240,3 +174,5 @@ problem is solved by this code?" On the other hand, if a test does fail and you
 better way to solve the same problem, a Pull Request with your solution would most certainly be
 welcome! Likewise, if rewriting a test can better communicate what code it's protecting, please
 send us that patch!
+
+

RELEASE.md

@@ -59,127 +59,47 @@ There are three release channels that map to branches as follows:
 * beta - tracks the largest (and latest) `vX.Y` stabilization branch, more stable.
 * stable - tracks the second largest `vX.Y` stabilization branch, most stable.
 
-## Steps to Create a Branch
+## Release Steps
 
-### Create the new branch
+### Changing channels
-1. Check out the latest commit on `master` branch:
+
-    ```
+When cutting a new channel branch these pre-steps are required:
-    git fetch --all
+
-    git checkout upstream/master
+1. Pick your branch point for release on master.
-    ```
+1. Create the branch.  The name should be "v" + the first 2 "version" fields
-1. Determine the new branch name.  The name should be "v" + the first 2 version fields
    from Cargo.toml.  For example, a Cargo.toml with version = "0.9.0" implies
    the next branch name is "v0.9".
-1. Create the new branch and push this branch to the `solana` repository:
+1. Push the new branch to the solana repository
-    ```
+1. Update Cargo.toml on master to the next semantic version (e.g. 0.9.0 -> 0.10.0)
-    git checkout -b <branchname>
+   by running `./scripts/increment-cargo-version.sh`, then rebuild with a
-    git push -u origin <branchname>
+   `cargo build --all` to cause a refresh of `Cargo.lock`.
-    ```
+1. Push your Cargo.toml change and the autogenerated Cargo.lock changes to the
+   master branch
 
-### Update master branch with the next version
+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".
 
-1. After the new branch has been created and pushed, update the Cargo.toml files on **master** to the next semantic version (e.g. 0.9.0 -> 0.10.0) with:
+### Updating channels (i.e. "making a release")
-     ```
-     scripts/increment-cargo-version.sh minor
-     ```
-1. Rebuild to get an updated version of `Cargo.lock`:
-    ```
-    cargo build
-    ```
-1. Push all the changed Cargo.toml and Cargo.lock files to the `master` branch with something like:
-    ```
-    git co -b version_update
-    git ls-files -m | xargs git add
-    git commit -m 'Update Cargo.toml versions from X.Y to X.Y+1'
-    git push -u origin version_update
-    ```
-1. Confirm that your freshly cut release branch is shown as `BETA_CHANNEL` and the previous release branch as `STABLE_CHANNEL`:
-    ```
-    ci/channel_info.sh
-    ```
 
-## Steps to Create a Release
+We use [github's Releases UI](https://github.com/solana-labs/solana/releases) for tagging a release.
 
-### Create the Release Tag on GitHub
+1. Go [there ;)](https://github.com/solana-labs/solana/releases).
-
-1. Go to [GitHub's Releases UI](https://github.com/solana-labs/solana/releases) for tagging a release.
 1. Click "Draft new release".  The release tag must exactly match the `version`
-   field in `/Cargo.toml` prefixed by `v`.
+   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 the first major release on the branch (e.g. v0.8.0), paste in [this
-1. Make sure the Target Branch field matches the branch you want to make a release on.
+   template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md)
-   1.  If you want to release v0.12.0, the target branch must be v0.12
+   and fill it in.
-1. If this is the first release on the branch (e.g. v0.13.**0**), paste in [this
+1. Test the release by generating a tag using semver's rules.  First try at a
-   template](https://raw.githubusercontent.com/solana-labs/solana/master/.github/RELEASE_TEMPLATE.md).  Engineering Lead can provide summary contents for release notes if needed.
+   release should be `<branchname>.X-rc.0`.
-1. Click "Save Draft", then confirm the release notes look good and the tag name and branch are correct.  Go back into edit the release and click "Publish release" when ready.
+1. Verify release automation:
-
+   1. [Crates.io](https://crates.io/crates/solana) should have an updated Solana version.
-### Update release branch with the next patch version
+   1. ...
-
+1. After testnet deployment, verify that testnets are running correct software.
-1. After the new release has been tagged, update the Cargo.toml files on **release branch** to the next semantic version (e.g. 0.9.0 -> 0.9.1) with:
+   http://metrics.solana.com should show testnet running on a hash from your
-     ```
+   newly created branch.
-     scripts/increment-cargo-version.sh patch
+1. 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
-1. Rebuild to get an updated version of `Cargo.lock`:
+   `./scripts/increment-cargo-version.sh patch`, then rebuild with a `cargo
-    ```
+   build --all` to cause a refresh of `Cargo.lock`.
-    cargo build
+1. Push your Cargo.toml change and the autogenerated Cargo.lock changes to the
-    ```
+   release branch
-1. Push all the changed Cargo.toml and Cargo.lock files to the **release branch** with something like:
-    ```
-    git co -b version_update
-    git ls-files -m | xargs git add
-    git commit -m 'Update Cargo.toml versions from X.Y.Z to X.Y.Z+1'
-    git push -u origin version_update
-    ```
-
-### Verify release automation success
-1. Go to [Solana Releases](https://github.com/solana-labs/solana/releases) and click on the latest release that you just published.  Verify that all of the build artifacts are present.  This can take up to 90 minutes after creating the tag.
-1. The `solana-secondary` Buildkite pipeline handles creating the binary tarballs and updated crates.  Look for a job under the tag name of the release: https://buildkite.com/solana-labs/solana-secondary
-1. [Crates.io](https://crates.io/crates/solana) should have an updated Solana version.
-
-### Update documentation
-TODO: Documentation update procedure is WIP as we move to gitbook
-
-Document the new recommended version by updating `book/src/running-archiver.md` and `book/src/validator-testnet.md` on the release (beta) branch to point at the `solana-install` for the upcoming release version.
-
-### Update software on testnet.solana.com
-
-The testnet running on testnet.solana.com is set to use a fixed release tag
-which is set in the Buildkite testnet-management pipeline.
-This tag needs to be updated and the testnet restarted after a new release
-tag is created.
-
-#### Update testnet schedules
-
-Go to https://buildkite.com/solana-labs and click through: Pipelines ->
-testnet-management -> Pipeline Settings -> Schedules
-Or just click here:
-https://buildkite.com/solana-labs/testnet-management/settings/schedules
-
-There are two scheduled jobs for testnet: a daily restart and an hourly sanity-or-restart. \
-https://buildkite.com/solana-labs/testnet-management/settings/schedules/0efd7856-7143-4713-8817-47e6bdb05387
-https://buildkite.com/solana-labs/testnet-management/settings/schedules/2a926646-d972-42b5-aeb9-bb6759592a53
-
-On each schedule:
-1.  Set TESTNET_TAG environment variable to the desired release tag.
-    1. Example, TESTNET_TAG=v0.13.2
-1.  Set the Build Branch to the branch that TESTNET_TAG is from.
-    1. Example: v0.13
-
-#### Restart the testnet
-
-Trigger a TESTNET_OP=create-and-start to refresh the cluster with the new version
-
-1.  Go to https://buildkite.com/solana-labs/testnet-management
-2.  Click "New Build" and use the following settings, then click "Create Build"
-    1.  Commit: HEAD
-    1.  Branch: [channel branch as set in the schedules]
-    1.  Environment Variables:
-```
-TESTNET=testnet
-TESTNET_TAG=[same value as used in TESTNET_TAG in the schedules]
-TESTNET_OP=create-and-start
-```
-
-### Alert the community
-
-Notify Discord users on #validator-support that a new release for
-testnet.solana.com is available

archiver-lib/Cargo.toml

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

archiver-lib/src/archiver.rs

@@ -1,945 +0,0 @@
-use crate::result::ArchiverError;
-use crossbeam_channel::unbounded;
-use ed25519_dalek;
-use rand::{thread_rng, Rng, SeedableRng};
-use rand_chacha::ChaChaRng;
-use solana_archiver_utils::sample_file;
-use solana_chacha::chacha::{chacha_cbc_encrypt_ledger, CHACHA_BLOCK_SIZE};
-use solana_client::{
-    rpc_client::RpcClient, rpc_request::RpcRequest, rpc_response::RpcStorageTurn,
-    thin_client::ThinClient,
-};
-use solana_core::{
-    cluster_info::{ClusterInfo, Node, VALIDATOR_PORT_RANGE},
-    contact_info::ContactInfo,
-    gossip_service::GossipService,
-    packet::{limited_deserialize, PACKET_DATA_SIZE},
-    repair_service,
-    repair_service::{RepairService, RepairSlotRange, RepairStrategy},
-    serve_repair::ServeRepair,
-    shred_fetch_stage::ShredFetchStage,
-    sigverify_stage::{DisabledSigVerifier, SigVerifyStage},
-    storage_stage::NUM_STORAGE_SAMPLES,
-    streamer::{receiver, responder, PacketReceiver},
-    window_service::WindowService,
-};
-use solana_ledger::{
-    blockstore::Blockstore, leader_schedule_cache::LeaderScheduleCache, shred::Shred,
-};
-use solana_net_utils::bind_in_range;
-use solana_perf::packet::Packets;
-use solana_perf::recycler::Recycler;
-use solana_sdk::packet::Packet;
-use solana_sdk::{
-    account_utils::StateMut,
-    client::{AsyncClient, SyncClient},
-    clock::{get_complete_segment_from_slot, get_segment_from_slot, Slot},
-    commitment_config::CommitmentConfig,
-    hash::Hash,
-    message::Message,
-    signature::{Keypair, KeypairUtil, Signature},
-    timing::timestamp,
-    transaction::Transaction,
-    transport::TransportError,
-};
-use solana_storage_program::{
-    storage_contract::StorageContract,
-    storage_instruction::{self, StorageAccountType},
-};
-use std::{
-    io::{self, ErrorKind},
-    net::{SocketAddr, UdpSocket},
-    path::{Path, PathBuf},
-    result,
-    sync::atomic::{AtomicBool, Ordering},
-    sync::mpsc::{channel, Receiver, Sender},
-    sync::{Arc, RwLock},
-    thread::{sleep, spawn, JoinHandle},
-    time::Duration,
-};
-
-type Result<T> = std::result::Result<T, ArchiverError>;
-
-static ENCRYPTED_FILENAME: &str = "ledger.enc";
-
-#[derive(Serialize, Deserialize)]
-pub enum ArchiverRequest {
-    GetSlotHeight(SocketAddr),
-}
-
-pub struct Archiver {
-    thread_handles: Vec<JoinHandle<()>>,
-    exit: Arc<AtomicBool>,
-}
-
-// Shared Archiver Meta struct used internally
-#[derive(Default)]
-struct ArchiverMeta {
-    slot: Slot,
-    slots_per_segment: u64,
-    ledger_path: PathBuf,
-    signature: Signature,
-    ledger_data_file_encrypted: PathBuf,
-    sampling_offsets: Vec<u64>,
-    blockhash: Hash,
-    sha_state: Hash,
-    num_chacha_blocks: usize,
-    client_commitment: CommitmentConfig,
-}
-
-fn get_slot_from_signature(
-    signature: &ed25519_dalek::Signature,
-    storage_turn: u64,
-    slots_per_segment: u64,
-) -> u64 {
-    let signature_vec = signature.to_bytes();
-    let mut segment_index = u64::from(signature_vec[0])
-        | (u64::from(signature_vec[1]) << 8)
-        | (u64::from(signature_vec[1]) << 16)
-        | (u64::from(signature_vec[2]) << 24);
-    let max_segment_index =
-        get_complete_segment_from_slot(storage_turn, slots_per_segment).unwrap();
-    segment_index %= max_segment_index as u64;
-    segment_index * slots_per_segment
-}
-
-fn create_request_processor(
-    socket: UdpSocket,
-    exit: &Arc<AtomicBool>,
-    slot_receiver: Receiver<u64>,
-) -> Vec<JoinHandle<()>> {
-    let mut thread_handles = vec![];
-    let (s_reader, r_reader) = channel();
-    let (s_responder, r_responder) = channel();
-    let storage_socket = Arc::new(socket);
-    let recycler = Recycler::default();
-    let t_receiver = receiver(storage_socket.clone(), exit, s_reader, recycler, "archiver");
-    thread_handles.push(t_receiver);
-
-    let t_responder = responder("archiver-responder", storage_socket, r_responder);
-    thread_handles.push(t_responder);
-
-    let exit = exit.clone();
-    let t_processor = spawn(move || {
-        let slot = poll_for_slot(slot_receiver, &exit);
-
-        loop {
-            if exit.load(Ordering::Relaxed) {
-                break;
-            }
-
-            let packets = r_reader.recv_timeout(Duration::from_secs(1));
-
-            if let Ok(packets) = packets {
-                for packet in &packets.packets {
-                    let req: result::Result<ArchiverRequest, Box<bincode::ErrorKind>> =
-                        limited_deserialize(&packet.data[..packet.meta.size]);
-                    match req {
-                        Ok(ArchiverRequest::GetSlotHeight(from)) => {
-                            let packet = Packet::from_data(&from, slot);
-                            let _ = s_responder.send(Packets::new(vec![packet]));
-                        }
-                        Err(e) => {
-                            info!("invalid request: {:?}", e);
-                        }
-                    }
-                }
-            }
-        }
-    });
-    thread_handles.push(t_processor);
-    thread_handles
-}
-
-fn poll_for_slot(receiver: Receiver<u64>, exit: &Arc<AtomicBool>) -> u64 {
-    loop {
-        let slot = receiver.recv_timeout(Duration::from_secs(1));
-        if let Ok(slot) = slot {
-            return slot;
-        }
-        if exit.load(Ordering::Relaxed) {
-            return 0;
-        }
-    }
-}
-
-impl Archiver {
-    /// Returns a Result that contains an archiver on success
-    ///
-    /// # Arguments
-    /// * `ledger_path` - path to where the ledger will be stored.
-    /// Causes panic if none
-    /// * `node` - The archiver node
-    /// * `cluster_entrypoint` - ContactInfo representing an entry into the network
-    /// * `keypair` - Keypair for this archiver
-    #[allow(clippy::new_ret_no_self)]
-    pub fn new(
-        ledger_path: &Path,
-        node: Node,
-        cluster_entrypoint: ContactInfo,
-        keypair: Arc<Keypair>,
-        storage_keypair: Arc<Keypair>,
-        client_commitment: CommitmentConfig,
-    ) -> Result<Self> {
-        let exit = Arc::new(AtomicBool::new(false));
-
-        info!("Archiver: id: {}", keypair.pubkey());
-        info!("Creating cluster info....");
-        let mut cluster_info = ClusterInfo::new(node.info.clone(), keypair.clone());
-        cluster_info.set_entrypoint(cluster_entrypoint.clone());
-        let cluster_info = Arc::new(RwLock::new(cluster_info));
-
-        // Note for now, this ledger will not contain any of the existing entries
-        // in the ledger located at ledger_path, and will only append on newly received
-        // entries after being passed to window_service
-        let blockstore = Arc::new(
-            Blockstore::open(ledger_path).expect("Expected to be able to open database ledger"),
-        );
-
-        let gossip_service = GossipService::new(&cluster_info, None, node.sockets.gossip, &exit);
-
-        info!("Connecting to the cluster via {:?}", cluster_entrypoint);
-        let (nodes, _) =
-            match solana_core::gossip_service::discover_cluster(&cluster_entrypoint.gossip, 1) {
-                Ok(nodes_and_archivers) => nodes_and_archivers,
-                Err(e) => {
-                    //shutdown services before exiting
-                    exit.store(true, Ordering::Relaxed);
-                    gossip_service.join()?;
-                    return Err(e.into());
-                }
-            };
-        let client = solana_core::gossip_service::get_client(&nodes);
-
-        info!("Setting up mining account...");
-        if let Err(e) = Self::setup_mining_account(
-            &client,
-            &keypair,
-            &storage_keypair,
-            client_commitment.clone(),
-        ) {
-            //shutdown services before exiting
-            exit.store(true, Ordering::Relaxed);
-            gossip_service.join()?;
-            return Err(e);
-        };
-
-        let repair_socket = Arc::new(node.sockets.repair);
-        let shred_sockets: Vec<Arc<UdpSocket>> =
-            node.sockets.tvu.into_iter().map(Arc::new).collect();
-        let shred_forward_sockets: Vec<Arc<UdpSocket>> = node
-            .sockets
-            .tvu_forwards
-            .into_iter()
-            .map(Arc::new)
-            .collect();
-        let (shred_fetch_sender, shred_fetch_receiver) = channel();
-        let fetch_stage = ShredFetchStage::new(
-            shred_sockets,
-            shred_forward_sockets,
-            repair_socket.clone(),
-            &shred_fetch_sender,
-            &exit,
-        );
-        let (slot_sender, slot_receiver) = channel();
-        let request_processor =
-            create_request_processor(node.sockets.storage.unwrap(), &exit, slot_receiver);
-
-        let t_archiver = {
-            let exit = exit.clone();
-            let node_info = node.info.clone();
-            let mut meta = ArchiverMeta {
-                ledger_path: ledger_path.to_path_buf(),
-                client_commitment,
-                ..ArchiverMeta::default()
-            };
-            spawn(move || {
-                // setup archiver
-                let window_service = match Self::setup(
-                    &mut meta,
-                    cluster_info.clone(),
-                    &blockstore,
-                    &exit,
-                    &node_info,
-                    &storage_keypair,
-                    repair_socket,
-                    shred_fetch_receiver,
-                    slot_sender,
-                ) {
-                    Ok(window_service) => window_service,
-                    Err(e) => {
-                        //shutdown services before exiting
-                        error!("setup failed {:?}; archiver thread exiting...", e);
-                        exit.store(true, Ordering::Relaxed);
-                        request_processor
-                            .into_iter()
-                            .for_each(|t| t.join().unwrap());
-                        fetch_stage.join().unwrap();
-                        gossip_service.join().unwrap();
-                        return;
-                    }
-                };
-
-                info!("setup complete");
-                // run archiver
-                Self::run(
-                    &mut meta,
-                    &blockstore,
-                    cluster_info,
-                    &keypair,
-                    &storage_keypair,
-                    &exit,
-                );
-                // wait until exit
-                request_processor
-                    .into_iter()
-                    .for_each(|t| t.join().unwrap());
-                fetch_stage.join().unwrap();
-                gossip_service.join().unwrap();
-                window_service.join().unwrap()
-            })
-        };
-
-        Ok(Self {
-            thread_handles: vec![t_archiver],
-            exit,
-        })
-    }
-
-    fn run(
-        meta: &mut ArchiverMeta,
-        blockstore: &Arc<Blockstore>,
-        cluster_info: Arc<RwLock<ClusterInfo>>,
-        archiver_keypair: &Arc<Keypair>,
-        storage_keypair: &Arc<Keypair>,
-        exit: &Arc<AtomicBool>,
-    ) {
-        // encrypt segment
-        Self::encrypt_ledger(meta, blockstore).expect("ledger encrypt not successful");
-        let enc_file_path = meta.ledger_data_file_encrypted.clone();
-        // do replicate
-        loop {
-            if exit.load(Ordering::Relaxed) {
-                break;
-            }
-
-            // TODO check if more segments are available - based on space constraints
-            Self::create_sampling_offsets(meta);
-            let sampling_offsets = &meta.sampling_offsets;
-            meta.sha_state =
-                match Self::sample_file_to_create_mining_hash(&enc_file_path, sampling_offsets) {
-                    Ok(hash) => hash,
-                    Err(err) => {
-                        warn!("Error sampling file, exiting: {:?}", err);
-                        break;
-                    }
-                };
-
-            Self::submit_mining_proof(meta, &cluster_info, archiver_keypair, storage_keypair);
-
-            // TODO make this a lot more frequent by picking a "new" blockhash instead of picking a storage blockhash
-            // prep the next proof
-            let (storage_blockhash, _) = match Self::poll_for_blockhash_and_slot(
-                &cluster_info,
-                meta.slots_per_segment,
-                &meta.blockhash,
-                exit,
-            ) {
-                Ok(blockhash_and_slot) => blockhash_and_slot,
-                Err(e) => {
-                    warn!(
-                        "Error couldn't get a newer blockhash than {:?}. {:?}",
-                        meta.blockhash, e
-                    );
-                    break;
-                }
-            };
-            meta.blockhash = storage_blockhash;
-            Self::redeem_rewards(
-                &cluster_info,
-                archiver_keypair,
-                storage_keypair,
-                meta.client_commitment.clone(),
-            );
-        }
-        exit.store(true, Ordering::Relaxed);
-    }
-
-    fn redeem_rewards(
-        cluster_info: &Arc<RwLock<ClusterInfo>>,
-        archiver_keypair: &Arc<Keypair>,
-        storage_keypair: &Arc<Keypair>,
-        client_commitment: CommitmentConfig,
-    ) {
-        let nodes = cluster_info.read().unwrap().tvu_peers();
-        let client = solana_core::gossip_service::get_client(&nodes);
-
-        if let Ok(Some(account)) =
-            client.get_account_with_commitment(&storage_keypair.pubkey(), client_commitment.clone())
-        {
-            if let Ok(StorageContract::ArchiverStorage { validations, .. }) = account.state() {
-                if !validations.is_empty() {
-                    let ix = storage_instruction::claim_reward(
-                        &archiver_keypair.pubkey(),
-                        &storage_keypair.pubkey(),
-                    );
-                    let message =
-                        Message::new_with_payer(vec![ix], Some(&archiver_keypair.pubkey()));
-                    if let Err(e) = client.send_message(&[&archiver_keypair], message) {
-                        error!("unable to redeem reward, tx failed: {:?}", e);
-                    } else {
-                        info!(
-                            "collected mining rewards: Account balance {:?}",
-                            client.get_balance_with_commitment(
-                                &archiver_keypair.pubkey(),
-                                client_commitment
-                            )
-                        );
-                    }
-                }
-            }
-        } else {
-            info!("Redeem mining reward: No account data found");
-        }
-    }
-
-    // Find a segment to replicate and download it.
-    fn setup(
-        meta: &mut ArchiverMeta,
-        cluster_info: Arc<RwLock<ClusterInfo>>,
-        blockstore: &Arc<Blockstore>,
-        exit: &Arc<AtomicBool>,
-        node_info: &ContactInfo,
-        storage_keypair: &Arc<Keypair>,
-        repair_socket: Arc<UdpSocket>,
-        shred_fetch_receiver: PacketReceiver,
-        slot_sender: Sender<u64>,
-    ) -> Result<WindowService> {
-        let slots_per_segment =
-            match Self::get_segment_config(&cluster_info, meta.client_commitment.clone()) {
-                Ok(slots_per_segment) => slots_per_segment,
-                Err(e) => {
-                    error!("unable to get segment size configuration, exiting...");
-                    //shutdown services before exiting
-                    exit.store(true, Ordering::Relaxed);
-                    return Err(e);
-                }
-            };
-        let (segment_blockhash, segment_slot) = match Self::poll_for_segment(
-            &cluster_info,
-            slots_per_segment,
-            &Hash::default(),
-            exit,
-        ) {
-            Ok(blockhash_and_slot) => blockhash_and_slot,
-            Err(e) => {
-                //shutdown services before exiting
-                exit.store(true, Ordering::Relaxed);
-                return Err(e);
-            }
-        };
-        let signature = storage_keypair.sign(segment_blockhash.as_ref());
-        let slot = get_slot_from_signature(&signature, segment_slot, slots_per_segment);
-        info!("replicating slot: {}", slot);
-        slot_sender.send(slot)?;
-        meta.slot = slot;
-        meta.slots_per_segment = slots_per_segment;
-        meta.signature = Signature::new(&signature.to_bytes());
-        meta.blockhash = segment_blockhash;
-
-        let mut repair_slot_range = RepairSlotRange::default();
-        repair_slot_range.end = slot + slots_per_segment;
-        repair_slot_range.start = slot;
-
-        let (retransmit_sender, _) = channel();
-
-        let (verified_sender, verified_receiver) = unbounded();
-
-        let _sigverify_stage = SigVerifyStage::new(
-            shred_fetch_receiver,
-            verified_sender,
-            DisabledSigVerifier::default(),
-        );
-
-        let window_service = WindowService::new(
-            blockstore.clone(),
-            cluster_info.clone(),
-            verified_receiver,
-            retransmit_sender,
-            repair_socket,
-            &exit,
-            RepairStrategy::RepairRange(repair_slot_range),
-            &Arc::new(LeaderScheduleCache::default()),
-            |_, _, _, _| true,
-        );
-        info!("waiting for ledger download");
-        Self::wait_for_segment_download(
-            slot,
-            slots_per_segment,
-            &blockstore,
-            &exit,
-            &node_info,
-            cluster_info,
-        );
-        Ok(window_service)
-    }
-
-    fn wait_for_segment_download(
-        start_slot: Slot,
-        slots_per_segment: u64,
-        blockstore: &Arc<Blockstore>,
-        exit: &Arc<AtomicBool>,
-        node_info: &ContactInfo,
-        cluster_info: Arc<RwLock<ClusterInfo>>,
-    ) {
-        info!(
-            "window created, waiting for ledger download starting at slot {:?}",
-            start_slot
-        );
-        let mut current_slot = start_slot;
-        'outer: loop {
-            while blockstore.is_full(current_slot) {
-                current_slot += 1;
-                info!("current slot: {}", current_slot);
-                if current_slot >= start_slot + slots_per_segment {
-                    break 'outer;
-                }
-            }
-            if exit.load(Ordering::Relaxed) {
-                break;
-            }
-            sleep(Duration::from_secs(1));
-        }
-
-        info!("Done receiving entries from window_service");
-
-        // Remove archiver from the data plane
-        let mut contact_info = node_info.clone();
-        contact_info.tvu = "0.0.0.0:0".parse().unwrap();
-        contact_info.wallclock = timestamp();
-        // copy over the adopted shred_version from the entrypoint
-        contact_info.shred_version = cluster_info.read().unwrap().my_data().shred_version;
-        {
-            let mut cluster_info_w = cluster_info.write().unwrap();
-            cluster_info_w.insert_self(contact_info);
-        }
-    }
-
-    fn encrypt_ledger(meta: &mut ArchiverMeta, blockstore: &Arc<Blockstore>) -> Result<()> {
-        meta.ledger_data_file_encrypted = meta.ledger_path.join(ENCRYPTED_FILENAME);
-
-        {
-            let mut ivec = [0u8; 64];
-            ivec.copy_from_slice(&meta.signature.as_ref());
-
-            let num_encrypted_bytes = chacha_cbc_encrypt_ledger(
-                blockstore,
-                meta.slot,
-                meta.slots_per_segment,
-                &meta.ledger_data_file_encrypted,
-                &mut ivec,
-            )?;
-
-            meta.num_chacha_blocks = num_encrypted_bytes / CHACHA_BLOCK_SIZE;
-        }
-
-        info!(
-            "Done encrypting the ledger: {:?}",
-            meta.ledger_data_file_encrypted
-        );
-        Ok(())
-    }
-
-    fn create_sampling_offsets(meta: &mut ArchiverMeta) {
-        meta.sampling_offsets.clear();
-        let mut rng_seed = [0u8; 32];
-        rng_seed.copy_from_slice(&meta.blockhash.as_ref());
-        let mut rng = ChaChaRng::from_seed(rng_seed);
-        for _ in 0..NUM_STORAGE_SAMPLES {
-            meta.sampling_offsets
-                .push(rng.gen_range(0, meta.num_chacha_blocks) as u64);
-        }
-    }
-
-    fn sample_file_to_create_mining_hash(
-        enc_file_path: &Path,
-        sampling_offsets: &[u64],
-    ) -> Result<Hash> {
-        let sha_state = sample_file(enc_file_path, sampling_offsets)?;
-        info!("sampled sha_state: {}", sha_state);
-        Ok(sha_state)
-    }
-
-    fn setup_mining_account(
-        client: &ThinClient,
-        keypair: &Keypair,
-        storage_keypair: &Keypair,
-        client_commitment: CommitmentConfig,
-    ) -> Result<()> {
-        // make sure archiver has some balance
-        info!("checking archiver keypair...");
-        if client.poll_balance_with_timeout_and_commitment(
-            &keypair.pubkey(),
-            &Duration::from_millis(100),
-            &Duration::from_secs(5),
-            client_commitment.clone(),
-        )? == 0
-        {
-            return Err(ArchiverError::EmptyStorageAccountBalance);
-        }
-
-        info!("checking storage account keypair...");
-        // check if the storage account exists
-        let balance = client
-            .poll_get_balance_with_commitment(&storage_keypair.pubkey(), client_commitment.clone());
-        if balance.is_err() || balance.unwrap() == 0 {
-            let blockhash =
-                match client.get_recent_blockhash_with_commitment(client_commitment.clone()) {
-                    Ok((blockhash, _)) => blockhash,
-                    Err(e) => {
-                        return Err(ArchiverError::TransportError(e));
-                    }
-                };
-
-            let ix = storage_instruction::create_storage_account(
-                &keypair.pubkey(),
-                &keypair.pubkey(),
-                &storage_keypair.pubkey(),
-                1,
-                StorageAccountType::Archiver,
-            );
-            let tx = Transaction::new_signed_instructions(&[keypair], ix, blockhash);
-            let signature = client.async_send_transaction(tx)?;
-            client
-                .poll_for_signature_with_commitment(&signature, client_commitment)
-                .map_err(|err| match err {
-                    TransportError::IoError(e) => e,
-                    TransportError::TransactionError(_) => io::Error::new(
-                        ErrorKind::Other,
-                        "setup_mining_account: signature not found",
-                    ),
-                })?;
-        }
-        Ok(())
-    }
-
-    fn submit_mining_proof(
-        meta: &ArchiverMeta,
-        cluster_info: &Arc<RwLock<ClusterInfo>>,
-        archiver_keypair: &Arc<Keypair>,
-        storage_keypair: &Arc<Keypair>,
-    ) {
-        // No point if we've got no storage account...
-        let nodes = cluster_info.read().unwrap().tvu_peers();
-        let client = solana_core::gossip_service::get_client(&nodes);
-        let storage_balance = client.poll_get_balance_with_commitment(
-            &storage_keypair.pubkey(),
-            meta.client_commitment.clone(),
-        );
-        if storage_balance.is_err() || storage_balance.unwrap() == 0 {
-            error!("Unable to submit mining proof, no storage account");
-            return;
-        }
-        // ...or no lamports for fees
-        let balance = client.poll_get_balance_with_commitment(
-            &archiver_keypair.pubkey(),
-            meta.client_commitment.clone(),
-        );
-        if balance.is_err() || balance.unwrap() == 0 {
-            error!("Unable to submit mining proof, insufficient Archiver Account balance");
-            return;
-        }
-
-        let blockhash =
-            match client.get_recent_blockhash_with_commitment(meta.client_commitment.clone()) {
-                Ok((blockhash, _)) => blockhash,
-                Err(_) => {
-                    error!("unable to get recent blockhash, can't submit proof");
-                    return;
-                }
-            };
-        let instruction = storage_instruction::mining_proof(
-            &storage_keypair.pubkey(),
-            meta.sha_state,
-            get_segment_from_slot(meta.slot, meta.slots_per_segment),
-            Signature::new(&meta.signature.as_ref()),
-            meta.blockhash,
-        );
-        let message = Message::new_with_payer(vec![instruction], Some(&archiver_keypair.pubkey()));
-        let mut transaction = Transaction::new(
-            &[archiver_keypair.as_ref(), storage_keypair.as_ref()],
-            message,
-            blockhash,
-        );
-        if let Err(err) = client.send_and_confirm_transaction(
-            &[&archiver_keypair, &storage_keypair],
-            &mut transaction,
-            10,
-            0,
-        ) {
-            error!("Error: {:?}; while sending mining proof", err);
-        }
-    }
-
-    pub fn close(self) {
-        self.exit.store(true, Ordering::Relaxed);
-        self.join()
-    }
-
-    pub fn join(self) {
-        for handle in self.thread_handles {
-            handle.join().unwrap();
-        }
-    }
-
-    fn get_segment_config(
-        cluster_info: &Arc<RwLock<ClusterInfo>>,
-        client_commitment: CommitmentConfig,
-    ) -> Result<u64> {
-        let rpc_peers = {
-            let cluster_info = cluster_info.read().unwrap();
-            cluster_info.all_rpc_peers()
-        };
-        debug!("rpc peers: {:?}", rpc_peers);
-        if !rpc_peers.is_empty() {
-            let rpc_client = {
-                let node_index = thread_rng().gen_range(0, rpc_peers.len());
-                RpcClient::new_socket(rpc_peers[node_index].rpc)
-            };
-            Ok(rpc_client
-                .send(
-                    &RpcRequest::GetSlotsPerSegment,
-                    serde_json::json!([client_commitment]),
-                    0,
-                )
-                .map_err(|err| {
-                    warn!("Error while making rpc request {:?}", err);
-                    ArchiverError::ClientError(err)
-                })?
-                .as_u64()
-                .unwrap())
-        } else {
-            Err(ArchiverError::NoRpcPeers)
-        }
-    }
-
-    /// Waits until the first segment is ready, and returns the current segment
-    fn poll_for_segment(
-        cluster_info: &Arc<RwLock<ClusterInfo>>,
-        slots_per_segment: u64,
-        previous_blockhash: &Hash,
-        exit: &Arc<AtomicBool>,
-    ) -> Result<(Hash, u64)> {
-        loop {
-            let (blockhash, turn_slot) = Self::poll_for_blockhash_and_slot(
-                cluster_info,
-                slots_per_segment,
-                previous_blockhash,
-                exit,
-            )?;
-            if get_complete_segment_from_slot(turn_slot, slots_per_segment).is_some() {
-                return Ok((blockhash, turn_slot));
-            }
-        }
-    }
-
-    /// Poll for a different blockhash and associated max_slot than `previous_blockhash`
-    fn poll_for_blockhash_and_slot(
-        cluster_info: &Arc<RwLock<ClusterInfo>>,
-        slots_per_segment: u64,
-        previous_blockhash: &Hash,
-        exit: &Arc<AtomicBool>,
-    ) -> Result<(Hash, u64)> {
-        info!("waiting for the next turn...");
-        loop {
-            let rpc_peers = {
-                let cluster_info = cluster_info.read().unwrap();
-                cluster_info.all_rpc_peers()
-            };
-            debug!("rpc peers: {:?}", rpc_peers);
-            if !rpc_peers.is_empty() {
-                let rpc_client = {
-                    let node_index = thread_rng().gen_range(0, rpc_peers.len());
-                    RpcClient::new_socket(rpc_peers[node_index].rpc)
-                };
-                let response = rpc_client
-                    .send(
-                        &RpcRequest::GetStorageTurn,
-                        serde_json::value::Value::Null,
-                        0,
-                    )
-                    .map_err(|err| {
-                        warn!("Error while making rpc request {:?}", err);
-                        ArchiverError::ClientError(err)
-                    })?;
-                let RpcStorageTurn {
-                    blockhash: storage_blockhash,
-                    slot: turn_slot,
-                } = serde_json::from_value::<RpcStorageTurn>(response)
-                    .map_err(ArchiverError::JsonError)?;
-                let turn_blockhash = storage_blockhash.parse().map_err(|err| {
-                    io::Error::new(
-                        io::ErrorKind::Other,
-                        format!(
-                            "Blockhash parse failure: {:?} on {:?}",
-                            err, storage_blockhash
-                        ),
-                    )
-                })?;
-                if turn_blockhash != *previous_blockhash {
-                    info!("turn slot: {}", turn_slot);
-                    if get_segment_from_slot(turn_slot, slots_per_segment) != 0 {
-                        return Ok((turn_blockhash, turn_slot));
-                    }
-                }
-            }
-            if exit.load(Ordering::Relaxed) {
-                return Err(ArchiverError::IO(io::Error::new(
-                    ErrorKind::Other,
-                    "exit signalled...",
-                )));
-            }
-            sleep(Duration::from_secs(5));
-        }
-    }
-
-    /// Ask an archiver to populate a given blockstore with its segment.
-    /// Return the slot at the start of the archiver's segment
-    ///
-    /// It is recommended to use a temporary blockstore for this since the download will not verify
-    /// shreds received and might impact the chaining of shreds across slots
-    pub fn download_from_archiver(
-        serve_repair: &ServeRepair,
-        archiver_info: &ContactInfo,
-        blockstore: &Arc<Blockstore>,
-        slots_per_segment: u64,
-    ) -> Result<u64> {
-        // Create a client which downloads from the archiver and see that it
-        // can respond with shreds.
-        let start_slot = Self::get_archiver_segment_slot(archiver_info.storage_addr);
-        info!("Archiver download: start at {}", start_slot);
-
-        let exit = Arc::new(AtomicBool::new(false));
-        let (s_reader, r_reader) = channel();
-        let repair_socket = Arc::new(bind_in_range(VALIDATOR_PORT_RANGE).unwrap().1);
-        let t_receiver = receiver(
-            repair_socket.clone(),
-            &exit,
-            s_reader,
-            Recycler::default(),
-            "archiver_reeciver",
-        );
-        let id = serve_repair.keypair().pubkey();
-        info!(
-            "Sending repair requests from: {} to: {}",
-            serve_repair.my_info().id,
-            archiver_info.gossip
-        );
-        let repair_slot_range = RepairSlotRange {
-            start: start_slot,
-            end: start_slot + slots_per_segment,
-        };
-        // try for upto 180 seconds //TODO needs tuning if segments are huge
-        for _ in 0..120 {
-            // Strategy used by archivers
-            let repairs = RepairService::generate_repairs_in_range(
-                blockstore,
-                repair_service::MAX_REPAIR_LENGTH,
-                &repair_slot_range,
-            );
-            //iter over the repairs and send them
-            if let Ok(repairs) = repairs {
-                let reqs: Vec<_> = repairs
-                    .into_iter()
-                    .filter_map(|repair_request| {
-                        serve_repair
-                            .map_repair_request(&repair_request)
-                            .map(|result| ((archiver_info.gossip, result), repair_request))
-                            .ok()
-                    })
-                    .collect();
-
-                for ((to, req), repair_request) in reqs {
-                    if let Ok(local_addr) = repair_socket.local_addr() {
-                        datapoint_info!(
-                            "archiver_download",
-                            ("repair_request", format!("{:?}", repair_request), String),
-                            ("to", to.to_string(), String),
-                            ("from", local_addr.to_string(), String),
-                            ("id", id.to_string(), String)
-                        );
-                    }
-                    repair_socket
-                        .send_to(&req, archiver_info.gossip)
-                        .unwrap_or_else(|e| {
-                            error!("{} repair req send_to({}) error {:?}", id, to, e);
-                            0
-                        });
-                }
-            }
-            let res = r_reader.recv_timeout(Duration::new(1, 0));
-            if let Ok(mut packets) = res {
-                while let Ok(mut more) = r_reader.try_recv() {
-                    packets.packets.append_pinned(&mut more.packets);
-                }
-                let shreds: Vec<Shred> = packets
-                    .packets
-                    .into_iter()
-                    .filter_map(|p| Shred::new_from_serialized_shred(p.data.to_vec()).ok())
-                    .collect();
-                blockstore.insert_shreds(shreds, None, false)?;
-            }
-            // check if all the slots in the segment are complete
-            if Self::segment_complete(start_slot, slots_per_segment, blockstore) {
-                break;
-            }
-            sleep(Duration::from_millis(500));
-        }
-        exit.store(true, Ordering::Relaxed);
-        t_receiver.join().unwrap();
-
-        // check if all the slots in the segment are complete
-        if !Self::segment_complete(start_slot, slots_per_segment, blockstore) {
-            return Err(ArchiverError::SegmentDownloadError);
-        }
-        Ok(start_slot)
-    }
-
-    fn segment_complete(
-        start_slot: Slot,
-        slots_per_segment: u64,
-        blockstore: &Arc<Blockstore>,
-    ) -> bool {
-        for slot in start_slot..(start_slot + slots_per_segment) {
-            if !blockstore.is_full(slot) {
-                return false;
-            }
-        }
-        true
-    }
-
-    fn get_archiver_segment_slot(to: SocketAddr) -> u64 {
-        let (_port, socket) = bind_in_range(VALIDATOR_PORT_RANGE).unwrap();
-        socket
-            .set_read_timeout(Some(Duration::from_secs(5)))
-            .unwrap();
-
-        let req = ArchiverRequest::GetSlotHeight(socket.local_addr().unwrap());
-        let serialized_req = bincode::serialize(&req).unwrap();
-        for _ in 0..10 {
-            socket.send_to(&serialized_req, to).unwrap();
-            let mut buf = [0; 1024];
-            if let Ok((size, _addr)) = socket.recv_from(&mut buf) {
-                // Ignore bad packet and try again
-                if let Ok(slot) = bincode::config()
-                    .limit(PACKET_DATA_SIZE as u64)
-                    .deserialize(&buf[..size])
-                {
-                    return slot;
-                }
-            }
-            sleep(Duration::from_millis(500));
-        }
-        panic!("Couldn't get segment slot from archiver!");
-    }
-}

archiver-lib/src/lib.rs

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

archiver-lib/src/result.rs

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

archiver-utils/Cargo.toml

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

archiver-utils/src/lib.rs

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

archiver/.gitignore

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

archiver/Cargo.toml

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

archiver/src/main.rs

@@ -1,147 +0,0 @@
-use clap::{crate_description, crate_name, App, Arg};
-use console::style;
-use solana_archiver_lib::archiver::Archiver;
-use solana_clap_utils::{
-    input_validators::is_keypair,
-    keypair::{
-        self, keypair_input, KeypairWithSource, ASK_SEED_PHRASE_ARG,
-        SKIP_SEED_PHRASE_VALIDATION_ARG,
-    },
-};
-use solana_core::{
-    cluster_info::{Node, VALIDATOR_PORT_RANGE},
-    contact_info::ContactInfo,
-};
-use solana_sdk::{commitment_config::CommitmentConfig, signature::KeypairUtil};
-use std::{net::SocketAddr, path::PathBuf, process::exit, sync::Arc};
-
-fn main() {
-    solana_logger::setup();
-
-    let matches = App::new(crate_name!())
-        .about(crate_description!())
-        .version(solana_clap_utils::version!())
-        .arg(
-            Arg::with_name("identity_keypair")
-                .short("i")
-                .long("identity-keypair")
-                .value_name("PATH")
-                .takes_value(true)
-                .validator(is_keypair)
-                .help("File containing an identity (keypair)"),
-        )
-        .arg(
-            Arg::with_name("entrypoint")
-                .short("n")
-                .long("entrypoint")
-                .value_name("HOST:PORT")
-                .takes_value(true)
-                .required(true)
-                .validator(solana_net_utils::is_host_port)
-                .help("Rendezvous with the cluster at this entry point"),
-        )
-        .arg(
-            Arg::with_name("ledger")
-                .short("l")
-                .long("ledger")
-                .value_name("DIR")
-                .takes_value(true)
-                .required(true)
-                .help("use DIR as persistent ledger location"),
-        )
-        .arg(
-            Arg::with_name("storage_keypair")
-                .short("s")
-                .long("storage-keypair")
-                .value_name("PATH")
-                .takes_value(true)
-                .validator(is_keypair)
-                .help("File containing the storage account keypair"),
-        )
-        .arg(
-            Arg::with_name(ASK_SEED_PHRASE_ARG.name)
-                .long(ASK_SEED_PHRASE_ARG.long)
-                .value_name("KEYPAIR NAME")
-                .multiple(true)
-                .takes_value(true)
-                .possible_values(&["identity-keypair", "storage-keypair"])
-                .help(ASK_SEED_PHRASE_ARG.help),
-        )
-        .arg(
-            Arg::with_name(SKIP_SEED_PHRASE_VALIDATION_ARG.name)
-                .long(SKIP_SEED_PHRASE_VALIDATION_ARG.long)
-                .requires(ASK_SEED_PHRASE_ARG.name)
-                .help(SKIP_SEED_PHRASE_VALIDATION_ARG.help),
-        )
-        .get_matches();
-
-    let ledger_path = PathBuf::from(matches.value_of("ledger").unwrap());
-
-    let identity_keypair = keypair_input(&matches, "identity_keypair")
-        .unwrap_or_else(|err| {
-            eprintln!("Identity keypair input failed: {}", err);
-            exit(1);
-        })
-        .keypair;
-    let KeypairWithSource {
-        keypair: storage_keypair,
-        source: storage_keypair_source,
-    } = keypair_input(&matches, "storage_keypair").unwrap_or_else(|err| {
-        eprintln!("Storage keypair input failed: {}", err);
-        exit(1);
-    });
-    if storage_keypair_source == keypair::Source::Generated {
-        clap::Error::with_description(
-            "The `storage-keypair` argument was not found",
-            clap::ErrorKind::ArgumentNotFound,
-        )
-        .exit();
-    }
-
-    let entrypoint_addr = matches
-        .value_of("entrypoint")
-        .map(|entrypoint| {
-            solana_net_utils::parse_host_port(entrypoint)
-                .expect("failed to parse entrypoint address")
-        })
-        .unwrap();
-
-    let gossip_addr = {
-        let ip = solana_net_utils::get_public_ip_addr(&entrypoint_addr).unwrap();
-        let mut addr = SocketAddr::new(ip, 0);
-        addr.set_ip(solana_net_utils::get_public_ip_addr(&entrypoint_addr).unwrap());
-        addr
-    };
-    let node = Node::new_archiver_with_external_ip(
-        &identity_keypair.pubkey(),
-        &gossip_addr,
-        VALIDATOR_PORT_RANGE,
-    );
-
-    println!(
-        "{} version {} (branch={}, commit={})",
-        style(crate_name!()).bold(),
-        solana_clap_utils::version!(),
-        option_env!("CI_BRANCH").unwrap_or("unknown"),
-        option_env!("CI_COMMIT").unwrap_or("unknown")
-    );
-    solana_metrics::set_host_id(identity_keypair.pubkey().to_string());
-    println!(
-        "replicating the data with identity_keypair={:?} gossip_addr={:?}",
-        identity_keypair.pubkey(),
-        gossip_addr
-    );
-
-    let entrypoint_info = ContactInfo::new_gossip_entry_point(&entrypoint_addr);
-    let archiver = Archiver::new(
-        &ledger_path,
-        node,
-        entrypoint_info,
-        Arc::new(identity_keypair),
-        Arc::new(storage_keypair),
-        CommitmentConfig::recent(),
-    )
-    .unwrap();
-
-    archiver.join();
-}

banking-bench/.gitignore

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

banking-bench/Cargo.toml

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

banking-bench/src/main.rs

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

bench-exchange/.gitignore

@@ -1,4 +0,0 @@
-/target/
-/config/
-/config-local/
-/farf/

bench-exchange/Cargo.toml

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

bench-exchange/README.md

@@ -1,479 +0,0 @@
-# token-exchange
-Solana Token Exchange Bench
-
-If you can't wait; jump to [Running the exchange](#Running-the-exchange) to
-learn how to start and interact with the exchange.
-
-### Table of Contents
-[Overview](#Overview)<br>
-[Premise](#Premise)<br>
-[Exchange startup](#Exchange-startup)<br>
-[Order Requests](#Trade-requests)<br>
-[Order Cancellations](#Trade-cancellations)<br>
-[Trade swap](#Trade-swap)<br>
-[Exchange program operations](#Exchange-program-operations)<br>
-[Quotes and OHLCV](#Quotes-and-OHLCV)<br>
-[Investor strategies](#Investor-strategies)<br>
-[Running the exchange](#Running-the-exchange)<br>
-
-## Overview
-
-An exchange is a marketplace where one asset can be traded for another.  This
-demo demonstrates one way to host an exchange on the Solana blockchain by
-emulating a currency exchange.
-
-The assets are virtual tokens held by investors who may post order requests to
-the exchange.  A Matcher monitors the exchange and posts swap requests for
-matching orders.  All the transactions can execute concurrently.
-
-## Premise
-
-- Exchange
-  -  An exchange is a marketplace where one asset can be traded for another.
-     The exchange in this demo is the on-chain program that implements the
-     tokens and the policies for trading those tokens.
-- Token
-  - A virtual asset that can be owned, traded, and holds virtual intrinsic value
-    compared to other assets.  There are four types of tokens in this demo, A,
-    B, C, D.  Each one may be traded for another.
-- Token account
-  - An account owned by the exchange that holds a quantity of one type of token.
-- Account request
-  - A request to create a token account
-- Token request
-  - A request to deposit tokens of a particular type into a token account.
-- Asset pair
-  - A struct with fields Base and Quote, representing the two assets which make up a 
-    trading pair,  which themselves are Tokens. The Base or 'primary' asset is the
-    numerator and the Quote is the denominator for pricing purposes.
-- Order side
-  - Describes which side of the market an investor wants to place a trade on. Options
-    are "Bid" or "Ask", where a bid represents an offer to purchase the Base asset of
-    the AssetPair for a sum of the Quote Asset and an Ask is an offer to sell Base asset
-    for the Quote asset.
-- Price ratio
-  -  An expression of the relative prices of two tokens. Calculated with the Base
-     Asset as the numerator and the Quote Asset as the denominator. Ratios are 
-     represented as fixed point numbers.  The fixed point scaler is defined in
-     [exchange_state.rs](https://github.com/solana-labs/solana/blob/c2fdd1362a029dcf89c8907c562d2079d977df11/programs/exchange_api/src/exchange_state.rs#L7)
-- Order request
-  - A Solana transaction sent by a trader to the exchange to submit an order. 
-    Order requests are made up of the token pair, the order side (bid or ask),
-    quantity of the primary token, the price ratio, and the two token accounts
-    to be credited/deducted.  An example trade request looks like "T AB 5 2" 
-    which reads "Exchange 5 A tokens to B tokens at a price ratio of 1:2"  A fulfilled trade would result in 5 A tokens
-    deducted and 10 B tokens credited to the trade initiator's token accounts.
-    Successful order requests result in an order.
-- Order
-  - The result of a successful order request.  orders are stored in
-    accounts owned by the submitter of the order request.  They can only be
-    canceled by their owner but can be used by anyone in a trade swap.  They
-    contain the same information as the order request.
-- Price spread
-  - The difference between the two matching orders. The spread is the
-    profit of the Matcher initiating the swap request.
-- Match requirements
-  - Policies that result in a successful trade swap.
-- Match request
-  - A request to fill two complementary orders (bid/ask), resulting if successful,
-    in a trade being created.
-- Trade
-  - A successful trade is created from two matching orders that meet
-    swap requirements which are submitted in a Match Request by a Matcher and
-    executed by the exchange. A trade may not wholly satisfy one or both of the
-    orders in which case the orders are adjusted appropriately. Upon execution,
-    tokens are distributed to the traders' accounts and any overlap or 
-    "negative spread" between orders is deposited into the Matcher's profit
-    account.  All successful trades are recorded in the data of a new solana 
-    account for posterity.
-- Investor
-  - Individual investors who hold a number of tokens and wish to trade them on
-    the exchange.  Investors operate as Solana thin clients who own a set of
-    accounts containing tokens and/or order requests.  Investors post
-    transactions to the exchange in order to request tokens and post or cancel
-    order requests.
-- Matcher
-  - An agent who facilitates trading between investors.  Matchers operate as
-    Solana thin clients who monitor all the orders looking for a trade
-    match.  Once found, the Matcher issues a swap request to the exchange.
-    Matchers are the engine of the exchange and are rewarded for their efforts by
-    accumulating the price spreads of the swaps they initiate.  Matchers also
-    provide current bid/ask price and OHLCV (Open, High, Low, Close, Volume)
-    information on demand via a public network port.
-- Transaction fees
-  - Solana transaction fees are paid for by the transaction submitters who are
-    the Investors and Matchers.
-
-## Exchange startup
-
-The exchange is up and running when it reaches a state where it can take
-investors' trades and Matchers' match requests.  To achieve this state the
-following must occur in order:
-
-- Start the Solana blockchain
-- Start the  thin-client
-- The Matcher subscribes to change notifications for all the accounts owned by
-  the exchange program id.  The subscription is managed via Solana's JSON RPC
-  interface.
-- The Matcher starts responding to queries for bid/ask price and OHLCV
-
-The Matcher responding successfully to price and OHLCV requests is the signal to
-the investors that trades submitted after that point will be analyzed.  <!--This
-is not ideal, and instead investors should be able to submit trades at any time,
-and the Matcher could come and go without missing a trade.  One way to achieve
-this is for the Matcher to read the current state of all accounts looking for all
-open orders.-->
-
-Investors will initially query the exchange to discover their current balance
-for each type of token.  If the investor does not already have an account for
-each type of token, they will submit account requests.  Matcher as well will
-request accounts to hold the tokens they earn by initiating trade swaps.
-
-```rust
-/// Supported token types
-pub enum Token {
-    A,
-    B,
-    C,
-    D,
-}
-
-/// Supported token pairs
-pub enum TokenPair {
-    AB,
-    AC,
-    AD,
-    BC,
-    BD,
-    CD,
-}
-
-pub enum ExchangeInstruction {
-    /// New token account
-    /// key 0 - Signer
-    /// key 1 - New token account
-    AccountRequest,
-}
-
-/// Token accounts are populated with this structure
-pub struct TokenAccountInfo {
-    /// Investor who owns this account
-    pub owner: Pubkey,
-    /// Current number of tokens this account holds
-    pub tokens: Tokens,
-}
-```
-
-For this demo investors or Matcher can request more tokens from the exchange at
-any time by submitting token requests. In non-demos, an exchange of this type
-would provide another way to exchange a 3rd party asset into tokens.
-
-To request tokens, investors submit transfer requests:
-
-```rust
-pub enum ExchangeInstruction {
-    /// Transfer tokens between two accounts
-    /// key 0 - Account to transfer tokens to
-    /// key 1 - Account to transfer tokens from.  This can be the exchange program itself,
-    ///         the exchange has a limitless number of tokens it can transfer.
-    TransferRequest(Token, u64),
-}
-```
-
-## Order Requests
-
-When an investor decides to exchange a token of one type for another, they
-submit a transaction to the Solana Blockchain containing an order request, which,
-if successful, is turned into an order.  orders do not expire but are
-cancellable. <!-- orders should have a timestamp to enable trade
-expiration -->  When an order is created, tokens are deducted from a token
-account and the order acts as an escrow.  The tokens are held until the
-order is fulfilled or canceled. If the direction is `To`, then the number
-of `tokens` are deducted from the primary account, if `From` then `tokens`
-multiplied by `price` are deducted from the secondary account.  orders are
-no longer valid when the number of `tokens` goes to zero, at which point they
-can no longer be used. <!-- Could support refilling orders, so order
-accounts are refilled rather than accumulating -->
-
-```rust
-/// Direction of the exchange between two tokens in a pair
-pub enum Direction {
-    /// Trade first token type (primary) in the pair 'To' the second
-    To,
-    /// Trade first token type in the pair 'From' the second (secondary)
-    From,
-}
-
-pub struct OrderRequestInfo {
-    /// Direction of trade
-    pub direction: Direction,
-
-    /// Token pair to trade
-    pub pair: TokenPair,
-
-    /// Number of tokens to exchange; refers to the primary or the secondary depending on the direction
-    pub tokens: u64,
-
-    /// The price ratio the primary price over the secondary price.  The primary price is fixed
-    /// and equal to the variable `SCALER`.
-    pub price: u64,
-
-    /// Token account to deposit tokens on successful swap
-    pub dst_account: Pubkey,
-}
-
-pub enum ExchangeInstruction {
-    /// order request
-    /// key 0 - Signer
-    /// key 1 - Account in which to record the swap
-    /// key 2 - Token account associated with this trade
-    TradeRequest(TradeRequestInfo),
-}
-
-/// Trade accounts are populated with this structure
-pub struct TradeOrderInfo {
-    /// Owner of the order
-    pub owner: Pubkey,
-    /// Direction of the exchange
-    pub direction: Direction,
-    /// Token pair indicating two tokens to exchange, first is primary
-    pub pair: TokenPair,
-    /// Number of tokens to exchange; primary or secondary depending on direction
-    pub tokens: u64,
-    /// Scaled price of the secondary token given the primary is equal to the scale value
-    /// If scale is 1 and price is 2 then ratio is 1:2 or 1 primary token for 2 secondary tokens
-    pub price: u64,
-    /// account which the tokens were source from.  The trade account holds the tokens in escrow
-    /// until either one or more part of a swap or the trade is canceled.
-    pub src_account: Pubkey,
-    /// account which the tokens the tokens will be deposited into on a successful trade
-    pub dst_account: Pubkey,
-}
-```
-
-## Order cancellations
-
-An investor may cancel a trade at anytime, but only trades they own.  If the
-cancellation is successful, any tokens held in escrow are returned to the
-account from which they came.
-
-```rust
-pub enum ExchangeInstruction {
-    /// order cancellation
-    /// key 0 - Signer
-    /// key 1 -order to cancel
-    TradeCancellation,
-}
-```
-
-## Trade swaps
-
-The Matcher is monitoring the accounts assigned to the exchange program and
-building a trade-order table.  The order table is used to identify
-matching orders which could be fulfilled.  When a match is found the
-Matcher should issue a swap request.  Swap requests may not satisfy the entirety
-of either order, but the exchange will greedily fulfill it.  Any leftover tokens
-in either account will keep the order valid for further swap requests in
-the future.
-
-Matching orders are defined by the following swap requirements:
-
-- Opposite polarity (one `To` and one `From`)
-- Operate on the same token pair
-- The price ratio of the `From` order is greater than or equal to the `To` order
-- There are sufficient tokens to perform the trade
-
-Orders can be written in the following format:
-
-`investor direction pair quantity price-ratio`
-
-For example:
-
-- `1 T AB 2 1`
-  - Investor 1 wishes to exchange 2 A tokens to B tokens at a ratio of 1 A to 1
-    B
-- `2 F AC 6 1.2`
-  - Investor 2 wishes to exchange A tokens from 6 B tokens at a ratio of 1 A
-    from 1.2 B
-
-An order table could look something like the following. Notice how the columns
-are sorted low to high and high to low, respectively.  Prices are dramatic and
-whole for clarity.
-
-|Row| To          | From       |
-|---|-------------|------------|
-| 1 | 1 T AB 2 4  | 2 F AB 2 8 |
-| 2 | 1 T AB 1 4  | 2 F AB 2 8 |
-| 3 | 1 T AB 6 6  | 2 F AB 2 7 |
-| 4 | 1 T AB 2 8  | 2 F AB 3 6 |
-| 5 | 1 T AB 2 10 | 2 F AB 1 5 |
-
-As part of a successful swap request, the exchange will credit tokens to the
-Matcher's account equal to the difference in the price ratios or the two orders.
-These tokens are considered the Matcher's profit for initiating the trade.
-
-The Matcher would initiate the following swap on the order table above:
-
-  - Row 1, To:   Investor 1 trades 2 A tokens to 8 B tokens
-  - Row 1, From: Investor 2 trades 2 A tokens from 8 B tokens
-  - Matcher takes 8 B tokens as profit
-
-Both row 1 trades are fully realized, table becomes:
-
-|Row| To          | From       |
-|---|-------------|------------|
-| 1 | 1 T AB 1 4  | 2 F AB 2 8 |
-| 2 | 1 T AB 6 6  | 2 F AB 2 7 |
-| 3 | 1 T AB 2 8  | 2 F AB 3 6 |
-| 4 | 1 T AB 2 10 | 2 F AB 1 5 |
-
-The Matcher would initiate the following swap:
-
-  - Row 1, To:   Investor 1 trades 1 A token to 4 B tokens
-  - Row 1, From: Investor 2 trades 1 A token from 4 B tokens
-  - Matcher takes 4 B tokens as profit
-
-Row 1 From is not fully realized, table becomes:
-
-|Row| To          | From       |
-|---|-------------|------------|
-| 1 | 1 T AB 6 6  | 2 F AB 1 8 |
-| 2 | 1 T AB 2 8  | 2 F AB 2 7 |
-| 3 | 1 T AB 2 10 | 2 F AB 3 6 |
-| 4 |             | 2 F AB 1 5 |
-
-The Matcher would initiate the following swap:
-
-  - Row 1, To:   Investor 1 trades 1 A token to 6 B tokens
-  - Row 1, From: Investor 2 trades 1 A token from 6 B tokens
-  - Matcher takes 2 B tokens as profit
-
-Row 1 To is now fully realized, table becomes:
-
-|Row| To          | From       |
-|---|-------------|------------|
-| 1 | 1 T AB 5 6  | 2 F AB 2 7 |
-| 2 | 1 T AB 2 8  | 2 F AB 3 5 |
-| 3 | 1 T AB 2 10 | 2 F AB 1 5 |
-
-The Matcher would initiate the following last swap:
-
-  - Row 1, To:   Investor 1 trades 2 A token to 12 B tokens
-  - Row 1, From: Investor 2 trades 2 A token from 12 B tokens
-  - Matcher takes 2 B tokens as profit
-
-Table becomes:
-
-|Row| To          | From       |
-|---|-------------|------------|
-| 1 | 1 T AB 3 6  | 2 F AB 3 5 |
-| 2 | 1 T AB 2 8  | 2 F AB 1 5 |
-| 3 | 1 T AB 2 10 |            |
-
-At this point the lowest To's price is larger than the largest From's price so
-no more swaps would be initiated until new orders came in.
-
-```rust
-pub enum ExchangeInstruction {
-    /// Trade swap request
-    /// key 0 - Signer
-    /// key 1 - Account in which to record the swap
-    /// key 2 - 'To' order
-    /// key 3 - `From` order
-    /// key 4 - Token account associated with the To Trade
-    /// key 5 - Token account associated with From trade
-    /// key 6 - Token account in which to deposit the Matcher profit from the swap.
-    SwapRequest,
-}
-
-/// Swap accounts are populated with this structure
-pub struct TradeSwapInfo {
-    /// Pair swapped
-    pub pair: TokenPair,
-    /// `To` order
-    pub to_trade_order: Pubkey,
-    /// `From` order
-    pub from_trade_order: Pubkey,
-    /// Number of primary tokens exchanged
-    pub primary_tokens: u64,
-    /// Price the primary tokens were exchanged for
-    pub primary_price: u64,
-    /// Number of secondary tokens exchanged
-    pub secondary_tokens: u64,
-    /// Price the secondary tokens were exchanged for
-    pub secondary_price: u64,
-}
-```
-
-## Exchange program operations
-
-Putting all the commands together from above, the following operations will be
-supported by the on-chain exchange program:
-
-```rust
-pub enum ExchangeInstruction {
-    /// New token account
-    /// key 0 - Signer
-    /// key 1 - New token account
-    AccountRequest,
-
-    /// Transfer tokens between two accounts
-    /// key 0 - Account to transfer tokens to
-    /// key 1 - Account to transfer tokens from.  This can be the exchange program itself,
-    ///         the exchange has a limitless number of tokens it can transfer.
-    TransferRequest(Token, u64),
-
-    /// order request
-    /// key 0 - Signer
-    /// key 1 - Account in which to record the swap
-    /// key 2 - Token account associated with this trade
-    TradeRequest(TradeRequestInfo),
-
-    /// order cancellation
-    /// key 0 - Signer
-    /// key 1 -order to cancel
-    TradeCancellation,
-
-    /// Trade swap request
-    /// key 0 - Signer
-    /// key 1 - Account in which to record the swap
-    /// key 2 - 'To' order
-    /// key 3 - `From` order
-    /// key 4 - Token account associated with the To Trade
-    /// key 5 - Token account associated with From trade
-    /// key 6 - Token account in which to deposit the Matcher profit from the swap.
-    SwapRequest,
-}
-```
-
-## Quotes and OHLCV
-
-The Matcher will provide current bid/ask price quotes based on trade actively and
-also provide OHLCV based on some time window.  The details of how the bid/ask
-price quotes are calculated are yet to be decided.
-
-## Investor strategies
-
-To make a compelling demo, the investors needs to provide interesting trade
-behavior.  Something as simple as a randomly twiddled baseline would be a
-minimum starting point.
-
-## Running the exchange
-
-The exchange bench posts trades and swaps matches as fast as it can.  
-
-You might want to bump the duration up
-to 60 seconds and the batch size to 1000 for better numbers.  You can modify those
-in client_demo/src/demo.rs::test_exchange_local_cluster.
-
-The following command runs the bench:
-
-```bash
-$ RUST_LOG=solana_bench_exchange=info cargo test --release -- --nocapture test_exchange_local_cluster
-```
-
-To also see the cluster messages:
-
-```bash
-$ RUST_LOG=solana_bench_exchange=info,solana=info cargo test --release -- --nocapture test_exchange_local_cluster
-```

bench-exchange/src/cli.rs

@@ -1,220 +0,0 @@
-use clap::{crate_description, crate_name, value_t, App, Arg, ArgMatches};
-use solana_core::gen_keys::GenKeys;
-use solana_faucet::faucet::FAUCET_PORT;
-use solana_sdk::signature::{read_keypair_file, Keypair, KeypairUtil};
-use std::net::SocketAddr;
-use std::process::exit;
-use std::time::Duration;
-
-pub struct Config {
-    pub entrypoint_addr: SocketAddr,
-    pub faucet_addr: SocketAddr,
-    pub identity: Keypair,
-    pub threads: usize,
-    pub num_nodes: usize,
-    pub duration: Duration,
-    pub transfer_delay: u64,
-    pub fund_amount: u64,
-    pub batch_size: usize,
-    pub chunk_size: usize,
-    pub account_groups: usize,
-    pub client_ids_and_stake_file: String,
-    pub write_to_client_file: bool,
-    pub read_from_client_file: bool,
-}
-
-impl Default for Config {
-    fn default() -> Self {
-        Self {
-            entrypoint_addr: SocketAddr::from(([127, 0, 0, 1], 8001)),
-            faucet_addr: SocketAddr::from(([127, 0, 0, 1], FAUCET_PORT)),
-            identity: Keypair::new(),
-            num_nodes: 1,
-            threads: 4,
-            duration: Duration::new(u64::max_value(), 0),
-            transfer_delay: 0,
-            fund_amount: 100_000,
-            batch_size: 100,
-            chunk_size: 100,
-            account_groups: 100,
-            client_ids_and_stake_file: String::new(),
-            write_to_client_file: false,
-            read_from_client_file: false,
-        }
-    }
-}
-
-pub fn build_args<'a, 'b>(version: &'b str) -> App<'a, 'b> {
-    App::new(crate_name!())
-        .about(crate_description!())
-        .version(version)
-        .arg(
-            Arg::with_name("entrypoint")
-                .short("n")
-                .long("entrypoint")
-                .value_name("HOST:PORT")
-                .takes_value(true)
-                .required(false)
-                .default_value("127.0.0.1:8001")
-                .help("Cluster entry point; defaults to 127.0.0.1:8001"),
-        )
-        .arg(
-            Arg::with_name("faucet")
-                .short("d")
-                .long("faucet")
-                .value_name("HOST:PORT")
-                .takes_value(true)
-                .required(false)
-                .default_value("127.0.0.1:9900")
-                .help("Location of the faucet; defaults to 127.0.0.1:9900"),
-        )
-        .arg(
-            Arg::with_name("identity")
-                .short("i")
-                .long("identity")
-                .value_name("PATH")
-                .takes_value(true)
-                .help("File containing a client identity (keypair)"),
-        )
-        .arg(
-            Arg::with_name("threads")
-                .long("threads")
-                .value_name("<threads>")
-                .takes_value(true)
-                .required(false)
-                .default_value("1")
-                .help("Number of threads submitting transactions"),
-        )
-        .arg(
-            Arg::with_name("num-nodes")
-                .long("num-nodes")
-                .value_name("NUM")
-                .takes_value(true)
-                .required(false)
-                .default_value("1")
-                .help("Wait for NUM nodes to converge"),
-        )
-        .arg(
-            Arg::with_name("duration")
-                .long("duration")
-                .value_name("SECS")
-                .takes_value(true)
-                .default_value("60")
-                .help("Seconds to run benchmark, then exit; default is forever"),
-        )
-        .arg(
-            Arg::with_name("transfer-delay")
-                .long("transfer-delay")
-                .value_name("<delay>")
-                .takes_value(true)
-                .required(false)
-                .default_value("0")
-                .help("Delay between each chunk"),
-        )
-        .arg(
-            Arg::with_name("fund-amount")
-                .long("fund-amount")
-                .value_name("<fund>")
-                .takes_value(true)
-                .required(false)
-                .default_value("100000")
-                .help("Number of lamports to fund to each signer"),
-        )
-        .arg(
-            Arg::with_name("batch-size")
-                .long("batch-size")
-                .value_name("<batch>")
-                .takes_value(true)
-                .required(false)
-                .default_value("1000")
-                .help("Number of transactions before the signer rolls over"),
-        )
-        .arg(
-            Arg::with_name("chunk-size")
-                .long("chunk-size")
-                .value_name("<cunk>")
-                .takes_value(true)
-                .required(false)
-                .default_value("500")
-                .help("Number of transactions to generate and send at a time"),
-        )
-        .arg(
-            Arg::with_name("account-groups")
-                .long("account-groups")
-                .value_name("<groups>")
-                .takes_value(true)
-                .required(false)
-                .default_value("10")
-                .help("Number of account groups to cycle for each batch"),
-        )
-        .arg(
-            Arg::with_name("write-client-keys")
-                .long("write-client-keys")
-                .value_name("FILENAME")
-                .takes_value(true)
-                .help("Generate client keys and stakes and write the list to YAML file"),
-        )
-        .arg(
-            Arg::with_name("read-client-keys")
-                .long("read-client-keys")
-                .value_name("FILENAME")
-                .takes_value(true)
-                .help("Read client keys and stakes from the YAML file"),
-        )
-}
-
-pub fn extract_args<'a>(matches: &ArgMatches<'a>) -> Config {
-    let mut args = Config::default();
-
-    args.entrypoint_addr = solana_net_utils::parse_host_port(
-        matches.value_of("entrypoint").unwrap(),
-    )
-    .unwrap_or_else(|e| {
-        eprintln!("failed to parse entrypoint address: {}", e);
-        exit(1)
-    });
-
-    args.faucet_addr = solana_net_utils::parse_host_port(matches.value_of("faucet").unwrap())
-        .unwrap_or_else(|e| {
-            eprintln!("failed to parse faucet address: {}", e);
-            exit(1)
-        });
-
-    if matches.is_present("identity") {
-        args.identity = read_keypair_file(matches.value_of("identity").unwrap())
-            .expect("can't read client identity");
-    } else {
-        args.identity = {
-            let seed = [42_u8; 32];
-            let mut rnd = GenKeys::new(seed);
-            rnd.gen_keypair()
-        };
-    }
-    args.threads = value_t!(matches.value_of("threads"), usize).expect("Failed to parse threads");
-    args.num_nodes =
-        value_t!(matches.value_of("num-nodes"), usize).expect("Failed to parse num-nodes");
-    let duration = value_t!(matches.value_of("duration"), u64).expect("Failed to parse duration");
-    args.duration = Duration::from_secs(duration);
-    args.transfer_delay =
-        value_t!(matches.value_of("transfer-delay"), u64).expect("Failed to parse transfer-delay");
-    args.fund_amount =
-        value_t!(matches.value_of("fund-amount"), u64).expect("Failed to parse fund-amount");
-    args.batch_size =
-        value_t!(matches.value_of("batch-size"), usize).expect("Failed to parse batch-size");
-    args.chunk_size =
-        value_t!(matches.value_of("chunk-size"), usize).expect("Failed to parse chunk-size");
-    args.account_groups = value_t!(matches.value_of("account-groups"), usize)
-        .expect("Failed to parse account-groups");
-
-    if let Some(s) = matches.value_of("write-client-keys") {
-        args.write_to_client_file = true;
-        args.client_ids_and_stake_file = s.to_string();
-    }
-
-    if let Some(s) = matches.value_of("read-client-keys") {
-        assert!(!args.write_to_client_file);
-        args.read_from_client_file = true;
-        args.client_ids_and_stake_file = s.to_string();
-    }
-    args
-}

bench-exchange/src/lib.rs

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

bench-exchange/src/main.rs

@@ -1,83 +0,0 @@
-pub mod bench;
-mod cli;
-pub mod order_book;
-
-use crate::bench::{airdrop_lamports, create_client_accounts_file, do_bench_exchange, Config};
-use log::*;
-use solana_core::gossip_service::{discover_cluster, get_multi_client};
-use solana_sdk::signature::KeypairUtil;
-
-fn main() {
-    solana_logger::setup();
-    solana_metrics::set_panic_hook("bench-exchange");
-
-    let matches = cli::build_args(solana_clap_utils::version!()).get_matches();
-    let cli_config = cli::extract_args(&matches);
-
-    let cli::Config {
-        entrypoint_addr,
-        faucet_addr,
-        identity,
-        threads,
-        num_nodes,
-        duration,
-        transfer_delay,
-        fund_amount,
-        batch_size,
-        chunk_size,
-        account_groups,
-        client_ids_and_stake_file,
-        write_to_client_file,
-        read_from_client_file,
-        ..
-    } = cli_config;
-
-    let config = Config {
-        identity,
-        threads,
-        duration,
-        transfer_delay,
-        fund_amount,
-        batch_size,
-        chunk_size,
-        account_groups,
-        client_ids_and_stake_file,
-        read_from_client_file,
-    };
-
-    if write_to_client_file {
-        create_client_accounts_file(
-            &config.client_ids_and_stake_file,
-            config.batch_size,
-            config.account_groups,
-            config.fund_amount,
-        );
-    } else {
-        info!("Connecting to the cluster");
-        let (nodes, _archivers) =
-            discover_cluster(&entrypoint_addr, num_nodes).unwrap_or_else(|_| {
-                panic!("Failed to discover nodes");
-            });
-
-        let (client, num_clients) = get_multi_client(&nodes);
-
-        info!("{} nodes found", num_clients);
-        if num_clients < num_nodes {
-            panic!("Error: Insufficient nodes discovered");
-        }
-
-        if !read_from_client_file {
-            info!("Funding keypair: {}", config.identity.pubkey());
-
-            let accounts_in_groups = batch_size * account_groups;
-            const NUM_SIGNERS: u64 = 2;
-            airdrop_lamports(
-                &client,
-                &faucet_addr,
-                &config.identity,
-                fund_amount * (accounts_in_groups + 1) as u64 * NUM_SIGNERS,
-            );
-        }
-        do_bench_exchange(vec![client], config);
-    }
-}

bench-exchange/src/order_book.rs

@@ -1,134 +0,0 @@
-use itertools::EitherOrBoth::{Both, Left, Right};
-use itertools::Itertools;
-use log::*;
-use solana_exchange_program::exchange_state::*;
-use solana_sdk::pubkey::Pubkey;
-use std::cmp::Ordering;
-use std::collections::BinaryHeap;
-use std::{error, fmt};
-
-#[derive(Clone, Debug, Eq, PartialEq)]
-pub struct ToOrder {
-    pub pubkey: Pubkey,
-    pub info: OrderInfo,
-}
-
-impl Ord for ToOrder {
-    fn cmp(&self, other: &Self) -> Ordering {
-        other.info.price.cmp(&self.info.price)
-    }
-}
-impl PartialOrd for ToOrder {
-    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
-        Some(self.cmp(other))
-    }
-}
-#[derive(Clone, Debug, Eq, PartialEq)]
-pub struct FromOrder {
-    pub pubkey: Pubkey,
-    pub info: OrderInfo,
-}
-
-impl Ord for FromOrder {
-    fn cmp(&self, other: &Self) -> Ordering {
-        self.info.price.cmp(&other.info.price)
-    }
-}
-impl PartialOrd for FromOrder {
-    fn partial_cmp(&self, other: &Self) -> Option<Ordering> {
-        Some(self.cmp(other))
-    }
-}
-
-#[derive(Default)]
-pub struct OrderBook {
-    // TODO scale to x token types
-    to_ab: BinaryHeap<ToOrder>,
-    from_ab: BinaryHeap<FromOrder>,
-}
-impl fmt::Display for OrderBook {
-    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
-        writeln!(
-            f,
-            "+-Order Book--------------------------+-------------------------------------+"
-        )?;
-        for (i, it) in self
-            .to_ab
-            .iter()
-            .zip_longest(self.from_ab.iter())
-            .enumerate()
-        {
-            match it {
-                Both(to, from) => writeln!(
-                    f,
-                    "| T AB {:8} for {:8}/{:8} | F AB {:8} for {:8}/{:8} |{}",
-                    to.info.tokens,
-                    SCALER,
-                    to.info.price,
-                    from.info.tokens,
-                    SCALER,
-                    from.info.price,
-                    i
-                )?,
-                Left(to) => writeln!(
-                    f,
-                    "| T AB {:8} for {:8}/{:8} |                                     |{}",
-                    to.info.tokens, SCALER, to.info.price, i
-                )?,
-                Right(from) => writeln!(
-                    f,
-                    "|                                     | F AB {:8} for {:8}/{:8} |{}",
-                    from.info.tokens, SCALER, from.info.price, i
-                )?,
-            }
-        }
-        write!(
-            f,
-            "+-------------------------------------+-------------------------------------+"
-        )?;
-        Ok(())
-    }
-}
-
-impl OrderBook {
-    // TODO
-    // pub fn cancel(&mut self, pubkey: Pubkey) -> Result<(), Box<dyn error::Error>> {
-    //     Ok(())
-    // }
-    pub fn push(&mut self, pubkey: Pubkey, info: OrderInfo) -> Result<(), Box<dyn error::Error>> {
-        check_trade(info.side, info.tokens, info.price)?;
-        match info.side {
-            OrderSide::Ask => {
-                self.to_ab.push(ToOrder { pubkey, info });
-            }
-            OrderSide::Bid => {
-                self.from_ab.push(FromOrder { pubkey, info });
-            }
-        }
-        Ok(())
-    }
-    pub fn pop(&mut self) -> Option<(ToOrder, FromOrder)> {
-        if let Some(pair) = Self::pop_pair(&mut self.to_ab, &mut self.from_ab) {
-            return Some(pair);
-        }
-        None
-    }
-    pub fn get_num_outstanding(&self) -> (usize, usize) {
-        (self.to_ab.len(), self.from_ab.len())
-    }
-
-    fn pop_pair(
-        to_ab: &mut BinaryHeap<ToOrder>,
-        from_ab: &mut BinaryHeap<FromOrder>,
-    ) -> Option<(ToOrder, FromOrder)> {
-        let to = to_ab.peek()?;
-        let from = from_ab.peek()?;
-        if from.info.price < to.info.price {
-            debug!("Trade not viable");
-            return None;
-        }
-        let to = to_ab.pop()?;
-        let from = from_ab.pop()?;
-        Some((to, from))
-    }
-}

bench-exchange/tests/bench_exchange.rs

@@ -1,103 +0,0 @@
-use log::*;
-use solana_bench_exchange::bench::{airdrop_lamports, do_bench_exchange, Config};
-use solana_core::gossip_service::{discover_cluster, get_multi_client};
-use solana_core::validator::ValidatorConfig;
-use solana_exchange_program::exchange_processor::process_instruction;
-use solana_exchange_program::id;
-use solana_exchange_program::solana_exchange_program;
-use solana_faucet::faucet::run_local_faucet;
-use solana_local_cluster::local_cluster::{ClusterConfig, LocalCluster};
-use solana_runtime::bank::Bank;
-use solana_runtime::bank_client::BankClient;
-use solana_sdk::genesis_config::create_genesis_config;
-use solana_sdk::signature::{Keypair, KeypairUtil};
-use std::process::exit;
-use std::sync::mpsc::channel;
-use std::time::Duration;
-
-#[test]
-#[ignore]
-fn test_exchange_local_cluster() {
-    solana_logger::setup();
-
-    const NUM_NODES: usize = 1;
-
-    let mut config = Config::default();
-    config.identity = Keypair::new();
-    config.duration = Duration::from_secs(1);
-    config.fund_amount = 100_000;
-    config.threads = 1;
-    config.transfer_delay = 20; // 15
-    config.batch_size = 100; // 1000;
-    config.chunk_size = 10; // 200;
-    config.account_groups = 1; // 10;
-    let Config {
-        fund_amount,
-        batch_size,
-        account_groups,
-        ..
-    } = config;
-    let accounts_in_groups = batch_size * account_groups;
-
-    let cluster = LocalCluster::new(&ClusterConfig {
-        node_stakes: vec![100_000; NUM_NODES],
-        cluster_lamports: 100_000_000_000_000,
-        validator_configs: vec![ValidatorConfig::default(); NUM_NODES],
-        native_instruction_processors: [solana_exchange_program!()].to_vec(),
-        ..ClusterConfig::default()
-    });
-
-    let faucet_keypair = Keypair::new();
-    cluster.transfer(
-        &cluster.funding_keypair,
-        &faucet_keypair.pubkey(),
-        2_000_000_000_000,
-    );
-
-    let (addr_sender, addr_receiver) = channel();
-    run_local_faucet(faucet_keypair, addr_sender, Some(1_000_000_000_000));
-    let faucet_addr = addr_receiver.recv_timeout(Duration::from_secs(2)).unwrap();
-
-    info!("Connecting to the cluster");
-    let (nodes, _) =
-        discover_cluster(&cluster.entry_point_info.gossip, NUM_NODES).unwrap_or_else(|err| {
-            error!("Failed to discover {} nodes: {:?}", NUM_NODES, err);
-            exit(1);
-        });
-
-    let (client, num_clients) = get_multi_client(&nodes);
-
-    info!("clients: {}", num_clients);
-    assert!(num_clients >= NUM_NODES);
-
-    const NUM_SIGNERS: u64 = 2;
-    airdrop_lamports(
-        &client,
-        &faucet_addr,
-        &config.identity,
-        fund_amount * (accounts_in_groups + 1) as u64 * NUM_SIGNERS,
-    );
-
-    do_bench_exchange(vec![client], config);
-}
-
-#[test]
-fn test_exchange_bank_client() {
-    solana_logger::setup();
-    let (genesis_config, identity) = create_genesis_config(100_000_000_000_000);
-    let mut bank = Bank::new(&genesis_config);
-    bank.add_instruction_processor(id(), process_instruction);
-    let clients = vec![BankClient::new(bank)];
-
-    let mut config = Config::default();
-    config.identity = identity;
-    config.duration = Duration::from_secs(1);
-    config.fund_amount = 100_000;
-    config.threads = 1;
-    config.transfer_delay = 20; // 0;
-    config.batch_size = 100; // 1500;
-    config.chunk_size = 10; // 1500;
-    config.account_groups = 1; // 50;
-
-    do_bench_exchange(clients, config);
-}

bench-streamer/.gitignore

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

bench-streamer/Cargo.toml

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

bench-streamer/src/main.rs

@@ -1,33 +1,34 @@
-use clap::{crate_description, crate_name, App, Arg};
+use clap::{App, Arg};
-use solana_core::packet::{Packet, Packets, PacketsRecycler, PACKET_DATA_SIZE};
+use solana::packet::{Packet, SharedPackets, BLOB_SIZE, PACKET_DATA_SIZE};
-use solana_core::streamer::{receiver, PacketReceiver};
+use solana::result::Result;
+use solana::streamer::{receiver, PacketReceiver};
 use std::cmp::max;
 use std::net::{IpAddr, Ipv4Addr, SocketAddr, UdpSocket};
 use std::sync::atomic::{AtomicBool, AtomicUsize, Ordering};
 use std::sync::mpsc::channel;
 use std::sync::Arc;
 use std::thread::sleep;
-use std::thread::{spawn, JoinHandle, Result};
+use std::thread::{spawn, JoinHandle};
 use std::time::Duration;
 use std::time::SystemTime;
 
 fn producer(addr: &SocketAddr, exit: Arc<AtomicBool>) -> JoinHandle<()> {
     let send = UdpSocket::bind("0.0.0.0:0").unwrap();
-    let mut msgs = Packets::default();
+    let msgs = SharedPackets::default();
-    msgs.packets.resize(10, Packet::default());
+    let msgs_ = msgs.clone();
-    for w in msgs.packets.iter_mut() {
+    msgs.write().unwrap().packets.resize(10, Packet::default());
+    for w in &mut msgs.write().unwrap().packets {
         w.meta.size = PACKET_DATA_SIZE;
         w.meta.set_addr(&addr);
     }
-    let msgs = Arc::new(msgs);
     spawn(move || loop {
         if exit.load(Ordering::Relaxed) {
             return;
         }
         let mut num = 0;
-        for p in &msgs.packets {
+        for p in &msgs_.read().unwrap().packets {
             let a = p.meta.addr();
-            assert!(p.meta.size < PACKET_DATA_SIZE);
+            assert!(p.meta.size < BLOB_SIZE);
             send.send_to(&p.data[..p.meta.size], &a).unwrap();
             num += 1;
         }
@@ -42,7 +43,7 @@ fn sink(exit: Arc<AtomicBool>, rvs: Arc<AtomicUsize>, r: PacketReceiver) -> Join
         }
         let timer = Duration::new(1, 0);
         if let Ok(msgs) = r.recv_timeout(timer) {
-            rvs.fetch_add(msgs.packets.len(), Ordering::Relaxed);
+            rvs.fetch_add(msgs.read().unwrap().packets.len(), Ordering::Relaxed);
         }
     })
 }
@@ -50,9 +51,7 @@ fn sink(exit: Arc<AtomicBool>, rvs: Arc<AtomicUsize>, r: PacketReceiver) -> Join
 fn main() -> Result<()> {
     let mut num_sockets = 1usize;
 
-    let matches = App::new(crate_name!())
+    let matches = App::new("solana-bench-streamer")
-        .about(crate_description!())
-        .version(solana_clap_utils::version!())
         .arg(
             Arg::with_name("num-recv-sockets")
                 .long("num-recv-sockets")
@@ -73,9 +72,8 @@ fn main() -> Result<()> {
 
     let mut read_channels = Vec::new();
     let mut read_threads = Vec::new();
-    let recycler = PacketsRecycler::default();
     for _ in 0..num_sockets {
-        let read = solana_net_utils::bind_to(port, false).unwrap();
+        let read = solana_netutil::bind_to(port, false).unwrap();
         read.set_read_timeout(Some(Duration::new(1, 0))).unwrap();
 
         addr = read.local_addr().unwrap();
@@ -83,13 +81,7 @@ fn main() -> Result<()> {
 
         let (s_reader, r_reader) = channel();
         read_channels.push(r_reader);
-        read_threads.push(receiver(
+        read_threads.push(receiver(Arc::new(read), &exit, s_reader, "bench-streamer"));
-            Arc::new(read),
-            &exit,
-            s_reader,
-            recycler.clone(),
-            "bench-streamer-test",
-        ));
     }
 
     let t_producer1 = producer(&addr, exit.clone());

bench-tps/.gitignore

@@ -1,4 +0,0 @@
-/target/
-/config/
-/config-local/
-/farf/

bench-tps/Cargo.toml

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

bench-tps/src/cli.rs

@@ -1,75 +1,63 @@
-use clap::{crate_description, crate_name, App, Arg, ArgMatches};
+use std::net::SocketAddr;
-use solana_faucet::faucet::FAUCET_PORT;
+use std::process::exit;
-use solana_sdk::fee_calculator::FeeCalculator;
+use std::time::Duration;
-use solana_sdk::signature::{read_keypair_file, Keypair, KeypairUtil};
-use std::{net::SocketAddr, process::exit, time::Duration};
 
-const NUM_LAMPORTS_PER_ACCOUNT_DEFAULT: u64 = solana_sdk::native_token::LAMPORTS_PER_SOL;
+use clap::{crate_version, App, Arg, ArgMatches};
+use solana_drone::drone::DRONE_PORT;
+use solana_sdk::signature::{read_keypair, Keypair, KeypairUtil};
 
 /// Holds the configuration for a single run of the benchmark
 pub struct Config {
-    pub entrypoint_addr: SocketAddr,
+    pub network_addr: SocketAddr,
-    pub faucet_addr: SocketAddr,
+    pub drone_addr: SocketAddr,
     pub id: Keypair,
     pub threads: usize,
     pub num_nodes: usize,
     pub duration: Duration,
     pub tx_count: usize,
-    pub keypair_multiplier: usize,
     pub thread_batch_sleep_ms: usize,
     pub sustained: bool,
-    pub client_ids_and_stake_file: String,
+    pub reject_extra_nodes: bool,
-    pub write_to_client_file: bool,
+    pub converge_only: bool,
-    pub read_from_client_file: bool,
-    pub target_lamports_per_signature: u64,
-    pub multi_client: bool,
-    pub use_move: bool,
-    pub num_lamports_per_account: u64,
 }
 
 impl Default for Config {
     fn default() -> Config {
         Config {
-            entrypoint_addr: SocketAddr::from(([127, 0, 0, 1], 8001)),
+            network_addr: SocketAddr::from(([127, 0, 0, 1], 8001)),
-            faucet_addr: SocketAddr::from(([127, 0, 0, 1], FAUCET_PORT)),
+            drone_addr: SocketAddr::from(([127, 0, 0, 1], DRONE_PORT)),
             id: Keypair::new(),
             threads: 4,
             num_nodes: 1,
             duration: Duration::new(std::u64::MAX, 0),
-            tx_count: 50_000,
+            tx_count: 500_000,
-            keypair_multiplier: 8,
+            thread_batch_sleep_ms: 0,
-            thread_batch_sleep_ms: 1000,
             sustained: false,
-            client_ids_and_stake_file: String::new(),
+            reject_extra_nodes: false,
-            write_to_client_file: false,
+            converge_only: false,
-            read_from_client_file: false,
-            target_lamports_per_signature: FeeCalculator::default().target_lamports_per_signature,
-            multi_client: true,
-            use_move: false,
-            num_lamports_per_account: NUM_LAMPORTS_PER_ACCOUNT_DEFAULT,
         }
     }
 }
 
 /// Defines and builds the CLI args for a run of the benchmark
-pub fn build_args<'a, 'b>(version: &'b str) -> App<'a, 'b> {
+pub fn build_args<'a, 'b>() -> App<'a, 'b> {
-    App::new(crate_name!()).about(crate_description!())
+    App::new("solana-bench-tps")
-        .version(version)
+        .version(crate_version!())
         .arg(
-            Arg::with_name("entrypoint")
+            Arg::with_name("network")
                 .short("n")
-                .long("entrypoint")
+                .long("network")
                 .value_name("HOST:PORT")
                 .takes_value(true)
-                .help("Rendezvous with the cluster at this entry point; defaults to 127.0.0.1:8001"),
+                .help("Rendezvous with the network at this gossip entry point; defaults to 127.0.0.1:8001"),
         )
         .arg(
-            Arg::with_name("faucet")
+            Arg::with_name("drone")
                 .short("d")
-                .long("faucet")
+                .long("drone")
                 .value_name("HOST:PORT")
                 .takes_value(true)
-                .help("Location of the faucet; defaults to entrypoint:FAUCET_PORT"),
+                .help("Location of the drone; defaults to network:DRONE_PORT"),
         )
         .arg(
             Arg::with_name("identity")
@@ -87,6 +75,11 @@ pub fn build_args<'a, 'b>(version: &'b str) -> 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")
@@ -102,21 +95,16 @@ pub fn build_args<'a, 'b>(version: &'b str) -> 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")
                 .help("Use sustained performance mode vs. peak mode. This overlaps the tx generation with transfers."),
         )
-        .arg(
-            Arg::with_name("use-move")
-                .long("use-move")
-                .help("Use Move language transactions to perform transfers."),
-        )
-        .arg(
-            Arg::with_name("no-multi-client")
-                .long("no-multi-client")
-                .help("Disable multi-client support, only transact with the entrypoint."),
-        )
         .arg(
             Arg::with_name("tx_count")
                 .long("tx_count")
@@ -124,13 +112,6 @@ pub fn build_args<'a, 'b>(version: &'b str) -> App<'a, 'b> {
                 .takes_value(true)
                 .help("Number of transactions to send per batch")
         )
-        .arg(
-            Arg::with_name("keypair_multiplier")
-                .long("keypair-multiplier")
-                .value_name("NUM")
-                .takes_value(true)
-                .help("Multiply by transaction count to determine number of keypairs to create")
-        )
         .arg(
             Arg::with_name("thread-batch-sleep-ms")
                 .short("z")
@@ -139,39 +120,6 @@ pub fn build_args<'a, 'b>(version: &'b str) -> App<'a, 'b> {
                 .takes_value(true)
                 .help("Per-thread-per-iteration sleep in ms"),
         )
-        .arg(
-            Arg::with_name("write-client-keys")
-                .long("write-client-keys")
-                .value_name("FILENAME")
-                .takes_value(true)
-                .help("Generate client keys and stakes and write the list to YAML file"),
-        )
-        .arg(
-            Arg::with_name("read-client-keys")
-                .long("read-client-keys")
-                .value_name("FILENAME")
-                .takes_value(true)
-                .help("Read client keys and stakes from the YAML file"),
-        )
-        .arg(
-            Arg::with_name("target_lamports_per_signature")
-                .long("target-lamports-per-signature")
-                .value_name("LAMPORTS")
-                .takes_value(true)
-                .help(
-                    "The cost in lamports that the cluster will charge for signature \
-                     verification when the cluster is operating at target-signatures-per-slot",
-                ),
-        )
-        .arg(
-            Arg::with_name("num_lamports_per_account")
-                .long("num-lamports-per-account")
-                .value_name("LAMPORTS")
-                .takes_value(true)
-                .help(
-                    "Number of lamports per account.",
-                ),
-        )
 }
 
 /// Parses a clap `ArgMatches` structure into a `Config`
@@ -182,22 +130,22 @@ pub fn build_args<'a, 'b>(version: &'b str) -> App<'a, 'b> {
 pub fn extract_args<'a>(matches: &ArgMatches<'a>) -> Config {
     let mut args = Config::default();
 
-    if let Some(addr) = matches.value_of("entrypoint") {
+    if let Some(addr) = matches.value_of("network") {
-        args.entrypoint_addr = solana_net_utils::parse_host_port(addr).unwrap_or_else(|e| {
+        args.network_addr = addr.parse().unwrap_or_else(|e| {
-            eprintln!("failed to parse entrypoint address: {}", e);
+            eprintln!("failed to parse network: {}", e);
             exit(1)
         });
     }
 
-    if let Some(addr) = matches.value_of("faucet") {
+    if let Some(addr) = matches.value_of("drone") {
-        args.faucet_addr = solana_net_utils::parse_host_port(addr).unwrap_or_else(|e| {
+        args.drone_addr = addr.parse().unwrap_or_else(|e| {
-            eprintln!("failed to parse faucet address: {}", e);
+            eprintln!("failed to parse drone address: {}", e);
             exit(1)
         });
     }
 
     if matches.is_present("identity") {
-        args.id = read_keypair_file(matches.value_of("identity").unwrap())
+        args.id = read_keypair(matches.value_of("identity").unwrap())
             .expect("can't read client identity");
     }
 
@@ -217,15 +165,7 @@ pub fn extract_args<'a>(matches: &ArgMatches<'a>) -> Config {
     }
 
     if let Some(s) = matches.value_of("tx_count") {
-        args.tx_count = s.to_string().parse().expect("can't parse tx_count");
+        args.tx_count = s.to_string().parse().expect("can't parse tx_account");
-    }
-
-    if let Some(s) = matches.value_of("keypair_multiplier") {
-        args.keypair_multiplier = s
-            .to_string()
-            .parse()
-            .expect("can't parse keypair-multiplier");
-        assert!(args.keypair_multiplier >= 2);
     }
 
     if let Some(t) = matches.value_of("thread-batch-sleep-ms") {
@@ -236,28 +176,8 @@ pub fn extract_args<'a>(matches: &ArgMatches<'a>) -> Config {
     }
 
     args.sustained = matches.is_present("sustained");
-
+    args.converge_only = matches.is_present("converge-only");
-    if let Some(s) = matches.value_of("write-client-keys") {
+    args.reject_extra_nodes = matches.is_present("reject-extra-nodes");
-        args.write_to_client_file = true;
-        args.client_ids_and_stake_file = s.to_string();
-    }
-
-    if let Some(s) = matches.value_of("read-client-keys") {
-        assert!(!args.write_to_client_file);
-        args.read_from_client_file = true;
-        args.client_ids_and_stake_file = s.to_string();
-    }
-
-    if let Some(v) = matches.value_of("target_lamports_per_signature") {
-        args.target_lamports_per_signature = v.to_string().parse().expect("can't parse lamports");
-    }
-
-    args.use_move = matches.is_present("use-move");
-    args.multi_client = !matches.is_present("no-multi-client");
-
-    if let Some(v) = matches.value_of("num_lamports_per_account") {
-        args.num_lamports_per_account = v.to_string().parse().expect("can't parse lamports");
-    }
 
     args
 }

bench-tps/src/lib.rs

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

bench-tps/src/main.rs

@@ -1,137 +1,251 @@
-use log::*;
+mod bench;
-use solana_bench_tps::bench::{do_bench_tps, generate_and_fund_keypairs, generate_keypairs};
+mod cli;
-use solana_bench_tps::cli;
-use solana_core::gossip_service::{discover_cluster, get_client, get_multi_client};
-use solana_genesis::Base64Account;
-use solana_sdk::fee_calculator::FeeCalculator;
-use solana_sdk::signature::{Keypair, KeypairUtil};
-use solana_sdk::system_program;
-use std::{collections::HashMap, fs::File, io::prelude::*, path::Path, process::exit, sync::Arc};
 
-/// Number of signatures for all transactions in ~1 week at ~100K TPS
+use crate::bench::*;
-pub const NUM_SIGNATURES_FOR_TXS: u64 = 100_000 * 60 * 60 * 24 * 7;
+use solana::cluster_info::FULLNODE_PORT_RANGE;
+use solana::gen_keys::GenKeys;
+use solana::gossip_service::discover;
+use solana_client::client::create_client;
+use solana_metrics;
+use solana_sdk::signature::{Keypair, 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;
 
 fn main() {
-    solana_logger::setup_with_default("solana=info");
+    solana_logger::setup();
     solana_metrics::set_panic_hook("bench-tps");
 
-    let matches = cli::build_args(solana_clap_utils::version!()).get_matches();
+    let matches = cli::build_args().get_matches();
-    let cli_config = cli::extract_args(&matches);
+
+    let cfg = cli::extract_args(&matches);
 
     let cli::Config {
-        entrypoint_addr,
+        network_addr: network,
-        faucet_addr,
+        drone_addr,
         id,
+        threads,
+        thread_batch_sleep_ms,
         num_nodes,
+        duration,
         tx_count,
-        keypair_multiplier,
+        sustained,
-        client_ids_and_stake_file,
+        reject_extra_nodes,
-        write_to_client_file,
+        converge_only,
-        read_from_client_file,
+    } = cfg;
-        target_lamports_per_signature,
-        use_move,
-        multi_client,
-        num_lamports_per_account,
-        ..
-    } = &cli_config;
 
-    let keypair_count = *tx_count * keypair_multiplier;
+    let nodes = discover(&network, num_nodes).unwrap_or_else(|err| {
-    if *write_to_client_file {
+        eprintln!("Failed to discover {} nodes: {:?}", num_nodes, err);
-        info!("Generating {} keypairs", keypair_count);
+        exit(1);
-        let (keypairs, _) = generate_keypairs(&id, keypair_count as u64);
+    });
-        let num_accounts = keypairs.len() as u64;
+    if nodes.len() < num_nodes {
-        let max_fee =
+        eprintln!(
-            FeeCalculator::new(*target_lamports_per_signature, 0).max_lamports_per_signature;
+            "Error: Insufficient nodes discovered.  Expecting {} or more",
-        let num_lamports_per_account = (num_accounts - 1 + NUM_SIGNATURES_FOR_TXS * max_fee)
+            num_nodes
-            / num_accounts
+        );
-            + num_lamports_per_account;
+        exit(1);
-        let mut accounts = HashMap::new();
+    }
-        keypairs.iter().for_each(|keypair| {
+    if reject_extra_nodes && nodes.len() > num_nodes {
-            accounts.insert(
+        eprintln!(
-                serde_json::to_string(&keypair.to_bytes().to_vec()).unwrap(),
+            "Error: Extra nodes discovered.  Expecting exactly {}",
-                Base64Account {
+            num_nodes
-                    balance: num_lamports_per_account,
+        );
-                    executable: false,
+        exit(1);
-                    owner: system_program::id().to_string(),
-                    data: String::new(),
-                },
-            );
-        });
-
-        info!("Writing {}", client_ids_and_stake_file);
-        let serialized = serde_yaml::to_string(&accounts).unwrap();
-        let path = Path::new(&client_ids_and_stake_file);
-        let mut file = File::create(path).unwrap();
-        file.write_all(&serialized.into_bytes()).unwrap();
-        return;
     }
 
-    info!("Connecting to the cluster");
+    if converge_only {
-    let (nodes, _archivers) =
+        return;
-        discover_cluster(&entrypoint_addr, *num_nodes).unwrap_or_else(|err| {
+    }
-            eprintln!("Failed to discover {} nodes: {:?}", num_nodes, err);
+    let cluster_entrypoint = nodes[0].clone(); // Pick the first node, why not?
-            exit(1);
-        });
 
-    let client = if *multi_client {
+    let mut client = create_client(cluster_entrypoint.client_facing_addr(), FULLNODE_PORT_RANGE);
-        let (client, num_clients) = get_multi_client(&nodes);
+    let mut barrier_client =
-        if nodes.len() < num_clients {
+        create_client(cluster_entrypoint.client_facing_addr(), FULLNODE_PORT_RANGE);
-            eprintln!(
-                "Error: Insufficient nodes discovered.  Expecting {} or more",
-                num_nodes
-            );
-            exit(1);
-        }
-        Arc::new(client)
-    } else {
-        Arc::new(get_client(&nodes))
-    };
 
-    let (keypairs, move_keypairs) = if *read_from_client_file && !use_move {
+    let mut seed = [0u8; 32];
-        let path = Path::new(&client_ids_and_stake_file);
+    seed.copy_from_slice(&id.public_key_bytes()[..32]);
-        let file = File::open(path).unwrap();
+    let mut rnd = GenKeys::new(seed);
 
-        info!("Reading {}", client_ids_and_stake_file);
+    println!("Creating {} keypairs...", tx_count * 2);
-        let accounts: HashMap<String, Base64Account> = serde_yaml::from_reader(file).unwrap();
+    let mut total_keys = 0;
-        let mut keypairs = vec![];
+    let mut target = tx_count * 2;
-        let mut last_balance = 0;
+    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 = Keypair::new().pubkey();
 
-        accounts
+    println!("Get lamports...");
-            .into_iter()
+    let num_lamports_per_account = 20;
-            .for_each(|(keypair, primordial_account)| {
-                let bytes: Vec<u8> = serde_json::from_str(keypair.as_str()).unwrap();
-                keypairs.push(Keypair::from_bytes(&bytes).unwrap());
-                last_balance = primordial_account.balance;
-            });
 
-        if keypairs.len() < keypair_count {
+    // Sample the first keypair, see if it has lamports, if so then resume
-            eprintln!(
+    // to avoid lamport loss
-                "Expected {} accounts in {}, only received {} (--tx_count mismatch?)",
+    let keypair0_balance = client
-                keypair_count,
+        .poll_get_balance(&gen_keypairs.last().unwrap().pubkey())
-                client_ids_and_stake_file,
+        .unwrap_or(0);
-                keypairs.len(),
+
-            );
+    if num_lamports_per_account > keypair0_balance {
-            exit(1);
+        let extra = num_lamports_per_account - keypair0_balance;
-        }
+        let total = extra * (gen_keypairs.len() as u64);
-        // Sort keypairs so that do_bench_tps() uses the same subset of accounts for each run.
+        airdrop_lamports(&mut client, &drone_addr, &id, total);
-        // This prevents the amount of storage needed for bench-tps accounts from creeping up
+        println!("adding more lamports {}", extra);
-        // across multiple runs.
+        fund_keys(&mut client, &id, &gen_keypairs, extra);
-        keypairs.sort_by(|x, y| x.pubkey().to_string().cmp(&y.pubkey().to_string()));
+    }
-        (keypairs, None)
+    let start = gen_keypairs.len() - (tx_count * 2) as usize;
-    } else {
+    let keypairs = &gen_keypairs[start..];
-        generate_and_fund_keypairs(
+    airdrop_lamports(&mut barrier_client, &drone_addr, &barrier_source_keypair, 1);
-            client.clone(),
+
-            Some(*faucet_addr),
+    println!("Get last ID...");
-            &id,
+    let mut blockhash = client.get_recent_blockhash();
-            keypair_count,
+    println!("Got last ID {:?}", blockhash);
-            *num_lamports_per_account,
+
-            *use_move,
+    let first_tx_count = client.transaction_count();
-        )
+    println!("Initial transaction count {}", first_tx_count);
-        .unwrap_or_else(|e| {
+
-            eprintln!("Error could not fund keys: {:?}", e);
+    let exit_signal = Arc::new(AtomicBool::new(false));
-            exit(1);
+
+    // 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();
 
-    do_bench_tps(client, cli_config, keypairs, move_keypairs);
+    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),
+    );
+}
+
+#[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);
+    }
 }

bench-tps/tests/bench_tps.rs

@@ -1,86 +0,0 @@
-use serial_test_derive::serial;
-use solana_bench_tps::bench::{do_bench_tps, generate_and_fund_keypairs};
-use solana_bench_tps::cli::Config;
-use solana_client::thin_client::create_client;
-use solana_core::cluster_info::VALIDATOR_PORT_RANGE;
-use solana_core::validator::ValidatorConfig;
-use solana_faucet::faucet::run_local_faucet;
-use solana_local_cluster::local_cluster::{ClusterConfig, LocalCluster};
-#[cfg(feature = "move")]
-use solana_sdk::move_loader::solana_move_loader_program;
-use solana_sdk::signature::{Keypair, KeypairUtil};
-use std::sync::{mpsc::channel, Arc};
-use std::time::Duration;
-
-fn test_bench_tps_local_cluster(config: Config) {
-    #[cfg(feature = "move")]
-    let native_instruction_processors = vec![solana_move_loader_program()];
-
-    #[cfg(not(feature = "move"))]
-    let native_instruction_processors = vec![];
-
-    solana_logger::setup();
-    const NUM_NODES: usize = 1;
-    let cluster = LocalCluster::new(&ClusterConfig {
-        node_stakes: vec![999_990; NUM_NODES],
-        cluster_lamports: 200_000_000,
-        validator_configs: vec![ValidatorConfig::default(); NUM_NODES],
-        native_instruction_processors,
-        ..ClusterConfig::default()
-    });
-
-    let faucet_keypair = Keypair::new();
-    cluster.transfer(
-        &cluster.funding_keypair,
-        &faucet_keypair.pubkey(),
-        100_000_000,
-    );
-
-    let client = Arc::new(create_client(
-        (cluster.entry_point_info.rpc, cluster.entry_point_info.tpu),
-        VALIDATOR_PORT_RANGE,
-    ));
-
-    let (addr_sender, addr_receiver) = channel();
-    run_local_faucet(faucet_keypair, addr_sender, None);
-    let faucet_addr = addr_receiver.recv_timeout(Duration::from_secs(2)).unwrap();
-
-    let lamports_per_account = 100;
-
-    let keypair_count = config.tx_count * config.keypair_multiplier;
-    let (keypairs, move_keypairs) = generate_and_fund_keypairs(
-        client.clone(),
-        Some(faucet_addr),
-        &config.id,
-        keypair_count,
-        lamports_per_account,
-        config.use_move,
-    )
-    .unwrap();
-
-    let _total = do_bench_tps(client, config, keypairs, move_keypairs);
-
-    #[cfg(not(debug_assertions))]
-    assert!(_total > 100);
-}
-
-#[test]
-#[serial]
-fn test_bench_tps_local_cluster_solana() {
-    let mut config = Config::default();
-    config.tx_count = 100;
-    config.duration = Duration::from_secs(10);
-
-    test_bench_tps_local_cluster(config);
-}
-
-#[test]
-#[serial]
-fn test_bench_tps_local_cluster_move() {
-    let mut config = Config::default();
-    config.tx_count = 100;
-    config.duration = Duration::from_secs(10);
-    config.use_move = true;
-
-    test_bench_tps_local_cluster(config);
-}

benches/append_vec.rs

@@ -0,0 +1,248 @@
+#![feature(test)]
+
+extern crate rand;
+extern crate test;
+
+use bincode::{deserialize, serialize_into, serialized_size};
+use rand::{thread_rng, Rng};
+use solana_runtime::append_vec::{
+    deserialize_account, get_serialized_size, serialize_account, AppendVec,
+};
+use solana_sdk::account::Account;
+use solana_sdk::signature::{Keypair, KeypairUtil};
+use std::env;
+use std::io::Cursor;
+use std::path::PathBuf;
+use std::sync::atomic::{AtomicUsize, Ordering};
+use std::sync::{Arc, RwLock};
+use std::thread::spawn;
+use test::Bencher;
+
+const START_SIZE: u64 = 4 * 1024 * 1024;
+const INC_SIZE: u64 = 1 * 1024 * 1024;
+
+macro_rules! align_up {
+    ($addr: expr, $align: expr) => {
+        ($addr + ($align - 1)) & !($align - 1)
+    };
+}
+
+fn get_append_vec_bench_path(path: &str) -> PathBuf {
+    let out_dir = env::var("OUT_DIR").unwrap_or_else(|_| "target".to_string());
+    let mut buf = PathBuf::new();
+    buf.push(&format!("{}/{}", out_dir, path));
+    buf
+}
+
+#[bench]
+fn append_vec_atomic_append(bencher: &mut Bencher) {
+    let path = get_append_vec_bench_path("bench_append");
+    let mut vec = AppendVec::<AtomicUsize>::new(&path, true, START_SIZE, INC_SIZE);
+    bencher.iter(|| {
+        if vec.append(AtomicUsize::new(0)).is_none() {
+            assert!(vec.grow_file().is_ok());
+            assert!(vec.append(AtomicUsize::new(0)).is_some());
+        }
+    });
+    std::fs::remove_file(path).unwrap();
+}
+
+#[bench]
+fn append_vec_atomic_random_access(bencher: &mut Bencher) {
+    let path = get_append_vec_bench_path("bench_ra");
+    let mut vec = AppendVec::<AtomicUsize>::new(&path, true, START_SIZE, INC_SIZE);
+    let size = 1_000_000;
+    for _ in 0..size {
+        if vec.append(AtomicUsize::new(0)).is_none() {
+            assert!(vec.grow_file().is_ok());
+            assert!(vec.append(AtomicUsize::new(0)).is_some());
+        }
+    }
+    bencher.iter(|| {
+        let index = thread_rng().gen_range(0, size as u64);
+        vec.get(index * std::mem::size_of::<AtomicUsize>() as u64);
+    });
+    std::fs::remove_file(path).unwrap();
+}
+
+#[bench]
+fn append_vec_atomic_random_change(bencher: &mut Bencher) {
+    let path = get_append_vec_bench_path("bench_rax");
+    let mut vec = AppendVec::<AtomicUsize>::new(&path, true, START_SIZE, INC_SIZE);
+    let size = 1_000_000;
+    for k in 0..size {
+        if vec.append(AtomicUsize::new(k)).is_none() {
+            assert!(vec.grow_file().is_ok());
+            assert!(vec.append(AtomicUsize::new(k)).is_some());
+        }
+    }
+    bencher.iter(|| {
+        let index = thread_rng().gen_range(0, size as u64);
+        let atomic1 = vec.get(index * std::mem::size_of::<AtomicUsize>() as u64);
+        let current1 = atomic1.load(Ordering::Relaxed);
+        assert_eq!(current1, index as usize);
+        let next = current1 + 1;
+        let mut index = vec.append(AtomicUsize::new(next));
+        if index.is_none() {
+            assert!(vec.grow_file().is_ok());
+            index = vec.append(AtomicUsize::new(next));
+        }
+        let atomic2 = vec.get(index.unwrap());
+        let current2 = atomic2.load(Ordering::Relaxed);
+        assert_eq!(current2, next);
+    });
+    std::fs::remove_file(path).unwrap();
+}
+
+#[bench]
+fn append_vec_atomic_random_read(bencher: &mut Bencher) {
+    let path = get_append_vec_bench_path("bench_read");
+    let mut vec = AppendVec::<AtomicUsize>::new(&path, true, START_SIZE, INC_SIZE);
+    let size = 1_000_000;
+    for _ in 0..size {
+        if vec.append(AtomicUsize::new(0)).is_none() {
+            assert!(vec.grow_file().is_ok());
+            assert!(vec.append(AtomicUsize::new(0)).is_some());
+        }
+    }
+    bencher.iter(|| {
+        let index = thread_rng().gen_range(0, size);
+        let atomic1 = vec.get((index * std::mem::size_of::<AtomicUsize>()) as u64);
+        let current1 = atomic1.load(Ordering::Relaxed);
+        assert_eq!(current1, 0);
+    });
+    std::fs::remove_file(path).unwrap();
+}
+
+#[bench]
+fn append_vec_concurrent_lock_append(bencher: &mut Bencher) {
+    let path = get_append_vec_bench_path("bench_lock_append");
+    let vec = Arc::new(RwLock::new(AppendVec::<AtomicUsize>::new(
+        &path, true, START_SIZE, INC_SIZE,
+    )));
+    let vec1 = vec.clone();
+    let size = 1_000_000;
+    let count = Arc::new(AtomicUsize::new(0));
+    let count1 = count.clone();
+    spawn(move || loop {
+        let mut len = count.load(Ordering::Relaxed);
+        {
+            let rlock = vec1.read().unwrap();
+            loop {
+                if rlock.append(AtomicUsize::new(0)).is_none() {
+                    break;
+                }
+                len = count.fetch_add(1, Ordering::Relaxed);
+            }
+            if len >= size {
+                break;
+            }
+        }
+        {
+            let mut wlock = vec1.write().unwrap();
+            if len >= size {
+                break;
+            }
+            assert!(wlock.grow_file().is_ok());
+        }
+    });
+    bencher.iter(|| {
+        let _rlock = vec.read().unwrap();
+        let len = count1.load(Ordering::Relaxed);
+        assert!(len < size * 2);
+    });
+    std::fs::remove_file(path).unwrap();
+}
+
+#[bench]
+fn append_vec_concurrent_get_append(bencher: &mut Bencher) {
+    let path = get_append_vec_bench_path("bench_get_append");
+    let vec = Arc::new(RwLock::new(AppendVec::<AtomicUsize>::new(
+        &path, true, START_SIZE, INC_SIZE,
+    )));
+    let vec1 = vec.clone();
+    let size = 1_000_000;
+    let count = Arc::new(AtomicUsize::new(0));
+    let count1 = count.clone();
+    spawn(move || loop {
+        let mut len = count.load(Ordering::Relaxed);
+        {
+            let rlock = vec1.read().unwrap();
+            loop {
+                if rlock.append(AtomicUsize::new(0)).is_none() {
+                    break;
+                }
+                len = count.fetch_add(1, Ordering::Relaxed);
+            }
+            if len >= size {
+                break;
+            }
+        }
+        {
+            let mut wlock = vec1.write().unwrap();
+            if len >= size {
+                break;
+            }
+            assert!(wlock.grow_file().is_ok());
+        }
+    });
+    bencher.iter(|| {
+        let rlock = vec.read().unwrap();
+        let len = count1.load(Ordering::Relaxed);
+        if len > 0 {
+            let index = thread_rng().gen_range(0, len);
+            rlock.get((index * std::mem::size_of::<AtomicUsize>()) as u64);
+        }
+    });
+    std::fs::remove_file(path).unwrap();
+}
+
+#[bench]
+fn bench_account_serialize(bencher: &mut Bencher) {
+    let num: usize = 1000;
+    let account = Account::new(2, 100, &Keypair::new().pubkey());
+    let len = get_serialized_size(&account);
+    let ser_len = align_up!(len + std::mem::size_of::<u64>(), std::mem::size_of::<u64>());
+    let mut memory = vec![0; num * ser_len];
+    bencher.iter(|| {
+        for i in 0..num {
+            let start = i * ser_len;
+            serialize_account(&mut memory[start..start + ser_len], &account, len);
+        }
+    });
+
+    // make sure compiler doesn't delete the code.
+    let index = thread_rng().gen_range(0, num);
+    if memory[index] != 0 {
+        println!("memory: {}", memory[index]);
+    }
+
+    let start = index * ser_len;
+    let new_account = deserialize_account(&memory[start..start + ser_len], 0, num * len).unwrap();
+    assert_eq!(new_account, account);
+}
+
+#[bench]
+fn bench_account_serialize_bincode(bencher: &mut Bencher) {
+    let num: usize = 1000;
+    let account = Account::new(2, 100, &Keypair::new().pubkey());
+    let len = serialized_size(&account).unwrap() as usize;
+    let mut memory = vec![0u8; num * len];
+    bencher.iter(|| {
+        for i in 0..num {
+            let start = i * len;
+            let cursor = Cursor::new(&mut memory[start..start + len]);
+            serialize_into(cursor, &account).unwrap();
+        }
+    });
+
+    // make sure compiler doesn't delete the code.
+    let index = thread_rng().gen_range(0, len);
+    if memory[index] != 0 {
+        println!("memory: {}", memory[index]);
+    }
+
+    let start = index * len;
+    let new_account: Account = deserialize(&memory[start..start + len]).unwrap();
+    assert_eq!(new_account, account);
+}

benches/banking_stage.rs

@@ -0,0 +1,241 @@
+#![feature(test)]
+
+extern crate test;
+
+use rand::{thread_rng, Rng};
+use rayon::prelude::*;
+use solana::banking_stage::{create_test_recorder, BankingStage};
+use solana::cluster_info::ClusterInfo;
+use solana::cluster_info::Node;
+use solana::packet::to_packets_chunked;
+use solana::poh_recorder::WorkingBankEntries;
+use solana::service::Service;
+use solana_runtime::bank::Bank;
+use solana_sdk::genesis_block::GenesisBlock;
+use solana_sdk::hash::hash;
+use solana_sdk::pubkey::Pubkey;
+use solana_sdk::signature::{KeypairUtil, Signature};
+use solana_sdk::system_transaction::SystemTransaction;
+use solana_sdk::timing::{DEFAULT_TICKS_PER_SLOT, MAX_RECENT_BLOCKHASHES};
+use std::iter;
+use std::sync::atomic::Ordering;
+use std::sync::mpsc::{channel, Receiver};
+use std::sync::{Arc, RwLock};
+use std::time::Duration;
+use test::Bencher;
+
+fn check_txs(receiver: &Receiver<WorkingBankEntries>, 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]
+#[ignore]
+fn bench_banking_stage_multi_accounts(bencher: &mut Bencher) {
+    let num_threads = 4;
+    //   a multiple of packet chunk  2X duplicates to avoid races
+    let txes = 192 * 50 * num_threads * 2;
+    let mint_total = 1_000_000_000_000;
+    let (genesis_block, mint_keypair) = GenesisBlock::new(mint_total);
+
+    let (verified_sender, verified_receiver) = channel();
+    let bank = Arc::new(Bank::new(&genesis_block));
+    let dummy = SystemTransaction::new_move(
+        &mint_keypair,
+        &mint_keypair.pubkey(),
+        1,
+        genesis_block.hash(),
+        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 = SystemTransaction::new_move(
+            &mint_keypair,
+            &tx.account_keys[0],
+            mint_total / txes as u64,
+            genesis_block.hash(),
+            0,
+        );
+        let x = bank.process_transaction(&fund);
+        x.unwrap();
+    });
+    //sanity check, make sure all the transactions can execute sequentially
+    transactions.iter().for_each(|tx| {
+        let res = bank.process_transaction(&tx);
+        assert!(res.is_ok(), "sanity test transactions");
+    });
+    bank.clear_signatures();
+    //sanity check, make sure all the transactions can execute in parallel
+    let res = bank.process_transactions(&transactions);
+    for r in res {
+        assert!(r.is_ok(), "sanity parallel execution");
+    }
+    bank.clear_signatures();
+    let 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 (exit, poh_recorder, poh_service, signal_receiver) = create_test_recorder(&bank);
+    let cluster_info = ClusterInfo::new_with_invalid_keypair(Node::new_localhost().info);
+    let cluster_info = Arc::new(RwLock::new(cluster_info));
+    let _banking_stage = BankingStage::new(&cluster_info, &poh_recorder, verified_receiver);
+    poh_recorder.lock().unwrap().set_bank(&bank);
+
+    let mut id = genesis_block.hash();
+    for _ in 0..(MAX_RECENT_BLOCKHASHES * DEFAULT_TICKS_PER_SLOT as usize) {
+        id = hash(&id.as_ref());
+        bank.register_tick(&id);
+    }
+
+    let half_len = verified.len() / 2;
+    let mut start = 0;
+    bencher.iter(move || {
+        // make sure the transactions are still valid
+        bank.register_tick(&genesis_block.hash());
+        for v in verified[start..start + half_len].chunks(verified.len() / num_threads) {
+            verified_sender.send(v.to_vec()).unwrap();
+        }
+        check_txs(&signal_receiver, txes / 2);
+        bank.clear_signatures();
+        start += half_len;
+        start %= verified.len();
+    });
+    exit.store(true, Ordering::Relaxed);
+    poh_service.join().unwrap();
+}
+
+#[bench]
+#[ignore]
+fn bench_banking_stage_multi_programs(bencher: &mut Bencher) {
+    let progs = 4;
+    let num_threads = 4;
+    //   a multiple of packet chunk  2X duplicates to avoid races
+    let txes = 96 * 100 * num_threads * 2;
+    let mint_total = 1_000_000_000_000;
+    let (genesis_block, mint_keypair) = GenesisBlock::new(mint_total);
+
+    let (verified_sender, verified_receiver) = channel();
+    let bank = Arc::new(Bank::new(&genesis_block));
+    let dummy = SystemTransaction::new_move(
+        &mint_keypair,
+        &mint_keypair.pubkey(),
+        1,
+        genesis_block.hash(),
+        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 = SystemTransaction::new_move(
+            &mint_keypair,
+            &tx.account_keys[0],
+            mint_total / txes as u64,
+            genesis_block.hash(),
+            0,
+        );
+        bank.process_transaction(&fund).unwrap();
+    });
+    //sanity check, make sure all the transactions can execute sequentially
+    transactions.iter().for_each(|tx| {
+        let res = bank.process_transaction(&tx);
+        assert!(res.is_ok(), "sanity test transactions");
+    });
+    bank.clear_signatures();
+    //sanity check, make sure all the transactions can execute in parallel
+    let res = bank.process_transactions(&transactions);
+    for r in res {
+        assert!(r.is_ok(), "sanity parallel execution");
+    }
+    bank.clear_signatures();
+    let 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 (exit, poh_recorder, poh_service, signal_receiver) = create_test_recorder(&bank);
+    let cluster_info = ClusterInfo::new_with_invalid_keypair(Node::new_localhost().info);
+    let cluster_info = Arc::new(RwLock::new(cluster_info));
+    let _banking_stage = BankingStage::new(&cluster_info, &poh_recorder, verified_receiver);
+    poh_recorder.lock().unwrap().set_bank(&bank);
+
+    let mut id = genesis_block.hash();
+    for _ in 0..(MAX_RECENT_BLOCKHASHES * DEFAULT_TICKS_PER_SLOT as usize) {
+        id = hash(&id.as_ref());
+        bank.register_tick(&id);
+    }
+
+    let half_len = verified.len() / 2;
+    let mut start = 0;
+    bencher.iter(move || {
+        // make sure the transactions are still valid
+        bank.register_tick(&genesis_block.hash());
+        for v in verified[start..start + half_len].chunks(verified.len() / num_threads) {
+            verified_sender.send(v.to_vec()).unwrap();
+        }
+        check_txs(&signal_receiver, txes / 2);
+        bank.clear_signatures();
+        start += half_len;
+        start %= verified.len();
+    });
+    exit.store(true, Ordering::Relaxed);
+    poh_service.join().unwrap();
+}

benches/blocktree.rs

@@ -0,0 +1,194 @@
+#![feature(test)]
+use rand;
+
+extern crate test;
+
+#[macro_use]
+extern crate solana;
+
+use rand::seq::SliceRandom;
+use rand::{thread_rng, Rng};
+use solana::blocktree::{get_tmp_ledger_path, Blocktree};
+use solana::entry::{make_large_test_entries, make_tiny_test_entries, EntrySlice};
+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 Vec<Blob>, ledger_path: &str) {
+    let blocktree =
+        Blocktree::open(&ledger_path).expect("Expected to be able to open database ledger");
+
+    let num_blobs = blobs.len();
+
+    bench.iter(move || {
+        for blob in blobs.iter_mut() {
+            let index = blob.index();
+
+            blocktree
+                .put_data_blob_bytes(
+                    blob.slot(),
+                    index,
+                    &blob.data[..BLOB_HEADER_SIZE + blob.size()],
+                )
+                .unwrap();
+
+            blob.set_index(index + num_blobs as u64);
+        }
+    });
+
+    Blocktree::destroy(&ledger_path).expect("Expected successful database destruction");
+}
+
+// Insert some blobs into the ledger in preparation for read benchmarks
+fn setup_read_bench(
+    blocktree: &mut Blocktree,
+    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 mut blobs = entries.to_blobs();
+    for (index, b) in blobs.iter_mut().enumerate() {
+        b.set_index(index as u64);
+        b.set_slot(slot);
+    }
+    blocktree
+        .write_blobs(&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!();
+    let num_entries = 32 * 1024;
+    let entries = make_tiny_test_entries(num_entries);
+    let mut blobs = entries.to_blobs();
+    for (index, b) in blobs.iter_mut().enumerate() {
+        b.set_index(index as u64);
+    }
+    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!();
+    let num_entries = 32 * 1024;
+    let entries = make_large_test_entries(num_entries);
+    let mut blobs = entries.to_blobs();
+    for (index, b) in blobs.iter_mut().enumerate() {
+        b.set_index(index as u64);
+    }
+
+    bench_write_blobs(bench, &mut blobs, &ledger_path);
+}
+
+#[bench]
+#[ignore]
+fn bench_read_sequential(bench: &mut Bencher) {
+    let ledger_path = get_tmp_ledger_path!();
+    let mut blocktree =
+        Blocktree::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 blocktree, 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 _ = blocktree.get_data_blob(slot, i as u64 % total_blobs);
+        }
+    });
+
+    Blocktree::destroy(&ledger_path).expect("Expected successful database destruction");
+}
+
+#[bench]
+#[ignore]
+fn bench_read_random(bench: &mut Bencher) {
+    let ledger_path = get_tmp_ledger_path!();
+    let mut blocktree =
+        Blocktree::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 blocktree, 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 _ = blocktree.get_data_blob(slot, *i as u64);
+        }
+    });
+
+    Blocktree::destroy(&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!();
+    let blocktree =
+        Blocktree::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 blobs = entries.to_blobs();
+
+    blobs.shuffle(&mut thread_rng());
+
+    bench.iter(move || {
+        for blob in blobs.iter_mut() {
+            let index = blob.index();
+            blob.set_index(index + num_entries as u64);
+        }
+        blocktree.write_blobs(&blobs).unwrap();
+    });
+
+    Blocktree::destroy(&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!();
+    let blocktree =
+        Blocktree::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_shared_blobs();
+    shared_blobs.shuffle(&mut thread_rng());
+
+    bench.iter(move || {
+        for blob in shared_blobs.iter_mut() {
+            let index = blob.read().unwrap().index();
+            blocktree.write_shared_blobs(vec![blob.clone()]).unwrap();
+            blob.write().unwrap().set_index(index + num_entries as u64);
+        }
+    });
+
+    Blocktree::destroy(&ledger_path).expect("Expected successful database destruction");
+}

benches/chacha.rs

@@ -1,9 +1,9 @@
 //#![feature(test)]
 //
-//extern crate solana_core;
+//extern crate solana;
 //extern crate test;
 //
-//use solana_core::chacha::chacha_cbc_encrypt_files;
+//use solana::chacha::chacha_cbc_encrypt_files;
 //use std::fs::remove_file;
 //use std::fs::File;
 //use std::io::Write;

benches/gen_keys.rs

@@ -2,7 +2,7 @@
 
 extern crate test;
 
-use solana_core::gen_keys::GenKeys;
+use solana::gen_keys::GenKeys;
 use test::Bencher;
 
 #[bench]

benches/ledger.rs

@@ -0,0 +1,24 @@
+#![feature(test)]
+
+extern crate test;
+
+use solana::entry::{next_entries, reconstruct_entries_from_blobs, EntrySlice};
+use solana_sdk::hash::{hash, Hash};
+use solana_sdk::signature::{Keypair, KeypairUtil};
+use solana_sdk::system_transaction::SystemTransaction;
+use test::Bencher;
+
+#[bench]
+fn bench_block_to_blobs_to_block(bencher: &mut Bencher) {
+    let zero = Hash::default();
+    let one = hash(&zero.as_ref());
+    let keypair = Keypair::new();
+    let tx0 = SystemTransaction::new_move(&keypair, &keypair.pubkey(), 1, one, 0);
+    let transactions = vec![tx0; 10];
+    let entries = next_entries(&zero, 1, transactions);
+
+    bencher.iter(|| {
+        let blobs = entries.to_blobs();
+        assert_eq!(reconstruct_entries_from_blobs(blobs).unwrap().0, entries);
+    });
+}

benches/sigverify.rs

@@ -0,0 +1,21 @@
+#![feature(test)]
+
+extern crate test;
+
+use solana::packet::to_packets;
+use solana::sigverify;
+use solana::test_tx::test_tx;
+use test::Bencher;
+
+#[bench]
+fn bench_sigverify(bencher: &mut Bencher) {
+    let tx = test_tx();
+
+    // generate packet vector
+    let batches = to_packets(&vec![tx; 128]);
+
+    // verify packets
+    bencher.iter(|| {
+        let _ans = sigverify::ed25519_verify(&batches);
+    })
+}

book/.gitattributes

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

book/art/consensus.msc

@@ -0,0 +1,15 @@
+msc {
+  client,leader,verifier_a,verifier_b,verifier_c;
+
+  client=>leader [ label = "SUBMIT" ] ;
+  leader=>client [ label = "CONFIRMED" ] ;
+  leader=>verifier_a [ label = "CONFIRMED" ] ;
+  leader=>verifier_b [ label = "CONFIRMED" ] ;
+  leader=>verifier_c [ label = "CONFIRMED" ] ;
+  verifier_a=>leader [ label = "VERIFIED" ] ;
+  verifier_b=>leader [ label = "VERIFIED" ] ;
+  leader=>client [ label = "FINALIZED" ] ;
+  leader=>verifier_a [ label = "FINALIZED" ] ;
+  leader=>verifier_b [ label = "FINALIZED" ] ;
+  leader=>verifier_c [ label = "FINALIZED" ] ;
+}

book/art/data-plane-fanout.bob

@@ -1,19 +0,0 @@
-+------------------------------------------------------------------+
-|                                                                  |
-|   +-----------------+    Neighborhood 0    +-----------------+   |
-|   |                 +--------------------->+                 |   |
-|   |   Validator 1   |                      |   Validator 2   |   |
-|   |                 +<---------------------+                 |   |
-|   +--------+-+------+                      +------+-+--------+   |
-|            | |                                    | |            |
-|            | +-----------------------------+      | |            |
-|            |      +------------------------+------+ |            |
-|            |      |                        |        |            |
-+------------------------------------------------------------------+
-             |      |                        |        |
-             v      v                        v        v
-   +---------+------+---+                  +-+--------+---------+
-   |                    |                  |                    |
-   |   Neighborhood 1   |                  |   Neighborhood 2   |
-   |                    |                  |                    |
-   +--------------------+                  +--------------------+

book/art/data-plane-seeding.bob

@@ -1,15 +0,0 @@
-                          +--------------+
-                          |              |
-             +------------+    Leader    +------------+
-             |            |              |            |
-             |            +--------------+            |
-             v                                        v
-+------------+----------------------------------------+------------+
-|                                                                  |
-|   +-----------------+    Neighborhood 0    +-----------------+   |
-|   |                 +--------------------->+                 |   |
-|   |   Validator 1   |                      |   Validator 2   |   |
-|   |                 +<---------------------+                 |   |
-|   +-----------------+                      +-----------------+   |
-|                                                                  |
-+------------------------------------------------------------------+

book/art/data-plane.bob

@@ -1,18 +1,28 @@
-                                  +--------------------+
+
-                                  |                    |
+                                          +--------------+
-                         +--------+   Neighborhood 0   +----------+
+                                          |              |
-                         |        |                    |          |
+                             +------------+    Leader    +------------+
-                         |        +--------------------+          |
+                             |            |              |            |
-                         v                                        v
+                             |            +--------------+            |
-               +---------+----------+                  +----------+---------+
+                             v                                        v
-               |                    |                  |                    |
+                    +--------+--------+                      +--------+--------+
-               |   Neighborhood 1   |                  |   Neighborhood 2   |
+                    |                 +--------------------->+                 |
-               |                    |                  |                    |
+  +-----------------+   Validator 1   |                      |   Validator 2   +-------------+
-               +---+-----+----------+                  +----------+-----+---+
+  |                 |                 +<---------------------+                 |             |
-                   |     |                                        |     |
+  |                 +------+-+-+------+                      +---+-+-+---------+             |
-                   v     v                                        v     v
+  |                        | | |                                 | | |                       |
-+------------------+-+ +-+------------------+  +------------------+-+ +-+------------------+
+  |                        | | |                                 | | |                       |
-|                    | |                    |  |                    | |                    |
+  |                +---------------------------------------------+ | |                       |
-|   Neighborhood 3   | |   Neighborhood 4   |  |   Neighborhood 5   | |   Neighborhood 6   |
+  |                |       | | |                                   | |                       |
-|                    | |                    |  |                    | |                    |
+  |                |       | | |            +----------------------+ |                       |
-+--------------------+ +--------------------+  +--------------------+ +--------------------+
+  |                |       | | |            |                        |                       |
+  |                |       | | +--------------------------------------------+                |
+  |                |       | |              |                        |      |                |
+  |                |       | +----------------------+                |      |                |
+  |                |       |                |       |                |      |                |
+  v                v       v                v       v                v      v                v
++--------------------+   +--------------------+   +--------------------+  +--------------------+
+|                    |   |                    |   |                    |  |                    |
+|   Neighborhood 1   |   |   Neighborhood 2   |   |   Neighborhood 3   |  |   Neighborhood 4   |
+|                    |   |                    |   |                    |  |                    |
++--------------------+   +--------------------+   +--------------------+  +--------------------+

book/art/fullnode.bob

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

book/art/passive-staking-callflow.msc

@@ -1,30 +0,0 @@
-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"];
-       |||;
-  Cluster box Cluster [label="credits redeemed (at epoch)"];
-
-
-}

book/art/spv-bank-hash.bob

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

book/art/spv-block-merkle.bob

@@ -1,19 +0,0 @@
-                                   +---------------+
-                                   |  Block-Merkle |
-                                   +---------------+
-                                  ^                ^
-                                 /                  \
-                      +-------------+            +-------------+
-                      | Entry-Merkle|            | Entry-Merkle|
-                      +-------------+            +-------------+
-                         ^                                 ^
-                        /                                   \
-                  +-------+                               +-------+
-                  |  Hash |                               |  Hash |
-                  +-------+                               +-------+
-                 ^        ^                                ^      ^
-                /         |                                |       \
- +-----------------+   +-----------------+   +-----------------+   +---+
- | Hash(T1, status)|   | Hash(T2, status)|   | Hash(T3, status)|   | 0 | 
- +-----------------+   +-----------------+   +-----------------+   +---+
-

book/art/tpu.bob

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

book/art/tvu.bob

@@ -7,7 +7,7 @@
                   |  TVU                               |                    |
                   |                                    |                    |
                   |  .-------.   .------------.   .----+---.   .---------.  |
- .------------.   |  | Shred |   | Retransmit |   | Replay |   | Storage |  |
+ .------------.   |  | Blob  |   | Retransmit |   | Replay |   | Storage |  |
  | Upstream   +----->| Fetch +-->| Stage      +-->| Stage  +-->| Stage   |  |
  | Validators |   |  | Stage |   |            |   |        |   |         |  |
  `------------`   |  `-------`   `----+-------`   `----+---`   `---------`  |

book/art/validator-proposal.bob

@@ -1,60 +0,0 @@
-
-                                 .------------.
-                                 | Upstream   |
-                                 | Validators |
-                                 `----+-------`
-                                      |
-                                      |
-             .-----------------------------------.
-             | Validator              |          |
-             |                        v          |
-             |  .-----------.    .------------.  |
- .--------.  |  | Fetch     |    | Repair     |  |
- | Client +---->| Stage     |    | Stage      |  |
- `--------`  |  `---+-------`    `----+-------`  |
-             |      |                 |          |
-             |      v                 v          |
-             |  .-----------.    .------------.  |
-             |  | TPU       |<-->| Blockstore |  |
-             |  |           |    |            |  |
-             |  `-----------`    `----+-------`  |
-             |                        |          |
-             |                        v          |
-             |                   .------------.  |
-             |                   | Multicast  |  |
-             |                   | Stage      |  |
-             |                   `----+-------`  |
-             |                        |          |
-             `-----------------------------------`
-                                      |
-                                      v
-                                 .------------.
-                                 | Downstream |
-                                 | Validators |
-                                 `------------`
-
-
-
-                                 .------------.
-                                 | PoH        |
-                                 | Service    |
-                                 `-------+----`
-                                     ^   |
-                                     |   |
-             .-----------------------------------.
-             | TPU                   |   |       |
-             |                       |   v       |
-  .-------.  |  .-----------.    .---+--------.  |  .------------.
-  | Fetch +---->| SigVerify +--->| Banking    |<--->| Blockstore |
-  | Stage |  |  | Stage     |    | Stage      |  |  |            |
-  `-------`  |  `-----------`    `-----+------`  |  `------------`
-             |                         |         |
-             |                         |         |
-             `-----------------------------------`
-                                       |
-                                       v
-                                 .------------.
-                                 | Banktree   |
-                                 |            |
-                                 `------------`
-

book/art/validator.bob

@@ -1,30 +0,0 @@
-             .---------------------------------------.
-             |  Validator                            |
-             |                                       |
- .--------.  |  .-------------------.                |
- |        |---->|                   |                |
- | Client |  |  | JSON RPC Service  |                |
- |        |<----|                   |                |
- `----+---`  |  `-------------------`                |
-      |      |     ^                                 |
-      |      |     |     .----------------.          | .------------------.
-      |      |     |     | Gossip Service |<-----------| Validators       |
-      |      |     |     `----------------`          | |                  |
-      |      |     |           ^                     | |                  |
-      |      |     |           |                     | |  .------------.  |
-      |      | .---+---.  .----+---. .------------.  | |  |            |  |
-      |      | | Bank  |<-+ Replay | | ShredFetch |<------+ Upstream   |  |
-      |      | | Forks |  | Stage  | |  Stage     |  | |  | Validators |  |
-      |      | `-------`  `--------` `--+---------`  | |  |            |  |
-      |      |     ^              ^     |            | |  `------------`  |
-      |      |     |              |     v            | |                  |
-      |      |     |           .--+---------.        | |                  |
-      |      |     |           | Blockstore |        | |                  |
-      |      |     |           `------------`        | |  .------------.  |
-      |      |     |                ^                | |  |            |  |
-      |      |     |                |                | |  | Downstream |  |
-      |      |  .--+--.     .-------+---.            | |  | Validators |  |
-      `-------->| TPU +---->| Broadcast +---------------->|            |  |
-             |  `-----`     | Stage     |            | |  `------------`  |
-             |              `-----------`            | `------------------`
-             `---------------------------------------`

book/build-cli-usage.sh

@@ -1,34 +0,0 @@
-#!/usr/bin/env bash
-set -e
-
-cd "$(dirname "$0")"
-
-usage=$(cargo -q run -p solana-cli -- -C ~/.foo --help | sed 's|'"$HOME"'|~|g')
-
-out=${1:-src/cli/usage.md}
-
-cat src/cli/.usage.md.header > "$out"
-
-section() {
-  declare mark=${2:-"###"}
-  declare section=$1
-  read -r name rest <<<"$section"
-
-  printf '%s %s
-' "$mark" "$name"
-  printf '```text
-%s
-```
-
-' "$section"
-}
-
-section "$usage" >> "$out"
-
-in_subcommands=0
-while read -r subcommand rest; do
-  [[ $subcommand == "SUBCOMMANDS:" ]] && in_subcommands=1 && continue
-  if ((in_subcommands)); then
-      section "$(cargo -q run -p solana-cli -- help "$subcommand" | sed 's|'"$HOME"'|~|g')" "####" >> "$out"
-  fi
-done <<<"$usage">>"$out"

book/build.sh

@@ -3,14 +3,16 @@ set -e
 
 cd "$(dirname "$0")"
 
-# md check
+cargo_install_unless() {
-find src -name '*.md' -a \! -name SUMMARY.md |
+  declare crate=$1
- while read -r file; do
+  shift
-   if ! grep -q '('"${file#src/}"')' src/SUMMARY.md; then
-       echo "Error: $file missing from SUMMARY.md"
-       exit 1
-   fi
- done
 
+  "$@" > /dev/null 2>&1 || \
+    cargo install "$crate"
+}
 
-make -j"$(nproc)" test
+export PATH=$CARGO_HOME/bin:$PATH
+cargo_install_unless mdbook mdbook --help
+cargo_install_unless svgbob_cli svgbob --help
+
+make -j"$(nproc)"

book/makefile

@@ -1,41 +1,31 @@
 BOB_SRCS=$(wildcard art/*.bob)
-MSC_SRCS=$(wildcard art/*.msc)
+MD_SRCS=$(wildcard src/*.md)
-MD_SRCS=$(wildcard src/*.md src/*/*.md)
 
-SVG_IMGS=$(BOB_SRCS:art/%.bob=src/.gitbook/assets/%.svg) $(MSC_SRCS:art/%.msc=src/.gitbook/assets/%.svg)
+SVG_IMGS=$(BOB_SRCS:art/%.bob=src/img/%.svg)
 
-TARGET=html/index.html
+all: html/index.html
-TEST_STAMP=src/tests.ok
 
-all: $(TARGET)
+test: src/tests.ok
 
-svg: $(SVG_IMGS)
+open: all
-
-test: $(TEST_STAMP)
-
-open: $(TEST_STAMP)
 	mdbook build --open
 
 watch: $(SVG_IMGS)
 	mdbook watch
 
-src/.gitbook/assets/%.svg: art/%.bob
+src/img/%.svg: art/%.bob
 	@mkdir -p $(@D)
 	svgbob < $< > $@
 
-src/.gitbook/assets/%.svg: art/%.msc
-	@mkdir -p $(@D)
-	mscgen -T svg -i $< -o $@
-
 src/%.md: %.md
 	@mkdir -p $(@D)
 	@cp $< $@
 
-$(TEST_STAMP): $(TARGET)
+src/tests.ok: $(SVG_IMGS) $(MD_SRCS)
 	mdbook test
 	touch $@
 
-$(TARGET): $(SVG_IMGS) $(MD_SRCS)
+html/index.html: src/tests.ok
 	mdbook build
 
 clean:

book/src/SUMMARY.md

@@ -1,91 +1,59 @@
-# Table of contents
+# Solana Architecture
 
-* [Introduction](introduction.md)
+- [Introduction](introduction.md)
-* [Using Solana from the Command-line](cli/README.md)
+
-  * [Command-line Usage](cli/usage.md)
+- [Terminology](terminology.md)
-  * [Paper Wallet](paper-wallet/README.md)
+
-    * [Installation](paper-wallet/installation.md)
+- [Getting Started](getting-started.md)
-    * [Paper Wallet Usage](paper-wallet/usage.md)
+  - [Example: Web Wallet](webwallet.md)
-  * [Offline Signing](offline-signing/README.md)
+
-    * [Durable Transaction Nonces](offline-signing/durable-nonce.md)
+- [Programming Model](programs.md)
-* [Developing Applications](apps/README.md)
+  - [Example: Tic-Tac-Toe](tictactoe.md)
-  * [Example: Web Wallet](apps/webwallet.md)
+  - [Drones](drones.md)
-  * [Example: Tic-Tac-Toe](apps/tictactoe.md)
+
-  * [Drones](apps/drones.md)
+- [A Solana Cluster](cluster.md)
-  * [Anatomy of a Transaction](transaction.md)
+  - [Synchronization](synchronization.md)
-  * [JSON RPC API](apps/jsonrpc-api.md)
+  - [Leader Rotation](leader-rotation.md)
-  * [JavaScript API](apps/javascript-api.md)
+  - [Fork Generation](fork-generation.md)
-* [Running a Validator](running-validator/README.md)
+  - [Managing Forks](managing-forks.md)
-  * [Validator Requirements](running-validator/validator-reqs.md)
+  - [Data Plane Fanout](data-plane-fanout.md)
-  * [Choosing a Testnet](running-validator/validator-testnet.md)
+  - [Ledger Replication](ledger-replication.md)
-  * [Installing the Validator Software](running-validator/validator-software.md)
+  - [Secure Vote Signing](vote-signing.md)
-  * [Starting a Validator](running-validator/validator-start.md)
+  - [Staking Delegation and Rewards](stake-delegation-and-rewards.md)
-  * [Staking](running-validator/validator-stake.md)
+
-  * [Monitoring a Validator](running-validator/validator-monitor.md)
+- [Anatomy of a Fullnode](fullnode.md)
-  * [Publishing Validator Info](running-validator/validator-info.md)
+  - [TPU](tpu.md)
-  * [Troubleshooting](running-validator/validator-troubleshoot.md)
+  - [TVU](tvu.md)
-* [Running an Archiver](running-archiver.md)
+    - [Blocktree](blocktree.md)
-* [Understanding Solana's Architecture](cluster/README.md)
+  - [Gossip Service](gossip.md)
-  * [Synchronization](cluster/synchronization.md)
+  - [The Runtime](runtime.md)
-  * [Leader Rotation](cluster/leader-rotation.md)
+
-  * [Fork Generation](cluster/fork-generation.md)
+- [API Reference](api-reference.md)
-  * [Managing Forks](cluster/managing-forks.md)
+  - [Blockstreamer](blockstreamer.md)
-  * [Turbine Block Propagation](cluster/turbine-block-propagation.md)
+  - [JSON RPC API](jsonrpc-api.md)
-  * [Ledger Replication](cluster/ledger-replication.md)
+  - [JavaScript API](javascript-api.md)
-  * [Secure Vote Signing](cluster/vote-signing.md)
+  - [solana-wallet CLI](wallet.md)
-  * [Stake Delegation and Rewards](cluster/stake-delegation-and-rewards.md)
+
-  * [Performance Metrics](cluster/performance-metrics.md)
+- [Proposed Architectural Changes](proposals.md)
-* [Anatomy of a Validator](validator/README.md)
+  - [Ledger Replication](ledger-replication-to-implement.md)
-  * [TPU](validator/tpu.md)
+  - [Secure Vote Signing](vote-signing-to-implement.md)
-  * [TVU](validator/tvu.md)
+  - [Staking Rewards](staking-rewards.md)
-  * [Blockstore](validator/blockstore.md)
+  - [Fork Selection](fork-selection.md)
-  * [Gossip Service](validator/gossip.md)
+  - [Reliable Vote Transmission](reliable-vote-transmission.md)
-  * [The Runtime](validator/runtime.md)
+  - [Persistent Account Storage](persistent-account-storage.md)
-* [Building from Source](building-from-source.md)
+  - [Leader to Leader Transition](leader-leader-transition.md)
-* [Terminology](terminology.md)
+  - [Cluster Economics](ed_overview.md)
-* [Implemented Design Proposals](implemented-proposals/README.md)
+    - [Validation-client Economics](ed_validation_client_economics.md)
-  * [Cluster Software Installation and Updates](implemented-proposals/installer.md)
+      - [State-validation Protocol-based Rewards](ed_vce_state_validation_protocol_based_rewards.md)
-  * [Cluster Economics](implemented-proposals/ed_overview/README.md)
+      - [State-validation Transaction Fees](ed_vce_state_validation_transaction_fees.md)
-    * [Validation-client Economics](implemented-proposals/ed_overview/ed_validation_client_economics/README.md)
+      - [Replication-validation Transaction Fees](ed_vce_replication_validation_transaction_fees.md)
-      * [State-validation Protocol-based Rewards](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md)
+      - [Validation Stake Delegation](ed_vce_validation_stake_delegation.md)
-      * [State-validation Transaction Fees](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md)
+    - [Replication-client Economics](ed_replication_client_economics.md)
-      * [Replication-validation Transaction Fees](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md)
+      - [Storage-replication Rewards](ed_rce_storage_replication_rewards.md)
-      * [Validation Stake Delegation](implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_validation_stake_delegation.md)
+      - [Replication-client Reward Auto-delegation](ed_rce_replication_client_reward_auto_delegation.md)
-    * [Replication-client Economics](implemented-proposals/ed_overview/ed_replication_client_economics/README.md)
+    - [Economic Sustainability](ed_economic_sustainability.md)
-      * [Storage-replication Rewards](implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_storage_replication_rewards.md)
+    - [Attack Vectors](ed_attack_vectors.md)
-      * [Replication-client Reward Auto-delegation](implemented-proposals/ed_overview/ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md)
+    - [References](ed_references.md)
-    * [Storage Rent Economics](implemented-proposals/ed_overview/ed_storage_rent_economics.md)
+  - [Leader-to-Validator Transition](leader-validator-transition.md)
-    * [Economic Sustainability](implemented-proposals/ed_overview/ed_economic_sustainability.md)
+  - [Cluster Test Framework](cluster-test-framework.md)
-    * [Attack Vectors](implemented-proposals/ed_overview/ed_attack_vectors.md)
+  - [Testing Programs](testing-programs.md)
-    * [Economic Design MVP](implemented-proposals/ed_overview/ed_mvp.md)
-    * [References](implemented-proposals/ed_overview/ed_references.md)
-  * [Deterministic Transaction Fees](implemented-proposals/transaction-fees.md)
-  * [Tower BFT](implemented-proposals/tower-bft.md)
-  * [Leader-to-Leader Transition](implemented-proposals/leader-leader-transition.md)
-  * [Leader-to-Validator Transition](implemented-proposals/leader-validator-transition.md)
-  * [Persistent Account Storage](implemented-proposals/persistent-account-storage.md)
-  * [Reliable Vote Transmission](implemented-proposals/reliable-vote-transmission.md)
-  * [Repair Service](implemented-proposals/repair-service.md)
-  * [Testing Programs](implemented-proposals/testing-programs.md)
-  * [Credit-only Accounts](implemented-proposals/readonly-accounts.md)
-  * [Embedding the Move Langauge](implemented-proposals/embedding-move.md)
-  * [Staking Rewards](implemented-proposals/staking-rewards.md)
-  * [Rent](implemented-proposals/rent.md)
-  * [Durable Transaction Nonces](implemented-proposals/durable-tx-nonces.md)
-  * [Validator Timestamp Oracle](implemented-proposals/validator-timestamp-oracle.md)
-  * [Commitment](implemented-proposals/commitment.md)
-  * [Snapshot Verification](implemented-proposals/snapshot-verification.md)
-* [Accepted Design Proposals](proposals/README.md)
-  * [Ledger Replication](proposals/ledger-replication-to-implement.md)
-  * [Secure Vote Signing](proposals/vote-signing-to-implement.md)
-  * [Cluster Test Framework](proposals/cluster-test-framework.md)
-  * [Validator](proposals/validator-proposal.md)
-  * [Simple Payment and State Verification](proposals/simple-payment-and-state-verification.md)
-  * [Cross-Program Invocation](proposals/cross-program-invocation.md)
-  * [Inter-chain Transaction Verification](proposals/interchain-transaction-verification.md)
-  * [Snapshot Verification](proposals/snapshot-verification.md)
-  * [Bankless Leader](proposals/bankless-leader.md)
-  * [Slashing](proposals/slashing.md)
-  * [Tick Verification](proposals/tick-verification.md)
-  * [Block Confirmation](proposals/block-confirmation.md)
-  * [ABI Management](proposals/abi-management.md)

book/src/api-reference.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/apps/README.md

@@ -1,44 +0,0 @@
-# Programming Model
-
-An _app_ interacts with a Solana cluster by sending it _transactions_ with one or more _instructions_. The Solana _runtime_ passes those instructions to user-contributed _programs_. An instruction might, for example, tell a program to transfer _lamports_ from one _account_ to another or create an interactive contract that governs how lamports are transfered. Instructions are executed sequentially and atomically. If any instruction is invalid, any changes made within the transaction are discarded.
-
-### Accounts and Signatures
-
-Each transaction explicitly lists all account public keys referenced by the transaction's instructions. A subset of those public keys are each accompanied by a transaction signature. Those signatures signal on-chain programs that the account holder has authorized the transaction. Typically, the program uses the authorization to permit debiting the account or modifying its data.
-
-The transaction also marks some accounts as _read-only accounts_. The runtime permits read-only accounts to be read concurrently. If a program attempts to modify a read-only account, the transaction is rejected by the runtime.
-
-### Recent Blockhash
-
-A Transaction includes a recent blockhash to prevent duplication and to give transactions lifetimes. Any transaction that is completely identical to a previous one is rejected, so adding a newer blockhash allows multiple transactions to repeat the exact same action. Transactions also have lifetimes that are defined by the blockhash, as any transaction whose blockhash is too old will be rejected.
-
-### Instructions
-
-Each instruction specifies a single program account \(which must be marked executable\), a subset of the transaction's accounts that should be passed to the program, and a data byte array instruction that is passed to the program. The program interprets the data array and operates on the accounts specified by the instructions. The program can return successfully, or with an error code. An error return causes the entire transaction to fail immediately.
-
-## Deploying Programs to a Cluster
-
-![SDK tools](../.gitbook/assets/sdk-tools.svg)
-
-As shown in the diagram above a client creates a program and compiles it to an ELF shared object containing BPF bytecode and sends it to the Solana cluster. The cluster stores the program locally and makes it available to clients via a _program ID_. The program ID is a _public key_ generated by the client and is 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).
-
-## Storing State between Transactions
-
-If the program needs to store state between transactions, it does so using _accounts_. Accounts are similar to files in operating systems such as Linux. Like a file, an account may hold arbitrary data and that data persists beyond the lifetime of a program. Also like a file, an account includes metadata that tells the runtime who is allowed to access the data and how. Unlike a file, the account includes metadata for the lifetime of the file. That lifetime is expressed in "tokens", which is a number of fractional native tokens, called _lamports_. Accounts are held in validator memory and pay "rent" to stay there. Each validator periodically scan all accounts and collects rent. Any account that drops to zero lamports is purged.
-
-If an account is marked "executable", it will only be used by a _loader_ to run programs. For example, a BPF-compiled program is marked executable and loaded by the BPF loader. No program is allowed to modify the contents of an executable account.
-
-An account also includes "owner" metadata. The owner is a program ID. The runtime grants the program write access to the account if its ID matches the owner. If an account is not owned by a program, the program is permitted to read its data and credit the account.
-
-In the same way that a Linux user uses a path to look up a file, a Solana client uses public keys to look up accounts. To create an account, the client generates a _keypair_ and registers its public key using the `CreateAccount` instruction. The account created by `CreateAccount` is called a _system account_ and is owned by a built-in program called the System program. The System program allows clients to transfer lamports and assign account ownership.
-
-The runtime only permits the owner to debit the account or modify its data. The program then defines additional rules for whether the client can modify accounts it owns. In the case of the System program, it allows users to transfer lamports by recognizing transaction signatures. If it sees the client signed the transaction using the keypair's _private key_, it knows the client authorized the token transfer.
-
-After the runtime executes each of the transaction's instructions, it uses the account metadata to verify that none of the access rules were violated. If a program violates an access rule, the runtime discards all account changes made by all instructions and marks the transaction as failed.
-
-## Smart Contracts
-
-Programs don't always require transaction signatures, as the System program does. Instead, the program may manage _smart contracts_. A smart contract is a set of constraints that once satisfied, signal to a program that a token transfer or account update is permitted. For example, one could use the Budget program to create a smart contract that authorizes a token transfer only after some date. Once evidence that the date has past, the contract progresses, and token transfer completes.
-

book/src/apps/drones.md

@@ -1,44 +0,0 @@
-# Drones
-
-This chapter defines an off-chain service called a _drone_, which acts as custodian of a user's private key. In its simplest form, it can be used to create _airdrop_ transactions, a token transfer from the drone's account to a client's account.
-
-## Signing Service
-
-A drone is a simple signing service. It listens for requests to sign _transaction data_. Once received, the drone validates the request however it sees fit. It may, for example, only accept transaction data with a `SystemInstruction::Transfer` instruction transferring only up to a certain amount of tokens. If the drone accepts the transaction, it returns an `Ok(Signature)` where `Signature` is a signature of the transaction data using the drone's private key. If it rejects the transaction data, it returns a `DroneError` describing why.
-
-## Examples
-
-### Granting access to an on-chain game
-
-Creator of on-chain game tic-tac-toe hosts a drone that responds to airdrop requests containing an `InitGame` instruction. The drone signs the transaction data in the request and returns it, thereby authorizing its account to pay the transaction fee and as well as seeding the game's account with enough tokens to play it. The user then creates a transaction for its transaction data and the drones signature and submits it to the Solana cluster. Each time the user interacts with the game, the game pays the user enough tokens to pay the next transaction fee to advance the game. At that point, the user may choose to keep the tokens instead of advancing the game. If the creator wants to defend against that case, they could require the user to return to the drone to sign each instruction.
-
-### Worldwide airdrop of a new token
-
-Creator of a new on-chain token \(ERC-20 interface\), may wish to do a worldwide airdrop to distribute its tokens to millions of users over just a few seconds. That drone cannot spend resources interacting with the Solana cluster. Instead, the drone should only verify the client is unique and human, and then return the signature. It may also want to listen to the Solana cluster for recent entry IDs to support client retries and to ensure the airdrop is targeting the desired cluster.
-
-Note: the Solana cluster will not parallelize transactions funded by the same fee-paying account. This means that the max throughput of a single fee-paying account is limited to the number of _ticks_ processed per second by the current leader. Add additional fee-paying accounts to improve throughput.
-
-## Attack vectors
-
-### Invalid recent\_blockhash
-
-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 reference a recent one.
-
-Note: to listen for new entry IDs assumes the drone is either a validator or a _light_ client. At the time of this writing, light clients have not been implemented and no proposal describes them. This document assumes one of the following approaches be taken:
-
-1. Define and implement a light client
-2. Embed a validator
-3. Query the jsonrpc API for the latest last id at a rate slightly faster than
-
-   ticks are produced.
-
-### Double spends
-
-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 `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
-
-If the transaction data size is smaller than the size of the returned signature \(or descriptive error\), a single client can flood the network. Considering that a simple `Transfer` operation requires two public keys \(each 32 bytes\) and a `fee` field, and that the returned signature is 64 bytes \(and a byte to indicate `Ok`\), consideration for this attack may not be required.
-
-In the current design, the drone accepts TCP connections. This allows clients to DoS the service by simply opening lots of idle connections. Switching to UDP may be preferred. The transaction data will be smaller than a UDP packet since the transaction sent to the Solana cluster is already pinned to using UDP.
-

book/src/apps/tictactoe.md

@@ -1,22 +0,0 @@
-# Example: Tic-Tac-Toe
-
-[Click here to play Tic-Tac-Toe](https://solana-example-tictactoe.herokuapp.com/) on the Solana testnet. Open the link and wait for another player to join, or open the link in a second browser tab to play against yourself. You will see that every move a player makes stores a transaction on the ledger.
-
-## Build and run Tic-Tac-Toe locally
-
-First fetch the latest release of the example code:
-
-```bash
-$ git clone https://github.com/solana-labs/example-tictactoe.git
-$ cd example-tictactoe
-$ TAG=$(git describe --tags $(git rev-list --tags
---max-count=1))
-$ git checkout $TAG
-```
-
-Next, follow the steps in the git repository's [README](https://github.com/solana-labs/example-tictactoe/blob/master/README.md).
-
-## Getting lamports to users
-
-You may have noticed you interacted with the Solana cluster without first 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 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 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 lamports.
-

book/src/block-confirmation.md

@@ -4,7 +4,7 @@ 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 [Tower BFT](tower-bft.md).
+described in [fork selection](fork-selection.md).
 
 ## Current Design
 
@@ -17,7 +17,7 @@ height of the block it is voting on. The account stores the 32 highest heights.
 * 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 validator code. The validator code queries the bank for all
+  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
@@ -50,11 +50,12 @@ log the time since the NewBlock transaction was submitted.
 
 ### Finality and Payouts
 
-[Tower BFT](tower-bft.md) is the proposed fork selection algorithm.  It proposes
+Locktower is the proposed [fork selection](fork-selection.md) algorithm. It
-that payment to miners be postponed until the *stack* of validator votes reaches
+proposes that payment to miners be postponed until the *stack* of validator
-a certain depth, at which point rollback is not economically feasible. The vote
+votes reaches a certain depth, at which point rollback is not economically
-program may therefore implement Tower BFT. Vote instructions would need to
+feasible. The vote program may therefore implement locktower. Vote instructions
-reference a global Tower account so that it can track cross-block state.
+would need to reference a global locktower account so that it can track
+cross-block state.
 
 ## Challenges
 

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/building-from-source.md

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

book/src/cli/.usage.md.header

@@ -1,177 +0,0 @@
-# solana CLI
-
-The [solana-cli crate](https://crates.io/crates/solana-cli) provides a command-line interface tool for Solana
-
-## Examples
-
-### Get Pubkey
-
-```bash
-// Command
-$ solana address
-
-// Return
-<PUBKEY>
-```
-
-### Airdrop SOL/Lamports
-
-```bash
-// Command
-$ solana airdrop 2
-
-// Return
-"2.00000000 SOL"
-
-// Command
-$ solana airdrop 123 --lamports
-
-// Return
-"123 lamports"
-```
-
-### Get Balance
-
-```bash
-// Command
-$ solana balance
-
-// Return
-"3.00050001 SOL"
-```
-
-### Confirm Transaction
-
-```bash
-// Command
-$ solana confirm <TX_SIGNATURE>
-
-// Return
-"Confirmed" / "Not found" / "Transaction failed with error <ERR>"
-```
-
-### Deploy program
-
-```bash
-// Command
-$ solana deploy <PATH>
-
-// Return
-<PROGRAM_ID>
-```
-
-### Unconditional Immediate Transfer
-
-```bash
-// Command
-$ solana pay <PUBKEY> 123
-
-// Return
-<TX_SIGNATURE>
-```
-
-### Post-Dated Transfer
-
-```bash
-// Command
-$ solana pay <PUBKEY> 123 \
-    --after 2018-12-24T23:59:00 --require-timestamp-from <PUBKEY>
-
-// Return
-{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
-```
-
-_`require-timestamp-from` is optional. If not provided, the transaction will expect a timestamp signed by this wallet's private key_
-
-### Authorized Transfer
-
-A third party must send a signature to unlock the lamports.
-
-```bash
-// Command
-$ solana pay <PUBKEY> 123 \
-    --require-signature-from <PUBKEY>
-
-// Return
-{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
-```
-
-### Post-Dated and Authorized Transfer
-
-```bash
-// Command
-$ solana pay <PUBKEY> 123 \
-    --after 2018-12-24T23:59 --require-timestamp-from <PUBKEY> \
-    --require-signature-from <PUBKEY>
-
-// Return
-{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
-```
-
-### Multiple Witnesses
-
-```bash
-// Command
-$ solana pay <PUBKEY> 123 \
-    --require-signature-from <PUBKEY> \
-    --require-signature-from <PUBKEY>
-
-// Return
-{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
-```
-
-### Cancelable Transfer
-
-```bash
-// Command
-$ solana pay <PUBKEY> 123 \
-    --require-signature-from <PUBKEY> \
-    --cancelable
-
-// Return
-{signature: <TX_SIGNATURE>, processId: <PROCESS_ID>}
-```
-
-### Cancel Transfer
-
-```bash
-// Command
-$ solana cancel <PROCESS_ID>
-
-// Return
-<TX_SIGNATURE>
-```
-
-### Send Signature
-
-```bash
-// Command
-$ solana send-signature <PUBKEY> <PROCESS_ID>
-
-// Return
-<TX_SIGNATURE>
-```
-
-### Indicate Elapsed Time
-
-Use the current system time:
-
-```bash
-// Command
-$ solana send-timestamp <PUBKEY> <PROCESS_ID>
-
-// Return
-<TX_SIGNATURE>
-```
-
-Or specify some other arbitrary timestamp:
-
-```bash
-// Command
-$ solana send-timestamp <PUBKEY> <PROCESS_ID> --date 2018-12-24T23:59:00
-
-// Return
-<TX_SIGNATURE>
-```
-
-## Usage

book/src/cli/README.md

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

book/src/cluster-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;
+
+// Discover the cluster over a few seconds.
+let cluster_nodes = discover(&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(&entry_point_info, num_nodes);
+
+    // Poison the cluster.
+    let mut 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 mut 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

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

book/src/cluster/README.md

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

book/src/cluster/fork-generation.md

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

book/src/cluster/leader-rotation.md

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

book/src/cluster/ledger-replication.md

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

book/src/cluster/managing-forks.md

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

book/src/cluster/performance-metrics.md

@@ -1,24 +0,0 @@
-# Performance Metrics
-
-Solana cluster performance is measured as average number of transactions per second that the network can sustain \(TPS\). And, how long it takes for a transaction to be confirmed by super majority of the cluster \(Confirmation Time\).
-
-Each cluster node maintains various counters that are incremented on certain events. These counters are periodically uploaded to a cloud based database. Solana's metrics dashboard fetches these counters, and computes the performance metrics and displays it on the dashboard.
-
-## TPS
-
-Each node's bank runtime maintains a count of transactions that it has processed. The dashboard first calculates the median count of transactions across all metrics enabled nodes in the cluster. The median cluster transaction count is then averaged over a 2 second period and displayed in the TPS time series graph. The dashboard also shows the Mean TPS, Max TPS and Total Transaction Count stats which are all calculated from the median transaction count.
-
-## Confirmation Time
-
-Each validator node maintains a list of active ledger forks that are visible to the node. A fork is considered to be frozen when the node has received and processed all entries corresponding to the fork. A fork is considered to be confirmed when it receives cumulative super majority vote, and when one of its children forks is frozen.
-
-The node assigns a timestamp to every new fork, and computes the time it took to confirm the fork. This time is reflected as validator confirmation time in performance metrics. The performance dashboard displays the average of each validator node's confirmation time as a time series graph.
-
-## Hardware setup
-
-The validator software is deployed to GCP n1-standard-16 instances with 1TB pd-ssd disk, and 2x Nvidia V100 GPUs. These are deployed in the us-west-1 region.
-
-solana-bench-tps is started after the network converges from a client machine with n1-standard-16 CPU-only instance with the following arguments: `--tx\_count=50000 --thread-batch-sleep 1000`
-
-TPS and confirmation metrics are captured from the dashboard numbers over a 5 minute average of when the bench-tps transfer stage begins.
-

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

@@ -1,211 +0,0 @@
-# Stake Delegation and Rewards
-
-Stakers are rewarded for helping to validate the ledger. They do this by delegating their stake to validator nodes. Those validators do the legwork of replaying the ledger and send votes to a per-node vote account to which stakers can delegate their stakes. The rest of the cluster uses those stake-weighted votes to select a block when forks arise. Both the validator and staker need some economic incentive to play their part. The validator needs to be compensated for its hardware and the staker needs to be compensated for the risk of getting its stake slashed. The economics are covered in [staking rewards](../implemented-proposals/staking-rewards.md). This chapter, on the other hand, describes the underlying mechanics of its implementation.
-
-## Basic Design
-
-The general idea is that the validator owns a Vote account. The Vote account tracks validator votes, counts validator generated credits, and provides any additional validator specific state. The Vote account is not aware of any stakes delegated to it and has no staking weight.
-
-A separate Stake account \(created by a staker\) names a Vote account to which the stake is delegated. Rewards generated are proportional to the amount of lamports staked. The Stake account is owned by the staker only. Some portion of the lamports stored in this account are the stake.
-
-## Passive Delegation
-
-Any number of Stake accounts can delegate to a single Vote account without an interactive action from the identity controlling the Vote account or submitting votes to the account.
-
-The total stake allocated to a Vote account can be calculated by the sum of all the Stake accounts that have the Vote account pubkey as the `StakeState::Stake::voter_pubkey`.
-
-## Vote and Stake accounts
-
-The rewards process is split into two on-chain programs. The Vote program solves the problem of making stakes slashable. The Stake program acts as custodian of the rewards pool and provides for passive delegation. The Stake program is responsible for paying rewards to staker and voter when shown that a staker's delegate has participated in validating the ledger.
-
-### VoteState
-
-VoteState is the current state of all the votes the validator has submitted to the network. VoteState contains the following state information:
-
-* `votes` - The submitted votes data structure.
-* `credits` - The total number of rewards this vote program has generated over its lifetime.
-* `root_slot` - The last slot to reach the full lockout commitment necessary for rewards.
-* `commission` - The commission taken by this VoteState for any rewards claimed by staker's Stake accounts. This is the percentage ceiling of the reward.
-* Account::lamports - The accumulated lamports from the commission. These do not count as stakes.
-* `authorized_voter` - Only this identity is authorized to submit votes. This field can only modified by this identity.
-* `node_pubkey` - The Solana node that votes in this account.
-* `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's
-
-  ```text
-                       address and the authorized vote signer
-  ```
-
-### VoteInstruction::Initialize\(VoteInit\)
-
-* `account[0]` - RW - The VoteState
-
-  `VoteInit` carries the new vote account's `node_pubkey`, `authorized_voter`, `authorized_withdrawer`, and `commission`
-
-  other VoteState members defaulted
-
-### VoteInstruction::Authorize\(Pubkey, VoteAuthorize\)
-
-Updates the account with a new authorized voter or withdrawer, according to the VoteAuthorize parameter \(`Voter` or `Withdrawer`\). The transaction must be by signed by the Vote account's current `authorized_voter` or `authorized_withdrawer`.
-
-* `account[0]` - RW - The VoteState
-
-  `VoteState::authorized_voter` or `authorized_withdrawer` is set to to `Pubkey`.
-
-### VoteInstruction::Vote\(Vote\)
-
-* `account[0]` - RW - The VoteState
-
-  `VoteState::lockouts` and `VoteState::credits` are updated according to voting lockout rules see [Tower BFT](../implemented-proposals/tower-bft.md)
-
-* `account[1]` - RO - `sysvar::slot_hashes` A list of some N most recent slots and their hashes for the vote to be verified against.
-* `account[2]` - RO - `sysvar::clock` The current network time, expressed in slots, epochs.
-
-### StakeState
-
-A StakeState takes one of four forms, StakeState::Uninitialized, StakeState::Initialized, StakeState::Stake, and StakeState::RewardsPool. Only the first three forms are used in staking, but only StakeState::Stake is interesting. All RewardsPools are created at genesis.
-
-### StakeState::Stake
-
-StakeState::Stake is the current delegation preference of the **staker** and contains the following state information:
-
-* Account::lamports - The lamports available for staking.
-* `stake` - the staked amount \(subject to warm up and cool down\) for generating rewards, always less than or equal to Account::lamports
-* `voter_pubkey` - The pubkey of the VoteState instance the lamports are delegated to.
-* `credits_observed` - The total credits claimed over the lifetime of the program.
-* `activated` - the epoch at which this stake was activated/delegated. The full stake will be counted after warm up.
-* `deactivated` - the epoch at which this stake was de-activated, some cool down epochs are required before the account
-
-  ```text
-              is fully deactivated, and the stake available for withdrawal
-  ```
-
-* `authorized_staker` - the pubkey of the entity that must sign delegation, activation, and deactivation transactions
-* `authorized_withdrawer` - the identity of the entity in charge of the lamports of this account, separate from the account's
-
-  ```text
-                       address, and the authorized staker
-  ```
-
-### StakeState::RewardsPool
-
-To avoid a single network wide lock or contention in redemption, 256 RewardsPools are part of genesis under pre-determined keys, each with std::u64::MAX credits to be able to satisfy redemptions according to point value.
-
-The Stakes and the RewardsPool are accounts that are owned by the same `Stake` program.
-
-### StakeInstruction::DelegateStake
-
-The Stake account is moved from Initialized to StakeState::Stake form, or from a deactivated (i.e. fully cooled-down) StakeState::Stake to activated StakeState::Stake. This is how stakers choose the vote account and validator node to which their stake account lamports are delegated. The transaction must be signed by the stake's `authorized_staker`.
-
-* `account[0]` - RW - The StakeState::Stake instance.  `StakeState::Stake::credits_observed` is initialized to `VoteState::credits`,  `StakeState::Stake::voter_pubkey` is initialized to `account[1]`.  If this is the initial delegation of stake, `StakeState::Stake::stake` is initialized to the account's balance in lamports,  `StakeState::Stake::activated` is initialized to the current Bank epoch, and  `StakeState::Stake::deactivated` is initialized to std::u64::MAX
-* `account[1]` - R - The VoteState instance.
-* `account[2]` - R - sysvar::clock account, carries information about current Bank epoch
-* `account[3]` - R - sysvar::stakehistory account, carries information about stake history
-* `account[4]` - R - stake::Config accoount, carries warmup, cooldown, and slashing configuration
-
-### StakeInstruction::Authorize\(Pubkey, StakeAuthorize\)
-
-Updates the account with a new authorized staker or withdrawer, according to the StakeAuthorize parameter \(`Staker` or `Withdrawer`\). The transaction must be by signed by the Stakee account's current `authorized_staker` or `authorized_withdrawer`.  Any stake lock-up must have expired, or the lock-up custodian must also sign the transaction.
-
-* `account[0]` - RW - The StakeState
-
-  `StakeState::authorized_staker` or `authorized_withdrawer` is set to to `Pubkey`.
-
-### StakeInstruction::Deactivate
-
-A staker may wish to withdraw from the network. To do so he must first deactivate his stake, and wait for cool down.
-The transaction must be signed by the stake's `authorized_staker`.
-
-* `account[0]` - RW - The StakeState::Stake instance that is deactivating.
-* `account[1]` - R - sysvar::clock account from the Bank that carries current epoch
-
-StakeState::Stake::deactivated is set to the current epoch + cool down. The account's stake will ramp down to zero by that epoch, and Account::lamports will be available for withdrawal.
-
-### StakeInstruction::Withdraw\(u64\)
-
-Lamports build up over time in a Stake account and any excess over activated stake can be withdrawn. The transaction must be signed by the stake's `authorized_withdrawer`.
-
-* `account[0]` - RW - The StakeState::Stake from which to withdraw.
-* `account[1]` - RW - Account that should be credited with the withdrawn lamports.
-* `account[2]` - R - sysvar::clock account from the Bank that carries current epoch, to calculate stake.
-* `account[3]` - R - sysvar::stake\_history account from the Bank that carries stake warmup/cooldown history
-
-## Benefits of the design
-
-* Single vote for all the stakers.
-* Clearing of the credit variable is not necessary for claiming rewards.
-* Each delegated stake can claim its rewards independently.
-* Commission for the work is deposited when a reward is claimed by the delegated stake.
-
-## Example Callflow
-
-![Passive Staking Callflow](../.gitbook/assets/passive-staking-callflow.svg)
-
-## Staking Rewards
-
-The specific mechanics and rules of the validator rewards regime is outlined here. Rewards are earned by delegating stake to a validator that is voting correctly. Voting incorrectly exposes that validator's stakes to [slashing](../proposals/slashing.md).
-
-### Basics
-
-The network pays rewards from a portion of network [inflation](../terminology.md#inflation). The number of lamports available to pay rewards for an epoch is fixed and must be evenly divided among all staked nodes according to their relative stake weight and participation. The weighting unit is called a [point](../terminology.md#point).
-
-Rewards for an epoch are not available until the end of that epoch.
-
-At the end of each epoch, the total number of points earned during the epoch is summed and used to divide the rewards portion of epoch inflation to arrive at a point value. This value is recorded in the bank in a [sysvar](../terminology.md#sysvar) that maps epochs to point values.
-
-During redemption, the stake program counts the points earned by the stake for each epoch, multiplies that by the epoch's point value, and transfers lamports in that amount from a rewards account into the stake and vote accounts according to the vote account's commission setting.
-
-### Economics
-
-Point value for an epoch depends on aggregate network participation. If participation in an epoch drops off, point values are higher for those that do participate.
-
-### Earning credits
-
-Validators earn one vote credit for every correct vote that exceeds maximum lockout, i.e. every time the validator's vote account retires a slot from its lockout list, making that vote a root for the node.
-
-Stakers who have delegated to that validator earn points in proportion to their stake. Points earned is the product of vote credits and stake.
-
-### Stake warmup, cooldown, withdrawal
-
-Stakes, once delegated, do not become effective immediately. They must first pass through a warm up period. During this period some portion of the stake is considered "effective", the rest is considered "activating". Changes occur on epoch boundaries.
-
-The stake program limits the rate of change to total network stake, reflected in the stake program's `config::warmup_rate` \(typically 25% per epoch\).
-
-The amount of stake that can be warmed up each epoch is a function of the previous epoch's total effective stake, total activating stake, and the stake program's configured warmup rate.
-
-Cooldown works the same way. Once a stake is deactivated, some part of it is considered "effective", and also "deactivating". As the stake cools down, it continues to earn rewards and be exposed to slashing, but it also becomes available for withdrawal.
-
-Bootstrap stakes are not subject to warmup.
-
-Rewards are paid against the "effective" portion of the stake for that epoch.
-
-#### Warmup example
-
-Consider the situation of a single stake of 1,000 activated at epoch N, with network warmup rate of 20%, and a quiescent total network stake at epoch N of 2,000.
-
-At epoch N+1, the amount available to be activated for the network is 400 \(20% of 200\), and at epoch N, this example stake is the only stake activating, and so is entitled to all of the warmup room available.
-
-| epoch | effective | activating | total effective | total activating |
-| :--- | ---: | ---: | ---: | ---: |
-| N-1 |  |  | 2,000 | 0 |
-| N | 0 | 1,000 | 2,000 | 1,000 |
-| N+1 | 400 | 600 | 2,400 | 600 |
-| N+2 | 880 | 120 | 2,880 | 120 |
-| N+3 | 1000 | 0 | 3,000 | 0 |
-
-Were 2 stakes \(X and Y\) to activate at epoch N, they would be awarded a portion of the 20% in proportion to their stakes. At each epoch effective and activating for each stake is a function of the previous epoch's state.
-
-| epoch | X eff | X act | Y eff | Y act | total effective | total activating |
-| :--- | ---: | ---: | ---: | ---: | ---: | ---: |
-| N-1 |  |  |  |  | 2,000 | 0 |
-| N | 0 | 1,000 | 0 | 200 | 2,000 | 1,200 |
-| N+1 | 333 | 667 | 67 | 133 | 2,400 | 800 |
-| N+2 | 733 | 267 | 146 | 54 | 2,880 | 321 |
-| N+3 | 1000 | 0 | 200 | 0 | 3,200 | 0 |
-
-### Withdrawal
-
-Only lamports in excess of effective+activating stake may be withdrawn at any time. This means that during warmup, effectively no stake can be withdrawn. During cooldown, any tokens in excess of effective stake may be withdrawn \(activating == 0\). Because earned rewards are automatically added to stake, withdrawal is generally only possible after deactivation.
-
-### Lock-up
-
-Stake accounts support the notion of lock-up, wherein the stake account balance is unavailable for withdrawal until a specified time. Lock-up is specified as an epoch height, i.e. the minimum epoch height that must be reached by the network before the stake account balance is available for withdrawal, unless the transaction is also signed by a specified custodian. This information is gathered when the stake account is created, and stored in the Lockup field of the stake account's state.  Changing the authorized staker or withdrawer is also subject to lock-up, as such an operation is effectively a transfer.

book/src/cluster/synchronization.md

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

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

@@ -1,96 +0,0 @@
-# Turbine Block Propagation
-
-A Solana cluster uses a multi-layer block propagation mechanism called _Turbine_ to broadcast transaction shreds to all nodes with minimal amount of duplicate messages. The cluster divides itself into small collections of nodes, called _neighborhoods_. Each node is responsible for sharing any data it receives with the other nodes in its neighborhood, as well as propagating the data on to a small set of nodes in other neighborhoods. This way each node only has to communicate with a small number of nodes.
-
-During its slot, the leader node distributes shreds between the validator nodes in the first neighborhood \(layer 0\). Each validator shares its data within its neighborhood, but also retransmits the shreds to one node in some neighborhoods in the next layer \(layer 1\). The layer-1 nodes each share their data with their neighborhood peers, and retransmit to nodes in the next layer, etc, until all nodes in the cluster have received all the shreds.
-
-## Neighborhood Assignment - Weighted Selection
-
-In order for data plane fanout to work, the entire cluster must agree on how the cluster is divided into neighborhoods. To achieve this, all the recognized validator nodes \(the TVU peers\) are sorted by stake and stored in a list. This list is then indexed in different ways to figure out neighborhood boundaries and retransmit peers. For example, the leader will simply select the first nodes to make up layer 0. These will automatically be the highest stake holders, allowing the heaviest votes to come back to the leader first. Layer-0 and lower-layer nodes use the same logic to find their neighbors and next layer peers.
-
-To reduce the possibility of attack vectors, each shred is transmitted over a random tree of neighborhoods. Each node uses the same set of nodes representing the cluster. A random tree is generated from the set for each shred using randomness derived from the shred itself. Since the random seed is not known in advance, attacks that try to eclipse neighborhoods from certain leaders or blocks become very difficult, and should require almost complete control of the stake in the cluster.
-
-## Layer and Neighborhood Structure
-
-The current leader makes its initial broadcasts to at most `DATA_PLANE_FANOUT` nodes. If this layer 0 is smaller than the number of nodes in the cluster, then the data plane fanout mechanism adds layers below. Subsequent layers follow these constraints to determine layer-capacity: Each neighborhood contains `DATA_PLANE_FANOUT` nodes. Layer-0 starts with 1 neighborhood with fanout nodes. The number of nodes in each additional layer grows by a factor of fanout.
-
-As mentioned above, each node in a layer only has to broadcast its shreds to its neighbors and to exactly 1 node in some next-layer neighborhoods, instead of to every TVU peer in the cluster. A good way to think about this is, layer-0 starts with 1 neighborhood with fanout nodes, layer-1 adds "fanout" neighborhoods, each with fanout nodes and layer-2 will have `fanout * number of nodes in layer-1` and so on.
-
-This way each node only has to communicate with a maximum of `2 * DATA_PLANE_FANOUT - 1` nodes.
-
-The following diagram shows how the Leader sends shreds with a Fanout of 2 to Neighborhood 0 in Layer 0 and how the nodes in Neighborhood 0 share their data with each other.
-
-![Leader sends shreds to Neighborhood 0 in Layer 0](../.gitbook/assets/data-plane-seeding.svg)
-
-The following diagram shows how Neighborhood 0 fans out to Neighborhoods 1 and 2.
-
-![Neighborhood 0 Fanout to Neighborhood 1 and 2](../.gitbook/assets/data-plane-fanout.svg)
-
-Finally, the following diagram shows a two layer cluster with a Fanout of 2.
-
-![Two layer cluster with a Fanout of 2](../.gitbook/assets/data-plane.svg)
-
-### Configuration Values
-
-`DATA_PLANE_FANOUT` - Determines the size of layer 0. Subsequent layers grow by a factor of `DATA_PLANE_FANOUT`. The number of nodes in a neighborhood is equal to the fanout value. Neighborhoods will fill to capacity before new ones are added, i.e if a neighborhood isn't full, it _must_ be the last one.
-
-Currently, configuration is set when the cluster is launched. In the future, these parameters may be hosted on-chain, allowing modification on the fly as the cluster sizes change.
-
-## Calcuating the required FEC rate
-
-Turbine relies on retransmission of packets between validators.  Due to
-retransmission, any network wide packet loss is compounded, and the
-probability of the packet failing to reach is destination increases
-on each hop.  The FEC rate needs to take into account the network wide
-packet loss, and the propagation depth.
-
-A shred group is the set of data and coding packets that can be used
-to reconstruct each other.  Each shred group has a chance of failure,
-based on the likelyhood of the number of packets failing that exceeds
-the FEC rate. If a validator fails to reconstruct the shred group,
-then the block cannot be reconstructed, and the validator has to rely
-on repair to fixup the blocks.
-
-The probability of the shred group failing can be computed using the
-binomial distribution.  If the FEC rate is `16:4`, then the group size
-is 20, and at least 4 of the shreds must fail for the group to fail.
-Which is equal to the sum of the probability of 4 or more trails failing
-out of 20.
-
-Probability of a block succeeding in turbine:
-
-* Probability of packet failure: `P = 1 - (1 - network_packet_loss_rate)^2`
-* FEC rate: `K:M`
-* Number of trials: `N = K + M`
-* Shred group failure rate: `S = SUM of i=0 -> M for binomial(prob_failure = P,  trials = N, failures = i)`
-* Shreds per block: `G`
-* Block success rate: `B = (1 - S) ^ (G / N) `
-* Binomial distribution for exactly `i` results with probability of P in N trials is defined as `(N choose i) * P^i * (1 - P)^(N-i)`
-
-For example:
-
-* Network packet loss rate is 15%.
-* 50kpts network generates 6400 shreds per second.
-* FEC rate increases the total shres per block by the FEC ratio.
-
-With a FEC rate: `16:4`
-* `G = 8000`
-* `P = 1 - 0.85 * 0.85 = 1 - 0.7225 = 0.2775`
-* `S = SUM of i=0 -> 4 for binomial(prob_failure = 0.2775,  trials = 20, failures = i) = 0.689414`
-* `B = (1 - 0.689) ^ (8000 / 20) = 10^-203`
-
-With FEC rate of `16:16`
-* `G = 12800`
-* `S = SUM of i=0 -> 32 for binomial(prob_failure = 0.2775,  trials = 64, failures = i) = 0.002132`
-* `B = (1 - 0.002132) ^ (12800 / 32) = 0.42583`
-
-With FEC rate of `32:32`
-* `G = 12800`
-* `S = SUM of i=0 -> 32 for binomial(prob_failure = 0.2775,  trials = 64, failures = i) = 0.000048`
-* `B = (1 - 0.000048) ^ (12800 / 64) = 0.99045`
-
-## Neighborhoods
-
-The following diagram shows how two neighborhoods in different layers interact. To cripple a neighborhood, enough nodes \(erasure codes +1\) from the neighborhood above need to fail. Since each neighborhood receives shreds from multiple nodes in a neighborhood in the upper layer, we'd need a big network failure in the upper layers to end up with incomplete data.
-
-![Inner workings of a neighborhood](../.gitbook/assets/data-plane-neighborhood.svg)

book/src/cluster/vote-signing.md

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

book/src/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"/>