From f664540db0ac626110dee5d4d1e330458434b6df Mon Sep 17 00:00:00 2001 From: MalteHerrmann Date: Tue, 23 Jan 2024 13:42:20 +0100 Subject: [PATCH] fix linters --- docs/develop/api/ethereum-json-rpc/methods.md | 33 +++++++--- docs/develop/api/tendermint-rpc.md | 9 ++- docs/develop/graphs-indexers/index.md | 1 + docs/develop/oracles/index.md | 15 +++-- .../evm-extensions/ibc-transfer.md | 3 +- docs/develop/smart-contracts/index.md | 3 +- docs/develop/tools/tools-plugins.md | 34 ++++++++-- docs/protocol/concepts/accounts.md | 10 ++- docs/protocol/concepts/encoding.md | 6 +- docs/protocol/concepts/keyring.md | 8 +-- docs/protocol/concepts/signing.md | 2 +- docs/protocol/evmos-cli/multi-nodes.md | 2 +- docs/protocol/faq.md | 1 - docs/protocol/ibc-channels.md | 10 +-- docs/protocol/module-accounts.md | 9 ++- docs/protocol/modules/claims.md | 6 -- docs/protocol/modules/epochs.md | 3 - docs/protocol/modules/erc20.md | 7 -- docs/protocol/modules/feemarket.md | 11 +--- docs/protocol/modules/incentives.md | 7 -- docs/protocol/modules/index.md | 8 ++- docs/protocol/modules/recovery.md | 5 -- docs/protocol/modules/revenue.md | 3 - docs/protocol/modules/vesting.md | 4 +- docs/validate/relayers.md | 10 ++- docs/validate/security/index.md | 58 +++++++++++----- .../run-a-validator.md | 66 ++++++++++++++----- 27 files changed, 206 insertions(+), 128 deletions(-) diff --git a/docs/develop/api/ethereum-json-rpc/methods.md b/docs/develop/api/ethereum-json-rpc/methods.md index 84806e9e..0be151af 100644 --- a/docs/develop/api/ethereum-json-rpc/methods.md +++ b/docs/develop/api/ethereum-json-rpc/methods.md @@ -8,7 +8,10 @@ Find below a list of JSON-RPC methods supported on Evmos, sorted by namespaces. ## Curl Examples Explained -The curl options below might return a response where the node complains about the content type, this is because the `--data` option sets the content type to `application/x-www-form-urlencoded`. If your node does complain, manually set the header by placing `-H "Content-Type: application/json"` at the start of the call. +The curl options below might return a response where the node complains about the content type, +this is because the `--data` option sets the content type to `application/x-www-form-urlencoded`. +If your node does complain, manually set the header +by placing `-H "Content-Type: application/json"` at the start of the call. The examples also do not include the URL/IP & port combination which must be the last argument given to curl e.x. `127.0.0.1:8545` @@ -277,7 +280,8 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[] ### `eth_syncing` -The sync status object may need to be different depending on the details of Tendermint's sync protocol. However, the 'synced' result is simply a boolean, and can easily be derived from Tendermint's internal sync state. +The sync status object may need to be different depending on the details of Tendermint's sync protocol. +However, the 'synced' result is simply a boolean, and can easily be derived from Tendermint's internal sync state. ```json // Request @@ -468,15 +472,18 @@ Sends transaction from given account to a given account. `to`: `DATA`, 20 Bytes - (optional when creating new contract) The address the transaction is directed to. - `gas`: QUANTITY - (optional, default: 90000) Integer of the gas provided for the transaction execution. It will return unused gas. + `gas`: QUANTITY - (optional, default: 90000) Integer of the gas provided for the transaction execution. + It will return unused gas. `gasPrice`: QUANTITY - (optional, default: To-Be-Determined) Integer of the gasPrice used for each paid gas `value`: QUANTITY - value sent with this transaction - `data`: `DATA` - The compiled code of a contract OR the hash of the invoked method signature and encoded parameters. For details see Ethereum Contract ABI + `data`: `DATA` - The compiled code of a contract OR the hash of the invoked method signature and encoded parameters. + For details see Ethereum Contract ABI. - `nonce`: QUANTITY - (optional) Integer of a nonce. This allows to overwrite your own pending transactions that use the same nonce. + `nonce`: QUANTITY - (optional) Integer of a nonce. + This allows to overwrite your own pending transactions that use the same nonce. ```json // Request @@ -515,13 +522,15 @@ Executes a new message call immediately without creating a transaction on the bl `to`: `DATA`, 20 Bytes - The address the transaction is directed to. - `gas`: QUANTITY - gas provided for the transaction execution. eth_call consumes zero gas, but this parameter may be needed by some executions. + `gas`: QUANTITY - gas provided for the transaction execution. + eth_call consumes zero gas, but this parameter may be needed by some executions. `gasPrice`: QUANTITY - gasPrice used for each paid gas `value`: QUANTITY - value sent with this transaction - `data`: `DATA` - (optional) Hash of the method signature and encoded parameters. For details see Ethereum Contract ABI in the Solidity documentation + `data`: `DATA` - (optional) Hash of the method signature and encoded parameters. + For details see Ethereum Contract ABI in the Solidity documentation - Block number or Block Hash ([EIP-1898](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1898.md)) @@ -911,7 +920,9 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"personal_lockAccount","params":[ **Private**: Requires authentication. ::: -Generates a new private key and stores it in the key store directory. The key file is encrypted with the given passphrase. Returns the address of the new account. +Generates a new private key and stores it in the key store directory. +The key file is encrypted with the given passphrase. +It returns the address of the new account. #### Parameters @@ -1184,11 +1195,13 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"miner_setExtra","params":["data" **Private**: Requires authentication. ::: -Sets the minimal gas price used to accept transactions. Any transaction below this limit is excluded from the validator block proposal process. +Sets the minimal gas price used to accept transactions. +Any transaction below this limit is excluded from the validator block proposal process. This method requires a `node` restart after being called because it changes the configuration file. -Make sure your `evmosd start` call is not using the flag `minimum-gas-prices` because this value will be used instead of the one set on the configuration file. +Make sure your `evmosd start` call is not using the flag `minimum-gas-prices`, +because this value will be used instead of the one set on the configuration file. #### Parameters diff --git a/docs/develop/api/tendermint-rpc.md b/docs/develop/api/tendermint-rpc.md index 3f961763..56f03f6c 100644 --- a/docs/develop/api/tendermint-rpc.md +++ b/docs/develop/api/tendermint-rpc.md @@ -43,7 +43,11 @@ More on Events: ### Subscribing to Events via Websocket -Tendermint Core provides a [Websocket](https://docs.tendermint.com/v0.34/tendermint-core/subscription.html) connection to subscribe or unsubscribe to Tendermint `Events`. To start a connection with the Tendermint websocket you need to define the address with the `--rpc.laddr` flag when starting the node (default `tcp://127.0.0.1:26657`): +Tendermint Core provides a [Websocket](https://docs.tendermint.com/v0.34/tendermint-core/subscription.html) connection +to subscribe or unsubscribe to Tendermint `Events`. +To start a connection with the Tendermint websocket you need to +define the address with the `--rpc.laddr` flag when starting the node +(default `tcp://127.0.0.1:26657`): ```bash evmosd start --rpc.laddr="tcp://127.0.0.1:26657" @@ -98,7 +102,8 @@ The main events you can subscribe to are: - `ValidatorSetUpdates`: Contains validator set updates for the block. :::tip -👉 The list of events types and values for each Cosmos SDK module can be found in the [Modules Specification](./../../../../protocol/modules/) section. +👉 The list of events types and values for each Cosmos SDK module +can be found in the [Modules Specification](./../../../../protocol/modules/) section. Check the `Events` page to obtain the event list of each supported module on Evmos. ::: diff --git a/docs/develop/graphs-indexers/index.md b/docs/develop/graphs-indexers/index.md index 65266558..412d2b2f 100644 --- a/docs/develop/graphs-indexers/index.md +++ b/docs/develop/graphs-indexers/index.md @@ -9,6 +9,7 @@ find all transactions that include a specific token. This type of indexing can g of decentralized applications and make it easier for users to access and analyze the data stored on the blockchain. ## List of Graph Indexers + ### Mainnet | Service | Description | Support | Links & Features | diff --git a/docs/develop/oracles/index.md b/docs/develop/oracles/index.md index d5ddab9a..0de81721 100644 --- a/docs/develop/oracles/index.md +++ b/docs/develop/oracles/index.md @@ -47,10 +47,15 @@ This enables smart contracts to respond to real-world events, trigger automated In this diagram: -* External Data Source refers to a source of data outside the blockchain network, such as a stock market, weather service, or other external API. -* Oracle Service is a third-party service that acts as a bridge between the external data source and the smart contract. It retrieves the data from the external source and provides it to the smart contract. -* Smart Contract is a self-executing contract that is deployed on the blockchain network. It uses the data provided by the oracle to perform certain actions, such as releasing funds or triggering events. +* External Data Source refers to a source of data outside the blockchain network, +such as a stock market, weather service, or other external API. +* Oracle Service is a third-party service that acts as a bridge between the external data source and the smart contract. +It retrieves the data from the external source and provides it to the smart contract. +* Smart Contract is a self-executing contract that is deployed on the blockchain network. +It uses the data provided by the oracle to perform certain actions, such as releasing funds or triggering events. * API Call refers to the request made by the smart contract to the oracle service, asking for the required external data. -* Retrieve External Data refers to the process of retrieving the requested data from the external data source via the API call. -* Use External Data refers to the process of using the retrieved data in the smart contract to perform actions, such as condition checking and state changes. +* Retrieve External Data refers to the process of retrieving the requested data +from the external data source via the API call. +* Use External Data refers to the process of using the retrieved data in the smart contract to perform actions, +such as condition checking and state changes. * Return Result refers to the process of returning the result of the action performed in the smart contract back to the oracle. diff --git a/docs/develop/smart-contracts/evm-extensions/ibc-transfer.md b/docs/develop/smart-contracts/evm-extensions/ibc-transfer.md index 0dfd5442..437c6c55 100644 --- a/docs/develop/smart-contracts/evm-extensions/ibc-transfer.md +++ b/docs/develop/smart-contracts/evm-extensions/ibc-transfer.md @@ -6,7 +6,8 @@ sidebar_position: 5 ## Solidity Interface & ABI -`ICS20.sol` - previously known as `IBCTransfer.sol` - is an interface through which Solidity contracts can interact with the IBC protocol on Evmos chain. +`ICS20.sol` - previously known as `IBCTransfer.sol` - +is an interface through which Solidity contracts can interact with the IBC protocol on Evmos chain. This is convenient for developers as they don’t need to know the implementation details behind the `transfer` module in [IBC-go](https://ibc.cosmos.network/). Instead, they can perform IBC transfers using the Ethereum interface they are familiar with. An example of a simple implementation can be found in the [evmos/extensions repo](https://github.com/evmos/extensions/tree/main/examples/simple-ibc-transfer). diff --git a/docs/develop/smart-contracts/index.md b/docs/develop/smart-contracts/index.md index 8d883a34..3e7ad001 100644 --- a/docs/develop/smart-contracts/index.md +++ b/docs/develop/smart-contracts/index.md @@ -39,7 +39,8 @@ implementation, such as hashing, elliptic curve cryptography, and modular expone By adding custom EVM extensions to Ethereum's basic feature set, Evmos allows developers to use previously unavailable functionality in smart contracts, like staking and governance operations. -This will allow more complex smart contracts to be built on Evmos and further improves the interoperability between Cosmos and Ethereum. +This will allow more complex smart contracts to be built on Evmos +and further improves the interoperability between Cosmos and Ethereum. It also is a key feature to achieve Evmos' vision of being the definitive dApp chain, where any dApp can be deployed once and users can interact with a wide range of different blockchains natively. diff --git a/docs/develop/tools/tools-plugins.md b/docs/develop/tools/tools-plugins.md index d606f480..d368f2b0 100644 --- a/docs/develop/tools/tools-plugins.md +++ b/docs/develop/tools/tools-plugins.md @@ -6,15 +6,37 @@ sidebar_position: 4 ## Smart Contract Development Tools -- [Remix](https://remix.ethereum.org/#optimize=false&runs=200&evmVersion=null&version=soljson-v0.8.17+commit.8df45f5f.js) is a free, browser-based Integrated Development Environment (IDE) for writing, testing, and deploying smart contracts on the Ethereum blockchain. It is designed to make it easier for developers to get started with building decentralized applications (dapps) by providing a simple and user-friendly interface for writing and deploying smart contracts. With Remix, you can write, test, and deploy smart contracts written in Solidity. It also includes debugging tools and a simulation environment for testing contracts before deploying them to the blockchain. The tool provides plugins as well. -- [Truffle Suite](https://trufflesuite.com/docs/) contains a suite of comprehensive tools to streamline the process of building and testing smart contracts, and deploying them to any EVM network, like EVMOS network in Javascript/Typescript. The suite contains [Truffle](https://trufflesuite.com/docs/truffle/) to make compiling, testing, debugging, and deploying smart contract development. [Ganache](https://trufflesuite.com/docs/ganache/) provides easy and fast local blockchain development environment with UI and CLI functionalities. [Drizzle](https://trufflesuite.com/docs/drizzle/) packs frontend libraries that enables standard-compliant wallet connection, account, and contract state management through React components. -- [Foundry](https://getfoundry.sh/) is RUST toolkit that enables fast, portable, and modular application development for Ethereum and EVM-compatible chains. -- [Hardhat](https://hardhat.org/) is a JS/TS library that allow comprehensive testing, development, and deploying smart contracts. Hardhat contains many [plugins](https://hardhat.org/hardhat-runner/plugins) to aid further developments. +- [Remix](https://remix.ethereum.org/#optimize=false&runs=200&evmVersion=null&version=soljson-v0.8.17+commit.8df45f5f.js) +is a free, browser-based Integrated Development Environment (IDE) +for writing, testing, and deploying smart contracts on the Ethereum blockchain. +It is designed to make it easier for developers to get started with building decentralized applications (dapps) +by providing a simple and user-friendly interface for writing and deploying smart contracts. +With Remix, you can write, test, and deploy smart contracts written in Solidity. +It also includes debugging tools and a simulation environment +for testing contracts before deploying them to the blockchain. +The tool provides plugins as well. +- [Truffle Suite](https://trufflesuite.com/docs/) contains a suite of comprehensive tools +to streamline the process of building and testing smart contracts, +and deploying them to any EVM network, like EVMOS network in Javascript/Typescript. +The suite contains [Truffle](https://trufflesuite.com/docs/truffle/) +to make compiling, testing, debugging, and deploying smart contract development. +[Ganache](https://trufflesuite.com/docs/ganache/) provides easy and fast local blockchain development environment +with UI and CLI functionalities. +[Drizzle](https://trufflesuite.com/docs/drizzle/) packs frontend libraries +that enables standard-compliant wallet connection, account, +and contract state management through React components. +- [Foundry](https://getfoundry.sh/) is RUST toolkit that enables fast, portable, +and modular application development for Ethereum and EVM-compatible chains. +- [Hardhat](https://hardhat.org/) is a JS/TS library that allow comprehensive testing, development, and deploying smart contracts. +Hardhat contains many [plugins](https://hardhat.org/hardhat-runner/plugins) to aid further developments. ## Open Sourced Contracts -- [OpenZeppelin](https://www.openzeppelin.com/contracts) contains battle-tested libraries of smart contracts for Ethereum-compatible chains and includes the most used ERC standards. +- [OpenZeppelin](https://www.openzeppelin.com/contracts) contains battle-tested libraries of smart contracts +for Ethereum-compatible chains and includes the most used ERC standards. ## IDE -- [Truffle for VSCode](https://trufflesuite.com/docs/vscode-ext/) is a Visual Studio Code extension that simplifies how you create, build, debug, and deploy smart contracts on Ethereum and EVM-compatible blockchains. +- [Truffle for VSCode](https://trufflesuite.com/docs/vscode-ext/) is a Visual Studio Code extension +that simplifies how you create, build, debug, +and deploy smart contracts on Ethereum and EVM-compatible blockchains. diff --git a/docs/protocol/concepts/accounts.md b/docs/protocol/concepts/accounts.md index 53c23465..998e07d3 100644 --- a/docs/protocol/concepts/accounts.md +++ b/docs/protocol/concepts/accounts.md @@ -29,7 +29,8 @@ Creating a mnemonic phrase gives you control of many accounts, all accessible with that same phrase. Cosmos blockchains, like Evmos, support creating accounts with mnemonic phrases, -otherwise known as [hierarchical deterministic key generation](https://github.com/confio/cosmos-hd-key-derivation-spec) (HD keys). +otherwise known as +[hierarchical deterministic key generation](https://github.com/confio/cosmos-hd-key-derivation-spec) (HD keys). This allows the user to create accounts on multiple blockchains without having to manage multiple secrets. @@ -117,7 +118,8 @@ There are 3 main types of HRP for the `Addresses`/`PubKeys` available by default ### Address formats for clients -`EthAccount` can be represented in both [Bech32](https://en.bitcoin.it/wiki/Bech32) (`evmos1...`) and hex (`0x...`) formats for Ethereum's Web3 tooling compatibility. +`EthAccount` can be represented in both [Bech32](https://en.bitcoin.it/wiki/Bech32) (`evmos1...`) +and hex (`0x...`) formats for Ethereum's Web3 tooling compatibility. The Bech32 format is the default format for Cosmos-SDK queries and transactions through CLI and REST clients. The hex format on the other hand, is the Ethereum `common.Address` representation of a @@ -213,7 +215,9 @@ curl -X GET "http://localhost:10337/cosmos/auth/v1beta1/accounts/evmos14au322k9m ### JSON-RPC -To retrieve the Ethereum hex address using Web3, use the JSON-RPC [`eth_accounts`](./../../develop/api/ethereum-json-rpc/methods#eth-accounts) or [`personal_listAccounts`](./../../develop/api/ethereum-json-rpc/methods#personal-listAccounts) endpoints: +To retrieve the Ethereum hex address using Web3, +use the JSON-RPC [`eth_accounts`](./../../develop/api/ethereum-json-rpc/methods#eth-accounts) +or [`personal_listAccounts`](./../../develop/api/ethereum-json-rpc/methods#personal-listAccounts) endpoints: ```bash # query against a local node diff --git a/docs/protocol/concepts/encoding.md b/docs/protocol/concepts/encoding.md index 9f00ab8d..9797cbd0 100644 --- a/docs/protocol/concepts/encoding.md +++ b/docs/protocol/concepts/encoding.md @@ -57,12 +57,14 @@ support Amino in the EVM module, but it is supported for all other Cosmos SDK mo ### RLP -Recursive Length Prefix ([RLP](https://eth.wiki/en/fundamentals/rlp)), is an encoding/decoding algorithm that serializes a message and +Recursive Length Prefix ([RLP](https://eth.wiki/en/fundamentals/rlp)), +is an encoding/decoding algorithm that serializes a message and allows for quick reconstruction of encoded data. Evmos uses RLP to encode/decode Ethereum messages for JSON-RPC handling to conform messages to the proper Ethereum format. This allows messages to be encoded and decoded in the exact format as Ethereum's. -The `x/evm` transactions (`MsgEthereumTx`) encoding is performed by casting the message to a go-ethereum's `Transaction` and then marshaling the transaction data using RLP: +The `x/evm` transactions (`MsgEthereumTx`) encoding is performed by casting the message to a go-ethereum's `Transaction` +and then marshaling the transaction data using RLP: ```go // TxEncoder overwrites sdk.TxEncoder to support MsgEthereumTx diff --git a/docs/protocol/concepts/keyring.md b/docs/protocol/concepts/keyring.md index 18a9936e..7c59e41c 100644 --- a/docs/protocol/concepts/keyring.md +++ b/docs/protocol/concepts/keyring.md @@ -7,7 +7,7 @@ sidebar_position: 7 Create, import, export and delete keys using the CLI keyring. The keyring holds the private/public keypairs used to interact with the node. For instance, a validator key needs to be -set up before running the node, so that blocks can be correctly signed. The private key can be stored in different +set up before running the node, so that blocks can be correctly signed. The private key can be stored in different locations, called ["backends"](#keyring-backends), such as a file or the operating system's own key storage. :::tip @@ -38,14 +38,14 @@ MY_VALIDATOR_ADDRESS=$(evmosd keys show dev0 -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 +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` key. The keyring also supports `ed25519` keys, which may be created +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. :::tip -**Note**: The Ethereum address associated with a public key can be derived by taking the full Ethereum public key of type +**Note**: The Ethereum address associated with a public key can be derived by taking the full Ethereum public key of type `eth_secp256k1`, computing the `Keccak-256` hash, and truncating the first twelve bytes. ::: diff --git a/docs/protocol/concepts/signing.md b/docs/protocol/concepts/signing.md index 6d70a6cf..ec958028 100644 --- a/docs/protocol/concepts/signing.md +++ b/docs/protocol/concepts/signing.md @@ -9,7 +9,7 @@ on the Evmos network. The signature is created using a specific cryptographic al ensures the authenticity and integrity of the transaction using methods like [wallets](https://academy.evmos.org/articles/wallet) and the [CLI](./../evmos-cli). -There are different methods for signing, but one of the most commonly used methods is the +There are different methods for signing, but one of the most commonly used methods is the [EIP-712](https://eips.ethereum.org/EIPS/eip-712) standard. Evmos leverages EIP-712 to homogenize the interaction between the EVM and Cosmos. diff --git a/docs/protocol/evmos-cli/multi-nodes.md b/docs/protocol/evmos-cli/multi-nodes.md index f7c026a9..29da3b5b 100644 --- a/docs/protocol/evmos-cli/multi-nodes.md +++ b/docs/protocol/evmos-cli/multi-nodes.md @@ -179,7 +179,7 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1 The IP address will be the public IP of the docker container. ::: -Additional instructions on how to interact with the WebSocket can be found on the +Additional instructions on how to interact with the WebSocket can be found on the [events documentation](./../../develop/api/ethereum-json-rpc#ethereum-websocket). ### Keys & Accounts diff --git a/docs/protocol/faq.md b/docs/protocol/faq.md index 8842302e..271ca4b2 100644 --- a/docs/protocol/faq.md +++ b/docs/protocol/faq.md @@ -29,7 +29,6 @@ of security and performance, and you can afford to sacrifice some compatibility, -
Where can I find the Protobuf interfaces for Evmos? diff --git a/docs/protocol/ibc-channels.md b/docs/protocol/ibc-channels.md index 839bcec9..6884789b 100644 --- a/docs/protocol/ibc-channels.md +++ b/docs/protocol/ibc-channels.md @@ -4,10 +4,12 @@ sidebar_position: 5 # IBC Channels -IBC channels are a key component of the Inter-blockchain Communication (IBC) protocol used in the Cosmos ecosystem. -IBC channels enable communication between different Cosmos chains, allowing the transfer of tokens and data between -them. Each IBC channel has a unique identifier known as the channel ID, which is used to specify the source and -destination of a transfer. The channel ID can change depending on which relayers are active, so it's important to +IBC channels are a key component of the Inter-blockchain Communication (IBC) protocol used in the Cosmos ecosystem. +IBC channels enable communication between different Cosmos chains, +allowing the transfer of tokens and data between them. +Each IBC channel has a unique identifier known as the channel ID, +which is used to specify the source and destination of a transfer. +The channel ID can change depending on which relayers are active, so it's important to double-check the channel IDs before making a transfer. :::tip diff --git a/docs/protocol/module-accounts.md b/docs/protocol/module-accounts.md index 8a2dfd83..00d62ba3 100644 --- a/docs/protocol/module-accounts.md +++ b/docs/protocol/module-accounts.md @@ -33,8 +33,10 @@ Below is a table of modules, their respective wallet addresses and permissions: ## IBC Module Accounts Additionally, there are module accounts associated with IBC transfers. -For each IBC connection, there's an account of type `ModuleAccount` used to escrow the transferred coins when Evmos is the source chain. -Their addresses are derived using the first 20 bytes of the SHA256 checksum of the account name and following the format as outlined in [ADR 028](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses.md): +For each IBC connection, there's an account of type `ModuleAccount` used to escrow the transferred coins +when Evmos is the source chain. +Their addresses are derived using the first 20 bytes of the SHA256 checksum of the account name and following the format +as outlined in [ADR 028](https://github.com/cosmos/cosmos-sdk/blob/master/docs/architecture/adr-028-public-key-addresses.md): ```go // accountName is composed by the current version the IBC transfer module supports (in this case, ics20-1), the portID (transfer) and the channelID @@ -54,6 +56,7 @@ This can be calculated with the [`GetEscrowAccount` function on IBC-go](https:// evmosd q auth module-accounts ``` -This happens because the [`GetModuleAccount` function](https://github.com/cosmos/cosmos-sdk/blob/74d7a0dfcd9f47d8a507205f82c264a269ef0612/x/auth/keeper/keeper.go#L194-L224) used on the query considers only the accounts on the [`permAddrs` map of the `AccountKeeper`](https://github.com/cosmos/cosmos-sdk/blob/74d7a0dfcd9f47d8a507205f82c264a269ef0612/x/auth/keeper/keeper.go#L54-L68). +This happens because the [`GetModuleAccount` function](https://github.com/cosmos/cosmos-sdk/blob/74d7a0dfcd9f47d8a507205f82c264a269ef0612/x/auth/keeper/keeper.go#L194-L224) +used on the query considers only the accounts on the [`permAddrs` map of the `AccountKeeper`](https://github.com/cosmos/cosmos-sdk/blob/74d7a0dfcd9f47d8a507205f82c264a269ef0612/x/auth/keeper/keeper.go#L54-L68). This address map is set at compile time and cannot be changed on runtime. ::: diff --git a/docs/protocol/modules/claims.md b/docs/protocol/modules/claims.md index fc78a174..468b4209 100644 --- a/docs/protocol/modules/claims.md +++ b/docs/protocol/modules/claims.md @@ -163,7 +163,6 @@ After the claim period ends, the tokens that were not claimed by users will be t In the same way, users with tokens allocated but no transactions (i.e nonce = 0), will have their balance clawbacked to the community pool. - ## State ### State Objects @@ -224,7 +223,6 @@ balance := k.bankKeeper.GetBalance(ctx, moduleAccAddr, params.ClaimsDenom) isInvariantBroken := !expectedUnclaimed.Equal(balance.Amount.ToDec()) ``` - ## State Transitions ### ABCI @@ -248,7 +246,6 @@ The ABCI EndBlock checks if the airdrop has ended in order to process the clawba 4. Prune all the claim records from the state 5. Disable any further claim by setting the global parameter to `false` - ## Hooks The `x/claims` module implements transaction hooks for each of the four actions @@ -365,7 +362,6 @@ the `ClaimsRecord` is merged with the recipient's claims record. 4. neither the sender or recipient have a claims record -> perform a no-op by returning the original success acknowledgement - ## Events The `x/claims` module emits the following events: @@ -386,7 +382,6 @@ The `x/claims` module emits the following events: | `merge_claims_records` | `"claimed_coins"` | `{claimed_coins.String()}` | | `merge_claims_records` | `"fund_community_pool_coins"` | `{remainderCoins.String()}` | - ## Parameters The `x/claims` module contains the parameters described below. All parameters can be modified via governance. @@ -437,7 +432,6 @@ that users can perform the ibc callback with to claim coins for the ibc action. The `EVMChannels` parameter describes the list of Evmos channels that connected to EVM compatible chains and can be used during the ibc callback action. - ## Clients A user can query the `x/claims` module using the CLI, gRPC or REST. diff --git a/docs/protocol/modules/epochs.md b/docs/protocol/modules/epochs.md index ef05b402..899c98b9 100644 --- a/docs/protocol/modules/epochs.md +++ b/docs/protocol/modules/epochs.md @@ -31,7 +31,6 @@ We refer to the period in between two timer ticks as an "epoch". Every timer has a unique identifier, and every epoch will have a start time and an end time, where `end time = start time + timer interval`. - ## State ### State Objects @@ -190,7 +189,6 @@ so they can be modified by governance. Governance can change epoch periods from `week` to `day` as needed. - ## Queries The `x/epochs` module provides the following queries to check the module's state. @@ -204,7 +202,6 @@ service Query { } ``` - ## Future Improvements ### Correct Usage diff --git a/docs/protocol/modules/erc20.md b/docs/protocol/modules/erc20.md index f7716d74..2a9d52c4 100644 --- a/docs/protocol/modules/erc20.md +++ b/docs/protocol/modules/erc20.md @@ -167,7 +167,6 @@ Here are our recommendations for the reviewing process: - contract should be audited by a reputabele auditor - inherited contracts need to be verified for correctness - ## State ### State Objects @@ -263,7 +262,6 @@ type GenesisState struct { } ``` - ## State Transitions The erc20 modules allows for two types of registration state transitions. @@ -403,7 +401,6 @@ by using escrow & mint / burn & unescrow logic. 4. Check if token balance increased by amount 5. Fail if unexpected `Approval` event found in logs to prevent malicious contract behaviour - ## Transactions This section defines the `sdk.Msg` concrete types that result in the state transitions defined on the previous section. @@ -522,7 +519,6 @@ type ToggleTokenConversionProposal struct { } ``` - ## Hooks The erc20 module implements transaction hooks from the EVM in order to trigger token pair conversion. @@ -559,7 +555,6 @@ as the balance prior to the transaction is not available in the hook. 1. Mint Cosmos Coin 2. Transfer Cosmos Coin to the bech32 account address of the sender hex - ## Events The `x/erc20` module emits the following events: @@ -605,7 +600,6 @@ The `x/erc20` module emits the following events: | `convert_erc20` | `"cosmos_coin"` | `{denom}` | | `convert_erc20` | `"erc20_token"` | `{msg.ContractAddress}` | - ## Parameters The erc20 module contains the following parameters: @@ -625,7 +619,6 @@ When the parameter is disabled, it will prevent all token pair registration and The `EnableEVMHook` parameter enables the EVM hook to convert an ERC20 token to a Cosmos Coin by transferring the Tokens through a `MsgEthereumTx` to the `ModuleAddress` Ethereum address. - ## Clients ### CLI diff --git a/docs/protocol/modules/feemarket.md b/docs/protocol/modules/feemarket.md index bc1f898e..5545f2c9 100644 --- a/docs/protocol/modules/feemarket.md +++ b/docs/protocol/modules/feemarket.md @@ -10,7 +10,7 @@ The `MempoolFeeDecorator` in `x/auth` module needs to be overwritten to check the `baseFee` along with the `minimal-gas-prices` allowing to implement a global fee mechanism which vary depending on the network activity. -For more reference to EIP1559: +For more reference to EIP-1559: @@ -26,7 +26,6 @@ For more reference to EIP1559: 8. **[Client](#client)** 9. **[AnteHandlers](#antehandlers)** - ## Concepts ### EIP-1559: Fee Market @@ -145,7 +144,6 @@ This is implemented, so that the base fee can't drop to gas prices that wouldn't allow transactions to be accepted in the mempool, because of a higher `MinGasPrice`. ::: - ## State The x/feemarket module keeps in the state variable needed to the fee calculation: @@ -156,7 +154,6 @@ Only BlockGasUsed in previous block needs to be tracked in state for the next ba | ----------- | ------------------------------ | ---------------| ------------------- | --------- | | BlockGasUsed | gas used in the block | `[]byte{1}` | `[]byte{gas_used}` | KV | - ## Begin block The base fee is calculated at the beginning of each block. @@ -214,7 +211,6 @@ else: ``` - ## End block The `block_gas_used` value is updated at the end of each block. @@ -225,7 +221,6 @@ The total gas used by current block is stored in the KVStore at `EndBlock`. It is initialized to `block_gas` defined in the genesis. - ## Keeper The feemarket module provides this exported keeper @@ -238,7 +233,6 @@ type Keeper interface { } ``` - ## Events The `x/feemarket` module emits the following events: @@ -256,7 +250,6 @@ The `x/feemarket` module emits the following events: | block_gas | height | {blockHeight} | | block_gas | amount | {blockGasUsed} | - ## Parameters The `x/feemarket` module contains the following parameters: @@ -270,7 +263,6 @@ The `x/feemarket` module contains the following parameters: | EnableHeight | uint32 | 0 | height which enable fee adjustment | | MinGasPrice | sdk.Dec | 0 | global minimum gas price that needs to be paid to include a transaction in a block | - ## Client ### CLI @@ -360,7 +352,6 @@ value: "2" | `GET` | `/ethermint/feemarket/v1/base_fee` | Get the block base fee | | `GET` | `/ethermint/feemarket/v1/block_gas` | Get the block gas used | - ## AnteHandlers The `x/feemarket` module provides `AnteDecorator`s that are recursively chained together diff --git a/docs/protocol/modules/incentives.md b/docs/protocol/modules/incentives.md index 9d2ec14c..e49333fb 100644 --- a/docs/protocol/modules/incentives.md +++ b/docs/protocol/modules/incentives.md @@ -91,7 +91,6 @@ by transferring them to the participants accounts. because the hook has access to the actual gas spent and the hash only includes the gas limit. ::: - ## State ### State Objects @@ -172,7 +171,6 @@ type GenesisState struct { } ``` - ## State Transitions The `x/incentive` module allows for two types of registration state transitions: @@ -197,7 +195,6 @@ the incentive module creates the incentive and distributes rewards. the module account needs to have a positive amount to distribute the incentives 4. The sum of all registered allocations for each denom (current + proposed) is < 100% - ## Transactions This section defines the `sdk.Msg` concrete types that result in the state transitions defined on the previous section. @@ -256,7 +253,6 @@ The proposal content stateless validation fails if: - Description is invalid (length or char) - Contract address is invalid - ## Hooks The `x/incentives` module implements two transaction hooks from the `x/evm` and `x/epoch` modules. @@ -306,7 +302,6 @@ and then 2) distributes these rewards to all participants of each incentive. and the sum of all active incentivized contracts' allocation is < 100%. The accumulated rewards are added to the allocation in the following epoch. - ## Events The `x/incentives` module emits the following events: @@ -331,7 +326,6 @@ The `x/incentives` module emits the following events: | `distribute_incentives` | `"contract"` | `{erc20_address}` | | `distribute_incentives` | `"epochs"` | `{strconv.FormatUint(uint64(in.Epochs), 10)}` | - ## Parameters The `x/incentives` module contains the parameters described below. All parameters can be modified via governance. @@ -368,7 +362,6 @@ An incentive allows users to earn rewards up to `rewards = k * sum(txFees)`, where `k` defines the reward scaler parameter that caps the incentives allocated to a single user by multiplying it to the sum of transaction fees that they’ve spent in the current epoch. - ## Clients A user can query the `x/incentives` module using the CLI, JSON-RPC, gRPC or REST. diff --git a/docs/protocol/modules/index.md b/docs/protocol/modules/index.md index 8a94e4a8..08d2af6f 100644 --- a/docs/protocol/modules/index.md +++ b/docs/protocol/modules/index.md @@ -24,13 +24,15 @@ Here is a list of all production-grade modules that can be used on the Evmos blo Evmos uses the following Cosmos SDK modules: - [auth](https://docs.cosmos.network/main/modules/auth) - Authentication of accounts and transactions for Cosmos SDK applications. -- [authz](https://docs.cosmos.network/main/modules/authz) - Authorization for accounts to perform actions on behalf of other accounts. +- [authz](https://docs.cosmos.network/main/modules/authz) - +Authorization for accounts to perform actions on behalf of other accounts. - [bank](https://docs.cosmos.network/main/modules/bank) - Token transfer functionalities. - [capability](https://ibc.cosmos.network/main/ibc/capability-module) - Object capability implementation. - [distribution](https://docs.cosmos.network/main/modules/distribution) - Fee distribution, and staking token provision distribution. - [evidence](https://docs.cosmos.network/main/modules/evidence) - Evidence handling for double signing, misbehaviour, etc. - [feegrant](https://docs.cosmos.network/main/modules/feegrant) - Grant fee allowances for executing transactions. -- [genutil](https://github.com/cosmos/cosmos-sdk/tree/main/x/genutil) - variaety of genesis utility functionalities for usage within a blockchain application +- [genutil](https://github.com/cosmos/cosmos-sdk/tree/main/x/genutil) - +variety of genesis utility functionalities for usage within a blockchain application - [gov](https://docs.cosmos.network/main/modules/gov) - On-chain proposals and voting. - [params](https://docs.cosmos.network/main/modules/params) - Globally available parameter store. - [slashing](https://docs.cosmos.network/main/modules/slashing) - Validator punishment mechanisms. @@ -42,4 +44,4 @@ Evmos uses the following Cosmos SDK modules: Evmos uses the following the IBC modules for the SDK: - [interchain-accounts](https://ibc.cosmos.network/main/apps/interchain-accounts/overview.html) -- [transfer](https://ibc.cosmos.network/main/apps/transfer/overview.html) \ No newline at end of file +- [transfer](https://ibc.cosmos.network/main/apps/transfer/overview.html) diff --git a/docs/protocol/modules/recovery.md b/docs/protocol/modules/recovery.md index 32a91afe..7a446bab 100644 --- a/docs/protocol/modules/recovery.md +++ b/docs/protocol/modules/recovery.md @@ -153,7 +153,6 @@ and in that case the recovery will not be triggered by the transaction, as it wi So if at any point either the IBC transfer or the claims middleware return an error, then the recovery middleware will not be executed. - ## Hooks The `x/recovery` module allows for state transitions that return IBC tokens @@ -198,7 +197,6 @@ The behavior is implemented using an IBC`OnRecvPacket` callback. 5. If the recipient does not have any balance, return without recovering tokens - ## Events The `x/recovery` module emits the following event: @@ -215,7 +213,6 @@ The `x/recovery` module emits the following event: | `recovery` | `packet_dst_channel` | `packet.DestinationPort` | | `recovery` | `packet_dst_port` | `packet.DestinationChannel` | - ## Parameters The `x/recovery` module contains the following parameters: @@ -235,7 +232,6 @@ When the parameter is disabled, it will disable the recovery of stuck tokens to The `PacketTimeoutDuration` parameter is the duration before the IBC packet timeouts and the transaction is reverted on the counter party chain. - ## Clients A user can query the `x/recovery` module using the CLI, gRPC or REST. @@ -264,4 +260,3 @@ evmosd query recovery params [flags] | :----- | :------------------------------- | :-------------------- | | `gRPC` | `evmos.recovery.v1.Query/Params` | `Get Recovery params` | | `GET` | `/evmos/recovery/v1/params` | `Get Recovery params` | - diff --git a/docs/protocol/modules/revenue.md b/docs/protocol/modules/revenue.md index e04c1a24..3602bb6f 100644 --- a/docs/protocol/modules/revenue.md +++ b/docs/protocol/modules/revenue.md @@ -338,7 +338,6 @@ to the withdraw address set for that contract, or to the contract deployer. 5. Distribute the remaining amount in the `FeeCollector` to validators according to the [SDK Distribution Scheme](https://docs.cosmos.network/main/modules/distribution#the-distribution-scheme). - ## Events The `x/revenue` module emits the following events: @@ -465,5 +464,3 @@ evmosd query revenue params - `CREATE2` opcode support for address derivation. When registering a smart contract, we verify that its address is derived from the deployer’s address. At this time, we only support the derivation path using the `CREATE` opcode, which accounts for most cases. - - diff --git a/docs/protocol/modules/vesting.md b/docs/protocol/modules/vesting.md index 8e175209..4a28aed5 100644 --- a/docs/protocol/modules/vesting.md +++ b/docs/protocol/modules/vesting.md @@ -41,7 +41,6 @@ to incentivize long-term participation in the project. - Agoric’s Vesting Clawback Account: [https://github.com/Agoric/agoric-sdk/issues/4085](https://github.com/Agoric/agoric-sdk/issues/4085) - Agoric’s `vestcalc` tool: [https://github.com/agoric-labs/cosmos-sdk/tree/Agoric/x/auth/vesting/cmd/vestcalc](https://github.com/agoric-labs/cosmos-sdk/tree/Agoric/x/auth/vesting/cmd/vestcalc) - ## Concepts ### Vesting @@ -188,8 +187,7 @@ Upon creation, the owner assigns a funder, who is able to fund the account with 2. Check if 1. the vesting address is not a blocked address. 2. the vesting address is a clawback vesting account. - 3. there is at least one vesting or lockup schedule provided. - If one of them is absent, default to instant vesting or unlock schedule. + 3. there is at least one vesting or lockup schedule provided. If one of them is absent, default to instant vesting or unlock schedule. 4. lockup and vesting total amounts are equal. 3. Update the clawback vesting account and send coins from the funder to the vesting account, merging any existing schedules with the new funding. diff --git a/docs/validate/relayers.md b/docs/validate/relayers.md index 85314ac4..d8d771ce 100644 --- a/docs/validate/relayers.md +++ b/docs/validate/relayers.md @@ -202,7 +202,8 @@ list = [ Add your relayer wallet to Hermes' keyring (located in `$HOME/.hermes/keys`) -The best practice is to use the same mnemonic over all networks. Do not use your relaying-addresses for anything else, because it will lead to account sequence errors. +The best practice is to use the same mnemonic over all networks. Do not use your relaying-addresses for anything else, +because it will lead to account sequence errors. ```bash hermes keys restore cosmoshub-4 -m "24-word mnemonic seed" @@ -238,7 +239,8 @@ When your nodes are fully synced, you can start the hermes daemon: hermes start ``` -Watch hermes' output for successfully relayed packets, or any errors. It will try and clear any unrecieved packets after startup has completed. +Watch hermes' output for successfully relayed packets, or any errors. +It will try and clear any unrecieved packets after startup has completed. ## Helpful Commands @@ -268,7 +270,9 @@ hermes clear packets cosmoshub-4 transfer channel-292 hermes clear packets evmos_9001-2 transfer channel-3 ``` -Clear unrecieved packets manually (experimental, will need to stop hermes daemon to prevent confusion with account sequences) with the following: +Clear unrecieved packets manually +(experimental, will need to stop hermes daemon to prevent confusion with account sequences) +with the following: ```bash hermes tx raw packet-recv evmos_9001-2 cosmoshub-4 transfer channel-292 diff --git a/docs/validate/security/index.md b/docs/validate/security/index.md index 0db186cf..59c899fb 100644 --- a/docs/validate/security/index.md +++ b/docs/validate/security/index.md @@ -4,49 +4,73 @@ sidebar_position: 1 # Validator Security -Each validator is encouraged to run its operations independently, as diverse setups increase the resilience of the network. Validator candidates should put aside meaningful time to guarantee a secure validator launch. +Each validator is encouraged to run its operations independently, as diverse setups increase the resilience of the network. +Validator candidates should put aside meaningful time to guarantee a secure validator launch. -In this section, you can learn about best practices for operating a validator securely without sacrificing block sign performance. This includes information on how to secure your private keys, run a cluster of nodes with remote access, mitigate the risk of double signing and contribute to DDOS protection on the network through sentry nodes. +In this section, you can learn about best practices for operating a validator securely without sacrificing block sign performance. +This includes information on how to secure your private keys, run a cluster of nodes with remote access, +mitigate the risk of double signing and contribute to DDOS protection on the network through sentry nodes. -Also, a [validator security checklist](./validator-security-checklist.md) is provided to conduct a survey on the current security measures of a validator. +Also, a [validator security checklist](./validator-security-checklist.md) is provided +to conduct a survey on the current security measures of a validator. ## Horcrux -Horcrux is a [multi-party-computation (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) signing service for Tendermint nodes, that improves your validator infrastructure in terms of security and availability. It offers +Horcrux is a [multi-party-computation (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) +signing service for Tendermint nodes, that improves your validator infrastructure in terms of security and availability. +It offers -- Composed of a cluster of signer nodes in place of the remote signer, enabling High Availability (HA) for block signing through fault tolerance. +- Composed of a cluster of signer nodes in place of the remote signer, +enabling High Availability (HA) for block signing through fault tolerance. - Secure your validator private key by splitting it across multiple private signer nodes using threshold Ed25519 signatures - Add security and availability without sacrificing block sign performance. -See the documentation [here](https://github.com/strangelove-ventures/horcrux/blob/main/docs/migrating.md) to learn how to upgrade your validator infrastructure with Horcrux. +See the documentation [here](https://github.com/strangelove-ventures/horcrux/blob/main/docs/migrating.md) +to learn how to upgrade your validator infrastructure with Horcrux. ## Hardware HSM -It is mission-critical that an attacker cannot steal a validator's key. If this is possible, it puts the entire stake delegated to the compromised validator at risk. Hardware security modules are an important strategy for mitigating this risk. +It is mission-critical that an attacker cannot steal a validator's key. +If this is possible, it puts the entire stake delegated to the compromised validator at risk. +Hardware security modules are an important strategy for mitigating this risk. -HSM modules must support `ed25519` signatures for Evmos. The [YubiHSM 2](https://www.yubico.com/products/hardware-security-module/) supports `ed25519` and can be used with this YubiKey [library](https://github.com/iqlusioninc/yubihsm.rs). +HSM modules must support `ed25519` signatures for Evmos. +The [YubiHSM 2](https://www.yubico.com/products/hardware-security-module/) supports `ed25519` +and can be used with this YubiKey [library](https://github.com/iqlusioninc/yubihsm.rs). :::info -🚨 **IMPORTANT**: The YubiHSM can protect a private key but **cannot ensure** in a secure setting that it won't sign the same block twice. +🚨 **IMPORTANT**: +The YubiHSM can protect a private key but **cannot ensure** in a secure setting that it won't sign the same block twice. ::: ## Tendermint KMS -Tendermint KMS is a signature service with support for Hardware Security Modules (HSMs), such as YubiHSM2 and Ledger -Nano. It is intended to be run alongside Cosmos Validators, ideally on separate physical hosts, providing -defense-in-depth for online validator signing keys, double signing protection, and functioning as a central -signing service that can be used when operating multiple validators in several Cosmos Zones. +Tendermint KMS is a signature service with support for Hardware Security Modules (HSMs), +such as YubiHSM2 and Ledger Nano. +It is intended to be run alongside Cosmos Validators, +ideally on separate physical hosts, providing defense-in-depth for online validator signing keys, +double signing protection, +and functioning as a central signing service that can be used when operating multiple validators in several Cosmos Zones. Learn how to set up a Key Management System for Evmos with Tendermint KMS [here](./tendermint-kms). ## Sentry Nodes (DDOS Protection) -Validators are responsible for ensuring that the network can sustain denial-of-service attacks. One recommended way +Validators are responsible for ensuring that the network can sustain denial-of-service attacks. One recommended way to mitigate these risks is for validators to carefully structure their network topology in a so-called sentry node architecture. -Validator nodes should only connect to full nodes they trust because they operate them themselves or are run by other validators they know socially. A validator node will typically run in a data center. Most data centers provide direct links to the networks of major cloud providers. The validator can use those links to connect to sentry nodes in the cloud. This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes and may require new sentry nodes to be spun up or activated to mitigate attacks on existing ones. - -Sentry nodes can be quickly spun up or change their IP addresses. Because the links to the sentry nodes are in private IP space, an internet-based attack cannot disturb them directly. This will ensure validator block proposals and votes always make it to the rest of the network. +Validator nodes should only connect to full nodes they trust because they operate them themselves +or are run by other validators they know socially. +A validator node will typically run in a data center. +Most data centers provide direct links to the networks of major cloud providers. +The validator can use those links to connect to sentry nodes in the cloud. +This shifts the burden of denial-of-service from the validator's node directly to its sentry nodes +and may require new sentry nodes to be spun up or activated to mitigate attacks on existing ones. + +Sentry nodes can be quickly spun up or change their IP addresses. +Because the links to the sentry nodes are in private IP space, +an internet-based attack cannot disturb them directly. +This will ensure validator block proposals and votes always make it to the rest of the network. :::tip Read more about Sentry Nodes on the [forum](https://forum.cosmos.network/t/sentry-node-architecture-overview/454) diff --git a/docs/validate/setup-and-configuration/run-a-validator.md b/docs/validate/setup-and-configuration/run-a-validator.md index f5379db2..ff6eadf4 100644 --- a/docs/validate/setup-and-configuration/run-a-validator.md +++ b/docs/validate/setup-and-configuration/run-a-validator.md @@ -8,11 +8,12 @@ Learn how to run a validator node. ## Prerequisite Readings -- [Validator Overview](./../) -- [Validator Security](./../security/validator-security) +- [Validator Overview](./../) +- [Validator Security](./../security/validator-security) :::tip -If you plan to use a Key Management System (KMS), you should go through these steps first: [Using a KMS](./../../validate/security/tendermint-kms). +If you plan to use a Key Management System (KMS), you should go through these steps first: +[Using a KMS](./../../validate/security/tendermint-kms). ::: :::warning @@ -31,7 +32,10 @@ evmosd tendermint show-validator ``` :::danger -🚨 **DANGER**: Never create your mainnet validator keys using a [`test`](./../../protocol/concepts/keyring#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. +🚨 **DANGER**: Never create your mainnet validator keys +using a [`test`](./../../protocol/concepts/keyring#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/) ::: @@ -54,22 +58,37 @@ evmosd tx staking create-validator \ ``` :::tip -When specifying commission parameters, the `commission-max-change-rate` is used to measure % *point* change over the `commission-rate`. E.g. 1% to 2% is a 100% rate increase, but only 1 percentage point. +When specifying commission parameters, the `commission-max-change-rate` is used +to measure % *point* change over the `commission-rate`, +e.g. 1% to 2% is a 100% rate increase, but only 1 percentage point. ::: :::tip -`Min-self-delegation` is a strictly positive integer that represents the minimum amount of self-delegated voting power your validator must always have. A `min-self-delegation` of `1000000` means your validator will never have a self-delegation lower than `1 atevmos` +`Min-self-delegation` is a strictly positive integer +that represents the minimum amount of self-delegated voting power your validator must always have. +A `min-self-delegation` of `1000000` means your validator will never have a self-delegation lower than `1 atevmos`. ::: You can confirm that you are in the validator set by using a third party explorer. ## Edit Validator Description -You can edit your validator's public description. This info is to identify your validator, and will be relied on by delegators to decide which validators to stake to. Make sure to provide input for every flag below. If a flag is not included in the command the field will default to empty (`--moniker` defaults to the machine name) if the field has never been set or remain the same if it has been set in the past. +You can edit your validator's public description. +This info is to identify your validator, and will be relied on by delegators to decide which validators to stake to. +Make sure to provide input for every flag below. +If a flag is not included in the command the field will default to empty +(`--moniker` defaults to the machine name) +if the field has never been set or remain the same if it has been set in the past. -The specifies which validator you are editing. If you choose to not include certain flags, remember that the --from flag must be included to identify the validator to update. +The specifies which validator you are editing. +If you choose to not include certain flags, remember that the --from flag must be included to identify the validator to update. -The `--identity` can be used as to verify identity with systems like Keybase or UPort. When using with Keybase `--identity` should be populated with a 16-digit string that is generated with a [keybase.io](https://keybase.io) account. It's a cryptographically secure method of verifying your identity across multiple online networks. The Keybase API allows us to retrieve your Keybase avatar. This is how you can add a logo to your validator profile. +The `--identity` can be used as to verify identity with systems like Keybase or UPort. +When using with Keybase `--identity` should be populated with a 16-digit string that is generated +with a [keybase.io](https://keybase.io) account. +It's a cryptographically secure method of verifying your identity across multiple online networks. +The Keybase API allows us to retrieve your Keybase avatar. +This is how you can add a logo to your validator profile. ```bash evmosd tx staking edit-validator @@ -110,7 +129,9 @@ evmosd query slashing signing-info \ ## Unjail Validator -When a validator is "jailed" for downtime, you must submit an `Unjail` transaction from the operator account in order to be able to get block proposer rewards again (depends on the zone fee distribution). +When a validator is "jailed" for downtime, you must submit an `Unjail` transaction from the operator account +in order to be able to get block proposer rewards again +(depends on the zone fee distribution). ```bash evmosd tx slashing unjail \ @@ -126,7 +147,8 @@ Your validator is active if the following command returns anything: evmosd query tendermint-validator-set | grep "$(evmosd tendermint show-address)" ``` -You should now see your validator in one of Evmos explorers. You are looking for the `bech32` encoded `address` in the `~/.evmosd/config/priv_validator.json` file. +You should now see your validator in one of Evmos explorers. +You are looking for the `bech32` encoded `address` in the `~/.evmosd/config/priv_validator.json` file. :::warning Note To be in the validator set, you need to have more total voting power than the 100th validator. @@ -145,15 +167,19 @@ the block. ### Problem #1: My validator has `voting_power: 0` -Your validator has become jailed. Validators get jailed, i.e. get removed from the active validator set, if they do not vote on `500` of the last `10000` blocks, or if they double sign. +Your validator has become jailed. +Validators get jailed, i.e. get removed from the active validator set, +if they do not vote on `500` of the last `10000` blocks, or if they double sign. -If you got jailed for downtime, you can get your voting power back to your validator. First, if `evmosd` is not running, start it up again: +If you got jailed for downtime, you can get your voting power back to your validator. +First, if `evmosd` is not running, start it up again: ```bash evmosd start ``` -Wait for your full node to catch up to the latest block. Then, you can [unjail your validator](#unjail-validator) +Wait for your full node to catch up to the latest block. +Then, you can [unjail your validator](#unjail-validator) Lastly, check your validator again to see if your voting power is back. @@ -161,11 +187,17 @@ Lastly, check your validator again to see if your voting power is back. evmosd status ``` -You may notice that your voting power is less than it used to be. That's because you got slashed for downtime! +You may notice that your voting power is less than it used to be. +That's because you got slashed for downtime! ### Problem #2: My node crashes because of `too many open files` -The default number of files Linux can open (per-process) is `1024`. `evmosd` is known to open more than `1024` files. This causes the process to crash. A quick fix is to run `ulimit -n 4096` (increase the number of open files allowed) and then restart the process with `evmosd start`. If you are using `systemd` or another process manager to launch `evmosd` this may require some configuration at that level. A sample `systemd` file to fix this issue is below: +The default number of files Linux can open (per-process) is `1024`. `evmosd` is known to open more than `1024` files. +This causes the process to crash. +A quick fix is to run `ulimit -n 4096` (increase the number of open files allowed) +and then restart the process with `evmosd start`. +If you are using `systemd` or another process manager to launch `evmosd` this may require some configuration at that level. +A sample `systemd` file to fix this issue is below: ```toml # /etc/systemd/system/evmosd.service @@ -184,4 +216,4 @@ LimitNOFILE=4096 [Install] WantedBy=multi-user.target -``` \ No newline at end of file +```