From 9f839515e7885025eea248f77e46efb37c01b251 Mon Sep 17 00:00:00 2001 From: Conor Schaefer Date: Fri, 2 Aug 2024 15:07:02 -0700 Subject: [PATCH] docs: ibc relaying and chain upgrades --- pages/node/pd/indexing-events.md | 4 ++-- pages/relayers.md | 20 ++++++++++++++++++++ 2 files changed, 22 insertions(+), 2 deletions(-) diff --git a/pages/node/pd/indexing-events.md b/pages/node/pd/indexing-events.md index 33c5a46..7e59350 100644 --- a/pages/node/pd/indexing-events.md +++ b/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 diff --git a/pages/relayers.md b/pages/relayers.md index 39c1dd9..4a97bbf 100644 --- a/pages/relayers.md +++ b/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