mirror of
https://github.com/pezkuwichain/pezkuwi-subxt.git
synced 2026-07-12 22:45:49 +00:00
Markdown linter (#1309)
* Add markdown linting - add linter default rules - adapt rules to current code - fix the code for linting to pass - add CI check fix #1243 * Fix markdown for Substrate * Fix tooling install * Fix workflow * Add documentation * Remove trailing spaces * Update .github/.markdownlint.yaml Co-authored-by: Oliver Tale-Yazdi <oliver.tale-yazdi@parity.io> * Fix mangled markdown/lists * Fix captalization issues on known words
This commit is contained in:
@@ -1,14 +1,26 @@
|
||||
# Availability Cores
|
||||
|
||||
Yields information on all availability cores. Cores are either free or occupied. Free cores can have paras assigned to them. Occupied cores don't, but they can become available part-way through a block due to bitfields and then have something scheduled on them. To allow optimistic validation of candidates, the occupied cores are accompanied by information on what is upcoming. This information can be leveraged when validators perceive that there is a high likelihood of a core becoming available based on bitfields seen, and then optimistically validate something that would become scheduled based on that, although there is no guarantee on what the block producer will actually include in the block.
|
||||
Yields information on all availability cores. Cores are either free or occupied. Free cores can have paras assigned to
|
||||
them. Occupied cores don't, but they can become available part-way through a block due to bitfields and then have
|
||||
something scheduled on them. To allow optimistic validation of candidates, the occupied cores are accompanied by
|
||||
information on what is upcoming. This information can be leveraged when validators perceive that there is a high
|
||||
likelihood of a core becoming available based on bitfields seen, and then optimistically validate something that would
|
||||
become scheduled based on that, although there is no guarantee on what the block producer will actually include in the
|
||||
block.
|
||||
|
||||
See also the [Scheduler Module](../runtime/scheduler.md) for a high-level description of what an availability core is and why it exists.
|
||||
See also the [Scheduler Module](../runtime/scheduler.md) for a high-level description of what an availability core is
|
||||
and why it exists.
|
||||
|
||||
```rust
|
||||
fn availability_cores(at: Block) -> Vec<CoreState>;
|
||||
```
|
||||
|
||||
This is all the information that a validator needs about scheduling for the current block. It includes all information on [Scheduler](../runtime/scheduler.md) core-assignments and [Inclusion](../runtime/inclusion.md) state of blocks occupying availability cores. It includes data necessary to determine not only which paras are assigned now, but which cores are likely to become freed after processing bitfields, and exactly which bitfields would be necessary to make them so. The implementation of this runtime API should invoke `Scheduler::clear` and `Scheduler::schedule(Vec::new(), current_block_number + 1)` to ensure that scheduling is accurate.
|
||||
This is all the information that a validator needs about scheduling for the current block. It includes all information
|
||||
on [Scheduler](../runtime/scheduler.md) core-assignments and [Inclusion](../runtime/inclusion.md) state of blocks
|
||||
occupying availability cores. It includes data necessary to determine not only which paras are assigned now, but which
|
||||
cores are likely to become freed after processing bitfields, and exactly which bitfields would be necessary to make them
|
||||
so. The implementation of this runtime API should invoke `Scheduler::clear` and `Scheduler::schedule(Vec::new(),
|
||||
current_block_number + 1)` to ensure that scheduling is accurate.
|
||||
|
||||
```rust
|
||||
struct OccupiedCore {
|
||||
|
||||
Reference in New Issue
Block a user