Last fact-checked: 12 October 2026 (KST) · Educational guide
Ethereum combines accounts, programmable contracts and shared execution rules. To understand an application, follow three things: who authorizes an action, which code runs, and how its resource use is paid for.
This article explores Ethereum’s architecture and inner workings—including its virtual machine, account system, gas mechanics, and decentralized execution model.
1. Ethereum as a Decentralized Application Platform
Ethereum is a general-purpose blockchain that supports applications such as token transfers, exchanges and lending protocols.
Key Innovation: Smart Contracts
A smart contract is a program stored at an address. Its code runs when called during execution; it does not independently wake up because time has passed. Automation services can submit transactions, but those services are distinct from the contract itself.
Developers can use languages such as Solidity or Vyper and compile them into EVM bytecode. See Ethereum’s smart-contract introduction.
Ethereum’s Vision: The World Computer
The “world computer” metaphor refers to shared execution. It does not guarantee that a particular app is immune to admin controls, front-end outages or external-data failures. Common application categories include:
-
Decentralized Finance (DeFi)
-
Non-Fungible Tokens (NFTs)
-
Decentralized Autonomous Organizations (DAOs)
-
Web3 infrastructure
2. Ethereum Virtual Machine (EVM)
Purpose and Operation
The EVM is a decentralized, deterministic runtime environment for executing smart contracts on Ethereum. Execution clients apply the same rules to validate state changes. Given the same prior state, transaction inputs and block context, correct implementations compute the same result.
Key characteristics:
-
Turing-complete: Capable of performing any computation (given enough resources)
-
Stack-based: Uses a stack of 256-bit words, with a maximum depth of 1,024 items
-
Deterministic: Same state, inputs and execution context produce the same result
EVM Architecture: Key Components
| Component | Function |
|---|---|
| Stack | LIFO structure for temporary values during computation |
| Memory | Volatile, temporary storage for runtime data |
| Storage | Persistent key-value store tied to each contract |
| EVM Code | Smart contract bytecode to be executed |
| Program Counter (PC) | Pointer to the next instruction |
| Gas | Limits computation and prevents abuse |
Memory is local to an execution call frame. Persistent storage belongs to an account and survives transactions. Transient storage is another category: it can be shared by calls using that account within a transaction and is cleared at the end. EVM reference.
3. Gas: separate quantity from price
Gas measures execution work. The gas limit caps the quantity a transaction may consume; it is not a price in ETH. Under EIP-1559, the base fee is burned and the priority fee goes to the block proposer. Burning does not by itself guarantee that total ETH supply decreases, because issuance also matters.
| Field | Meaning |
|---|---|
| Gas used | The gas units actually charged for execution. |
| Gas limit | The transaction’s maximum gas quantity. |
| maxFeePerGas | The maximum total price per gas the sender permits. |
| maxPriorityFeePerGas | The maximum tip per gas. |
For a valid EIP-1559 transaction, the effective gas price is the lower of the maximum fee and the base fee plus the maximum tip. The execution fee is gas used × effective gas price. A higher fee cap is not automatically the amount paid.
Illustrative calculation: a basic 21,000-gas ETH transfer to an ordinary EOA, with a 15-gwei base fee, a 2-gwei maximum tip and a 30-gwei fee cap, pays 21,000 × 17 = 357,000 gwei, or 0.000357 ETH. Contract calls and delegated accounts may use more gas. These are invented prices, not a current quote. Blob transactions and rollup fees have additional considerations.
An included transaction that reverts still pays for gas consumed. An invalid transaction rejected before inclusion is different. Sources: Ethereum gas guide and EIP-1559.
4. Accounts after Pectra
An externally owned account (EOA) is controlled by a private key. An ordinary EOA has no code, but EIP-7702 allows it to carry a delegation indicator pointing to deployed code. This feature entered Ethereum mainnet with Pectra on 7 May 2025.
Delegation persists beyond one transaction. The original key remains authoritative; adding delegated logic does not automatically turn the account into a wallet whose key can no longer bypass that logic.
A conventional contract account runs its programmed rules when called. It can call other contracts, but does not originate an ordinary top-level signed transaction on its own. With ERC-4337, a bundler can submit smart-account operations through an EntryPoint contract.
Read the Pectra activation record and 7702 guidelines. Our EIP-7702 vs ERC-4337 guide explains the permission and fee consequences for wallet users.
5. Ethereum’s Expanding Ecosystem
-
EVM compatibility has enabled numerous Layer 1 and Layer 2 chains (e.g., Binance Smart Chain, Polygon, Optimism) to adopt Ethereum’s execution standard.
-
Compatible execution environments can make tooling and code easier to reuse. They do not automatically share security, state or liquidity; cross-chain transfers require additional mechanisms and assumptions.
6. Scaling: rollups and data availability
Ethereum’s roadmap emphasizes rollups and their data needs. Traditional execution shard chains are no longer the roadmap. Blob data and data-availability improvements support rollup scaling; they do not mean each L1 contract automatically runs on multiple execution shards. See Ethereum’s Danksharding explanation.
A useful reading exercise: open a transaction receipt and identify the sender, destination, success status, gas used and effective gas price. Then ask which contract permissions were used. An explorer’s success label confirms execution, not that the action was economically sensible.
Correction history — 12 October 2026 (KST): Added the EIP-7702 exception to the EOA model and linked the corrected account-abstraction guide. Clarified contract triggers, EVM word size and memory, fee caps, and the rollup roadmap. Removed copied editor formatting and added primary sources. Original publication date and URL retained.