Execution latency

In this entry, execution latency is the end-to-end elapsed time from submitting a signed blockchain transaction to a node until it has been executed and its containing history meets the stated finality criterion—the rule for treating that history as settled. It includes communication and waiting; execution-only processing time covers only the time spent running the transaction’s instructions.

A reported execution latency must identify the observer, such as the submitting client, and the finality or confidence rule used to stop the clock. Transaction creation, signing, wallet interaction and later notifications belong only in an explicitly broader measurement.

In cross-chain usage, execution latency can instead mean the time from source-chain submission until a message reaches its final state on the destination chain; confirmation and finality settings affect that wait. Comparisons must identify the workflow and endpoints.

How a Transaction Reaches Finality

On Ethereum’s public-submission path, a client submits an already signed transaction to a node, which checks validity. A valid transaction enters that node’s mempool—a local pending-transaction pool—and is broadcast to peers, which add it to their own pools. Not every submission uses a public pool, and admission guarantees neither inclusion nor finality.

At a scheduled proposal opportunity, the selected block producer chooses pending transactions within the available block capacity. It executes the chosen transactions while constructing a block, computing their outcomes and proposed state changes, then broadcasts the block. Unselected transactions can remain pending. Inclusion means appearing in a block; execution means running the instructions to compute an outcome.

Receiving nodes re-execute the block’s transactions to verify the proposed state change. Validators vote for a valid block consistent with their view of the chain and record it locally; this acceptance is not yet finality. Execution therefore occurs during both block construction and verification, not as one universally separate serial stage. A confirmation is a protocol- or application-defined acceptance or confidence milestone, not necessarily finality.

On Ethereum, validators cast stake-weighted votes on pairs of checkpoints, designated blocks marking chain progress. Votes representing at least two-thirds of total staked ETH justify the newer checkpoint and finalize the earlier, already justified one. This endpoint covers that earlier checkpoint and its ancestors on the same chain, with economic protection under protocol assumptions rather than absolute irreversibility.

In systems with immediate finality at commitment, nodes use their consensus rules to agree on transaction order and validate the block, then apply and record it across the relevant network. That commitment is the finality endpoint, without a mandatory extra confirmation wait.

On a probabilistic-finality path, a producer publishes the transaction in a block, but competing blocks may appear. Nodes resolve forks by adopting the winning history under their consensus rules; current inclusion is not an unconditional guarantee against reversal. As later blocks extend that history, the observing client waits until a disclosed confirmation or confidence rule is met, with residual reversal risk.

Inclusion or finality does not prove application success: finalized history can contain a failed execution. Consider a hypothetical contract accepting actions only in blocks timestamped from opening through closing. A transaction submitted before closing can still execute too late and fail. The window governs execution; later finality can occur after closing. Actual deadlines and extensions are application-specific.

What Affects the Delay

Congestion arises when demand competes for finite block capacity, leaving transactions waiting for selection. More complex transactions can require more processing and consume more capacity. Ethereum measures computational work in gas, not seconds; the amount of gas is also distinct from its price. Complexity therefore does not imply a fixed additional delay.

Fees can influence selection where the protocol supports them. On Ethereum, the offered price per gas must cover the base fee, the protocol-required minimum, before priority matters. A higher effective tip, an extra payment incentivizing selection, can improve the chance of inclusion. Raising a fee cap, the maximum authorized price per gas, does not necessarily increase that tip.

Network propagation latency measures only the communication component of execution latency. Throughput instead measures valid transactions committed per unit time across the measured network, not submissions or one node’s execution speed. Higher throughput need not reduce individual waiting. Comparisons require compatible workloads, network scope, commitment rules and observation points.

Limits of Reducing Latency