Ethereum is essentially a transaction-based state machine. In computer science, a state machine can read a series of inputs and, based on them, transition to a new state.

Ethereum’s state machine starts from a blank genesis state and is driven by transactions, transitioning from one state to another.

Each state of Ethereum carries a large amount of transaction information, which is assembled into a block. A block contains a series of transactions, and each block is linked to the one before it.

For a transaction to be considered valid, it must be included in a block and agreed upon by the network through consensus. Before the “Merge” in September 2022, Ethereum used Proof of Work (PoW), like Bitcoin, with miners competing through computational power to produce blocks. After the Merge, Ethereum officially transitioned to Proof of Stake (PoS).

Under PoS, the computationally intensive “miners” are gone, replaced by validators. Validators must stake 32 Ether as collateral. They are selected through a pseudorandom algorithm to propose new blocks, which are then attested to by committees of other validators. Validators who act honestly receive Ether as a reward; those who act maliciously or go offline have their staked Ether slashed.

1.2 Fork Choice and Consensus Mechanism (Gasper)

As mentioned earlier, Ethereum is a state machine shared by nodes around the world, and its state must be unique. Having multiple states (or multiple chains) would break the system. If the chain forks, you might have 10 coins on one chain, 20 on another, and 40 on yet another. In this scenario, there would be no way to determine which chain is the most “valid.”

Whenever multiple paths arise, a “fork” occurs. We generally want to avoid forks because they disrupt the system and force people to choose which chain they trust.

In the PoW era, Ethereum used the GHOST protocol (Greedy Heaviest Observed Subtree) to select the path on which the most computation had been completed, preventing multiple chains from forming. After the 2022 “Merge,” responsibility for determining the canonical chain passed to validators, and Ethereum adopted a consensus mechanism called Gasper.

Gasper combines two components:

LMD-GHOST fork-choice rule: Nodes always choose as the canonical chain the branch with the greatest validator voting weight (that is, the most stake).

Casper FFG finality mechanism: Ensures that once a block has been finalized by the network, it has “absolute finality” and cannot be rolled back or altered, eliminating the risk of potential chain reorganizations that existed in the old PoW era.

2 Accounts

An Ethereum account is an entity with an Ether (ETH) balance that can send transactions on Ethereum. An account can be controlled by a user or deployed as a smart contract.

There are two types of Ethereum accounts:

Externally owned accounts: Controlled by private keys and have no code associated with them.

Contract accounts: Controlled by their contract code and have code associated with them.

Both types of accounts can receive, hold, and send ETH and tokens, and interact with deployed smart contracts.

An externally owned account can send a message to another externally owned account or a contract account. A message sent between two externally owned accounts is simply a transfer of value. However, a message from an externally owned account to a contract account activates the contract account's code, allowing it to perform various actions (such as transferring tokens, writing to internal storage, minting a new token, performing computations, or creating a new contract). A contract account cannot initiate a transaction on its own. Therefore, every action on Ethereum is ultimately initiated by a transaction triggered by an externally owned account.

An Ethereum account has four fields:

nonce: A counter showing the number of transactions sent from the account, ensuring that each transaction is processed only once. For a contract account, this number represents how many contracts the account has created.

balance: The amount of Wei owned by this address. Wei is the unit used to denominate Ether: 1 Ether = 10^18 Wei.

storageRoot: Also known as the storage hash, this is the hash of the root node of the Merkle Patricia tree.

codeHash: The hash of this account's EVM code. For a contract account, the code is hashed and stored as codeHash. For an externally owned account, the codeHash field is the hash of an empty string.

For a long time, Ethereum strictly distinguished between externally owned accounts (EOAs) and contract accounts. But this created a high barrier to entry for users: they had to safeguard their private keys and hold ETH to pay Gas fees. The ERC-4337 standard, deployed in 2023, introduced “account abstraction,” allowing a user's account to be a smart contract by default.

This brought a revolutionary upgrade to the user experience: social recovery is supported (if you lose your private key, you can recover your account through friends), tokens such as USDT can be used to pay Gas fees, and transactions can even be batched (authorizations and swaps completed with one click). The Pectra upgrade in May 2025 went further: EIP-7702 allows traditional EOAs to temporarily delegate code and execute logic like smart contracts, bringing account abstraction capabilities to legacy accounts. Account abstraction is blurring the line between EOAs and contract accounts, and is key infrastructure for Ethereum's journey toward widespread Web3 adoption.

3 Blocks

All transactions are grouped into a “block.” A blockchain consists of a series of blocks linked together in this way.

3.1 Block Header

Each block has a “header” containing the following fields:

parentHash: The hash of the parent block header (this is also what makes a block a part of a blockchain)

