Skip to content

Ethereum Compatibility

Differences Between Moonbeam and Ethereum

While Moonbeam strives to be compatible with Ethereum’s Web3 API and EVM, there are a number of important Moonbeam differences.

First, Moonbeam uses a Proof of Stake-based consensus mechanism, which means that Proof of Work concepts, such as difficulty, uncles, hashrate, etc., generally don’t have meaning within Moonbeam. For APIs that return values related to Ethereum’s Proof of Work, we return default values. Existing Ethereum contracts that rely on Proof of Work internals (e.g., mining pool contracts) will almost certainly not work as expected on Moonbeam.

Another significant difference between Moonbeam and Ethereum is that Moonbeam includes an extensive set of on-chain governance features based on Substrate functionality. These onchain governance modules include functionality to power upgrades to the blockchain itself based on token weighted voting.

What Stays the Same

If you're moving portions of your existing workloads and state off of Ethereum Layer 1 to Moonbeam, you can expect minimal required changes (aside from the exceptions noted above). Your applications, contracts, and tools will largely remain unchanged.

Moonbeam supports:

  • Solidity-Based Smart Contracts
  • Ecosystem Tools (e.g., block explorers, front-end development libraries, wallets)
  • Development Tools (e.g., Hardhat, Remix, MetaMask)
  • Ethereum Tokens via Bridges (e.g., token movement, state visibility, message passing)

Frontier

Frontier is an Ethereum compatibility layer for Substrate. The goal of Frontier is to allow standard Ethereum DApps to run without modification on Substrate-based chains. Frontier makes this possible by offering some Substrate pallets that can be plugged into a Substrate runtime. The following pallets can be used independently, as needed, or collectively depending on the chain's desired functionality:

  • EVM pallet - handles EVM execution
  • Ethereum pallet - is responsible for storing block data and provides RPC compatibility
  • Base fee pallet - adds support for EIP-1559 transactions and handles base fee calculations
  • Dynamic fee pallet - calculates the dynamic minimum gas price

Moonbeam uses the EVM and Ethereum pallets to achieve full Ethereum compatibility. Moonbeam does not use the base fee or dynamic fee pallets. Moonbeam has its own dynamic fee mechanism for base fee calculations, which, as of RT2300, has been rolled out to all Moonbeam-based networks.

EVM Pallet

The EVM pallet implements a sandboxed virtual stack machine and uses the SputnikVM as the underlying EVM engine.

The EVM executes Ethereum smart contract bytecode, of which is typically written in a language like Solidity, and then compiles it to EVM bytecode. The goal of the EVM pallet is to emulate the functionality of executing smart contracts on Ethereum within the Substrate runtime. As such, it allows existing EVM code to be executed in Substrate-based blockchains.

Inside of the EVM are standard H160 Ethereum-style accounts, and they have associated data such as the balance and nonce. All of the accounts in the EVM are backed by a Substrate account type, which is configurable. Moonbeam has configured the Substrate account type to be a non-standard H160 account to be fully compatibile with Ethereum. As such, you only need a single account to interact with the Substrate runtime and the EVM. For more information on Moonbeam's account system, please refer to the Unified Accounts page.

With a unified accounts system, a mapped Substrate account can call the EVM pallet to deposit or withdraw balance from the Substrate-base currency into a different balance managed and used by the EVM pallet. Once a balance exists, smart contracts can be created and interacted with.

The EVM pallet can also be configured so that no dispatchable calls can cause EVM execution with the exception being from other pallets in the runtime. Moonbeam is configured this way with pallet Ethereum having sole responsibility of EVM execution. Using pallet Ethereum enables EVM interactions through the Ethereum API.

If a blockchain doesn't need Ethereum emulation and only needs EVM execution, Substrate uses its account model fully and signs transactions on behalf of EVM accounts. However, in this model Ethereum RPCs are not available, and DApps must write their frontend using the Substrate API.

The EVM pallet should produce nearly identical execution results compared to Ethereum, such as gas cost and balance changes. However, there are some differences. Please refer to the EVM module vs Ethereum network section of the Frontier EVM Pallet documentation for more information.

There are also some precompiles that can be used alongside the EVM pallet that extend the functionality of the EVM. Moonbeam uses the following EVM precompiles:

You can find an overview of most of these precompiles on the Ethereum MainNet Precompiled Contracts page.

Ethereum Pallet

The Ethereum pallet is responsible for handling blocks and transaction receipts and statuses. It enables sending and receiving Ethereum-formatted data to and from Moonbeam by storing an Ethereum-style block and it's associated transaction hashes in the Substrate runtime.

When a user submits a raw Ethereum transaction, it gets converted into a Substrate transaction through the pallet Ethereum's transact extrinsic. Using the Ethereum pallet as the sole executor of the EVM pallet, forces all of the data to be stored and transacted with in an Ethereum-compatible way. This enables block explorers such as Moonscan, which is built by Etherscan, to be able to index block data.

Along with support for Ethereum-style data, the Ethereum pallet combined with the RPC module provides RPC support. This enables usage of basic Ethereum JSON-RPC methods which ultimately allows existing Ethereum DApps to be deployed to Moonbeam with minimal changes.

Last update: January 31, 2024
| Created: July 2, 2020