Understanding How Ethereum Functions Under the Hood

Beyond simply transferring native tokens, Ethereum functions as a programmable Layer 1 blockchain where transactions, state, gas, consensus, token standards, smart contracts, and wallet architecture collaborate to support a unified global network.

This manual breaks down the internal mechanics of Ethereum and reviews how alternative Layer 1 protocols tackle comparable design hurdles.

The discussion centers on state tracking and modification, transaction routing through the network, computational pricing via gas, programmatic extensibility through smart contracts and token standards, and alternative methods employed by competing Layer 1 chains.

What you’ll learn

Ethereum & Layer 1s 201 presumes that learners already possess foundational knowledge regarding blockchains, private keys, wallets, ETH, and basic smart contract concepts. The focus here remains on the underlying mechanisms rather than surface-level user experiences.

• how Ethereum’s account-based state framework contrasts with the UTXO architecture of Bitcoin;
• how transactions are generated, authenticated, propagated, validated, included, and settled;
• how proof-of-stake finalization operates utilizing slots, checkpoints, epochs, and attestations;
• how EIP-1559, priority fees, base fees, and gas influence transaction expenses;
• how smart contracts are compiled and deployed on the network;
• how application interoperability is achieved via token frameworks like ERC-20, ERC-721, and ERC-1155;
• how account abstraction alongside ERC-4337 refines wallet interactions;
• how Ethereum stacks up against competing Layer 1 distributed ledgers.

Learning outcomes

Upon completing this material, participants should be capable of:

• detailing how the primary systems of Ethereum—such as gas, state, consensus, and transactions—interact to maintain network operations;
• following a transaction’s journey from initiation to final settlement;
• explaining how token standards and smart contracts transform the base layer into a programmable ecosystem;
• contrasting the architectural decisions of Ethereum with alternative Layer 1 networks by evaluating decentralization, performance, and security compromises.

Course lesson summaries

The summaries provided below offer a brief overview of the complete curriculum. Enroll in the interactive Ethereum & Layer 1s 201 course to investigate every section more thoroughly through guided examples, explanations, and activities.

Lesson 1 – State Models

Contrasts the global account-based state of Ethereum with the UTXO architecture of Bitcoin while introducing balances, nonces, Contract Accounts, EOAs, storage roots, and code hashes.

Lesson 2 – Transactions

Explores the transaction envelope of Ethereum, tracking signatures, chain IDs, destination addresses, nonces, gas parameters, value, and calldata from private relays or the mempool straight to validator inclusion.

Lesson 3 – Block Finality

Differentiates finalization, justification, and inclusion using proof-of-stake checkpoints, epochs, slots, and validator votes.

Lesson 4 – Gas Fees

Clarifies how gas limits computation while block demand, maximum fees, priority fees, and EIP-1559 base fees dictate transaction costs and inclusion rates.

Lesson 5 – Smart Contracts

Traces source code written in Vyper or Solidity through Yul down to EVM bytecode while introducing functions, variables, error management, and contract creation events.

Lesson 6 – Token Standards

Addresses ERC-1155, ERC-721, WETH, and ERC-20, focusing on metadata, transfers, approvals, allowances, and events that enable applications to manage assets uniformly.

Lesson 7 – Account Abstraction

Demonstrates how ERC-4337 utilizes paymasters, the Entry Point contract, bundlers, User Operations, and aggregators to facilitate flexible verification, social recovery, subsidized fees, and advanced wallets.

Lesson 8 – Alternative Layer 1s

Evaluates Ethereum against competing Layer 1 ecosystems by looking at interoperability, modularity, parallel execution, throughput, consensus, and validator frameworks.

How Ethereum tracks state

A state model defines the structure a distributed ledger employs to maintain and update its global record. Because they prioritize different objectives, Bitcoin and Ethereum implement distinct models.

Bitcoin relies on the UTXO framework, which keeps track of discrete transaction outputs without any built-in concept of account balances or persistent accounts. Although this structure is robust and straightforward for asset transfers, it is poorly suited for executing complex applications.

