From 2c0446fc9825eb91b463a2d8c67488d6cb421fbf Mon Sep 17 00:00:00 2001 From: Josh Stein <46639943+jcstein@users.noreply.github.com> Date: Wed, 11 Oct 2023 16:36:15 -0400 Subject: [PATCH] chore(docs): update QGB to "Blobstream" (#514) * chore: update non-programmatic instances of QGB to "Blobstream" * format with prettier * cleanup extra * * docs: update qgb -> blobstream * Update docs/deploy.md Co-authored-by: CHAMI Rachid --------- Co-authored-by: CHAMI Rachid --- docs/bootstrapper.md | 22 ++++---- docs/deploy.md | 44 +++++++-------- docs/keys.md | 132 +++++++++++++++++++++---------------------- docs/orchestrator.md | 76 ++++++++++++------------- docs/relayer.md | 50 ++++++++-------- 5 files changed, 162 insertions(+), 162 deletions(-) diff --git a/docs/bootstrapper.md b/docs/bootstrapper.md index 9b0abd33..43ce1cdd 100644 --- a/docs/bootstrapper.md +++ b/docs/bootstrapper.md @@ -1,25 +1,25 @@ -# 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 Before starting the bootstrapper, we will need to init the store: ```ssh -qgb bootstrapper init +blobstream bootstrapper init ``` By default, the store will be created un `~/.bootstrapper`. However, if you want to specify a custom location, you can use the `--home` flag. Or, you can use the following environment variable: | Variable | Explanation | Default value | Required | -|---------------------|-------------------------------------|-------------------|----------| +| ------------------- | ----------------------------------- | ----------------- | -------- | | `BOOTSTRAPPER_HOME` | Home directory for the bootstrapper | `~/.bootstrapper` | Optional | ### Add keys @@ -29,7 +29,7 @@ The P2P private key is optional, and a new one will be generated automatically o The `p2p` sub-command will help you set up this key if you want to use a specific one: ```ssh -qgb bootstrapper p2p --help +blobstream bootstrapper p2p --help ``` ### Start the bootstrapper @@ -37,12 +37,12 @@ qgb bootstrapper p2p --help Now that we have the store initialized, we can start the bootstrapper: ```shell -qgb bootstrapper +blobstream bootstrapper -QGB P2P network bootstrapper command +Blobstream P2P network bootstrapper command Usage: - qgb bootstrapper [command] + blobstream bootstrapper [command] Aliases: bootstrapper, bs @@ -50,7 +50,7 @@ Aliases: Flags: -h, --help help for bootstrapper -Use "qgb bootstrapper [command] --help" for more information about a command. +Use "blobstream bootstrapper [command] --help" for more information about a command. ``` ### Open the P2P port diff --git a/docs/deploy.md b/docs/deploy.md index 0108351b..066b3ec9 100644 --- a/docs/deploy.md +++ b/docs/deploy.md @@ -1,45 +1,45 @@ --- -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 -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 +blobstream 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] - qgb deploy [command] + blobstream deploy [flags] + blobstream 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 +blobstream deploy keys --help ``` To import your EVM private key, there is the `import` subcommand to assist you with that: ```ssh -qgb deploy keys evm import --help +blobstream deploy 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). @@ -47,17 +47,17 @@ This subcommand allows you to either import a raw ECDSA private key provided as After adding the key, you can check that it's added via running: ```ssh -qgb deploy keys evm list +blobstream 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 \ +blobstream deploy \ --evm.chain-id 4 \ --evm.contract-address 0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 \ --core.grpc.host localhost \ @@ -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 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. diff --git a/docs/keys.md b/docs/keys.md index aa37e92d..720d7c2d 100644 --- a/docs/keys.md +++ b/docs/keys.md @@ -7,31 +7,31 @@ description: Learn how to manage EVM private keys and P2P identities. -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 -The `qgb orchestrator keys` command manages keys for the orchestrator. By default, it uses the orchestrator default home directory to store the keys: `~/.orchestrator/keystore`. However, the default home can be changed either by specifying a different directory using the `--home` flag or setting the following environment variable: +The `blobstream orchestrator keys` command manages keys for the orchestrator. By default, it uses the orchestrator default home directory to store the keys: `~/.orchestrator/keystore`. However, the default home can be changed either by specifying a different directory using the `--home` flag or setting the following environment variable: -| Variable | Explanation | Default value | Required | -|---------------------|---------------------------------------|-------------------|----------| -| `ORCHESTRATOR_HOME` | Home directory for the orchestrator | `~/.orchestrator` | Optional | +| Variable | Explanation | Default value | Required | +| ------------------- | ----------------------------------- | ----------------- | -------- | +| `ORCHESTRATOR_HOME` | Home directory for the orchestrator | `~/.orchestrator` | Optional | ## Relayer command -The `qgb relayer keys` command manages keys for the relayer. By default, it uses the relayer default home directory to store the keys: `~/.relayer/keystore`. However, the default home can be changed either by specifying a different directory using the `--home` flag or setting the following environment variable: +The `blobstream relayer keys` command manages keys for the relayer. By default, it uses the relayer default home directory to store the keys: `~/.relayer/keystore`. However, the default home can be changed either by specifying a different directory using the `--home` flag or setting the following environment variable: -| Variable | Explanation | Default value | Required | -|---------------------|---------------------------------------|-------------------|----------| -| `RELAYER_HOME` | Home directory for the relayer | `~/.relayer` | Optional | +| Variable | Explanation | Default value | Required | +| -------------- | ------------------------------ | ------------- | -------- | +| `RELAYER_HOME` | Home directory for the relayer | `~/.relayer` | Optional | ## Deploy command -The `qgb deploy keys` command manages keys for the deployer. By default, it uses the deployer default home directory to store the keys: `~/.deployer/keystore`. However, the default home can be changed either by specifying a different directory using the `--home` flag or setting the following environment variable: +The `blobstream deploy keys` command manages keys for the deployer. By default, it uses the deployer default home directory to store the keys: `~/.deployer/keystore`. However, the default home can be changed either by specifying a different directory using the `--home` flag or setting the following environment variable: -| Variable | Explanation | Default value | Required | -|---------------------|---------------------------------------|-------------------|----------| -| `DEPLOYER_HOME` | Home directory for the deploy command | `~/.deployer` | Optional | +| Variable | Explanation | Default value | Required | +| --------------- | ------------------------------------- | ------------- | -------- | +| `DEPLOYER_HOME` | Home directory for the deploy command | `~/.deployer` | Optional | ## Store initialization (!) @@ -48,21 +48,21 @@ As specified above, aside from the difference in the default home directory, the The examples will use the orchestrator command to access the keys. However, the same behaviour applies to the other commands as well. ```ssh -qgb orchestrator keys --help +blobstream orchestrator keys --help -QGB keys manager +Blobstream keys manager Usage: - qgb orchestrator keys [command] + blobstream 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 -Use "qgb orchestrator keys [command] --help" for more information about a command. +Use "blobstream orchestrator keys [command] --help" for more information about a command. ``` ### EVM keystore @@ -72,12 +72,12 @@ The first subcommand of the `keys` command is `evm`. This latter allows managing The EVM keys are `ECDSA` keys using the `secp256k1` curve. The implementation uses `geth` file system keystore [implementation](https://geth.ethereum.org/docs/developers/dapp-developer/native-accounts). Thus, keys can be used interchangeably with any compatible software. ```ssh -qgb orchestrator keys evm --help +blobstream orchestrator keys evm --help -QGB EVM keys manager +Blobstream EVM keys manager Usage: - qgb orchestrator keys evm [command] + blobstream orchestrator keys evm [command] Available Commands: add create a new EVM address @@ -89,7 +89,7 @@ Available Commands: Flags: -h, --help help for evm -Use "qgb orchestrator keys evm [command] --help" for more information about a command. +Use "blobstream orchestrator keys evm [command] --help" for more information about a command. ``` The store also uses the `accounts.StandardScryptN` and `accounts.StandardScryptP` for the `Scrypt` password-based key derivation algorithm to improve its resistance to parallel hardware attacks: @@ -103,12 +103,12 @@ evmKs = keystore.NewKeyStore(evmKeyStorePath(path), keystore.StandardScryptN, ke The `add` subcommand allows creating a new EVM private key and storing it in the keystore: ```ssh -qgb orchestrator keys evm add --help +blobstream orchestrator keys evm add --help create a new EVM address Usage: - qgb orchestrator keys evm add [flags] + blobstream orchestrator keys evm add [flags] ``` The passphrase of the key encryption can be passed as a flag. But it is advised not to pass it as plain text and instead enter it when prompted interactively. @@ -116,10 +116,10 @@ The passphrase of the key encryption can be passed as a flag. But it is advised After creating a new key, you will see its corresponding address printed: ```ssh -qgb orchestrator keys evm add +blobstream orchestrator keys evm add I[2023-04-13|14:16:11.387] successfully opened store path=/home/midnight/.orchestrator -I[2023-04-13|14:16:11.387] please provide a passphrase for your account +I[2023-04-13|14:16:11.387] please provide a passphrase for your account I[2023-04-13|14:16:30.533] account created successfully address=0xaF319b70de80232539ad576f88739afD2dF44187 I[2023-04-13|14:16:30.534] successfully closed store path=/home/midnight/.orchestrator ``` @@ -129,12 +129,12 @@ I[2023-04-13|14:16:30.534] successfully closed store path=/ho The `delete` subcommand allows deleting an EVM private key from store via providing its corresponding address: ```ssh -qgb orchestrator keys evm delete --help +blobstream orchestrator keys evm delete --help delete an EVM addresses from the key store Usage: - qgb orchestrator keys evm delete [flags] + blobstream orchestrator keys evm delete [flags] ``` The provided address should be a `0x` prefixed EVM address. @@ -144,12 +144,12 @@ After running the command, you will be prompted to enter the passphrase for the Then, you will be prompted to confirm that you want to delete that private key. Make sure to verify if you're deleting the right one because once deleted, it can no longer be recovered! ```ssh -qgb orchestrator keys evm delete 0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 +blobstream orchestrator keys evm delete 0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 I[2023-04-13|15:01:41.308] successfully opened store path=/home/midnight/.orchestrator I[2023-04-13|15:01:41.309] deleting account address=0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 -I[2023-04-13|15:01:41.309] please provide the address passphrase -I[2023-04-13|15:01:43.268] Are you sure you want to delete your private key? This action cannot be undone and may result in permanent loss of access to your account. +I[2023-04-13|15:01:41.309] please provide the address passphrase +I[2023-04-13|15:01:43.268] Are you sure you want to delete your private key? This action cannot be undone and may result in permanent loss of access to your account. Please enter 'yes' or 'no' to confirm your decision: yes I[2023-04-13|15:01:45.532] private key has been deleted successfully address=0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 I[2023-04-13|15:01:45.534] successfully closed store path=/home/midnight/.orchestrator @@ -160,11 +160,11 @@ I[2023-04-13|15:01:45.534] successfully closed store path=/ho The `list` subcommand allows listing the existing keys in the keystore: ```ssh -qgb orchestrator keys evm list +blobstream orchestrator keys evm list I[2023-04-13|16:08:45.084] successfully opened store path=/home/midnight/.orchestrator -I[2023-04-13|16:08:45.084] listing accounts available in store -I[2023-04-13|16:08:45.084] 0x7Dd8F9CAfe6D25165249A454F2d0b72FD149Bbba +I[2023-04-13|16:08:45.084] listing accounts available in store +I[2023-04-13|16:08:45.084] 0x7Dd8F9CAfe6D25165249A454F2d0b72FD149Bbba I[2023-04-13|16:08:45.084] successfully closed store path=/home/midnight/.orchestrator ``` @@ -175,23 +175,23 @@ You could specify a different home using the `--home` flag to list the keys in a The `update` subcommand allows changing the EVM private key passphrase to a new one. It takes as argument the `0x` prefixed EVM address corresponding to the private key we want to edit. ```ssh -qgb orchestrator evm update --help +blobstream orchestrator evm update --help update an EVM account passphrase Usage: - qgb orchestrator keys evm update [flags] + blobstream orchestrator keys evm update [flags] ``` Example: ```ssh -qgb orchestrator evm update 0x7Dd8F9CAfe6D25165249A454F2d0b72FD149Bbba +blobstream orchestrator evm update 0x7Dd8F9CAfe6D25165249A454F2d0b72FD149Bbba I[2023-04-13|16:21:17.139] successfully opened store path=/home/midnight/.orchestrator I[2023-04-13|16:21:17.140] updating account address=0x7Dd8F9CAfe6D25165249A454F2d0b72FD149Bbba -I[2023-04-13|16:21:17.140] please provide the address passphrase -I[2023-04-13|16:21:18.134] please provide the address new passphrase +I[2023-04-13|16:21:17.140] please provide the address passphrase +I[2023-04-13|16:21:18.134] please provide the address new passphrase I[2023-04-13|16:21:22.403] successfully updated the passphrase address=0x7Dd8F9CAfe6D25165249A454F2d0b72FD149Bbba I[2023-04-13|16:21:22.420] successfully closed store path=/home/midnight/.orchestrator ``` @@ -205,12 +205,12 @@ The `--home` can be specified if the store is not in the default directory. The `import` subcommand allows importing existing private keys into the keystore. It has two subcommands: `ecdsa` and `file`. The first allows importing a private key in plaintext, while the other allows importing a private key from a JSON file secured with a passphrase. ```ssh -qgb orchestrator keys evm import --help +blobstream orchestrator keys evm import --help import evm keys to the keystore Usage: - qgb orchestrator keys evm import [command] + blobstream orchestrator keys evm import [command] Available Commands: ecdsa import an EVM address from an ECDSA private key @@ -219,7 +219,7 @@ Available Commands: Flags: -h, --help help for import -Use "qgb orchestrator keys evm import [command] --help" for more information about a command. +Use "blobstream orchestrator keys evm import [command] --help" for more information about a command. ``` #### EVM: Import ECDSA @@ -229,11 +229,11 @@ For the first one, it takes as argument the private key in plaintext. Then, it p Example: ```ssh -qgb orchestrator keys evm import ecdsa da6ed55cb2894ac2c9c10209c09de8e8b9d109b910338d5bf3d747a7e1fc9eb7 +blobstream orchestrator keys evm import ecdsa da6ed55cb2894ac2c9c10209c09de8e8b9d109b910338d5bf3d747a7e1fc9eb7 I[2023-04-13|17:00:48.617] successfully opened store path=/home/midnight/.orchestrator -I[2023-04-13|17:00:48.617] importing account -I[2023-04-13|17:00:48.617] please provide the address passphrase +I[2023-04-13|17:00:48.617] importing account +I[2023-04-13|17:00:48.617] please provide the address passphrase I[2023-04-13|17:00:51.989] successfully imported file address=0x6B452Da14195b0aDc3C960E56a078Cf8f50448f8 I[2023-04-13|17:00:51.990] successfully closed store path=/home/midnight/.orchestrator ``` @@ -243,28 +243,28 @@ I[2023-04-13|17:00:51.990] successfully closed store path=/ho For the second, it takes a JSON key file, as defined in [@ethereum/eth-keyfile](https://github.com/ethereum/eth-keyfile), and imports it to your keystore, so it can be used for signatures. ```ssh -qgb orchestrator keys evm import file --help +blobstream orchestrator keys evm import file --help import an EVM address from a file Usage: - qgb orchestrator keys evm import file [flags] + blobstream orchestrator keys evm import file [flags] ``` For example, if we have a file in the current directory containing a private key, we could run the following: ```ssh -qgb orchestrator keys evm import file UTC--2023-04-13T15-00-50.302148204Z--966e6f22781ef6a6a82bbb4db3df8e225dfd9488 +blobstream orchestrator keys evm import file UTC--2023-04-13T15-00-50.302148204Z--966e6f22781ef6a6a82bbb4db3df8e225dfd9488 I[2023-04-13|17:31:53.307] successfully opened store path=/home/midnight/.orchestrator -I[2023-04-13|17:31:53.307] importing account -I[2023-04-13|17:31:53.308] please provide the address passphrase -I[2023-04-13|17:31:54.440] please provide the address new passphrase +I[2023-04-13|17:31:53.307] importing account +I[2023-04-13|17:31:53.308] please provide the address passphrase +I[2023-04-13|17:31:54.440] please provide the address new passphrase I[2023-04-13|17:31:58.436] successfully imported file address=0x966e6f22781EF6a6A82BBB4DB3df8E225DfD9488 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 @@ -273,12 +273,12 @@ Similar to the above EVM keystore, the P2P store has similar subcommands for han To access the P2P keystore, run the following: ```ssh -qgb orchestrator keys p2p +blobstream orchestrator keys p2p -QGB p2p keys manager +Blobstream p2p keys manager Usage: - qgb orchestrator keys p2p [command] + blobstream orchestrator keys p2p [command] Available Commands: add create a new Ed25519 P2P address @@ -289,7 +289,7 @@ Available Commands: Flags: -h, --help help for p2p -Use "qgb orchestrator keys p2p [command] --help" for more information about a command. +Use "blobstream orchestrator keys p2p [command] --help" for more information about a command. ``` The `orchestrator` could be replaced by `relayer` and the only difference would be the default home directory. Aside from that, all the methods defined for the orchestrator will also work with the relayer. @@ -299,18 +299,18 @@ The `orchestrator` could be replaced by `relayer` and the only difference would The `add` subcommand creates a new p2p key to the p2p store: ```ssh -qgb orchestrator keys p2p add --help +blobstream orchestrator keys p2p add --help create a new Ed25519 P2P address Usage: - qgb orchestrator keys p2p add [flags] + blobstream orchestrator keys p2p add [flags] ``` It takes as argument an optional `` which would be the name that we can use to reference that private key. If not specified, an incremental nickname will be assigned. ```ssh -qgb orchestrator keys p2p add +blobstream orchestrator keys p2p add I[2023-04-13|17:38:17.289] successfully opened store path=/home/midnight/.orchestrator I[2023-04-13|17:38:17.290] generating a new Ed25519 private key nickname=1 @@ -327,12 +327,12 @@ The nickname will be needed in case the orchestrator needs to use a specific pri The `delete` subcommand will delete a P2P private key from store referenced by its nickname: ```ssh -qgb orchestrator keys p2p delete --help +blobstream orchestrator keys p2p delete --help delete an Ed25519 P2P private key from store Usage: - qgb orchestrator keys p2p delete [flags] + blobstream orchestrator keys p2p delete [flags] ``` #### P2P: Import subcommand @@ -340,12 +340,12 @@ Usage: The `import` subcommand will import an existing Ed25519 private key to the store. It takes as argument the nickname that we wish to save the private key under, and the actual private key in hex format without `0x`: ```ssh -qgb orchestrator keys p2p import --help +blobstream orchestrator keys p2p import --help import an existing p2p private key Usage: - qgb orchestrator keys p2p import [flags] + blobstream orchestrator keys p2p import [flags] ``` #### P2P: List subcommand @@ -353,10 +353,10 @@ Usage: The `list` subcommand lists the existing P2P private keys in the store: ```ssh -qgb orchestrator keys p2p list --help +blobstream orchestrator keys p2p list --help list existing p2p addresses Usage: - qgb orchestrator keys p2p list [flags] + blobstream orchestrator keys p2p list [flags] ``` diff --git a/docs/orchestrator.md b/docs/orchestrator.md index cf225ad5..f623ee96 100644 --- a/docs/orchestrator.md +++ b/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 -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. @@ -24,7 +24,7 @@ The orchestrator connects to a separate P2P network than the consensus or the da Bootstrapper for the Blockspace Race is: -* `/dns/bootstr-incent-1.celestia.tools/tcp/30000/p2p/12D3KooWSGZ2LXW2soQFHgU82uLfN7pNW5gMMkTnu1fhMXG43TvP` +- `/dns/bootstr-incent-1.celestia.tools/tcp/30000/p2p/12D3KooWSGZ2LXW2soQFHgU82uLfN7pNW5gMMkTnu1fhMXG43TvP` Make sure to specify it using the `-b` flag when running the orchestrator. @@ -42,34 +42,34 @@ I[2023-04-26|00:04:28.175] waiting for routing table to populate targetnu To run an orchestrator, you will need to have access to the following: -* *Access to your EVM address private key. This latter doesn't need to be funded in any network. If yours is not yet set, check the [register an EVM address](#register-evm-address) section. -* *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. +- Access to your EVM address private key. This latter doesn't need to be funded in any network. If yours is not yet set, check the [register an EVM address](#register-evm-address) section. +- 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 Before starting the orchestrator, we will need to init the store: ```ssh -qgb orchestrator init +blobstream orchestrator init ``` By default, the store will be created under `~/.orchestrator`. However, if you want to specify a custom location, you can use the `--home` flag. Or, you can use the following environment variable: -| Variable | Explanation | Default value | Required | -|---------------------|---------------------------------------|-------------------|----------| -| `ORCHESTRATOR_HOME` | Home directory for the orchestrator | `~/.orchestrator` | Optional | +| Variable | Explanation | Default value | Required | +| ------------------- | ----------------------------------- | ----------------- | -------- | +| `ORCHESTRATOR_HOME` | Home directory for the orchestrator | `~/.orchestrator` | Optional | ### Add keys In order for the orchestrator to start, it will need two private keys: -* *EVM private key -* *P2P private key +- EVM private key +- P2P private key The EVM private key is the most important one since it needs to correspond to the EVM address provided when creating the validator. @@ -78,7 +78,7 @@ The P2P private key is optional, and a new one will be generated automatically o The `keys` command will help you set up these keys: ```ssh -qgb orchestrator keys --help +blobstream orchestrator keys --help ``` To add an EVM private key, check the next section. @@ -92,7 +92,7 @@ To register an EVM address for your validator, check the section [Register EVM A To import your EVM private key, there is the `import` subcommand to assist you with that: ```ssh -qgb orchestrator keys evm import --help +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). @@ -100,10 +100,10 @@ This subcommand allows you to either import a raw ECDSA private key provided as After adding the key, you can check that it's added via running: ```ssh -qgb orchestrator keys evm list +blobstream 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 @@ -112,18 +112,18 @@ Now that we have the store initialized, we can start the orchestrator. Make sure The orchestrator accepts the following flags: ```ssh -qgb orchestrator start --help +blobstream orchestrator start --help -Starts the QGB orchestrator to sign attestations +Starts the Blobstream orchestrator to sign attestations Usage: - qgb orchestrator start [flags] + blobstream orchestrator start [flags] ``` To start the orchestrator in the default home directory, run the following: ```ssh -qgb orchestrator start \ +blobstream orchestrator start \ --core.grpc.host localhost \ --core.grpc.port 9090 \ --core.rpc.host localhost \ @@ -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. @@ -160,13 +160,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: ```ssh -celestia-appd query qgb evm +celestia-appd query blobstream evm ``` Then, to proceed with the edit, run the following command: ```shell -celestia-appd tx qgb register \ +celestia-appd tx blobstream register \ \ \ --fees 30000utia \ @@ -244,11 +244,11 @@ logs: - events: - attributes: - key: action - value: /celestia.qgb.v1.MsgRegisterEVMAddress + value: /celestia.blobstream.v1.MsgRegisterEVMAddress type: message log: "" msg_index: 0 -raw_log: '[{"msg_index":0,"events":[{"type":"message","attributes":[{"key":"action","value":"/celestia.qgb.v1.MsgRegisterEVMAddress"}]}]}]' +raw_log: '[{"msg_index":0,"events":[{"type":"message","attributes":[{"key":"action","value":"/celestia.blobstream.v1.MsgRegisterEVMAddress"}]}]}]' timestamp: "" tx: null txhash: 4199EA959A2CFEFCD4726D8D8F7B536458A46A27318D3483A4E9614F560606BC @@ -257,7 +257,7 @@ txhash: 4199EA959A2CFEFCD4726D8D8F7B536458A46A27318D3483A4E9614F560606BC Now, you can verify that the EVM address has been updated using the following command: ```ssh -celestia-appd query qgb evm +celestia-appd query blobstream evm ``` Now, you can restart the orchestrator, and it should start signing. @@ -268,17 +268,17 @@ Note: A validator set change is triggered if more than 5% of the total staking p If you want to start the orchestrator as a `systemd` service, you could use the following: -* *Make sure you have the store initialized and the EVM address private key imported. Check the above sections for how to do that. -* *Put the following configuration under: `/etc/systemd/system/orchestrator.service`: +- Make sure you have the store initialized and the EVM address private key imported. Check the above sections for how to do that. +- Put the following configuration under: `/etc/systemd/system/orchestrator.service`: ```text [Unit] -Description=QGB orchestrator service +Description=Blobstream orchestrator service After=network.target [Service] Type=simple -ExecStart= orchestrator start --evm.account --evm.passphrase --core.grpc.host --core.grpc.port --core.rpc.host --core.rpc.port --p2p.bootstrappers +ExecStart= orchestrator start --evm.account --evm.passphrase --core.grpc.host --core.grpc.port --core.rpc.host --core.rpc.port --p2p.bootstrappers LimitNOFILE=infinity LimitCORE=infinity Restart=always @@ -293,13 +293,13 @@ TTYPath=/dev/tty0 WantedBy=multi-user.target ``` -* *Start the orchestrator service using: +- Start the orchestrator service using: ```shell sudo systemctl start orchestrator ``` -* Follow the logs to see if everything is running correctly: +- Follow the logs to see if everything is running correctly: ```shell sudo journalctl -f -u orchestrator diff --git a/docs/relayer.md b/docs/relayer.md index 1e698521..1afbc822 100644 --- a/docs/relayer.md +++ b/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 -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 `blobstream 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,23 +36,23 @@ 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 Before starting the relayer, we will need to init the store: ```ssh -qgb relayer init +blobstream relayer init ``` By default, the store will be created un `~/.relayer`. However, if you want to specify a custom location, you can use the `--home` flag. Or, you can use the following environment variable: -| Variable | Explanation | Default value | Required | -|---------------------|---------------------------------------|-------------------|----------| -| `RELAYER_HOME` | Home directory for the relayer | `~/.relayer` | Optional | +| Variable | Explanation | Default value | Required | +| -------------- | ------------------------------ | ------------- | -------- | +| `RELAYER_HOME` | Home directory for the relayer | `~/.relayer` | Optional | ### Add keys @@ -68,7 +68,7 @@ The P2P private key is optional, and a new one will be generated automatically o The `keys` command will help you set up these keys: ```ssh -qgb relayer keys --help +blobstream relayer keys --help ``` To add an EVM private key, check the next section. @@ -80,7 +80,7 @@ Because EVM keys are important, we provide a keystore that will help manage them To import your EVM private key, there is the `import` subcommand to assist you with that: ```ssh -qgb relayer keys evm import --help +blobstream relayer 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). @@ -88,30 +88,30 @@ This subcommand allows you to either import a raw ECDSA private key provided as After adding the key, you can check that it's added via running: ```ssh -qgb relayer keys evm list +blobstream 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 +blobstream 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] + blobstream relayer start [flags] ``` To start the relayer using the default home directory, run the following: ```ssh -/bin/qgb relayer start \ +/bin/blobstream relayer start \ --evm.contract-address=0x27a1F8CE94187E4b043f4D57548EF2348Ed556c7 \ --core.rpc.host=localhost \ --core.rpc.port=26657 \ @@ -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.