Ethereum and EVM Architecture

Introduction

Ethereum is a programmable blockchain: it records value transfers, but it also maintains a shared computational state that can be changed by transactions executing smart-contract code. The Ethereum Virtual Machine (EVM) is the deterministic execution environment responsible for processing that code. Understanding Ethereum architecture is therefore essential before writing, testing, auditing, or deploying Solidity contracts.

This chapter examines the relationship between accounts, transactions, blocks, gas, bytecode, opcodes, state transitions, logs, calls, execution contexts, and Layer 1 and Layer 2 environments. The central architectural idea is that every valid transaction causes a deterministic state transition. Nodes independently execute the same transaction and should obtain the same result, while consensus determines which ordered set of transitions becomes canonical.

Learning Objectives

By the end of this chapter, you should be able to:

1. Distinguish externally owned accounts from contract accounts.
2. Explain the structure and lifecycle of an Ethereum transaction.
3. Describe how blocks order transactions and support consensus.
4. Calculate basic gas costs and explain EIP-1559 fee components.
5. Relate Solidity source code to compiler output, bytecode, and EVM opcodes.
6. Analyse state transitions, execution contexts, calls, reverts, and logs.
7. Distinguish Layer 1 execution from common Layer 2 execution models.
8. Evaluate practical, security, governance, and operational implications of EVM architecture.

1. Ethereum as a State-Transition System

Ethereum can be modelled as a replicated state machine. Let S_t denote the global state after block t, and let B_{t+1} be the next valid block. Applying the block transition function produces the next state:

Here, Υ is the protocol-defined state-transition function. S_t includes accounts, balances, contract storage, contract code, and protocol-related data. B_{t+1} contains an ordered list of transactions and block-level information. The equation is conceptual rather than a complete implementation specification: Ethereum clients also validate consensus rules, transaction signatures, gas limits, and block structure.

For an individual transaction T, execution can be represented as:

S is the pre-transaction state, S' is the post-transaction state, Γ is the EVM transaction execution procedure, and R is the execution result, including status, gas usage, logs, and returned data. A reverted call may consume gas while discarding state changes made during the reverted execution frame. Some effects, such as already-paid transaction fees, are handled by transaction-processing rules rather than by ordinary contract storage semantics.

The state-transition model provides three important properties:

• Determinism: identical valid inputs produce identical results.
• Verifiability: independent nodes can recompute results.
• Composability: one contract can invoke another contract within the same transaction.

Ethereum is not simply a database. It is a database plus a deterministic execution engine plus a consensus protocol that orders state changes.

2. Accounts and Global State

An Ethereum account is an address associated with protocol-defined account information. The two principal account categories are externally owned accounts and contract accounts.

An EOA is controlled by a private key. A valid signature demonstrates authorization to spend the account’s assets and submit a transaction. The private key itself is never placed on-chain. A contract account has no private key in the ordinary sense. Its behaviour is determined by bytecode, storage, and the message or transaction that invokes it.

At an abstract level, an account contains a nonce, balance, storage root, and code hash. The exact serialization and treatment of account fields are implementation details, but the conceptual roles are stable:

• Nonce: prevents replay and distinguishes sequential account actions. For an EOA, it generally counts transactions sent; for a contract, it is relevant to contract creation.
• Balance: the amount of the native asset denominated in wei.
• Storage root: commitment to the contract’s persistent key-value storage, or an empty storage structure for an EOA.
• Code hash: commitment to deployed runtime code, with no executable code for a normal EOA.

One ether equals 10^18 wei. Contract arithmetic commonly uses integer units because the EVM does not provide floating-point arithmetic. Solidity developers must therefore choose explicit scaling conventions for prices, tokens, interest rates, and other fractional concepts.

Addresses and contract creation

A contract may be created by a transaction or by another contract using a creation operation. Traditional contract addresses are derived from the creator address and creator nonce; deterministic creation mechanisms such as CREATE2 use a formula involving the creator, a salt, and the creation-code hash. Developers should not treat an address as proof of identity: address ownership, upgrade authority, and code provenance require separate verification.

Contract creation code is not the same as runtime code. Creation bytecode runs once, usually storing or returning the runtime bytecode. The returned runtime bytecode is what remains associated with the deployed contract and executes on later calls.