beneficiary (now more commonly called feeRecipient): The account address that receives this block's priority fees

stateRoot: The hash of the root node of the state tree

transactionsRoot: The hash of the root node of the Merkle tree containing all transactions in this block

receiptsRoot: The hash of the root node of the Merkle tree containing the receipts for all transactions in this block

logsBloom: A Bloom filter composed of log data

prevRandao: A random value provided by the Beacon Chain (replaced mixHash after the Merge)

number: The current block number (the genesis block is numbered 0, and the number increases by 1 for each subsequent block)

gasLimit: The current gas limit for each block

gasUsed: The total amount of gas used by transactions in this block

timestamp: The Unix timestamp at which this block was created

baseFeePerGas: The base fee per unit of gas for this block (introduced with the 2021 London upgrade / EIP-1559)

withdrawalsRoot: The hash of the root node of the Merkle tree containing validator staking withdrawal data (introduced with the 2023 Shanghai upgrade)

blobGasUsed / excessBlobGas: Records Blob data usage (introduced with the 2024 Cancun upgrade)

parentBeaconBlockRoot: The root hash of the parent Beacon block, allowing the EVM to access Beacon Chain state (introduced with the Cancun upgrade)

requestsHash: The hash of various execution-layer requests (deposits, withdrawals, and validator consolidations) (introduced with the 2025 Pectra upgrade)

extraData: Additional data associated with this block

Note: After the Merge, some fields from the PoW era became obsolete—mixHash was replaced by prevRandao, while ommerHash, difficulty, and nonce remain as placeholders in the protocol but have been fixed at constant values and no longer serve any practical purpose. The classic block-header diagram below uses the old layout and does not reflect these changes.

Each block contains three tree structures, corresponding to:

State (stateRoot)

Transactions (transactionsRoot)

Receipts (receiptsRoot)

3.2 MPT Trees

Ethereum uses a Merkle Patricia Tree (MPT) data structure for storage. An MPT is an improved data structure that combines the advantages of both Merkle trees and prefix trees. It is an important data structure in Ethereum for managing account data and generating hashes for sets of transactions.

The efficiency of information storage in MPTs is especially useful for Ethereum “light clients” and “light nodes.” Broadly speaking, Ethereum has two types of nodes: full nodes and light nodes.

Full nodes sync by downloading the entire chain, from the genesis block to the current block, and executing all transactions it contains. Validators typically run full nodes, since both validation and block production require complete state data.

Rather than downloading and storing the entire chain and executing all its transactions, light nodes download only the chain's headers, from the genesis block to the current block. They do not execute any transactions or retrieve any associated state. Because light nodes can access block headers, which contain the root hashes of the three MPT trees, they can still easily generate and receive verifiable information about transactions, events, balances, and more.

This works because hashes propagate upward through an MPT: if a malicious user tries to replace a transaction at the bottom of the MPT with a fake one, this changes the hash of the node above it. That change also alters the hash of the next node up, and so on, all the way to the root of the tree.

In short, the advantage of using MPTs is that the hash of the root node depends on the data stored in the tree, and the root hash can serve as a secure identifier for that data. Since a block header contains the root hashes of the state tree, transaction tree, and receipt tree, any node can verify a small part of Ethereum's state without storing the entire state, which can be extremely large.

Although MPTs have performed well over the past few years, as Ethereum's state data has grown to hundreds of gigabytes, MPT proofs have become too large, pushing up the hardware requirements for running a full node. To address this, Ethereum's roadmap plans to migrate the data structure from MPTs to Verkle Trees during “The Verge” phase.

Verkle trees combine the advantages of Vector Commitments and Merkle trees, reducing the size of cryptographic proofs (witnesses) by more than an order of magnitude. This will allow even phones and very low-spec computers to run Ethereum “Stateless Clients” with ease, bringing true, extreme decentralization. Note that as of 2026, the Verkle migration is still under development and has not yet been scheduled for a confirmed hard fork.

3.3 Block Production Times and Cadence (Slots & Epochs)

In the Proof of Work (PoW) era, block production times were probabilistic (averaging about 13–15 seconds) and adjusted dynamically based on mining difficulty. Under today's Proof of Stake (PoS) mechanism, however, the passage of time on Ethereum is as precise as a clock.

Ethereum divides time into fixed units:

Slot: Each slot is fixed at 12 seconds. This is the time window in which the system attempts to create a new block. During each slot, the system pseudorandomly selects a validator to propose a block, while the other validators attest to it.

Epoch: Every 32 slots make up an epoch, or 6.4 minutes. An epoch is the basic cycle in which the system settles validator rewards and penalties, shuffles (reassigns validator duties), and achieves block “finality.”

