Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs: ibc relaying and chain upgrades #25

Merged
merged 1 commit into from
Aug 7, 2024
Merged

docs: ibc relaying and chain upgrades #25

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions pages/node/pd/indexing-events.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -28,8 +28,9 @@ 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`
5. Run `pd` and `cometbft` as normal, taking care to use the appropriate versions.
4. Move aside the the archive node's CometBFT addressbook, if present: `mv ~/.penumbra/node0/cometbft/config/addrbook.json{,.bak}`.
5. 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`
6. 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
node to the archive node. As it streams blocks, the ABCI events will be recorded in the database.
Expand Down
21 changes: 20 additions & 1 deletion pages/relayers.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ In order to run a Hermes instance for Penumbra, you'll need to prepare the follo
* The chain ID of the counterparty network
* A funded Penumbra wallet, to pay fees on Penumbra (the host chain)
* A funded counterparty wallet, to pay fees on the counterparty chain
* Two (2) API endpoints for Penumbra node, `pd` gRPC and CometBFT JSON-RPC
* Two (2) API endpoints for [Penumbra node](./node/pd.md), `pd` gRPC and CometBFT JSON-RPC
* Two (2) API endpoints for counterparty node, app gRPC and CometBFT JSON-RPC
* A compatible version of `hermes`, built as described above.

Expand Down Expand Up @@ -80,6 +80,25 @@ 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.
In order to perform this step, you'll need the following information:

* The chain id of counterparty chain, for `--host-chain`.
* The halt height of penumbra chain for `--restart-height`, visible in the governance proposal for the chain upgrade.
* The IBC client id for the relayer on the counterparty chain, for `--client`.
* The [archive node](./node/pd/indexing-events.md#running-an-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
Expand Down