3. Transactions

A transaction is a signed instruction submitted to the network. It may transfer native currency, call a contract, or create a contract. A transaction commonly specifies:

• sender, recovered from the signature;
• nonce;
• destination, except for contract creation;
• value, denominated in wei;
• input data, also called calldata;
• gas limit;
• fee parameters;
• chain identifier and signature fields.

Modern Ethereum transactions use typed envelopes. The exact fields vary by transaction type, but the purpose is to support protocol evolution without interpreting all transactions as one historical format. EIP-1559-style transactions specify a maximum total fee per gas and a maximum priority fee per gas. The effective price paid by the sender is bounded by these values and the block’s base fee.

For a transaction with gas used G, base fee per gas B, priority fee per gas P, and sender’s maximum fee per gas F, the effective gas price can be expressed as:

The total execution fee is:

where G is measured in gas units and all fee variables are denominated in wei per gas. The base-fee component is protocol-determined and burned under the current fee mechanism; the priority component is paid to the validator, subject to protocol rules and the transaction’s effective price. This formula excludes the transaction’s value transfer, which is not an execution fee.

A transaction’s gas limit is the maximum gas the sender authorizes for execution. It is not necessarily the amount consumed. Unused gas is generally not charged as execution, although the sender must have sufficient funds to satisfy the protocol’s upfront affordability checks.

Transaction lifecycle

1. A wallet constructs a transaction.
2. The sender signs it with its private key.
3. A node checks basic validity and may place it in a transaction pool.
4. A validator selects transactions and places them in a proposed block.
5. Other nodes validate the block, signatures, ordering, gas constraints, and execution result.
6. Consensus finality and chain rules determine its canonical status.

A transaction can be included but fail during execution. Such a transaction normally has a failed status, consumes gas according to the rules, and does not retain ordinary state changes made in the reverted execution frame. Failure is therefore not the same as non-inclusion.

4. Blocks and Consensus Context

A block groups transactions and provides ordering and commitment data. A block header includes fields such as the parent reference, state commitment, transaction commitment, receipt commitment, gas limit, gas used, timestamp, base fee, and proposer-related information. Header details change as Ethereum evolves, so developers should consult the relevant network specification when implementing low-level tooling.

The state root commits to the resulting global state. The transaction root commits to the block’s transactions, and the receipt root commits to execution receipts. These commitments allow compact verification and support light-client designs.

Ethereum currently uses proof-of-stake consensus. Validators participate in proposing and attesting to blocks, while the consensus protocol provides fork choice and finality mechanisms. Execution and consensus clients are separate components that communicate through standard interfaces. The execution layer processes transactions and maintains EVM state; the consensus layer coordinates validator duties and block agreement.

A block is not merely a container. Its ordering creates the sequence in which state changes occur. This creates practical consequences:

• Two transactions interacting with the same contract may have different results depending on order.
• A contract cannot assume that pending-transaction order is private or stable.
• Block timestamps and numbers are protocol-provided context, not trusted real-world clocks.
• Applications requiring randomness must use appropriate randomness infrastructure rather than treating block variables as unpredictable secrets.

5. Gas and Resource Accounting

Gas is a protocol accounting unit for computational and state-related work. It prevents unbounded execution and makes resource consumption economically measurable. Each EVM instruction has a gas cost, although costs can depend on operands and state conditions. Storage changes, memory expansion, calldata, cryptographic operations, and external calls can all affect consumption.

For a simple transaction, total gas used is the sum of applicable intrinsic and execution costs:

This is a conceptual decomposition. The exact intrinsic cost and dynamic schedules are protocol-defined and may vary by transaction type and data characteristics. Developers should not hard-code historical gas schedules without checking the target network and current Ethereum Improvement Proposals.

If a transaction has a gas limit L and consumes G gas, then the unused amount is:

provided that G ≤ L. If execution requires more gas than the available limit, the frame runs out of gas and reverts its ordinary state changes. Gas already consumed is not generally refunded as though execution never occurred.

Gas is not equivalent to time. Two operations with similar gas costs may have different hardware execution times, and gas schedules are protocol decisions intended to protect network resources and maintain economic incentives. Gas also does not guarantee privacy: calldata, logs, balances, and state changes are publicly observable on a public chain.

