One Block,Two Worlds

Once a wallet signs a transaction, it propagates across the peer-to-peer network. Different nodes can receive different transactions, in different orders, at different times. Each node’s transaction pool—or mempool—is therefore a set of candidate requests, not settled public history.

Suppose Alice has only 5 ETH and broadcasts “send Bob 5 ETH” and “send Carol 5 ETH” almost simultaneously. Both signatures may be authentic, but both transfers cannot succeed. Nodes must first agree on execution order before they can derive one result. A block’s first job is to turn a batch of candidates into a strictly ordered sequence.

Its second job is to define a clean boundary around a state transition. Starting from the same prior state, nodes replay transactions and protocol-level operations in block order, derive the next state, and record key results as root commitments. No one needs to trust the block builder’s word: every execution node can recompute the answer for itself.

In everyday speech, “an Ethereum block” may mean the beacon block, or it may mean the execution block shown by a block explorer. These are not two unrelated chains; they are two protocol views of the same Ethereum.

The consensus layer answers: “Which slot is this? Who proposed it? Which parent beacon block does it follow? Which branch do validators recognize?” The execution layer answers: “In what order do these transactions run? How much gas do they consume? What account and contract state results?” The beacon block’s body carries an execution_payload, fastening the two together.

Also separate the beacon block header from the full beacon block

The compact BeaconBlockHeader contains only slot, proposer_index, parent_root, state_root, and body_root. A full BeaconBlock carries the body itself; SignedBeaconBlock then wraps the message with the proposer’s BLS signature.

What is commonly called the beacon-block root is the SSZ hash_tree_root of the block message; the outer signature is not part of that root. By contrast, today’s execution-block hash is Keccak-256 over the RLP-encoded execution header.

The execution block body stores full transactions and withdrawals. The execution header does not duplicate that data; it stores root commitments instead. Think of the header as a table of contents, tamper-evident seal, and protocol-parameter sheet combined.

As of July 2026, after Fusaka and BPO2, the mainnet execution header contains 21 fields. You do not need to memorize them all at once. Start with the parent hash, three essential roots, block number, timestamp, and gas; then place the later withdrawal, blob, and request commitments on the same map.

Why retain PoW fields that are no longer “used”?

The Merge changed the consensus mechanism without redesigning the execution header from scratch. The positions of difficulty, nonce, and ommers_hash remain, but protocol rules constrain them to fixed values. The old mixHash position acquired a new meaning as prev_randao. This approach reduced disruptive changes to serialization and clients.

A consensus-layer beacon block has no top-level timestamp; it has a slot. The execution payload’s timestamp must equal the protocol time assigned to that slot.

A new slot begins every 12 seconds, but its proposer may be offline, propagation may be late, or the proposed block may not be accepted. That slot can therefore remain empty. When the next block actually appears, slot and timestamp skip over the gap, while the execution-block number still rises by only one from the previous actual block.

A transaction typically expresses who authorized it, which address to call, how much value to transfer, what data to carry, the maximum gas it may use, and the fees it is willing to pay. Exact fields depend on the transaction type, but all of them must ultimately become canonical serialized bytes.

Common current types include type 0 legacy transactions, type 1 access-list transactions, type 2 EIP-1559 transactions, type 3 blob transactions, and type 4 EIP-7702 set-code transactions. EIP-2718 gives us this unifying envelope model:

Why is order itself data?

The execution block’s transaction list has a strict order. A node uses each transaction’s in-block index as the trie key and builds the transaction Merkle-Patricia Trie. Even if two transactions remain byte-for-byte unchanged, swapping their positions changes transactions_root.

Order also changes meaning. Two calls may compete for the same balance, nonce, market price, or NFT. The transaction root commits to which inputs exist and the order in which they enter execution; the EVM then computes results in that same order.

After receiving a block, a node does not merely check that “the transaction root looks like a hash.” It rebuilds the transaction trie according to the specification, replays every transaction, creates receipts, updates state, and compares all three locally computed roots to the header. If any one differs, the block is invalid.

Why is logsBloom not a fourth “exact root”?

logs_bloom is a 2,048-bit fast filter used to ask whether an address or event topic “may be present.” It permits false positives, so it can only narrow a search. To confirm the actual logs, a node must still inspect and verify transaction receipts. receipts_root is the cryptographic commitment to the complete receipt set.

A root hash does not encrypt the underlying data

Hashing does not hide transaction contents. Public nodes can still read the transaction bytes. A root provides a compact commitment that exposes differences and supports membership proofs. Privacy and commitment are separate concerns.

Altering a transaction changes at least transactions_root. Re-execution will usually also change receipts_root, state_root, gas_used, and logs. Once the header changes, the block hash changes; the old parent_hash recorded by the next block immediately stops matching.

Why does “the hash changed” not mean “history is absolutely immutable”?

Anyone can locally alter an old block’s bytes and recompute that block’s hash and every successor link. That alone does not create a valid competing history. Honest nodes already retain the original history, consensus rules determine which branch is canonical, validator votes and economic penalties raise the cost of rewriting, and finality makes finalized checkpoints extremely difficult to revert.

Keep four judgments separate: hash-consistent means only that content matches its fingerprint; valid means the block obeys the protocol and executes correctly; canonical means fork choice currently selects it; finalized means another branch will not replace it under normal protocol conditions.

A block producer supplies a candidate answer. A node rechecks the structure, parent relationships, transaction signatures, execution process, and root commitments. If any essential commitment disagrees, the entire block is invalid.

Why not memorize a single field list?

Fields evolve with hard forks, and names retain historical traces for compatibility. A more durable approach is to classify responsibilities: link history, commit to contents, commit to execution results, constrain resources, connect the layers, preserve compatibility. When a future field appears, you can first ask which responsibility it serves.

Why do execution-layer RLP and consensus-layer SSZ coexist?

Ethereum’s execution layer inherited its early RLP and Merkle-Patricia Trie systems. The beacon chain was designed around SSZ and SSZ Merkleization from the start. The two meet through the Engine API and the execution payload. This is why “hashing” cannot be reduced to one universal formula: different objects, serialization schemes, and hash-tree rules produce roots with different meanings.