Merge pull request #615 from oasisprotocol/matevz/docs/oasis-core-23.0

docs/node/copy-state-from-on-node-to-enother: Migrate directory names for Oasis Core 23.0

.gitmodules

@@ -1,7 +1,7 @@
 [submodule "external/oasis-core"]
 	path = external/oasis-core
 	url = https://github.com/oasisprotocol/oasis-core
-	branch = stable/22.2.x
+	branch = stable/23.0.x
 [submodule "external/oasis-sdk"]
 	path = external/oasis-sdk
 	url = https://github.com/oasisprotocol/oasis-sdk

docs/node/run-your-node/advanced/copy-state-from-one-node-to-the-other.md

@@ -1,58 +1,76 @@
 # Copy State from One Node to the Other
 
-A network that's been running for some time can accrue significant amount of state. This means  bootstraping a new Oasis Node would take quite some time and resources (bandwidth, CPU) since it would need to fetch (download) and validate (replay) all the blocks from the genesis height onwards.
+A network that's been running for some time can accrue significant amount of
+state. This means  bootstraping a new Oasis node would take quite some time and
+resources (bandwidth, CPU) since it would need to fetch (download) and validate
+(replay) all the blocks from the genesis height onwards.
 
-If one has access to an Oasis Node that is synced with the latest height, he could just copy Oasis Node's state from the synced node to an unsynced node.
+If one has access to an Oasis node that is synced with the latest height, he
+could just copy Oasis node's state from the synced node to an unsynced node.
 
 :::info
 
-Another way to speed up bootstraping an Oasis Node is to sync the node using [State Sync](sync-node-using-state-sync.md).
+Another way to speed up bootstrapping an Oasis node is to sync the node using
+the [State Sync](sync-node-using-state-sync.md).
 
 :::
 
-To bootstrap a new Oasis Node by copying state from a synced Oasis Node, first set up your new Oasis Node as a [Validator Node](../validator-node.mdx), a [Non-validator Node](../non-validator-node.md) or a [ParaTime Node](../paratime-node.mdx).
+To bootstrap a new Oasis node by copying state from a synced Oasis node, first
+set up your new Oasis node as a [Validator Node](../validator-node.mdx), a
+[Non-validator Node](../non-validator-node.md) or a
+[ParaTime Node](../paratime-node.mdx).
 
 :::caution
 
-Make sure you use the **exact same version of Oasis Core** on both the synced Oasis Node and your new Oasis Node to prevent **issues or state corruption** if an Oasis Node's state is opened **with** an **incompatible version** of Oasis Core.
+Make sure you use the **exact same version of Oasis Core** on both the synced
+Oasis node and your new Oasis node to prevent **issues or state corruption** if
+an Oasis node's state is opened **with an incompatible version** of Oasis
+Core.
 
 :::
 
-Before starting your new Oasis Node, do the following:
+Before starting your new Oasis node, do the following:
 
-* Stop the synced Oasis Node.
+1. Stop the synced Oasis node.
 
-:::danger
+   :::danger
 
-If an Oasis Node is **not stopped** before its state is copied, its on-disk state might not be consistent and up-to-date. This can lead to **state corruption** and inability to use the state with your new Oasis Node.
+   If an Oasis node is **not stopped** before its state is copied, its on-disk
+   state might not be consistent and up-to-date. This can lead to **state
+   corruption** and inability to use the state with your new Oasis node.
 
-:::
+   :::
 
-* Copy the following directories from your synced Oasis Node's working directory (e.g. `/node/data`) to your new Oasis Node's working directory:
-  * `tendermint/abci-state`
-  * `tendermint/data`
+2. Copy the following directories from your synced Oasis node's **data
+   directory** (e.g. `/node/data`) to your new Oasis node's data directory:
+
+   * `consensus/state`
+   * `consensus/data`
 
-:::caution
+   :::caution
 
-You could also copy the whole `tendermint` directory from your synced Oasis Node's working directory. In that case, you must **omit** the **`oasis_priv_validator.json` file**, otherwise starting your new Oasis Node with fail with something like:
+   You could also copy the whole `consensus` directory from your synced Oasis
+   node's working directory. In that case, you must **omit** the
+   **`oasis_priv_validator.json` file**, otherwise starting your new Oasis node
+   with fail with something like:
 
-```
-{"caller":"node.go:696","err":"tendermint/crypto: public key mismatch, state corruption?: %!w(<nil>)","level":"error","module":"oasis-node","msg":"failed to initialize tendermint service","ts":"2021-09-25T14:13:17.919296668Z"}
-```
+   ```json
+   {"caller":"node.go:541","err":"cometbft/crypto: public key mismatch, state corruption?: %!w(<nil>)","level":"error","module":"oasis-node","msg":"failed to initialize cometbft service","ts":"2023-11-25T14:13:17.919296668Z"}
+   ```
 
-:::
+   :::
 
-:::caution
+   :::caution
 
-If you are copying data from a node that is running [TEE-enabled ParaTimes], you
-must make sure to **remove** the `runtimes/*/worker-local-storage.badger.db` as
-otherwise the ParaTime binary may fail to start on a different node since it
-contains data sealed to the source CPU.
+   If you are copying data from a node that is running [TEE-enabled ParaTimes],
+   you must make sure to **remove** the `runtimes/*/worker-local-storage.badger.db`
+   as otherwise the ParaTime binary may fail to start on a different node since
+   it contains data sealed to the source CPU.
 
-[TEE-enabled ParaTimes]: ../prerequisites/set-up-trusted-execution-environment-tee.md
+   :::
 
-:::
+3. Start back the synced Oasis node.
 
-* Start back the synced Oasis Node.
+Finally, you can start your new Oasis node for the first time.
 
-Finally, start your new Oasis Node for the first time.
+[TEE-enabled ParaTimes]: ../prerequisites/set-up-trusted-execution-environment-tee.md