chore: update blobstream docs (#1264)

* chore: update blobstream docs

based on celestiaorg/orchestrator-relayer#585

* chore: update bstream docs

nodes/blobstream-deploy.md

@@ -60,16 +60,16 @@ Now, we can deploy the Blobstream contract to a new EVM chain:
 blobstream deploy \
   --evm.chain-id 4 \
   --evm.contract-address 0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 \
-  --core.grpc.host localhost \
-  --core.grpc.port 9090 \
+  --core.grpc localhost:9090 \
+  --core.rpc localhost:26657 \
   --starting-nonce latest \
   --evm.rpc http://localhost:8545
 ```
 
-The `latest` can be replaced by the following:
+The `--starting-nonce` can have the following values:
 
 - `latest`: to deploy the Blobstream contract starting from the latest validator set.
 - `earliest`: to deploy the Blobstream contract starting from genesis.
-- `nonce`: you can provide a custom nonce on where you want Blobstream to start. If the provided nonce is not a `Valset` attestation, then the one before it will be used to deploy the Blobstream smart contract.
+- `nonce`: you can provide a custom nonce on where you want Blobstream to start. If the provided nonce is not a `Valset` attestation, then the valset before it will be used to deploy the Blobstream smart contract.
 
 And, now you will see the Blobstream smart contract address in the logs along with the transaction hash.

nodes/blobstream-orchestrator.md

@@ -1,9 +1,9 @@
 ---
-sidebar_label: Blobstream orchestrator
-description: Learn about the Blobstream orchestrator.
+sidebar_label: Blobstream Orchestrator
+description: Learn about the Blobstream Orchestrator.
 ---
 
-# Blobstream orchestrator
+# Blobstream Orchestrator
 
 <!-- markdownlint-disable MD013 -->
 <!-- markdownlint-disable MD010 -->
@@ -95,7 +95,7 @@ To import your EVM private key, there is the `import` subcommand to assist you w
 blobstream orchestrator keys evm import --help
 ```
 
-This subcommand allows you to either import a raw ECDSA private key provided as plaintext, or import it from a file. The files are JSON keystore files encrypted using a passphrase like in [this example](https://geth.ethereum.org/docs/developers/dapp-developer/native-accounts).
+This subcommand allows you to either import a raw ECDSA private key provided as plaintext, import it from a file, or use a BIP39 mnemonic and derive a private key from it. The files are JSON keystore files encrypted using a passphrase like in [this example](https://geth.ethereum.org/docs/developers/dapp-developer/native-accounts).
 
 After adding the key, you can check that it's added via running:
 
@@ -120,30 +120,45 @@ Usage:
   blobstream orchestrator start <flags> [flags]
 ```
 
+Also, you can set the necessary configuration in the orchestrator's TOML config file. You can find the latter in the orchestrator's home directory under `config/config.toml`.
+
+> **_NOTE:_** The CLI flags take precedence over the config files for the same parameters.
+
 To start the orchestrator in the default home directory, run the following:
 
 ```sh
-blobstream orchestrator start \
-    --core.grpc.host localhost \
-    --core.grpc.port 9090 \
-    --core.rpc.host localhost \
-    --core.rpc.port 26657 \
-    --evm.account 0x966e6f22781EF6a6A82BBB4DB3df8E225DfD9488 \
-    --p2p.bootstrappers /ip4/127.0.0.1/tcp/30001/p2p/12D3KooWFFHahpcZcuqnUhpBoX5fJ68Qm5Hc8dxiBcX1oo46fLxh \
-    --p2p.listen-addr /ip4/0.0.0.0/tcp/30000
+blobstream orchestrator start --evm.account 0x966e6f22781EF6a6A82BBB4DB3df8E225DfD9488
 ```
 
-And, you will be prompted to enter your EVM key passphrase so that the orchestrator can use it to sign attestations. Make sure that it's the EVM address that was provided when creating the validator. If not, then the orchestrator will not sign, and you will keep seeing a "validator not part of valset" warning message. If you see such message, first verify that your validator is part of the active validator set. If so, then probably the EVM address provided to the orchestrator is not the right one, and you should check which EVM address is registered to your validator. Check the next section for more information.
+> **_NOTE:_** The above command assumes that the necessary configuration is specified in the  `<orchestrator_home>/config/config.toml` file.
+
+Then, you will be prompted to enter your EVM key passphrase so that the orchestrator can use it to sign attestations. Make sure that it's the EVM address that was provided when creating the validator. If not, then the orchestrator will not sign, and you will keep seeing a "validator not part of valset" warning message. If you see such message, first verify that your validator is part of the active validator set. If so, then probably the EVM address provided to the orchestrator is not the right one, and you should check which EVM address is registered to your validator. Check the [Register EVM Address](#register-evm-address) section for more information.
 
-If you no longer have access to your EVM address, you could always edit your validator with a new EVM address. This can be done through the `edit-validator` command. Check the next section.
+If you no longer have access to your EVM address, you could always edit your validator with a new EVM address. This can be done through the `edit-validator` command. Check the [Register EVM Address](#register-evm-address) section.
 
 ### Open the P2P port
 
 In order for the signature propagation to be successful, you will need to expose the P2P port, which is by default `30000`.
 
 If not, then the signatures may not be available to the network and relayers will not be able to query them.
 
-#### Register EVM Address
+### Known issues
+
+#### `transport: authentication handshake failed`
+
+```text
+rpc error: code = Unavailable desc = connection error: desc = "transport: authentication handshake failed: tls: first record does not look like a TLS handshake" 
+```
+
+Seeing this error means that the orchestrator/relayer is trying to connect to a gRPC endpoint that is not secure. To bypass this, use the `--grpc.insecure` flag. However, we recommend using secure gRPC connections.
+
+#### `failed to query last valset before nonce (most likely pruned)`
+
+This warning shows that an attestation, that is needed by the orchestrator/relayer, has been pruned from the state machine. However, it's not an issue since we implemented fallback mechanisms that will use the P2P network to get it. And if that doesn't work, connecting the orchestrator/relayer to an archive node will get that attestation.
+
+So, seeing that warning is not a problem.
+
+### Register EVM Address
 
 When creating a validator, a random EVM address corresponding to its operator is set in the Blobstream state. This latter will be used by the orchestrator to sign attestations. And since validators will generally not have access to its corresponding private key, that address needs to be edited with one whose private key is known to the validator operator.
 
@@ -160,13 +175,13 @@ This assumes that you're using the default home directory, the default keystore
 To check which EVM address is registered for your `valoper` address, run the following:
 
 ```sh
-celestia-appd query blobstream evm <validator_valoper_address>
+celestia-appd query qgb evm <validator_valoper_address>
 ```
 
 Then, to proceed with the edit, run the following command:
 
 ```shell
-celestia-appd tx blobstream register \
+celestia-appd tx qgb register \
     <valoper_address> \
     <new_evm_address> \
     --fees 30000utia \
@@ -257,7 +272,7 @@ txhash: 4199EA959A2CFEFCD4726D8D8F7B536458A46A27318D3483A4E9614F560606BC
 Now, you can verify that the EVM address has been updated using the following command:
 
 ```sh
-celestia-appd query blobstream evm <validator_valoper_address>
+celestia-appd query qgb evm <validator_valoper_address>
 ```
 
 Now, you can restart the orchestrator, and it should start signing.
@@ -278,7 +293,7 @@ After=network.target
 
 [Service]
 Type=simple
-ExecStart=<absolute_path_to_blobstream_binary> orchestrator start --evm.account <evm_account> --evm.passphrase <evm_passphrase> --core.grpc.host <grpc_endpoint_host> --core.grpc.port <grpc_endpoint_port> --core.rpc.host <rpc_endpoint_host> --core.rpc.port <rpc_endpoint_port> --p2p.bootstrappers <bootstrappers_list>
+ExecStart=<absolute_path_to_blobstream_binary> orchestrator start --evm.account <evm_account> --evm.passphrase <evm_passphrase>
 LimitNOFILE=infinity
 LimitCORE=infinity
 Restart=always

nodes/blobstream-relayer.md

@@ -1,9 +1,9 @@
 ---
-sidebar_label: Blobstream relayer
-description: Learn about the Blobstream relayer.
+sidebar_label: Blobstream Relayer
+description: Learn about the Blobstream Relayer.
 ---
 
-# Blobstream relayer
+# Blobstream Relayer
 
 <!-- markdownlint-disable MD013 -->
 
@@ -108,20 +108,16 @@ Usage:
   blobstream relayer start <flags> [flags]
 ```
 
+Also, you can set the necessary configuration in the relayers's TOML config file. You can find the latter in the relayer's home directory under `config/config.toml`.
+
+> **_NOTE:_** The CLI flags take precedence over the config files for the same parameters.
+
 To start the relayer using the default home directory, run the following:
 
 ```sh
-/bin/blobstream relayer start \
-  --evm.contract-address=0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 \
-  --core.rpc.host=localhost \
-  --core.rpc.port=26657 \
-  --core.grpc.host=localhost \
-  --core.grpc.port=9090 \
-  --evm.chain-id=4 \
-  --evm.rpc=http://localhost:8545 \
-  --evm.account=0x35a1F8CE94187E4b043f4D57548EF2348Ed556c8 \
-  --p2p.bootstrappers=/ip4/127.0.0.1/tcp/30001/p2p/12D3KooWFFHahpcZcuqnUhpBoX5fJ68Qm5Hc8dxiBcX1oo46fLxh \
-  --p2p.listen-addr=/ip4/0.0.0.0/tcp/30001
+/bin/blobstream relayer start --evm.account=0x35a1F8CE94187E4b043f4D57548EF2348Ed556c8
 ```
 
-And, you will be prompted to enter your EVM key passphrase for the EVM address passed using the `-d` flag, so that the relayer can use it to send transactions to the target Blobstream smart contract. Make sure that it's funded.
+> **_NOTE:_** The above command assumes that the necessary configuration is specified in the  `<relayer_home>/config/config.toml` file.
+
+Then, you will be prompted to enter your EVM key passphrase for the EVM address passed using the `--evm.account` flag, so that the relayer can use it to send transactions to the target Blobstream smart contract. Make sure that it's funded.