From c139627733050dfbb41ef21cfb1e23adb563f032 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Federico=20Kunze=20K=C3=BCllmer?= Date: Tue, 29 Mar 2022 12:55:57 +0200 Subject: [PATCH 1/2] docs: add warnings for keyring-backend test --- docs/guides/keys-wallets/keyring.md | 44 +++++++++++++++++++--------- docs/guides/keys-wallets/metamask.md | 2 +- docs/guides/localnet/single_node.md | 8 ++--- docs/guides/localnet/testnet_cmd.md | 2 +- docs/guides/validators/faq.md | 8 ++++- docs/guides/validators/setup.md | 6 ++++ docs/mainnet/join.md | 6 ++++ docs/quickstart/binary.md | 22 +++++++------- 8 files changed, 66 insertions(+), 32 deletions(-) diff --git a/docs/guides/keys-wallets/keyring.md b/docs/guides/keys-wallets/keyring.md index 506e92088d..1a801ee3c2 100644 --- a/docs/guides/keys-wallets/keyring.md +++ b/docs/guides/keys-wallets/keyring.md @@ -10,25 +10,43 @@ The keyring holds the private/public keypairs used to interact with the node. Fo ## Add keys -You can use `evmosd keys` for help with the keys command and `evmosd keys [command] --help` for more information about a particular subcommand. +You can use the following commands for help with the `keys` command and for more information about a particular subcommand, respectively: -To create a new key in the keyring, run the `add` subcommand with a `` argument. For the purpose of this tutorial, we will solely use the `test` backend, and call our new key `mykey`. This key will be used in the next section. +```bash +evmosd keys +``` ```bash -evmosd keys add mykey --keyring-backend test +evmosd keys [command] --help +``` + +To create a new key in the keyring, run the `add` subcommand with a `` argument. You will have to provide a password for the newly generated key. This key will be used in the next section. + +```bash +evmosd keys add mykey # Put the generated address in a variable for later use. -MY_VALIDATOR_ADDRESS=$(evmosd keys show mykey -a --keyring-backend test) +MY_VALIDATOR_ADDRESS=$(evmosd keys show mykey -a) ``` This command generates a new 24-word mnemonic phrase, persists it to the relevant backend, and outputs information about the keypair. If this keypair will be used to hold value-bearing tokens, be sure to write down the mnemonic phrase somewhere safe! -By default, the keyring generates a `eth_secp256k1` keypair. The keyring also supports `ed25519` keys, which may be created by passing the `--algo` flag. A keyring can of course hold both types of keys simultaneously. +By default, the keyring generates a `eth_secp256k1` key. The keyring also supports `ed25519` keys, which may be created by passing the `--algo` flag. A keyring can of course hold both types of keys simultaneously. + +::: warning +**NOTE**: Cosmos `secp256k1` keys are not supported on Evmos due to compatibility issues with Ethereum transactions. +::: ## Keyring Backends ### OS +::: tip +**`os`** is the default option since operating system's default credentials managers are +designed to meet users' most common needs and provide them with a comfortable +experience without compromising on security. +::: + The `os` backend relies on operating system-specific defaults to handle key storage securely. Typically, an operating system's credential sub-system handles password prompts, private keys storage, and user sessions according to the user's password policies. Here @@ -46,10 +64,6 @@ commonly provided with [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_ Whilst the former is in fact a `libsecret` convenient frontend, the latter is a `kwallet` client. -`os` is the default option since operating system's default credentials managers are -designed to meet users' most common needs and provide them with a comfortable -experience without compromising on security. - The recommended backends for headless environments are `file` and `pass`. ### File @@ -81,7 +95,7 @@ operating systems as well as GNU/Linux distributions. Please refer to its manual information on how to download and install it. ::: tip -**pass** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent` +**`pass`** uses [GnuPG](https://gnupg.org/) for encryption. `gpg` automatically invokes the `gpg-agent` daemon upon execution, which handles the caching of GnuPG credentials. Please refer to `gpg-agent` man page for more information on how to configure cache parameters such as credentials TTL and passphrase expiration. @@ -106,10 +120,12 @@ information. ### Testing The `test` backend is a password-less variation of the `file` backend. Keys are stored -**unencrypted** on disk. +**unencrypted** on disk. This keyring is provided for testing purposes only. Use at your own risk! -:::danger -Provided for testing purposes only. The `test` backend is **NOT** recommended for use in production environments. +::: danger +🚨 **DANGER**: Never create your mainnet validator keys using a `test` keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint. + +Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/) ::: ### In Memory @@ -117,5 +133,5 @@ Provided for testing purposes only. The `test` backend is **NOT** recommended fo The `memory` backend stores keys in memory. The keys are immediately deleted after the program has exited. :::danger -Provided for testing purposes only. The `memory` backend is **NOT** recommended for use in production environments. +**IMPORTANT**: Provided for testing purposes only. The `memory` backend is **not** recommended for use in production environments. Use at your own risk! ::: diff --git a/docs/guides/keys-wallets/metamask.md b/docs/guides/keys-wallets/metamask.md index ae50a545fe..69e07f74f1 100644 --- a/docs/guides/keys-wallets/metamask.md +++ b/docs/guides/keys-wallets/metamask.md @@ -74,7 +74,7 @@ Close the `Settings`, go to `My Accounts` (top right circle) and select `Import Now you can export your private key from the terminal using the following command. Again, make sure to replace `mykey` with the name of the key that you want to export and use the correct `keyring-backend`: ```bash -evmosd keys unsafe-export-eth-key mykey --keyring-backend test +evmosd keys unsafe-export-eth-key mykey ``` Go back to the browser and select the `Private Key` option. Then paste the private key exported from the `unsafe-export-eth-key` command. diff --git a/docs/guides/localnet/single_node.md b/docs/guides/localnet/single_node.md index 4e7c1fe40b..0930779d8d 100644 --- a/docs/guides/localnet/single_node.md +++ b/docs/guides/localnet/single_node.md @@ -15,7 +15,7 @@ You can customize the local testnet script by changing values for convenience fo ```bash # customize the name of your key, the chain-id, moniker of the node, keyring backend, and log level KEY="mykey" -CHAINID="evmos_9000-2" +CHAINID="evmos_9000-3" MONIKER="localtestnet" KEYRING="test" LOGLEVEL="info" @@ -48,7 +48,7 @@ Before actually running the node, we need to initialize the chain, and most impo ```bash $MONIKER=testing $KEY=mykey -$CHAINID="evmos_9000-2" +$CHAINID="evmos_9000-3" # The argument $MONIKER is the custom username of your node, it should be human-readable. evmosd init $MONIKER --chain-id=$CHAINID @@ -67,13 +67,13 @@ The command above creates all the configuration files needed for your node and v Before starting the chain, you need to populate the state with at least one account using the [keyring](./../keys-wallets/keyring.md#add-keys): ```bash -evmosd keys add my_validator --keyring-backend=test +evmosd keys add my_validator ``` Once you have created a local account, go ahead and grant it some `aevmos` tokens in your chain's genesis file. Doing so will also make sure your chain is aware of this account's existence: ```bash -evmosd add-genesis-account my_validator 10000000000aevmos --keyring-backend test +evmosd add-genesis-account my_validator 10000000000aevmos ``` Now that your account has some tokens, you need to add a validator to your chain. diff --git a/docs/guides/localnet/testnet_cmd.md b/docs/guides/localnet/testnet_cmd.md index b3ee8f950c..85d3b868c7 100644 --- a/docs/guides/localnet/testnet_cmd.md +++ b/docs/guides/localnet/testnet_cmd.md @@ -80,7 +80,7 @@ evmosd status Import the key from the provided mnemonic: ```bash -evmosd keys add test --recover --keyring-backend test +evmosd keys add test --recover ``` Check the balance of the account address: diff --git a/docs/guides/validators/faq.md b/docs/guides/validators/faq.md index 175bc79f33..8e0acc4721 100644 --- a/docs/guides/validators/faq.md +++ b/docs/guides/validators/faq.md @@ -61,11 +61,17 @@ evmosd tx staking create-validator --commission-max-change-rate="0.01" --min-self-delegation "1" --moniker "validator" - --chain-id "evmos_9000-2" + --chain-id "evmos_9000-3" --gas auto --node tcp://127.0.0.1:26647 ``` +::: danger +🚨 **DANGER**: Never create your mainnet validator keys using a [`test`](./../keys-wallets/keyring.md#testing) keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint. + +Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/) +::: + Once a validator is created and registered, EVMOS holders can delegate EVMOS to it, effectively adding stake to its pool. The total stake of a validator is the sum of the EVMOS self-bonded by the validator's operator and the EVMOS bonded by external delegators. **Only the top 150 validators with the most stake are considered the active validators**, becoming **bonded validators**. If ever a validator's total stake dips below the top 150, the validator loses its validator privileges (meaning that it won't generate rewards) and no longer serves as part of the active set (i.e doesn't participate in consensus), entering **unbonding mode** and eventually becomes **unbonded**. diff --git a/docs/guides/validators/setup.md b/docs/guides/validators/setup.md index 46c98becab..805da30f9b 100644 --- a/docs/guides/validators/setup.md +++ b/docs/guides/validators/setup.md @@ -46,6 +46,12 @@ Your `evmosvalconspub` can be used to create a new validator by staking tokens. evmosd tendermint show-validator ``` +::: danger +🚨 **DANGER**: Never create your mainnet validator keys using a [`test`](./../keys-wallets/keyring.md#testing) keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint. + +Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/) +::: + To create your validator, just use the following command: ```bash diff --git a/docs/mainnet/join.md b/docs/mainnet/join.md index 542ebb3b34..9d04994f12 100644 --- a/docs/mainnet/join.md +++ b/docs/mainnet/join.md @@ -134,6 +134,12 @@ evmosd tx staking create-validator \ --from= ``` +::: danger +🚨 **DANGER**: Never create your validator keys using a [`test`](./../guides/keys-wallets/keyring.md#testing) keying backend. Doing so might result in a loss of funds by making your funds remotely accessible via the `eth_sendTransaction` JSON-RPC endpoint. + +Ref: [Security Advisory: Insecurely configured geth can make funds remotely accessible](https://blog.ethereum.org/2015/08/29/security-alert-insecurely-configured-geth-can-make-funds-remotely-accessible/) +::: + ## Start mainnet The final step is to [start the nodes](./../quickstart/run_node#start-node). Once enough voting power (+2/3) from the genesis validators is up-and-running, the node will start producing blocks. diff --git a/docs/quickstart/binary.md b/docs/quickstart/binary.md index 6eb17d19b2..d1897497e7 100644 --- a/docs/quickstart/binary.md +++ b/docs/quickstart/binary.md @@ -109,13 +109,13 @@ evmosd config We can make changes to the default settings upon our choices, so it allows users to set the configuration beforehand all at once, so it would be ready with the same config afterward. -For example, the chain identifier can be changed to `evmos_9000-2` from a blank name by using: +For example, the chain identifier can be changed to `evmos_9000-3` from a blank name by using: ```bash -evmosd config "chain-id" evmos_9000-2 +evmosd config "chain-id" evmos_9000-3 evmosd config { - "chain-id": "evmos_9000-2", + "chain-id": "evmos_9000-3", "keyring-backend": "os", "output": "text", "node": "tcp://localhost:26657", @@ -135,7 +135,7 @@ Alternatively, we can directly make the changes to the config values in one plac # The network chain ID -chain-id = "evmos_9000-2" +chain-id = "evmos_9000-3" # The keyring's backend, where the keys are stored (os|file|kwallet|pass|test|memory) @@ -171,19 +171,19 @@ evmosd config A list of commonly used flags of `evmosd` is listed below: -| Option | Description | Type | Default Value | -|---------------------|-------------------------------|--------------|-----------------| -| `--chain-id` | Full Chain ID | String | --- | -| `--home` | Directory for config and data | string | `~/.evmosd` | -| `--keyring-backend` | Select keyring's backend | os/file/test | os | -| `--output` | Output format | string | "text" | +| Option | Description | Type | Default Value | +| ------------------- | ----------------------------- | ------------------------------------------------ | ------------- | +| `--chain-id` | Full Chain ID | `string` | `""` | +| `--home` | Directory for config and data | `string` | `~/.evmosd` | +| `--keyring-backend` | Select keyring's backend | `{"os"|"file"|"kwallet"|"pass"|"test"|"memory"}` | `"os"` | +| `--output` | Output format | `string` | "text" | ## Command list A list of commonly used `evmosd` commands. You can obtain the full list by using the `evmosd -h` command. | Command | Description | Subcommands (example) | -|--------------|--------------------------|---------------------------------------------------------------------------| +| ------------ | ------------------------ | ------------------------------------------------------------------------- | | `keys` | Keys management | `list`, `show`, `add`, `add --recover`, `delete` | | `tx` | Transactions subcommands | `bank send`, `ibc-transfer transfer`, `distribution withdraw-all-rewards` | | `query` | Query subcommands | `bank balance`, `staking validators`, `gov proposals` | From 59d35ae36a7124d26529a9f16742c521181b531d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Federico=20Kunze=20K=C3=BCllmer?= Date: Tue, 29 Mar 2022 13:08:11 +0200 Subject: [PATCH 2/2] fix lint --- docs/guides/validators/setup.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/guides/validators/setup.md b/docs/guides/validators/setup.md index 805da30f9b..7aaeedb71d 100644 --- a/docs/guides/validators/setup.md +++ b/docs/guides/validators/setup.md @@ -31,10 +31,10 @@ architecture. To run testnet nodes, you will need a machine with the following minimum hardware requirements: -- 4 or more physical CPU cores -- At least 500GB of SSD disk storage -- At least 32GB of memory (RAM) -- At least 100mbps network bandwidth +* 4 or more physical CPU cores +* At least 500GB of SSD disk storage +* At least 32GB of memory (RAM) +* At least 100mbps network bandwidth As the usage of the blockchain grows, the server requirements may increase as well, so you should have a plan for updating your server as well. @@ -133,11 +133,11 @@ evmosd tx staking edit-validator --commission-rate="0.10" ``` -__Note__: The `commission-rate` value must adhere to the following invariants: +**Note**: The `commission-rate` value must adhere to the following invariants: -- Must be between 0 and the validator's `commission-max-rate` -- Must not exceed the validator's `commission-max-change-rate` which is maximum - % point change rate __per day__. In other words, a validator can only change +* Must be between 0 and the validator's `commission-max-rate` +* Must not exceed the validator's `commission-max-change-rate` which is maximum + % point change rate **per day**. In other words, a validator can only change its commission once per day and within `commission-max-change-rate` bounds. ## View Validator Description