docs: chain upgrade for testnet 72

Bumps the application version to v0.72.0, which is required
because the changes in #4293 were merged into a release branch,
and thus didn't land on main naturally. We'll backport that patch
shortly.

More relevantly, the chain-upgrade docs now reference the "current"
migration, which is 71 -> 72, with its own genesis time.

Finally, a small change is made to the recommended dir names, using
unique-to-this-migration dirnames for the export, to avoid confusion
for operators who have previously migrated and not cleaned up the state.

COMPATIBILITY.md

@@ -2,3 +2,4 @@
 | ------------------------- | ---------------------- | -------- | -------- |
 | 1 (Testnet 70)            | v0.70.x                | v0.37.5  |   v1     |
 | 2 (Testnet 71)            | v0.71.x                | v0.37.5  |   v1     |
+| 3 (Testnet 72)            | v0.72.x                | v0.37.5  |   v1     |

docs/guide/src/node/pd/chain-upgrade.md

@@ -38,9 +38,9 @@ until the `--genesis-start` time is reached, at which point it will resume proce
 the community of validators can coordinate resumption of chain activity, even when operators perform migrate their ndoes
 at slightly different times.
 
-### Testnet 70 -> 71
+### Testnet 71 -> 72
 
-For the first chain upgrade performed on a Penumbra testnet, use this value for genesis time: `{{ #include ../../upgrade_genesis_time_70_71.md }}`.
+For the most recent upgrade on the Penumbra testnet, use this value for genesis time: `{{ #include ../../upgrade_genesis_time_71_72.md }}`.
 See an example below for how to supply this value when performing the migration.
 
 ## Performing a chain upgrade
@@ -49,10 +49,10 @@ The following steps assume that your node uses the default directory of `~/.penu
 to store state for both `pd` and `cometbft`. If your instance is using a different directory, update the paths accordingly.
 
 1. Stop both `pd` and `cometbft`. Depending on how you run Penumbra, this could mean `sudo systemctl stop penumbra cometbft`.
-2. Back up the existing node state, as a precaution: `tar -cf ~/.penumbra/testnet_data/node0-state-backup.tar ~/.penumbra/testnet_data/node0`
+2. Back up the existing node state, as a precaution: `tar -cf ~/.penumbra/testnet_data/node0-state-backup-71.tar ~/.penumbra/testnet_data/node0`
 3. Download the latest version of `pd` and install it. Run `pd --version` and confirm you see `{{ #include ../../penumbra_version.md }}` before proceeding.
 4. Prepare an export directory:
-   `pd export --home ~/.penumbra/testnet_data/node0/pd --export-directory ~/.penumbra/testnet_data/node0/pd-exported-state`
+   `pd export --home ~/.penumbra/testnet_data/node0/pd --export-directory ~/.penumbra/testnet_data/node0/pd-exported-state-71`
 <!--
 An example log message emitted by `pd migrate` without providing `--genesis-start`:
 
@@ -61,11 +61,11 @@ An example log message emitted by `pd migrate` without providing `--genesis-star
 The value after `now=` is what should be copied. In practice, for testnets, Penumbra Labs will advise on a genesis time
 and provide that value in the documentation. Or should we just pick a genesis start ahead of time, and use that for all?
 -->
-5. Apply the migration: `pd migrate --genesis-start "{{ #include ../../upgrade_genesis_time_70_71.md }}" --target-directory ~/.penumbra/testnet_data/node0/pd-exported-state/ --migrate-archive ~/.penumbra/testnet_data/node0/pd-migrated-state-{{ #include ../../penumbra_version.md }}.tar.gz`.
+5. Apply the migration: `pd migrate --genesis-start "{{ #include ../../upgrade_genesis_time_71_72.md }}" --target-directory ~/.penumbra/testnet_data/node0/pd-exported-state-71/ --migrate-archive ~/.penumbra/testnet_data/node0/pd-migrated-state-{{ #include ../../penumbra_version.md }}.tar.gz`.
    You must use that precise genesis time, otherwise your node will not be able to reach consensus with the rest of the network.
-6. Move the migrated state into place: `rm -r ~/.penumbra/testnet_data/node0/pd/rocksdb && mv ~/.penumbra/testnet_data/node0/pd-exported-state/rocksdb ~/.penumbra/testnet_data/node0/pd/`
-7. Copy the new genesis into place: `cp ~/.penumbra/testnet_data/node0/pd-exported-state/genesis.json ~/.penumbra/testnet_data/node0/cometbft/config/genesis.json`
-8. Copy the new signing state into place: `cp ~/.penumbra/testnet_data/node0/pd-exported-state/priv_validator_state.json ~/.penumbra/testnet_data/node0/cometbft/data/priv_validator_state.json`
+6. Move the migrated state into place: `rm -r ~/.penumbra/testnet_data/node0/pd/rocksdb && mv ~/.penumbra/testnet_data/node0/pd-exported-state-71/rocksdb ~/.penumbra/testnet_data/node0/pd/`
+7. Copy the new genesis into place: `cp ~/.penumbra/testnet_data/node0/pd-exported-state-71/genesis.json ~/.penumbra/testnet_data/node0/cometbft/config/genesis.json`
+8. Copy the new signing state into place: `cp ~/.penumbra/testnet_data/node0/pd-exported-state-71/priv_validator_state.json ~/.penumbra/testnet_data/node0/cometbft/data/priv_validator_state.json`
 9. Clean up the old CometBFT state: `find ~/.penumbra/testnet_data/node0/cometbft/data/ -mindepth 1 -maxdepth 1 -type d -and -not -name tx_index.db -exec rm -r {} +`
 
 <!--

docs/guide/src/penumbra_version.md

@@ -1 +1 @@
-v0.71.0
+v0.72.0

docs/guide/src/upgrade_genesis_time_71_72.md

@@ -0,0 +1 @@
+2024-04-23T00:00:00.000000000Z