Differences between Arbitrum and Ethereum: Overview
Arbitrum's design is to be as compatible and consistent with Ethereum as possible, from its high-level RPCs to its low-level bytecode and everything in between. Decentralized app developers with experience building on Ethereum will likely find that little to no new specific knowledge is required to build on Arbitrum.
This article outlines the key differences, benefits, and potential pitfalls that devs should be aware of when working with Arbitrum. This first page serves as an outline, with links to the relevant pages.
STF in Ethereum
In Ethereum, the STF receives transactions as inputs, processes them via the EVM, and produces the final state as output.
The Ethereum state is a vast data structure represented by a modified Merkle Patricia Trie. This structure holds all accounts, linking them via hashes and reducing the entire state to a single root hash stored on the blockchain.
The Ethereum Virtual Machine (EVM) operates similarly to a mathematical function: given an input, it produces a deterministic output. Ethereum's STF encapsulates this behavior:
Here, S represents the current state, T denotes the transaction, and S' is the new state resulting from the execution of T.
The EVM operates as a stack machine with a maximum depth of 1024 items. Each item is a 256-bit word, chosen for compatibility with 256-bit cryptography (e.g., Keccak-256 hashes and secp256k1 signatures).
During execution, the EVM uses transient memory (a word-addresses byte array) that only persists for the duration of a transaction. In contrast, each contract maintains a persistent Merkle Patricia storage trie–a word-addressable word array–that forms part of the global state.
smart contract bytecode compiles into a series of EVM opcodes
that perform standard stack operations (such as XOR, AND, ADD, SUB) and blockchain-specific operations
(such as ADDRESS, BALANCE, BLOCKHASH).
Geth (go-Ethereum) is one of the primary client implementations of Ethereum, serving as the practical embodiment of both the STF and the EVM execution engine. It processes transactions by executing the smart contract's bytecode and updating the global state, ensuring that every state change is deterministic and secure.
In essence, Geth converts transaction inputs into precise computational steps within the EVM, maintaining the intricate data structures that underpin Ethereum's blockchain. Its robust design not only powers the core operations of Ethereum but also provides the foundation for advanced modificaitons in platforms like the Arbitrum Nitro stack.
STF on Arbitrum
The Arbitrum Nitro stack implements a modified version of Ethereum's STF. While it retains the core principles of Ethereum, several Arbitrum-specific features and processes distinguish it from Ethereum's implementation. Key differences include:
Block numbers and time
Time in Arbitrum chains is tricky. The timing assumptions one is used to making about Ethereum blocks don't exactly carry over into the timing of Arbitrum blocks. See Block numbers and time for details about how block numbers and time work in Arbitrum.
RPC methods
Although the majority of RPC methods follow the same behavior as Ethereum, some methods may produce a different result or add additional information when used on an Arbitrum chain. You can find more information about these differences in RPC methods.
Solidity support
You can deploy Solidity contracts onto Arbitrum just like you do on Ethereum. There are only a few minor functional differences. For more information, refer to Solidity support.
Gas accounting
The fees for executing an Arbitrum transaction function similarly to gas fees on Ethereum. However, Arbitrum transactions must also pay a fee component to cover the cost of posting their calldata to the parent chain (for example, calldata on Arbitrum One, a child chain, is posted to Ethereum, a parent chain). Find more information about the two components of gas fees in Gas and fees and parent chain pricing.
Base fee mechanism
Arbitrum chains support arbitrary message passing from a parent chain (e.g., Ethereum) to a child chain (e.g., Arbitrum One). These messages are commonly referred to as "parent chain to child chain messages." Developers using this functionality should familiarize themselves with how messaging works. For more information, refer to Parent chain to child chain messaging.
Similarly, Arbitrum chains can also send messages to the parent chain—more information about this is available in Child Chain to Parent Chain Messaging and the Outbox.
Arbitrum chains support arbitrary message passing from a parent chain (for example, a parent chain like Ethereum) to a child chain (for example, a child chain like Arbitrum One or Arbitrum Nova). These are commonly known as "parent chain to child chain messages". Developers using this functionality should familiarize themselves with how they work. Find more information about it in Parent chain to child chain messaging.
Similarly, Arbitrum chains can also send messages to the parent chain. Find more information about them in Child chain to parent chain messaging and the outbox.
Precompiles
Besides supporting all precompiles available in Ethereum, Arbitrum provides child chain-specific precompiles with methods that smart contracts can call in the same way as Solidity functions. You can find a full reference to them on the Precompiles page.
NodeInterface
The Arbitrum Nitro software includes a special NodeInterface contract, available at address 0xc8, that is only accessible via RPCs (deployed offchain, making it inaccessible to smart contracts). Find more information about this interface in NodeInterface.