Replace oasis-node with oasis in the Run node part

README.md

@@ -200,8 +200,8 @@ There are three kinds of image assets currently used in the docs.
 
 ## Vocabulary
 
-The following is a consistent case-sensitive collection of Oasis-related terms
-and their usage:
+The following is a consistent case-sensitive collection of Oasis-related terms,
+and their usage including the articles:
 
 - c10l
   Check out the c10l-hello-world folder for the confidential version of the
@@ -217,7 +217,11 @@ and their usage:
 - key manager
 - key manager node
 - Mainnet
+  This feature is also enabled on Mainnet.
 - Testnet
+  This only runs on Testnet.
+- Oasis CLI
+  You can use the Oasis CLI to set up your wallet.
 - Oasis Core
 - OPL
   Oasis Privacy Layer supports privacy of dApps on all EVM chains.

docs/general/manage-tokens/holding-rose-tokens/ledger-wallet.md

@@ -4,7 +4,7 @@ This is a general documentation that will help users setup [Ledger] hadware
 wallets with Oasis Network. Ledger Live software doesn't support Oasis (ROSE)
 tokens natively yet. In this guide we will install Oasis app via Ledger Live to
 open and access wallet with one or multiple accounts via our official
-[Oasis Wallet - Web].
+[Oasis Wallet - Web][wallet.oasis.io].
 
 ## Setup your Ledger device and Install Oasis App
 
@@ -146,7 +146,6 @@ Ledger is supported by the Oasis CLI. Follow the instructions in the
 [Oasis CLI Tools] page to learn more.
 
 [Ledger]: https://www.ledger.com
-[Oasis Wallet - Web]: https://www.ledger.com
 [Oasis app]: https://github.com/Zondax/ledger-oasis
 [Ledger Live]: https://www.ledger.com/ledger-live/
 [wallet.oasis.io]: https://wallet.oasis.io

docs/general/manage-tokens/how-to-transfer-rose-into-paratime.mdx

@@ -188,17 +188,19 @@ the exchange.
 
 :::info
 
