docs: ibc relaying and chain upgrades

pages/node/pd/indexing-events.md

@@ -18,7 +18,7 @@ The format for `DATABASE_URL` is specified in the [Postgres docs](https://www.po
 After the node is running, check the logs for errors. Query the database with `SELECT height FROM blocks ORDER BY height DESC LIMIT 10;` and confirm
 you're seeing the latest blocks being added to the database.
 
-## Rebuilding an index database from scratch
+## Running an archive node
 
 If you are joining the network after a chain upgrade, the events behind the upgrade boundary
 will not be available to your node for syncing while catching up to current height. To emit
@@ -28,7 +28,7 @@ planned upgrade. The process then becomes:
 1. Restore node state from backup.
 2. Ensure you're using the appropriate `pd` and `cometbft` versions for the associated state.
 3. Run `pd migrate --ready-to-start` to permit `pd` to start up.
-4. Run CometBFT with extra options: `--p2p.pex=false --p2p.seeds='' --moniker archive-node-1`
+4. Run CometBFT with extra options: `--p2p.pex=false --p2p.seeds='' --p2p.persistent_peers='' --p2p.laddr="tcp://127.0.0.1:26656" --moniker archive-node-1`
 5. Run `pd` and `cometbft` as normal, taking care to use the appropriate versions.
 
 Then configure another node with indexing support, as described above, and join the second

pages/relayers.md

@@ -80,6 +80,26 @@ Consult the official Hermes docs for [running in production](https://hermes.info
 as well as the [telemetry guide](https://hermes.informal.systems/documentation/telemetry/index.html).
 You'll need to communicate the channels that you maintain to the community. How you do so is up to you.
 
+## Performing upgrades
+
+When a [Penumbra chain upgrade](./node/pd/chain-upgrade.md) is performed, relayer operators must [configure an archive node](./node/pd/indexing-events.md#running-an-archive-node)
+on the pre-upgrade version of `pd`, and use that archive node, as well as an upgraded Penumbra node, to bridge the upgrade boundary via the relayer.
+See the [genesis-restart](https://hermes.informal.systems/advanced/troubleshooting/genesis-restart.html?highlight=genesis%20restart#updating-a-client-after-a-genesis-restart-without-ibc-upgrade-proposal) functionality in the Hermes docs.
+Info you'll need:
+
+* chain id of counterparty chain, for `--host-chain`
+* halt height of penumbra chain for `--restart-height`
+* halt height + 1 for `--height`
+* client-id on the counterparty chain, for `--client`
+* archive node url for `--archive-address`
+
+1. Set up an archive node on the pre-upgrade chain, with the pre-upgrade version of pd, [as described here](./node/pd/indexing-events.md#running-an-archive-node)
+2. Stop the `hermes` service, so that the relayer is not running.
+3. Run a one-off invocation to bridge the upgrade boundary, pointing at the archive node: `hermes --config /etc/hermes/config-penumbra-noble.toml update client --archive-address http://localhost:26657/ --restart-height 222200 --host-chain grand-1 --client 07-tendermint-257` (as described here https://hermes.informal.systems/advanced/troubleshooting/genesis-restart.html)
+4. Then restart the hermes service.
+
+After that, the relayer instance should be running properly on the post-upgrade chain, and the archive node can be shut down.
+
 [Cosmos]: https://cosmos.network
 [IBC]: https://ibc.cosmos.network
 [hermes]: https://hermes.informal.systems