Ethereum is a programmable state machine maintained collectively by distributed nodes. Execution clients run the EVM and update account state, consensus clients select the head of the chain, and validators propose blocks and cast votes.
The term "world computer" does not refer to a single globally shared server. Instead, many nodes deterministically execute the same set of transactions. Only when every node reaches the same result can the network agree on account balances, contract storage, and event logs.

After the Merge, a full Ethereum node typically includes an execution client and a consensus client. A validator component is also required when the operator participates in staking and block production.
| Component | Primary responsibility |
|---|---|
| Execution client | Maintains the transaction pool, runs the EVM, validates state transitions, and provides JSON-RPC |
| Consensus client | Receives blocks and votes, runs fork choice, and tracks checkpoint finality |
| Validator | Signs attestations and proposes blocks when selected |
| Engine API | Lets execution and consensus clients exchange execution payloads and validation results |
Running only an execution client is not enough to identify the current canonical chain head, while a consensus client alone cannot independently execute EVM transactions. The validator is optional: not every synchronized node needs to stake ETH.
The EVM is a deterministic virtual machine. Smart contracts are compiled into bytecode and stored at on-chain addresses. When a transaction calls a contract, nodes execute the code with the same opcodes and inputs.
Ethereum uses an account model. Externally owned accounts are controlled by private keys, while contract accounts are controlled by code. The global state records balances, nonces, contract code, and storage, and each valid block produces a new state transition.
Contracts can call one another, allowing DeFi protocols to compose like software components. Composability also propagates risk: if an underlying token, oracle, or called contract fails, applications built on top of it may be affected at the same time.

After a user signs and broadcasts a transaction, the execution client first checks its signature, nonce, and fee conditions. A block builder or validator selects transactions and creates an execution payload. The EVM processes them in order, producing a new state root and transaction receipts.
The consensus client validates the block and its execution result. Validators sign attestations for the chain head and checkpoints. Fork choice updates the canonical chain according to valid votes, and checkpoints that meet the protocol threshold subsequently become finalized.
| Stage | Possible causes of failure |
|---|---|
| Before broadcast | Invalid signature, nonconsecutive nonce, or insufficient balance |
| Entering the transaction pool | Fees are too low or the node's policy rejects the transaction |
| EVM execution | Contract conditions are not met, gas runs out, or the call reverts |
| Consensus confirmation | The block does not become canonical or the network temporarily forks |
| Application settlement | The confirmation or finality threshold required by the application has not yet been reached |
A failed transaction may still consume gas because nodes have already performed computation and used block resources.
Gas measures the resources consumed by EVM operations and data. Users pay fees in ETH. The protocol burns the base fee, while priority fees and other revenue may enter the block production process.
ETH also serves as the security collateral for proof of stake. Validators lock assets to propose blocks and vote. Going offline reduces their rewards, while serious violations may trigger slashing. This ties network security to staked capital, although concentration among staking services remains a risk worth monitoring.
The gas limit caps the amount of work that can be performed in a single block, preventing unbounded computation from overwhelming nodes. Raising the limit can increase capacity, but it also increases execution demands and state growth pressure.
Ethereum delegates much of its additional capacity to rollups. Layer2 networks execute batches of transactions off-chain and then submit data or proofs to Ethereum, allowing L1 to focus more on settlement, data availability, and dispute resolution.
Different Layer2 networks may use centralized sequencers, challenge periods, or zero-knowledge proofs. Users need to distinguish whether an asset is on Ethereum mainnet, on a particular Layer2, or represented by a bridged token. For route-specific details, see the Overview of Layer2 Scaling Solutions.
Ethereum and Bitcoin pursue different goals. Read the Bitcoin Deep Dive for a comparison, or return to the 2025 Overview of Major Layer 1 Blockchain Ecosystems for a broader multichain perspective.
Not directly. Nodes must receive identical inputs to execute deterministically, so off-chain information such as prices, weather, or sports results is usually submitted on-chain by oracles.
ETH is the protocol's native asset and is used to pay gas fees and stake. ERC-20 token balances and transfer rules are recorded by smart contracts, and interacting with them usually still requires ETH to pay network fees.
Not always. The code at a contract address usually cannot be changed directly, but a project can use proxies, governance, or migration mechanisms to change the logic users interact with. Users should check who controls the upgrade permissions.
No. Anyone can run a non-validating node to verify on-chain data. A deposit of 32 ETH is required to operate a standalone protocol validator, not to synchronize a node.