Storage, memory, stack, and calldata

The EVM uses several data areas:

• Stack: a word-oriented operand stack, with a maximum depth of 1024 items. EVM words are 256 bits.
• Memory: temporary, byte-addressable data available during a call; it is not persistent after the call frame ends.
• Storage: persistent contract key-value data, expensive relative to transient computation.
• Calldata: read-only input supplied to a call, typically containing a function selector and ABI-encoded arguments.
• Return data: output produced by a call and made available to the caller.

Memory expansion has a dynamic cost, so allocating or copying large regions can be expensive. Storage reads and writes interact with protocol-defined warm and cold access rules. Solidity’s apparent high-level simplicity therefore hides important resource decisions.

6. From Solidity to Opcodes and Bytecode

Solidity is compiled into EVM bytecode. The compiler performs parsing, type checking, optimization, ABI generation, and code generation. The resulting deployment artifact commonly contains:

• creation bytecode;
• runtime bytecode;
• ABI metadata;
• compiler version and settings;
• source-map information for debugging.

The EVM executes bytecode as a sequence of opcodes. Examples include:

A 256-bit EVM word can represent an unsigned integer from 0 through 2^256 − 1. Solidity 0.8 and later generally inserts checked arithmetic for ordinary integer operations, reverting on overflow or underflow unless an unchecked block or another mechanism changes that behaviour. At the EVM level, arithmetic is word-based; compiler-generated checks provide the higher-level safety semantics.

The first bytes of typical contract runtime code implement dispatch logic. The dispatcher reads calldata, extracts a four-byte function selector, and jumps to the corresponding function body. The selector is derived from the first four bytes of the hash of the canonical function signature. Because selectors are truncated, collisions are possible; robust interfaces and compiler-generated dispatchers must handle this reality.

7. Execution Contexts and Calls

Every EVM execution occurs in a context containing values such as caller, immediate caller, call value, gas, calldata, return data, address, and block environment. Solidity exposes some of these through global variables, but their meanings must be distinguished carefully.

• msg.sender is the immediate caller of the current call frame.
• tx.origin is the original EOA that initiated the transaction. It should generally not be used for authorization because intermediary contracts can cause confusing and dangerous behaviour.
• msg.value is the native currency sent with the current message call.
• address(this) is the address associated with the current execution context.
• block.number, block.timestamp, and related values describe block context and should not be treated as arbitrary trusted inputs.

A normal external call creates a new frame. The callee has its own code and storage context, and msg.sender in the callee is the caller’s address. DELEGATECALL is different: it executes target code while preserving the caller’s storage address, caller, and value context. This enables proxy patterns but creates severe storage-layout and upgrade-authority risks.

STATICCALL restricts the call to read-only execution under EVM rules. It is useful for view-like operations, but a Solidity view declaration is also a compiler-level promise and should not be confused with universal off-chain execution or guaranteed zero cost when invoked through a transaction.

Calls can return success or failure data. Solidity’s try/catch and low-level call interfaces can inspect this outcome, but callers must deliberately check the success flag. Ignoring a failed low-level call can create silent accounting or authorization errors.

Reentrancy and interaction order

Because a call can transfer control to another contract, the callee may call back into the caller before the original function completes. This is reentrancy. A common defensive pattern is checks-effects-interactions: validate conditions, update internal state, and only then perform external interactions. Reentrancy guards, pull-payment designs, and carefully specified invariants provide additional protection. The pattern is not a substitute for analysis because reentrancy may occur through tokens, callbacks, or unexpected call paths.

8. State Changes, Reverts, Receipts, and Logs

A successful transaction can modify balances, nonces, contract storage, and other state. A revert rolls back state changes made in the relevant execution frame and returns data that may encode an error selector and arguments. Revert data is not automatically a human-readable message; tools decode it using ABI knowledge.

Logs are transaction-level data records emitted with LOG0 through LOG4. A Solidity event normally contains:

• an emitting contract address;
• up to four topics, including the event signature topic unless configured otherwise;
• data containing non-indexed event arguments.

