Merge pull request #695 from laboon/patch-3

Various minor fixes to block production page

docs/sect-block-production.md

@@ -13,7 +13,7 @@ import buildBlock from '!!raw-loader!@site/src/algorithms/buildBlock.tex';
 
 ## -sec-num- Introduction {#id-introduction-3}
 
-The Polkadot Host uses BABE protocol for block production. It is designed based on Ouroboros praos. BABE execution happens in sequential non-overlapping phases known as an ***epoch***. Each epoch is divided into a predefined number of slots. All slots in each epoch are sequentially indexed starting from 0. At the beginning of each epoch, the BABE node needs to run [Block-Production-Lottery](sect-block-production#algo-block-production-lottery) to find out in which slots it should produce a block and gossip to the other block producers. In turn, the block producer node should keep a copy of the block tree and grow it as it receives valid blocks from other block producers. A block producer prunes the tree in parallel by eliminating branches that do not include the most recently finalized blocks ([Definition -def-num-ref-](chap-state#defn-pruned-tree)).
+The Polkadot Host uses BABE protocol for block production. It is designed based on [Ouroboros Praos](https://eprint.iacr.org/2017/573.pdf). BABE execution happens in sequential non-overlapping phases known as an ***epoch***. Each epoch is divided into a predefined number of slots. All slots in each epoch are sequentially indexed starting from 0. At the beginning of each epoch, the BABE node needs to run [Block-Production-Lottery](sect-block-production#algo-block-production-lottery) to find out in which slots it should produce a block and gossip to the other block producers. In turn, the block producer node should keep a copy of the block tree and grow it as it receives valid blocks from other block producers. A block producer prunes the tree in parallel by eliminating branches that do not include the most recently finalized blocks ([Definition -def-num-ref-](chap-state#defn-pruned-tree)).
 
 ### -sec-num- Block Producer {#id-block-producer}
 
@@ -29,7 +29,7 @@ A **block producer**, noted by ${\mathcal{{P}}}_{{j}}$, is a node running the Po
 A block production **epoch**, formally referred to as ${\mathcal{{E}}}$, is a period with a pre-known starting time and fixed-length during which the set of block producers stays constant. Epochs are indexed sequentially, and we refer to the ${n}^{{{t}{h}}}$ epoch since genesis by ${\mathcal{{E}}}_{{n}}$. Each epoch is divided into equal-length periods known as block production **slots**, sequentially indexed in each epoch. The index of each slot is called a **slot number**. The equal length duration of each slot is called the **slot duration** and indicated by ${\mathcal{{T}}}$. Each slot is awarded to a subset of block producers during which they are allowed to generate a block.
 
 :::info
-Substrate refers to an epoch as a "session" in some places. However, epoch should be the preferred and official name for these periods. |
+Substrate refers to an epoch as a "session" in some places. However, epoch should be the preferred and official name for these periods.
 :::
 
 ::::
@@ -89,9 +89,9 @@ $$
 :::
 ## -sec-num- Block Production Lottery {#sect-block-production-lottery}
 
-The babe constant ([Definition -def-num-ref-](sect-block-production#defn-babe-constant)) is initialized at genesis to the value returned by calling `BabeApi_configuration` ([Section -sec-num-ref-](chap-runtime-api#sect-rte-babeapi-epoch)). For efficiency reasons, it is generally updated by the Runtime through the *next config data* consensus message in the digest ([Definition -def-num-ref-](chap-state#defn-digest)) of the first block of an epoch for the next epoch.
+The BABE constant ([Definition -def-num-ref-](sect-block-production#defn-babe-constant)) is initialized at genesis to the value returned by calling `BabeApi_configuration` ([Section -sec-num-ref-](chap-runtime-api#sect-rte-babeapi-epoch)). For efficiency reasons, it is generally updated by the Runtime through the *next config data* consensus message in the digest ([Definition -def-num-ref-](chap-state#defn-digest)) of the first block of an epoch for the next epoch.
 
-A block producer aiming to produce a block during ${\mathcal{{E}}}_{{n}}$ should run \<algo-block-production-lottery\>\> to identify the slots it is awarded. These are the slots during which the block producer is allowed to build a block. The ${s}{k}$ is the block producer lottery secret key and ${n}$ is the index of the epoch for whose slots the block producer is running the lottery.
+A block producer aiming to produce a block during ${\mathcal{{E}}}_{{n}}$ should run ([Block-Production-Lottery](sect-block-production#algo-block-production-lottery)) to identify the slots it is awarded. These are the slots during which the block producer is allowed to build a block. The ${s}{k}$ is the block producer lottery secret key and ${n}$ is the index of the epoch for whose slots the block producer is running the lottery.
 
 In order to ensure consistent block production, BABE uses secondary slots in case no authority wins the (primary) block production lottery. Unlike the lottery, secondary slot assignees are known upfront publically ([Definition -def-num-ref-](sect-block-production#defn-babe-secondary-slots)). The Runtime provides information on how or if secondary slots are executed ([Section -sec-num-ref-](chap-runtime-api#sect-rte-babeapi-epoch)), explained further in [Definition -def-num-ref-](sect-block-production#defn-babe-secondary-slots).
 
@@ -212,7 +212,7 @@ It is imperative for the security of the network that each block producer correc
 
 Polkadot does this synchronization without relying on any external clock source (e.g., through the or the ). To stay in synchronization, each producer is therefore required to periodically estimate its local clock offset in relation to the rest of the network.
 
-This estimation depends on the two fixed parameters ${k}$ ([Definition -def-num-ref-](sect-block-production#defn-prunned-best)) and ${s}_{{{c}{q}}}$ ([Definition -def-num-ref-](sect-block-production#defn-chain-quality)). These are chosen based on the results of a [formal security analysis](https://research.web3.foundation/Polkadot/protocols/block-production/Babe#5-security-analysis), currently assuming a ${1}{s}$ clock drift per day and targeting a probability lower than ${0.5}\%$ for an adversary to break BABE in 3 years with resistance against a network delay up to $\frac{{1}}{{3}}$ of the slot time and a Babe constant ([Definition -def-num-ref-](sect-block-production#defn-babe-constant)) of ${c}={0.38}$.
+This estimation depends on the two fixed parameters ${k}$ ([Definition -def-num-ref-](sect-block-production#defn-prunned-best)) and ${s}_{{{c}{q}}}$ ([Definition -def-num-ref-](sect-block-production#defn-chain-quality)). These are chosen based on the results of a [formal security analysis](https://research.web3.foundation/Polkadot/protocols/block-production/Babe#5-security-analysis), currently assuming a ${1}{s}$ clock drift per day and targeting a probability lower than ${0.5}\%$ for an adversary to break BABE in 3 years with resistance against a network delay up to $\frac{{1}}{{3}}$ of the slot time and a BABE constant ([Definition -def-num-ref-](sect-block-production#defn-babe-constant)) of ${c}={0.38}$.
 
 All validators are then required to run [Median-Algorithm](sect-block-production#algo-median-algorithm) at the beginning of each sync period ([Definition -def-num-ref-](sect-block-production#defn-sync-period)) to update their synchronization using all block arrival times of the previous period. The algorithm should only be run once all the blocks in this period have been finalized, even if only probabilistically ([Definition -def-num-ref-](sect-block-production#defn-prunned-best)). The target slot to which to synchronize should be the first slot in the new sync period.