Merge pull request #1434 from ipopescu/1426_cleanup

1426 Cleanup old Highway and rewards references

source/docs/casper/concepts/about.md

@@ -5,7 +5,7 @@ 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 [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).
 

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

@@ -6,8 +6,6 @@ title: Highway Consensus
 
 The [Highway](https://arxiv.org/pdf/2101.02159.pdf) consensus protocol was used on the Casper Mainnet until the [Zug](./zug.md) consensus protocol was introduced in version 2.0 of the Casper node software. Consensus in Casper is described in more detail [here](./consensus.md). This page describes the Highway consensus protocol at a high level. Private networks can choose between Zug and Highway, depending on their needs.
 
-<!-- TODO confirm that we can use Casper-specific terms in these descriptions, even though Highway is a more general algorithm. For example, a value is a block. I understand that the value is a list of deploys, and a block has other calculated values, but this simplification makes the explanations easier. -->
-
 ## Unit Broadcasting
 
 In Highway, nodes communicate by broadcasting units. A unit is a structure containing the following:
@@ -20,7 +18,6 @@ An empty unit still carries an implicit vote. The citations determine which bloc
 
 Over time, the units form a Directed Acyclic Graph (DAG), where units are the vertices and citations are the edges.
 
-<!-- TODO Include a higher res diagram here. -->
 <p align="center">
 <img src={"/image/design/highway-dag.png"} alt="Image showing the DAG" width="600"/>
 </p>

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/economics/consensus.md

@@ -4,9 +4,9 @@ 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.
+[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}
+## Validator Selection {#selection}
 
 After genesis, the system selects a set of validators using a stake auction process. The auction takes place in the last block of an era, also called a switch block. An auction contract governs the validator selection process, and a _chainspec_ configuration file specifies a few key parameters:
 
@@ -27,15 +27,15 @@ 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.
+The correct operation of the consensus protocol requires the platform's economics 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.
 
-The network incentivizes participation by scaling rewards for on-time proposals and responses, taking into account the speed of finalizing blocks. All rewards are added directly to the corresponding bids and delegations.
+The network incentivizes participation by issuing [rewards](../design/rewards.md) to validators for proposing blocks and creating and publishing finality signatures. Delegators also receive rewards by [staking](./staking/concepts.md) with a validator. All rewards are added directly to the corresponding bids and delegations.
 
-### Participation {#participation}
+### Validator Participation {#participation}
 
-Issuance of new tokens and their distribution to validators incentivizes work even under low transaction load.
+The issuance of new tokens and their distribution to validators incentivizes participation even when there is a low transaction load.
 
 CSPR is issued at a fixed rate and distributed to validators (and, indirectly, delegators) in proportion to their stake. This is analogous to block rewards in Proof-of-Work blockchains, outlining the following:
 
@@ -69,36 +69,30 @@ base_round_reward(i) = round_issuance_rate * supply(i)
 
 This value gives us the maximum amount of CSPR that the validators can collectively receive from a proposed block.
 
-#### Distribution {#distribution}
+### Rewards 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 blocks and creating and publishing finality signatures. Each round has a reward pool, mostly allocated toward creating and publishing finality signatures. There is also a small portion of rewards allocated to the block proposals.
 
--   **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
+The concept of validator weight is crucial in understanding the distribution scheme:
 
-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.
+- **Weight:** A validator's bonded stake, which affects rewards distribution since rewards are proportional to a validator's weight on average
+- **Assigned weight of a round:** The total weight of validators scheduled to participate in a round
+- **Participated weight of a round:** The total weight of validators that participated or sent messages before the end of the round
+- **Relative weight**: A validator's weight relative to the total validator weight that participated in a 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.
+The rewards allocated for finality signatures are split between creating and publishing the signatures. These rewards are proportional to the weight of the signing validators for both the signers and the finders. A finder's fee determines how the split happens. To summarize:
 
-##### Participation schedule {#participation-schedule}
+- For each finalized block, there is a fraction of rewards due for signature creation and collection
+- Signature rewards are split between the finder (block proposer) and the signature creators
+- The signature creators get a part of the signature reward pot due for the block: `(1 - finder's fee) * relative weight`
+- The finder gets a small reward as well to incentivize collecting and reporting all the signatures: `finder's fee * total relative weight of signatures collected`
 
-The participation schedule is segmented into rounds, which are allocated dynamically according to the validators' exponents and a deterministic (randomized at era start) assignment of validators to milliseconds of an era. Thus, a validator with the round exponent `n` must participate in rounds that repeat every `2^n` ticks.
+The rewards calculation takes place at the end of an era. In addition to rewarding everything in that era, the algorithm also looks back into blocks from the previous era to compensate for the delay in creating and distributing finality signatures. Review the [Rewards Design](../design/rewards.md) page for more details.
 
-Each validator is assessed according to its round exponent. All assigned validators become eligible to receive tokens as long as the block gets finalized with messages sent within each validator's round.
+### Validator Inactivity {#inactivity}
 
-##### Eligibility {#eligibility}
+Validators who send no messages during an entire era are marked as inactive and cease participating in the auction until they send a special transaction that reactivates their bid.
 
-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.
+## Founding Validators {#founding-validators}
 
-### 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.
-
-### 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.
+When launching a new Casper network, founding validators are subject to token lock-up, which prevents them from withdrawing any tokens from their bids for 90 days. Then, the network releases their genesis bid tokens in weekly steps, linearly, over an additional 90 days.