diff --git a/book/src/.gitbook/assets/data-plane (1).svg b/book/src/.gitbook/assets/data-plane (1).svg
new file mode 100644
index 0000000000..5a33b8bf6e
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane (1).svg
@@ -0,0 +1,192 @@
+
diff --git a/book/src/.gitbook/assets/data-plane (2).svg b/book/src/.gitbook/assets/data-plane (2).svg
new file mode 100644
index 0000000000..5a33b8bf6e
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane (2).svg
@@ -0,0 +1,192 @@
+
diff --git a/book/src/.gitbook/assets/data-plane (3).svg b/book/src/.gitbook/assets/data-plane (3).svg
new file mode 100644
index 0000000000..5a33b8bf6e
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane (3).svg
@@ -0,0 +1,192 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-fanout (1).svg b/book/src/.gitbook/assets/data-plane-fanout (1).svg
new file mode 100644
index 0000000000..ad73f77ef0
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-fanout (1).svg
@@ -0,0 +1,183 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-fanout (2).svg b/book/src/.gitbook/assets/data-plane-fanout (2).svg
new file mode 100644
index 0000000000..ad73f77ef0
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-fanout (2).svg
@@ -0,0 +1,183 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-fanout (3).svg b/book/src/.gitbook/assets/data-plane-fanout (3).svg
new file mode 100644
index 0000000000..ad73f77ef0
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-fanout (3).svg
@@ -0,0 +1,183 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-neighborhood (1).svg b/book/src/.gitbook/assets/data-plane-neighborhood (1).svg
new file mode 100644
index 0000000000..1a7f080a31
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-neighborhood (1).svg
@@ -0,0 +1,322 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-neighborhood (2).svg b/book/src/.gitbook/assets/data-plane-neighborhood (2).svg
new file mode 100644
index 0000000000..1a7f080a31
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-neighborhood (2).svg
@@ -0,0 +1,322 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-neighborhood (3).svg b/book/src/.gitbook/assets/data-plane-neighborhood (3).svg
new file mode 100644
index 0000000000..1a7f080a31
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-neighborhood (3).svg
@@ -0,0 +1,322 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-seeding (1).svg b/book/src/.gitbook/assets/data-plane-seeding (1).svg
new file mode 100644
index 0000000000..765b53c93f
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-seeding (1).svg
@@ -0,0 +1,138 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-seeding (2).svg b/book/src/.gitbook/assets/data-plane-seeding (2).svg
new file mode 100644
index 0000000000..765b53c93f
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-seeding (2).svg
@@ -0,0 +1,138 @@
+
diff --git a/book/src/.gitbook/assets/data-plane-seeding (3).svg b/book/src/.gitbook/assets/data-plane-seeding (3).svg
new file mode 100644
index 0000000000..765b53c93f
--- /dev/null
+++ b/book/src/.gitbook/assets/data-plane-seeding (3).svg
@@ -0,0 +1,138 @@
+
diff --git a/book/src/.gitbook/assets/fork-generation (1).svg b/book/src/.gitbook/assets/fork-generation (1).svg
new file mode 100644
index 0000000000..3d13d7549b
--- /dev/null
+++ b/book/src/.gitbook/assets/fork-generation (1).svg
@@ -0,0 +1,330 @@
+
diff --git a/book/src/.gitbook/assets/fork-generation (2).svg b/book/src/.gitbook/assets/fork-generation (2).svg
new file mode 100644
index 0000000000..3d13d7549b
--- /dev/null
+++ b/book/src/.gitbook/assets/fork-generation (2).svg
@@ -0,0 +1,330 @@
+
diff --git a/book/src/.gitbook/assets/fork-generation (3).svg b/book/src/.gitbook/assets/fork-generation (3).svg
new file mode 100644
index 0000000000..3d13d7549b
--- /dev/null
+++ b/book/src/.gitbook/assets/fork-generation (3).svg
@@ -0,0 +1,330 @@
+
diff --git a/book/src/.gitbook/assets/forks (1).svg b/book/src/.gitbook/assets/forks (1).svg
new file mode 100644
index 0000000000..725a73f5d3
--- /dev/null
+++ b/book/src/.gitbook/assets/forks (1).svg
@@ -0,0 +1,122 @@
+
diff --git a/book/src/.gitbook/assets/forks (2).svg b/book/src/.gitbook/assets/forks (2).svg
new file mode 100644
index 0000000000..725a73f5d3
--- /dev/null
+++ b/book/src/.gitbook/assets/forks (2).svg
@@ -0,0 +1,122 @@
+
diff --git a/book/src/.gitbook/assets/forks (3).svg b/book/src/.gitbook/assets/forks (3).svg
new file mode 100644
index 0000000000..725a73f5d3
--- /dev/null
+++ b/book/src/.gitbook/assets/forks (3).svg
@@ -0,0 +1,122 @@
+
diff --git a/book/src/.gitbook/assets/forks-pruned (1).svg b/book/src/.gitbook/assets/forks-pruned (1).svg
new file mode 100644
index 0000000000..5a8f41f21c
--- /dev/null
+++ b/book/src/.gitbook/assets/forks-pruned (1).svg
@@ -0,0 +1,92 @@
+
diff --git a/book/src/.gitbook/assets/forks-pruned (2).svg b/book/src/.gitbook/assets/forks-pruned (2).svg
new file mode 100644
index 0000000000..5a8f41f21c
--- /dev/null
+++ b/book/src/.gitbook/assets/forks-pruned (2).svg
@@ -0,0 +1,92 @@
+
diff --git a/book/src/.gitbook/assets/forks-pruned (3).svg b/book/src/.gitbook/assets/forks-pruned (3).svg
new file mode 100644
index 0000000000..5a8f41f21c
--- /dev/null
+++ b/book/src/.gitbook/assets/forks-pruned (3).svg
@@ -0,0 +1,92 @@
+
diff --git a/book/src/.gitbook/assets/forks-pruned2 (1).svg b/book/src/.gitbook/assets/forks-pruned2 (1).svg
new file mode 100644
index 0000000000..f57f691d73
--- /dev/null
+++ b/book/src/.gitbook/assets/forks-pruned2 (1).svg
@@ -0,0 +1,92 @@
+
diff --git a/book/src/.gitbook/assets/forks-pruned2 (2).svg b/book/src/.gitbook/assets/forks-pruned2 (2).svg
new file mode 100644
index 0000000000..f57f691d73
--- /dev/null
+++ b/book/src/.gitbook/assets/forks-pruned2 (2).svg
@@ -0,0 +1,92 @@
+
diff --git a/book/src/.gitbook/assets/forks-pruned2 (3).svg b/book/src/.gitbook/assets/forks-pruned2 (3).svg
new file mode 100644
index 0000000000..f57f691d73
--- /dev/null
+++ b/book/src/.gitbook/assets/forks-pruned2 (3).svg
@@ -0,0 +1,92 @@
+
diff --git a/book/src/.gitbook/assets/p_ex_schedule (5).png b/book/src/.gitbook/assets/p_ex_schedule (5).png
new file mode 100644
index 0000000000..beb4c0cc5c
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_schedule (5).png differ
diff --git a/book/src/.gitbook/assets/p_ex_schedule (6).png b/book/src/.gitbook/assets/p_ex_schedule (6).png
new file mode 100644
index 0000000000..beb4c0cc5c
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_schedule (6).png differ
diff --git a/book/src/.gitbook/assets/p_ex_schedule (7).png b/book/src/.gitbook/assets/p_ex_schedule (7).png
new file mode 100644
index 0000000000..beb4c0cc5c
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_schedule (7).png differ
diff --git a/book/src/.gitbook/assets/p_ex_schedule-3 (1).png b/book/src/.gitbook/assets/p_ex_schedule-3 (1).png
new file mode 100644
index 0000000000..beb4c0cc5c
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_schedule-3 (1).png differ
diff --git a/book/src/.gitbook/assets/p_ex_schedule-3.png b/book/src/.gitbook/assets/p_ex_schedule-3.png
new file mode 100644
index 0000000000..beb4c0cc5c
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_schedule-3.png differ
diff --git a/book/src/.gitbook/assets/p_ex_supply (5).png b/book/src/.gitbook/assets/p_ex_supply (5).png
new file mode 100644
index 0000000000..3779849368
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_supply (5).png differ
diff --git a/book/src/.gitbook/assets/p_ex_supply (6).png b/book/src/.gitbook/assets/p_ex_supply (6).png
new file mode 100644
index 0000000000..3779849368
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_supply (6).png differ
diff --git a/book/src/.gitbook/assets/p_ex_supply-1 (1).png b/book/src/.gitbook/assets/p_ex_supply-1 (1).png
new file mode 100644
index 0000000000..3779849368
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_supply-1 (1).png differ
diff --git a/book/src/.gitbook/assets/p_ex_supply-1.png b/book/src/.gitbook/assets/p_ex_supply-1.png
new file mode 100644
index 0000000000..3779849368
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_supply-1.png differ
diff --git a/book/src/.gitbook/assets/p_ex_supply-3.png b/book/src/.gitbook/assets/p_ex_supply-3.png
new file mode 100644
index 0000000000..3779849368
Binary files /dev/null and b/book/src/.gitbook/assets/p_ex_supply-3.png differ
diff --git a/book/src/.gitbook/assets/passive-staking-callflow (1).svg b/book/src/.gitbook/assets/passive-staking-callflow (1).svg
new file mode 100644
index 0000000000..378686284a
--- /dev/null
+++ b/book/src/.gitbook/assets/passive-staking-callflow (1).svg
@@ -0,0 +1,238 @@
+
+
diff --git a/book/src/.gitbook/assets/passive-staking-callflow (2).svg b/book/src/.gitbook/assets/passive-staking-callflow (2).svg
new file mode 100644
index 0000000000..378686284a
--- /dev/null
+++ b/book/src/.gitbook/assets/passive-staking-callflow (2).svg
@@ -0,0 +1,238 @@
+
+
diff --git a/book/src/.gitbook/assets/passive-staking-callflow (3).svg b/book/src/.gitbook/assets/passive-staking-callflow (3).svg
new file mode 100644
index 0000000000..378686284a
--- /dev/null
+++ b/book/src/.gitbook/assets/passive-staking-callflow (3).svg
@@ -0,0 +1,238 @@
+
+
diff --git a/book/src/.gitbook/assets/runtime (1).svg b/book/src/.gitbook/assets/runtime (1).svg
new file mode 100644
index 0000000000..0a9b8289b2
--- /dev/null
+++ b/book/src/.gitbook/assets/runtime (1).svg
@@ -0,0 +1,346 @@
+
diff --git a/book/src/.gitbook/assets/runtime (2).svg b/book/src/.gitbook/assets/runtime (2).svg
new file mode 100644
index 0000000000..0a9b8289b2
--- /dev/null
+++ b/book/src/.gitbook/assets/runtime (2).svg
@@ -0,0 +1,346 @@
+
diff --git a/book/src/.gitbook/assets/runtime (3).svg b/book/src/.gitbook/assets/runtime (3).svg
new file mode 100644
index 0000000000..0a9b8289b2
--- /dev/null
+++ b/book/src/.gitbook/assets/runtime (3).svg
@@ -0,0 +1,346 @@
+
diff --git a/book/src/.gitbook/assets/sdk-tools (1).svg b/book/src/.gitbook/assets/sdk-tools (1).svg
new file mode 100644
index 0000000000..629a3feaa3
--- /dev/null
+++ b/book/src/.gitbook/assets/sdk-tools (1).svg
@@ -0,0 +1,237 @@
+
diff --git a/book/src/.gitbook/assets/sdk-tools (2).svg b/book/src/.gitbook/assets/sdk-tools (2).svg
new file mode 100644
index 0000000000..629a3feaa3
--- /dev/null
+++ b/book/src/.gitbook/assets/sdk-tools (2).svg
@@ -0,0 +1,237 @@
+
diff --git a/book/src/.gitbook/assets/sdk-tools (3).svg b/book/src/.gitbook/assets/sdk-tools (3).svg
new file mode 100644
index 0000000000..629a3feaa3
--- /dev/null
+++ b/book/src/.gitbook/assets/sdk-tools (3).svg
@@ -0,0 +1,237 @@
+
diff --git a/book/src/.gitbook/assets/spv-bank-merkle (1).svg b/book/src/.gitbook/assets/spv-bank-merkle (1).svg
new file mode 100644
index 0000000000..a07908d17e
--- /dev/null
+++ b/book/src/.gitbook/assets/spv-bank-merkle (1).svg
@@ -0,0 +1,163 @@
+
diff --git a/book/src/.gitbook/assets/spv-bank-merkle (2).svg b/book/src/.gitbook/assets/spv-bank-merkle (2).svg
new file mode 100644
index 0000000000..a07908d17e
--- /dev/null
+++ b/book/src/.gitbook/assets/spv-bank-merkle (2).svg
@@ -0,0 +1,163 @@
+
diff --git a/book/src/.gitbook/assets/spv-bank-merkle (3).svg b/book/src/.gitbook/assets/spv-bank-merkle (3).svg
new file mode 100644
index 0000000000..a07908d17e
--- /dev/null
+++ b/book/src/.gitbook/assets/spv-bank-merkle (3).svg
@@ -0,0 +1,163 @@
+
diff --git a/book/src/.gitbook/assets/spv-block-merkle (1).svg b/book/src/.gitbook/assets/spv-block-merkle (1).svg
new file mode 100644
index 0000000000..18ea80cadd
--- /dev/null
+++ b/book/src/.gitbook/assets/spv-block-merkle (1).svg
@@ -0,0 +1,203 @@
+
diff --git a/book/src/.gitbook/assets/spv-block-merkle (2).svg b/book/src/.gitbook/assets/spv-block-merkle (2).svg
new file mode 100644
index 0000000000..18ea80cadd
--- /dev/null
+++ b/book/src/.gitbook/assets/spv-block-merkle (2).svg
@@ -0,0 +1,203 @@
+
diff --git a/book/src/.gitbook/assets/spv-block-merkle (3).svg b/book/src/.gitbook/assets/spv-block-merkle (3).svg
new file mode 100644
index 0000000000..18ea80cadd
--- /dev/null
+++ b/book/src/.gitbook/assets/spv-block-merkle (3).svg
@@ -0,0 +1,203 @@
+
diff --git a/book/src/.gitbook/assets/tpu (1).svg b/book/src/.gitbook/assets/tpu (1).svg
new file mode 100644
index 0000000000..1de96c7927
--- /dev/null
+++ b/book/src/.gitbook/assets/tpu (1).svg
@@ -0,0 +1,312 @@
+
diff --git a/book/src/.gitbook/assets/tpu (2).svg b/book/src/.gitbook/assets/tpu (2).svg
new file mode 100644
index 0000000000..1de96c7927
--- /dev/null
+++ b/book/src/.gitbook/assets/tpu (2).svg
@@ -0,0 +1,312 @@
+
diff --git a/book/src/.gitbook/assets/tvu (1).svg b/book/src/.gitbook/assets/tvu (1).svg
new file mode 100644
index 0000000000..de4c59c97e
--- /dev/null
+++ b/book/src/.gitbook/assets/tvu (1).svg
@@ -0,0 +1,311 @@
+
diff --git a/book/src/.gitbook/assets/tvu (2).svg b/book/src/.gitbook/assets/tvu (2).svg
new file mode 100644
index 0000000000..de4c59c97e
--- /dev/null
+++ b/book/src/.gitbook/assets/tvu (2).svg
@@ -0,0 +1,311 @@
+
diff --git a/book/src/.gitbook/assets/tvu (3).svg b/book/src/.gitbook/assets/tvu (3).svg
new file mode 100644
index 0000000000..de4c59c97e
--- /dev/null
+++ b/book/src/.gitbook/assets/tvu (3).svg
@@ -0,0 +1,311 @@
+
diff --git a/book/src/.gitbook/assets/validator (1).svg b/book/src/.gitbook/assets/validator (1).svg
new file mode 100644
index 0000000000..11be7b6a71
--- /dev/null
+++ b/book/src/.gitbook/assets/validator (1).svg
@@ -0,0 +1,456 @@
+
diff --git a/book/src/.gitbook/assets/validator (2).svg b/book/src/.gitbook/assets/validator (2).svg
new file mode 100644
index 0000000000..11be7b6a71
--- /dev/null
+++ b/book/src/.gitbook/assets/validator (2).svg
@@ -0,0 +1,456 @@
+
diff --git a/book/src/.gitbook/assets/validator-proposal (1).svg b/book/src/.gitbook/assets/validator-proposal (1).svg
new file mode 100644
index 0000000000..bf8410aba8
--- /dev/null
+++ b/book/src/.gitbook/assets/validator-proposal (1).svg
@@ -0,0 +1,496 @@
+
diff --git a/book/src/.gitbook/assets/validator-proposal (2).svg b/book/src/.gitbook/assets/validator-proposal (2).svg
new file mode 100644
index 0000000000..bf8410aba8
--- /dev/null
+++ b/book/src/.gitbook/assets/validator-proposal (2).svg
@@ -0,0 +1,496 @@
+
diff --git a/book/src/.gitbook/assets/validator-proposal (3).svg b/book/src/.gitbook/assets/validator-proposal (3).svg
new file mode 100644
index 0000000000..bf8410aba8
--- /dev/null
+++ b/book/src/.gitbook/assets/validator-proposal (3).svg
@@ -0,0 +1,496 @@
+
diff --git a/book/src/cluster/fork-generation.md b/book/src/cluster/fork-generation.md
index d644bb7ca9..d1397d9de2 100644
--- a/book/src/cluster/fork-generation.md
+++ b/book/src/cluster/fork-generation.md
@@ -12,14 +12,14 @@ Nodes take turns being leader and generating the PoH that encodes state changes.
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 blobs\)
- 1. The PoH stream includes ticks; empty entries that indicate liveness of
+5. Leader transmits the entries to validator nodes \(in signed blobs\) 1. The PoH stream includes ticks; empty entries that indicate liveness of
- the leader and the passage of time on the cluster.
+ the leader and the passage of time on the cluster.
- 2. A leader's stream begins with the tick entries necessary complete the PoH
+ 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.
@@ -58,7 +58,7 @@ Validators vote based on a greedy choice to maximize their reward described in [
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.
-
+
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.
diff --git a/book/src/cluster/ledger-replication.md b/book/src/cluster/ledger-replication.md
index 6d7060303b..d289d127b6 100644
--- a/book/src/cluster/ledger-replication.md
+++ b/book/src/cluster/ledger-replication.md
@@ -100,7 +100,7 @@ We have the following constraints:
there are not any obvious attack vectors that this could accomplish besides having the
- replicator do extra wasted work. For many of the operations there are a number of options
+ replicator do extra wasted work. For many of the operations there are a number of options
depending on how paranoid a replicator is:
diff --git a/book/src/cluster/managing-forks.md b/book/src/cluster/managing-forks.md
index 0146ffe843..6a26b4b0cd 100644
--- a/book/src/cluster/managing-forks.md
+++ b/book/src/cluster/managing-forks.md
@@ -23,13 +23,13 @@ A fullnode may vote on any checkpoint in the tree. In the diagram above, that's
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:
-
+
The new root is 2, and any active forks that are not descendants from 2 are pruned.
Alternatively, a vote on 6:
-
+
The tree remains with a root of 1, since the active fork starting at 6 is only 2 checkpoints from the root.
diff --git a/book/src/cluster/stake-delegation-and-rewards.md b/book/src/cluster/stake-delegation-and-rewards.md
index d496e0bfca..c89cd7b1dc 100644
--- a/book/src/cluster/stake-delegation-and-rewards.md
+++ b/book/src/cluster/stake-delegation-and-rewards.md
@@ -35,18 +35,17 @@ VoteState is the current state of all the votes the validator has submitted to t
`VoteState::authorized_voter_pubkey` is initialized to `account[0]`
- other VoteState members defaulted
+ other VoteState members defaulted
### VoteInstruction::AuthorizeVoter\(Pubkey\)
-Allows a staker to choose a signing service for its votes. That service is
-responsible for ensuring the vote won't cause the staker to be slashed.
+Allows a staker to choose a signing service for its votes. That service is responsible for ensuring the vote won't cause the staker to be slashed.
* `account[0]` - RW - The VoteState
`VoteState::authorized_voter_pubkey` is set to to `Pubkey`, the transaction must by
- signed by the Vote account's current `authorized_voter_pubkey`.
+ signed by the Vote account's current `authorized_voter_pubkey`.
### VoteInstruction::Vote\(Vec\)
@@ -135,7 +134,7 @@ Lamports build up over time in a Stake account and any excess over activated sta
## Example Callflow
-
+
## Staking Rewards
@@ -206,3 +205,4 @@ As rewards are earned lamports can be withdrawn from a stake account. Only lampo
### 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 a slot height, i.e. the minimum slot height that must be reached by the network before the stake account balance is available for withdrawal.
+
diff --git a/book/src/cluster/turbine-block-propagation.md b/book/src/cluster/turbine-block-propagation.md
index d200402139..045f5d28af 100644
--- a/book/src/cluster/turbine-block-propagation.md
+++ b/book/src/cluster/turbine-block-propagation.md
@@ -24,11 +24,11 @@ The following diagram shows how the Leader sends shreds with a Fanout of 2 to Ne
The following diagram shows how Neighborhood 0 fans out to Neighborhoods 1 and 2.
-
+
Finally, the following diagram shows a two layer cluster with a Fanout of 2.
-
+
### Configuration Values
@@ -40,5 +40,5 @@ Currently, configuration is set when the cluster is launched. In the future, the
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.
-
+
diff --git a/book/src/implemented-proposals/blocktree.md b/book/src/implemented-proposals/blocktree.md
index 31a7f7d194..1399b0d716 100644
--- a/book/src/implemented-proposals/blocktree.md
+++ b/book/src/implemented-proposals/blocktree.md
@@ -12,7 +12,7 @@ Repair requests for recent shreds are served out of RAM or recent files and out
1. Persistence: the Blocktree lives in the front of the nodes verification
- pipeline, right behind network receive and signature verification. If the
+ pipeline, right behind network receive and signature verification. If the
shred received is consistent with the leader schedule \(i.e. was signed by the
@@ -30,7 +30,7 @@ Repair requests for recent shreds are served out of RAM or recent files and out
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
+ 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
@@ -76,12 +76,9 @@ The bank exposes to replay stage:
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
+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
+ 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.
diff --git a/book/src/implemented-proposals/credit-only-credit-debit-accounts.md b/book/src/implemented-proposals/credit-only-credit-debit-accounts.md
index c837fb3db2..d6d031ac59 100644
--- a/book/src/implemented-proposals/credit-only-credit-debit-accounts.md
+++ b/book/src/implemented-proposals/credit-only-credit-debit-accounts.md
@@ -69,7 +69,7 @@ This design attempts to cache a credit-only account after loading without the us
1. Transaction accounts are locked.
- a. If the account is present in the ‘credit-only' table, the TX does not fail.
+ a. If the account is present in the ‘credit-only' table, the TX does not fail.
```text
The pending state for this TX is marked NeedReadLock.
@@ -77,13 +77,13 @@ This design attempts to cache a credit-only account after loading without the us
2. Transaction accounts are loaded.
- a. Transaction accounts that are credit-only increase their reference
+ a. Transaction accounts that are credit-only increase their reference
```text
count in the `credit-only` table.
```
- b. Transaction accounts that need a write lock and are present in the
+ b. Transaction accounts that need a write lock and are present in the
```text
`credit-only` table fail.
@@ -91,9 +91,9 @@ This design attempts to cache a credit-only account after loading without the us
3. Transaction accounts are unlocked.
- a. Decrement the `credit-only` lock table reference count; remove if its 0
+ a. Decrement the `credit-only` lock table reference count; remove if its 0
- b. Remove from the `lock` set if the account is not in the `credit-only`
+ b. Remove from the `lock` set if the account is not in the `credit-only`
```text
table.
diff --git a/book/src/implemented-proposals/ed_overview/README.md b/book/src/implemented-proposals/ed_overview/README.md
index 59fe81b785..f95c486d84 100644
--- a/book/src/implemented-proposals/ed_overview/README.md
+++ b/book/src/implemented-proposals/ed_overview/README.md
@@ -8,7 +8,7 @@ These protocol-based rewards, to be distributed to participating validation and
Transaction fees are market-based participant-to-participant transfers, attached to network interactions as a necessary motivation and compensation for the inclusion and execution of a proposed transaction \(be it a state execution or proof-of-replication verification\). A mechanism for long-term economic stability and forking protection through partial burning of each transaction fee is also discussed below.
-A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics/), [State-validation Protocol-based Rewards](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. Additionally, in [Storage Rent Economics](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. The [Replication-client Economics](ed_replication_client_economics/) chapter will review the Solana network design for global ledger storage/redundancy and replicator-client economics \([Storage-replication rewards](ed_replication_client_economics/ed_rce_storage_replication_rewards.md)\) along with a replicator-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md). An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. Finally, in chapter [Attack Vectors](ed_attack_vectors.md), various attack vectors will be described and potential vulnerabilities explored and parameterized.
+A high-level schematic of Solana’s crypto-economic design is shown below in **Figure 1**. The specifics of validation-client economics are described in sections: [Validation-client Economics](ed_validation_client_economics/), [State-validation Protocol-based Rewards](ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md), [State-validation Transaction Fees](ed_validation_client_economics/ed_vce_state_validation_transaction_fees.md) and [Replication-validation Transaction Fees](ed_validation_client_economics/ed_vce_replication_validation_transaction_fees.md). Also, the chapter titled [Validation Stake Delegation](ed_validation_client_economics/ed_vce_validation_stake_delegation.md) closes with a discussion of validator delegation opportunties and marketplace. Additionally, in [Storage Rent Economics](https://github.com/solana-labs/solana/tree/aacead62c0eb052068172eba6b53fc85874d6d54/book/src/ed_storage_rent_economics.md), we describe an implementation of storage rent to account for the externality costs of maintaining the active state of the ledger. The [Replication-client Economics](ed_replication_client_economics/) chapter will review the Solana network design for global ledger storage/redundancy and replicator-client economics \([Storage-replication rewards](ed_replication_client_economics/ed_rce_storage_replication_rewards.md)\) along with a replicator-to-validator delegation mechanism designed to aide participant on-boarding into the Solana economy discussed in [Replication-client Reward Auto-delegation](ed_replication_client_economics/ed_rce_replication_client_reward_auto_delegation.md). An outline of features for an MVP economic design is discussed in the [Economic Design MVP](ed_mvp.md) section. Finally, in chapter [Attack Vectors](ed_attack_vectors.md), various attack vectors will be described and potential vulnerabilities explored and parameterized.
**Figure 1**: Schematic overview of Solana economic incentive design.
diff --git a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md
index 8dfee0e9f2..c0ec83fbf7 100644
--- a/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md
+++ b/book/src/implemented-proposals/ed_overview/ed_validation_client_economics/ed_vce_state_validation_protocol_based_rewards.md
@@ -17,9 +17,9 @@ The first factor is a function of protocol parameters only \(i.e. independent of
At any given point in time, a specific validator's interest rate can be determined based on the porportion of circulating supply that is staked by the network and the validator's uptime/activity in the previous epoch. For example, consider a hypothetical instance of the network with an initial circulating token supply of 250MM tokens with an additional 250MM vesting over 3 years. Additionally an inflation rate is specified at network launch of 7.5%, and a disinflationary schedule of 20% decrease in inflation rate per year \(the actual rates to be implemented are to be worked out during the testnet experimentation phase of mainnet launch\). With these broad assumptions, the 10-year inflation rate \(adjusted daily for this example\) is shown in **Figure 2**, while the total circulating token supply is illustrated in **Figure 3**. Neglected in this toy-model is the inflation supression due to the portion of each transaction fee that is to be destroyed.
- \*\*Figure 2:\*\* In this example schedule, the annual inflation rate \[%\] reduces at around 20% per year, until it reaches the long-term, fixed, 1.5% rate.
+ \*\*Figure 2:\*\* In this example schedule, the annual inflation rate \[%\] reduces at around 20% per year, until it reaches the long-term, fixed, 1.5% rate.
- \*\*Figure 3:\*\* The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in \*\*Figure 2\*\* Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabalize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for state-validation and ledger storage replication \(PoReps\) are not accounted for here. Given these example parameters, annualized validator-specific interest rates can be determined based on the global fraction of tokens bonded as stake, as well as their uptime/activity in the previous epoch. For the purpose of this example, we assume 100% uptime for all validators and a split in interest-based rewards between validators and replicator nodes of 80%/20%. Additionally, the fraction of staked circulating supply is assummed to be constant. Based on these assumptions, an annualized validation-client interest rate schedule as a function of % circulating token supply that is staked is shown in\*\* Figure 4\*\*.
+ \*\*Figure 3:\*\* The total token supply over a 10-year period, based on an initial 250MM tokens with the disinflationary inflation schedule as shown in \*\*Figure 2\*\* Over time, the interest rate, at a fixed network staked percentage, will reduce concordant with network inflation. Validation-client interest rates are designed to be higher in the early days of the network to incentivize participation and jumpstart the network economy. As previously mentioned, the inflation rate is expected to stabalize near 1-2% which also results in a fixed, long-term, interest rate to be provided to validator-clients. This value does not represent the total interest available to validator-clients as transaction fees for state-validation and ledger storage replication \(PoReps\) are not accounted for here. Given these example parameters, annualized validator-specific interest rates can be determined based on the global fraction of tokens bonded as stake, as well as their uptime/activity in the previous epoch. For the purpose of this example, we assume 100% uptime for all validators and a split in interest-based rewards between validators and replicator nodes of 80%/20%. Additionally, the fraction of staked circulating supply is assummed to be constant. Based on these assumptions, an annualized validation-client interest rate schedule as a function of % circulating token supply that is staked is shown in\*\* Figure 4\*\*.

diff --git a/book/src/implemented-proposals/installer.md b/book/src/implemented-proposals/installer.md
index b3e7b0d698..b3e085b599 100644
--- a/book/src/implemented-proposals/installer.md
+++ b/book/src/implemented-proposals/installer.md
@@ -95,7 +95,7 @@ A release archive is expected to be a tar file compressed with bzip2 with the fo
* `/version.yml` - a simple YAML file containing the field `"target"` - the
- target tuple. Any additional fields are ignored.
+ target tuple. Any additional fields are ignored.
* `/bin/` -- directory containing available programs in the release.
diff --git a/book/src/implemented-proposals/leader-validator-transition.md b/book/src/implemented-proposals/leader-validator-transition.md
index 1afaf51b17..92e8ef5940 100644
--- a/book/src/implemented-proposals/leader-validator-transition.md
+++ b/book/src/implemented-proposals/leader-validator-transition.md
@@ -35,19 +35,17 @@ The PoH Recorder manages the transition between modes. Once a ledger is replayed
The loop is synchronized to PoH and does a synchronous start and stop of the slot leader functionality. After stopping, the validator's TVU should find itself in the same state as if a different leader had sent it the same block. The following is pseudocode for the loop:
1. Query the LeaderScheduler for the next assigned slot.
-2. Run the TVU over all the forks.
- 1. TVU will send votes to what it believes is the "best" fork.
- 2. After each vote, restart the PoH Recorder to run until the next assigned
+2. Run the TVU over all the forks. 1. TVU will send votes to what it believes is the "best" fork. 2. After each vote, restart the PoH Recorder to run until the next assigned
+
+ slot.
- slot.
3. When time to be a slot leader, start the TPU. Point it to the last fork the
TVU voted on.
-4. Produce entries until the end of the slot.
- 1. For the duration of the slot, the TVU must not vote on other forks.
- 2. After the slot ends, the TPU freezes its BankFork. After freezing,
+4. Produce entries until the end of the slot. 1. For the duration of the slot, the TVU must not vote on other forks. 2. After the slot ends, the TPU freezes its BankFork. After freezing,
+
+ the TVU may resume voting.
- the TVU may resume voting.
5. Goto 1.
diff --git a/book/src/proposals/interchain-transaction-verification.md b/book/src/proposals/interchain-transaction-verification.md
index 70de8f3ea5..7469a5da73 100644
--- a/book/src/proposals/interchain-transaction-verification.md
+++ b/book/src/proposals/interchain-transaction-verification.md
@@ -56,7 +56,7 @@ A contract deployed on Solana which coordinates and intermediates the interactio
* Submit Proof Request - allows client to place a request for a specific proof or set of proofs
* Cancel Proof Request - allows client to invalidate a pending request
-* Fill Proof Request - used by Provers to submit for validation a proof corresponding to a given Proof Request
+* Fill Proof Request - used by Provers to submit for validation a proof corresponding to a given Proof Request
The SPV program maintains a publicly available listing of valid pending Proof
diff --git a/book/src/proposals/rent.md b/book/src/proposals/rent.md
index e99cda87e8..f6a4ffc5c1 100644
--- a/book/src/proposals/rent.md
+++ b/book/src/proposals/rent.md
@@ -30,11 +30,11 @@ Under this design, it is possible to have accounts that linger, never get touche
Collecting rent on an as-needed basis \(i.e. whenever accounts were loaded/accessed\) was considered. The issues with such an approach are:
-* accounts loaded as "credit only" for a transaction could very reasonably be expected to have rent due,
+* accounts loaded as "credit only" for a transaction could very reasonably be expected to have rent due,
but would not be debitable during any such transaction
-* a mechanism to "beat the bushes" \(i.e. go find accounts that need to pay rent\) is desirable,
+* a mechanism to "beat the bushes" \(i.e. go find accounts that need to pay rent\) is desirable,
lest accounts that are loaded infrequently get a free ride
diff --git a/book/src/proposals/simple-payment-and-state-verification.md b/book/src/proposals/simple-payment-and-state-verification.md
index 3bb0df0270..6fe94c4654 100644
--- a/book/src/proposals/simple-payment-and-state-verification.md
+++ b/book/src/proposals/simple-payment-and-state-verification.md
@@ -48,7 +48,7 @@ At the end of the block, A and B are in the exact same starting state, and any s
The Bank-Merkle is computed from the Merkle Tree of the new state changes, along with the Previous Bank-Merkle, and the Block-Merkle.
-
+
A state receipt contains only the state changes occurring in the block. A direct Merkle Path to the current Bank-Merkle guarantees the state value at that bank hash, but it cannot be used to generate a “current” receipt to the latest state if the state modification occurred in some previous block. There is no guarantee that the path provided by the validator is the latest one available out of all the previous Bank-Merkles.
diff --git a/book/src/proposals/validator-proposal.md b/book/src/proposals/validator-proposal.md
index 1c31574f68..4828e4ab52 100644
--- a/book/src/proposals/validator-proposal.md
+++ b/book/src/proposals/validator-proposal.md
@@ -12,7 +12,7 @@ The fundamental difference between the pipelines is when the PoH is present. In
We unwrap the many abstraction layers and build a single pipeline that can toggle leader mode on whenever the validator's ID shows up in the leader schedule.
-
+
## Notable changes
diff --git a/book/src/validator/runtime.md b/book/src/validator/runtime.md
index 9b428b566a..7f5e0365e0 100644
--- a/book/src/validator/runtime.md
+++ b/book/src/validator/runtime.md
@@ -20,7 +20,7 @@ Transactions are batched and processed in a pipeline. The TPU and TVU follow a s
The TVU runtime ensures that PoH verification occurs before the runtime processes any transactions.
-
+
At the _execute_ stage, the loaded accounts have no data dependencies, so all the programs can be executed in parallel.
diff --git a/book/src/validator/tvu/blocktree.md b/book/src/validator/tvu/blocktree.md
index f07eff244d..69497d84c6 100644
--- a/book/src/validator/tvu/blocktree.md
+++ b/book/src/validator/tvu/blocktree.md
@@ -12,7 +12,7 @@ Repair requests for recent shreds are served out of RAM or recent files and out
1. Persistence: the Blocktree lives in the front of the nodes verification
- pipeline, right behind network receive and signature verification. If the
+ pipeline, right behind network receive and signature verification. If the
shred received is consistent with the leader schedule \(i.e. was signed by the
@@ -30,7 +30,7 @@ Repair requests for recent shreds are served out of RAM or recent files and out
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
+ 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
@@ -76,12 +76,9 @@ The bank exposes to replay stage:
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
+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
+ 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.