chore: run markdownlint on the whole repository (#14106)
This commit is contained in:
Jacob Gadikian
GitHub
parent
6679ee0eea
commit
679c5d6086
@ -8,6 +8,7 @@ Optimized C library for EC operations on curve secp256k1.
|
||||
This library is a work in progress and is being used to research best practices. Use at your own risk.
|
||||
|
||||
Features:
|
||||
|
||||
* secp256k1 ECDSA signing/verification and key generation.
|
||||
* Adding/multiplying private/public keys.
|
||||
* Serialization/parsing of private keys, public keys, signatures.
|
||||
@ -19,43 +20,43 @@ Implementation details
|
||||
----------------------
|
||||
|
||||
* General
|
||||
* No runtime heap allocation.
|
||||
* Extensive testing infrastructure.
|
||||
* Structured to facilitate review and analysis.
|
||||
* Intended to be portable to any system with a C89 compiler and uint64_t support.
|
||||
* Expose only higher level interfaces to minimize the API surface and improve application security. ("Be difficult to use insecurely.")
|
||||
* No runtime heap allocation.
|
||||
* Extensive testing infrastructure.
|
||||
* Structured to facilitate review and analysis.
|
||||
* Intended to be portable to any system with a C89 compiler and uint64_t support.
|
||||
* Expose only higher level interfaces to minimize the API surface and improve application security. ("Be difficult to use insecurely.")
|
||||
* Field operations
|
||||
* Optimized implementation of arithmetic modulo the curve's field size (2^256 - 0x1000003D1).
|
||||
* Using 5 52-bit limbs (including hand-optimized assembly for x86_64, by Diederik Huys).
|
||||
* Using 10 26-bit limbs.
|
||||
* Field inverses and square roots using a sliding window over blocks of 1s (by Peter Dettman).
|
||||
* Optimized implementation of arithmetic modulo the curve's field size (2^256 - 0x1000003D1).
|
||||
* Using 5 52-bit limbs (including hand-optimized assembly for x86_64, by Diederik Huys).
|
||||
* Using 10 26-bit limbs.
|
||||
* Field inverses and square roots using a sliding window over blocks of 1s (by Peter Dettman).
|
||||
* Scalar operations
|
||||
* Optimized implementation without data-dependent branches of arithmetic modulo the curve's order.
|
||||
* Using 4 64-bit limbs (relying on __int128 support in the compiler).
|
||||
* Using 8 32-bit limbs.
|
||||
* Optimized implementation without data-dependent branches of arithmetic modulo the curve's order.
|
||||
* Using 4 64-bit limbs (relying on __int128 support in the compiler).
|
||||
* Using 8 32-bit limbs.
|
||||
* Group operations
|
||||
* Point addition formula specifically simplified for the curve equation (y^2 = x^3 + 7).
|
||||
* Use addition between points in Jacobian and affine coordinates where possible.
|
||||
* Use a unified addition/doubling formula where necessary to avoid data-dependent branches.
|
||||
* Point/x comparison without a field inversion by comparison in the Jacobian coordinate space.
|
||||
* Point addition formula specifically simplified for the curve equation (y^2 = x^3 + 7).
|
||||
* Use addition between points in Jacobian and affine coordinates where possible.
|
||||
* Use a unified addition/doubling formula where necessary to avoid data-dependent branches.
|
||||
* Point/x comparison without a field inversion by comparison in the Jacobian coordinate space.
|
||||
* Point multiplication for verification (a*P + b*G).
|
||||
* Use wNAF notation for point multiplicands.
|
||||
* Use a much larger window for multiples of G, using precomputed multiples.
|
||||
* Use Shamir's trick to do the multiplication with the public key and the generator simultaneously.
|
||||
* Optionally (off by default) use secp256k1's efficiently-computable endomorphism to split the P multiplicand into 2 half-sized ones.
|
||||
* Use wNAF notation for point multiplicands.
|
||||
* Use a much larger window for multiples of G, using precomputed multiples.
|
||||
* Use Shamir's trick to do the multiplication with the public key and the generator simultaneously.
|
||||
* Optionally (off by default) use secp256k1's efficiently-computable endomorphism to split the P multiplicand into 2 half-sized ones.
|
||||
* Point multiplication for signing
|
||||
* Use a precomputed table of multiples of powers of 16 multiplied with the generator, so general multiplication becomes a series of additions.
|
||||
* Access the table with branch-free conditional moves so memory access is uniform.
|
||||
* No data-dependent branches
|
||||
* The precomputed tables add and eventually subtract points for which no known scalar (private key) is known, preventing even an attacker with control over the private key used to control the data internally.
|
||||
* Use a precomputed table of multiples of powers of 16 multiplied with the generator, so general multiplication becomes a series of additions.
|
||||
* Access the table with branch-free conditional moves so memory access is uniform.
|
||||
* No data-dependent branches
|
||||
* The precomputed tables add and eventually subtract points for which no known scalar (private key) is known, preventing even an attacker with control over the private key used to control the data internally.
|
||||
|
||||
Build steps
|
||||
-----------
|
||||
|
||||
libsecp256k1 is built using autotools:
|
||||
|
||||
$ ./autogen.sh
|
||||
$ ./configure
|
||||
$ make
|
||||
$ ./tests
|
||||
$ sudo make install # optional
|
||||
./autogen.sh
|
||||
./configure
|
||||
make
|
||||
./tests
|
||||
sudo make install # optional
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Changelog
|
||||
|
||||
- Nov, 23, 2021: Initial Draft
|
||||
* Nov, 23, 2021: Initial Draft
|
||||
|
||||
## Status
|
||||
|
||||
@ -19,9 +19,9 @@ The `upgrade` module in conjunction with Cosmovisor are designed to facilitate a
|
||||
|
||||
Users submit a software upgrade governance proposal containing an upgrade `Plan`.
|
||||
The [Plan](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto#L12) currently contains the following fields:
|
||||
- `name`: A short string identifying the new version.
|
||||
- `height`: The chain height at which the upgrade is to be performed.
|
||||
- `info`: A string containing information about the upgrade.
|
||||
* `name`: A short string identifying the new version.
|
||||
* `height`: The chain height at which the upgrade is to be performed.
|
||||
* `info`: A string containing information about the upgrade.
|
||||
|
||||
The `info` string can be anything.
|
||||
However, Cosmovisor will try to use the `info` field to automatically download a new version of the blockchain executable.
|
||||
@ -40,6 +40,7 @@ Both `DAEMON_HOME` and `DAEMON_NAME` are [environment variables used to configur
|
||||
Currently, there is no mechanism that makes Cosmovisor run a command after the upgraded chain has been restarted.
|
||||
|
||||
The current upgrade process has this timeline:
|
||||
|
||||
1. An upgrade governance proposal is submitted and approved.
|
||||
1. The upgrade height is reached.
|
||||
1. The `x/upgrade` module writes the `upgrade_info.json` file.
|
||||
@ -78,7 +79,7 @@ message UpgradeInstructions {
|
||||
```
|
||||
|
||||
All fields in the `UpgradeInstructions` are optional.
|
||||
- `pre_run` is a command to run prior to the upgraded chain restarting.
|
||||
* `pre_run` is a command to run prior to the upgraded chain restarting.
|
||||
If defined, it will be executed after halting and downloading the new artifact but before restarting the upgraded chain.
|
||||
The working directory this command runs from MUST be `{DAEMON_HOME}/cosmovisor/{upgrade name}`.
|
||||
This command MUST behave the same as the current [pre-upgrade](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md) command.
|
||||
@ -91,12 +92,12 @@ All fields in the `UpgradeInstructions` are optional.
|
||||
| `30` | `pre-upgrade` command was executed but failed. This fails the entire upgrade. |
|
||||
| `31` | `pre-upgrade` command was executed but failed. But the command is retried until exit code `1` or `30` are returned. |
|
||||
If defined, then the app supervisors (e.g. Cosmovisor) MUST NOT run `app pre-run`.
|
||||
- `post_run` is a command to run after the upgraded chain has been started. If defined, this command MUST be only executed at most once by an upgrading node.
|
||||
* `post_run` is a command to run after the upgraded chain has been started. If defined, this command MUST be only executed at most once by an upgrading node.
|
||||
The output and exit code SHOULD be logged but SHOULD NOT affect the running of the upgraded chain.
|
||||
The working directory this command runs from MUST be `{DAEMON_HOME}/cosmovisor/{upgrade name}`.
|
||||
- `artifacts` define items to be downloaded.
|
||||
* `artifacts` define items to be downloaded.
|
||||
It SHOULD have only one entry per platform.
|
||||
- `description` contains human-readable information about the upgrade and might contain references to external resources.
|
||||
* `description` contains human-readable information about the upgrade and might contain references to external resources.
|
||||
It SHOULD NOT be used for structured processing information.
|
||||
|
||||
```protobuf
|
||||
@ -108,20 +109,20 @@ message Artifact {
|
||||
}
|
||||
```
|
||||
|
||||
- `platform` is a required string that SHOULD be in the format `{OS}/{CPU}`, e.g. `"linux/amd64"`.
|
||||
* `platform` is a required string that SHOULD be in the format `{OS}/{CPU}`, e.g. `"linux/amd64"`.
|
||||
The string `"any"` SHOULD also be allowed.
|
||||
An `Artifact` with a `platform` of `"any"` SHOULD be used as a fallback when a specific `{OS}/{CPU}` entry is not found.
|
||||
That is, if an `Artifact` exists with a `platform` that matches the system's OS and CPU, that should be used;
|
||||
otherwise, if an `Artifact` exists with a `platform` of `any`, that should be used;
|
||||
otherwise no artifact should be downloaded.
|
||||
- `url` is a required URL string that MUST conform to [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt).
|
||||
* `url` is a required URL string that MUST conform to [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt).
|
||||
A request to this `url` MUST return either an executable file or an archive containing either `bin/{DAEMON_NAME}` or `{DAEMON_NAME}`.
|
||||
The URL should not contain checksum - it should be specified by the `checksum` attribute.
|
||||
- `checksum` is a checksum of the expected result of a request to the `url`.
|
||||
* `checksum` is a checksum of the expected result of a request to the `url`.
|
||||
It is not required, but is recommended.
|
||||
If provided, it MUST be a hex encoded checksum string.
|
||||
Tools utilizing these `UpgradeInstructions` MUST fail if a `checksum` is provided but is different from the checksum of the result returned by the `url`.
|
||||
- `checksum_algo` is a string identify the algorithm used to generate the `checksum`.
|
||||
* `checksum_algo` is a string identify the algorithm used to generate the `checksum`.
|
||||
Recommended algorithms: `sha256`, `sha512`.
|
||||
Algorithms also supported (but not recommended): `sha1`, `md5`.
|
||||
If a `checksum` is provided, a `checksum_algo` MUST also be provided.
|
||||
@ -140,6 +141,7 @@ We will update the creation of the `upgrade-info.json` file to include the `Upgr
|
||||
|
||||
We will update the optional validation available via CLI to account for the new `Plan` structure.
|
||||
We will add the following validation:
|
||||
|
||||
1. If `UpgradeInstructions` are provided:
|
||||
1. There MUST be at least one entry in `artifacts`.
|
||||
1. All of the `artifacts` MUST have a unique `platform`.
|
||||
@ -165,6 +167,7 @@ If the `upgrade-info.json` file does not contain any `UpgradeInstructions`, exis
|
||||
|
||||
We will update Cosmovisor to look for and handle the new `UpgradeInstructions` in `upgrade-info.json`.
|
||||
If the `UpgradeInstructions` are provided, we will do the following:
|
||||
|
||||
1. The `info` field will be ignored.
|
||||
1. The `artifacts` field will be used to identify the artifact to download based on the `platform` that Cosmovisor is running in.
|
||||
1. If a `checksum` is provided (either in the field or as a query param in the `url`), and the downloaded artifact has a different checksum, the upgrade process will be interrupted and Cosmovisor will exit with an error.
|
||||
@ -179,6 +182,7 @@ We will deprecate the use of the `info` field for anything other than human read
|
||||
A warning will be logged if the `info` field is used to define the assets (either by URL or JSON).
|
||||
|
||||
The new upgrade timeline is very similar to the current one. Changes are in bold:
|
||||
|
||||
1. An upgrade governance proposal is submitted and approved.
|
||||
1. The upgrade height is reached.
|
||||
1. The `x/upgrade` module writes the `upgrade_info.json` file **(now possibly with `UpgradeInstructions`)**.
|
||||
@ -199,6 +203,7 @@ Additionally, current behavior will be maintained when no `UpgradeInstructions`
|
||||
### Forwards Compatibility
|
||||
|
||||
In order to utilize the `UpgradeInstructions` as part of a software upgrade, both of the following must be true:
|
||||
|
||||
1. The chain must already be using a sufficiently advanced version of the Cosmos SDK.
|
||||
1. The chain's nodes must be using a sufficiently advanced version of Cosmovisor.
|
||||
|
||||
@ -237,9 +242,9 @@ In order to utilize the `UpgradeInstructions` as part of a software upgrade, bot
|
||||
|
||||
## References
|
||||
|
||||
- [Current upgrade.proto](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto)
|
||||
- [Upgrade Module README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/x/upgrade/spec/README.md)
|
||||
- [Cosmovisor README](https://github.com/cosmos/cosmos-sdk/blob/cosmovisor/v1.0.0/cosmovisor/README.md)
|
||||
- [Pre-upgrade README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md)
|
||||
- [Draft/POC PR #10032](https://github.com/cosmos/cosmos-sdk/pull/10032)
|
||||
- [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt)
|
||||
* [Current upgrade.proto](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/proto/cosmos/upgrade/v1beta1/upgrade.proto)
|
||||
* [Upgrade Module README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/x/upgrade/spec/README.md)
|
||||
* [Cosmovisor README](https://github.com/cosmos/cosmos-sdk/blob/cosmovisor/v1.0.0/cosmovisor/README.md)
|
||||
* [Pre-upgrade README](https://github.com/cosmos/cosmos-sdk/blob/v0.44.5/docs/migrations/pre-upgrade.md)
|
||||
* [Draft/POC PR #10032](https://github.com/cosmos/cosmos-sdk/pull/10032)
|
||||
* [RFC 1738: Uniform Resource Locators](https://www.ietf.org/rfc/rfc1738.txt)
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
## Changelog
|
||||
|
||||
- Jan 19, 2022: Initial Draft
|
||||
- Apr 29, 2022: Safer extension snapshotter interface
|
||||
* Jan 19, 2022: Initial Draft
|
||||
* Apr 29, 2022: Safer extension snapshotter interface
|
||||
|
||||
## Status
|
||||
|
||||
@ -150,13 +150,13 @@ But for applications that does not have the state data outside of the IAVL tree
|
||||
|
||||
### Positive
|
||||
|
||||
- State maintained outside of IAVL tree like CosmWasm blobs can create snapshots by implementing extension snapshotters, and being fetched by new clients via state-sync.
|
||||
* State maintained outside of IAVL tree like CosmWasm blobs can create snapshots by implementing extension snapshotters, and being fetched by new clients via state-sync.
|
||||
|
||||
### Negative
|
||||
|
||||
### Neutral
|
||||
|
||||
- All modules that maintain state outside of IAVL tree need to implement `ExtensionSnapshotter` and the snapshot `Manager` need to call `RegisterExtensions` when setting up the application.
|
||||
* All modules that maintain state outside of IAVL tree need to implement `ExtensionSnapshotter` and the snapshot `Manager` need to call `RegisterExtensions` when setting up the application.
|
||||
|
||||
## Further Discussions
|
||||
|
||||
@ -169,6 +169,6 @@ Test cases for an implementation are mandatory for ADRs that are affecting conse
|
||||
|
||||
## References
|
||||
|
||||
- https://github.com/cosmos/cosmos-sdk/pull/10961
|
||||
- https://github.com/cosmos/cosmos-sdk/issues/7340
|
||||
- https://hackmd.io/gJoyev6DSmqqkO667WQlGw
|
||||
* https://github.com/cosmos/cosmos-sdk/pull/10961
|
||||
* https://github.com/cosmos/cosmos-sdk/issues/7340
|
||||
* https://hackmd.io/gJoyev6DSmqqkO667WQlGw
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
|
||||
## Changelog
|
||||
|
||||
- Dec 06, 2021: Initial Draft
|
||||
- Feb 07, 2022: Draft read and concept-ACKed by the Ledger team.
|
||||
* Dec 06, 2021: Initial Draft
|
||||
* Feb 07, 2022: Draft read and concept-ACKed by the Ledger team.
|
||||
|
||||
## Status
|
||||
|
||||
@ -19,47 +19,47 @@ Value Renderers describe how values of different Protobuf types should be encode
|
||||
|
||||
### Protobuf `number`
|
||||
|
||||
- Applies to:
|
||||
- protobuf numeric integer types (`int{32,64}`, `uint{32,64}`, `sint{32,64}`, `fixed{32,64}`, `sfixed{32,64}`)
|
||||
- strings whose `customtype` is `github.com/cosmos/cosmos-sdk/types.Int` or `github.com/cosmos/cosmos-sdk/types.Dec`
|
||||
- bytes whose `customtype` is `github.com/cosmos/cosmos-sdk/types.Int` or `github.com/cosmos/cosmos-sdk/types.Dec`
|
||||
- Trailing decimal zeroes are always removed
|
||||
- Formatting with `'`s for every three integral digits.
|
||||
- Usage of `.` to denote the decimal delimiter.
|
||||
* Applies to:
|
||||
* protobuf numeric integer types (`int{32,64}`, `uint{32,64}`, `sint{32,64}`, `fixed{32,64}`, `sfixed{32,64}`)
|
||||
* strings whose `customtype` is `github.com/cosmos/cosmos-sdk/types.Int` or `github.com/cosmos/cosmos-sdk/types.Dec`
|
||||
* bytes whose `customtype` is `github.com/cosmos/cosmos-sdk/types.Int` or `github.com/cosmos/cosmos-sdk/types.Dec`
|
||||
* Trailing decimal zeroes are always removed
|
||||
* Formatting with `'`s for every three integral digits.
|
||||
* Usage of `.` to denote the decimal delimiter.
|
||||
|
||||
#### Examples
|
||||
|
||||
- `1000` (uint64) -> `1'000`
|
||||
- `"1000000.00"` (string representing a Dec) -> `1'000'000`
|
||||
- `"1000000.10"` (string representing a Dec) -> `1'000'000.1`
|
||||
* `1000` (uint64) -> `1'000`
|
||||
* `"1000000.00"` (string representing a Dec) -> `1'000'000`
|
||||
* `"1000000.10"` (string representing a Dec) -> `1'000'000.1`
|
||||
|
||||
### `coin`
|
||||
|
||||
- Applies to `cosmos.base.v1beta1.Coin`.
|
||||
- Denoms are converted to `display` denoms using `Metadata` (if available). **This requires a state query**. The definition of `Metadata` can be found in the [bank Protobuf definition](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/bank.proto#L79-L108). If the `display` field is empty or nil, then we do not perform any denom conversion.
|
||||
- Amounts are converted to `display` denom amounts and rendered as `number`s above
|
||||
- We do not change the capitalization of the denom. In practice, `display` denoms are stored in lowercase in state (e.g. `10 atom`), however they are often showed in UPPERCASE in everyday life (e.g. `10 ATOM`). Value renderers keep the case used in state, but we may recommend chains changing the denom metadata to be uppercase for better user display.
|
||||
- One space between the denom and amount (e.g. `10 atom`).
|
||||
- In the future, IBC denoms could maybe be converted to DID/IIDs, if we can find a robust way for doing this (ex. `cosmos:cosmos:hub:bank:denom:atom`)
|
||||
* Applies to `cosmos.base.v1beta1.Coin`.
|
||||
* Denoms are converted to `display` denoms using `Metadata` (if available). **This requires a state query**. The definition of `Metadata` can be found in the [bank Protobuf definition](https://github.com/cosmos/cosmos-sdk/blob/v0.46.0/proto/cosmos/bank/v1beta1/bank.proto#L79-L108). If the `display` field is empty or nil, then we do not perform any denom conversion.
|
||||
* Amounts are converted to `display` denom amounts and rendered as `number`s above
|
||||
* We do not change the capitalization of the denom. In practice, `display` denoms are stored in lowercase in state (e.g. `10 atom`), however they are often showed in UPPERCASE in everyday life (e.g. `10 ATOM`). Value renderers keep the case used in state, but we may recommend chains changing the denom metadata to be uppercase for better user display.
|
||||
* One space between the denom and amount (e.g. `10 atom`).
|
||||
* In the future, IBC denoms could maybe be converted to DID/IIDs, if we can find a robust way for doing this (ex. `cosmos:cosmos:hub:bank:denom:atom`)
|
||||
|
||||
#### Examples
|
||||
|
||||
- `1000000000uatom` -> `["1'000 atom"]`, because atom is the metadata's display denom.
|
||||
* `1000000000uatom` -> `["1'000 atom"]`, because atom is the metadata's display denom.
|
||||
|
||||
### `coins`
|
||||
|
||||
- an array of `coin` is display as the concatenation of each `coin` encoded as the specification above, the joined together with the delimiter `", "` (a comma and a space, no quotes around).
|
||||
- the list of coins is ordered by unicode code point of the display denom: `A-Z` < `a-z`. For example, the string `aAbBcC` would be sorted `ABCabc`.
|
||||
* an array of `coin` is display as the concatenation of each `coin` encoded as the specification above, the joined together with the delimiter `", "` (a comma and a space, no quotes around).
|
||||
* the list of coins is ordered by unicode code point of the display denom: `A-Z` < `a-z`. For example, the string `aAbBcC` would be sorted `ABCabc`.
|
||||
|
||||
### Example
|
||||
|
||||
- `["3cosm", "2000000uatom"]` -> `2 atom, 3 COSM` (assuming the display denoms are `atom` and `COSM`)
|
||||
- `["10atom", "20Acoin"]` -> `20 Acoin, 10 atom` (assuming the display denoms are `atom` and `Acoin`)
|
||||
* `["3cosm", "2000000uatom"]` -> `2 atom, 3 COSM` (assuming the display denoms are `atom` and `COSM`)
|
||||
* `["10atom", "20Acoin"]` -> `20 Acoin, 10 atom` (assuming the display denoms are `atom` and `Acoin`)
|
||||
|
||||
### `repeated`
|
||||
|
||||
- Applies to all `repeated` fields, except `cosmos.tx.v1beta1.TxBody#Messages`, which has a particular encoding (see [ADR-050](./adr-050-sign-mode-textual.md)).
|
||||
- A repeated type has the following template:
|
||||
* Applies to all `repeated` fields, except `cosmos.tx.v1beta1.TxBody#Messages`, which has a particular encoding (see [ADR-050](./adr-050-sign-mode-textual.md)).
|
||||
* A repeated type has the following template:
|
||||
|
||||
```
|
||||
<field_name>: <int> <field_kind>
|
||||
@ -72,13 +72,13 @@ End of <field_name>.
|
||||
|
||||
where:
|
||||
|
||||
- `field_name` is the Protobuf field name of the repeated field
|
||||
- `field_kind`:
|
||||
- if the type of the repeated field is a message, `field_kind` is the message name
|
||||
- if the type of the repeated field is an enum, `field_kind` is the enum name
|
||||
- in any other case, `field_kind` is the protobuf primitive type (e.g. "string" or "bytes")
|
||||
- `int` is the length of the array
|
||||
- `index` is one based index of the repeated field
|
||||
* `field_name` is the Protobuf field name of the repeated field
|
||||
* `field_kind`:
|
||||
* if the type of the repeated field is a message, `field_kind` is the message name
|
||||
* if the type of the repeated field is an enum, `field_kind` is the enum name
|
||||
* in any other case, `field_kind` is the protobuf primitive type (e.g. "string" or "bytes")
|
||||
* `int` is the length of the array
|
||||
* `index` is one based index of the repeated field
|
||||
|
||||
#### Examples
|
||||
|
||||
@ -107,20 +107,21 @@ End of Allowed messages
|
||||
|
||||
### `message`
|
||||
|
||||
- Applies to Protobuf messages whose name does not start with `Msg`
|
||||
- For `sdk.Msg`s, please see [ADR-050](./adr-050-sign-mode-textual.md)
|
||||
- alternatively, we can decide to add a protobuf option to denote messages that are `sdk.Msg`s.
|
||||
- Field names follow [sentence case](https://en.wiktionary.org/wiki/sentence_case)
|
||||
- replace `_` with a spaces
|
||||
- capitalize first letter of the setence
|
||||
- Field names are ordered by their Protobuf field number
|
||||
- Nesting:
|
||||
- if a field contains a nested message, we value-render the underlying message using the template:
|
||||
* Applies to Protobuf messages whose name does not start with `Msg`
|
||||
* For `sdk.Msg`s, please see [ADR-050](./adr-050-sign-mode-textual.md)
|
||||
* alternatively, we can decide to add a protobuf option to denote messages that are `sdk.Msg`s.
|
||||
* Field names follow [sentence case](https://en.wiktionary.org/wiki/sentence_case)
|
||||
* replace `_` with a spaces
|
||||
* capitalize first letter of the setence
|
||||
* Field names are ordered by their Protobuf field number
|
||||
* Nesting:
|
||||
* if a field contains a nested message, we value-render the underlying message using the template:
|
||||
|
||||
```
|
||||
<field_name>: <1st line of value-rendered message>
|
||||
> <lines 2-n of value-rendered message> // Notice the `>` prefix.
|
||||
```
|
||||
- `>` character is used to denote nesting. For each additional level of nesting, add `>`.
|
||||
* `>` character is used to denote nesting. For each additional level of nesting, add `>`.
|
||||
|
||||
#### Examples
|
||||
|
||||
@ -166,7 +167,7 @@ Vote object
|
||||
|
||||
### Enums
|
||||
|
||||
- Show the enum variant name as string.
|
||||
* Show the enum variant name as string.
|
||||
|
||||
#### Examples
|
||||
|
||||
@ -174,8 +175,8 @@ See example above with `message Vote{}`.
|
||||
|
||||
### `google.protobuf.Any`
|
||||
|
||||
- Applies to `google.protobuf.Any`
|
||||
- Rendered as:
|
||||
* Applies to `google.protobuf.Any`
|
||||
* Rendered as:
|
||||
|
||||
```
|
||||
Object: <type_url>
|
||||
@ -243,14 +244,14 @@ Negative durations will be indicated with a leading minus sign (`-`).
|
||||
|
||||
Examples:
|
||||
|
||||
- `1 day`
|
||||
- `30 days`
|
||||
- `-1 day, 12 hours`
|
||||
- `3 hours, 0 minutes, 53.025 seconds`
|
||||
* `1 day`
|
||||
* `30 days`
|
||||
* `-1 day, 12 hours`
|
||||
* `3 hours, 0 minutes, 53.025 seconds`
|
||||
|
||||
### bytes
|
||||
|
||||
- Bytes are rendered in hexadecimal, all capital letters, without the `0x` prefix.
|
||||
* Bytes are rendered in hexadecimal, all capital letters, without the `0x` prefix.
|
||||
|
||||
### address bytes
|
||||
|
||||
@ -262,7 +263,7 @@ Strings are rendered as-is.
|
||||
|
||||
### Default Values
|
||||
|
||||
- Default Protobuf values for each field are skipped.
|
||||
* Default Protobuf values for each field are skipped.
|
||||
|
||||
#### Example
|
||||
|
||||
@ -293,8 +294,8 @@ _This paragraph is in the Annex for informational purposes only, and will be rem
|
||||
<details>
|
||||
<summary>Click to see abandoned idea.</summary>
|
||||
|
||||
- all protobuf messages to be used with `SIGN_MODE_TEXTUAL` CAN have a short title associated with them that can be used in format strings whenever the type URL is explicitly referenced via the `cosmos.msg.v1.textual.msg_title` Protobuf message option.
|
||||
- if this option is not specified for a Msg, then the Protobuf fully qualified name will be used.
|
||||
* all protobuf messages to be used with `SIGN_MODE_TEXTUAL` CAN have a short title associated with them that can be used in format strings whenever the type URL is explicitly referenced via the `cosmos.msg.v1.textual.msg_title` Protobuf message option.
|
||||
* if this option is not specified for a Msg, then the Protobuf fully qualified name will be used.
|
||||
|
||||
```protobuf
|
||||
message MsgSend {
|
||||
@ -302,11 +303,11 @@ message MsgSend {
|
||||
}
|
||||
```
|
||||
|
||||
- they MUST be unique per message, per chain
|
||||
* they MUST be unique per message, per chain
|
||||
|
||||
#### Examples
|
||||
|
||||
- `cosmos.gov.v1.MsgVote` -> `governance v1 vote`
|
||||
* `cosmos.gov.v1.MsgVote` -> `governance v1 vote`
|
||||
|
||||
#### Best Pratices
|
||||
|
||||
@ -314,7 +315,7 @@ We recommend to use this option only for `Msg`s whose Protobuf fully qualified n
|
||||
|
||||
In those cases, we recommend to drop the version (e.g. `v1`) in the string if there's only one version of the module on chain. This way, the bijective mapping can figure out which message each string corresponds to. If multiple Protobuf versions of the same module exist on the same chain, we recommend keeping the first `msg_title` with version, and the second `msg_title` with version (e.g. `v2`):
|
||||
|
||||
- `mychain.mymodule.v1.MsgDo` -> `mymodule do something`
|
||||
- `mychain.mymodule.v2.MsgDo` -> `mymodule v2 do something`
|
||||
* `mychain.mymodule.v1.MsgDo` -> `mymodule do something`
|
||||
* `mychain.mymodule.v2.MsgDo` -> `mymodule v2 do something`
|
||||
|
||||
</details>
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
## Changelog
|
||||
|
||||
- Oct 3, 2022: Initial Draft
|
||||
* Oct 3, 2022: Initial Draft
|
||||
|
||||
## Status
|
||||
|
||||
@ -47,42 +47,42 @@ As an illustration of these principles, here is an example algorithm
|
||||
for presentation on a device which can display a single 80-character
|
||||
line of printable ASCII characters:
|
||||
|
||||
- The presentation is broken into lines, and each line is presented in
|
||||
* The presentation is broken into lines, and each line is presented in
|
||||
sequence, with user controls for going forward or backward a line.
|
||||
|
||||
- Expert mode screens are only presented if the device is in expert mode.
|
||||
* Expert mode screens are only presented if the device is in expert mode.
|
||||
|
||||
- Each line of the screen starts with a number of `>` characters equal
|
||||
* Each line of the screen starts with a number of `>` characters equal
|
||||
to the screen's indentation level, followed by a `+` character if this
|
||||
isn't the first line of the screen, followed by a space if either a
|
||||
`>` or a `+` has been emitted,
|
||||
or if this header is followed by a `>`, `+`, or space.
|
||||
|
||||
- If the line ends with whitespace or an `@` character, an additional `@`
|
||||
* If the line ends with whitespace or an `@` character, an additional `@`
|
||||
character is appended to the line.
|
||||
|
||||
- The following ASCII control characters or backslash (`\`) are converted
|
||||
* The following ASCII control characters or backslash (`\`) are converted
|
||||
to a backslash followed by a letter code, in the manner of string literals
|
||||
in many languages:
|
||||
|
||||
- a: U+0007 alert or bell
|
||||
- b: U+0008 backspace
|
||||
- f: U+000C form feed
|
||||
- n: U+000A line feed
|
||||
- r: U+000D carriage return
|
||||
- t: U+0009 horizontal tab
|
||||
- v: U+000B vertical tab
|
||||
- `\`: U+005C backslash
|
||||
* a: U+0007 alert or bell
|
||||
* b: U+0008 backspace
|
||||
* f: U+000C form feed
|
||||
* n: U+000A line feed
|
||||
* r: U+000D carriage return
|
||||
* t: U+0009 horizontal tab
|
||||
* v: U+000B vertical tab
|
||||
* `\`: U+005C backslash
|
||||
|
||||
- All other ASCII control characters, plus non-ASCII Unicode code points,
|
||||
* All other ASCII control characters, plus non-ASCII Unicode code points,
|
||||
are shown as either:
|
||||
|
||||
- `\u` followed by 4 uppercase hex chacters for code points
|
||||
* `\u` followed by 4 uppercase hex chacters for code points
|
||||
in the basic multilingual plane (BMP).
|
||||
|
||||
- `\U` followed by 8 uppercase hex characters for other code points.
|
||||
* `\U` followed by 8 uppercase hex characters for other code points.
|
||||
|
||||
- The screen will be broken into multiple lines to fit the 80-character
|
||||
* The screen will be broken into multiple lines to fit the 80-character
|
||||
limit, considering the above transformations in a way that attempts to
|
||||
minimize the number of lines generated. Expanded control or Unicode characters
|
||||
are never split across lines.
|
||||
|
||||
@ -2,13 +2,13 @@
|
||||
|
||||
## Changelog
|
||||
|
||||
- Dec 06, 2021: Initial Draft.
|
||||
- Feb 07, 2022: Draft read and concept-ACKed by the Ledger team.
|
||||
- May 16, 2022: Change status to Accepted.
|
||||
- Aug 11, 2022: Require signing over tx raw bytes.
|
||||
- Sep 07, 2022: Add custom `Msg`-renderers.
|
||||
- Sep 18, 2022: Structured format instead of lines of text
|
||||
- Nov 23, 2022: Specify CBOR encoding.
|
||||
* Dec 06, 2021: Initial Draft.
|
||||
* Feb 07, 2022: Draft read and concept-ACKed by the Ledger team.
|
||||
* May 16, 2022: Change status to Accepted.
|
||||
* Aug 11, 2022: Require signing over tx raw bytes.
|
||||
* Sep 07, 2022: Add custom `Msg`-renderers.
|
||||
* Sep 18, 2022: Structured format instead of lines of text
|
||||
* Nov 23, 2022: Specify CBOR encoding.
|
||||
|
||||
## Status
|
||||
|
||||
@ -22,8 +22,8 @@ This ADR specifies SIGN_MODE_TEXTUAL, a new string-based sign mode that is targe
|
||||
|
||||
Protobuf-based SIGN_MODE_DIRECT was introduced in [ADR-020](./adr-020-protobuf-transaction-encoding.md) and is intended to replace SIGN_MODE_LEGACY_AMINO_JSON in most situations, such as mobile wallets and CLI keyrings. However, the [Ledger](https://www.ledger.com/) hardware wallet is still using SIGN_MODE_LEGACY_AMINO_JSON for displaying the sign bytes to the user. Hardware wallets cannot transition to SIGN_MODE_DIRECT as:
|
||||
|
||||
- SIGN_MODE_DIRECT is binary-based and thus not suitable for display to end-users. Technically, hardware wallets could simply display the sign bytes to the user. But this would be considered as blind signing, and is a security concern.
|
||||
- hardware cannot decode the protobuf sign bytes due to memory constraints, as the Protobuf definitions would need to be embedded on the hardware device.
|
||||
* SIGN_MODE_DIRECT is binary-based and thus not suitable for display to end-users. Technically, hardware wallets could simply display the sign bytes to the user. But this would be considered as blind signing, and is a security concern.
|
||||
* hardware cannot decode the protobuf sign bytes due to memory constraints, as the Protobuf definitions would need to be embedded on the hardware device.
|
||||
|
||||
In an effort to remove Amino from the SDK, a new sign mode needs to be created for hardware devices. [Initial discussions](https://github.com/cosmos/cosmos-sdk/issues/6513) propose a text-based sign mode, which this ADR formally specifies.
|
||||
|
||||
@ -264,9 +264,9 @@ Recall that the transaction bytes merklelized on chain are the Protobuf binary s
|
||||
```
|
||||
|
||||
where:
|
||||
- `++` denotes concatenation,
|
||||
- `HEX` is the hexadecimal representation of the bytes, all in capital letters, no `0x` prefix,
|
||||
- and `len()` is encoded as a Big-Endian uint64.
|
||||
* `++` denotes concatenation,
|
||||
* `HEX` is the hexadecimal representation of the bytes, all in capital letters, no `0x` prefix,
|
||||
* and `len()` is encoded as a Big-Endian uint64.
|
||||
|
||||
This is to prevent transaction hash malleability. The point #1 about invertiblity assures that transaction `body` and `auth_info` values are not malleable, but the transaction hash still might be malleable with point #1 only, because the SIGN_MODE_TEXTUAL strings don't follow the byte ordering defined in `body_bytes` and `auth_info_bytes`. Without this hash, a malicious validator or exchange could intercept a transaction, modify its transaction hash _after_ the user signed it using SIGN_MODE_TEXTUAL (by tweaking the byte ordering inside `body_bytes` or `auth_info_bytes`), and then submit it to Tendermint.
|
||||
|
||||
@ -587,30 +587,30 @@ SIGN_MODE_TEXTUAL is purely additive, and doesn't break any backwards compatibil
|
||||
|
||||
### Positive
|
||||
|
||||
- Human-friendly way of signing in hardware devices.
|
||||
- Once SIGN_MODE_TEXTUAL is shipped, SIGN_MODE_LEGACY_AMINO_JSON can be deprecated and removed. On the longer term, once the ecosystem has totally migrated, Amino can be totally removed.
|
||||
* Human-friendly way of signing in hardware devices.
|
||||
* Once SIGN_MODE_TEXTUAL is shipped, SIGN_MODE_LEGACY_AMINO_JSON can be deprecated and removed. On the longer term, once the ecosystem has totally migrated, Amino can be totally removed.
|
||||
|
||||
### Negative
|
||||
|
||||
- Some fields are still encoded in non-human-readable ways, such as public keys in hexadecimal.
|
||||
- New ledger app needs to be released, still unclear
|
||||
* Some fields are still encoded in non-human-readable ways, such as public keys in hexadecimal.
|
||||
* New ledger app needs to be released, still unclear
|
||||
|
||||
### Neutral
|
||||
|
||||
- If the transaction is complex, the string array can be arbitrarily long, and some users might just skip some screens and blind sign.
|
||||
* If the transaction is complex, the string array can be arbitrarily long, and some users might just skip some screens and blind sign.
|
||||
|
||||
## Further Discussions
|
||||
|
||||
- Some details on value renderers need to be polished, see [Annex 1](./adr-050-sign-mode-textual-annex1.md).
|
||||
- Are ledger apps able to support both SIGN_MODE_LEGACY_AMINO_JSON and SIGN_MODE_TEXTUAL at the same time?
|
||||
- Open question: should we add a Protobuf field option to allow app developers to overwrite the textual representation of certain Protobuf fields and message? This would be similar to Ethereum's [EIP4430](https://github.com/ethereum/EIPs/pull/4430), where the contract developer decides on the textual representation.
|
||||
- Internationalization.
|
||||
* Some details on value renderers need to be polished, see [Annex 1](./adr-050-sign-mode-textual-annex1.md).
|
||||
* Are ledger apps able to support both SIGN_MODE_LEGACY_AMINO_JSON and SIGN_MODE_TEXTUAL at the same time?
|
||||
* Open question: should we add a Protobuf field option to allow app developers to overwrite the textual representation of certain Protobuf fields and message? This would be similar to Ethereum's [EIP4430](https://github.com/ethereum/EIPs/pull/4430), where the contract developer decides on the textual representation.
|
||||
* Internationalization.
|
||||
|
||||
## References
|
||||
|
||||
- [Annex 1](./adr-050-sign-mode-textual-annex1.md)
|
||||
* [Annex 1](./adr-050-sign-mode-textual-annex1.md)
|
||||
|
||||
- Initial discussion: https://github.com/cosmos/cosmos-sdk/issues/6513
|
||||
- Living document used in the working group: https://hackmd.io/fsZAO-TfT0CKmLDtfMcKeA?both
|
||||
- Working group meeting notes: https://hackmd.io/7RkGfv_rQAaZzEigUYhcXw
|
||||
- Ethereum's "Described Transactions" https://github.com/ethereum/EIPs/pull/4430
|
||||
* Initial discussion: https://github.com/cosmos/cosmos-sdk/issues/6513
|
||||
* Living document used in the working group: https://hackmd.io/fsZAO-TfT0CKmLDtfMcKeA?both
|
||||
* Working group meeting notes: https://hackmd.io/7RkGfv_rQAaZzEigUYhcXw
|
||||
* Ethereum's "Described Transactions" https://github.com/ethereum/EIPs/pull/4430
|
||||
|
||||
@ -52,6 +52,7 @@ as to how to do this, with some developers arguing for larger vs smaller
|
||||
module scopes. There are pros and cons to both approaches (which will be
|
||||
discussed below in the [Consequences](#consequences) section), but the
|
||||
approach being adopted is the following:
|
||||
|
||||
* a go module should generally be scoped to a specific coherent set of
|
||||
functionality (such as math, errors, store, etc.)
|
||||
* when code is removed from the core SDK and moved to a new module path, every
|
||||
@ -106,4 +107,4 @@ the Cosmos SDK Framework Working Group.
|
||||
* https://github.com/cosmos/cosmos-sdk/discussions/10162
|
||||
* https://github.com/cosmos/cosmos-sdk/discussions/10582
|
||||
* https://github.com/cosmos/cosmos-sdk/pull/10779
|
||||
* https://github.com/cosmos/cosmos-sdk/pull/11788
|
||||
* https://github.com/cosmos/cosmos-sdk/pull/11788
|
||||
|
||||
@ -38,6 +38,7 @@ and https://github.com/cosmos/cosmos-sdk/pull/10454.
|
||||
These prior efforts culminated in the creation of the Cosmos SDK `orm` go module which uses protobuf annotations
|
||||
for specifying ORM table definitions. This ORM is based on the new `google.golang.org/protobuf/reflect/protoreflect`
|
||||
API and supports:
|
||||
|
||||
* sorted indexes for all simple protobuf types (except `bytes`, `enum`, `float`, `double`) as well as `Timestamp` and `Duration`
|
||||
* unsorted `bytes` and `enum` indexes
|
||||
* composite primary and secondary keys
|
||||
@ -63,9 +64,9 @@ A code generator is included with the ORM which creates type safe wrappers aroun
|
||||
implementation and is the recommended way for modules to use the ORM.
|
||||
|
||||
The ORM tests provide a simplified bank module demonstration which illustrates:
|
||||
- [ORM proto options](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.proto)
|
||||
- [Generated Code](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.cosmos_orm.go)
|
||||
- [Example Usage in a Module Keeper](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/model/ormdb/module_test.go)
|
||||
* [ORM proto options](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.proto)
|
||||
* [Generated Code](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/internal/testpb/bank.cosmos_orm.go)
|
||||
* [Example Usage in a Module Keeper](https://github.com/cosmos/cosmos-sdk/blob/0d846ae2f0424b2eb640f6679a703b52d407813d/orm/model/ormdb/module_test.go)
|
||||
|
||||
## Consequences
|
||||
|
||||
@ -92,12 +93,13 @@ for potential improvements
|
||||
## Further Discussions
|
||||
|
||||
Further discussions will happen within the Cosmos SDK Framework Working Group. Current planned and ongoing work includes:
|
||||
|
||||
* automatically generate client-facing query layer
|
||||
* client-side query libraries that transparently verify light client proofs
|
||||
* index ORM data to SQL databases
|
||||
* improve performance by:
|
||||
* optimizing existing reflection based code to avoid unnecessary gets when doing deletes & updates of simple tables
|
||||
* more sophisticated code generation such as making fast path reflection even faster (avoiding `switch` statements),
|
||||
* optimizing existing reflection based code to avoid unnecessary gets when doing deletes & updates of simple tables
|
||||
* more sophisticated code generation such as making fast path reflection even faster (avoiding `switch` statements),
|
||||
or even fully generating code that equals handwritten performance
|
||||
|
||||
|
||||
@ -108,4 +110,4 @@ Further discussions will happen within the Cosmos SDK Framework Working Group. C
|
||||
* https://github.com/cosmos/cosmos-sdk/tree/35d3312c3be306591fcba39892223f1244c8d108/x/group/internal/orm
|
||||
* https://github.com/cosmos/cosmos-sdk/discussions/9156
|
||||
* https://github.com/allinbits/cosmos-sdk-poc/tree/master/runtime/orm
|
||||
* https://github.com/cosmos/cosmos-sdk/pull/10454
|
||||
* https://github.com/cosmos/cosmos-sdk/pull/10454
|
||||
|
||||
@ -252,6 +252,7 @@ when certain events happen.
|
||||
|
||||
With the app wiring framework, these hooks interfaces can be defined as a `OnePerModuleType`s and then the module
|
||||
which consumes these hooks can collect these hooks as a map of module name to hook type (ex. `map[string]FooHooks`). Ex:
|
||||
|
||||
```go
|
||||
func init() {
|
||||
appmodule.Register(
|
||||
@ -275,6 +276,7 @@ in its config object.
|
||||
|
||||
An alternative way for registering hooks via reflection was considered where all keeper types are inspected to see if
|
||||
they implement the hook interface by the modules exposing hooks. This has the downsides of:
|
||||
|
||||
* needing to expose all the keepers of all modules to the module providing hooks,
|
||||
* not allowing for encapsulating hooks on a different type which doesn't expose all keeper methods,
|
||||
* harder to know statically which module expose hooks or are checking for them.
|
||||
@ -286,6 +288,7 @@ With the approach proposed here, hooks registration will be obviously observable
|
||||
|
||||
The `depinject` framework will optionally allow the app configuration and dependency injection wiring to be code
|
||||
generated. This will allow:
|
||||
|
||||
* dependency injection wiring to be inspected as regular go code just like the existing `app.go`,
|
||||
* dependency injection to be opt-in with manual wiring 100% still possible.
|
||||
|
||||
|
||||
@ -42,6 +42,7 @@ The basic design for automatically generating CLI commands is to:
|
||||
|
||||
In order to make the auto-generated CLI as easy to use (or easier) than handwritten CLI, we need to do custom handling
|
||||
of specific protobuf field types so that the input format is easy for humans:
|
||||
|
||||
* `Coin`, `Coins`, `DecCoin`, and `DecCoins` should be input using the existing format (i.e. `1000uatom`)
|
||||
* it should be possible to specify an address using either the bech32 address string or a named key in the keyring
|
||||
* `Timestamp` and `Duration` should accept strings like `2001-01-01T00:00:00Z` and `1h3m` respectively
|
||||
@ -74,12 +75,14 @@ this functionality.
|
||||
## Further Discussions
|
||||
|
||||
We would like to be able to customize:
|
||||
|
||||
* short and long usage strings for commands
|
||||
* aliases for flags (ex. `-a` for `--amount`)
|
||||
* which fields are positional parameters rather than flags
|
||||
|
||||
It is an [open discussion](https://github.com/cosmos/cosmos-sdk/pull/11725#issuecomment-1108676129)
|
||||
as to whether these customizations options should line in:
|
||||
|
||||
* the .proto files themselves,
|
||||
* separate config files (ex. YAML), or
|
||||
* directly in code
|
||||
|
||||
@ -9,6 +9,7 @@ This document describes the lifecycle of a transaction from creation to committe
|
||||
:::
|
||||
|
||||
:::note
|
||||
|
||||
### Pre-requisite Readings
|
||||
|
||||
* [Anatomy of a Cosmos SDK Application](./00-app-anatomy.md)
|
||||
|
||||
@ -5,6 +5,7 @@ sidebar_position: 1
|
||||
# Module Simulation
|
||||
|
||||
:::note
|
||||
|
||||
### Pre-requisite Readings
|
||||
|
||||
* [Cosmos Blockchain Simulator](../core/12-simulation.md)
|
||||
|
||||
@ -64,6 +64,7 @@ or
|
||||
```bash
|
||||
sudo ufw allow 22
|
||||
```
|
||||
|
||||
Both of the above commands are the same.
|
||||
|
||||
3. Allow Port 26656 (tendermint p2p port). If the node has a modified p2p port then that port must be used here.
|
||||
@ -158,6 +159,7 @@ cargo install tmkms --features=softsign
|
||||
tmkms init config
|
||||
tmkms softsign keygen ./config/secrets/secret_connection_key
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
Cargo install:
|
||||
@ -245,6 +247,7 @@ It is recommended to comment or delete the lines that specify the path of the va
|
||||
# Path to the JSON file containing the last sign state of a validator
|
||||
# priv_validator_state_file = "data/priv_validator_state.json"
|
||||
```
|
||||
|
||||
:::
|
||||
|
||||
6. Start the two processes.
|
||||
|
||||
@ -37,6 +37,7 @@ Ref: https://keepachangelog.com/en/1.0.0/
|
||||
## [Unreleased]
|
||||
|
||||
### Improvements
|
||||
|
||||
* [#14061](https://github.com/cosmos/cosmos-sdk/pull/14061) Adds openapi specification.
|
||||
* [#13832](https://github.com/cosmos/cosmos-sdk/pull/13832) Correctly populates rosetta's `/network/status` endpoint response. Rosetta's data api is divided into its own go files (account, block, mempool, network).
|
||||
|
||||
|
||||
2
tx/textual/internal/testdata/README.md
vendored
2
tx/textual/internal/testdata/README.md
vendored
@ -1,3 +1,3 @@
|
||||
# Testdata
|
||||
|
||||
This folder contains test vectors shared between [CosmJS](https://github.com/cosmos/cosmjs/pull/1147) and the Cosmos SDK.
|
||||
This folder contains test vectors shared between [CosmJS](https://github.com/cosmos/cosmjs/pull/1147) and the Cosmos SDK.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user