4.6.2.Transaction to block

Message sequence

1. An execution client receives a transaction from its API or an eth peer.
2. It decodes the typed envelope and checks chain ID, signature, nonce policy, fee fields, size, intrinsic gas, and current fork rules.
3. It adds an acceptable transaction to the local pool and announces its hash, type, and size through NewPooledTransactionHashes.
4. Interested peers request the transaction. The sender returns the network encoding in PooledTransactions in request order, but may omit transactions that left the pool.

5. At proposal time, a local execution client or external builder selects transactions and executes them against the parent state.
6. The consensus proposer obtains a valid payload, puts it in the beacon block or follows the fork's payload-delivery rule, and publishes the block.
7. Other nodes submit the payload to their execution clients. A VALID result makes the transaction part of that branch's executed block.

Failure and recovery

A pool rejection stops local relay but is not a consensus judgment. A peer may omit an unknown or dropped transaction. A builder or local payload may exclude a valid transaction. A reorganization returns eligible transactions from the old branch to local pool policy.

Design rationale

The transaction pool is local policy. Block execution is consensus-critical. The network moves candidates before a proposer fixes one ordered payload.