Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

Commit

Permalink
First round of implementers guide fixes (#6146)
Browse files Browse the repository at this point in the history
  • Loading branch information
BradleyOlson64 authored Oct 13, 2022
1 parent 4ac7d94 commit e307a26
Show file tree
Hide file tree
Showing 4 changed files with 7 additions and 7 deletions.
2 changes: 1 addition & 1 deletion roadmap/implementers-guide/src/disputes-flow.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
2 changes: 1 addition & 1 deletion roadmap/implementers-guide/src/protocol-chain-selection.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
2 changes: 1 addition & 1 deletion roadmap/implementers-guide/src/runtime/configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ The session change routine works as follows:
## Routines

```rust
enum InconsistentErrror {
enum InconsistentError {
// ...
}

Expand Down
8 changes: 4 additions & 4 deletions roadmap/implementers-guide/src/runtime/paras.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
///
Expand Down Expand Up @@ -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

Expand Down Expand Up @@ -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`.

0 comments on commit e307a26

Please sign in to comment.