docs: app v4

how-to-guides/celestia-app.md

@@ -17,12 +17,12 @@ This tutorial will guide you through installing celestia-app, both
 [from source](#building-binary-from-source) and with
 [a pre-built binary](#installing-a-pre-built-binary)
 
-Celestia-app is the software that allows you to run
-consensus nodes — including validators — and provide RPC endpoints.
+Celestia-app is the software that enables you to run
+consensus nodes (including validators) and provide RPC endpoints.
 
 ## Building binary from source
 
-This section of the tutorial presumes you completed the steps in
+This section of the tutorial assumes you completed the steps in
 [setting up your own environment](/how-to-guides/environment.md).
 
 The steps below will create a binary file named `celestia-appd`
@@ -57,7 +57,7 @@ Be sure to select the correct network to install the binary for.
 
    :::
 
-3. Build and install the `celestia-appd` binary:
+3. Build and install the `celestia-appd` binary with multiplexer support:
 
    ```bash
    make install

how-to-guides/consensus-node.md

@@ -320,13 +320,13 @@ The [Node snapshots guide](/how-to-guides/snapshots.md) provides everything you
 
 ## Start the consensus node
 
-If you are running celestia-app v1.x.x:
+If you are running celestia-app >= v4.0.0, the `rpc.grpc_laddr` config option is required. This option can be set via the CLI flag `--rpc.grpc_laddr tcp://0.0.0.0:9098` or in the `config.toml`.
 
 ```sh
-celestia-appd start
+celestia-appd start --rpc.grpc_laddr tcp://0.0.0.0:9098
 ```
 
-If you are running celestia-app >= v2.0.0: then you'll want to start the node with a `--v2-upgrade-height` that is dependent on the network. The `--v2-upgrade-height` flag is only needed during the v2 upgrade height so after your node has executed the upgrade (e.g. you see the log `upgraded from app version 1 to 2`), you don't need to provide this flag for future `celestia-appd start` invocations.
+If you are running celestia-app v2.x.x then you'll want to start the node with a `--v2-upgrade-height` that is dependent on the network. The `--v2-upgrade-height` flag is only needed during the v2 upgrade height so after your node has executed the upgrade (e.g. you see the log `upgraded from app version 1 to 2`), you don't need to provide this flag for future `celestia-appd start` invocations.
 
 ::: code-group
 
@@ -361,6 +361,7 @@ celestia-appd tendermint reset-state
 ```
 
 This preserves your configuration, validator state (`priv_validator_state.json`), and peer connections (`addrbook.json`), but removes:
+
 - blockstore.db
 - state.db
 - evidence.db
@@ -376,6 +377,7 @@ celestia-appd tendermint unsafe-reset-all --home $HOME/.celestia-app
 ```
 
 This command:
+
 - Resets blockchain data
 - Resets validator state (`priv_validator_state.json`) but NOT private keys (which are in `priv_validator_key.json`)
 - Clears address book (`addrbook.json`)
@@ -410,6 +412,7 @@ echo "{}" > ~/.celestia-app/data/priv_validator_state.json
 ```
 
 This approach:
+
 - Completely removes all blockchain data (blocks, state, evidence, etc.)
 - Removes the keyring-test directory containing transaction signing keys (but not validator consensus keys)
 - Creates a new, empty data directory structure