Conversely, Ethereum adopts an account-based state mechanism that continuously logs account data and balances. This design enables smart contracts to store information, execute logic, and communicate directly with other accounts on-chain.

Every participant on the Ethereum network acts as an account, though they function differently. Externally Owned Accounts (EOAs) are managed via private keys and possess the ability to kick off transactions. Contract Accounts are governed by deployed smart contract code; while they cannot initiate transactions independently, they execute logic, alter data, and interact with other contracts or accounts when triggered by an EOA.

Four distinct fields define every account on Ethereum: balance, nonce, storage root, and code hash. The nonce tracks outgoing transactions to prevent replay attacks. The balance shows the total ETH held by the account. The code hash points to the smart contract logic for Contract Accounts while remaining blank for EOAs. The storage root references persistent contract data and is likewise blank for EOAs.

Together, these distinct account ledgers construct the global state of Ethereum, which is subsequently modified via transactions.

How Ethereum transactions move through the network

Transactions serve as the primary vehicle for altering the global state of Ethereum. They can deploy code, invoke contracts, send ETH, or set off internal logic sequences.

Transactions are encapsulated within a transaction envelope that carries the signature, fee configurations, destination address, value, calldata, and data required for the network to execute the user’s instructions. Type-2 transactions, introduced by EIP-1559, represent the standard format on Ethereum today.

A transaction envelope incorporates identity and replay protection fields like the nonce and chain ID; economic parameters such as max priority fee per gas, max fee per gas, and gas limit; operational fields including calldata, value, and destination; along with the sender’s cryptographic authorization.

Once authenticated, the transaction enters the public mempool or routes through a private relay. Block builders and validators assess pending transactions, package valid ones into blocks, and process them against the existing state. The outcome manifests as a state transition, updating nonces, balances, gas accounting, and contract storage simultaneously.

This interconnectivity explains why state and transactions must be studied in tandem: state represents the ongoing ledger, whereas transactions provide the modification instructions.

How Ethereum finality works

Proof of stake coordinates both finality and block generation on Ethereum, where a block undergoes inclusion, justification, and finality—three distinct milestones.

An included block has merely been proposed and appended to the ledger. A justified block has acquired sufficient backing from validators within the checkpoint framework of Ethereum. A finalized block has achieved deep consensus, rendering it irreversible unless a catastrophic consensus failure occurs.

Time on Ethereum is measured in epochs and slots. A slot represents the fundamental unit of proof-of-stake time where a designated validator may propose a single block. An epoch consists of 32 slots dedicated to checkpoint voting and validator rotations. Validators issue attestations endorsing blocks and checkpoints, assisting the network in reaching consensus on the canonical chain.

Achieving finality is crucial because exchanges, bridges, applications, and users require assurance that a transaction is economically settled rather than merely visible. Timelines illustrating finality clarify how these stages connect.

How gas fees and EIP-1559 shape transaction costs

Gas functions as the computational unit of measurement on Ethereum, capping execution resource consumption to prevent smart contracts and transactions from draining excessive network capacity.

Every transaction carries a gas limit, representing the ceiling of computational work the sender agrees to fund. If execution exceeds this limit and runs out of gas, the transaction fails, yet the network still deducts fees for the computational effort expended up to that point.

The introduction of EIP-1559 overhauled the fee market by establishing priority and base fees. Protocol rules dictate the base fee, which fluctuates dynamically based on block utilization. Meanwhile, users append an optional priority fee to incentivize faster transaction inclusion.

Consequently, Ethereum fees operate as a sophisticated resource pricing mechanism rather than simple network tolls. Gas pricing reflects the urgency of inclusion, the computational resources demanded, and overall blockspace demand.

How smart contracts make Ethereum programmable

Smart contracts are executable programs deployed as Contract Accounts on Ethereum. They maintain state and code, running whenever invoked by a transaction or another contract.

Developers typically draft smart contract code using Vyper or Solidity. This source text is compiled through intermediate steps like Yul into EVM bytecode, which is the low-level instruction set processed by the Ethereum Virtual Machine.

