Prefer the term 'cluster' over 'network'

Use 'network' for the networking stack. Examples:

* The network drops packets.
* The cluster rejects bad transactions.
* The Solana cluster runs on a gigabit network.

book/src/enclave.md

@@ -1,7 +1,7 @@
 # Signing using Secure Enclave
 
 This document defines the security mechanism of signing keys used by the
-network nodes. Every node contains an asymmetric key that's used for signing
+fullnodes. Every node contains an asymmetric key that's used for signing
 and verifying the votes. The node signs the vote transactions using its private
 key. Other entities can verify the signature using the node's public key.
 
@@ -57,7 +57,7 @@ means
 ## Ancestor Verification
 
 This is alternate, albeit, less certain approach to verifying voting fork.
-1. The validator maintains an active set of nodes in the network
+1. The validator maintains an active set of nodes in the cluster
 2. It observes the votes from the active set in the last voting period
 3. It stores the ancestor/last_tick at which each node voted
 4. It sends new vote request to vote-signing service
@@ -71,7 +71,7 @@ and the vote ancestor matches with majority of the nodes
 The premise is that the validator can be spoofed at most once to vote on
 incorrect data. If someone hijacks the validator and submits a vote request for
 bogus data, that vote will not be included in the PoH (as it'll be rejected by
-the network). The next time the validator sends a request to sign the vote, the
+the cluster). The next time the validator sends a request to sign the vote, the
 signing service will detect that validator's last vote is missing (as part of
 #5 above).
 
@@ -134,9 +134,9 @@ simply carry the keypair in the process memory.
 ## Validator voting
 
 A validator node, at startup, creates a new vote account and registers it with
-the network. This is done by submitting a new "vote register" transaction. The
+the cluster. This is done by submitting a new "vote register" transaction. The
 transaction contains validator's keypair, it's vote signing public key, and
-some additional information. The other nodes on the network process this
+some additional information. The other nodes on the cluster process this
 transaction and include the new validator in the active set.
 
 Subsequently, the validator submits a "new vote" transaction on a voting event.
@@ -155,11 +155,11 @@ The validator node will be configured with Signing service's network endpoint
 At startup, the validator will call Signing service using JSON RPC to register
 itself. The RPC call will return the voting public key for the validator node.
 The validator will create a new "vote register" transaction including this
-public key in it, and submit it to the network.
+public key in it, and submit it to the cluster.
 
 ### Collect votes for last period
 
-The validator will look up the votes submitted by all the nodes in the network
+The validator will look up the votes submitted by all the nodes in the cluster
 for the last voting period. This information will be submitted to signing
 service with new vote signing request.
 

book/src/fork-generation.md

@@ -7,7 +7,7 @@ rotation](leader-rotation.md).
 ## Overview
 
 Nodes take turns being leader and generating the PoH that encodes state
-changes.  The network can tolerate loss of connection to any leader by
+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
@@ -22,7 +22,7 @@ transactions will be accepted.
 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
-      the leader and the passage of time on the network.
+      the leader and the passage of time on the cluster.
    2. 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
@@ -35,20 +35,20 @@ transactions will be accepted.
       count
    2. Votes are also propagated via gossip
 10. Leader executes the votes as any other transaction and broadcasts them to
-    the network
+    the cluster.
-11. Validators observe their votes and all the votes from the network.
+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 network at a network-specified rate for hashes/per/tick `Z`.
+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 network can derive from the last tick in the previous
+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
@@ -78,7 +78,7 @@ 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 network.  The following table presents the
+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

book/src/staking-rewards.md

@@ -2,15 +2,15 @@
 
 Initial Proof of Stake (PoS) (i.e. using in-protocol asset, SOL, to provide
 secure consensus) design ideas outlined here. Solana will implement a proof of
-stake reward/security scheme for node validators on the network. The purpose is
+stake reward/security scheme for node validators in the cluster. The purpose is
 threefold:
 
-- Align validator incentives with that of the greater network through
+- Align validator incentives with that of the greater cluster through
   skin-in-the-game deposits at risk
 - Avoid 'nothing at stake' fork voting issues by implementing slashing rules
   aimed at promoting fork convergence
 - Provide an avenue for validator rewards provided as a function of validator
-  participation in the network.
+  participation in the cluster.
 
 While many of the details of the specific implementation are currently under
 consideration and are expected to come into focus through specific modeling
