Execution Phase

The state transition function is the core deterministic algorithm that defines how a blockchain's global state changes based on a transaction. It takes the current state and a transaction as inputs, and outputs a new, validated state.

• Inputs: Current world state, transaction data (sender, recipient, value, calldata).
• Processing: Executes the logic encoded in a smart contract's bytecode or a simple value transfer.
• Output: A new world state (updated account balances, contract storage) and a set of execution logs (events).

On Ethereum and EVM-compatible chains, execution occurs within the Ethereum Virtual Machine (EVM), a quasi-Turing-complete state machine. Smart contract code is compiled into EVM bytecode, which is executed as a sequence of low-level opcodes.

• Examples: ADD, SSTORE, CALL, JUMP.
• Gas Metering: Each opcode has a predefined gas cost. Execution halts if the transaction's provided gas is exhausted.
• Isolation: The EVM provides a sandboxed environment, preventing execution from affecting the underlying node's operating system.

Gas is the fundamental unit of computational work in the Execution Phase. It serves two primary purposes:

• Resource Pricing: Every computational step (opcode) and storage operation consumes gas, translating execution cost into a network fee.
• Execution Limitation: Gas provides a measurable limit to prevent infinite loops and denial-of-service attacks via unbounded computation.

The transaction sender specifies a gas limit and gas price. Unused gas is refunded, while exhausted gas causes the transaction to revert, with fees still paid to validators.

Execution can terminate unsuccessfully via a revert, which rolls back all state changes made during the current call frame while consuming all gas up to that point. This is distinct from an out-of-gas exception.

• Causes: Failed assertion (e.g., require() or assert()), invalid opcode, insufficient funds.
• Effect: State changes are discarded, but the transaction is still included in a block and the sender pays fees for computation performed before the revert.
• Revert Data: Smart contracts can provide a reason string or custom error data for debugging.

Execution often involves message calls where one contract invokes another. Each call creates a new execution context with its own:

• Gas Allocation: The calling contract can specify a gas limit for the sub-call.
• Stack Isolation: The callee operates with its own memory and stack, separate from the caller.
• Value Transfer: Calls can carry Ether (msg.value) to the recipient contract.

Calls can be of different types: CALL (forwards gas, can transfer value), DELEGATECALL (uses caller's storage context), STATICCALL (read-only).

Execution clients (like Geth, Erigon, Nethermind, Besu) are the software implementations that perform the Execution Phase. They:

• Validate Transactions: Check signatures, nonces, and gas limits.
• Run the EVM: Process transactions and smart contract calls in a local sandbox.
• Compute State Root: Generate the new state trie root after applying all transactions in a block.
• Sync with Consensus Layer: Post the execution payload (block body, state root) to the consensus client for block proposal and finalization.

The state machine that executes smart contract bytecode. It is a quasi-Turing complete environment where all operations are measured in gas. Every node in the Ethereum network runs the EVM to compute the same deterministic result, ensuring consensus on state changes.

• Processes opcodes like ADD, SSTORE, and CALL.
• Maintains temporary memory (volatile) and persistent storage (non-volatile).
• The foundation for other EVM-compatible chains like Polygon, Arbitrum, and Avalanche C-Chain.

The unit of computational work and the price paid for it. Gas measures the cost of EVM operations, while the fee is the product of gas used and gas price (in Gwei).

• Prevents infinite loops and spam by attaching a cost to computation.
• Users set a gas limit (max work) and gas price (bid per unit).
• Base fee is burned (EIP-1559), priority fee incentivizes validators.

The waiting area for pending, unconfirmed transactions broadcast to the network. Validators select transactions from this pool to include in the next block.

• Transactions are ordered by effective gas price (fee per gas).
• A critical component for MEV (Maximal Extractable Value) strategies.
• Nodes maintain their own view of the mempool, leading to network latency.

A Merkle Patricia Trie data structure that encodes the entire global state of the blockchain. It maps addresses to account states (balance, nonce, storage root, code hash).

• Provides a cryptographically verifiable, commitment to all account data.
• Updated after every transaction in the execution phase.
• Enables light clients to verify state proofs without storing the full chain history.

Execution artifacts generated during transaction processing. A receipt contains cumulative gas used, status (success/failure), and logs—structured data emitted by smart contracts via the LOG opcodes.

• Logs are the primary mechanism for off-chain indexing and event listening.
• Stored in a receipts trie within the block header.
• Essential for dApp front-ends and blockchain explorers to track contract events.

Native extensions to the EVM, implemented as highly optimized native code at fixed addresses (e.g., 0x01 to 0x09). They provide cryptographic primitives and complex operations that would be prohibitively expensive in standard EVM bytecode.

• Common examples: ecrecover (ECDSA signature verification), sha256, bn256 (elliptic curve operations for zk-SNARKs).
• Called via the CALL or STATICCALL opcodes.
• Charge gas based on a predefined, efficient cost schedule.

The unit of computational work required to execute operations on a blockchain like Ethereum. It is the fee mechanism that compensates validators for resources and prevents network abuse.

• Gas Price: The amount of native token (e.g., Gwei for ETH) a user pays per unit of gas, set via auction.
• Gas Limit: The maximum amount of gas a user is willing to spend on a transaction.
• Execution Cost: Complex operations (like storage writes) cost more gas than simple ones (like addition). If a transaction runs out of gas, it fails and all state changes are reverted, but the gas is still spent.

The core mathematical function that defines a blockchain. It takes the current state and a new block of transactions as input, and outputs a new, updated state.

• Input: (Current State, Transaction(s)) -> Output: New State.
• Deterministic Core: This function must be perfectly deterministic for all network participants to reach consensus.
• Execution Result: The execution phase is the practical implementation of this function, applying transaction logic (transfers, contract calls) to mutate the global state.

A low-level instruction in the Ethereum Virtual Machine's bytecode. Smart contracts are compiled down to these fundamental operations, which the EVM executes sequentially.

• Examples: ADD, MUL, SSTORE (write to storage), CALL (invoke another contract).
• Gas Cost: Each opcode has a predefined gas cost (e.g., ADD costs 3 gas, SSTORE can cost 20,000+ gas).
• Execution Granularity: The execution phase is essentially the step-by-step processing of a transaction's opcode stream, updating the EVM's internal state (stack, memory, storage) with each step.

An exceptional state in execution where all changes made within the current call frame are rolled back, but gas up to that point is consumed. It is triggered by an explicit REVERT opcode or a failed requirement (e.g., failed assert/require).

• State Rollback: Storage writes, balance changes, and other mutations are undone.
• Gas Consumption: All gas used up to the revert point is burned; remaining gas may be refunded.
• Error Handling: Allows smart contracts to safely abort execution while providing an error message, a critical feature for secure contract design.

A transaction feature that pre-declares the storage slots and addresses a transaction will access. This mitigates a gas cost increase introduced by EIP-2929 and can optimize execution.

• Gas Optimization: Accessing declared storage slots costs less gas (2100 vs 2600).
• Execution Planning: Allows the EVM to warm up these addresses before execution begins.
• Use Case: Beneficial for complex transactions interacting with many contracts, as it makes gas costs more predictable and can reduce total cost.