chore: update non-programmatic instances of QGB to "Blobstream"

docs/bootstrapper.md

@@ -1,12 +1,12 @@
-# QGB bootstrapper
+# Blobstream bootstrapper
 
-To bootstrap the QGB P2P network, we use the bootstrapper QGB node type to accept connections from freshly created orchestrators/relayers and share its peer table with them.
+To bootstrap the Blobstream P2P network, we use the bootstrapper Blobstream node type to accept connections from freshly created orchestrators/relayers and share its peer table with them.
 
 ## How to run
 
-### Install the QGB binary
+### Install the Blobstream binary
 
-Make sure to have the QGB binary installed. Check [the QGB binary page](https://docs.celestia.org/nodes/qgb-binary) for more details.
+Make sure to have the Blobstream binary installed. Check [the Blobstream binary page](https://docs.celestia.org/nodes/blobstream-binary) for more details.
 
 ### Init the store
 
@@ -39,7 +39,7 @@ Now that we have the store initialized, we can start the bootstrapper:
 ```shell
 qgb bootstrapper
 
-QGB P2P network bootstrapper command
+Blobstream P2P network bootstrapper command
 
 Usage:
   qgb bootstrapper [command]

docs/deploy.md

@@ -1,36 +1,36 @@
 ---
-sidebar_label: Deploy the QGB contract
-description: Learn how to deploy the QGB smart contract.
+sidebar_label: Deploy the Blobstream contract
+description: Learn how to deploy the Blobstream smart contract.
 ---
 
-# Deploy the QGB contract
+# Deploy the Blobstream contract
 
 <!-- markdownlint-disable MD013 -->
 
-The `deploy` is a helper command that allows deploying the QGB smart contract to a new EVM chain:
+The `deploy` is a helper command that allows deploying the Blobstream smart contract to a new EVM chain:
 
 ```ssh
 qgb deploy --help
 
-Deploys the QGB contract and initializes it using the provided Celestia chain
+Deploys the Blobstream contract and initializes it using the provided Celestia chain
 
 Usage:
   qgb deploy <flags> [flags]
   qgb deploy [command]
 
 Available Commands:
-  keys        QGB keys manager
+  keys        Blobstream keys manager
 ```
 
 ## How to run
 
-### Install the QGB binary
+### Install the Blobstream binary
 
-Make sure to have the QGB binary installed. Check [the QGB binary page](https://docs.celestia.org/nodes/qgb-binary) for more details.
+Make sure to have the Blobstream binary installed. Check [the Blobstream binary page](https://docs.celestia.org/nodes/blobstream-binary) for more details.
 
 ### Add keys
 
-In order to deploy a QGB smart contract, you will need a funded EVM address and its private key. The `keys` command will help you set up this key:
+In order to deploy a Blobstream smart contract, you will need a funded EVM address and its private key. The `keys` command will help you set up this key:
 
 ```ssh
 qgb deploy keys  --help
@@ -50,11 +50,11 @@ After adding the key, you can check that it's added via running:
 qgb deploy keys evm list
 ```
 
-For more information about the `keys` command, check [the `keys` documentation](https://docs.celestia.org/nodes/qgb-keys).
+For more information about the `keys` command, check [the `keys` documentation](https://docs.celestia.org/nodes/blobstream-keys).
 
 ### Deploy the contract
 
-Now, we can deploy the QGB contract to a new EVM chain:
+Now, we can deploy the Blobstream contract to a new EVM chain:
 
 ```ssh
 qgb deploy \
@@ -68,8 +68,8 @@ qgb deploy \
 
 The `latest` can be replaced by the following:
 
-- `latest`: to deploy the QGB contract starting from the latest validator set.
-- `earliest`: to deploy the QGB contract starting from genesis.
-- `nonce`: you can provide a custom nonce on where you want the QGB to start. If the provided nonce is not a `Valset` attestation, then the one before it will be used to deploy the QGB smart contract.
+- `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 the 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.
 
-And, now you will see the QGB smart contract address in the logs along with the transaction hash.
+And, now you will see the Blobstream smart contract address in the logs along with the transaction hash.

docs/keys.md

@@ -7,7 +7,7 @@ description: Learn how to manage EVM private keys and P2P identities.
 
 <!-- markdownlint-disable MD013 -->
 
-The QGB `keys` command allows managing EVM private keys and P2P identities. It is defined as a subcommand for multiple commands with the only difference being the directory where the keys are stored. For the remaining functionality, it is the same for all the commands.
+The Blobstream `keys` command allows managing EVM private keys and P2P identities. It is defined as a subcommand for multiple commands with the only difference being the directory where the keys are stored. For the remaining functionality, it is the same for all the commands.
 
 ## Orchestrator command
 
@@ -50,14 +50,14 @@ The examples will use the orchestrator command to access the keys. However, the
 ```ssh
 qgb orchestrator keys --help
 
-QGB keys manager
+Blobstream keys manager
 
 Usage:
   qgb orchestrator keys [command]
 
 Available Commands:
-  evm         QGB EVM keys manager
-  p2p         QGB p2p keys manager
+  evm         Blobstream EVM keys manager
+  p2p         Blobstream p2p keys manager
 
 Flags:
   -h, --help   help for keys
@@ -74,7 +74,7 @@ The EVM keys are `ECDSA` keys using the `secp256k1` curve. The implementation us
 ```ssh
 qgb orchestrator keys evm --help
 
-QGB EVM keys manager
+Blobstream EVM keys manager
 
 Usage:
   qgb orchestrator keys evm [command]
@@ -264,7 +264,7 @@ I[2023-04-13|17:31:58.436] successfully imported file                   address=
 I[2023-04-13|17:31:58.437] successfully closed store                    path=/home/midnight/.orchestrator
 ```
 
-with the `passphrase` being the current file passphrase, and the `new passphrase` being the new passphrase that will be used to encrypt the private key in the QGB store.
+with the `passphrase` being the current file passphrase, and the `new passphrase` being the new passphrase that will be used to encrypt the private key in the Blobstream store.
 
 ### P2P keystore
 
@@ -275,7 +275,7 @@ To access the P2P keystore, run the following:
 ```ssh
 qgb orchestrator keys p2p
 
-QGB p2p keys manager
+Blobstream p2p keys manager
 
 Usage:
   qgb orchestrator keys p2p [command]

docs/orchestrator.md

@@ -1,22 +1,22 @@
 ---
-sidebar_label: QGB Orchestrator
-description: Learn about the QGB Orchestrator.
+sidebar_label: Blobstream Orchestrator
+description: Learn about the Blobstream Orchestrator.
 ---
 
-# QGB Orchestrator
+# Blobstream Orchestrator
 
 <!-- markdownlint-disable MD013 -->
 <!-- markdownlint-disable MD010 -->
 
-The role of the orchestrator is to sign attestations using its corresponding validator EVM private key. These attestations are generated within the QGB module of the Celestia-app state machine. To learn more about what attestations are, you can refer to [the QGB overview](https://github.com/celestiaorg/celestia-app/tree/main/x/qgb).
+The role of the orchestrator is to sign attestations using its corresponding validator EVM private key. These attestations are generated within the Blobstream module of the Celestia-app state machine. To learn more about what attestations are, you can refer to [the Blobstream overview](https://github.com/celestiaorg/celestia-app/tree/main/x/blobstream).
 
 ## How it works
 
 The orchestrator does the following:
 
 1. Connect to a Celestia-app full node or validator node via RPC and gRPC and wait for new attestations
-2. Once an attestation is created inside the QGB state machine, the orchestrator queries it.
-3. After getting the attestation, the orchestrator signs it using the provided EVM private key. The private key should correspond to the EVM address provided when creating the validator. Read [more about QGB keys](https://docs.celestia.org/nodes/qgb-keys/).
+2. Once an attestation is created inside the Blobstream state machine, the orchestrator queries it.
+3. After getting the attestation, the orchestrator signs it using the provided EVM private key. The private key should correspond to the EVM address provided when creating the validator. Read [more about Blobstream keys](https://docs.celestia.org/nodes/blobstream-keys/).
 4. Then, the orchestrator pushes its signature to the P2P network it is connected to, via adding it as a DHT value.
 5. Listen for new attestations and go back to step 2.
 
@@ -46,9 +46,9 @@ To run an orchestrator, you will need to have access to the following:
 * *A list of bootstrappers for the P2P network. These will be shared by the team for every network we plan on supporting.
 * *Access to your consensus node RPC and gRPC ports.
 
-### Install the QGB binary
+### Install the Blobstream binary
 
-Make sure to have the QGB binary installed. Check [the QGB binary page](https://docs.celestia.org/nodes/qgb-binary) for more details.
+Make sure to have the Blobstream binary installed. Check [the Blobstream binary page](https://docs.celestia.org/nodes/blobstream-binary) for more details.
 
 ### Init the store
 
@@ -103,7 +103,7 @@ After adding the key, you can check that it's added via running:
 qgb orchestrator keys evm list
 ```
 
-For more information about the `keys` command, check [the `keys` documentation](https://docs.celestia.org/nodes/qgb-keys).
+For more information about the `keys` command, check [the `keys` documentation](https://docs.celestia.org/nodes/blobstream-keys).
 
 ### Start the orchestrator
 
@@ -114,7 +114,7 @@ The orchestrator accepts the following flags:
 ```ssh
 qgb orchestrator start --help
 
-Starts the QGB orchestrator to sign attestations
+Starts the Blobstream orchestrator to sign attestations
 
 Usage:
   qgb orchestrator start <flags> [flags]
@@ -145,7 +145,7 @@ If not, then the signatures may not be available to the network and relayers wil
 
 #### Register EVM Address
 
-When creating a validator, a random EVM address corresponding to its operator is set in the QGB 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.
+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.
 
 To edit an EVM address for a certain validator, its corresponding account needs to send a `RegisterEVMAddress` transaction with the new address.
 
@@ -273,7 +273,7 @@ If you want to start the orchestrator as a `systemd` service, you could use the
 
 ```text
 [Unit]
-Description=QGB orchestrator service
+Description=Blobstream orchestrator service
 After=network.target
 
 [Service]

docs/relayer.md

@@ -1,27 +1,27 @@
 ---
-sidebar_label: QGB Relayer
-description: Learn about the QGB Relayer.
+sidebar_label: Blobstream Relayer
+description: Learn about the Blobstream Relayer.
 ---
 
-# QGB Relayer
+# Blobstream Relayer
 
 <!-- markdownlint-disable MD013 -->
 
-The role of the relayer is to gather attestations' signatures from the orchestrators, and submit them to a target EVM chain. The attestations are generated within the QGB module of the Celestia-app state machine. To learn more about what attestations are, you can refer to [the QGB overview](https://github.com/celestiaorg/celestia-app/tree/main/x/qgb).
+The role of the relayer is to gather attestations' signatures from the orchestrators, and submit them to a target EVM chain. The attestations are generated within the Blobstream module of the Celestia-app state machine. To learn more about what attestations are, you can refer to [the Blobstream overview](https://github.com/celestiaorg/celestia-app/tree/main/x/blobstream).
 
-Also, while every validator in the Celestia validator set needs to run an orchestrator, we only need one entity to run the relayer, and it can be anyone. Thus, if you're a validator, most likely you want to read [the orchestrator documentation](https://docs.celestia.org/nodes/qgb-orchestrator/).
+Also, while every validator in the Celestia validator set needs to run an orchestrator, we only need one entity to run the relayer, and it can be anyone. Thus, if you're a validator, most likely you want to read [the orchestrator documentation](https://docs.celestia.org/nodes/blobstream-orchestrator/).
 
-Every relayer needs to target a QGB smart contract. This latter can be deployed, if not already, using the `qgb deploy` command. More details in the [Deploy the QGB contract guide](https://docs.celestia.org/nodes/qgb-deploy/).
+Every relayer needs to target a Blobstream smart contract. This latter can be deployed, if not already, using the `qgb deploy` command. More details in the [Deploy the Blobstream contract guide](https://docs.celestia.org/nodes/blobstream-deploy/).
 
 ## How it works
 
 The relayer works as follows:
 
 1. Connect to a Celestia-app full node or validator node via RPC and gRPC and wait for attestations.
-2. Once an attestation is created inside the QGB state machine, the relayer queries it.
-3. After getting the attestation, the relayer checks if the target QGB smart contract's nonce is lower than the attestation.
+2. Once an attestation is created inside the Blobstream state machine, the relayer queries it.
+3. After getting the attestation, the relayer checks if the target Blobstream smart contract's nonce is lower than the attestation.
 4. If so, the relayer queries the P2P network for signatures from the orchestrators.
-5. Once the relayer finds more than 2/3s signatures, it submits them to the target QGB smart contract where they get validated.
+5. Once the relayer finds more than 2/3s signatures, it submits them to the target Blobstream smart contract where they get validated.
 6. Listen for new attestations and go back to step 2.
 
 The relayer connects to a separate P2P network than the consensus or the data availability one. So, we will provide bootstrappers for that one.
@@ -36,9 +36,9 @@ I[2023-04-26|00:04:28.175] waiting for routing table to populate        targetnu
 
 ## How to run
 
-### Install the QGB binary
+### Install the Blobstream binary
 
-Make sure to have the QGB binary installed. Check out the [Install the QGB binary page](https://docs.celestia.org/nodes/qgb-binary) for more details.
+Make sure to have the Blobstream binary installed. Check out the [Install the Blobstream binary page](https://docs.celestia.org/nodes/blobstream-binary) for more details.
 
 ### Init the store
 
@@ -91,18 +91,18 @@ After adding the key, you can check that it's added via running:
 qgb relayer keys evm list
 ```
 
-For more information about the `keys` command, check [the `keys` documentation](https://docs.celestia.org/nodes/qgb-keys).
+For more information about the `keys` command, check [the `keys` documentation](https://docs.celestia.org/nodes/blobstream-keys).
 
 ### Start the relayer
 
-Now that we have the store initialized, and we have a target QGB smart contract address, we can start the relayer. Make sure you have your Celestia-app node RPC and gRPC accessible, and able to connect to the P2P network bootstrappers.
+Now that we have the store initialized, and we have a target Blobstream smart contract address, we can start the relayer. Make sure you have your Celestia-app node RPC and gRPC accessible, and able to connect to the P2P network bootstrappers.
 
 The relayer accepts the following flags:
 
 ```ssh
 qgb relayer start --help
 
-Runs the QGB relayer to submit attestations to the target EVM chain
+Runs the Blobstream relayer to submit attestations to the target EVM chain
 
 Usage:
   qgb relayer start <flags> [flags]
@@ -124,4 +124,4 @@ To start the relayer using the default home directory, run the following:
   --p2p.listen-addr=/ip4/0.0.0.0/tcp/30001
 ```
 
-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 QGB smart contract. Make sure that it's funded.
+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.