docs: updates (#590)

* gas docs

* add period

* pending state docs

* format

* fix links

* add more to pendingstate docs

* add more to gas docs

* add hardspoon doc

* minor fix to pendingstate doc

* note on rlp encoding

* usecase doc

* update encoding doc

* gas docs

* hard spoon and reorder

* fix links

* encoding

* pending state

* final touches

* update intro

* use cases and resources

* typo

Co-authored-by: Federico Kunze <federico.kunze94@gmail.com>
Co-authored-by: Federico Kunze <31522760+fedekunze@users.noreply.github.com>
This commit is contained in:
Daniel Choi 2020-11-12 11:42:24 -08:00 committed by GitHub
parent b2735dcd13
commit 71090323c0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
13 changed files with 238 additions and 77 deletions

View File

@ -13,5 +13,6 @@ This repository contains reference documentation on the basic concepts of Etherm
3. [Lifecycle of a transaction](./transactions.md) 3. [Lifecycle of a transaction](./transactions.md)
4. [Photon](./photon.md) 4. [Photon](./photon.md)
5. [JSON-RPC Server](./json_rpc.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. After reading the basics, head on to the [Core Reference](../core/README.md) for more advanced material.

View File

@ -73,7 +73,7 @@ curl -X GET "<NODE_IP>/auth/accounts/eth1f8rqrfwut7ngkxwth0gt99h0lxnxsp09ngvzwl"
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 `ethermintcli keys`) only supports addresses and public keys in Bech32 format.
::: :::
To retrieve the Ethereum hex address using Web3, use the JSON-RPC `eth_accounts` endpoint: To retrieve the Ethereum hex address using Web3, use the JSON-RPC [`eth_accounts`](./json_rpc.md#eth-accounts) endpoint:
```bash ```bash
# query against a local node # query against a local node

View File

@ -6,23 +6,88 @@ order: 3
Learn about the differences between `Gas` and `Fees` in Ethereum and Cosmos. {synopsis} Learn about the differences between `Gas` and `Fees` in Ethereum and Cosmos. {synopsis}
## Introduction to `Gas` in the SDK ## Pre-requisite Readings
<!-- TODO: --> - [Cosmos SDK Gas](https://docs.cosmos.network/master/basics/gas-fees.html) {prereq}
- [Ethereum Gas](https://ethereum.org/en/developers/docs/gas/) {prereq}
The concept of Gas represents the amount of computational effort required to execute specific operations on the state machine.
Gas was created on Ethereum to disallow the EVM (Ethereum Virtual Machine) from running infinite
loops by allocating a small amount of monetary value into the system. A unit of gas, usually in a
form as a fraction of the native coin, is consumed for every operation on the EVM and requires a
user to pay for these operations. These operations consist in state transitions such as sending a
transaction or calling a contract.
Exactly like Ethereum, Cosmos utilizes the concept of gas and this is how Cosmos tracks the resource
usage of operations during execution. Operations on Cosmos are represented as read or writes done to the chain's store.
In Cosmos, a fee is calculated and charged to the user during a message execution. This fee is
calculated from the sum of all gas consumed in an message execution:
```
fee = gas * gas price
```
In both networks, gas is used to make sure that operations do not require an excess amount of
computational power to complete and as a way to deter bad-acting users from spamming the network.
## Cosmos SDK `Gas`
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.
- `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 ## Matching EVM Gas consumption
<!-- TODO: --> 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).
## Gas refunds 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.
<!-- TODO: --> ### `BeginBlock` and `EndBlock`
## AnteHandler 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.
The `AnteHandler` is a special `handler` that is run for every transaction during `CheckTx` and `DeliverTx`, before the `handler` of each `message` in the transaction. `AnteHandler`s have a different signature than `handler`s ### `AnteHandler`
<!-- TODO: --> 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.
## 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.
## 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.
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.
## Next {hide} ## Next {hide}

17
docs/basics/hard_spoon.md Normal file
View File

@ -0,0 +1,17 @@
<!--
order: 6
-->
# Hard Spoon
Learn about Ethermint's Hard Spoon functionality. {synopsis}
## Hard Spoon on Ethermint
A [hard spoon](https://blog.cosmos.network/introducing-the-hard-spoon-4a9288d3f0df) is the migration of the snapshot of a target blockchain's state into a new chain. The state of a network can be imported (or "scooped") onto a separate chain to accurately replicate the account balances and other information from the state.
Ethermint's Hard Spoon tool (currently under specification) is targeted to import the state of the Ethereum mainnet to replicate the state for the given accounts. This will allow anyone on the Ethereum network to import their contracts into Ethermint.
## Next {hide}
Learn about the [encoding](./../core/encoding.md) formats used on Ethermint {hide}

View File

@ -895,4 +895,4 @@ curl -X POST --data '{"jsonrpc":"2.0","method":"personal_ecRecover","params":["0
## Next {hide} ## Next {hide}
Learn about the [encoding](./../core/encoding.md) formats used on Ethermint {hide} Learn about the Ethermint [Hard Spoon](./hard_spoon.md) functionality {hide}

View File

@ -20,9 +20,9 @@ responsible for performing preliminary message execution business logic such as
signature verification, etc. This is particular to Cosmos SDK routed transactions. Ethereum routed 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. 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 encoded, however all 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 internal interaction between Ethermint and Tendermint will utilize one of the supported encoding
formats: Protobuf, Amino or Hybrid of the previous two. formats: [Protobuf](./../core/encoding.md#protocol-buffers) and [Amino](./../core/encoding.md#amino).
## Transaction formats ## Transaction formats

View File

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

View File

@ -4,70 +4,39 @@ order: 1
# Encoding # Encoding
The `codec` is used everywhere in the Cosmos SDK to encode and decode structs and interfaces. The specific codec used in the Cosmos SDK is called `go-amino`. {synopsis} Learn about the encoding formats used on Ethermint. {synopsis}
## Pre-requisite Readings ## Pre-requisite Readings
- [Cosmos SDK Encoding](https://docs.cosmos.network/master/core/encoding.html) {prereq} - [Cosmos SDK Encoding](https://docs.cosmos.network/master/core/encoding.html) {prereq}
- [Ethereum RLP](https://eth.wiki/en/fundamentals/rlp) {prereq}
## Encoding Formats ## Encoding Formats
The Cosmos SDK utilizes two binary wire encoding protocols, [Amino](https://github.com/tendermint/go-amino/) ### Protocol Buffers
and [Protocol Buffers](https://developers.google.com/protocol-buffers), where Amino
is an object encoding specification. It is a subset of Proto3 with an extension for
interface support. See the [Proto3 spec](https://developers.google.com/protocol-buffers/docs/proto3)
for more information on Proto3, which Amino is largely compatible with (but not with Proto2).
Due to Amino having significant performance drawbacks, being reflection-based, and The Cosmos [Stargate](https://stargate.cosmos.network/) release introduces
not having any meaningful cross-language/client support, Protocol Buffers, specifically [protobuf](https://developers.google.com/protocol-buffers) as the main encoding format for both
[gogoprotobuf](https://github.com/gogo/protobuf/), is being used in place of Amino. client and state serialization. All the EVM module structs that are used for state and clients
Note, this process of using Protocol Buffers over Amino is still an ongoing process. (transaction messages, genesis, query services, etc) will be implemented as protocol buffer messages.
Binary wire encoding of types in the Cosmos SDK can be broken down into two main
categories, client encoding and store encoding. Client encoding mainly revolves
around transaction processing and signing, whereas store encoding revolves around
types used in state-machine transitions and what is ultimately stored in the Merkle
tree.
For store encoding, protobuf definitions can exist for any type and will typically
have an Amino-based "intermediary" type. Specifically, the protobuf-based type
definition is used for serialization and persistence, whereas the Amino-based type
is used for business logic in the state-machine where they may converted back-n-forth.
Note, the Amino-based types may slowly be phased-out in the future so developers
should take note to use the protobuf message definitions where possible.
In the `codec` package, there exists two core interfaces, `Marshaler` and `ProtoMarshaler`,
where the former encapsulates the current Amino interface except it operates on
types implementing the latter instead of generic `interface{}` types.
In addition, there exists three implementations of `Marshaler`. The first being
`AminoCodec`, where both binary and JSON serialization is handled via Amino. The
second being `ProtoCodec`, where both binary and JSON serialization is handled
via Protobuf. Finally, `HybridCodec`, a codec that utilizes Protobuf for binary
serialization and Amino for JSON serialization. The `HybridCodec` is typically
the codec that used in majority in situations as it's easier to use for client
and state serialization.
This means that modules may use Amino or Protobuf encoding but the types must
implement `ProtoMarshaler`. If modules wish to avoid implementing this interface
for their types, they may use an Amino codec directly.
### Amino ### Amino
Every module uses an Amino codec to serialize types and interfaces. This codec typically The Cosmos SDK also supports the legacy Amino encoding format for backwards compatibility with
has types and interfaces registered in that module's domain only (e.g. messages), previous versions, specially for client encoding. Ethermint will not support Amino in the EVM module
but there are exceptions like `x/gov`. Each module exposes a `RegisterCodec` function once the migration to SDK `v0.40` is finalized.
that allows a user to provide a codec and have all the types registered. An application
will call this method for each necessary module.
### Protobuf ### RLP
<!-- TODO: --> 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. Ethermint 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.
## RLP 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
<!-- TODO: --> to sign bytes and transactions in `RLPSignBytes` and `Sign`.
## Next {hide} ## Next {hide}
Learn how to deploy a Solidity smart contract on Ethermint using [Truffle](./../guides/truffle.md) {hide} Learn how [pending state](./pending_state.md) is handled on Ethermint. {hide}

View File

@ -0,0 +1,49 @@
<!--
order: 2
-->
# Pending State
Learn how Ethermint handles pending state queries. {synopsis}
## Pre-requisite Readings
- [Tendermint Mempool](https://docs.tendermint.com/master/tendermint-core/mempool.htm) {prereq}
## Ethermint vs Ethereum
In Ethereum, pending blocks are generated as they are queued for production by miners. These pending
blocks include pending transactions that are picked out by miners, based on the highest reward paid
in gas. This mechanism exists as block finality is not possible on the Ethereum network. Blocks are
committed with probabilistic finality, which means that transactions and blocks become less likely
to become reverted as more time (and blocks) passes.
Ethermint is designed quite differently on this front as there is no concept of a "pending state".
Ethermint uses [Tendermint Core](https://docs.tendermint.com/) BFT consensus which provides instant
finality for transaction. For this reason, Etheremint does not require a pending state mechanism, as
all (if not most) of the transactions will be committed to the next block (avg. block time on Cosmos chains is ~8s). However, this causes a
few hiccups in terms of the Ethereum Web3-compatible queries that can be made to pending state.
Another significant difference with Ethereum, is that blocks are produced by validators or block producers, who include transactions from their local mempool into blocks in a
first-in-first-out (FIFO) fashion. Transactions on Ethermint cannot be ordered or cherry picked out from the Tendermint node [mempool](https://docs.tendermint.com/master/tendermint-core/mempool.html#transaction-ordering).
## Pending State Queries
Ethermint will make queries which will account for any unconfirmed transactions present in a node's
transaction mempool. A pending state query made will be subjective and the query will be made on the
target node's mempool. Thus, the pending state will not be the same for the same query to two
different nodes.
### RPC Calls on Pending Transactions
- [`eth_getBalance`](./../basics/json_rpc.md#eth_getbalance)
- [`eth_getTransactionCount`](./../basics/json_rpc.md#eth-gettransactioncount)
- [`eth_getBlockTransactionCountByNumber`](./../basics/json_rpc.md#eth-getblocktransactioncountbynumber)
- [`eth_getBlockByNumber`](./../basics/json_rpc.md#eth-getblockbynumber)
- [`eth_getTransactionByHash`](./../basics/json_rpc.md#eth-gettransactionbyhash)
- [`eth_getTransactionByBlockNumberAndIndex`](./../basics/json_rpc.html#eth-gettransactionbyblockhashandindex)
- [`eth_sendTransaction`](./../basics/json_rpc.md#eth-sendtransaction)
## Next {hide}
Learn how to deploy a Solidity smart contract on Ethermint using [Truffle](./../guides/truffle.md) {hide}

View File

@ -10,6 +10,7 @@ This folder contains introduction material for Ethermint.
1. [Overview](./overview.md) 1. [Overview](./overview.md)
1. [Architecture](./architecture.md) 1. [Architecture](./architecture.md)
1. [Use Cases](./use_cases.md)
1. [Resources](./resources.md) 1. [Resources](./resources.md)
After reading the introduction material, head over to the [basics](../basics/README.md) to learn more. After reading the introduction material, head over to the [basics](../basics/README.md) to learn more.

View File

@ -4,15 +4,20 @@ order: 1
# High-level Overview # High-level Overview
Learn about Ethermint and its primary features. {synopsis}
## What is Ethermint ## What is Ethermint
Ethermint is a scalable, high-throughput Proof-of-Stake blockchain that is fully compatible and Ethermint is a scalable, high-throughput Proof-of-Stake blockchain that is fully compatible and
interoperable with Ethereum. It's built using the [Cosmos SDK](https://github.com/cosmos/cosmos-sdk/) which runs on top of [Tendermint Core](https://github.com/tendermint/tendermint) consensus engine. interoperable with Ethereum. It's built using the [Cosmos
SDK](https://github.com/cosmos/cosmos-sdk/) which runs on top of [Tendermint
Core](https://github.com/tendermint/tendermint) consensus engine.
Ethermint allows for running vanilla Ethereum as a [Cosmos](https://cosmos.network/) application-specific blockchain. This allows developers Ethermint allows for running vanilla Ethereum as a [Cosmos](https://cosmos.network/)
to have all the desired features of Ethereum, while at the same time, benefit application-specific blockchain. This allows developers to have all the desired features of
from Tendermints PoS implementation. Also, because it is built on top of the Ethereum, while at the same time, benefit from Tendermints PoS implementation. Also, because it is
Cosmos SDK, it will be able to exchange value with the rest of the Cosmos Ecosystem through the Inter Blockchain Communication Protocol (IBC). built on top of the Cosmos SDK, it will be able to exchange value with the rest of the Cosmos
Ecosystem through the Inter Blockchain Communication Protocol (IBC).
### Features ### Features
@ -20,20 +25,21 @@ Heres a glance at some of the key features of Ethermint:
* Web3 compatibility * Web3 compatibility
* High throughput via [Tendermint Core](https://github.com/tendermint/tendermint) * High throughput via [Tendermint Core](https://github.com/tendermint/tendermint)
* Horizontal scalability via [IBC](https://github.com/cosmos/ics) * Horizontal scalability via [IBC](https://cosmos.network/ibc)
* Fast transaction finality * Fast transaction finality
* [Hard Spoon](https://blog.cosmos.network/introducing-the-hard-spoon-4a9288d3f0df) * [Hard Spoon](./../basics/hard_spoon.md)
Ethermint enables these key features through: Ethermint enables these key features by:
* Implementing Tendermint Core's ABCI application interface to manage the blockchain * Implementing Tendermint Core's Application Blockchain Interface ([ABCI](https://docs.tendermint.com/master/spec/abci/)) to manage the blockchain
* Leveraging [modules](https://github.com/cosmos/cosmos-sdk/tree/master/x/) and other mechanisms implemented by the Cosmos SDK * Leveraging [modules](https://docs.cosmos.network/master/building-modules/intro.html) and other mechanisms implemented by the [Cosmos SDK](https://docs.cosmos.network/).
* Utilizing [`geth`](https://github.com/ethereum/go-ethereum) as a library to avoid code reuse and improve maintainability. * Utilizing [`geth`](https://github.com/ethereum/go-ethereum) as a library to avoid code reuse and improve maintainability.
* Exposing a fully compatible Web3 RPC layer for interacting with existing Ethereum clients and tooling (Metamask, Remix, Truffle, etc). * Exposing a fully compatible Web3 [JSON-RPC](./../basic/json_rpc.md) layer for interacting with existing Ethereum clients and tooling ([Metamask](./../guides/metamask.md), [Remix](./../guides/remix.md), [Truffle](./../guides/truffle.md), etc).
The sum of these features allows developers to leverage existing Ethereum ecosystem tooling and The sum of these features allows developers to leverage existing Ethereum ecosystem tooling and
software to seamlessly deploy smart contracts which interact with the rest of the Cosmos ecosystem! software to seamlessly deploy smart contracts which interact with the rest of the Cosmos
[ecosystem](https://cosmos.network/ecosystem)!
## Next {hide} ## Next {hide}
Learn about Ethermint's [architecture](./architectures.md) {hide} Learn about Ethermint's [architecture](./architecture.md) {hide}

View File

@ -1,5 +1,5 @@
<!-- <!--
order: 3 order: 4
--> -->
# Resources # Resources
@ -27,10 +27,12 @@ Learn about Ethermint with the list of official resources. {synopsis}
Note: most of these articles are outdated as they refer to the previous Ethermint projects (linked below). They are listed here for reference only. Note: most of these articles are outdated as they refer to the previous Ethermint projects (linked below). They are listed here for reference only.
::: :::
- [Ethermint Supports Web3 Personal API - Colin Schwarz](https://blog.cosmos.network/ethermint-supports-web3-personal-api-556adf75c24e)
- [The Road to Ethermint - Colin Schwarz](https://blog.cosmos.network/the-road-to-ethermint-836c0745f535)
- [A Beginners Guide to Ethermint - ICF](https://blog.cosmos.network/a-beginners-guide-to-ethermint-38ee15f8a6f4) - [A Beginners Guide to Ethermint - ICF](https://blog.cosmos.network/a-beginners-guide-to-ethermint-38ee15f8a6f4)
- [Using Ethermint with Truffle - Billy Rennekamp](https://blog.cosmos.network/using-ethermint-with-truffle-984e6721e30d) - [Using Ethermint with Truffle - Billy Rennekamp](https://blog.cosmos.network/using-ethermint-with-truffle-984e6721e30d)
- [Light Clients on Ethermint - ICF](https://blog.cosmos.network/light-clients-on-ethermint-9ae1f3c6c4f5) - [Light Clients on Ethermint - ICF](https://blog.cosmos.network/light-clients-on-ethermint-9ae1f3c6c4f5)
- [Cosmos Fee Token Introducing the Photon - ICF](https://blog.cosmos.network/cosmos-fee-token-introducing-the-photon-8a62b2f51aa) - [Cosmos Fee Token Introducing the Photon - ICF](https://blog.cosmos.network/cosmos-fee-token-introducing-the-photon-8a62b2f51aa)
- [Introducing the Hard Spoon - Chjango Unchained](https://blog.cosmos.network/introducing-the-hard-spoon-4a9288d3f0df) - [Introducing the Hard Spoon - Chjango Unchained](https://blog.cosmos.network/introducing-the-hard-spoon-4a9288d3f0df)
- [Ethermint and NFTs at EthDenver - Tendermint](https://blog.cosmos.network/ethermint-nfts-at-ethdenver-bf32766835b6) - [Ethermint and NFTs at EthDenver - Tendermint](https://blog.cosmos.network/ethermint-nfts-at-ethdenver-bf32766835b6)

50
docs/intro/use_cases.md Normal file
View File

@ -0,0 +1,50 @@
<!--
order: 3
-->
# Use Cases
Check out the 2 use cases for the Ethermint project. {synopsis}
## Ethermint chain
The Ethermint blockchain provides Ethereum developers to deploy their smart contracts to the
Ethermint EVM and get the benefits of a fast-finality Proof-of-Stake (PoS) chain. Developers will
also benefit from highly-reliable clients from testnets can be used to test and deploy their
contracts.
Ethermint will also offer built-in interoperability functionalities with other Cosmos and BFT chains by using [IBC](https://cosmos.network/ibc). Developers can also benefit from using a bridge network (like
[Chainbridge](https://github.com/ChainSafe/ChainBridge), or a [Peg
Zone](https://github.com/cosmos/peggy)) to enable interoperability between mainnet Ethereum and Ethermint.
## EVM module dependency
The EVM module ([x/evm](https://github.com/cosmos/ethermint/tree/development/x/evm)) packaged inside
Ethermint can be used separately as its own standalone module. This can be added as a dependency to
any Cosmos chain, which will allow for smart contract support.
Importing EVM module can also enable use cases such as Proof-of-Authority
([PoA](https://en.wikipedia.org/wiki/Proof_of_authority)) chains for enterprise and consortium
projects. Every chain on Cosmos is an [application-specific
blockchain](https://docs.cosmos.network/master/intro/why-app-specific.html) that is customized for
the business logic defined by a single application. Thus, by using a predefined validator set and
the EVM module as a dependency, enables projects with fast finality, interoperability as well as
Proof-of-Stake (PoS) consensus.
## Trade offs
Either option above will allow for fast finality, using a PoS consensus engine. Using the EVM module
as a dependency will require the importing of the EVM and the maintaining of the chain (including
validator sets, code upgrades/conformance, community engagement, incentives, etc), thus it incurs on a
higher operation cost. The benefit of importing the EVM module to your chains is that it allows for
granular control over the network and chain specific configurations/features that may not be
available in the Ethermint chain such as developing a module or importing a third-party one.
Using Ethermint chain will allow for the direct deployment of smart contracts to the Ethermint
network. Utilizing the Ethermint client will defer the chain maintenance to the Ethermint network
and allow for the participation in a more mature blockchain. The Ethermint client will also offer
(in the near future) IBC compatibility which allows for interoperability between different network.
## Next {hide}
Read the available Ethermint [resources](./resources.md) {hide}