Indexed event arguments become topics and are useful for filtering. Dynamic indexed values are represented by a hash rather than their complete original value, so indexing improves searchability but may reduce direct readability. Logs are not contract storage: contracts cannot generally read historical logs during EVM execution. They are intended for off-chain consumers such as wallets, indexers, analytics systems, and monitoring services.

Receipts record execution-related results such as status, cumulative gas information, logs, and a bloom filter. A receipt is not the same as state. An event appearing in a receipt is evidence that the corresponding execution emitted it, but applications should still validate the emitting address, event signature, chain, and relevant fields.

9. Contract Interfaces and ABI

The Application Binary Interface (ABI) specifies how external data is encoded and decoded. A function call generally begins with a four-byte selector followed by ABI-encoded arguments. Return values and custom errors use related encoding rules. ABI compatibility therefore depends on function signatures, data types, tuple layouts, array offsets, and contract expectations.

The ABI is not the contract’s security policy. A malicious contract can emit an event with a familiar name or implement a function with unexpected semantics. Applications should verify addresses, code, chain identifiers, permissions, and assumptions rather than trusting names alone.

10. Layer 1 and Layer 2 Environments

Ethereum Layer 1 (L1) is the base network whose consensus and execution provide final settlement. Layer 2 (L2) systems execute transactions away from the main execution path and publish data, commitments, proofs, or messages to L1. Their exact trust and security models differ.

“EVM-compatible” does not mean identical. An L2 may differ in gas pricing, precompiles, supported opcodes, block timing, address derivation, transaction format, system contracts, sequencing, and data publication. Some L2s have a centralized or limited sequencer, creating operational and censorship considerations even when settlement ultimately relies on Ethereum.

Cross-domain messaging introduces asynchronous execution. A message sent from L2 to L1 may not be available immediately, and withdrawal processes may involve challenge periods or proof-generation delays. Contracts should not assume that an L1 and L2 transaction share one atomic execution context. Chain identifiers, bridge contracts, replay protection, and message authentication must be explicitly checked.

11. Worked Example: Fee and Execution Analysis

Assume a transaction consumes G = 80,000 gas. The block base fee is B = 30 gwei, the sender specifies a maximum priority fee P = 2 gwei, and the maximum fee F = 50 gwei. Since:

the execution fee is:

Because 1 gwei = 10^9 wei:

The transaction’s native currency transfer, if any, must be added separately. It is not part of the gas fee. If the transaction had a gas limit of 100,000, then 20,000 gas was unused, assuming execution completed successfully:

The example assumes the transaction is valid, the stated effective-price rule applies, and no additional protocol-specific adjustment changes the displayed fee calculation.

12. Applied Case: A Layer-2 Payment Contract

Background

This illustrative case concerns a business that deploys a payment contract on an EVM-compatible Layer 2. The contract records invoice payments and emits events for an accounting system.

Problem

The business initially treats L2 events as immediately equivalent to L1 settlement. It also authorizes refunds using tx.origin, accepts arbitrary bridge messages, and assumes that the L2 gas price and block timestamp have the same operational meaning as L1 values.

Analysis

The architecture reveals four risks. First, L2 execution and L1 settlement have different timing and finality assumptions. Second, tx.origin can be exploited through an intermediary contract. Third, cross-domain messages require authenticated origin and destination checks. Fourth, event indexing must distinguish the correct chain, contract address, invoice identifier, and finality status.

Approach

The redesigned system:

1. Uses role-based authorization based on msg.sender and a controlled access contract.
2. Validates the authenticated bridge messenger and expected remote contract.
3. Stores invoice status changes and emits events containing invoice identifiers, payer, amount, and status.
4. Records chain ID, transaction hash, block number, and a finality classification in the off-chain accounting system.
5. Uses explicit integer units and rejects unexpected token decimals.
6. Tests on the target L2 for gas, precompile, opcode, timestamp, and address-behaviour differences.
7. Treats withdrawal and cross-domain messages as asynchronous workflows rather than atomic function calls.

Outcome

The system becomes more robust because contract authorization, message authentication, event processing, and settlement assumptions are separated. The accounting service can show a payment as observed, L2-confirmed, or L1-settled rather than incorrectly presenting all states as identical.

Learning points

Architecture affects application security. A contract that is safe on a local EVM test chain may require changes on an L2 because execution cost, sequencing, messaging, and finality differ. Off-chain software is part of the system’s trust boundary, especially when it consumes logs or reports settlement.

