Enforce 80-character line limit in all markdown files

Makefile

@@ -184,7 +184,7 @@ MARKDOWN_FILES = $(CURDIR)/README.md \
 
 # Check for mistakes.
 lint: pyspec
-	@$(MDFORMAT_VENV) --number $(MARKDOWN_FILES)
+	@$(MDFORMAT_VENV) --number --wrap=80 $(MARKDOWN_FILES)
 	@$(CODESPELL_VENV) . --skip "./.git,$(VENV),$(PYSPEC_DIR)/.mypy_cache" -I .codespell-whitelist
 	@$(PYTHON_VENV) -m black $(CURDIR)/tests
 	@$(PYTHON_VENV) -m pylint --rcfile $(PYLINT_CONFIG) $(PYLINT_SCOPE)

README.md

@@ -4,15 +4,17 @@
 [![testgen](https://github.com/ethereum/consensus-specs/actions/workflows/generate_vectors.yml/badge.svg?branch=dev&event=schedule)](https://github.com/ethereum/consensus-specs/actions/workflows/generate_vectors.yml)
 
 This repository hosts the current Ethereum
-[proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/) specifications.
-Discussions about design rationale and proposed changes can be brought up and discussed as issues.
-Solidified, agreed-upon changes to the specifications can be made through pull requests.
+[proof-of-stake](https://ethereum.org/en/developers/docs/consensus-mechanisms/pos/)
+specifications. Discussions about design rationale and proposed changes can be
+brought up and discussed as issues. Solidified, agreed-upon changes to the
+specifications can be made through pull requests.
 
 ## Specifications
 
-Core specifications for Ethereum proof-of-stake clients can be found in [specs](specs). These are
-divided into features. Features are researched and developed in parallel, and then consolidated into
-sequential upgrades when ready.
+Core specifications for Ethereum proof-of-stake clients can be found in
+[specs](specs). These are divided into features. Features are researched and
+developed in parallel, and then consolidated into sequential upgrades when
+ready.
 
 ### Stable Specifications
 
@@ -39,8 +41,8 @@ sequential upgrades when ready.
 
 ### External specifications
 
-Additional specifications and standards outside of requisite client functionality can be found in
-the following repositories:
+Additional specifications and standards outside of requisite client
+functionality can be found in the following repositories:
 
 - [Beacon APIs](https://github.com/ethereum/beacon-apis)
 - [Engine APIs](https://github.com/ethereum/execution-apis/tree/main/src/engine)
@@ -49,11 +51,11 @@ the following repositories:
 
 ### Reference tests
 
-Reference tests built from the executable Python spec are available in the [Ethereum Proof-of-Stake
-Consensus Spec Tests](https://github.com/ethereum/consensus-spec-tests) repository. Compressed
-tarballs are available for each release
-[here](https://github.com/ethereum/consensus-spec-tests/releases). Nightly reference tests are
-available
+Reference tests built from the executable Python spec are available in the
+[Ethereum Proof-of-Stake Consensus Spec Tests](https://github.com/ethereum/consensus-spec-tests)
+repository. Compressed tarballs are available for each release
+[here](https://github.com/ethereum/consensus-spec-tests/releases). Nightly
+reference tests are available
 [here](https://github.com/ethereum/consensus-specs/actions/workflows/generate_vectors.yml).
 
 ## Contributors
@@ -80,12 +82,16 @@ make help
 
 ### Design goals
 
-The following are the broad design goals for the Ethereum proof-of-stake consensus specifications:
+The following are the broad design goals for the Ethereum proof-of-stake
+consensus specifications:
 
 - Minimize complexity, even at the cost of some losses in efficiency.
-- Remain live through major network partitions and when very large portions of nodes go offline.
-- Select components that are quantum secure or easily swappable for quantum-secure alternatives.
-- Utilize crypto and design techniques that allow for a large participation of validators.
+- Remain live through major network partitions and when very large portions of
+  nodes go offline.
+- Select components that are quantum secure or easily swappable for
+  quantum-secure alternatives.
+- Utilize crypto and design techniques that allow for a large participation of
+  validators.
 - Minimize hardware requirements such that a consumer laptop can participate.
 
 ### Useful resources

specs/_deprecated/custody_game/beacon-chain.md

@@ -52,8 +52,9 @@
 
 ## Introduction
 
-This document details the beacon chain additions and changes of to support the shard data custody game,
-building upon the [Sharding](../sharding/beacon-chain.md) specification.
+This document details the beacon chain additions and changes of to support the
+shard data custody game, building upon the
+[Sharding](../sharding/beacon-chain.md) specification.
 
 ## Constants
 
@@ -219,7 +220,9 @@ class CustodyKeyReveal(Container):
 
 #### `EarlyDerivedSecretReveal`
 
-Represents an early (punishable) reveal of one of the derived secrets, where derived secrets are RANDAO reveals and custody reveals (both are part of the same domain).
+Represents an early (punishable) reveal of one of the derived secrets, where
+derived secrets are RANDAO reveals and custody reveals (both are part of the
+same domain).
 
 ```python
 class EarlyDerivedSecretReveal(Container):
@@ -251,7 +254,9 @@ def replace_empty_or_append(l: List, new_element: Any) -> int:
 
 ### `legendre_bit`
 
-Returns the Legendre symbol `(a/q)` normalizes as a bit (i.e. `((a/q) + 1) // 2`). In a production implementation, a well-optimized library (e.g. GMP) should be used for this.
+Returns the Legendre symbol `(a/q)` normalizes as a bit (i.e.
+`((a/q) + 1) // 2`). In a production implementation, a well-optimized library
+(e.g. GMP) should be used for this.
 
 ```python
 def legendre_bit(a: int, q: int) -> int:
@@ -280,7 +285,8 @@ def legendre_bit(a: int, q: int) -> int:
 
 ### `get_custody_atoms`
 
-Given one set of data, return the custody atoms: each atom will be combined with one legendre bit.
+Given one set of data, return the custody atoms: each atom will be combined with
+one legendre bit.
 
 ```python
 def get_custody_atoms(bytez: bytes) -> Sequence[bytes]:

specs/_deprecated/custody_game/validator.md

@@ -19,47 +19,77 @@
 
 ## Introduction
 
-This is an accompanying document to [Custody Game -- The Beacon Chain](./beacon-chain.md), which describes the expected actions of a "validator"
-participating in the shard data Custody Game.
+This is an accompanying document to
+[Custody Game -- The Beacon Chain](./beacon-chain.md), which describes the
+expected actions of a "validator" participating in the shard data Custody Game.
 
 ## Prerequisites
 
-This document is an extension of the [Sharding -- Validator](../sharding/validator.md). All behaviors and definitions defined in the Sharding doc carry over unless explicitly noted or overridden.
+This document is an extension of the
+[Sharding -- Validator](../sharding/validator.md). All behaviors and definitions
+defined in the Sharding doc carry over unless explicitly noted or overridden.
 
-All terminology, constants, functions, and protocol mechanics defined in the [Custody Game -- The Beacon Chain](./beacon-chain.md)
-docs are requisite for this document and used throughout. Please see the Custody Game docs before continuing and use them as a reference throughout.
+All terminology, constants, functions, and protocol mechanics defined in the
+[Custody Game -- The Beacon Chain](./beacon-chain.md) docs are requisite for
+this document and used throughout. Please see the Custody Game docs before
+continuing and use them as a reference throughout.
 
 ## Becoming a validator
 
-Becoming a validator in Custody Game is unchanged from Phase 0. See the [Phase 0 validator guide](../../phase0/validator.md#becoming-a-validator) for details.
+Becoming a validator in Custody Game is unchanged from Phase 0. See the
+[Phase 0 validator guide](../../phase0/validator.md#becoming-a-validator) for
+details.
 
 ## Beacon chain validator assignments
 
-Beacon chain validator assignments to beacon committees and beacon block proposal are unchanged from Phase 0. See the [Phase 0 validator guide](../../phase0/validator.md#validator-assignments) for details.
+Beacon chain validator assignments to beacon committees and beacon block
+proposal are unchanged from Phase 0. See the
+[Phase 0 validator guide](../../phase0/validator.md#validator-assignments) for
+details.
 
 ##### Custody slashings
 
-Up to `MAX_CUSTODY_SLASHINGS`, [`CustodySlashing`](./beacon-chain.md#custodyslashing) objects can be included in the `block`. The custody slashings must satisfy the verification conditions found in [custody slashings processing](beacon-chain.md#custody-slashings). The validator receives a small "whistleblower" reward for each custody slashing included (THIS IS NOT CURRENTLY THE CASE BUT PROBABLY SHOULD BE).
+Up to `MAX_CUSTODY_SLASHINGS`,
+[`CustodySlashing`](./beacon-chain.md#custodyslashing) objects can be included
+in the `block`. The custody slashings must satisfy the verification conditions
+found in [custody slashings processing](beacon-chain.md#custody-slashings). The
+validator receives a small "whistleblower" reward for each custody slashing
+included (THIS IS NOT CURRENTLY THE CASE BUT PROBABLY SHOULD BE).
 
 ##### Custody key reveals
 
-Up to `MAX_CUSTODY_KEY_REVEALS`, [`CustodyKeyReveal`](./beacon-chain.md#custodykeyreveal) objects can be included in the `block`. The custody key reveals must satisfy the verification conditions found in [custody key reveal processing](beacon-chain.md#custody-key-reveals). The validator receives a small reward for each custody key reveal included.
+Up to `MAX_CUSTODY_KEY_REVEALS`,
+[`CustodyKeyReveal`](./beacon-chain.md#custodykeyreveal) objects can be included
+in the `block`. The custody key reveals must satisfy the verification conditions
+found in [custody key reveal processing](beacon-chain.md#custody-key-reveals).
+The validator receives a small reward for each custody key reveal included.
 
 ##### Early derived secret reveals
 
-Up to `MAX_EARLY_DERIVED_SECRET_REVEALS`, [`EarlyDerivedSecretReveal`](./beacon-chain.md#earlyderivedsecretreveal) objects can be included in the `block`. The early derived secret reveals must satisfy the verification conditions found in [early derived secret reveal processing](beacon-chain.md#custody-key-reveals). The validator receives a small "whistleblower" reward for each early derived secret reveal included.
+Up to `MAX_EARLY_DERIVED_SECRET_REVEALS`,
+[`EarlyDerivedSecretReveal`](./beacon-chain.md#earlyderivedsecretreveal) objects
+can be included in the `block`. The early derived secret reveals must satisfy
+the verification conditions found in
+[early derived secret reveal processing](beacon-chain.md#custody-key-reveals).
+The validator receives a small "whistleblower" reward for each early derived
+secret reveal included.
 
 #### Construct attestation
 
-`attestation.data`, `attestation.aggregation_bits`, and `attestation.signature` are unchanged from Phase 0. But safety/validity in signing the message is premised upon calculation of the "custody bit" [TODO].
+`attestation.data`, `attestation.aggregation_bits`, and `attestation.signature`
+are unchanged from Phase 0. But safety/validity in signing the message is
+premised upon calculation of the "custody bit" [TODO].
 
 ## How to avoid slashing
 
-Proposer and Attester slashings described in Phase 0 remain in place with the addition of the following.
+Proposer and Attester slashings described in Phase 0 remain in place with the
+addition of the following.
 
 ### Custody slashing
 
-To avoid custody slashings, the attester must never sign any shard transition for which the custody bit is one. The custody bit is computed using the custody secret:
+To avoid custody slashings, the attester must never sign any shard transition
+for which the custody bit is one. The custody bit is computed using the custody
+secret:
 
 ```python
 def get_custody_secret(state: BeaconState,
@@ -75,5 +105,7 @@ def get_custody_secret(state: BeaconState,
     return bls.Sign(privkey, signing_root)
 ```
 
-Note that the valid custody secret is always the one for the **attestation target epoch**, not to be confused with the epoch in which the shard block was generated.
-While they are the same most of the time, getting this wrong at custody epoch boundaries would result in a custody slashing.
+Note that the valid custody secret is always the one for the **attestation
+target epoch**, not to be confused with the epoch in which the shard block was
+generated. While they are the same most of the time, getting this wrong at
+custody epoch boundaries would result in a custody slashing.

specs/_deprecated/das/das-core.md

@@ -91,8 +91,9 @@ def das_fft_extension(data: Sequence[Point]) -> Sequence[Point]:
 
 ### Data recovery
 
-See [Reed-Solomon erasure code recovery in `n*log^2(n)` time with FFTs](https://ethresear.ch/t/reed-solomon-erasure-code-recovery-in-n-log-2-n-time-with-ffts/3039) for theory.
-Implementations:
+See
+[Reed-Solomon erasure code recovery in `n*log^2(n)` time with FFTs](https://ethresear.ch/t/reed-solomon-erasure-code-recovery-in-n-log-2-n-time-with-ffts/3039)
+for theory. Implementations:
 
 - [Original Python](https://github.com/ethereum/research/blob/master/mimc_stark/recovery.py)
 - [New optimized approach in python](https://github.com/ethereum/research/tree/master/polynomial_reconstruction)

specs/_deprecated/das/fork-choice.md

@@ -11,9 +11,13 @@
 
 ## Introduction
 
-This document is the beacon chain fork choice spec for Data Availability Sampling. The only change that we add from phase 0 is that we add a concept of "data dependencies";
-a block is only eligible for consideration in the fork choice after a data availability test has been successfully completed for all dependencies.
-The "root" of a shard block for data dependency purposes is considered to be a `DataCommitment` object, which is a pair of a Kate commitment and a length.
+This document is the beacon chain fork choice spec for Data Availability
+Sampling. The only change that we add from phase 0 is that we add a concept of
+"data dependencies"; a block is only eligible for consideration in the fork
+choice after a data availability test has been successfully completed for all
+dependencies. The "root" of a shard block for data dependency purposes is
+considered to be a `DataCommitment` object, which is a pair of a Kate commitment
+and a length.
 
 ## Dependency calculation