This fixed-cadence design makes the Ethereum network more predictable: validator rotation duties, transaction confirmation times, and the settlement of rewards and penalties all follow a clear rhythm.

4 Gas and Fees

One important concept in Ethereum is fees: every computation performed by a transaction on the Ethereum network incurs a fee. These fees are paid in Gas.

Gas is a unit used to measure the cost of a specific computation. Wei is the smallest unit of Ether: 1 Ether = 10^18 Wei. The price of gas is usually measured in gwei: 1 gwei = 10^9 Wei.

Ethereum's fee market changed fundamentally after the 2021 London upgrade (EIP-1559). Transaction fees now consist of two parts:

Base Fee: Automatically calculated by the protocol based on congestion in the previous block and applied uniformly to all transactions in the same block. This fee is not paid to validators; it is burned by the network.

Priority Fee / Tip: An optional additional fee that users pay to the block proposer (validator) to incentivize them to include their transactions first.

Therefore, when sending a transaction, users no longer set a single gasPrice. Instead, they set maxFeePerGas (the maximum total price they are willing to pay per unit of gas) and maxPriorityFeePerGas (the maximum tip they are willing to offer). Each transaction must still set a gasLimit, which is the maximum amount of gas the sender is willing to pay for executing the transaction.

For example, suppose the sender sets a gasLimit of 50,000 and a maxFeePerGas of 20 gwei. This means the sender is willing to pay up to 50,000 × 20 gwei = 1,000,000,000,000,000 Wei = 0.001 Ether to execute the transaction.

The actual price paid per unit of gas is min(maxFeePerGas, Base Fee + maxPriorityFeePerGas). If the user's account has enough Ether to cover this maximum fee, there is no problem; at the end of the transaction, any unused gas is refunded to the sender.

If the sender does not provide enough gas to execute a transaction, execution runs out of gas and the transaction is considered invalid. In this case, processing is halted, all state changes are reverted, and the state returns to exactly what it was before the transaction—as if the transaction had never happened. Since the machine has already performed computation before running out of gas, in theory, no gas is refunded to the sender.

So where does all this gas money go?

Base Fee: Permanently burned and removed from the total ETH supply. When on-chain activity is high, the amount burned can even push ETH into a deflationary state.

Priority Fee: Paid to the validator who successfully proposed the block (the equivalent of a “miner” in the old system). The proposer receives this reward in return for the computational and bandwidth costs of including, executing, and validating transactions.

In general, the higher the priority fee a sender is willing to pay, the more value a validator can earn from the transaction, making the validator more likely to include it first. Validators can freely choose which transactions to validate or ignore; the priority fee is a bid for that right to choose.

What purpose do Ethereum's fees serve?

First, an important aspect of how Ethereum works is that every operation executed by the network is also repeated by every full node. However, computation is very expensive on the Ethereum Virtual Machine. Ethereum smart contracts are therefore best suited to simple tasks, such as running basic business logic or verifying signatures and other cryptographic objects, rather than complex operations like file storage, email, or machine learning, which would put pressure on the network. Fees help prevent the network from becoming overloaded.

Second, Ethereum's smart contract language is Turing-complete (in brief, a Turing machine is a machine that can simulate any computer algorithm), which means that code can contain loops. Without fees, malicious actors could cripple the network by executing a transaction containing an infinite loop. Fees therefore also protect the network from deliberate attacks.

Third, Gas is used not only to pay for computation, but also for storage. The total storage cost is proportional to the size of the data, incentivizing users to minimize the amount they store. Expanding storage increases the size of the Ethereum state database on every node, a cost that the entire network must bear.

5 Transactions and Messages

Ethereum is a transaction-based state machine. In other words, transactions between different accounts are what move Ethereum's global state from one state to another.

A transaction is a cryptographically signed instruction generated and serialized by an externally owned account, then submitted to the blockchain. Transactions fall into two types: message calls and contract creations.

All transactions contain the following components, regardless of type:

nonce: A counter for the number of transactions sent by the sender

gasPrice: The amount of Wei the sender is willing to pay for each unit of gas required to execute the transaction. Since EIP-1559, it has gradually been replaced by maxFeePerGas and maxPriorityFeePerGas (see Section 4)

gasLimit: The maximum amount of gas the sender is willing to pay for executing the transaction. This amount is deducted in advance, before any computation is performed

to: The recipient's address. In a contract creation transaction, the contract account does not yet exist, so this field is empty

value: The amount of Wei transferred from the sender to the recipient. In a contract creation transaction, value is the initial balance of the new contract account

v, r, s: The signature values used to identify the transaction sender

