Merge branch 'main' into query-committed

docs/basics/README.md

@@ -11,8 +11,7 @@ This repository contains reference documentation on the basic concepts of Etherm
 1. [Accounts](./accounts.md)
 2. [Gas and Fees](./gas.md)
 3. [Lifecycle of a transaction](./transactions.md)
-4. [Photon](./photon.md)
+4. [Tokens](./tokens.md)
 5. [JSON-RPC Server](./json_rpc.md)
-6. [Hard Spoon](./hard_spoon.md)
 
 After reading the basics, head on to the [Core Reference](../core/README.md) for more advanced material.

docs/basics/accounts.md

@@ -17,7 +17,7 @@ Ethermint defines its own custom `Account` type that uses Ethereum's ECDSA secp2
 satisfies the [EIP84](https://github.com/ethereum/EIPs/issues/84) for full [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) paths.
 The root HD path for Ethermint-based accounts is `m/44'/60'/0'/0`.
 
-+++ https://github.com/tharsis/ethermint/blob/v0.1.0/types/account.go#L31-L36
++++ https://github.com/tharsis/ethermint/blob/main/types/account.pb.go#L28-L33
 
 ## Addresses and Public Keys
 
@@ -49,7 +49,7 @@ You can query an account address using the Cosmos CLI or REST clients:
 
 ```bash
 # NOTE: the --output (-o) flag will define the output format in JSON or YAML (text)
-ethermintcli q auth account $(ethermintcli keys show <MYKEY> -a) -o text
+ethermintd q auth account $(ethermintd keys show <MYKEY> -a) -o text
 |
   address: eth1f8rqrfwut7ngkxwth0gt99h0lxnxsp09ngvzwl
   eth_address: 0x49c601A5DC5FA68b19CBbbd0b296eFF9a66805e5
@@ -70,7 +70,7 @@ curl -X GET "<NODE_IP>/auth/accounts/eth1f8rqrfwut7ngkxwth0gt99h0lxnxsp09ngvzwl"
 ```
 
 ::: tip
-The Cosmos SDK Keyring output (i.e `ethermintcli keys`) only supports addresses and public keys in Bech32 format.
+The Cosmos SDK Keyring output (i.e `ethermintd keys`) only supports addresses and public keys in Bech32 format.
 :::
 
 To retrieve the Ethereum hex address using Web3, use the JSON-RPC [`eth_accounts`](./json_rpc.md#eth-accounts) endpoint:

docs/basics/gas.md

@@ -36,59 +36,50 @@ computational power to complete and as a way to deter bad-acting users from spam
 
 In the Cosmos SDK, gas is tracked in the main `GasMeter` and the `BlockGasMeter`:
 
-- `GasMeter`: keeps track of the gas consumed during executions that lead to state transitions. It is reset on every transaction  execution.
+- `GasMeter`: keeps track of the gas consumed during executions that lead to state transitions. It is reset on every transaction execution.
 - `BlockGasMeter`: keeps track of the gas consumed in a block and enforces that the gas does not go over a predefined limit. This limit is defined in the Tendermint consensus parameters and can be changed via governance parameter change proposals.
 
 More information regarding gas in Cosmos SDK can be found [here](https://docs.cosmos.network/master/basics/gas-fees.html).
 
 ## Matching EVM Gas consumption
 
 Ethermint is an EVM-compatible chain that supports Ethereum Web3 tooling. For this reason, gas
-consumption must be equitable in order to accurately calculate the state transition hashes and exact
-the behaviour that would be seen on the main Ethereum network (main net).
+consumption must be equitable with other EVMs, most importantly Ethereum.
 
-In Cosmos, there are types of operations that are not triggered by transactions that can also result in state transitions. Concrete examples are the  `BeginBlock` and `EndBlock` operations and the `AnteHandler` checks, which might also read and write to the store before running the state transition from a transaction.
+The main difference between EVM and Cosmos state transitions, is that the EVM uses a [gas table](https://github.com/ethereum/go-ethereum/blob/master/params/protocol_params.go) for each OPCODE, whereas Cosmos uses a `GasConfig` that charges gas for each CRUD operation by setting a flat and per-byte cost for accessing the database.
 
-### `BeginBlock` and `EndBlock`
++++ https://github.com/cosmos/cosmos-sdk/blob/3fd376bd5659f076a4dc79b644573299fd1ec1bf/store/types/gas.go#L187-L196
 
-These operations are defined by the Tendermint Core's Application Blockchain Interface (ABCI) and are defined by each Cosmos SDK module. As their name suggest, they are executed at the beginning and at the end of each block processing respectively (i.e pre and post transaction execution). Since these operations are not reflected on Ethereum, to match the the gas consumption we reset the main `GasMeter` to 0 on Ethermint's EVM module.
+In order to match the the gas consumed by the EVM, the gas consumption logic from the SDK is ignored, and instead the gas consumed is calculated by subtracting the state transition leftover gas from the gas limit defined on the message.
 
 ### `AnteHandler`
 
 The Cosmos SDK [`AnteHandler`](https://docs.cosmos.network/master/basics/gas-fees.html#antehandler)
 performs basic checks prior to transaction execution. These checks are usually signature
 verification, transaction field validation, transaction fees, etc.
 
-Because the gas calculated in Ethermint is done by the `IntrinsicGas` method from go-ethereum, a
-special `AnteHandler` that is customized for EVM transaction fee verification is required. This
-allows Ethermint to generate the expected gas costs for operations done in the network and scale the
-gas costs as it would in the Ethereum network.
+Regarding gas consumption and fees, the `AnteHandler` checks that the user has enough balance to
+cover for the tx cost (amount plus fees) as well as checking that the gas limit defined in the
+message is greater or equal than the computed intrinsic gas for the message.
 
 ## Gas Refunds
 
-In Ethereum, gas can be specified prior to execution and the remaining gas will be refunded back to
-the user if any gas is left over - should fail with out of gas if not enough gas was provided. In
-Ethermint, the concept of gas refunds does not exist and the fees paid is not refunded in part back
-to the user. The fees exacted on a transaction will be collected by the validator and no refunds are
-issued. Thus, it is extremely important to use the correct gas.
-
-To prevent overspending on fees, providing the `--gas-adjustment` flag for a cosmos transactions
-will determine the fees automatically. Also the `eth_estimateGas` rpc call can be used to manually
-get the correct gas costs for a transaction.
+In The EVM, gas can be specified prior to execution and the remaining gas will be refunded back to
+the user if any gas is left over. The same logic applies to Ethermint, where the gas refunded will be capped to a fraction of the used gas depending on the fork/version being used.
 
 ## 0 Fee Transactions
 
 In Cosmos, a minimum gas price is not enforced by the `AnteHandler` as the `min-gas-prices` is
 checked against the local node/validator. In other words, the minimum fees accepted are determined
-by the validators of the network, and each validator can specify a different value for their fees.
+by the validators of the network, and each validator can specify a different minimum value for their fees.
 This potentially allows end users to submit 0 fee transactions if there is at least one single
 validator that is willing to include transactions with `0` gas price in their blocks proposed.
 
 For this same reason, in Ethermint it is possible to send transactions with `0` fees for transaction
 types other than the ones defined by the `evm` module. EVM module transactions cannot have `0` fees
-as gas is required inherently by Ethereum. This check is done by the evm transactions
-`ValidateBasic` function as well as on the custom `AnteHandler` defined by Ethermint.
+as gas is required inherently by the EVM. This check is done by the EVM transactions stateless validation
+(i.e `ValidateBasic`) function as well as on the custom `AnteHandler` defined by Ethermint.
 
 ## Next {hide}
 
-Learn about the [Photon](./photon.md) token {hide}
+Learn about the different types of [tokens](./tokens.md) available {hide}

docs/basics/json_rpc.md

@@ -19,7 +19,7 @@ To enable RPC server use the following flag (set to true by default).
 ethermintd start --evm-rpc.enable
 ```
 
-By default, only `eth` namespace is enabled. In order to enable other namespaces use flag `--evm-rpc.api`.
+`Eth`,`Net` and `Web3` namespaces are enabled by default. In order to enable other namespaces use flag `--evm-rpc.api`.
 
 ```
 ethermintd start --evm-rpc.api eth,txpool,personal,net,debug,web3

docs/basics/tokens.md

@@ -0,0 +1,40 @@
+<!--
+order: 4
+-->
+
+# Tokens
+
+Learn about the the different types of tokens available in Ethermint. {synopsis}
+
+## Introduction
+
+Ethermint is a Cosmos SDK-based chain with full EVM support. Because of this architecture, tokens and assets in the network may come from different independent sources: the `bank` module and the `evm` module.
+
+## Cosmos Coins
+
+Accounts can own SDK coins in their balance, which are used for operations with other Cosmos modules and transactions. Examples of these are using the coins for staking, IBC transfers, governance deposits and EVM  
+
+### Photon
+
+The denomination used for staking, governance and gas consumption on the EVM is the Photon. The Photon provides the utility of: securing the Proof-of-Stake chain, token used for governance proposals, fee distribution and as a mean of gas for running smart contracts on the EVM.
+
+Ethermint uses [Atto](https://en.wikipedia.org/wiki/Atto-) Photon as the base denomination to maintain parity with Ethereum.
+
+```
+1 photon = 1×10⁻¹⁸ aphoton
+```
+
+This matches Ethereum denomination of:
+
+```
+1 ETH = 1x10⁻¹⁸ wei
+```
+
+### EVM Tokens
+
+Ethermint is compatible with ERC20 tokens and other non-fungible token standards (EIP721, EIP1155)
+that are natively supported by the EVM. One important remark is that these tokens don't interact with the Cosmos modules and other Cosmos SDK coins.
+
+## Next {hide}
+
+Learn about the supported [JSON-RPC](./json_rpc.md) methods on Ethermint {hide}

docs/basics/transactions.md

@@ -7,38 +7,30 @@ order: 2
 ## Routing
 
 Ethermint needs to parse and handle transactions routed for both the EVM and for the Cosmos hub. We
-attempt to achieve this by mimicking [Geth's](https://github.com/ethereum/go-ethereum) `Transaction`
+attempt to achieve this by mimicking [geth's](https://github.com/ethereum/go-ethereum) `Transaction`
 structure and treat it as a unique Cosmos SDK message type. An Ethereum transaction is a single
-[`sdk.Msg`](https://godoc.org/github.com/cosmos/cosmos-sdk/types#Msg) contained in an
-[`auth.StdTx`](https://godoc.org/github.com/cosmos/cosmos-sdk/x/auth#StdTx). All relevant Ethereum
+[`sdk.Msg`](https://godoc.org/github.com/cosmos/cosmos-sdk/types#Msg). All relevant Ethereum
 transaction information is contained in this message. This includes the signature, gas, payload,
-etc.
+amount, etc.
 
 Being that Ethermint implements the Tendermint ABCI application interface, as transactions are
 consumed, they are passed through a series of handlers. Once such handler, the `AnteHandler`, is
 responsible for performing preliminary message execution business logic such as fee payment,
 signature verification, etc. This is particular to Cosmos SDK routed transactions. Ethereum routed
 transactions will bypass this as the EVM handles the same business logic.
 
-Ethereum routed transactions coming from a Web3 source are expected to be [RLP](./../core/encoding.md#rlp) encoded, however all
-internal interaction between Ethermint and Tendermint will utilize one of the supported encoding
-formats: [Protobuf](./../core/encoding.md#protocol-buffers) and [Amino](./../core/encoding.md#amino).
+All EVM transactions are [RLP](./../core/encoding.md#rlp) encoded using a custom tx encoder.
 
-## Transaction formats
+## Signers
 
-<!-- TODO: -->
+The signature processing and verification in Ethereum is performed by the `Signer` interface. The
+protocol supports different signer types based on the chain configuration params and the block number.
 
-- Cosmos transactions
-- Ethereum transaction
++++ https://github.com/ethereum/go-ethereum/blob/v1.10.3/core/types/transaction_signing.go#L145-L166
 
-## Signatures
-
-Ethermint supports [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md)
-signatures. A `Transaction` is expected to have a single signature for Ethereum routed transactions.
-However, just as in Cosmos, Ethermint will support multiple signers for non-Ethereum transactions.
-Signatures over the `Transaction` type are identical to Ethereum and the signatures will not be
-duplicated in the embedding
-[`auth.StdTx`](https://godoc.org/github.com/cosmos/cosmos-sdk/x/auth#StdTx).
+Ethermint supports all Ethereum `Signer`s up to the latest go-ethereum version (London, Berlin,
+EIP155, Homestead and Frontier). The chain will generate the latest `Signer` type depending on the
+`ChainConfig`.
 
 ## Next {hide}
 

docs/core/README.md

@@ -10,5 +10,6 @@ This repository contains reference documentation on the core concepts of Ethermi
 
 1. [Encoding](./encoding.md)
 2. [Pending State](./pending_state.md)
+3. [Protobuf Docs](./proto-docs.md)
 
 After reading the core concepts, head on to the [guides](../guides/README.md) to learn how to use Ethereum tooling with Ethermint.

docs/core/encoding.md

@@ -17,14 +17,14 @@ Learn about the encoding formats used on Ethermint. {synopsis}
 
 The Cosmos [Stargate](https://stargate.cosmos.network/) release introduces
 [protobuf](https://developers.google.com/protocol-buffers) as the main encoding format for both
-client and state serialization. All the EVM module structs that are used for state and clients
+client and state serialization. All the EVM module types that are used for state and clients
 (transaction messages, genesis, query services, etc) will be implemented as protocol buffer messages.
 
 ### Amino
 
 The Cosmos SDK also supports the legacy Amino encoding format for backwards compatibility with
-previous versions, specially for client encoding. Ethermint will not support Amino in the EVM module
-once the migration to SDK `v0.40` is finalized.
+previous versions, specially for client encoding and signing with Ledger devices. Ethermint does not
+support Amino in the EVM module, but it is supported for all other Cosmos SDK modules that enable it.
 
 ### RLP
 
@@ -33,9 +33,36 @@ allows for quick reconstruction of encoded data. Ethermint uses RLP to encode/de
 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.
 
-Each message type defined on the EVM module define the `EncodeRLP` and `DecodeRLP` methods which
-implement the `rlp.Encoder` and `rlp.Decoder` interfaces respectively. The RLP encode method is used
-to sign bytes and transactions in `RLPSignBytes` and `Sign`.
+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
+func (g txConfig) TxEncoder() sdk.TxEncoder {
+  return func(tx sdk.Tx) ([]byte, error) {
+    msg, ok := tx.(*evmtypes.MsgEthereumTx)
+    if ok {
+      return msg.AsTransaction().MarshalBinary()
+   }
+    return g.TxConfig.TxEncoder()(tx)
+  }
+}
+
+// TxDecoder overwrites sdk.TxDecoder to support MsgEthereumTx
+func (g txConfig) TxDecoder() sdk.TxDecoder {
+  return func(txBytes []byte) (sdk.Tx, error) {
+    tx := &ethtypes.Transaction{}
+
+    err := tx.UnmarshalBinary(txBytes)
+    if err == nil {
+      msg := &evmtypes.MsgEthereumTx{}
+      msg.FromEthereumTx(tx)
+      return msg, nil
+    }
+
+    return g.TxConfig.TxDecoder()(txBytes)
+  }
+}
+```
 
 ## Next {hide}
 

docs/guides/cloud_testnet.md

@@ -60,11 +60,10 @@ Clone and build Ethermint in the droplet using `git`:
 go install https://github.com/tharsis/ethermint.git
 ```
 
-Check that the binaries have been successfuly installed:
+Check that the binaries have been successfully installed:
 
 ```bash
 ethermintd -h
-ethermintcli -h
 ```
 
 ### Copy the Genesis File
@@ -85,4 +84,4 @@ Once the genesis file is copied over run `ethermind start` inside the node dropl
 
 ## Next {hide}
 
-Follow [Deploy node to public testnet](./deploy_node_on_public_testnet.md)
+Follow [Deploy node to public testnet](./deploy_node_on_public_testnet.md)