Typically, smart contracts feature functions, variables, error management, and events. Variables hold data, functions outline operational capabilities, events allow applications to monitor critical state updates, and error handlers ensure safe failure modes when preconditions aren’t met.

This infrastructure underpins the programmable economy of Ethereum. Rather than solely facilitating value transfers, the network allows accounts to execute complex logic, coordinating lending markets, tokens, gaming economies, governance structures, decentralized exchanges, and numerous other applications.

How token standards make Ethereum interoperable

Token frameworks allow dapps, wallets, and exchanges to support diverse assets seamlessly without requiring bespoke integrations for every individual project by establishing uniform interfaces that contracts can adopt.

ERC-20 serves as the baseline for fungible tokens, representing interchangeable units such as governance assets or stablecoins. Similarly, Wrapped Ether (WETH) provides an ERC-20 compatible wrapper for ETH utilized widely across decentralized finance protocols.

ERC-721 governs unique, non-fungible assets, while ERC-1155 offers a versatile standard enabling a single contract to oversee multiple token classifications, encompassing both fungible and non-fungible assets simultaneously.

Associated concepts include allowances, approvals, transferFrom functions, event logging, and metadata. These elements are essential because token standards dictate not only asset characteristics but also how applications recognize, transfer, authorize, and display those digital assets.

How account abstraction improves Ethereum wallets

Legacy Ethereum wallets rely on EOAs. While EOAs are robust and straightforward, they constrain wallet versatility; a single private key governs the account, signing must follow rigid formats, and users generally need ETH to cover gas.

Account abstraction transforms this paradigm by empowering wallets with programmable logic. ERC-4337 achieves this abstraction via User Operations without altering underlying consensus rules.

Within this architecture, users generate User Operations that are gathered by bundlers. The Entry Point contract then orchestrates validation and execution. Advanced signature schemes can be supported via aggregators, while paymasters facilitate fee sponsorship, making sponsored or gasless transactions viable.

The outcome is an expanded design space for wallets supporting batched executions, social recovery, multi-signature authentication, sponsored transaction fees, and adaptable security policies. While account abstraction leaves Ethereum’s core security model intact, it greatly improves the user experience.

How Ethereum compares with alternative Layer 1 blockchains

Ethereum represents one specific design philosophy among many potential Layer 1 architectures. Competing base-layer networks adopt varying compromises regarding interoperability, modularity, execution frameworks, validator structures, decentralization, and throughput.

Certain platforms emphasize rapid execution and high transaction volumes, whereas others utilize alternative validator networks, consensus models, application-centric structures, or parallel execution engines. Prominent examples include Solana, BNB Smart Chain, Avalanche, Hyperliquid, Tron, Sui, Aptos, and Polygon PoS.

This architectural landscape features mechanisms like Avalanche subnet designs, Solana’s Proof of History timing, sidechain setups like Polygon PoS, and Move-based execution environments on Sui and Aptos. Evaluating these systems requires examining their foundational assumptions rather than focusing solely on throughput metrics.

The objective is not to declare a single superior Layer 1, but rather to analyze trade-offs. Enhanced speed may necessitate heavier hardware dependencies, and accelerated execution could impact decentralization guarantees, while monolithic and modular designs distribute operational duties differently.

The design philosophy of Ethereum prioritizes decentralization, security, developer extensibility, and broad ecosystem support, whereas competing L1s address these fundamental challenges through alternative approaches.

Key takeaways

• Unlike the UTXO architecture of Bitcoin, Ethereum implements an account-based state framework.
• Private keys control EOAs, whereas deployed code governs Contract Accounts.
• Transactions modify the global state of Ethereum by packaging intent, signatures, calldata, and fee parameters.
• Proof-of-stake consensus drives finality through a progression of inclusion, justification, and finalization.
• Gas prices out computational operations to prevent infinite execution loops.
• Smart contracts transform Ethereum into a programmable platform by enabling accounts to store and run code.
• Interoperability of digital assets across dapps, wallets, and exchanges is ensured by token standards.
• Wallet usability is enhanced through account abstraction without modifying core consensus rules.
• Alternative Layer 1 networks manage architectural compromises differently across security, architecture, speed, and decentralization.

