chore(fmt): lint

.prettierrc.js

@@ -14,7 +14,7 @@ module.exports = {
       files: '*.md',
       options: {
         parser: 'markdown',
-        printWidth: 80,
+        printWidth: 120,
         proseWrap: 'always',
         tabWidth: 4,
         useTabs: true,

cspell.json

@@ -2,6 +2,7 @@
   "version": "0.2",
   "language": "en",
   "words": [
+    "blockspace",
     "bool",
     "uint",
     "uint8",
@@ -143,7 +144,6 @@
     "manifoldfinance",
     "manifoldx",
     "mathjax",
-    "meveth",
     "mkdocs",
     "multicall",
     "pathfile",
@@ -162,6 +162,11 @@
     "nixops",
     "alphanum",
     "clsx",
-    "copyof"
+    "copyof",
+    "permissioned",
+    "Ausubel",
+    "Licalzi",
+    "Calzi",
+    "gantt"
   ]
 }

docs/Clients/accounting.md

@@ -4,26 +4,23 @@ title: Accounting and Rewards
 
 ## Payment processing and finalization
 
-Builder payments are processed during the epoch finalization process (a
-two-epoch lag).
+Builder payments are processed during the epoch finalization process (a two-epoch lag).
 
--   The builder `ExecutionPayloadHeader` is part of the canonical chain (i.e.,
-    the CL block for that slot is not missing). This includes two cases: The
-    corresponding `ExecutionPayload` MUST also part of the canonical chain.
+-   The builder `ExecutionPayloadHeader` is part of the canonical chain (i.e., the CL block for that slot is not
+    missing). This includes two cases: The corresponding `ExecutionPayload` MUST also part of the canonical chain.
 
--   The builder `ExecutionPayloadHeader` is part of the canonical chain even if
-    the corresponding `ExecutionPayload` is not.
+-   The builder `ExecutionPayloadHeader` is part of the canonical chain even if the corresponding `ExecutionPayload` is
+    not.
 
-This means that there is consensus that the builder was not on time by virtue of
-having an empty block. However, this may be intentional in the mutli-block
-auction scenario so is subject to change
+This means that there is consensus that the builder was not on time by virtue of having an empty block. However, this
+may be intentional in the mutli-block auction scenario so is subject to change
 
 ### Proposer equivocation
 
 There is no evidence of proposer equivocation.
 
--   A builder who sees an equivocation can get the validator slashed. Any
-    slashed validator will not receive the unconditional builder payment.
+-   A builder who sees an equivocation can get the validator slashed. Any slashed validator will not receive the
+    unconditional builder payment.
 
 ## Builder Payment Methods
 
@@ -33,22 +30,19 @@ Builder payment patterns in the context of MEV payments to the validators
 
 ### Indirect Address Payment (IAP) Method
 
-This method involves the builder using a different address to pay the proposer
-through an end-of-block transaction. In this pattern, the builder first sets its
-own address to receive the block’s transaction fees and then employs a different
-address to remunerate the proposer in the end-of-block transaction.
+This method involves the builder using a different address to pay the proposer through an end-of-block transaction. In
+this pattern, the builder first sets its own address to receive the block’s transaction fees and then employs a
+different address to remunerate the proposer in the end-of-block transaction.
 
 ### Intermediate Transfer Payment (ITP) Method
 
-In this method, the builder pays the proposer through an end-of-block
-transaction, initially transferring the amount to an alternate address, which
-then initiates an internal transaction to send the funds to the proposer. This
-involves a two-step process where the payment is first sent to an intermediary
-address (like a smart contract) before reaching the proposer.
+In this method, the builder pays the proposer through an end-of-block transaction, initially transferring the amount to
+an alternate address, which then initiates an internal transaction to send the funds to the proposer. This involves a
+two-step process where the payment is first sent to an intermediary address (like a smart contract) before reaching the
+proposer.
 
 ## Proposer Payments Value (PPV)
 
-The `feeReceipent` address is configured in the consensus layer client and is
-provided by the NO at the time of the block proposal. Because the eth1 address
-that is provided for the feeReceipent is under the complete control of the NO,
+The `feeReceipent` address is configured in the consensus layer client and is provided by the NO at the time of the
+block proposal. Because the eth1 address that is provided for the feeReceipent is under the complete control of the NO,
 there is an opportunity for a NO to steal all the PPV for themselves.

docs/Clients/clients.md

@@ -6,26 +6,22 @@ title: Clients
 
 What is the Etheruem network?[^1]
 
--   A user of the network sends a transaction (e.g. an ETH transfer) to the
-    network.
+-   A user of the network sends a transaction (e.g. an ETH transfer) to the network.
 -   The network validates the transaction.
 -   The network includes the transaction in a block.
--   The network includes the block in the chain, so the new state includes the
-    transaction sent by the user. Any user can request this information and the
-    change will be reflected.
+-   The network includes the block in the chain, so the new state includes the transaction sent by the user. Any user
+    can request this information and the change will be reflected.
 
 The problem here is: what does sending something to the network mean?
 
 ## Execution and Consensus clients
 
 A full node is split into two clients:
 
--   **The execution client** knows how to represent the EVM state and apply
-    state changes (transactions) to generate new states. It represents the state
-    machine.
--   **The consensus client** knows very little about the state machine, but
-    knows how to choose between different worldviews and agree with other nodes.
-    It enables the execution client to apply the correct state transitions.
+-   **The execution client** knows how to represent the EVM state and apply state changes (transactions) to generate new
+    states. It represents the state machine.
+-   **The consensus client** knows very little about the state machine, but knows how to choose between different
+    worldviews and agree with other nodes. It enables the execution client to apply the correct state transitions.
 
 ```mermaid
 graph BT
@@ -55,67 +51,54 @@ linkStyle 2 stroke:#ff0000,stroke-width:2px;
 linkStyle 3 stroke:#ff0000,stroke-width:2px;
 ```
 
-You might notice there's a section called "validator" in there, with red arrows.
-Your node is considered a validator if it has 32 ETH staked in the validator
-contract, which makes it capable of proposing new blocks and attesting to other
-proposals. That is: actively participating in the protocol and getting rewards
-for it.
+You might notice there's a section called "validator" in there, with red arrows. Your node is considered a validator if
+it has 32 ETH staked in the validator contract, which makes it capable of proposing new blocks and attesting to other
+proposals. That is: actively participating in the protocol and getting rewards for it.
 
-If you're not a validator you can still participate though! The block diagram is
-the same, without the red lines (and you won't receive rewards for it). You can
-still send transactions to your local node, propagate them to others, and
+If you're not a validator you can still participate though! The block diagram is the same, without the red lines (and
+you won't receive rewards for it). You can still send transactions to your local node, propagate them to others, and
 receive updates.
 
 ## Lifecycle of a transaction
 
 Here's the full sequence from the perspective of a non-validator node:
 
-1. A user builds, signs, and sends a transaction to their execution client's
-   JSON-RPC API. This is usually done with a wrapper library like `ethers`,
-   `hardhat`, or `foundry`.
+1. A user builds, signs, and sends a transaction to their execution client's JSON-RPC API. This is usually done with a
+   wrapper library like `ethers`, `hardhat`, or `foundry`.
 
 2. The execution client receives the transaction and:
 
-    1. Validates it (checks the user has enough ETH, the signature matches,
-       etc).
+    1. Validates it (checks the user has enough ETH, the signature matches, etc).
 
-    2. Adds it to its local mempool. The mempool is a local pool of transactions
-       that are not yet executed.
+    2. Adds it to its local mempool. The mempool is a local pool of transactions that are not yet executed.
 
-    3. Broadcasts it through the execution gossip layer, to other execution
-       nodes. Other execution nodes include it in their mempools.
+    3. Broadcasts it through the execution gossip layer, to other execution nodes. Other execution nodes include it in
+       their mempools.
 
 3. A validator node is selected as a block proposer. As a proposer:
 
-    1. Their execution client bundles many transactions from its mempool into a
-       block.
+    1. Their execution client bundles many transactions from its mempool into a block.
 
-    2. All transactions in the bundle are executed locally and state change is
-       calculated.
+    2. All transactions in the bundle are executed locally and state change is calculated.
 
-    3. Their consensus client gets this block (or as consensus calls it,
-       "execution payload") and adds consensus layer information, like
-       attestations, slashings, rewards, penalties, etc. The execution payload +
-       consensus metadata forms a "beacon block".
-    4. The beacon block is signed and sent over the consensus gossip layer to
-       other nodes.
+    3. Their consensus client gets this block (or as consensus calls it, "execution payload") and adds consensus layer
+       information, like attestations, slashings, rewards, penalties, etc. The execution payload + consensus metadata
+       forms a "beacon block".
+    4. The beacon block is signed and sent over the consensus gossip layer to other nodes.
 
-4. A committee of validators validates that block and sends signed attestations
-   for it over the consensus gossip protocol too.
+4. A committee of validators validates that block and sends signed attestations for it over the consensus gossip
+   protocol too.
 
 5. All nodes receive both the new proposed block and attestations. Then they:
     1. Include the new block in their local fork tree if it's valid.
     2. Save the attestations and update the weights of the blocks on the tree.
-    3. Apply fork choice to recalculate, if necessary, what blocks are included
-       in the canonical chain.
-    4. The changes + the new block are propagated to the execution node so
-       transactions are applied and the state is changed and up to date.
+    3. Apply fork choice to recalculate, if necessary, what blocks are included in the canonical chain.
+    4. The changes + the new block are propagated to the execution node so transactions are applied and the state is
+       changed and up to date.
 
 [^1]:
 
-The Ethereum network is not a networked database: It's a series of tubes. And if
-you don't understand, those tubes can be filled and if they are filled, when you
-put your message in, it gets in line and it's going to be delayed by anyone that
-puts into that tube enormous amounts of material, enormous amounts of material.
-Ted Stevens (2024) Wikipedia. Available at:
-https://en.wikipedia.org/wiki/Ted_Stevens (Accessed: 03 April 2024).
+The Ethereum network is not a networked database: It's a series of tubes. And if you don't understand, those tubes can
+be filled and if they are filled, when you put your message in, it gets in line and it's going to be delayed by anyone
+that puts into that tube enormous amounts of material, enormous amounts of material. Ted Stevens (2024) Wikipedia.
+Available at: https://en.wikipedia.org/wiki/Ted_Stevens (Accessed: 03 April 2024).

docs/Clients/configuration.md

@@ -5,9 +5,8 @@ description: Mandatory values, settings and settings.
 
 ## Mandatory Values for Validator and Beacon clients
 
-**LocalBlockValueBoost** is the value boost for local block construction. This
-is used to prioritize local block construction over relay/builder block
-construction.
+**LocalBlockValueBoost** is the value boost for local block construction. This is used to prioritize local block
+construction over relay/builder block construction.
 
 ```toml
 LocalBlockValueBoost = 0

docs/Clients/index.md

@@ -9,13 +9,12 @@ title: Validators
 
 ## Protections
 
-Node Operators are being provided with a tailored risk management solution that
-addresses the unique challenges and risks of participating through the relay.
+Node Operators are being provided with a tailored risk management solution that addresses the unique challenges and
+risks of participating through the relay.
 
 > Read more at [Relay: Captive Insurance](../Relay/captive-insurance.md)
 
-This is a block diagram of all the parts of the system and will be updated as
-needed.
+This is a block diagram of all the parts of the system and will be updated as needed.
 
 ```mermaid
 graph LR
@@ -45,23 +44,20 @@ VALIDATOR --> BAPI
 
 ## Networking
 
-The main entry for new events is the gossip protocol, which is how consensus
-nodes communicates with other consensus nodes.
+The main entry for new events is the gossip protocol, which is how consensus nodes communicates with other consensus
+nodes.
 
-1. Discovery: our node has a series of known `bootnodes` hardcoded. We request a
-   list of the nodes they know about and add them to our list. We save them
-   locally and now can use those too to request new nodes.
+1. Discovery: our node has a series of known `bootnodes` hardcoded. We request a list of the nodes they know about and
+   add them to our list. We save them locally and now can use those too to request new nodes.
 
-2. Message propagation. When a proposer sends a new block, or validators attest
-   for a new block, they send those to other known nodes. Those, in turn,
-   propagate the messages sent to other nodes. This process is repeated until,
+2. Message propagation. When a proposer sends a new block, or validators attest for a new block, they send those to
+   other known nodes. Those, in turn, propagate the messages sent to other nodes. This process is repeated until,
    ideally, the whole network receives the messages.
 
 ## Gossipsub
 
-One of the main communication protocols is GossipSub. This allows us to tell
-peers which topics we're interested in and receive events for them. The main
-external events we react to are blocks and attestations.
+One of the main communication protocols is GossipSub. This allows us to tell peers which topics we're interested in and
+receive events for them. The main external events we react to are blocks and attestations.
 
 ### Receiving an attestation
 
@@ -81,18 +77,14 @@ sequenceDiagram
 ```
 
 When receiving an attestation, it's processed by the
-[on_attestation](https://eth2book.info/capella/annotated-spec/#on_attestation)
-callback. We just validate it and send it to the fork choice store to update its
-weights and target checkpoints. The attestation is only processed if this
-attestation is the latest message by that validator. If there's a newer one, it
-should be discarded.
-
-The most relevant piece of the spec here is the
-[get_weight](https://eth2book.info/capella/annotated-spec/#get_weight) function,
-which is the core of the fork-choice algorithm. In the specs, this function is
-called on demand, when calling
-[get_head](https://eth2book.info/capella/annotated-spec/#get_head), works with
-the store's values, and recalculates them each time.
+[on_attestation](https://eth2book.info/capella/annotated-spec/#on_attestation) callback. We just validate it and send it
+to the fork choice store to update its weights and target checkpoints. The attestation is only processed if this
+attestation is the latest message by that validator. If there's a newer one, it should be discarded.
+
+The most relevant piece of the spec here is the [get_weight](https://eth2book.info/capella/annotated-spec/#get_weight)
+function, which is the core of the fork-choice algorithm. In the specs, this function is called on demand, when calling
+[get_head](https://eth2book.info/capella/annotated-spec/#get_head), works with the store's values, and recalculates them
+each time.
 
 !!! important
 
@@ -133,12 +125,10 @@ sequenceDiagram
 Receiving a block is more complex:
 
 -   The block itself needs to be stored.
--   The state transition needs to be applied, a new beacon state calculated, and
-    stored separately.
+-   The state transition needs to be applied, a new beacon state calculated, and stored separately.
 -   A new node needs to be added to the block tree aside from updating weights.
 -   on_attestation needs to be called for each attestation.
 
-Also, there's a more complex case: we can only include a block in the fork tree
-if we know of its parents and their connection with our current finalized
-checkpoint. If we receive a disconnected node, we'll need to use
-Request-Response to ask peers for the missing blocks.
+Also, there's a more complex case: we can only include a block in the fork tree if we know of its parents and their
+connection with our current finalized checkpoint. If we receive a disconnected node, we'll need to use Request-Response
+to ask peers for the missing blocks.

docs/Clients/relay.md

@@ -6,16 +6,14 @@ title: Relay
 
 proposer payout: empty block, 0; non empty block, non-negative value < 0
 
-Once a proposer calls `submitBlindedBlock` to a relay (with a signed header), it
-depends on the relay to release the block to be able to propose anything (no
-fallback to a local block is possible at that point due to possible slashing).
+Once a proposer calls `submitBlindedBlock` to a relay (with a signed header), it depends on the relay to release the
+block to be able to propose anything (no fallback to a local block is possible at that point due to possible slashing).
 
 There's several relay error scenarios:
 
-1.  payload withholding (relay doesn't release the payload and the proposer
-    needs to forfeit the slot)
+1.  payload withholding (relay doesn't release the payload and the proposer needs to forfeit the slot)
 
 2.  incorrect payload  
-    a. incorrect value (the final amount paid by the builder to the proposer was
-    different to the amount claimed in the `BuilderBid`)  
+    a. incorrect value (the final amount paid by the builder to the proposer was different to the amount claimed in the
+    `BuilderBid`)  
     b. invalid block (invalid data / fields)