Ethereum works as a shared state machine: thousands of independent nodes keep the same record of every account, balance, and contract, and any signed transaction updates that record under rules each node verifies for itself. No central server holds the truth; the network agrees on it block by block, which is why value moves on Ethereum without an intermediary.
What is Ethereum at the protocol level?
At the protocol level, Ethereum is a single global state machine that every full node executes in lockstep: each node independently runs the same transactions and arrives at the same updated state, so no operator's copy is more authoritative than another's. The popular "world computer" label refers specifically to the Ethereum Virtual Machine, the engine that runs those state-changing rules.
Picture a giant spreadsheet that thousands of independent operators keep on their own machines, and every time someone wants to add a row or change a cell, they broadcast a signed request to the whole group. Each operator checks the request against the rules, runs the same calculation, and arrives at the same updated spreadsheet. No single operator is in charge, and any operator can verify any other operator's work. That is the mental picture of Ethereum's design (source: Technical intro to Ethereum).
The reason the design matters is that it removes the need to trust a single record-keeper. A bank's database is opaque, and you trust the bank because of laws, audits, and reputation. Ethereum's database is open, every participant computes the result independently, and you trust the result because the math is verifiable rather than because any single party vouched for it. That property is what makes Ethereum suitable for moving value without an intermediary, and it is also why every action on Ethereum costs gas: the redundancy across thousands of nodes is real work, and someone has to pay for it.
This article covers the protocol itself. ETH as a financial asset is a different topic, covered in ETH tokenomics and what drives ETH price (sibling articles shipping later in this pillar). For the portfolio-allocation view of ETH alongside Bitcoin, see Blofin's piece on BTC vs ETH in a portfolio.
What is the difference between an EOA and a contract account?
Ethereum has exactly two account types. An externally owned account (EOA) is controlled by a private key. A contract account is controlled by code deployed to it. Your MetaMask is an EOA. USDT on Ethereum is a contract account. Mixing them up is the most common source of confusion for new Ethereum users.
EOAs: the accounts your wallet controls
An EOA is the account type you create the first time your address shows up in a transaction. There is no creation fee and no deployment step. The private key derives the address, and the address is valid the moment the network sees it. EOAs can do three things on their own: sign transactions, send ETH, and trigger smart contracts by calling them. An EOA cannot run code on its own, which matters because every chain of activity on Ethereum starts with an EOA somewhere signing a transaction (source: Ethereum Accounts).
Contract accounts: the accounts that run code
A contract account is created when someone deploys a smart contract to the network. The deployment transaction sets the account's permanent address and loads the compiled code into it. After deployment, the code cannot be changed, except through specific upgrade patterns the contract was built to allow. A contract account can hold ETH, hold ERC-20 tokens like USDT, and run complex logic, but it cannot initiate a transaction on its own. It only acts when something calls it. When Blofin sends a USDT withdrawal, the contract account that holds the USDT logic is the one running the transfer, and the call comes from a Blofin EOA, not from the user's wallet.
What both account types share
Every account on Ethereum, regardless of type, carries the same four fields in the state. The fields are how Ethereum tells one account from another and tracks what each one holds.
Field | EOA value | Contract account value |
|---|---|---|
nonce | Number of transactions this account has sent | Number of contracts this account has created |
balance | Amount of ETH held, in wei (1 ETH = 10^18 wei) | Same: amount of ETH held by the contract |
codeHash | Hash of an empty string (no code) | Hash of the deployed bytecode |
storageRoot | Empty (EOAs have no contract storage) | Root hash of this contract's storage trie |
The four fields are what every Ethereum node stores for every address. Together they define what the account is and what it owns.
The post-Pectra hybrid: EIP-7702
The clean EOA-versus-contract split has blurred since the Pectra upgrade activated on mainnet on May 7, 2025 (source: Pectra mainnet activation). EIP-7702 introduced a transaction type that lets an EOA set a revocable delegation pointer to a target contract, so the account can run that contract's code as if it were its own until the owner clears the pointer (source: EIP-7702 specification). In practice, this means an EOA can behave like a smart wallet (enabling batched transactions, sponsored gas, and limited session keys) without permanently converting into a contract account. The result is a third mode that sits between the two original types. For the full treatment of how account abstraction reshapes wallets, see Ethereum account abstraction.
Where does your ETH balance actually live?
Your ETH balance lives in Ethereum's global state, a giant record holding the four-field entry for every account at the current block. The state sits in a Modified Merkle Patricia Trie, a hashed tree whose single root hash lives in every block header. Change any balance and the root changes, which is how nodes detect every state shift.
State is the source of truth your block explorer reads from
When Etherscan shows your ETH balance, it is reading from the state trie. When a smart contract checks whether you own enough USDT to send some, it is reading from the contract's storage trie. The state is what every full node agrees on, and the agreement is what makes Ethereum trustless. A new node joining the network either downloads the full state from genesis and verifies every step, or it downloads a recent snapshot and verifies that snapshot's root hash matches the one in a recent block header (source: Patricia Merkle Trie).
The Merkle Patricia Trie at the simplest level
The Modified Merkle Patricia Trie combines two ideas. The Patricia part is a prefix tree, which stores key-value data efficiently by sharing common prefixes between keys. The Merkle part is that every node in the tree is hashed, and each hash depends on the hashes of its children, so the single root hash at the top is a cryptographic fingerprint of every piece of data in the entire structure. Change one account's balance, and the chain of hashes from that account up to the root all change. The root in the block header is therefore a guarantee that nothing in the state has been quietly tampered with.
The four tries committed in every block
Ethereum actually commits to four trie roots per block, not one. Three of them live in the block header directly; the fourth sits one level deeper.
Trie | What it encodes | Where the root lives |
|---|---|---|
State trie | All accounts (EOAs and contracts), with their nonce, balance, codeHash, and storageRoot | stateRoot in the block header |
Transactions trie | All transactions included in this block | transactionsRoot in the block header |
Receipts trie | Execution results of each transaction (gas used, logs, success or failure) | receiptsRoot in the block header |
Storage trie | Each contract's internal storage, one trie per contract | Referenced via storageRoot inside the state trie entry for that contract |
The three roots in the header are what validators sign when they propose a block. Together they form a cryptographic fingerprint of the network's state, every transaction in that block, and every transaction's outcome. This is the structure that makes block-by-block verification cheap even when the state itself is large.
What is inside an Ethereum transaction?
An Ethereum transaction is a signed instruction that tells the network to apply a specific change to the state. The signature proves the private key holder authorised it, and the fields tell the EVM exactly what to do. Every action on Ethereum, from an ETH transfer to a Uniswap swap, fits inside the same transaction format.
The core fields are below (source: Ethereum Transactions). A wallet builds a transaction by filling out these fields and signing it; a node validates the signature and processes the result.
Field | Purpose |
|---|---|
from | The EOA initiating the transaction, derived from the signature |
to | The recipient: an EOA address (ETH transfer) or a contract address (contract interaction) |
value | The amount of ETH to transfer to the recipient, in wei |
nonce | A counter that increases by one with every transaction this account sends |
gasLimit | The maximum gas the sender authorises the EVM to consume |
maxFeePerGas | The maximum total fee per unit of gas the sender will pay |
data | For contract calls, the function selector plus encoded arguments; empty for plain ETH transfers |
The signature fields v, r, and s prove the transaction was authorised by the private key holder. The nonce serialises transactions from the same account, which is why broadcasting two transactions with the same nonce results in only one being included, and the others get dropped or replaced.
The Ethereum Yellow Paper describes every block as one application of the state transition function. Given an old state S and a set of valid transactions T, the function produces a new state S', written as Y(S, T) = S'. A simple ETH transfer from Alice to Bob is straightforward: Alice's balance falls by the value plus gas paid, Bob's balance rises by the value, Alice's nonce increases by one. A contract call is more complex because the EVM runs the contract's bytecode, which can update storage, emit events, transfer ETH, or call other contracts. At the end of execution, the result is S'.
If execution fails (out of gas, an explicit revert, or an invalid instruction), the state changes get rolled back, but the gas consumed up to the failure is still charged. This is why a failed transaction still costs you money: the EVM did the work before deciding the change was invalid, and the network paid for that work even if the result was discarded.
What is the Ethereum Virtual Machine, exactly?
The Ethereum Virtual Machine, or EVM, is the deterministic engine that runs the code which changes Ethereum's state. Every full node runs its own copy, and they all reach the same result for the same inputs. Determinism is what lets thousands of independent nodes agree on the network's state without trusting each other (source: Ethereum Virtual Machine).
Determinism means same input always produces same output
The EVM behaves like a mathematical function. Give it the same starting state and the same transaction, and it always produces the same ending state. Without that property, nodes would compute different results from the same input, they would disagree about what the new state should be, and the network would split into incompatible chains. Determinism is also the reason your wallet can simulate a transaction before you sign it: the simulation runs the same EVM logic against the current state, and the estimate is accurate because there is no randomness in the path from input to output.
Stack-based and opcode-by-opcode
The EVM is a stack machine with a stack depth of 1024 items, where each item is a 256-bit word, sized to match the cryptographic primitives Ethereum uses. Smart contract code is compiled into a sequence of EVM instructions called opcodes, and the EVM processes them one at a time. Simple opcodes like ADD, SUB, and AND perform arithmetic and logic. Blockchain-specific opcodes like BALANCE, BLOCKHASH, and SLOAD read from the chain state. Storage opcodes like SSTORE write to it.
Every opcode has a gas cost that reflects the computational and storage burden it places on every node that runs the contract. Reading from contract storage is more expensive than reading from memory; writing to storage is the most expensive class of operation, because every node has to persist the change. The cost schedule is not arbitrary, and developers optimise contracts by minimising storage writes and re-using cached reads.
Why gas exists: bounding what is otherwise unbounded
The EVM is Turing-complete, which means it can in principle compute anything a normal computer can compute. Turing-completeness has a well-known problem: it allows infinite loops. Without a way to stop them, a single malicious transaction could lock up every node on Ethereum forever.
Ethereum solves this with two limits. Each transaction carries a gasLimit set by the sender, which caps the total computational work that transaction can do. Each block has a higher gas limit set by the protocol, which caps the total work across all transactions in the block. The block gas limit was raised to roughly 60 million units by late 2025, in three steps from the 30 million baseline that had held since 2021, with further increases on the 2026 roadmap (source: Etherscan live block stats). When a transaction hits its gasLimit, the EVM stops, reverts the state changes, and charges for the gas already consumed. The constraint turns the EVM into an "effectively" Turing-complete machine that is capable of any computation but bounded in every execution. For the full treatment of how gas pricing works in practice, see how gas works on Ethereum.
How does a Blofin USDT withdrawal move through the EVM?
A Blofin USDT withdrawal is the cleanest place to see every concept in this article working at once. One click in the Blofin app becomes a smart-contract call, runs through the EVM, and ends with a state change every node has independently verified. The five steps below tie the mechanics to a transaction most readers have sent.
From Blofin's operational perspective, the moment one of our hot-wallet EOAs signs and broadcasts a USDT withdrawal, the transaction enters the public mempool exactly the way any retail user's transaction does. Peer propagation does not favour the exchange. It favours fee priority and the connectivity of the node that broadcast first. The network is fee-blind, not actor-blind.
Step 1: User initiates a withdrawal on Blofin. The user enters their MetaMask address, picks USDT as the asset, picks Ethereum mainnet as the network, and confirms the amount. Blofin's backend verifies the request against the user's balance, withdrawal limits, and any pending security checks, then queues the transaction for the operational hot wallet to sign.
Step 2: Blofin broadcasts a transaction from a hot-wallet EOA. The hot-wallet EOA signs a transaction whose to field points to the USDT contract address, not to the user's MetaMask. The data field encodes a call to the USDT contract's transfer(address, uint256) function, with the user's MetaMask address as the first argument and the withdrawal amount as the second. The transaction enters the mempool and waits for inclusion in a block.
Step 3: The EVM runs the USDT contract's transfer function. When a validator includes the transaction in a block, every full node loads the USDT contract's bytecode and runs it. The EVM reads Blofin's USDT balance from the contract's storage trie, checks that it is sufficient, subtracts the amount from Blofin's balance, and adds the amount to the user's balance. The contract emits a Transfer event, which gets captured in the receipts trie and shows up on Etherscan as the on-chain confirmation that the transfer happened.
Step 4: Gas is deducted from the Blofin EOA. An ERC-20 transfer consumes approximately 65,000 gas units, well above the 21,000-unit floor for a plain ETH transfer because the EVM has to load the contract code and update storage. The opcode-cost schedule that drives those figures is documented in the protocol gas docs, with live gas tracking on Etherscan (source: Etherscan gas tracker). The gas cost comes out of Blofin's hot-wallet EOA, not the user's MetaMask balance. Blofin sets withdrawal fees to cover this cost on a network-by-network basis, which is why mainnet ETH withdrawals are priced differently from withdrawals on Arbitrum or Base. For the gas mechanics behind those fee figures, see how gas works on Ethereum.
Step 5: State updates across the network. Within one block, every full node has applied the same state transition. The USDT contract's storage trie has updated the balance entries for both Blofin and the user. The user's MetaMask wallet will reflect the new balance as soon as it queries any node, which is why a withdrawal that has been included on-chain can still appear to be "missing" if MetaMask is pointed at the wrong network or has not refreshed its data. The funds are at the user's address on Ethereum; the balance is visible to anyone querying the right contract on the right chain.
Reading the receipt on Etherscan
Once the block is final, the withdrawal leaves a public receipt that confirms every step above. The table maps the fields on a typical ERC-20 transfer's Etherscan page to the concept each one proves (the values are illustrative of a standard USDT withdrawal, not a specific transaction).
Etherscan field | What it shows | What it confirms in this article |
|---|---|---|
From | The Blofin hot-wallet EOA address | An EOA, not the user's wallet, initiated and signed the transaction (Step 2) |
Interacted With (To) | The USDT contract address | The to field targets the contract, not the recipient (Step 2) |
Tokens Transferred | Transfer [amount] USDT From 0xBlofin… To 0xUser… | The decoded transfer(address, uint256) call carried in the data field (Step 2) |
Value | 0 ETH | No ETH moved in the value field; the USDT balance change lives in contract storage, not the base ledger (Step 3) |
Transaction Fee / Gas Used | Roughly 65,000 gas, paid by the Blofin EOA | The gas cost of loading contract code and writing storage, charged to Blofin (Step 4) |
Transaction Action / Logs | The emitted Transfer event | The event captured in the receipts trie, which is the on-chain confirmation the transfer happened (Step 3) |
Status | Success | The state transition committed; a revert here would still have charged the gas already consumed |
What does Ethereum's design cost?
The same redundancy that makes Ethereum trustless makes it slow and expensive. Every full node runs every transaction, the EVM does not parallelise within a block, and throughput is bounded by what one thread finishes under the block gas limit. The trade-off is paid in fees, and the response is the Layer 2 architecture covered later in this pillar.
From Blofin's operational perspective, an inbound deposit transaction reaches mempool inclusion within roughly twelve seconds, hits the confirmation count our automated systems require within four to seven minutes, and triggers user-balance credit shortly after. The same redundant computation that makes the network slow is what makes the timing predictable enough to automate against. We do not have to ask any one node whether a transaction landed; we read the block header, verify the receipts trie, and the answer is the same on every node we query.
Predictability for traders and users
Determinism creates a payoff a centralised system cannot easily match: simulation is accurate. Every modern Ethereum wallet shows a gas estimate and a preview of what the transaction will do before the user signs. The simulation runs the same EVM logic against the current state. The estimate matches reality because EVM execution is a mathematical function, not a probabilistic process. Traders running automated strategies, exchanges sending withdrawals, and DeFi protocols composing across multiple contracts all benefit from this: the same inputs produce the same outputs, every time, on every node.
Composability comes free
Because every contract sits at a public address and can be called by any other contract, Ethereum's smart contracts compose. A single transaction can atomically swap a token, deposit the result into a lending pool, borrow against it, and forward the loan somewhere else, all without any single party coordinating the steps. This property is what made DeFi possible on Ethereum and what makes it hard to replicate on isolated systems. For the full treatment of how composability shapes the DeFi ecosystem, see DeFi on Ethereum.
The trade-offs are real
The same redundancy is expensive. Every full node stores the full state and runs every transaction. State growth is a long-running pressure that Ethereum's research roadmap addresses through state expiry and Verkle trees. Both might enable smaller proofs and lighter nodes, but both are still in development; they do not affect today's behaviour.
The mainnet throughput limit is the more immediate constraint. Layer 2 rollups offload execution to their own sequencers while posting compressed state back to Ethereum, which is how Arbitrum, Optimism, and Base deliver fees that are roughly one to two orders of magnitude cheaper than mainnet. The settlement security still ultimately comes from Ethereum, which is why the architecture is described as "rollup-centric." For the deeper coverage of how L2s extend Ethereum's capacity, see why Ethereum needs Layer 2s.
Frequently asked questions
Is Ethereum the same as ETH?
No. Ethereum is the protocol: the rules, the EVM, the state machine, the network of nodes. ETH is the native asset that pays for gas and that validators stake as collateral. You can hold ETH without interacting with any smart contract, and someone else can sponsor your gas if you have the right wallet setup. The two are tightly related but distinct objects, and confusing them is a common source of mistakes when people first arrive at Ethereum.
How is Ethereum's design different from Bitcoin's?
Bitcoin uses an unspent transaction output, or UTXO, model that tracks ownership through chains of unspent outputs. Ethereum uses an account model where every address has an explicit balance and state. Bitcoin's scripting language is intentionally limited and is not Turing-complete; Ethereum's EVM is Turing-complete with gas as the bound. Both approaches involve real trade-offs in complexity, security surface area, and what kind of applications fit. For the full comparison, see Bitcoin vs Ethereum.
Why do Ethereum transactions cost gas?
Gas prices every computational step the EVM performs (source: Ethereum Gas and Fees). Without a cost attached to each operation, anyone could submit a transaction that runs an infinite loop, consuming every node's CPU for free. Gas turns computation into a market: the network charges for the work, and the base fee gets burned while the priority tip goes to the validator who includes the transaction. The full mechanics of base fee, priority fee, and EIP-1559 are covered in how gas works on Ethereum (source: EIP-1559 specification).
Can the EVM be upgraded?
Yes. Changes to the EVM are proposed through Ethereum Improvement Proposals, reviewed by the All Core Devs meetings, and shipped in coordinated network upgrades. Recent examples include Pectra (activated May 2025, which added EIP-7702 among other changes) and Fusaka (activated December 2025); the next major upgrade in the roadmap is Glamsterdam. No single party can change the EVM unilaterally; every upgrade requires rough consensus among the client teams who build the software validators and node operators run.
How does Ethereum's state grow over time, and is that a problem?
The state trie grows every time a new account is created or a contract stores new data. Once a piece of state is written, it stays in the trie until something explicitly deletes it. Over Ethereum's history since 2015, the chain has grown into the multi-terabyte range that every full node must store (the pruned-archival disk requirement sits in the 1 to 2 terabyte band as of 2026), and that growth creates real barriers to running a node on low-resource hardware. The roadmap addresses this through state expiry mechanisms and Verkle trees, which are in research and development as of 2026; pruning of historical block data is already possible through snap sync and similar modes.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Ethereum Yellow Paper, EIP-7702 specification, and ethereum.org developer documentation. All facts independently verified against cited documentation current as of May 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making investment decisions. Blofin Academy content reflects the state of public information at time of publication; protocol parameters, fees, and ecosystem data change frequently.