13. Limitations, Governance, and Best Practice

Ethereum’s architecture has limitations. Public state creates privacy challenges. Gas costs are variable. Block production creates ordering and transaction-inclusion risks. Smart contracts are difficult to modify after deployment, while upgradeable contracts introduce governance and administrative risk. Compiler bugs, protocol changes, bridge failures, oracle manipulation, and dependency vulnerabilities can affect otherwise correct application logic.

Recommended professional practices include:

• Pin compiler versions and document compiler settings.
• Inspect both creation and runtime bytecode during deployment review.
• Use static analysis, unit tests, fuzzing, invariant testing, and independent audits.
• Specify authorization, pause, upgrade, and emergency-recovery policies.
• Check return values and handle revert data deliberately.
• Avoid tx.origin for authorization.
• Treat external calls and callbacks as adversarial control transfers.
• Bound loops and estimate worst-case gas consumption.
• Validate chain ID, contract address, bridge origin, token decimals, and message domains.
• Do not rely on timestamps or block hashes as secure general-purpose randomness.
• Monitor events but verify emitting addresses and finality assumptions.
• Maintain incident-response procedures and communicate administrative privileges transparently.

Governance is not only a social issue. Validator rules, fee markets, compiler releases, L2 upgrades, bridge administration, and contract ownership all shape how code behaves in practice. A technically correct contract can still be unacceptable if its governance permits unilateral confiscation, opaque upgrades, or uncontrolled dependence on an external service.

Contemporary Developments

Ethereum development increasingly separates execution, consensus, data availability, and settlement concerns. Rollups, data-publication improvements, account-abstraction mechanisms, typed transactions, and cryptographic precompiles continue to expand the design space. These developments do not remove the need to understand the EVM; they make execution-context analysis more important because applications may run across multiple environments with different fee, data, and finality properties.

AI tools can assist with ABI exploration, test generation, bytecode comparison, and anomaly detection. They cannot establish contract correctness by themselves. Generated code and generated tests require human review, formal specifications where appropriate, and independent security validation. In smart-contract engineering, deterministic execution does not imply that the development process is automatically reliable.

Chapter Summary

Ethereum is a replicated state-transition system. Accounts hold balances and protocol data; EOAs authorize transactions with signatures, while contracts execute deployed bytecode. Transactions specify calls, values, calldata, nonces, gas limits, and fee parameters. Blocks order transactions and commit to transactions, receipts, and resulting state, while proof-of-stake consensus coordinates agreement and finality.

The EVM executes 256-bit stack-based bytecode using gas as a resource-accounting mechanism. Solidity compiles into creation and runtime bytecode, and opcodes operate on stack, memory, storage, calldata, and return data. Calls create execution frames, while CALL, DELEGATECALL, and STATICCALL produce materially different contexts. Reverts discard ordinary state changes in the relevant frame, whereas logs provide off-chain event data and are not persistent contract storage.

Layer 2 systems extend Ethereum’s execution environment but may differ in gas, sequencing, finality, messaging, and supported features. Professional developers must therefore analyse not only Solidity source code but also bytecode, transaction economics, execution contexts, governance, bridge assumptions, and the target deployment environment.

Key Terms

Account: An address-associated protocol object containing fields such as balance and nonce.

Externally owned account (EOA): An account controlled by a private-key signature.

Contract account: An account whose behaviour is determined by deployed bytecode.

Nonce: A protocol counter used to order actions and prevent replay.

Transaction: A signed instruction requesting a state-changing operation.

Block: An ordered collection of transactions and associated consensus and commitment data.

State transition: The deterministic transformation from one valid global state to another.

EVM: Ethereum Virtual Machine, the deterministic execution environment for EVM bytecode.

Opcode: A low-level EVM instruction.

Bytecode: Machine-readable code executed by the EVM.

Gas: A protocol unit measuring computational and state-related resource consumption.

Base fee: The protocol-determined fee component in the EIP-1559 fee mechanism.

Calldata: Read-only input supplied to a contract call.

Storage: Persistent contract key-value data.

Execution context: Values defining a call frame, including caller, value, address, and input data.