-Advanced users (e.g. those running ParaTime
-[compute nodes](../../node/run-your-node/paratime-node.mdx)) may need to
-withdraw ROSE from EVM-compatible ParaTimes stored in their `oasis1` accounts,
-for example to claim their ParaTime execution rewards. Oasis Wallet Browser
-Extension does not support such withdrawals. Read the
-[Oasis CLI Deposit/Withdraw Tokens to/from ParaTime chapter][Oasis CLI] to
-learn how to use Oasis CLI instead.
+Advanced users (e.g. those running ParaTime [compute nodes] may need to
+withdraw ROSE from ParaTimes stored in their `oasis1` accounts, for example to
+claim their ParaTime execution rewards. Oasis Wallet Browser Extension does not
+support such withdrawals. Use the [`oasis account withdraw`] command which is
+part of the [Oasis CLI] instead, for example:
+
+![code shell](../../../external/cli/examples/account/withdraw.y.in)
 
 :::
 
-[Oasis CLI]: cli/account.md
+[compute nodes]: ../../node/run-your-node/paratime-node.mdx
+[Oasis CLI]: cli/README.md
+[`oasis account withdraw`]: cli/account.md#withdraw
 
 ### Verifying ParaTime deposits and withdrawals
 

docs/node/mainnet/eden-upgrade.md

@@ -180,15 +180,15 @@ running the following command:
 ``` bash
 # specify 'datadir' as your node's data directory
 oasis-node unsafe-reset \
-  --datadir=/serverdir/node \
+  --datadir=/node/data \
   --dry_run
 ```
 2. **Wipe blockchain state:** after reviewing the dry run results, proceed with
 the reset by running:
 ``` bash
 # specify 'datadir' as your node's data directory
 oasis-node unsafe-reset \
-  --datadir=/serverdir/node
+  --datadir=/node/data
 ```
 
 Transitioning confidential ParaTimes to the new network requires local state

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

@@ -28,7 +28,7 @@ If an Oasis Node is **not stopped** before its state is copied, its on-disk stat
 
 :::
 
-* Copy the following directories from your synced Oasis Node's working directory (e.g. `/node/`, `/srv/oasis/node`, `/serverdir/node`) to your new Oasis Node's working directory:
+* 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`
 

docs/node/run-your-node/advanced/sync-node-using-state-sync.md

@@ -1,20 +1,31 @@
 # Using State Sync for Quick Bootstraping
 
-The State Sync is a way to **quickly bootstrap** a **full Oasis node** (either a [validator node](../validator-node.mdx) or a [non-validator node](../non-validator-node.md)) by using [Tendermint's Light Client protocol](https://docs.tendermint.com/main/tendermint-core/light-client.html). It allows one to initialize a node from a trusted height, its corresponding block's header and a trusted validator set (given in the [genesis document](../../genesis-doc.md)). It does so by securely updating the node's trusted state by requesting and verifying a minimal set of data from the network's full nodes.
+The State Sync is a way to **quickly bootstrap** a **full Oasis node** (either a
+[validator node](../validator-node.mdx) or a
+[non-validator node](../non-validator-node.md)) by using the
+[Tendermint's Light Client protocol]. It allows one to initialize a node from a
+trusted height, its corresponding block's header and a trusted validator set
+(given in the [genesis document](../../genesis-doc.md)). It does so by securely
+updating the node's trusted state by requesting and verifying a minimal set of
+data from the network's full nodes.
 
 :::info
 
-If you have access to an Oasis Node that is synced with the latest height, another option to speed bootstraping a new Oasis Node is to [copy state from one node to the other](copy-state-from-one-node-to-the-other.md).
+If you have access to an Oasis node that is synced with the latest height,
+another option to speed bootstraping a new Oasis node is to [copy state from one
+node to the other].
 
 :::
 
 :::caution
 
-Tendermint's Light Client protocol requires at least 1 full node to be correct to be able to [detect and submit evidence for a light client attack](https://docs.tendermint.com/main/tendermint-core/light-client.html#where-to-obtain-trusted-height-hash).
+Tendermint's Light Client protocol requires at least 1 full node to be correct
+to be able to [detect and submit evidence for a light client attack].
 
 :::
 
-To configure your node to use the state sync, amend your node's configuration (i.e. `config.yml`) with (non-relevant fields omitted):
+To configure your node to use the state sync, amend your node's configuration
+(i.e. `config.yml`) with (non-relevant fields omitted):
 
 ```yaml
 ... trimmed ...
@@ -44,28 +55,34 @@ consensus:
         - "{{ noden_grpc_endpoint }}"
 
 ... trimmed ...
-
 ```
 
 and replace the following variables in the configuration snippet:
 
-* `{{ trusted_height }}`: Trusted height defines the height at which your node should trust the chain.
-* `{{ trusted_height_hash }}`: Trusted height hash defines the hash of the block header corresponding to the trusted height.
-*   `{{ node1_grpc_endpoint }}`, `{{ node2_grpc_endpoint }}` , ...,
-
-    `{{ noden_grpc_endpoint }}`: Addresses of a Oasis Nodes' publicly exposed gRPC endpoints of the form: `[email protected]:9001`.
+* `{{ trusted_height }}`: Trusted height defines the height at which your node 
+  should trust the chain.
+* `{{ trusted_height_hash }}`: Trusted height hash defines the hash of the block
+  header corresponding to the trusted height.
+* `{{ node1_grpc_endpoint }}`, `{{ node2_grpc_endpoint }}` , ...,
+  `{{ noden_grpc_endpoint }}`: Addresses of a Oasis nodes' publicly exposed gRPC
+  endpoints of the form:
+  `[email protected]:9001`.
 
 :::caution
 
-You need to provide publicly exposed gRPC endpoints for **at least 2 different consensus nodes** for the state sync to work.
+You need to provide publicly exposed gRPC endpoints for **at least 2 different
+consensus nodes** for the state sync to work.
 
 :::
 
 :::danger
 
-You need to **delete any existing node state** (if it exists), otherwise state sync will be skipped. To do that, follow the [Wiping Node State](../maintenance/wiping-node-state.md#state-wipe-and-keep-node-identity) instructions.
+You need to **delete any existing node state** (if it exists), otherwise the
+state sync will be skipped. To do that, follow the [Wiping Node State]
+instructions.
 
-If existing node state is found and state sync is skipped, you will see something like the following in your node's logs:
+If existing node state is found and state sync is skipped, you will see
+something like the following in your node's logs:
 
 ```
 {"caller":"full.go:1233","level":"info","module":"tendermint","msg":"state sync enabled","ts":"2021-06-21T14:40:55.033642763Z"}
@@ -74,27 +91,39 @@ If existing node state is found and state sync is skipped, you will see somethin
 
 :::
 
+[Tendermint's Light Client protocol]:
+  https://docs.tendermint.com/main/tendermint-core/light-client.html
+[copy state from one node to the other]: copy-state-from-one-node-to-the-other.md
+[detect and submit evidence for a light client attack]:
+  https://docs.tendermint.com/main/tendermint-core/light-client.html#where-to-obtain-trusted-height-hash
+[Wiping Node State]: ../maintenance/wiping-node-state.md#state-wipe-and-keep-node-identity
+
 ### Obtaining Trusted Height and Hash
 
-To obtain the trusted height and the corresponding block header's hash, use one of the following options.
+To obtain the trusted height and the corresponding block header's hash, use one
+of the following options.
 
 #### Block Explorers
 
-Browse to one of our block explorers (e.g. [OASIS SCAN](https://www.oasisscan.com), [Oasis Monitor](https://oasismonitor.com)) and obtain the trusted height and hash there:
+Browse to one of our block explorers (e.g. [Oasis Scan], [Oasis Monitor]) and
+obtain the trusted height and hash there:
 
 1. Obtain the current block height from the main page, e.g. 4819139.
-2. Click on block height's number to view the block's details and obtain its hash, e.g. `377520acaf7b8011b95686b548504a973aa414abba2db070b6a85725dec7bd21`.
+2. Click on block height's number to view the block's details and obtain its
+   hash, e.g. `377520acaf7b8011b95686b548504a973aa414abba2db070b6a85725dec7bd21`.
+
+[Oasis Scan]: https://www.oasisscan.com
+[Oasis Monitor]: https://oasismonitor.com
 
 #### A Trusted Node
 
-If you have an existing node that you trust, you can use its status output to retrieve the current block height and hash by running:
+If you have an existing node that you trust, you can use its status output to
+retrieve the current block height and hash by running:
 
 ```
-oasis-node control status -a $ADDR
+oasis-node control status -a unix:/node/data/internal.sock
 ```
 
-replacing `$ADDR` with the path to your node's internal UNIX socket (e.g. `/srv/oasis/node/internal.sock`).
-
 This will give you output like the following (non-relevant fields omitted):
 
 ```json
@@ -119,33 +148,46 @@ The values you need are `latest_height` and `latest_hash` .
 
 #### Public Rosetta Gateway
 
-Query our public Rosetta Gateway instance and obtain the trusted height and hash there:
+Query our public Rosetta Gateway instance and obtain the trusted height and hash
+there:
 
 1. _TODO._
 
 #### Oasis Node's gRPC Endpoint
 
-Query our public Oasis Node's gRPC endpoint and obtain the trusted height and hash there:
+Query our public Oasis node's gRPC endpoint and obtain the trusted height and
+hash there:
 
 1. _TODO._
 
 ### Obtaining Addresses of Oasis Nodes' Publicly Exposed gRPC Endpoints
 
-To find the addresses of Oasis Node's publicly exposed gRPC endpoints, use one of the following options.
+To find the addresses of Oasis node's publicly exposed gRPC endpoints, use one
+of the following options.
 
 #### List Registered Nodes' Descriptors via Oasis CLI from the Local Oasis Node
 
-If you already have a local Oasis Node set up, you can list the descriptors of all registered nodes via Oasis CLI.
+If you already have a local Oasis node set up, you can list the descriptors of
+all registered nodes via the [`oasis network show nodes`] Oasis CLI command.
+
+:::info
+
+To avoid denial-of-service attacks this call is not enabled on public Oasis gRPC
+endpoints. You will have to [connect Oasis CLI to your own Oasis node]!
+
+:::
 
 You need to search for the nodes that implement the `consensus-rpc` role.
 
-The publicly exposed gRPC endpoint addresses are found under the node descriptor's `tls.addresses` key.
+The publicly exposed gRPC endpoint addresses are found under the node
+descriptor's `tls.addresses` key.
 
 You can list the relevant addresses by running:
 
 ```
-oasis-node registry node list -v -a $ADDR | \
+oasis network show nodes --network mainnet_local | \
   jq 'select(.roles | contains("consensus-rpc")) | .tls.addresses'
 ```
 
-replacing `$ADDR` with the path to your node's internal UNIX socket (e.g. `/srv/oasis/node/internal.sock`).
+[`oasis network show nodes`]: ../../../general/manage-tokens/cli/network.md#show-nodes
+[connect Oasis CLI to your own Oasis node]: ../../../general/manage-tokens/cli/network.md#add

docs/node/run-your-node/keymanager-node/key-manager-upgrade.md

@@ -66,7 +66,7 @@ the `control status` output should show `keymanager.status="ready"` and
 `registration.descriptor.runtimes.0.extra_info` should contain a hash of the 
 key material state:
 ```
-$ oasis_node oasis-node -a unix:/storage/node/internal.sock control status
+$ oasis-node -a unix:/node/data/internal.sock control status
 ...
   "registration": {
     "last_registration": "2023-02-06T08:40:30Z",