Move implemented proposals into the implemented section of the book (s…

…olana-labs#7591)

* Move implemented proposals to implemented section of the book

Leave "Slashing" commentary in a new proposal.

* Remove considered considerations

@CriesofCarrots says meh about the first concern, and has moved the
second concern into a GitHub issue solana-labs#7485.

book/src/SUMMARY.md

@@ -49,17 +49,14 @@
 * [Accepted Design Proposals](proposals/README.md)
   * [Ledger Replication](proposals/ledger-replication-to-implement.md)
   * [Secure Vote Signing](proposals/vote-signing-to-implement.md)
-  * [Staking Rewards](proposals/staking-rewards.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)
-  * [Rent](proposals/rent.md)
   * [Inter-chain Transaction Verification](proposals/interchain-transaction-verification.md)
   * [Snapshot Verification](proposals/snapshot-verification.md)
   * [Bankless Leader](proposals/bankless-leader.md)
-  * [Durable Transaction Nonces](proposals/durable-tx-nonces.md)
-  * [Validator Timestamp Oracle](proposals/validator-timestamp-oracle.md)
+  * [Slashing](proposals/slashing.md)
 * [Implemented Design Proposals](implemented-proposals/README.md)
   * [Blocktree](implemented-proposals/blocktree.md)
   * [Cluster Software Installation and Updates](implemented-proposals/installer.md)
@@ -86,3 +83,7 @@
   * [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)

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

@@ -48,45 +48,6 @@ To become a Solana validator, one must deposit/lock-up some amount of SOL in a c
 
 Solana's trustless sense of time and ordering provided by its PoH data structure, along with its [turbine](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast and transmission design, should provide sub-second transaction confirmation times that scale with the log of the number of nodes in the cluster. This means we shouldn't have to restrict the number of validating nodes with a prohibitive 'minimum deposits' and expect nodes to be able to become validators with nominal amounts of SOL staked. At the same time, Solana's focus on high-throughput should create incentive for validation clients to provide high-performant and reliable hardware. Combined with potential a minimum network speed threshold to join as a validation-client, we expect a healthy validation delegation market to emerge. To this end, Solana's testnet will lead into a "Tour de SOL" validation-client competition, focusing on throughput and uptime to rank and reward testnet validators.
 
-## Slashing rules
-
-Unlike Proof of Work \(PoW\) where off-chain capital expenses are already deployed at the time of block construction/voting, PoS systems require capital-at-risk to prevent a logical/optimal strategy of multiple chain voting. We intend to implement slashing rules which, if broken, result some amount of the offending validator's deposited stake to be removed from circulation. Given the ordering properties of the PoH data structure, we believe we can simplify our slashing rules to the level of a voting lockout time assigned per vote.
-
-I.e. Each vote has an associated lockout time \(PoH duration\) that represents a duration by any additional vote from that validator must be in a PoH that contains the original vote, or a portion of that validator's stake is slashable. This duration time is a function of the initial vote PoH count and all additional vote PoH counts. It will likely take the form:
-
-Lockouti\(PoHi, PoHj\) = PoHj + K \* exp\(\(PoHj - PoHi\) / K\)
-
-Where PoHi is the height of the vote that the lockout is to be applied to and PoHj is the height of the current vote on the same fork. If the validator submits a vote on a different PoH fork on any PoHk where k > j > i and PoHk < Lockout\(PoHi, PoHj\), then a portion of that validator's stake is at risk of being slashed.
-
-In addition to the functional form lockout described above, early implementation may be a numerical approximation based on a First In, First Out \(FIFO\) data structure and the following logic:
-
-* FIFO queue holding 32 votes per active validator
-* new votes are pushed on top of queue \(`push_front`\)
-* expired votes are popped off top \(`pop_front`\)
-* as votes are pushed into the queue, the lockout of each queued vote doubles
-* votes are removed from back of queue if `queue.len() > 32`
-* the earliest and latest height that has been removed from the back of the
-
-  queue should be stored
-
-It is likely that a reward will be offered as a % of the slashed amount to any node that submits proof of this slashing condition being violated to the PoH.
-
-### Partial Slashing
-
-In the schema described so far, when a validator votes on a given PoH stream, they are committing themselves to that fork for a time determined by the vote lockout. An open question is whether validators will be hesitant to begin voting on an available fork if the penalties are perceived too harsh for an honest mistake or flipped bit.
-
-One way to address this concern would be a partial slashing design that results in a slashable amount as a function of either:
-
-1. the fraction of validators, out of the total validator pool, that were also
-
-   slashed during the same time period \(ala Casper\)
-
-2. the amount of time since the vote was cast \(e.g. a linearly increasing % of
-
-   total deposited as slashable amount over time\), or both.
-
-This is an area currently under exploration
-
 ## Penalties
 
 As discussed in the [Economic Design](../implemented-proposals/ed_overview/) section, annual validator interest rates are to be specified as a function of total percentage of circulating supply that has been staked. The cluster rewards validators who are online and actively participating in the validation process throughout the entirety of their _validation period_. For validators that go offline/fail to validate transactions during this period, their annual reward is effectively reduced.

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

@@ -67,7 +67,7 @@ A validator's vote account will hold its most recent slot-timestamp in VoteState
 ### Vote Program
 
 The on-chain Vote program needs to be extended to process a timestamp sent with
-a Vote instruction from validators. In addition to its current process_vote
+a Vote instruction from validators. In addition to its current process\_vote
 functionality (including loading the correct Vote account and verifying that the
 transaction signer is the expected validator), this process needs to compare the
 timestamp and corresponding slot to the currently stored values to verify that
@@ -86,7 +86,7 @@ let timestamp_slot = floor(current_slot / timestamp_interval);
 Then the validator needs to gather all Vote WithTimestamp transactions from the
 ledger that reference that slot, using `Blocktree::get_slot_entries()`. As these
 transactions could have taken some time to reach and be processed by the leader,
-the validator needs to scan several completed blocks after the timestamp_slot to
+the validator needs to scan several completed blocks after the timestamp\_slot to
 get a reasonable set of Timestamps. The exact number of slots will need to be
 tuned: More slots will enable greater cluster participation and more timestamp
 datapoints; fewer slots will speed how long timestamp filtering takes.
@@ -109,21 +109,5 @@ let block_n_timestamp = mean_timestamp + (block_n_slot_offset * slot_duration);
 ```
 
 where `block_n_slot_offset` is the difference between the slot of block N and
-the timestamp_slot, and `slot_duration` is derived from the cluster's
+the timestamp\_slot, and `slot_duration` is derived from the cluster's
 `slots_per_year` stored in each Bank
-
-## Additional Considerations
-
-1. This proposal puts a distinct processing burden on a validator when it receives
-a `getBlockTime` RPC request. Another approach would be for a validator to
-maintain a list of mean timestamps, populated as the validator
-builds/replays the ledger.
-
-2. This proposal doesn't address the 4th requirement, that each validator must
-maintain a timestamp oracle. Even though timestamps are tied to voting, there
-are no lockout implications if a validator does not ever included timestamps
-with Votes. One sociological approach would be to include timestamp expectations
-in validator uptime calculations, where uptime is redefined as a function of a
-validator both promptly submitting votes and timestamps over an epoch. This
-might require storing more information about historical timestamps in the vote
-account, however.

book/src/proposals/slashing.md

@@ -0,0 +1,58 @@
+# Slashing rules
+
+Unlike Proof of Work \(PoW\) where off-chain capital expenses are already
+deployed at the time of block construction/voting, PoS systems require
+capital-at-risk to prevent a logical/optimal strategy of multiple chain voting.
+We intend to implement slashing rules which, if broken, result some amount of
+the offending validator's deposited stake to be removed from circulation. Given
+the ordering properties of the PoH data structure, we believe we can simplify
+our slashing rules to the level of a voting lockout time assigned per vote.
+
+I.e. Each vote has an associated lockout time \(PoH duration\) that represents
+a duration by any additional vote from that validator must be in a PoH that
+contains the original vote, or a portion of that validator's stake is
+slashable. This duration time is a function of the initial vote PoH count and
+all additional vote PoH counts. It will likely take the form:
+
+```text
+Lockouti\(PoHi, PoHj\) = PoHj + K \* exp\(\(PoHj - PoHi\) / K\)
+```
+
+Where PoHi is the height of the vote that the lockout is to be applied to and
+PoHj is the height of the current vote on the same fork. If the validator
+submits a vote on a different PoH fork on any PoHk where k > j > i and
+PoHk < Lockout\(PoHi, PoHj\), then a portion of that validator's stake is at
+risk of being slashed.
+
+In addition to the functional form lockout described above, early
+implementation may be a numerical approximation based on a First In, First Out
+\(FIFO\) data structure and the following logic:
+
+* FIFO queue holding 32 votes per active validator
+* new votes are pushed on top of queue \(`push_front`\)
+* expired votes are popped off top \(`pop_front`\)
+* as votes are pushed into the queue, the lockout of each queued vote doubles
+* votes are removed from back of queue if `queue.len() > 32`
+* the earliest and latest height that has been removed from the back of the
+  queue should be stored
+
+It is likely that a reward will be offered as a % of the slashed amount to any
+node that submits proof of this slashing condition being violated to the PoH.
+
+### Partial Slashing
+
+In the schema described so far, when a validator votes on a given PoH stream,
+they are committing themselves to that fork for a time determined by the vote
+lockout. An open question is whether validators will be hesitant to begin
+voting on an available fork if the penalties are perceived too harsh for an
+honest mistake or flipped bit.
+
+One way to address this concern would be a partial slashing design that results
+in a slashable amount as a function of either:
+
+1. the fraction of validators, out of the total validator pool, that were also
+   slashed during the same time period \(ala Casper\)
+2. the amount of time since the vote was cast \(e.g. a linearly increasing % of
+   total deposited as slashable amount over time\), or both.
+
+This is an area currently under exploration.