|1.0.0||Apr 7, 2021|
#789 in Magic Beans
42 downloads per month
Used in 3 crates
Frontier is Substrate's Ethereum compatibility layer. It allows you to run unmodified Ethereum dapps.
The goal of Ethereum compatibility layer is to be able to:
- Run a normal web3 application via the compatibility layer, using local nodes, where an extra bridge binary is acceptable.
- Be able to import state from Ethereum mainnet.
Those are suitable to be included in a runtime. Primitives are structures shared by higher-level code.
fp-consensus: Consensus layer primitives.
fp-evm: EVM primitives.
fp-rpc: RPC primitives.
fp-storage: Well-known storage information.
Those pallets serve as runtime components for projects using Frontier.
pallet-evm: EVM execution handling.
pallet-ethereum: Ethereum block handling.
pallet-dynamic-fee: Extends the fee handling logic so that it can be changed within the runtime.
Those precompiles can be used together with
pallet-evm for additional
functionalities of the EVM executor.
pallet-evm-precompile-simple: Four basic precompiles in Ethereum EVMs.
pallet-evm-precompile-blake2: BLAKE2 precompile.
pallet-evm-precompile-bn128: BN128 precompile.
pallet-evm-precompile-ed25519: ED25519 precompile.
pallet-evm-precompile-modexp: MODEXP precompile.
pallet-evm-precompile-sha3fips: Standard SHA3 precompile.
pallet-evm-precompile-dispatch: Enable interoperability between EVM contracts and other Substrate runtime components.
Those are libraries that should be used on client-side to enable RPC, block hash mapping, and other features.
fc-consensus: Consensus block import.
fc-db: Frontier-specific database backend.
fc-mapping-sync: Block hash mapping syncing logic.
fc-rpc-core: Core RPC logic.
fc-rpc: RPC implementation.
All changes (except new releases) are handled through pull requests.
Frontier follows Semantic Versioning. An unreleased crate
in the repository will have the
-dev suffix in the end, and we do rolling
When you make a pull request against this repository, please also update the
affected crates' versions, using the following rules. Note that the rules should
be applied recursively -- if a change modifies any upper crate's dependency
(even just the
Cargo.toml file), then the upper crate will also need to apply
Additionally, if your change is notable, then you should also modify the
CHANGELOG.md file, in the "Unreleased" section.
If the affected crate already has
- If your change is a patch, then you do not have to update any versions.
- If your change introduces a new feature, please check if the local version already had its minor version bumped, if not, bump it.
- If your change modifies the current interface, please check if the local version already had its major version bumped, if not, bump it.
If the affected crate does not yet have
- If your change is a patch, then bump the patch version, and add
- If your change introduces a new feature, then bump the minor version, and add
- If your change modifies the current interface, then bump the major version,
If your pull request introduces a new crate, please set its version to