@@ -22,13 +22,13 @@ specific attributes to be modified as is allowed by Solana's Proof of History
 
 ### General Overview
 
-Solana's validation network design is based on a rotating, stake-weighted
+Solana's ledger validation design is based on a rotating, stake-weighted
-randomly selected leader broadcasting network transactions in a PoH data
+randomly selected leader broadcasting transactions in a PoH data
 structure to validating nodes. These nodes, upon receiving the leader's
 broadcast, have the opportunity to vote on the current state and PoH height by
 signing a transaction into the PoH stream.
 
-To become a Solana validator, a network node must deposit/lock-up some amount
+To become a Solana validator, a fullnode must deposit/lock-up some amount
 of SOL in a contract. This SOL will not be accessible for a specific time
 period. The precise duration of the staking lockup period has not been
 determined. However we can consider three phases of this time for which
@@ -36,22 +36,22 @@ specific parameters will be necessary:
 
 - *Warm-up period*: which SOL is deposited and inaccessible to the node,
   however PoH transaction validation has not begun. Most likely on the order of
-days to weeks
+  days to weeks
 - *Validation period*: a minimum duration for which the deposited SOL will be
   inaccessible, at risk of slashing (see slashing rules below) and earning
-network rewards for the validator participation. Likely duration of months to a
+  rewards for the validator participation. Likely duration of months to a
-year.
+  year.
 - *Cool-down period*: a duration of time following the submission of a
   'withdrawal' transaction. During this period validation responsibilities have
-been removed and the funds continue to be inaccessible. Accumulated rewards
+  been removed and the funds continue to be inaccessible. Accumulated rewards
-should be delivered at the end of this period, along with the return of the
+  should be delivered at the end of this period, along with the return of the
-initial deposit.
+  initial deposit.
 
 Solana's trustless sense of time and ordering provided by its PoH data
 structure, along with its
 [avalanche](https://www.youtube.com/watch?v=qt_gDRXHrHQ&t=1s) data broadcast
 and transmission design, should provide subsecond confirmation times that scale
-with the log of the number of nodes in the network. This means we shouldn't
+with the log of the number of nodes in the cluster. This means we shouldn't
 have to restrict the number of validating nodes with a prohibitive 'minimum
 deposits' and expect nodes to be able to become validators with nominal amounts
 of SOL staked. This should also render validation pools, a proposed solution
@@ -67,7 +67,7 @@ stake out of the entirety of the staking pool.
 
 We expect to define a baseline annual validator payout/inflation rate based on
 the total SOL deposited. E.g. 10% annual interest on SOL deposited with X total
-SOL deposited as slashable on network. This is the same design as currently
+SOL deposited as slashable on the cluster. This is the same design as currently
 proposed in Casper FFG which has additionally specifies how inflation rates
 adjust as a function of total ETH deposited. Specifically, Casper validator
 returns are proportional to the inverse square root of the total deposits and
@@ -128,29 +128,32 @@ implementation may be a numerical approximation based on a First In, First Out
 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
+#### Partial Slashing
-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
+In the schema described so far, when a validator votes on a given PoH stream,
-hesitant to begin voting on an available fork if the penalties are perceived
+they are committing themselves to that fork for a time determined by the vote
-too harsh for an honest mistake or flipped bit.
+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
+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
+   slashed during the same time period (ala Casper)
-the vote was cast (e.g. a linearly increasing % of total deposited as slashable
+2. the amount of time since the vote was cast (e.g. a linearly increasing % of
-amount over time), or both.  
+   total deposited as slashable amount over time), or both.  
 
 This is an area currently under exploration
 
 
-### Penalties As previously discussed, annual validator reward rates are to be
+### Penalties
-specified as a function of total amount staked. The network rewards validators
+
-who are online and actively participating in the validation process throughout
+As previously discussed, annual validator reward rates are to be specified as a
-the entirety of their *validation period*. For validators that go offline/fail
+function of total amount staked. The cluster rewards validators who are online
-to validate transactions during this period, their annual reward is effectively
+and actively participating in the validation process throughout the entirety of
-reduced.
+their *validation period*. For validators that go offline/fail to validate
+transactions during this period, their annual reward is effectively reduced.
 
 Similarly, we may consider an algorithmic reduction in a validator's active
 amount staked amount in the case that they are offline. I.e. if a validator is