Simple example: following one Ethereum transaction

A user signs a transaction within their wallet application. This transaction envelope incorporates the signature, destination, gas configurations, calldata, nonce, chain ID, and value. When interacting with a contract, the calldata informs the target contract which function to execute and supplies the requisite arguments.

Upon signing, the transaction enters the broader network, sitting in the public mempool or routing through a private relay. A block builder or validator integrates it into a proposed block, and Ethereum processes the instruction against the current state. Consequently, the sender’s nonce increments, gas fees are deducted, balances adjust, and contract storage may be updated.

The block is initially included in the chain. Subsequently, through checkpoints and attestations, it progresses to justified and finalized states. At that juncture, the transaction transcends visibility, achieving deep economic settlement under the proof-of-stake consensus of Ethereum.

Continue learning

Related subjects include Scaling & Layer 2s 201, Bitcoin 201, Market Structure 201, and DeFi 201. Gaining familiarity with Ethereum mechanics is especially beneficial before diving into rollups, token economies, decentralized finance protocols, and wallet designs built on account abstraction.

Glossary

Account-based model

An architectural ledger design that records persistent account data and balances directly.

UTXO model

A ledger structure that tracks unspent transaction outputs instead of maintaining explicit account balances.

Externally Owned Account (EOA)

An Ethereum account managed via a private key utilized for initiating transactions.

Contract Account

An account on Ethereum governed by deployed smart contract code.

Nonce

An incremental counter tracking outgoing transactions from a specific account to thwart replay attacks.

Storage root

A cryptographic pointer referencing the persistent contract storage data within the account state of Ethereum.

Transaction envelope

The standardized data container holding signature parameters, fee instructions, data, and transaction fields.

Calldata

The encoded arguments and function selector utilized when a transaction invokes a smart contract.

Mempool

A holding queue where unconfirmed transactions reside prior to block inclusion.

Private relay

A specialized transmission pathway that delivers transactions directly to validators to bypass public mempool visibility.

Slot

The shortest increment of proof-of-stake time on Ethereum during which a designated validator proposes a block.

Epoch

A collection of 32 sequential slots utilized for managing checkpoint votes and validator rotations.

Finalized block

A block that has secured robust consensus, making reversion impossible without experiencing major consensus failure.

Gas

The metric utilized by Ethereum to quantify computational effort and constrain execution boundaries.

Base fee

The mandatory protocol-enforced fee under EIP-1559 that fluctuates in response to block congestion.

Priority fee

An optional tip supplied by users to encourage validators to prioritize transaction inclusion.

EVM bytecode

The low-level operational code deployed to the network and processed by the EVM.

Solidity

A high-level programming language tailored specifically for building smart contracts.

ERC-20

The foundational technical specification governing fungible tokens on Ethereum.

ERC-721

The standard interface dedicated to unique non-fungible digital assets.

ERC-1155

A versatile multi-token standard permitting a single contract to manage numerous asset variations.

WETH

Wrapped Ether, which acts as an ERC-20 compatible version of ETH employed throughout decentralized finance.

Account abstraction

A wallet framework empowering contract accounts to support customizable user interactions and programmable validation.

ERC-4337

A technical standard facilitating account abstraction via User Operations without modifying core consensus mechanisms.

Paymaster

An ERC-4337 protocol participant capable of covering gas expenses on behalf of users.

Alternative Layer 1

A base-layer blockchain featuring an architectural design or compromise profile distinct from Ethereum.

Validator set

The active network participants tasked with verifying, proposing, and finalizing blocks.

Start the full interactive course

This overview explores Ethereum and alternative Layer 1 networks beyond the fundamentals. The complete curriculum offers deeper immersion through interactive exercises, visual aids, transaction walkthroughs, comprehension quizzes, feedback systems, and progress tracking as part of the overarching Campus learning journey.

Start the full interactive Ethereum & Layer 1s 201 course to grasp how Ethereum functions internally and how alternative Layer 1 chains navigate compromises surrounding state, gas, transactions, smart contracts, wallet design, token standards, and architecture.