Apply formatting and spell checking

Ran "treefmt" on the whole repository.

Author: ch1bo

CONTRIBUTING.md

@@ -3,8 +3,9 @@
 Thank you for considering contributing and sharing your knowledge about the Cardano protocol in one capacity or another.
 
 There are basically two ways to contribute:
- - Validate and provide feedback about existing blueprints
- - Create or update blueprints
+
+- Validate and provide feedback about existing blueprints
+- Create or update blueprints
 
 ## Validate blueprints
 
@@ -44,10 +45,10 @@ Thank you for contributing your changes by opening a pull request!
 
 We do appreciate it if your pull request meets the following criteria:
 
-+ **Description of the changes**: providing a clear summary of the changes is beneficial
-+ **Quality of changes**: ensure that new or updated automated tests validate your changes
-+ **Scope**: we prefer multiple pull requests that are well-scoped rather than a single large one
-+ **Correctness**: the pull request should pass the continuous integration (CI) pipeline.
+- **Description of the changes**: providing a clear summary of the changes is beneficial
+- **Quality of changes**: ensure that new or updated automated tests validate your changes
+- **Scope**: we prefer multiple pull requests that are well-scoped rather than a single large one
+- **Correctness**: the pull request should pass the continuous integration (CI) pipeline.
 
 The project is currently in an expand-and-gather phase with no requirement of approvals, but consider requesting for reviews on Github-suggested reviewers.
 

src/SUMMARY.md

@@ -9,7 +9,7 @@
     - [BlockFetch](network/node-to-node/blockfetch/README.md)
     - [TxSubmission2](network/node-to-node/txsubmission2/README.md)
     - [KeepAlive](network/node-to-node/keep-alive/README.md)
-    - [PeerSharing]()
+    - [PeerSharing](<>)
 - [Consensus](consensus/README.md)
   - [Chain validity](consensus/chainvalid.md)
   - [Chain selection](consensus/chainsel.md)
@@ -28,15 +28,15 @@
   - [Serialization](plutus/serialization.md)
 - [Client interfaces](client/README.md)
   - [NTC](client/node-to-client/README.md)
-    - [Handshake]()
+    - [Handshake](<>)
     - [LocalStateQuery](client/node-to-client/state-query/README.md)
-    - [LocalTxSubmission]()
-    - [TxMonitor]()
-    - [LocalChainSync]()
+    - [LocalTxSubmission](<>)
+    - [TxMonitor](<>)
+    - [LocalChainSync](<>)
   - [UTxO-RPC](client/utxo-rpc/README.md)
 - [Codec basics](codecs/README.md)
 
----
+______________________________________________________________________
 
 - [Styleguide](styleguide.md)
 - [Contributing](CONTRIBUTING.md)

src/client/README.md

@@ -13,15 +13,15 @@ enabling this interaction:
 Below we present a table with clients and servers that implement each protocol:
 
 | Server         | NTC | UTxO RPC |
-|:---------------|-----|----------|
+| :------------- | --- | -------- |
 | [cardano-node] | ✅  | ❔       |
 | [dingo]        | ✅  | ✅       |
 | [amaru]        | ❔  | ❔       |
 
 <br/>
 
 | Client        | NTC | UTxO RPC |
-|:--------------|-----|----------|
+| :------------ | --- | -------- |
 | [cardano-cli] | ✅  | ⬜       |
 | [pallas]      | ✅  | ❔       |
 | [gouroboros]  | ✅  | ❔       |