Revert: Abortion of an execution frame with rollback of its ordinary state changes.

Log: Event data emitted during execution for off-chain consumption.

ABI: Application Binary Interface used to encode calls, arguments, returns, and errors.

Layer 1: The base Ethereum network providing settlement and consensus.

Layer 2: A system that executes transactions away from the primary L1 execution path while relying on a settlement or security relationship with L1.

Review Questions

Short Answer Questions

1. What is the difference between an EOA and a contract account?
2. Why is gas required in the EVM?
3. What is the purpose of a transaction nonce?
4. How do logs differ from contract storage?
5. What is the principal difference between CALL and DELEGATECALL?

Long Answer Questions

1. Explain Ethereum’s state-transition model and relate it to blocks, transactions, and deterministic execution.
2. Describe the lifecycle of an EIP-1559-style transaction from signing to block validation.
3. Explain how Solidity source code becomes creation bytecode, runtime bytecode, and executed opcodes.
4. Analyse the roles of stack, memory, storage, calldata, and return data in the EVM.
5. Compare Ethereum Layer 1 with optimistic and validity rollups, including differences in execution and finality.

Analytical / Application Questions

1. A contract uses tx.origin to authorize withdrawals and calls an external token contract before updating its balance. Identify the threats and propose a safer design.
2. An application indexes events from an L2 and immediately reports every event as final L1 settlement. Design a revised data and finality model.
3. A transaction has a gas limit of 150,000 and consumes 112,000 gas. Its base fee is 24 gwei, priority fee is 3 gwei, and maximum fee is 40 gwei. Calculate the effective gas price and execution fee, stating your assumptions.

Multiple Choice Questions with Answers

Question 1

Which account type can independently initiate a signed Ethereum transaction?

A. Externally owned account

B. Contract account

C. Storage account

D. Log account

Correct Answer: A. Externally owned account

Question 2

What does the Ethereum state root primarily commit to?

A. The validator’s private key

B. The resulting global state

C. Only the block timestamp

D. Only pending transactions

Correct Answer: B. The resulting global state

Question 3

A transaction uses 80,000 gas, with a base fee of 30 gwei and priority fee of 2 gwei, while its maximum fee is 50 gwei. What is its effective gas price?

A. 2 gwei

B. 30 gwei

C. 32 gwei

D. 50 gwei

Correct Answer: C. 32 gwei

Question 4

Which EVM area persists contract data across transactions?

A. Memory

B. Stack

C. Calldata

D. Storage

Correct Answer: D. Storage

Question 5

What is a principal security concern with using tx.origin for authorization?

A. It disables bytecode deployment

B. An intermediary contract can cause misleading authorization behaviour

C. It makes all calls free

D. It changes the block gas limit

Correct Answer: B. An intermediary contract can cause misleading authorization behaviour

Question 6

What is the main purpose of an event log?

A. To provide persistent storage readable by contracts

B. To replace transaction signatures

C. To provide execution data for off-chain consumers

D. To increase the EVM stack depth

Correct Answer: C. To provide execution data for off-chain consumers

Question 7

What distinguishes DELEGATECALL from a normal CALL?

A. It executes target code while preserving the caller’s storage context

B. It can only be used by EOAs

C. It cannot return data

D. It always creates a new contract

Correct Answer: A. It executes target code while preserving the caller’s storage context

Question 8

If a transaction has a gas limit of 150,000 and uses 112,000 gas, how much gas is unused?

A. 38,000 gas

B. 42,000 gas

C. 112,000 gas

D. 262,000 gas

Correct Answer: A. 38,000 gas

Question 9

Which statement about Layer 2 environments is most accurate?

A. Every L2 has exactly the same gas and finality behaviour as L1

B. L2s cannot execute smart contracts

C. L2s may differ in sequencing, gas pricing, messaging, and finality

D. L2 transactions never interact with L1

Correct Answer: C. L2s may differ in sequencing, gas pricing, messaging, and finality

Question 10

What normally happens to ordinary state changes in an execution frame that runs out of gas?

A. They are permanently retained

B. They are rolled back, while consumed gas is generally not restored

C. They are moved automatically to an L2

D. They become event logs

Correct Answer: B. They are rolled back, while consumed gas is generally not restored