Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[docs]: New configuration reference #397

Open
wants to merge 80 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 36 commits
Commits
Show all changes
80 commits
Select commit Hold shift + click to select a range
15d9ea4
[misc]: update deps
0x009922 Aug 30, 2023
6b17267
[style]: remove brand colors and `SButton`; revert prettier
0x009922 Aug 30, 2023
d13775b
[refactor]: use headless dialog; revert plugin-pwa
0x009922 Sep 1, 2023
793959a
[chore]: disable `vue/no-v-html` in Mermaid
0x009922 Sep 1, 2023
122f05f
[refactor]: remove sora components from MermaidRender
0x009922 Sep 1, 2023
c472637
[chore]: format
0x009922 Sep 1, 2023
6bd761d
[chore]: remove `@soramitsu-ui/*` packages
0x009922 Sep 1, 2023
15f8e10
[refactor]: remove `vite-plugin-pwa`
0x009922 Sep 1, 2023
6d39164
[docs]: introduce "Reference" section
0x009922 Sep 8, 2023
6a9e6dd
[chore]: remove logo temporarily
0x009922 Sep 8, 2023
1d091a7
Merge branch 'service-update' into 392-draft-config-reference
0x009922 Sep 8, 2023
29736bd
[chore]: fix ffi link
0x009922 Sep 8, 2023
c88c48e
[chore]: update deps
0x009922 Sep 11, 2023
17fc897
[refactor]: simplify logging, remove `log-update`
0x009922 Sep 11, 2023
e123ac0
Merge branch 'service-update' into 392-draft-config-reference
0x009922 Sep 11, 2023
f6bb470
[docs]: change headings
0x009922 Sep 11, 2023
e2ecaa7
[docs]: format chores
0x009922 Sep 11, 2023
6786935
Merge remote-tracking branch 'hyperledger/main' into service-update
0x009922 Sep 15, 2023
ce9bf11
[chore]: update pnpm
0x009922 Sep 15, 2023
5828496
[fix]: remove `SSpinner` import
0x009922 Sep 15, 2023
134a275
[chore]: bump vitepress
0x009922 Sep 15, 2023
de585ca
[fix]: fix version of unocss
0x009922 Sep 15, 2023
4bafdab
[chore]: fix format
0x009922 Sep 15, 2023
cd0cede
[chore]: bump vitepress to `rc.14`
0x009922 Sep 18, 2023
1fe2a67
Merge branch 'service-update' into 392-draft-config-reference
0x009922 Sep 18, 2023
cbe8885
[docs]: use tex math syntax across
0x009922 Sep 18, 2023
13fe5ce
[docs]: move `/reference/` to `/api/`; split config reference
0x009922 Sep 18, 2023
5e2265a
[docs]: describe duration type
0x009922 Sep 18, 2023
eff21b2
[docs]: describe byte size type
0x009922 Sep 18, 2023
18b614b
[docs]: remove `*.actor-channel-capacity`
0x009922 Sep 18, 2023
32008ad
[fix]: dead links
0x009922 Sep 18, 2023
2adbbf9
[docs]: restore `snake_case`
0x009922 Sep 20, 2023
cfabb36
[docs]: update config reference
0x009922 Sep 21, 2023
6d88337
Merge branch 'main' into 392-draft-config-reference
0x009922 Sep 21, 2023
c9e4fcf
[chore]: remove dead code
0x009922 Sep 21, 2023
07fd463
Apply suggestions from code review
0x009922 Sep 22, 2023
60edf4e
Apply suggestions from code review
yamkovoy Sep 26, 2023
a0bc81f
[docs]: use TODO marks
0x009922 Sep 27, 2023
b1c7ef8
[docs]: add Snapshot section
0x009922 Sep 27, 2023
12a026d
Merge remote-tracking branch '0x009922/392-draft-config-reference' in…
0x009922 Sep 27, 2023
2db62aa
[chore]: fix format
0x009922 Sep 27, 2023
08532e0
[docs]: change TODO notation
0x009922 Sep 27, 2023
bb938ef
Merge branch 'main' into 392-draft-config-reference
0x009922 Sep 27, 2023
35a0974
Apply suggestions from code review
0x009922 Sep 29, 2023
5b3dd60
Merge branch 'main' into 392-draft-config-reference
0x009922 Sep 29, 2023
0efcf1c
[docs]: put TODOs
0x009922 Sep 29, 2023
ea286e6
Merge remote-tracking branch '0x009922/392-draft-config-reference' in…
0x009922 Sep 29, 2023
9dd1a49
[chore]: remove dead sidebar link
0x009922 Sep 29, 2023
76b850c
[docs]: expand logger params
0x009922 Sep 29, 2023
38dd466
[docs]: expand sections, update naming, rethink structure
0x009922 Sep 29, 2023
6688e80
Apply suggestions from code review
0x009922 Oct 2, 2023
d5d1156
[docs]: refactor the reference
0x009922 Oct 4, 2023
e9aa302
[chore]: fix typo and format
0x009922 Oct 4, 2023
fc9bd81
[docs]: combine sumeragi and block_sync
0x009922 Oct 4, 2023
2750023
Merge branch 'main' into 392-draft-config-reference
0x009922 Oct 10, 2023
df7415b
[docs]: torii bindings
0x009922 Oct 10, 2023
bde027d
Apply suggestions from code review
0x009922 Oct 20, 2023
b86a04c
Update src/api/config/sumeragi-params.md
0x009922 Oct 23, 2023
5e5582a
bunch of updates
0x009922 Nov 3, 2023
b9177e7
Merge remote-tracking branch 'hyperledger/main' into 392-draft-config…
0x009922 Nov 3, 2023
0d949c6
Merge remote-tracking branch '0x009922/392-draft-config-reference' in…
0x009922 Nov 3, 2023
f74845e
[docs]: fix broken link
0x009922 Nov 3, 2023
99698dd
[docs]: a bunch of edits of config
0x009922 Nov 22, 2023
7d9c926
[docs]: update configuration guides (wip)
0x009922 Nov 22, 2023
128e675
Merge branch 'main' into 392-draft-config-reference
0x009922 Nov 22, 2023
2be984d
Merge branch 'main' into 392-draft-config-reference
0x009922 Feb 12, 2024
4c78fe2
[chore]: update deps
0x009922 Feb 12, 2024
8841a0b
[chore]: `type: module`, fixing warning from Vitest
0x009922 Feb 12, 2024
3d26c72
[revert]: project is not ready for ESM
0x009922 Feb 12, 2024
c704b6f
Merge branch 'housekeeping' into 392-draft-config-reference
0x009922 Feb 12, 2024
a96fa91
[docs]: update reference section
0x009922 Feb 21, 2024
b21c68e
[docs]: migration guide; edits
0x009922 Mar 25, 2024
cfe5ae4
[revert]: remove `Specs` component
0x009922 Mar 25, 2024
dfd5498
[feat]: add sidebar link
0x009922 Mar 25, 2024
ca2f813
[chore]: fix format
0x009922 Mar 25, 2024
eb231f3
misc: update dependencies
Nov 7, 2024
aae25ba
Merge branch 'housekeeping' into 392-draft-config-reference
Nov 7, 2024
9fe82b7
docs: revamp config reference
Nov 8, 2024
1e3b453
Merge branch 'main' into 392-draft-config-reference
0x009922 Nov 8, 2024
39cfe97
docs: fix links
0x009922 Nov 8, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
132 changes: 113 additions & 19 deletions .vitepress/config.mts
Original file line number Diff line number Diff line change
Expand Up @@ -16,9 +16,9 @@ function getNav(): DefaultTheme.NavItem[] {
activeMatch: '^/$|^/guide/',
},
{
text: 'Schema',
link: '/data-model-schema/',
activeMatch: '^/data-model-schema/',
text: 'API',
link: '/api/',
activeMatch: '^/api/',
},
]
}
Expand Down Expand Up @@ -222,6 +222,10 @@ function getGuideSidebar(): DefaultTheme.SidebarItem[] {
text: 'Metadata and Store assets',
link: '/guide/configure/metadata-and-store-assets',
},
{
text: '[wip] Reference',
link: '/configuration-reference',
},
],
},
{
Expand Down Expand Up @@ -280,19 +284,19 @@ function getGuideSidebar(): DefaultTheme.SidebarItem[] {
},
],
},
{
text: 'API',
items: [
{
text: 'Specification',
link: '/api/index.md',
},
{
text: 'Foreign Function Interfaces',
link: '/api/ffi',
},
],
},
// {
// text: 'API',
// items: [
// {
// text: 'Specification',
// link: '/api/index.md',
// },
// {
// text: 'Foreign Function Interfaces',
// link: '/api/ffi',
// },
// ],
// },
{
text: 'Documenting Iroha',
items: [
Expand Down Expand Up @@ -367,6 +371,7 @@ export default defineConfig({
themeConfig: {
// logo: '/icon.svg',
siteTitle: 'Iroha 2',
outline: 'deep',

socialLinks: [
{ icon: 'github', link: 'https://github.com/hyperledger/iroha-2-docs' },
Expand All @@ -392,11 +397,100 @@ export default defineConfig({

sidebar: {
'/guide/': getGuideSidebar(),
'/data-model-schema': [
'/api/': [
{
text: 'Overview',
link: '/api/',
},
{
text: 'Configuration',
link: '/api/configuration',
},
{
text: 'Command Line Interface (CLI)',
link: '/api/cli',
},
{
text: 'API Specification',
link: '/api/api',
},
{
text: 'Foreign Function Interfaces (FFI)',
link: '/api/ffi',
},
{
text: 'Configuration',
items: [
{
text: 'Overview',
link: '/api/config/',
},
{
text: 'Parameters',
items: [
{
text: 'Base',
link: '/api/config/base-params',
},
{
text: 'Genesis',
link: '/api/config/genesis-params',
},
{
text: 'Network',
link: '/api/config/network-params',
},
{
text: 'Sumeragi',
link: '/api/config/sumeragi-params',
},
{
text: 'Torii',
link: '/api/config/torii-params',
},
{
text: 'Queue',
link: '/api/config/queue-params',
},
{
text: 'Kura',
link: '/api/config/kura-params',
},
{
text: 'Logger',
link: '/api/config/logger-params',
},
{
text: 'Block Sync',
link: '/api/config/block-sync-params',
},
{
text: 'WSV',
link: '/api/config/wsv-params',
},
{
text: 'Telemetry',
link: '/api/config/telemetry-params',
},

],
},

{
text: 'Glossary',
link: '/api/config/glossary',
},
{
text: 'Deprecation and Migration',
link: '/api/config/deprecation-and-migration',
},
],
},
{
text: 'Channel',
text: 'Data Model Schema',
link: '/api/data-model-schema/',
items: ['stable', 'lts', 'dev'].map((channel) => ({
link: `/data-model-schema/${channel}`,
link: `/api/data-model-schema/${channel}`,
text: `iroha2-${channel}`,
})),
},
Expand Down
20 changes: 20 additions & 0 deletions src/api/api.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
<script setup>
import { useData } from 'vitepress'

const { page } = useData()
</script>

# API Specification

::: info

This page contains a copy of `api_spec.md` from
yamkovoy marked this conversation as resolved.
Show resolved Hide resolved
`hyperledger/iroha#iroha2-dev`. You can read the most up-to-date version of
yamkovoy marked this conversation as resolved.
Show resolved Hide resolved
it on
yamkovoy marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
it on
it in

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use in case you pick my suggestion below

[GitHub](https://github.com/hyperledger/iroha/blob/iroha2-dev/docs/source/references/api_spec.md).
0x009922 marked this conversation as resolved.
Show resolved Hide resolved

Please note this page was last updated on <b>{{ new Date(page.lastUpdated).toLocaleString() }}</b>.

:::

<!--@include: ../snippets/iroha2_dev_api_spec.md -->
11 changes: 11 additions & 0 deletions src/api/cli.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Command Line Interface (CLI)

## `--config`

Alias: `-c`

Env: `IROHA_CONFIG`

## `--trace-config`

## `--submit-genesis`
23 changes: 23 additions & 0 deletions src/api/config/base-params.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Base Parameters
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there any requirements for the key?

  • Could I introduce a new peer with random keys (given a proper algorithm that generates them and that they have a proper format)?
  • Could I randomly change keys for a peer at some moment, restart it and expect it to work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Well, each peer might have any keys you want it to use. I lack understanding of the bigger picture and how keys should be approached in real-world scenarios.
  2. Not sure, don't think so.


## `public_key`

- **Type:** String, [Multi-hash](glossary#type-multi-hash)
- **Required**

Public key of this peer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should add some links to the source of those keys:

  • At which stage are these generated?
  • Are Kagami Crypto / Kagami Swarm used for those, given the mention of multi-hash above?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. I can hardly answer to it
  2. Yes, kagami crypto might generate a usable key pair

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think that we should mention keys generation and Kagami in the configuration reference. There are many other places in the docs which mention keys, and explaining the same things again and again might be ridiculous and inconsistent. I would like to have a single "Keys 101" section which we could reference from everywhere.


```toml
public_key = "ed0120FAFCB2B27444221717F6FCBF900D5BE95273B1B0904B08C736B32A19F16AC1F9"
```

## `private_key`

- **Type:** Table, [Private Key](glossary#type-private-key)
- **Required**

Private key of this peer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same as above


```toml
private_key = { digest = "ed25519", payload = "82886B5A2BB3785F3CA8F8A78F60EA9DB62F939937B1CFA8407316EF07909A8D236808A6D4C12C91CA19E54686C2B8F5F3A786278E3824B4571EF234DEC8683B" }
```
27 changes: 27 additions & 0 deletions src/api/config/block-sync-params.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
# Block Sync Parameters

Explain module
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I haven't heard about that part before, so any explanation would be helpful. I wonder who can help?


## `block_sync.block_batch_amount`

- **Type:** Number
- **Default:** $4$

The number of blocks that can be sent in one message.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why the explanation of a config parameter goes after its specifications (type, values, default value, etc.). Why not change this order?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have no objections, and you probably understand better how it would be more comprehensible. Should I change the order everywhere?


```toml
[block_sync]
block_batch_amount = 4
```

## `block_sync.gossip_period`

- **Type:** String or Number, [Duration](glossary#type-duration)
- **Default:** 10 seconds
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it seconds or as in the example below? What will actually be accepted by the gossip_period parameter?

Copy link
Contributor Author

@0x009922 0x009922 Sep 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gossip_period accepts a String or a Number, and interprets it as a Duration. Duration is explained at the link. A question: would it be clearer to say "Type: Duration (String or Number)", or "Type: Duration, String or Number" or current "Type: String or Number, Duration"?

For Duration types, I specify their "Default" values as a human readable string like "30 seconds" or "5 minutes".

In the examples, I specify any valid value. Here is a question: maybe, we should change example to show the default value for each config parameter?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My last comment doesn't have a part of the message for some reason. I was actually interested in the terminology.
In the "Default" you have "10 seconds", while in the example you have "5 secs".
So, the question is: does a peer have to write out "seconds" or "secs", or just a plain number in the "gossip_period" field? Juding by your reply, it seems like peers can input minutes as well.
For instance, if I want the interval to be 3 minutes and 22 seconds, should I input "3 mins, 22 secs" or "202 secs", or any other variation?
I'd like to make it clear for the readers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, and it is why I put the link [Duration](glossary#type-duration). That section explains all the possible inputs for durations.

Should it be pointed out more explicitly in some way?


The period of time to wait between sending requests for the latest block.

```toml
[block_sync]
gossip_period = "5 secs"
```
3 changes: 3 additions & 0 deletions src/api/config/deprecation-and-migration.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# Deprecation and Migration Policy

TODO
50 changes: 50 additions & 0 deletions src/api/config/genesis-params.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Genesis Parameters

Explain the purpose of this block. Maybe explain both keys in a single
section?
0x009922 marked this conversation as resolved.
Show resolved Hide resolved

## `genesis.public_key`

- **Type:** [Multi_hash](glossary#type-multi-hash)
- **Required**

The public key of the genesis account, should be supplied to all peers.

```toml
[genesis]
public_key = "ed0120FAFCB2B27444221717F6FCBF900D5BE95273B1B0904B08C736B32A19F16AC1F9"
```


## `genesis.private_key`

- **Type:** Table, [Private Key](glossary#type-private-key)
- **Required** if the configured peer submits the genesis block, **optional** otherwise

The private key of the genesis account, only needed for the peer that
submits the genesis block.


```toml
[genesis]
private_key = { digest = "ed25519", payload = "82886B5A2BB3785F3CA8F8A78F60EA9DB62F939937B1CFA8407316EF07909A8D236808A6D4C12C91CA19E54686C2B8F5F3A786278E3824B4571EF234DEC8683B" }
```


::: info

This parameter is required if the peer being configured submits the
genesis, i.e. if it is run with the [`--submit-genesis`](../cli#submit-genesis)
CLI argument.

:::

::: warning



The warning will be printed if the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly does the warning say? What happens after the warning is printed?

Copy link
Contributor Author

@0x009922 0x009922 Sep 27, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's come up with a line!

I want to remind that this configuration reference describes the configuration that doesn't exist yet. We are at the design stage, and we need to find the best ways to present configuration system to the users. It means that we might change the naming/structure/phrasing of anything if we decide it will be more convenient to users.

As for this topic, actually Iroha should fail to start with --submit-genesis arg, but without genesis.private_key config parameter. However, if there is no --submit-genesis arg, but genesis.private_key is provided, what Iroha should do? Just print a warning and continue execution, or fail? @Mingela, your input might be valuable.

@yamkovoy, for more context about what we are doing in this PR, please refer to the RFC.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the private key is needed only when a flag is specified it feels like the values should be combined somehow, i.e. --submit-genesis --private-key <key>. I might have encountered flag dependencies where one couldn't be used without other but cannot find an example. So following my suggestion just --private-key <key> must prompt an error and usage manual (like usage: iroha [--submit-genesis --private-key <key>] .. etc).
Another idea came to my mind, what about removing --submit-genesis at all and treat presence of --private-key <key> implicitly as it's intended to submit the genesis block?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private-key was used for simplicity there, we should define a simpler name for genesis.private_key in that case, maybe genesis-key?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two parameters:

  • genesis.public_key: used by all peers
  • genesis.private_key: used only by the peer which submits the genesis

Not sure how genesis-key (or genesis.key) might be used in this context.

The downside of iroha --submit-genesis --private-key <key>: it is not good to provide sensitive information through CLI. Although it might be workarounded with ENV: --private-key $IROHA_PRIV_KEY.

Anyway, the solution of omitting --submit-genesis seems fine. The main downside of it as I see is that it might not be that obvious which peer submits the genesis, and the user must know the details of how configuration works.

Still, if we want to choose the path of the highest reliability for the end user, I think the current approach is the best. You clearly identify your intention with --submit-genesis flag. Iroha will clearly fail if you forgot to provide genesis.private_key (or GENESIS_PRIVATE_KEY var (naming is up to discussion)). In this case, the question becomes: should Iroha fail or warn if the key is provided, but the intention was not given?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either is fine. Seems all options around the --submit-genesis have tradeoffs. I don't like the ability to have unused parameters specified, though a warning would be reasonable in that case. Let's hear opinions of others, @mversic @BAStos525

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We definitely should not provide genesis.private.key as shell parameter and it has to be hided somehow, e.g. env var. Currently, we have this block in peer config.json file, and we pass these keys in plain text. Should it be hided somehow? Moreover, we don't separate this config file between peers, so it's the same for all peers. We manage genesis submitting only by --submit-genesis for peer-0 selection by script.
So, there are two ways:

  1. Should we pass genesis keys through config.json? Should it be hided and private key should be specified only for genesis peer-0 (different configs for peers then). And if it's necessary to use --submit-genesis flag for peer-0 if keys are already specified in config?
  2. Remove --submit-genesis flag and this genesis.private.key field in config and apply genesis private key through ENV var or any kind of secret.

The second item sounds a kinda better since it may be easier to hide a sensitive data.
As for should iroha if the keys are provided, but the intention was not given, I think it depends on the selected approach how to provide the private key. If through config and flag, so it means to have a more deployment routine to separate peers configs e.t.c. to avoid iroha fail. So, here warning sounds more reasonable. In the second option we could try to fail it in order do not spread sensitive data across peers where and if it's not necessary.

Copy link
Contributor Author

@0x009922 0x009922 Oct 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had a discussion with the team and dove deeper into the topic of genesis. We agreed that the whole genesis approach as of now is somewhat weird and needs thoughtful revision. It will be done later (idk when, hopefully soon). As for configuration, I will preserve the current behavior without significant changes.

That is:

  • genesis.public_key should be provided for all peers. Through config file or ENV var.
  • genesis.private_key should be provided for the peer with --submit-genesis CLI flag. genesis.private_key might be set through config file or ENV var.
  • if genesis.private_key is provided, but --submit-genesis is not, then Iroha prints a warning, but continues execution.
  • if --submig-genesis is provided, but genesis.private_key is not, then Iroha fails with FATAL error.

[`genesis.private_key`](#genesis-private-key) and
[`--submit-genesis`](../cli#submit-genesis) are used without each other.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[`--submit-genesis`](../cli#submit-genesis) are used without each other.
the [`--submit-genesis`](../cli#submit-genesis) command are used without each other.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

--submit-genesis is not a command, but a CLI (command-line interface) flag. It might be set or not.


:::
Loading
Loading