Ethereum Block

An ordered computation that every node can check.

A contract stores x = 1. Alice sends a transaction that adds 2; Bob sends one that multiplies by 3. Alice first gives 9. Bob first gives 5. Both calls can be valid, yet their order changes the result.

A block specifies that order, names the parent it builds on, and commits to the resulting state. Other nodes execute the same work to check the claim.

Block Replay

Order

+2 → ×3×3 → +2

Claim

CorrectTampered

Parent

x

1

Tx 1

+ 2

—

Tx 2

× 3

—

Claim9

·

Replay—

0 / 2

Execute

From transactions to state

The state is Ethereum’s current account data: balances, nonces, contract code and storage. Each transaction reads and changes that state. The next transaction starts where the previous one finished.

For a block with transactions $T_1, \ldots, T_k$:

$$S_0 \xrightarrow{T_1} S_1 \xrightarrow{T_2} \cdots \xrightarrow{T_k} S_k$$

Here $S_0$ comes from the parent block. Execution also depends on block context, such as the timestamp, and fork-specific system operations. Replaying a real block includes those rules, not just the transaction loop.

Changing the order creates a different candidate block. It can still be valid if its commitments match its execution. Keeping an old commitment after changing the result makes it invalid.

What a block commits to

A root is a cryptographic summary of structured data. A node recomputes it and compares it with the published value; the root does not contain the data needed to execute the block.

These execution-header fields answer different questions:

A transaction hash identifies one transaction. A block hash identifies the execution header, which in turn commits to the roots above and other header fields. Editing an ancestor changes its hash, breaking the references in its descendants.

These are the execution-layer / JSON-RPC names. The consensus-layer execution payload carries the transaction list directly; it does not carry an identically shaped execution header. See the block structure reference for the two views.

A failed call can belong to a valid block

Suppose a contract call reaches revert. Its contract changes are rolled back, but the included transaction still consumes gas and advances the sender’s nonce. Its receipt records failure.

That is different from an invalid transaction or an incorrect block commitment. A valid block may contain failed calls; it cannot pass validation with a state root that disagrees with execution.

The replay above isolates the state comparison. Real validation also checks signatures, nonces, gas constraints, receipts and the other protocol rules.

Where execution fits

An Ethereum node normally runs two cooperating clients:

• The execution client executes transactions and validates execution payloads.
• The consensus client validates consensus rules, processes validator votes and chooses the chain to follow.

The beacon block carries consensus data and an execution payload. Its consensus state_root commits to beacon state, including validator information; the payload’s execution state_root commits to account state. They are different roots over different data.

The clients communicate through the Engine API. A vote cannot make incorrect execution valid. Conversely, valid execution alone does not establish which branch the network will keep.

Where fees fit

Gas measures execution work. For a type-2 transaction, the sender sets a total fee cap and a priority-fee cap. If the total cap covers the block’s base fee:

$$\mathrm{tip}=\min(\mathrm{maxPriorityFeePerGas},\ \mathrm{maxFeePerGas}-\mathrm{baseFee})$$ $$\mathrm{executionFee}=\mathrm{gasUsed}\cdot(\mathrm{baseFee}+\mathrm{tip})$$

The base fee is burned; the priority fee goes to the block’s fee recipient. maxFeePerGas is a ceiling, not necessarily the price paid. Blob transactions also have a separate blob-gas fee. These fee rules come from EIP-1559 and EIP-4844.

Paying more may help inclusion. It does not make an included transaction finalized sooner.

Valid is not yet canonical

Two blocks can extend the same parent, contain different orders, and both pass execution checks. Your node can verify each one. It still needs a rule for choosing which branch to follow.

That is the next question: Ethereum Consensus ⁠.

References

• Execution specifications — transaction processing and block validation.
• Ethereum transactions — execution, gas and transaction types.
• Consensus specifications — beacon blocks and execution payloads.