This content originally appeared on DEV Community and was authored by Allan Githaiga
Ethereum is more than just transfers of ETH — it’s a decentralized global computer powered by nodes and fueled by gas. Let’s break down its core components to help you grasp why it works the way it does.
1. The Ethereum Virtual Machine (EVM)
What it is: The EVM is the runtime engine powering Ethereum, a virtual CPU that runs smart contracts and processes transactions.
Why it matters:
It ensures every node executes code deterministically, so all states stay in sync.
It supports a defined set of opcodes (like ADD, JUMP, SLOAD), with each costing gas based on the amount of computation required .
Analogy:
Think of Ethereum as a massive online code playground, and the EVM as the consistent engine that runs your code—even on someone else’s computer. Every time you press “execute,” it runs exactly the same way.
2. Blocks: Ethereum’s Time Capsules
What it is: Ethereum groups transactions into blocks, each containing:
Block number, timestamp
-
Gas limit (cap for total gas used) & gas used
Transaction list, Merkle roots, parent hash, and proposer’s signature.
Why it matters: Blocks batch transactions to maintain consensus across nodes.
Each block advances the state, forming a permanent ledger of changes.
Analogy:
Blocks are like train cars, each carrying multiple passenger transactions and connected to the previous one to form a train—a never-ending ride.
3. Gas: Ethereum’s Fuel Meter
What it is: Gas measures how much computation you’re using. Every EVM opcode requires a specific gas amount .
Why we pay gas:
It prevents spam and infinite loops.
It pays validators for computation.
It ensures execution stays deterministic and bounded.
Gas Units vs. Gwei:
Gas units = computational steps
Gwei = 10⁻⁹ ETH, used to price each gas unit.
Example with Analogy:
Imagine riding a motorbike:
Distance = gas units
Fuel price per km = base fee + priority tip
You load your bike with just enough fuel (gas limit) and tip for priority service (priority fee).
4. Accounts: EOAs vs. Contract Accounts
Ethereum has two account types
1. EOA (Externally Owned Account)
Controlled by a private key
Can initiate transactions
No code, just ETH balance
2. Contract Account
Live code at an address
Can store data, and run logic when triggered
Cannot initiate transactions—EOAs must call them
Analogy:
EOAs are like people with wallets, while contract accounts are like vending machines: they respond to your actions, they can hold funds, but they don’t make moves on their own.
5. Transactions: State-Changing Actions
What they are: The only way to change Ethereum’s state (send ETH, create contracts, interact with smart contracts).
Transaction content includes:
from, to, value, nonce
gasLimit, maxFeePerGas, maxPriorityFeePerGas
data (optional), signature components
Stages of a transaction:
Signed by your private key
Broadcast to mempool
Picked by a validator
Executed, state updated, included in a block
Block finalized—permanent record
Analogy:
Think of it like ordering at a busy coffee shop:
You put in your order (transaction)
It goes on the queue (mempool)
A barista (validator) makes it (executes)
You wait until they confirm your order is done (block inclusion)
You finally drink it when it’s served (finalization)
Recap Table
Component | What It Does | Why It Matters |
---|---|---|
EVM | Runs smart contract bytecode | Ensures consistent behavior across all nodes |
Blocks | Batch transactions into permanent records | Maintain global state and ledger |
Gas | Measures computation, controls use | Prevents abuse, rewards validators |
EOA | User-controlled account with balance | Initiate transactions |
Contract | Code and state living on-chain | Enables programmable logic |
Transaction | Signed messages changing state | The only way to interact with Ethereum |
Why This Matters
By understanding these pillars:
You’ll optimize gas usage
Avoid common errors like low gas limits
Build or interact with contracts more confidently
Understand transaction lifecycles and how fees work
This content originally appeared on DEV Community and was authored by Allan Githaiga