Removed some TODOs

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/rewards.md

@@ -4,8 +4,6 @@ title: Rewards Design
 
 # Network Participation Rewards
 
-<!-- TODO Check existing pages describing rewards under economics. Refactor and update these pages. -->
-
 Validators receive rewards for participating in consensus and thus securing the network. Delegators also receive rewards indirectly by staking with a validator. This page serves as an introduction to how the rewards are calculated and distributed. For more details, refer to the corresponding CEP. <!-- TODO Link here to the future CEP. -->
 
 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.

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

@@ -4,9 +4,6 @@ title: Consensus
 
 # Consensus Economics
 
-<!--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}
@@ -33,6 +30,7 @@ Currently, delegation is unrestricted. Please visit [Delegation details](./staki
 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.
+
 <!--TODO Material below this needs to be reworded because the new consensus-independent rewards don't care about consensus performance directly-->
 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.
 
@@ -73,6 +71,7 @@ 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}
+
 <!--TODO Needs to be reworked in light of new rewards -->
 Validators receive rewards for proposing and finalizing blocks according to their performance. The concept of weight is crucial for understanding this distribution scheme: