How Ethereum Works

Ethereum is more than a network for sending ETH. It is a programmable Layer 1 blockchain where state, transactions, consensus, gas, smart contracts, token standards, and wallet design all work together to maintain a shared global system.

This guide explains how Ethereum works under the hood and how other Layer 1 networks approach similar design problems.

The focus is how it tracks and updates state, how transactions flow through the network, how computation is priced through gas, how smart contracts and token standards make Ethereum programmable, and how other Layer 1 blockchains approach the same problems in different ways.

What you’ll learn

Ethereum & Layer 1s 201 assumes readers already understand blockchain basics, wallets, private keys, ETH, and the general idea of smart contracts. It focuses on the mechanics that sit beneath the user experience.

• how Ethereum’s account-based state model differs from Bitcoin’s UTXO model;
• how transactions are created, signed, propagated, validated, included, and finalized;
• how proof-of-stake finality works through slots, epochs, checkpoints, and attestations;
• how gas, EIP-1559, base fees, and priority fees shape transaction costs;
• how smart contracts are deployed and executed on Ethereum;
• how token standards such as ERC-20, ERC-721, and ERC-1155 make applications interoperable;
• how account abstraction and ERC-4337 improve wallet flows;
• how Ethereum compares with alternative Layer 1 blockchains.

Learning outcomes

By the end of this course, learners should be able to:

• explain how Ethereum’s core systems — state, transactions, consensus, and gas — work together to maintain the network;
• trace how a transaction moves from creation to finalization;
• describe how smart contracts and token standards extend Ethereum’s base layer into a programmable economy;
• compare Ethereum’s design choices with other Layer 1 blockchains using performance, security, and decentralization trade-offs.

Course lesson summaries

The lesson summaries below are a short overview of the full course content. Take the full interactive Ethereum & Layer 1s 201 course to explore each lesson in more depth through guided explanations, examples, and activities.

Lesson 1 - State Models

Compares Ethereum's account-based global state with Bitcoin's UTXO model and introduces EOAs, Contract Accounts, nonce, balance, code hash, and storage root.

Lesson 2 - Transactions

Unpacks the Ethereum transaction envelope and follows chain ID, nonce, gas settings, destination, value, calldata, and signatures through the mempool or a private relay to validator inclusion.

Lesson 3 - Block Finality

Distinguishes inclusion, justification, and finalization through proof-of-stake slots, epochs, checkpoints, and validator attestations.

Lesson 4 - Gas Fees

Explains how gas bounds computation and how EIP-1559 base fees, priority fees, gas limits, and block demand shape transaction cost and inclusion.

Lesson 5 - Smart Contracts

Follows Solidity or Vyper source code through Yul to EVM bytecode and introduces contract creation, variables, functions, events, and error handling.

Lesson 6 - Token Standards

Covers ERC-20, WETH, ERC-721, and ERC-1155, including approvals, allowances, transfers, events, and metadata that let applications support assets consistently.

Lesson 7 - Account Abstraction

Shows how ERC-4337 uses User Operations, bundlers, the Entry Point, aggregators, and paymasters to support smarter wallets, sponsored fees, social recovery, and flexible verification.

Lesson 8 - Alternative Layer 1s

Compares Ethereum with other Layer 1 ecosystems through validator design, consensus, throughput, parallel execution, modularity, and interoperability.

How Ethereum tracks state

A state model is the framework a blockchain uses to represent and update its global ledger. Bitcoin and Ethereum use different models because they optimize for different things.

Bitcoin uses a UTXO model. It tracks individual transaction outputs. There is no native concept of persistent accounts or balances. This design is simple and reliable for transferring value, but it is not built around running applications.

Ethereum uses an account-based state model. It tracks account balances and account data continuously. This design makes it possible to have smart contracts that store data, run logic, and interact with other accounts directly on-chain.

On Ethereum, every participant is an account, but not all accounts behave the same. Externally Owned Accounts, or EOAs, are controlled by private keys and can initiate transactions. Contract Accounts are controlled by deployed smart contract code. They cannot start transactions by themselves, but when triggered by an EOA, they can execute logic, update data, and interact with other accounts or contracts.

Every Ethereum account is defined by four fields: nonce, balance, code hash, and storage root. The nonce records transactions sent from the account and prevents replay. The balance records how much ETH the account owns. The code hash identifies smart contract code for Contract Accounts and is empty for EOAs. The storage root points to persistent contract data and is also empty for EOAs.

Together, these account records form Ethereum’s global state. Transactions are the mechanism that changes that state.

How Ethereum transactions move through the network

A transaction is the mechanism that updates Ethereum’s global state. It can send ETH, call a contract, deploy a contract, or trigger logic that causes other internal calls.

Ethereum transactions are packaged in a transaction envelope. The envelope carries the data, fee settings, destination, value, calldata, and signature the network needs to process the sender’s intent. EIP-1559 introduced Type-2 transactions, now the common Ethereum format.

A transaction envelope includes identity and replay-protection fields such as chain ID and nonce; economic fields such as gas limit, max fee per gas, and max priority fee per gas; action fields such as destination, value, and calldata; and authorization through the sender’s signature.

Once signed, a transaction can enter the public mempool or travel through a private relay. Validators and block builders evaluate pending transactions, include valid ones in blocks, and execute them against the current state. The result is recorded as a state transition: balances, nonces, contract storage, and gas accounting update together.

This is why state and transactions must be learned together. Ethereum’s state is the living ledger. Transactions are the instructions that modify it.

How Ethereum finality works

Ethereum uses proof of stake to coordinate block production and finality. A block can be included, justified, and finalized. These are not the same thing.

An included block has been proposed and added to the chain. A justified block has received enough validator support within Ethereum’s checkpoint system. A finalized block has reached strong consensus and cannot be reverted without a major consensus failure.

Ethereum organizes time into slots and epochs. A slot is the smallest proof-of-stake time unit where one validator may propose a block. An epoch is a group of 32 slots used for validator rotations and checkpoint voting. Validators provide attestations to support blocks and checkpoints, helping the network agree on the canonical chain.

Finality matters because applications, exchanges, bridges, and users need to know when a transaction is not just visible, but economically settled. Finality timelines show how inclusion, justification, and finalization fit together.

How gas fees and EIP-1559 shape transaction costs

Gas is the unit Ethereum uses to measure computational work and bound execution. It prevents transactions and smart contracts from consuming unlimited network resources.

Each transaction has a gas limit: the maximum amount of work the sender is willing to pay for. If execution runs out of gas, the transaction can fail, but the gas used up to that point is still charged because validators still had to perform the work.

EIP-1559 changed Ethereum’s fee market by introducing a base fee and a priority fee. The base fee is determined by the protocol and adjusts with block demand. The priority fee is a user-selected tip that can help incentivize faster inclusion.

This structure means Ethereum fees are not simply “network charges.” They are part of a resource-pricing system. Gas prices reflect demand for blockspace, the amount of computation required, and the urgency of inclusion.

How smart contracts make Ethereum programmable

Smart contracts are programs deployed to Ethereum as Contract Accounts. They hold code and state, and they execute when called by a transaction or another contract.

A developer may write smart contract logic in Solidity or Vyper. That source code is compiled through intermediate representations such as Yul into EVM bytecode, the low-level code executed by the Ethereum Virtual Machine.

Smart contracts usually contain variables, functions, events, and error handling. Variables store data. Functions define what the contract can do. Events let applications track important state changes. Errors help contracts fail safely when conditions are not met.

This is the foundation of Ethereum’s programmable economy. Instead of only transferring value, Ethereum lets accounts run logic that can coordinate tokens, exchanges, lending markets, games, identity systems, governance, and other applications.

How token standards make Ethereum interoperable

Token standards let wallets, exchanges, and dapps support many assets without building custom integrations for every project. They define common interfaces that contracts can follow.

ERC-20 is the standard for fungible tokens. These are interchangeable units, such as stablecoins or governance tokens. WETH, or Wrapped Ether, is an ERC-20 representation of ETH used across DeFi integrations.

ERC-721 is the standard for unique non-fungible assets. ERC-1155 is a more flexible standard that lets one contract manage many token types, including fungible and non-fungible assets.

Related topics include approvals, allowances, transferFrom, events, and metadata. These details matter because token standards do more than define assets. They define how applications can recognize, move, approve, and display those assets.

How account abstraction improves Ethereum wallets

Traditional Ethereum wallets are based on EOAs. EOAs are simple and powerful, but they limit wallet flexibility. A private key controls the account, transactions must be signed in a specific way, and users usually need ETH to pay gas.

Account abstraction changes the wallet model by allowing smarter account logic. ERC-4337 enables account abstraction through User Operations without changing Ethereum consensus.

In this model, a user creates a User Operation. Bundlers collect these operations. The Entry Point contract coordinates validation and execution. Aggregators can support advanced signature schemes. Paymasters can sponsor fees, making gasless or sponsored transactions possible.

The result is a better wallet design space: social recovery, multi-signature verification, sponsored fees, batched actions, and more flexible security rules. Account abstraction does not remove Ethereum’s security assumptions, but it improves how users interact with them.

How Ethereum compares with alternative Layer 1 blockchains

Ethereum is one Layer 1 design, not the only possible design. Alternative Layer 1 blockchains make different choices around throughput, decentralization, validator design, execution models, modularity, and interoperability.

Some networks prioritize high throughput and fast execution. Others use different validator sets, consensus designs, parallel execution models, or application-specific architectures. Examples include Solana, Avalanche, BNB Smart Chain, Tron, Hyperliquid, Sui, Aptos, and Polygon PoS.

