Nodes, mining & validator operations

transaction propagation

Transaction propagation is how a freshly signed transaction spreads from the one node that first received it to the rest of the network, until it reaches the block producers who can include it. There is no central server to upload to; instead each node tells its handful of directly connected peers, who tell their peers, and so on, in a flood that fans out across the whole peer-to-peer graph in a second or two. This is a gossip protocol: information ripples outward like a rumor through a crowd.

Naively, a node could just push every transaction's full bytes to every peer, but that wastes enormous bandwidth because peers often already have it. So modern networks 'announce then fetch.' In Ethereum's devp2p protocol a node first sends only the transaction hashes it has heard of; a peer that has not seen a given hash responds by requesting the full transaction. Bitcoin uses the same idea with inv (inventory) messages followed by getdata. This dramatically cuts duplicate traffic at the cost of one extra round trip.

Propagation is not instantaneous or uniform, and that asymmetry has real consequences. A transaction reaches nodes near its origin before distant ones, so different parts of the network briefly hold different mempools. Block producers with superior connectivity (or who pay for private feeds and relays) see profitable transactions sooner, which is part of how MEV searchers gain an edge. Latency also drives block propagation races: in proof-of-work, a miner who learns of a new block late may waste effort mining on a stale tip, which is why low-latency relay networks were built.

Propagation has a privacy dimension too. Because a transaction originates at one node and spreads outward, an adversary running many well-connected listening nodes can sometimes infer which node first announced a transaction and thus guess the sender's IP — a deanonymization vector. Protocols mitigate this with randomized peer selection and diffusion techniques (Bitcoin's Dandelion proposal, for instance, first routes a transaction along a single private 'stem' path before broadcasting it widely) so the true source is harder to pin down.

A node hears a new transaction and sends its 32-byte hash to its 50 peers. The 30 peers that already have it stay silent; the 20 that do not each reply 'getdata,' and the node ships them the full ~200-byte transaction. The hash ripples outward and the full bytes follow only where needed.

Propagation is a gossip flood, not a broadcast to one server — which is why latency, connectivity, and peer count materially affect who sees a transaction first and who can exploit it.