docs: fmt all commonmark

Author: drahnr

contracts/contracts/README.md

@@ -30,6 +30,6 @@ To do that, we use the `get_selectors` function from a script in Python.
 
 ## References
 
--   [Introduction to EIP-2535 Diamonds](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard)
--   [ERC-2535: Diamonds, Multi-Facet Proxy](https://eips.ethereum.org/EIPS/eip-2535#facets-state-variables-and-diamond-storage)
--   [Understanding Diamonds on Ethereum](https://dev.to/mudgen/understanding-diamonds-on-ethereum-1fb)
+- [Introduction to EIP-2535 Diamonds](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard)
+- [ERC-2535: Diamonds, Multi-Facet Proxy](https://eips.ethereum.org/EIPS/eip-2535#facets-state-variables-and-diamond-storage)
+- [Understanding Diamonds on Ethereum](https://dev.to/mudgen/understanding-diamonds-on-ethereum-1fb)

contracts/ops/README.md

@@ -2,5 +2,5 @@
 
 This directory includes a set of scripts to ease the deployment of the IPC Solidity contracts to any network using hardhat.
 
--   `deploy.sh`: Deploys the IPC solidity contracts into a specific network.
--   `compile-abi.sh`: Compiles all contracts and outputs the ABI for the high-level contracts in the desired folder (by default `./out`).
+- `deploy.sh`: Deploys the IPC solidity contracts into a specific network.
+- `compile-abi.sh`: Compiles all contracts and outputs the ABI for the high-level contracts in the desired folder (by default `./out`).

contracts/specs/PROPERTIES.md

@@ -2,16 +2,16 @@
 
 List of identified and checked invariants of the IPC protocol following the categorization by [Certora](https://github.com/Certora/Tutorials/blob/master/06.Lesson_ThinkingProperties/Categorizing_Properties.pdf):
 
--   Valid States
--   State Transitions
--   Variable Transitions
--   High-Level Properties
--   Unit Tests
--   Valid States
--   State Transitions
--   Variable Transitions
--   High-Level Properties
--   Unit Tests
+- Valid States
+- State Transitions
+- Variable Transitions
+- High-Level Properties
+- Unit Tests
+- Valid States
+- State Transitions
+- Variable Transitions
+- High-Level Properties
+- Unit Tests
 
 ## Subnet Registry
 

docs-gitbook/concepts/subnets/parent-child-interactions.md

@@ -16,8 +16,6 @@ There are following parent-child interactions available in IPC
 
 6\. Removing child subnets from the IPC hierarchy.
 
-
-
 ## Checkpointing
 
 Checkpointing is a method for a parent subnet to keep a record of the evolution of its child subnet’s state by including snapshots of the child’s state (called checkpoints) in the parent’s state. If, for some reason, the child subnet misbehaves as a whole, agreement can be reached in the parent subnet about how to proceed.
@@ -26,7 +24,6 @@ Checkpointed history of a child subnet cannot be reverted as long as a parent su
 
 In case of subnet failure, checkpointing enables participants (e.g., former users of the failed subnet) to agree on picking up an older version of the child subnet’s state from before the occurrence of the failure and, say, use that version as the initial state of a new, more robust subnet.\
 
-
 ### Checkpointing fees
 
 There are a number of fees that are paid during checkpointing: 

docs-gitbook/developer-guides/deploy-blockscout.md

@@ -1,16 +1,18 @@
-# Deploying Blockscout on a local subnet 
+# Deploying Blockscout on a local subnet
 
 Before delving into this tutorial, you should have [deployed a local subnet](deploy-a-subnet). If you're connecting to an existing remote subnet and not following the guide, make sure that you have a local docker installation.
 
 These are instructions for deploying a basic, non-customised, local subnet explorer. The resulting instance will not provide all Blockscout features not be appropriate for production use.
 
 1. Get Blockscout
+
 ```
 git clone https://github.com/blockscout/blockscout
 cd ./blockscout/docker-compose
 ```
 
-2. Edit `./envs/common-blockscout.env` and set 
+2. Edit `./envs/common-blockscout.env` and set
+
 ```
 INDEXER_DISABLE_PENDING_TRANSACTIONS_FETCHER=true           
 INDEXER_DISABLE_INTERNAL_TRANSACTIONS_FETCHER=true
@@ -21,6 +23,7 @@ The default setup assumes a local subnet with the Ethereum RPC on `localhost:854
 Some frontend calls use hardcoded absolute URLs. Unless you're only accessing the Blockscout interface on `localhost`, make sure to review the environmental variables in the different files under `./envs/` and adjust addresses (e.g. `BLOCKSCOUT_HOST` in `envs/common-blockscout.env` and `NEXT_PUBLIC_STATS_API_HOST` in `envs/common-frontend.env`. You'll also need to make sure the required ports are accessible (at least 80, 8080, and 8081).
 
 3. Start Blockscout
+
 ```
 docker compose -f docker-compose-no-build-geth.yml up -d
 ```

docs-gitbook/developer-guides/pluggable-syscall-tutorial.md

@@ -15,7 +15,7 @@ IPC uses the [Filecoin Virtual Machine (FVM)](https://docs.filecoin.io/smart-con
 * Extending chain-specific syscalls once IPC supports more root chains. Because other chains may have their own special syscalls different as Filecoin (proof validation, etc.).
 * Extending features to support better development tools. E.g. adding special debugging syscalls, adding randomness syscalls, and supporting more ECC curve, etc.
 
-## Pre-requisite knowledge for tutorial:
+## Pre-requisite knowledge for tutorial
 
 * [ref-fvm](https://github.com/filecoin-project/ref-fvm)
 * [fvm syscall APIs](https://docs.rs/fvm\_sdk/latest/fvm\_sdk/sys/index.html)
@@ -34,7 +34,7 @@ TIP: For clarity, the instructions may have skipped certain files (like long `Ca
 ### **1. Define the custom syscall**
 
 * In this example, we will be creating a simple syscall which accesses the filesystem. Inside syscalls, you can run external processes, link to rust libraries, access network, call other syscalls, etc.
-*   We’ll call this new syscall `my_custom_syscall`and its defined as follows:
+* We’ll call this new syscall `my_custom_syscall`and its defined as follows:
 
     ```rust
     pub trait CustomKernel: Kernel {
@@ -43,7 +43,7 @@ TIP: For clarity, the instructions may have skipped certain files (like long `Ca
     ```
 
     [fendermint/vm/interpreter/src/fvm/examples/mycustomkernel.rs#L23](https://github.com/consensus-shipyard/ipc/blob/98497363a10e08236325e6d5c52755b9fcd52958/fendermint/vm/interpreter/src/fvm/examples/mycustomkernel.rs#L23)
-*   Define a struct `CustomKernelImpl` which extends `DefaultKernel` . We use the `ambassador` crate to automatically delegate calls which reduces the boilerplate code we need to write. Here we simply delegate all calls to existing syscall to the `DefaultKernel`.
+* Define a struct `CustomKernelImpl` which extends `DefaultKernel` . We use the `ambassador` crate to automatically delegate calls which reduces the boilerplate code we need to write. Here we simply delegate all calls to existing syscall to the `DefaultKernel`.
 
     ```rust
     #[derive(Delegate)]
@@ -65,7 +65,7 @@ TIP: For clarity, the instructions may have skipped certain files (like long `Ca
 
 ### **2. Implementing all necessary functions for the syscall**
 
-*   Implement `my_custom_syscall`
+* Implement `my_custom_syscall`
 
     Here is where we implement our custom syscall:
 
@@ -166,11 +166,11 @@ where
         + MessageOps
         + NetworkOps
         + RandomnessOps
-        + SelfOps,	
+        + SelfOps,
 {
-	fn link_syscalls(linker: &mut Linker<K>) -> anyhow::Result<()> {
+ fn link_syscalls(linker: &mut Linker<K>) -> anyhow::Result<()> {
         DefaultKernel::<K::CallManager>::link_syscalls(linker)?;
-				
+
         linker.link_syscall("my_custom_kernel", "my_custom_syscall", my_custom_syscall)?;
 
         Ok(())
@@ -211,8 +211,7 @@ executor: DefaultExecutor<CustomKernelImpl<DefaultCallManager<DefaultMachine<DB,
 
 ### **6. Use syscall in your IPC subnet**
 
-*   Now, we are all set to use the custom syscall in the IPC subnet. The custom syscall can be called in IPC actors to utilize the extended feature. For this tutorial, we can create a simple actor to demonstrate how to import and call the custom syscall and then confirm that its working correctly.
-
+* Now, we are all set to use the custom syscall in the IPC subnet. The custom syscall can be called in IPC actors to utilize the extended feature. For this tutorial, we can create a simple actor to demonstrate how to import and call the custom syscall and then confirm that its working correctly.
 
 * Let’s create a `customsyscall` folder in `ipc/fendermint/actors/` and then create a file called [actor.rs](https://github.com/consensus-shipyard/ipc/blob/98497363a10e08236325e6d5c52755b9fcd52958/fendermint/actors/customsyscall/src/actor.rs) in that new folder. Here we want to create a very simple actor, which when invoked (received a message on its Invoke method) will call the new syscall and return its value:
 

docs-gitbook/developer-guides/upgrades/README.md

@@ -7,6 +7,7 @@ In this document, we describe how IPC achieves full upgradability of all its com
 # IPC Actor upgrades
 
 The on-chain logic for IPC is implemented in two contracts, the IPC gateway and the subnet actor, as well as an auxiliary contract use for UX purposes, the registry.
+
 - The gateway is a singleton actor that lives in every IPC subnet and implements the common logic for IPC. It is responsible for managing the collateral of subnet, enforcing the firewall requirement, and the cross-net interactions.
 - The subnet actor is a user-defined actor that implements the specific logic of a subnet. This contract is deployed in the parent from which the child subnet wants to be deployed. There is one subnet-actor for each child subnet in the parent.
 - The subnet registry behaves as a subnet actor factory that offers users a convenient way of deploying instances of the reference implementation of the subnet actor in a network.
@@ -104,14 +105,14 @@ pub struct Upgrade {
 ```
 
 Fields:
+
 - `chain_id`: The chain id the upgrade should be applied to.
 - `block_height`: The block height where the upgrade should be applied to and the `migration` function executed.
 - `new_app_version`: Indicates a new application protocol version if the upgrade introduces backward-incompatible changes.
 - `migration`: The migration function that is executed when applying the upgrade. The migration function is passed the `FvmExecState` which gives access to the `state_tree`, `block_store`, ability to send messages and more.
 
 Fendermint supports scheduling multiple upgrades through its `UpgradeScheduler` API which is defined as follows:
 
-
 ```rust
 struct UpgradeKey(ChainID, BlockHeight);
 
@@ -219,4 +220,3 @@ halt_height = 0
 #### 5. Start the new Fendermint version
 
 We can now start the new version of Fendermint which contains the upgrade we need.
-

docs-gitbook/developer-guides/upgrades/patch-state.md

@@ -20,7 +20,6 @@ Inside this migration function, we need to retrieve the actor state associated w
 
 Our migration function is defined as follows:
 
-
 ```rust
 pub fn patch_actor_state_func(state: &mut FvmExecState<NamespaceBlockstore>) -> anyhow::Result<()> {
     let state_tree = state.state_tree_mut();
@@ -90,4 +89,4 @@ let interpreter = FvmMessageInterpreter::<DB, _>::new(
   ...
   scheduler,
 );
-```
+```

docs-gitbook/developer-guides/upgrades/upgrade-wasm-actor.md

@@ -10,7 +10,6 @@ To replace the existing `chainmetadata` actor that we deployed at genesis with t
 
 Our migration function is defined as follows:
 
-
 ```rust
 // The WASM binary of the new version of the chainmetadata actor.
 static WASM_BIN: &[u8] = include_bytes!("../output/fendermint_actor_chainmetadata_v2.wasm");
@@ -73,4 +72,4 @@ let interpreter = FvmMessageInterpreter::<DB, _>::new(
   ...
   scheduler,
 );
-```
+```

docs-gitbook/quickstarts/deploy-a-subnet.md

@@ -10,10 +10,11 @@ Several steps in this guide involve running long-lived processes. In each of the
 
 ### Step 1: Prepare your system
 
-#### Install the basic requirements for IPC:
+#### Install the basic requirements for IPC
 
 {% tabs %}
 {% tab title="Linux" %}
+
 * Install system packages: `sudo apt install build-essential clang cmake pkg-config libssl-dev protobuf-compiler git curl`.
 * Install Rust. See [instructions](https://www.rust-lang.org/tools/install).
 * Install cargo-make: `cargo install --force cargo-make`.
@@ -25,9 +26,11 @@ Also install the following dependencies ([details](https://lotus.filecoin.io/lot
 ```
 sudo apt update && sudo apt install build-essential libssl-dev mesa-opencl-icd ocl-icd-opencl-dev gcc git bzr jq pkg-config curl clang hwloc libhwloc-dev wget ca-certificates gnupg -y
 ```
+
 {% endtab %}
 
 {% tab title="MacOS" %}
+
 * Install Xcode from App Store or terminal: `xcode-select --install`
 * Install Homebrew. See [instructions](https://brew.sh/).
 * Install dependencies: `brew install jq`
@@ -38,14 +41,15 @@ sudo apt update && sudo apt install build-essential libssl-dev mesa-opencl-icd o
 {% endtab %}
 {% endtabs %}
 
-#### Building:
+#### Building
 
 {% hint style="info" %}
 NOTE: this step may take a while to compile, depending on OS version and hardware build
 {% endhint %}
 
 {% tabs %}
 {% tab title="Linux" %}
+
 ```
 # make sure that rust has the wasm32 target & use stable version of rustc
 rustup target add wasm32-unknown-unknown
@@ -63,9 +67,11 @@ make
 ./target/release/ipc-cli --version
 ./target/release/fendermint --version
 ```
+
 {% endtab %}
 
 {% tab title="MacOS" %}
+
 ```
 # make sure that rust has the wasm32 target & use stable version of rustc
 rustup target add wasm32-unknown-unknown
@@ -82,6 +88,7 @@ cargo build --release
 ./target/release/ipc-cli --version
 ./target/release/fendermint --version
 ```
+
 {% endtab %}
 {% endtabs %}
 
@@ -91,10 +98,12 @@ cargo build --release
 
 {% tabs %}
 {% tab title="Linux/MacOS" %}
+
 ```
 alias ipc-cli="cargo run -q -p ipc-cli --release --"
 ipc-cli config init
 ```
+
 {% endtab %}
 {% endtabs %}
 
@@ -117,7 +126,7 @@ gateway_addr = "<GATEWAY_ADDR>"
 registry_addr = "<REGISTRY_ADDR>"
 ```
 
-*   **Replace** the `gateway_addr` and `registry_addr` with the following values. Click on the badges below to take you to the source to copy and paste them or go to [this link](https://github.com/consensus-shipyard/ipc/blob/cd/contracts/deployments/r314159.json).
+* **Replace** the `gateway_addr` and `registry_addr` with the following values. Click on the badges below to take you to the source to copy and paste them or go to [this link](https://github.com/consensus-shipyard/ipc/blob/cd/contracts/deployments/r314159.json).
 
     [![Gateway Address](https://img.shields.io/badge/dynamic/json?url=https%3A%2F%2Fraw.githubusercontent.com%2Fconsensus-shipyard%2Fipc%2Fcd%2Fcontracts%2Fdeployments%2Fr314159.json\&query=%24.gateway\_addr\&label=Gateway%20Address)](https://github.com/consensus-shipyard/ipc/blob/cd/contracts/deployments/r314159.json)
 
@@ -224,39 +233,40 @@ TIP: Highly recommend documenting that information which will be useful to boots
 #################################
 
 Subnet ID:
-	/r314159/t410f6b2qto756ox3qfoonq4ii6pdrylxwyretgpixuy
+ /r314159/t410f6b2qto756ox3qfoonq4ii6pdrylxwyretgpixuy
 
 Eth API:
-	http://0.0.0.0:8545
+ http://0.0.0.0:8545
 
 Chain ID:
-	3684170297508395
+ 3684170297508395
 
 Fendermint API:
-	http://localhost:26658
+ http://localhost:26658
 
 CometBFT API:
-	http://0.0.0.0:26657
+ http://0.0.0.0:26657
 
 CometBFT node ID:
-	ca644ac3194d39a2834f5d98e141d682772c149b
+ ca644ac3194d39a2834f5d98e141d682772c149b
 
 CometBFT P2P:
-	http://0.0.0.0:26656
+ http://0.0.0.0:26656
 
 IPLD Resolver Multiaddress:
-	/ip4/0.0.0.0/tcp/26655/p2p/16Uiu2HAkwhrWn9hYFQMR2QmW5Ky7HJKSGVkT8xKnQr1oUGCkqWms
+ /ip4/0.0.0.0/tcp/26655/p2p/16Uiu2HAkwhrWn9hYFQMR2QmW5Ky7HJKSGVkT8xKnQr1oUGCkqWms
 ```
 
 You'll need the final component of the `IPLD Resolver Multiaddress` (the `peer ID`) and the `CometBFT node ID` for the next nodes to start.
 
-*   _**BOOTSTRAPS**_: \<CometBFT node ID for validator1>@validator-1-cometbft:26656
+* _**BOOTSTRAPS**_: \<CometBFT node ID for validator1>@validator-1-cometbft:26656
 
     ```
     // An example
     ca644ac3194d39a2834f5d98e141d682772c149b@validator-1-cometbft:26656
     ```
-*   _**RESOLVER\_BOOTSTRAPS**_: /dns/validator-1-fendermint/tcp/26655/p2p/\<Peer ID in IPLD Resolver Multiaddress>
+
+* _**RESOLVER\_BOOTSTRAPS**_: /dns/validator-1-fendermint/tcp/26655/p2p/\<Peer ID in IPLD Resolver Multiaddress>
 
     <pre><code>// An example
     <strong>/dns/validator-1-fendermint/tcp/26655/p2p/16Uiu2HAkwhrWn9hYFQMR2QmW5Ky7HJKSGVkT8xKnQr1oUGCkqWms