The design space includes mechanisms such as Solana's Proof of History-based timing, Avalanche's subnet architecture, Move-based execution in Sui and Aptos, and sidechain models such as Polygon PoS. These systems should be compared by the assumptions they make, not by throughput alone.

The point is not to rank every Layer 1. The point is to compare trade-offs. Higher throughput may depend on different hardware assumptions. Faster execution may change decentralization requirements. Modular and monolithic designs distribute responsibilities differently.

Ethereum’s design choices emphasize security, decentralization, programmability, and a broad developer ecosystem. Other L1s approach the same core problems in different ways.

Key takeaways

• Ethereum uses an account-based state model, unlike Bitcoin’s UTXO model.
• EOAs are controlled by private keys; Contract Accounts are controlled by deployed code.
• Transactions update Ethereum’s global state by carrying intent, fees, calldata, and a signature.
• Finality moves from inclusion to justification to finalization through proof-of-stake consensus.
• Gas prices computational work and helps prevent unbounded execution.
• Smart contracts make Ethereum programmable by letting accounts store and execute code.
• Token standards make assets interoperable across wallets, exchanges, and dapps.
• Account abstraction improves wallet flows without changing Ethereum consensus.
• Alternative Layer 1s make different trade-offs across speed, security, decentralization, and architecture.

Simple example: following one Ethereum transaction

A user opens a wallet and signs a transaction. The transaction envelope includes the chain ID, nonce, gas settings, destination, value, calldata, and signature. If the user is calling a contract, the calldata tells the contract which function to run and which arguments to use.

The signed transaction enters the network. It may sit in the public mempool, or it may be sent through a private relay. A validator or builder includes it in a block. Ethereum executes the transaction against the current state. The sender’s nonce increases, gas is charged, balances may change, and contract storage may update.

The block is included first. Later, through attestations and checkpoints, the block can become justified and finalized. At that point, the transaction is not only visible. It is deeply settled in Ethereum’s proof-of-stake consensus.

Continue learning

Related topics include Bitcoin 201, Scaling & Layer 2s 201, DeFi 201, and Market Structure 201. Ethereum mechanics are especially useful before studying rollups, DeFi protocols, token markets, and account-abstraction-based wallet design.

Glossary

Account-based model

A ledger design that tracks persistent account balances and account data directly.

UTXO model

A ledger design that tracks spendable transaction outputs rather than persistent balances.

Externally Owned Account (EOA)

An Ethereum account controlled by a private key and used to initiate transactions.

Contract Account

An Ethereum account controlled by deployed smart contract code.

Nonce

A counter that records transactions sent from an account and prevents replay.

Storage root

A reference to contract storage data in Ethereum’s account state.

Transaction envelope

The standardized package containing transaction fields, fee parameters, data, and signature.

Calldata

The encoded function selector and arguments used when a transaction calls a contract.

Mempool

A waiting area where pending transactions are shared before inclusion in a block.

Private relay

A relay path that sends transactions directly to validators to reduce public mempool exposure.

Slot

Ethereum’s smallest proof-of-stake time unit, where one validator may propose a block.

Epoch

A group of 32 slots used to coordinate validator rotations and checkpoints.

Finalized block

A block that has reached strong consensus and cannot be reverted without major consensus failure.

Gas

The unit Ethereum uses to price computational work and bound execution.

Base fee

The EIP-1559 protocol-determined fee that adjusts with block demand.

Priority fee

A user-selected tip that incentivizes faster validator inclusion.

EVM bytecode

The low-level code deployed to Ethereum and executed by the EVM.

Solidity

A high-level language purpose-built for smart contract development.

ERC-20

The token standard for fungible Ethereum tokens.

ERC-721

The token standard for unique non-fungible assets.

ERC-1155

A flexible token standard allowing one contract to manage many token types.

WETH

Wrapped Ether, an ERC-20 representation of ETH used for DeFi integrations.

Account abstraction

A wallet model that lets contract accounts support programmable verification and user flows.

ERC-4337

A standard that enables account abstraction through User Operations without changing Ethereum consensus.

Paymaster

An ERC-4337 component that can sponsor gas fees for users.

Alternative Layer 1

A base-layer blockchain with a different architecture or trade-off profile from Ethereum.

Validator set

The active participants responsible for proposing, verifying, and finalizing blocks.

Start the full interactive course

This guide covers Ethereum and other Layer 1 networks beyond the basics. The full course goes deeper with guided visuals, interaction-based practice, transaction and finality walkthroughs, knowledge checks, feedback, completion tracking, and the full Campus learning experience.

Start the full interactive Ethereum & Layer 1s 201 course to understand how Ethereum works under the hood and how Layer 1 blockchains make trade-offs across state, transactions, gas, smart contracts, token standards, wallet design, and architecture.