Fix list presentation in rendered specifications (ethereum#4156)

Author: hara-desu

specs/_deprecated/das/p2p-interface.md

@@ -59,12 +59,14 @@ without concentrating too many requests on a single node, or breaking the networ
 ## DAS Subnets
 
 On a high level, the push-model roles are divided into:
+
 - Sources: create blobs of shard block data, and transformed into many tiny samples.
 - Sinks: continuously look for samples
 
 At full operation, the network has one proposer, per shard, per slot.
 
 In the push-model, there are:
+
 - *Vertical subnets*: Sinks can subscribe to indices of samples: there is a sample to subnet mapping.
 - *Horizontal subnets*: Sources need to distribute samples to all vertical networks: they participate in a fan-out layer.
 
@@ -115,6 +117,7 @@ TODO: define `(shard, slot, sample_index) -> subnet_index` hash function.
 To allow for subscriptions to rotate quickly and randomly, a backbone is formed to help onboard peers into other topics.
 
 This backbone is based on a pure function of the *node* identity and time:
+
 - Nodes can be found *without additional discovery overhead*:
   peers on a vertical topic can be found by searching the local peerstore for identities that hash to the desired topic(s),
   assuming the peerstore already has a large enough variety of peers.
@@ -166,6 +169,7 @@ Shard blob samples can be verified with just a 48 byte KZG proof (commitment quo
 against the commitment to blob polynomial, specific to that `(shard, slot)` key.
 
 The following validations MUST pass before forwarding the `sample` on the vertical subnet.
+
 - _[IGNORE]_ The commitment for the (`sample.shard`, `sample.slot`, `sample.index`) tuple must be known.
    If not known, the client MAY queue the sample if it passes formatting conditions.
 - _[REJECT]_ `sample.shard`, `sample.slot` and `sample.index` are hashed into a `sbunet_index` (TODO: define hash) which MUST match the topic `{subnet_index}` parameter.
@@ -214,6 +218,7 @@ Response Content:
 ```
 
 When the sample is:
+
 - Available: respond with a `Success` result code, and the encoded sample.
 - Expected to be available, but not: respond with a `ResourceUnavailable` result code.
 - Not available, but never of interest to the node: respond with an `InvalidRequest` result code.

specs/_features/eip7732/beacon-chain.md

@@ -70,6 +70,7 @@ This is the beacon chain specification of the enshrined proposer builder separat
 This feature adds new staked consensus participants called *Builders* and new honest validators duties called *payload timeliness attestations*. The slot is divided in **four** intervals. Honest validators gather *signed bids* (a `SignedExecutionPayloadHeader`) from builders and submit their consensus blocks (a `SignedBeaconBlock`) including these bids at the beginning of the slot. At the start of the second interval, honest validators submit attestations just as they do previous to this feature). At the  start of the third interval, aggregators aggregate these attestations and the builder broadcasts either a full payload or a message indicating that they are withholding the payload (a `SignedExecutionPayloadEnvelope`). At the start of the fourth interval, some validators selected to be members of the new **Payload Timeliness Committee** (PTC) attest to the presence and timeliness of the builder's payload.
 
 At any given slot, the status of the blockchain's head may be either
+
 - A block from a previous slot (e.g. the current slot's proposer did not submit its block).
 - An *empty* block from the current slot (e.g. the proposer submitted a timely block, but the builder did not reveal the payload on time).
 - A full block for the current slot (both the proposer and the builder revealed on time).

specs/_features/eip7732/p2p-interface.md

@@ -112,8 +112,9 @@ Some gossip meshes are upgraded in the fork of EIP-7732 to support upgraded type
 Topics follow the same specification as in prior upgrades.
 
 The `beacon_block` topic is updated to support the modified type
-| Name | Message Type |
-| --- | --- |
+
+| Name           | Message Type                               |
+|----------------|--------------------------------------------|
 | `beacon_block` | `SignedBeaconBlock` [modified in EIP-7732] |
 
 The new topics along with the type of the `data` field of a gossipsub message are given in this table:
@@ -162,6 +163,7 @@ The following validations MUST pass before forwarding the `signed_execution_payl
 
 Let `block` be the block with `envelope.beacon_block_root`.
 Let `header` alias `block.body.signed_execution_payload_header.message` (notice that this can be obtained from the `state.signed_execution_payload_header`)
+
 - _[REJECT]_ `block` passes validation.
 - _[REJECT]_ `envelope.builder_index == header.builder_index`
 - if `envelope.payload_withheld == False` then

specs/_features/eip7732/validator.md

@@ -81,6 +81,7 @@ Validators are still expected to propose `SignedBeaconBlock` at the beginning of
 #### Constructing the new `signed_execution_payload_header` field in  `BeaconBlockBody`
 
 To obtain `signed_execution_payload_header`, a block proposer building a block on top of a `state` must take the following actions:
+
 * Listen to the `execution_payload_header` gossip global topic and save an accepted `signed_execution_payload_header` from a builder. Proposer MAY obtain these signed messages by other off-protocol means.
 * The `signed_execution_payload_header` must satisfy the verification conditions found in `process_execution_payload_header`, that is
     - The header signature must be valid
@@ -93,6 +94,7 @@ To obtain `signed_execution_payload_header`, a block proposer building a block o
 #### Constructing the new `payload_attestations` field in  `BeaconBlockBody`
 
 Up to `MAX_PAYLOAD_ATTESTATIONS`, aggregate payload attestations can be included in the block. The validator will have to
+
 * Listen to the `payload_attestation_message` gossip global topic
 * The payload attestations added must satisfy the verification conditions found in payload attestation gossip validation and payload attestation processing. This means
     - The `data.beacon_block_root` corresponds to `block.parent_root`.
@@ -116,6 +118,7 @@ If a validator is in the payload attestation committee for the current slot (as
 according to the logic in `get_payload_attestation_message` below and broadcast it not after  `SECONDS_PER_SLOT * 3 / INTERVALS_PER_SLOT` seconds since the start of the slot, to the global `payload_attestation_message` pubsub topic.
 
 The validator creates `payload_attestation_message` as follows:
+
 * If the validator has not seen any beacon block for the assigned slot, do not submit a payload attestation. It will be ignored anyway.
 * Set `data.beacon_block_root` be the HTR of the beacon block seen for the assigned slot
 * Set `data.slot` to be the assigned slot.

specs/altair/light-client/p2p-interface.md

@@ -57,13 +57,16 @@ New global topics are added to provide light clients with the latest updates.
 This topic is used to propagate the latest `LightClientFinalityUpdate` to light clients, allowing them to keep track of the latest `finalized_header`.
 
 The following validations MUST pass before forwarding the `finality_update` on the network.
+
 - _[IGNORE]_ The `finalized_header.beacon.slot` is greater than that of all previously forwarded `finality_update`s, or it matches the highest previously forwarded slot and also has a `sync_aggregate` indicating supermajority (> 2/3) sync committee participation while the previously forwarded `finality_update` for that slot did not indicate supermajority
 - _[IGNORE]_ The `finality_update` is received after the block at `signature_slot` was given enough time to propagate through the network -- i.e. validate that one-third of `finality_update.signature_slot` has transpired (`SECONDS_PER_SLOT / INTERVALS_PER_SLOT` seconds after the start of the slot, with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance)
 
 For full nodes, the following validations MUST additionally pass before forwarding the `finality_update` on the network.
+
 - _[IGNORE]_ The received `finality_update` matches the locally computed one exactly (as defined in [`create_light_client_finality_update`](./full-node.md#create_light_client_finality_update))
 
 For light clients, the following validations MUST additionally pass before forwarding the `finality_update` on the network.
+
 - _[REJECT]_ The `finality_update` is valid -- i.e. validate that `process_light_client_finality_update` does not indicate errors
 - _[IGNORE]_ The `finality_update` advances the `finalized_header` of the local `LightClientStore` -- i.e. validate that processing `finality_update` increases `store.finalized_header.beacon.slot`
 
@@ -85,13 +88,16 @@ Per `context = compute_fork_digest(fork_version, genesis_validators_root)`:
 This topic is used to propagate the latest `LightClientOptimisticUpdate` to light clients, allowing them to keep track of the latest `optimistic_header`.
 
 The following validations MUST pass before forwarding the `optimistic_update` on the network.
+
 - _[IGNORE]_ The `attested_header.beacon.slot` is greater than that of all previously forwarded `optimistic_update`s
 - _[IGNORE]_ The `optimistic_update` is received after the block at `signature_slot` was given enough time to propagate through the network -- i.e. validate that one-third of `optimistic_update.signature_slot` has transpired (`SECONDS_PER_SLOT / INTERVALS_PER_SLOT` seconds after the start of the slot, with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` allowance)
 
 For full nodes, the following validations MUST additionally pass before forwarding the `optimistic_update` on the network.
+
 - _[IGNORE]_ The received `optimistic_update` matches the locally computed one exactly (as defined in [`create_light_client_optimistic_update`](./full-node.md#create_light_client_optimistic_update))
 
 For light clients, the following validations MUST additionally pass before forwarding the `optimistic_update` on the network.
+
 - _[REJECT]_ The `optimistic_update` is valid -- i.e. validate that `process_light_client_optimistic_update` does not indicate errors
 - _[IGNORE]_ The `optimistic_update` either matches corresponding fields of the most recently forwarded `LightClientFinalityUpdate` (if any), or it advances the `optimistic_header` of the local `LightClientStore` -- i.e. validate that processing `optimistic_update` increases `store.optimistic_header.beacon.slot`
 

specs/altair/p2p-interface.md

@@ -74,6 +74,7 @@ The specification around the creation, validation, and dissemination of messages
 
 The derivation of the `message-id` has changed starting with Altair to incorporate the message `topic` along with the message `data`. These are fields of the `Message` Protobuf, and interpreted as empty byte strings if missing.
 The `message-id` MUST be the following 20 byte value computed from the message:
+
 * If `message.data` has a valid snappy decompression, set `message-id` to the first 20 bytes of the `SHA256` hash of
   the concatenation of the following data: `MESSAGE_DOMAIN_VALID_SNAPPY`, the length of the topic byte string (encoded as little-endian `uint64`),
   the topic byte string, and the snappy decompressed message data:
@@ -192,12 +193,15 @@ Topic-meshes can be grafted quickly as the nodes are already connected and excha
 
 Messages SHOULD NOT be re-broadcast from one fork to the other.
 A node's behavior before the fork and after the fork are as follows:
+
 Pre-fork:
+
 - Peers who propagate messages on the post-fork topics MAY be scored negatively proportionally to time till fork,
   to account for clock discrepancy.
 - Messages can be IGNORED on the post-fork topics, with a `MAXIMUM_GOSSIP_CLOCK_DISPARITY` margin.
 
 Post-fork:
+
 - Peers who propagate messages on the pre-fork topics MUST NOT be scored negatively. Lagging IWANT may force them to.
 - Messages on pre and post-fork variants of topics share application-level caches.
   E.g. an attestation on the both the old and new topic is ignored like any duplicate.

specs/altair/validator.md

@@ -176,6 +176,7 @@ For this reason, *always* get committee assignments via the fields of the `Beaco
 
 A validator should plan for future sync committee assignments by noting which sync committee periods they are selected for participation.
 Specifically, a validator should:
+
 * Upon (re)syncing the chain and upon sync committee period boundaries, check for assignments in the current and next sync committee periods.
 * If the validator is in the current sync committee period, then they perform the responsibilities below for sync committee rewards.
 * If the validator is in the next sync committee period, they should wait until the next `EPOCHS_PER_SYNC_COMMITTEE_PERIOD` boundary and then perform the responsibilities throughout that period.

specs/bellatrix/p2p-interface.md

@@ -75,6 +75,7 @@ validity of the execution payload. This prevents network segregation between
 In addition to the gossip validations for this topic from prior specifications,
 the following validations MUST pass before forwarding the `signed_beacon_block` on the network.
 Alias `block = signed_beacon_block.message`, `execution_payload = block.body.execution_payload`.
+
 - If the execution is enabled for the block -- i.e. `is_execution_enabled(state, block.body)`
   then validate the following:
     - _[REJECT]_ The block's execution payload timestamp is correct with respect to the slot
@@ -87,6 +88,7 @@ Alias `block = signed_beacon_block.message`, `execution_payload = block.body.exe
     	  validation (including execution node verification of the `block.body.execution_payload`).
 
 The following gossip validation from prior specifications MUST NOT be applied if the execution is enabled for the block -- i.e. `is_execution_enabled(state, block.body)`:
+
   - [REJECT] The block's parent (defined by `block.parent_root`) passes validation.
 
 #### Transitioning the gossip

specs/capella/beacon-chain.md

@@ -46,6 +46,7 @@
 
 Capella is a consensus-layer upgrade containing a number of features related
 to validator withdrawals. Including:
+
 * Automatic withdrawals of `withdrawable` validators.
 * Partial withdrawals sweep for validators with 0x01 withdrawal
   credentials and balances in excess of `MAX_EFFECTIVE_BALANCE`.

specs/deneb/beacon-chain.md

@@ -50,6 +50,7 @@
 ## Introduction
 
 Deneb is a consensus-layer upgrade containing a number of features. Including:
+
 * [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788): Beacon block root in the EVM
 * [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844): Shard Blob Transactions scale data-availability of Ethereum in a simple, forwards-compatible manner
 * [EIP-7044](https://eips.ethereum.org/EIPS/eip-7044): Perpetually Valid Signed Voluntary Exits