init: Present only in contract creation transactions. This is a snippet of EVM code used to initialize the new contract account. The init value runs once and is then discarded. When init runs for the first time, it returns a runtime code body, which is the code permanently associated with the contract account

data: An optional field present only in message calls, containing the input data (that is, the parameters). For example, if a smart contract is a domain name registration service, a call to the contract might expect the domain name and IP address as input parameters

Whether a transaction is a message call or a contract creation, it is triggered by an externally owned account and submitted to the blockchain. In other words, a transaction is the bridge between the outside world and Ethereum's internal state.

However, this does not mean that one contract cannot communicate with another. Contracts within Ethereum's global state can communicate with one another. They do so through “messages” or “internal transactions.” When one contract sends an internal transaction to another, the code associated with the recipient contract's account is executed.

One important thing to note is that internal transactions, or messages, do not include a gasLimit. The gas limit is determined by the creator of the original external transaction (that is, the externally owned account). The external account must set a gas limit high enough to complete the transaction, including any “sub-executions” it triggers, such as messages between contracts.

As Ethereum established its “Rollup-centric” scaling roadmap, Layer 2 networks needed to publish large amounts of data to the mainnet to ensure security. Previously, this data could only be squeezed into expensive regular transactions, taking up calldata.

The Cancun upgrade in March 2024 introduced a new transaction type: Blob transactions (Type 3 transactions). A Blob (Binary Large Object) is temporary storage designed specifically to carry large amounts of data. Its key feature is that data is kept on-chain for only about 18 days, after which nodes automatically discard it, so it does not permanently increase the burden on Ethereum's state. This innovation reduced Layer 2 transaction fees by more than 90%, marking Ethereum's official entry into the era of low-cost applications.

The Fusaka upgrade in December 2025 introduced PeerDAS (Peer Data Availability Sampling), increasing Blob data capacity by roughly another order of magnitude and further reducing Layer 2 costs.

6 Ethereum Virtual Machine

The Ethereum protocol itself exists solely to keep this particular state machine running continuously and immutably.

The Ethereum Virtual Machine is the environment in which all Ethereum accounts and smart contracts operate. At any given block on the chain, Ethereum has one and only one “canonical” state, and the Ethereum Virtual Machine defines the rules for computing a new valid state from one block to the next.

Blockchains such as Bitcoin are often described by analogy to a “distributed ledger.” Ethereum also has its own native cryptocurrency (ETH), which follows almost exactly the same rules, but it also supports a more powerful feature: smart contracts. So Ethereum is not merely a distributed ledger; it is more accurately described as a distributed state machine.

Ethereum's state is a huge data structure called an MPT. It stores not only all accounts and balances, but also a machine state that can change between blocks according to a predefined set of rules and execute arbitrary machine code. The specific rules for changing state within a block are defined by the EVM.

The EVM operates as a stack machine with a stack depth of 1,024 items. Each item is a 256-bit word; 256-bit cryptography was chosen for ease of use.

The EVM has memory, which stores entries in word-addressed byte arrays. Memory is volatile and does not persist between transactions.

The EVM also has storage. Unlike memory, storage is non-volatile and maintained as part of the system state. The EVM stores program code independently in a virtual ROM, which can be accessed only through special instructions. This is how the EVM differs from a typical von Neumann architecture, in which program code resides in memory or storage.

The EVM also has its own language: EVM bytecode. When programmers write smart contracts on Ethereum, they usually use a high-level language such as Solidity. The code can then be compiled into EVM bytecode so the EVM can understand and execute it.

Compiled smart contract bytecode is executed as a series of EVM opcodes, which perform standard stack operations such as XOR, AND, ADD, and SUB. The EVM also implements blockchain-specific stack operations such as ADDRESS, BALANCE, and BLOCKHASH.

Although the EVM has been extremely successful, its underlying bytecode format has undergone almost no structural optimization since its creation, resulting in inefficient code parsing and a greater risk of vulnerabilities. Ethereum developers are working on the EOF (EVM Object Format) upgrade, which will introduce an explicit “container” structure for smart contracts, separating code sections, data sections, and type information. This could reduce the Gas cost of contract deployment and fundamentally eliminate certain types of jump vulnerabilities, making audits safer. However, because of the broad scope of the change, EOF was once planned for the Fusaka upgrade at the end of 2025, but was ultimately removed due to timeline risks. As of 2026, it has not been deployed in any hard fork.

In addition, although Solidity remains the dominant language, the EVM ecosystem is becoming more diverse. The security-focused Vyper language and efforts to run Rust/C++ compiled code using the RISC-V architecture are continually expanding the capabilities of the Ethereum Virtual Machine.

Follow me so you don't miss the next quick market update.