1426 Cleanup old Highway and rewards references

source/docs/casper/concepts/about.md

@@ -5,9 +5,9 @@ slug: /
 
 ## What is Casper? {#what-is-casper}
 
-Casper is a new [Turing-complete](../concepts/glossary/T.md#turing-complete-blockchain) smart-contracting platform, backed by a Proof-of-Stake (PoS) consensus algorithm and WebAssembly (Wasm). The network is a [permissionless](../concepts/glossary/P.md#permissionless), decentralized, public blockchain.
+Casper is a [Turing-complete](../concepts/glossary/T.md#turing-complete-blockchain) smart-contracting platform, backed by a Proof-of-Stake (PoS) consensus algorithm and WebAssembly (Wasm). The network is a [permissionless](../concepts/glossary/P.md#permissionless), decentralized, public blockchain.
 
-The network's consensus protocol is called [Highway](https://arxiv.org/pdf/2101.02159.pdf), and it has several benefits over classic Byzantine Fault Tolerant (BFT) consensus protocols. First, Highway allows networks to reach higher thresholds of _finality_, meaning that more blocks are finalized, and validators agree to add them to the blockchain. Second, the protocol achieves flexibility by expressing block finality in ways not possible in BFT models. This protocol is built on the [correct-by-construction (CBC) Casper](https://github.com/cbc-casper/cbc-casper-paper) research.
+The network's consensus protocol is called [Zug](./design/zug.md), and it has several benefits over classic Byzantine Fault Tolerant (BFT) consensus protocols. First, Zug allows networks to reach higher thresholds of _finality_, meaning that every block gets finalized within seconds, as fast as the network connections allow. Second, the protocol achieves flexibility by expressing block finality in ways not possible in BFT models. This protocol is built on the following research: [From Weakly-terminating Binary Agreement and Reliable Broadcast to Atomic Broadcast](https://arxiv.org/abs/2205.06314).
 
 Additionally, the Casper Network is optimized for enterprise and developer adoption. While leveraging blockchain technology, the network seeks to accelerate business operations via unique features like predictable network fees, upgradeable contracts, on-chain governance, privacy flexibility, and developer-friendly languages. Casper's [core features and strengths](../resources/build-on-casper.md) enable developers and enterprises to reap the benefits of blockchain technology.
 

source/docs/casper/concepts/design/casper-design.md

@@ -230,7 +230,7 @@ Refer to the [Serialization Standard](../serialization-standard.md) for addition
 
 ## Tokens {#tokens-head}
 
-Casper is a decentralized Proof-of-Stake blockchain platform that uses a consensus algorithm called [Highway](./highway.md). Having a unit of value is required to make this system work because users must pay for computation, and validators must have [stake](../economics/staking/staking.md) to bond. In the blockchain space, this unit of value is a _token_.
+Casper is a decentralized Proof-of-Stake blockchain platform that uses a consensus algorithm called [Zug](./zug.md). Having a unit of value is required to make this system work because users must pay for computation, and validators must have [stake](../economics/staking/staking.md) to bond. In the blockchain space, this unit of value is a _token_.
 
 This chapter describes tokens and how one can use them on the Casper platform.
 

source/docs/casper/concepts/design/index.md

@@ -11,4 +11,4 @@ slug: /design
 | [Zug Consensus](./zug.md)                                   | An overview of the Zug consensus used in Mainnet and Testnet                                   |
 | [Highway Consensus](./highway.md)                           | Brief overview of the Highway consensus available as an alternative to Zug                     |
 | [Validator Rewards](./rewards.md)                           | Overview of how rewards are calculated and distributed                                         |
-| [Reading and Writing Data to Global State](./reading-and-writing-to-the-blockchain.md) | Storing and reading data from the blockchain                        |
+| [Reading and Writing Data to Global State](./reading-and-writing-to-the-blockchain.md) | Storing and reading data from the blockchain                        |

source/docs/casper/concepts/design/networking-protocol.md

@@ -180,7 +180,7 @@ struct GossipedAddress(SocketAddr);
 
 ### Consensus
 
-A consensus message is sent exclusively between instances of the consensus component, from one peer to another. A precise description of the Highway consensus protocol is out of scope of this document, see the `consensus::Message` type or an appropriate description of the underlying protocol for details.
+A [consensus](./consensus.md) message is sent exclusively between instances of the consensus component, from one peer to another.
 
 ### Gossiping
 

source/docs/casper/concepts/design/rewards.md

@@ -10,8 +10,7 @@ Validators receive rewards for participating in consensus and thus securing the
 
 Like other Proof-of-Stake chains, a Casper network rewards validators for participating in building a linear chain of blocks, each containing ordered state changes and ensuring that the entire ecosystem of validators, builders, and users eventually achieve common knowledge of the chain's history. External, non-validator participants in the ecosystem can thus have a high degree of confidence on the canonical history of the blockchain's state, thus making the blockchain economically useful.
 
-<!-- TODO link to Zug and Highway once PR 1427 merges-->
-The network uses a new reward scheme that does not depend on the details of the consensus protocol and is compatible with both Zug and Highway. The current reward scheme has the following properties:
+The network uses a new reward scheme that does not depend on the details of the consensus protocol and is compatible with both [Zug](./zug.md) and [Highway](./highway.md). The current reward scheme has the following properties:
 
 - Rewards are proportional to a validator's weight.
 - The reward scheme incentivizes cooperation.

source/docs/casper/concepts/economics/consensus.md

@@ -4,7 +4,10 @@ title: Consensus
 
 # Consensus Economics
 
-[Highway consensus](../design/highway.md) is a continuous, trust-less process where a fixed set of validators engage in scheduled communication to advance the linear chain of finalized blocks, representing the history of changes to the global state of the blockchain. The fixed set of validators may change at each era boundary. The economics of this layer revolve around validator selection and incentivization of participation according to the schedule.
+<!--TODO review this entire page with AL/BK/AS-->
+<!--TODO Is Zug a Correct-by-construction (CBC) protocol (async liveness, provable safety)?-->
+
+[Casper consensus](../design/consensus.md) is a continuous, trustless process where a fixed set of validators engage in scheduled communication to advance the linear chain of finalized blocks, representing the history of changes in the global state of the blockchain. The fixed set of validators may change at each era boundary. The economics of this layer revolve around validator selection and incentivization of participation according to the schedule.
 
 ## Entry {#entry}
 
@@ -27,7 +30,7 @@ Currently, delegation is unrestricted. Please visit [Delegation details](./staki
 
 ## Incentives {#incentives}
 
-Correct operation of the Highway protocol requires the economics of the platform to discourage equivocation for safety and incentivize participation for liveness. Participation consists of on-time block proposals and timely responses to block proposals.
+Correct operation of the consensus protocol requires the economics of the platform to discourage equivocation (signing conflicting consensus messages) for safety and incentivize participation for liveness. Participation consists of on-time block proposals and timely responses to block proposals.
 
 Safety may be incentivized through slashing for equivocation. This feature is currently disabled but may be reactivated in the future.
 
@@ -71,15 +74,17 @@ This value gives us the maximum amount of CSPR that the validators can collectiv
 
 #### Distribution {#distribution}
 
-Validators receive tokens for proposing and finalizing blocks according to their performance. The concept of weight is crucial for understanding this distribution scheme:
+Validators receive rewards for proposing and finalizing blocks according to their performance. The concept of weight is crucial for understanding this distribution scheme:
 
 -   **Weight:** A validator's bonded stake, used in consensus
 -   **Assigned weight of a block/round:** The total stake of validators scheduled to participate in a block
 -   **Participated weight of a block/round:** The total stake of validators that end up participating or sending messages to finalize a block before the end of their respective round
 
 To determine eligibility, we look at **on-time finalization (OTF)**. Validators should finalize blocks on time by sending required messages before the end of their respective round.
 
-Switch blocks are not visible to the issuance calculation (as this calculation is performed in the switch block itself for each era), and, consequently, no tokens are issued for switch blocks.
+Switch blocks are not visible to the issuance calculation (as this calculation is performed in the switch block itself for each era), and, consequently, no rewards are issued for switch blocks.
+
+<!-- TODO participation and eligibility seem to be too specific to Highway. Work with AL/BK to add new explanations or confirm that we can remove these.
 
 ##### Participation schedule {#participation-schedule}
 
@@ -90,15 +95,18 @@ Each validator is assessed according to its round exponent. All assigned validat
 ##### Eligibility {#eligibility}
 
 Once a block has been proposed and enough time has passed, the history of protocol messages can be examined to detect whether the block was finalized on time, according to the conditions given above. If the block was _not_ finalized on time, validators receive a fraction of the expected tokens, governed by the `reduced_reward_multiplier` chainspec parameter. If the block was finalized on time, assigned validators share the reward proportionally to their stake, regardless of whether they have sent messages or not.
+-->
 
 ### Inactivity {#inactivity}
 
 Validators who send no messages during an entire era are marked as inactive and cease participating in the auction until they send a special deploy that reactivates their bid.
 
+<!--TODO remove this? It is too old
 ### Slashing {#slashing}
 
 Please review our [Equivocator Policy](https://github.com/casper-network/ceps/blob/master/text/0038-equivocator-policy.md). We are currently conducting research into the utility of slashing as an incentive mechanism.
 
 ## Founding validators {#founding-validators}
 
 Founding validators are subject to token lock-up, which prevents them from withdrawing any tokens from their bids for 90 days, then releases their genesis bid tokens in weekly steps, linearly, over an additional 90 days.
+-->