First Round of Implementers Guide Fixes

roadmap/implementers-guide/src/disputes-flow.md

@@ -96,7 +96,7 @@ Votes must be queryable by a particular validator, identified by its signing key
 
 Votes must be queryable by a particular validator, identified by a session index and the validator index valid in that session.
 
-If there exists a negative and a positive fork for a particular block, a dispute is detected.
+If there exists a negative and a positive vote for a particular block, a dispute is detected.
 
 If a dispute is detected, all currently available votes for that block must be gossiped.
 

roadmap/implementers-guide/src/protocol-chain-selection.md

@@ -43,6 +43,6 @@ The leaf-selection rule based on our definitions above is simple: we take the ma
 Finality gadgets, as mentioned above, will often impose an additional requirement to vote on a chain containing a specific block, known as the **required** block. Although this is typically the most recently finalized block, it is possible that it may be a block that is unfinalized. When receiving such a request:
 1. If the required block is the best finalized block, then select the best viable leaf.
 2. If the required block is unfinalized and non-viable, then select the required block and go no further. This is likely an indication that something bad will be finalized in the network, which will never happen when approvals & disputes are functioning correctly. Nevertheless we account for the case here.
-3. If the required block is unfinalized and non-viable, then iterate over the viable leaves in descending order by score and select the first one which contains the required block in its chain. Backwards iteration is a simple way to check this, but if unfinalized chains grow long then Merkle Mountain-Ranges will most likely be more efficient.
+3. If the required block is unfinalized and viable, then iterate over the viable leaves in descending order by score and select the first one which contains the required block in its chain. Backwards iteration is a simple way to check this, but if unfinalized chains grow long then Merkle Mountain-Ranges will most likely be more efficient.
 
 Once selecting a leaf, the chain should be constrained to the maximum of the required block or the highest **finalizable** ancestor.

roadmap/implementers-guide/src/runtime/configuration.md

@@ -28,7 +28,7 @@ The session change routine works as follows:
 ## Routines
 
 ```rust
-enum InconsistentErrror {
+enum InconsistentError {
  // ...
 }
 

roadmap/implementers-guide/src/runtime/paras.md

@@ -172,7 +172,7 @@ PastCodePruning: Vec<(ParaId, BlockNumber)>;
 /// The change will be applied after the first parablock for this ID included which executes
 /// in the context of a relay chain block with a number >= `expected_at`.
 FutureCodeUpgrades: map ParaId => Option<BlockNumber>;
-/// The actual future code of a para.
+/// Hash of the actual future code of a para.
 FutureCodeHash: map ParaId => Option<ValidationCodeHash>;
 /// This is used by the relay-chain to communicate to a parachain a go-ahead with in the upgrade procedure.
 ///
@@ -246,8 +246,8 @@ CodeByHash: map ValidationCodeHash => Option<ValidationCode>
 1. Do pruning based on all entries in `PastCodePruning` with `BlockNumber <= now`. Update the
  corresponding `PastCodeMeta` and `PastCode` accordingly.
 1. Toggle the upgrade related signals
- 1. Collect all `(para_id, expected_at)` from `UpcomingUpgrades` where `expected_at <= now` and prune them. For each para pruned set `UpgradeGoAheadSignal` to `GoAhead`.
- 1. Collect all `(para_id, next_possible_upgrade_at)` from `UpgradeCooldowns` where `next_possible_upgrade_at <= now` and prune them. For each para pruned set `UpgradeRestrictionSignal` to `Present`.
+ 1. Collect all `(para_id, expected_at)` from `UpcomingUpgrades` where `expected_at <= now` and prune them. For each para pruned set `UpgradeGoAheadSignal` to `GoAhead`. Reserve weight for the state modification to upgrade each para pruned.
+ 1. Collect all `(para_id, next_possible_upgrade_at)` from `UpgradeCooldowns` where `next_possible_upgrade_at <= now`. For each para obtained this way reserve weight to remove its `UpgradeRestrictionSignal` on finalization.
 
 ## Routines
 
@@ -275,4 +275,4 @@ In case the PVF pre-checking is enabled, or the new code is not already present
 
 ## Finalization
 
-No finalization routine runs for this module.
+Collect all `(para_id, next_possible_upgrade_at)` from `UpgradeCooldowns` where `next_possible_upgrade_at <= now` and prune them. For each para pruned remove its `UpgradeRestrictionSignal`.