@@ -30,9 +30,9 @@ Below we present a table with clients and servers that implement each protocol:
 >
 > Please help us keep this list up-to-date by [suggesting an edit](https://github.com/cardano-scaling/cardano-blueprint/edit/main/src/client/README.md).
 
-[cardano-node]: https://github.com/IntersectMBO/cardano-node
+[amaru]: https://github.com/pragma-org/amaru/
 [cardano-cli]: https://github.com/IntersectMBO/cardano-cli
+[cardano-node]: https://github.com/IntersectMBO/cardano-node
 [dingo]: https://github.com/blinklabs-io/dingo
 [gouroboros]: https://github.com/blinklabs-io/gouroboros
-[amaru]: https://github.com/pragma-org/amaru/
 [pallas]: https://github.com/txpipe/pallas

src/client/node-to-client/README.md

@@ -11,8 +11,8 @@ In particular, these mini-protocols will also be wrapped by a
 
 These mini-protocols are:
 
-- [Handshake](): to negotiate the versions used in the connection,
-- [LocalTxSubmission](): to submit transactions to the network,
+- [Handshake](<>): to negotiate the versions used in the connection,
+- [LocalTxSubmission](<>): to submit transactions to the network,
 - [LocalStateQuery](state-query): to query for information about the ledger state,
-- [TxMonitor](): to monitor the status of transactions,
-- [LocalChainSync](): to retrieve chains of blocks from the node.
+- [TxMonitor](<>): to monitor the status of transactions,
+- [LocalChainSync](<>): to retrieve chains of blocks from the node.

src/client/node-to-client/state-query/README.md

@@ -61,8 +61,6 @@ stateDiagram
 
 </details>
 
-[^1]: Derived from [ogmios](https://ogmios.dev/mini-protocols/local-state-query/)' great ascii art description.
-
 ## Acquire a state
 
 To use the ledger state query API, a client needs to first specify at which point on the chain the query should be executed. Depending on the server implementation, this point may only be within the "volatile" recent part of the chain. A typical practice is to acquire the tip of the chain, perform one or more queries and close the connection again.
@@ -103,6 +101,7 @@ Example response:
 
 > [!CAUTION]
 > FIXME: While I experimented in using the network / consensus cddl parts above, `time` would be defined in the CDDL prelude (a number, assuming seconds since epoch), but is actually incorrect and the result is serialized using `ToCBOR UTCTime` following this cddl:
+>
 > ```cddl
 > time = [year, dayOfYear, timeOfDayPico]
 > year = bigint
@@ -114,3 +113,5 @@ Example response:
 
 > [!WARNING]
 > TODO: Era-specific query with an involved answer
+
+[^1]: Derived from [ogmios](https://ogmios.dev/mini-protocols/local-state-query/)' great ascii art description.

src/consensus/README.md

@@ -62,7 +62,7 @@ The consensus protocol has three main responsibilities:
 
 - [Chain validity check](./chainvalid.md): the validity of a chain of blocks
   is defined by the Consensus protocol, whether the values in the block match
-  are as expected. This involves things like singature checking, checking the
+  are as expected. This involves things like signature checking, checking the
   previous hash, ensuring the header is consistent, etc.
 
 - [Chain selection](./chainsel.md): Competing chains arise when two or more
@@ -96,15 +96,15 @@ Depending on the Ledger era in effect, the Consensus protocol (which governs
 both chain selection and block production) is different:
 
 | Era                                        | Protocol                              | Link                                     |
-|:-------------------------------------------|:--------------------------------------|:-----------------------------------------|
-| Byron                                      | Ouroboros Classic                     | [Paper][Classic]                         |
-| Byron (reimplementation, block forging)    | Ouroboros BFT                         | [Paper][BFT]                             |
-| Byron (reimplementation, block processing) | Ouroboros Permissive BFT              | Section 4 of the [Byron spec][PBFT]      |
-| Shelley                                    | Ouroboros Transitional Praos (TPraos) | Section 12 of the [Shelley spec][TPraos] |
+| :----------------------------------------- | :------------------------------------ | :--------------------------------------- |
+| Byron                                      | Ouroboros Classic                     | [Paper][classic]                         |
+| Byron (reimplementation, block forging)    | Ouroboros BFT                         | [Paper][bft]                             |
+| Byron (reimplementation, block processing) | Ouroboros Permissive BFT              | Section 4 of the [Byron spec][pbft]      |
+| Shelley                                    | Ouroboros Transitional Praos (TPraos) | Section 12 of the [Shelley spec][tpraos] |
 | Allegra                                    | Ouroboros TPraos                      |                                          |
 | Mary                                       | Ouroboros TPraos                      |                                          |
 | Alonzo                                     | Ouroboros TPraos                      |                                          |
-| Babbage                                    | Ouroboros Praos                       | [Paper][Praos]                           |
+| Babbage                                    | Ouroboros Praos                       | [Paper][praos]                           |
 | Conway                                     | Ouroboros Praos                       |                                          |
 
 Each of these protocols defines how to fulfill the responsibilities
@@ -120,18 +120,17 @@ based on the particular era in effect.
 > protocols used in the Network _will_ use this distinction of headers and
 > bodies, so implementations can as well consider leveraging it.
 
-
 An essential and uncontroversial design refinement in any blockchain
 implementation is to separate block headers and block bodies:
 
 - If blocks can be almost fully validated in constant time based on looking at
-only a small fixed size block header, then honest nodes can validate candidate
-chains with a small bounded amount of work.
+  only a small fixed size block header, then honest nodes can validate candidate
+  chains with a small bounded amount of work.
 
 - It also enables a design where a node can see blocks available from many
-immediate peers but can choose to download each block body of interest just once
-(from a peer of its choosing from which it is available). This saves network
-bandwidth.
+  immediate peers but can choose to download each block body of interest just once
+  (from a peer of its choosing from which it is available). This saves network
+  bandwidth.
 
 In the case of Ouroboros, all the cryptographic consensus evidence is packed
 into the block header, leaving the block body containing only the ledger data,
@@ -152,7 +151,7 @@ effectively separating concerns.
 ## Mini-protocols
 
 The mini-protocols mentioned in the neworking chapter are one of the possible
-mechanisms used for data difussion. The [Networking design
+mechanisms used for data diffusion. The [Networking design
 document][network-design] has many more insights on why these protocols were
 implemented, and how they differ from other off-the-shelf mechanisms.
 
@@ -196,37 +195,36 @@ blocks or transactions. From the perspective of the consensus layer, the ledger
 layer has four primary responsibilities:
 
 - Applying blocks: The most obvious and most important responsibility of the
-ledger is to define how the ledger state changes in response to new blocks,
-validating blocks at it goes and rejecting invalid blocks.
+  ledger is to define how the ledger state changes in response to new blocks,
+  validating blocks at it goes and rejecting invalid blocks.
 
 - Applying transactions: Similar to applying blocks, the ledger layer must also
-provide an interface for applying a single transaction to the ledger state. This
-is important, because the consensus layer does not just deal with previously
-constructed blocks, but also constructs new blocks.
+  provide an interface for applying a single transaction to the ledger state. This
+  is important, because the consensus layer does not just deal with previously
+  constructed blocks, but also constructs new blocks.
 
 - Ticking time: Some parts of the ledger state change only due to the passage of
-time. For example, blocks might schedule some changes to be applied at a given
-slot, without the need for a block to be processed at that slot.
+  time. For example, blocks might schedule some changes to be applied at a given
+  slot, without the need for a block to be processed at that slot.
 
 - Forecasting: Some consensus protocols require limited information from the
-ledger. For instance, in Praos, a node’s probability of being elected a slot
-leader is proportional to its stake, but the stake distribution is something
-that the ledger keeps track of. This information is referred to as _ledger
-view_. We require not just that the ledger can provide a view of the current
-ledger state but also that it can predict what view will be for slots in the
-near future.
-
+  ledger. For instance, in Praos, a node’s probability of being elected a slot
+  leader is proportional to its stake, but the stake distribution is something
+  that the ledger keeps track of. This information is referred to as _ledger
+  view_. We require not just that the ledger can provide a view of the current
+  ledger state but also that it can predict what view will be for slots in the
+  near future.
 
 ## Resources
 
 - [Technical report: Data Diffusion and Network][network-design]: Original design document of the peer-to-peer network protocols and diffusion semantics
 - [Technical report: Cardano Consensus and Storage Layer](https://ouroboros-consensus.cardano.intersectmbo.org/pdfs/report.pdf): Documentation of the Haskell implementation of consensus components
 - [Website: ouroboros-consensus > For Developers](https://ouroboros-consensus.cardano.intersectmbo.org/docs/for-developers): Collection of developer articles on the Haskell implementation of consensus components
 
+[bft]: https://iohk.io/en/research/library/papers/ouroboros-bft-a-simple-byzantine-fault-tolerant-consensus-protocol/
+[classic]: https://iohk.io/en/research/library/papers/ouroboros-a-provably-secure-proof-of-stake-blockchain-protocol/
 [feature-table]: https://github.com/cardano-foundation/CIPs/blob/master/CIP-0059/feature-table.md
 [network-design]: https://ouroboros-network.cardano.intersectmbo.org/pdfs/network-design/network-design.pdf
-[Classic]: https://iohk.io/en/research/library/papers/ouroboros-a-provably-secure-proof-of-stake-blockchain-protocol/
-[BFT]: https://iohk.io/en/research/library/papers/ouroboros-bft-a-simple-byzantine-fault-tolerant-consensus-protocol/
-[PBFT]: https://github.com/intersectmbo/cardano-ledger/releases/latest/download/byron-blockchain.pdf
-[TPraos]: https://github.com/intersectmbo/cardano-ledger/releases/latest/download/shelley-ledger.pdf
-[Praos]: https://iohk.io/en/research/library/papers/ouroboros-praos-an-adaptively-secure-semi-synchronous-proof-of-stake-protocol/
+[pbft]: https://github.com/intersectmbo/cardano-ledger/releases/latest/download/byron-blockchain.pdf
+[praos]: https://iohk.io/en/research/library/papers/ouroboros-praos-an-adaptively-secure-semi-synchronous-proof-of-stake-protocol/
+[tpraos]: https://github.com/intersectmbo/cardano-ledger/releases/latest/download/shelley-ledger.pdf

src/consensus/chainsel.md

@@ -151,7 +151,7 @@ chain $B_{0}B_{1}\ldots{}B_{l}$ with a different chain
 $B_{0}{B'}_{1}\ldots{B'}_{s}$ if $s > l$, therefore if the candidate is longer
 than the current selection.
 
-See Figure 1 in the [paper][BFT].
+See Figure 1 in the [paper][bft].
 
 Ouroboros PBFT does not change the chain selection rules of BFT, just focuses on
 validity of blocks, making parts of the block superfluous. It therefore also
@@ -161,11 +161,11 @@ uses length to choose among candidates.
 
 Ouroboros Praos circles back to defining the ${\tt maxvalid}_S(\mathcal{C},
 \mathbb{C})$ function, with identical behaviour to that in Ouroboros
-Classic. This means that longer candidates are preferrable to shorter ones, and
+Classic. This means that longer candidates are preferable to shorter ones, and
 that ties are broken in favour of the already selected candidate.
 
 See Figure 4 and the definition of ${\tt maxvalid}$ above it in the
-[paper][Praos].
+[paper][praos].
 
 Ouroboros TPraos refines how blocks are produced, but doesn't modify the ${\tt
 maxvalid}$ function in any way.
@@ -221,14 +221,14 @@ era).
 However, in Praos, the rule for selecting the best chain between two competing
 chains is fundamentally based on chain length. The protocol assumes
 instantaneous transmission of entire chains, meaning that the perceived length
-of a candidate would be its actual length.  Due to fundamental real-world
+of a candidate would be its actual length. Due to fundamental real-world
 limitations, sending such a large amount of data instantaneously is impossible;
 instead, data is streamed to the syncing node. Consequently, nodes only know the
 length of the received prefix of the candidate chain. This creates the risk of
 adversaries tricking nodes into committing to an adversarial chain during
 synchronization.
 
-[Ouroboros Genesis][Genesis] is a refinement of Praos used by nodes only during
+[Ouroboros Genesis][genesis] is a refinement of Praos used by nodes only during
 network synchronization. The key point of Genesis is precisely a refinement of
 the Praos chain selection rule: instead of choosing based (primarily) on length
 of the candidate chains, it chooses based on the density of blocks at the
@@ -260,10 +260,13 @@ into the usual length-based comparison used in Praos, so the node can safely
 switch to running only Ouroboros Praos.
 
 <!-- iohk.io links return 403 "if you are not a human" -->
+
 <!-- markdown-link-check-disable -->
+
+<!-- markdown-link-check-enable -->
+
+[bft]: https://iohk.io/en/research/library/papers/ouroboros-bft-a-simple-byzantine-fault-tolerant-consensus-protocol/
 [classic]: https://iohk.io/en/research/library/papers/ouroboros-a-provably-secure-proof-of-stake-blockchain-protocol/
-[BFT]: https://iohk.io/en/research/library/papers/ouroboros-bft-a-simple-byzantine-fault-tolerant-consensus-protocol/
-[Praos]: https://iohk.io/en/research/library/papers/ouroboros-praos-an-adaptively-secure-semi-synchronous-proof-of-stake-protocol/
-[Genesis]: https://iohk.io/en/research/library/papers/ouroboros-genesis-composable-proof-of-stake-blockchains-with-dynamic-availability/
+[genesis]: https://iohk.io/en/research/library/papers/ouroboros-genesis-composable-proof-of-stake-blockchains-with-dynamic-availability/
 [genesis-blogpost]: https://iohk.io/en/blog/posts/2024/05/08/ouroboros-genesis-design-update/
-<!-- markdown-link-check-enable -->
+[praos]: https://iohk.io/en/research/library/papers/ouroboros-praos-an-adaptively-secure-semi-synchronous-proof-of-stake-protocol/

src/consensus/chainvalid.md

@@ -4,6 +4,7 @@ A chain of blocks has to be valid in order to be considered for adoption. In
 particular the mainnet chain _is_ valid.
 
 Validity is defined by induction on the length of the chain as:
+
 - The first block on the chain fragment is valid,
 - The tail of the chain fragment is valid.
 
@@ -89,7 +90,7 @@ A block is said to be _valid_ if:
   block. Notice the validity of these transactions is defined in the Ledger
   layer.
 
-See Figure 1 in the [paper][BFT].
+See Figure 1 in the [paper][bft].
 
 ## Ouroboros PBFT
 
@@ -118,4 +119,4 @@ This can be leveraged to skip such checks when replaying a chain that has
 already been validated, for example when restarting a node and having to replay
 the chain from scratch.
 
-[BFT]: https://iohk.io/en/research/library/papers/ouroboros-bft-a-simple-byzantine-fault-tolerant-consensus-protocol/
+[bft]: https://iohk.io/en/research/library/papers/ouroboros-bft-a-simple-byzantine-fault-tolerant-consensus-protocol/

src/consensus/forging.md

@@ -23,11 +23,11 @@ actions:
    this slot. Below we describe what this means in Ouroboros Praos. We
    omit the details for other protocols as they do not produce blocks
    anymore on Cardano mainnet.
-2. Acquire a data to constitute the body of a block. Consensus is theoretically
+1. Acquire a data to constitute the body of a block. Consensus is theoretically
    unaware of what data makes up the block body, and it will be the
    [Mempool](../mempool) the one that specifies which data is valid and provides
    such data.
-3. Pack the data into a block body, produce a block header and emit a signature.
+1. Pack the data into a block body, produce a block header and emit a signature.
 
 Note that it is in the interest of the stake pool (so that its block is included
 in the chain) and of the network as a whole (so that the chain grows) that the
@@ -71,7 +71,7 @@ $$p_i = \phi{}_f(\alpha_i) = 1 - (1 - f)^{\alpha_i}$$
 Some important properties are ensured by Praos:
 
 - There can be multiple slot leaders as the events "$U_i$ is a leader for slot
-  `sl`" are independant,
+  `sl`" are independent,
 - There can be slots with no leader,
 - Only a slot leader is aware that it is indeed a leader for a given slot,
 - The probability of being a slot leader is independent of whether the stake