How are Ethereum transactions propagated (broadcast)?

Written by Alchemy

Reviewed by Brady Werkheiser

Published on 2022-09-077 min read

---

Transactions are the foundational exchange of information and value on a blockchain, and are critical for developers, traders, and hobbyists to understand. Transactions are propagated across Ethereum's decentralized Peer-to-Peer (P2P) network using a variety of networking protocols such as RLPx and the Wire Protocol, to ensure block producers and validators can find pending transactions in the mempool.

This article will cover Ethereum transaction types, and how transactions are broadcast across Ethereum's network of nodes.

What is an Ethereum transaction?

An Ethereum transaction is a contractual process whereby an address sends tokens or assets to another address on the Ethereum network. One simple example of an Ethereum transaction is a person, Alice, who sends 1 ETH, the native token on Ethereum, to their friend Bob.

Because transactions are foundational to building blockchain applications, let's explore the information included in an Ethereum transaction.

What information is included in an Ethereum transaction?

At the programming language level, the sender Alice bears the msg.sender global variable, while the receiver, Bob, bears the address(this) variable, and the amount of tokens that are being sent between the two parties, 1 ETH, is the msg.value.

Apart from the above data, a typical Ethereum transaction would always contain the following details:

• Signature - a stamp of approval of the sender to initialize the transaction

• gasLimit - the highest amount of gas that can be used for the transaction

• Nonce - a unique identifier of the specific transaction

• Data - an optional section for the transaction's description or message

What are the different types of Ethereum transactions?

There are multiple types of Ethereum transactions, including transactions to deploy smart contracts, transactions between entities (i.e. humans), transactions between smart contracts (internal transactions), or a mix of human-smart-contract transactions such as using a DeFi protocol.

For this section, we'll focus on different types of Entity-to-Entity transaction states as they relate to transaction propagation across the Ethereum network.

1. Pooled (Pending) Transactions

Pooled transactions are pending transactions in the mempool that have not been mined (i.e. pending transactions within the local storage of a single node).

When two nodes establish a shared connection, the contents of each node's local pool of transactions are shared so each node has a complete list of pending transactions.

As nodes establish more connections on Ethereum's P2P network, transactions sent to a single node or multiple nodes simultaneously propagate more broadly across the network.

2. Mined Transactions

Mined transactions are completed transactions that have been selected from the global pool of pending transactions (i.e. the mempool), and included in a new block that was added to the blockchain.

Because of chain reorganizations (reorgs), a mined transaction can have one of many commitment levels. Before The Merge, blocks of transactions have a latest commitment level that increments every block (~12 seconds), while after The Merge transactions can additionally be labeled as safe (also called justified) or finalized which are incremented every 32 blocks (~6 minutes).

Safe blocks are blocks that are unlikely to be re-organized, and finalized blocks are extremely unlikely to be reorged.

3. Dropped and Replaced Transactions

A dropped transaction is a pending transaction that was removed from the global mempool. Dropped transactions can occur if the sender's gas fees were too low, or there was an error with the transaction's nonce.

A replaced transaction is a transaction that has the same nonce as an existing transaction in the mempool. Replaced transactions are most typically used when users try to increase the gas price of their original transaction to get it included in the next block. When a replaced transaction is confirmed, the original transaction is dropped.

4. Reinforced Transactions

A reinforced transaction is a new Ethereum transaction type that increases the likelihood of transactions getting validated, especially during periods of high network activity and gas price volatility, by re-propagating transactions to Ethereum nodes.

Reinforced transactions are a solution for failed and dropped transactions.

Additional Transaction Types

Besides, pooled, mined, dropped and replaced, and reinforced transactions, there are other transaction states including:

• Canceled Transactions - a type of replacement transaction that cancels the original transaction

• Confirmed Transactions - a transaction that has been mined and included on the blockchain

• EOA Transactions - a transaction between one or more Externally Owned Accounts (EOAs), typically a person

• Failed Transactions - a transaction that was attempted and didn't succeed

• Internal Transactions - a transaction between two smart contracts

• Private Transactions - a transaction sent directly to a miner, circumventing the public mempool

• Stuck Transactions - a transaction that can't be mined

• Type 0 Transactions - a transaction before EIP-1559 was adopted

• Type 2 Transactions - a transaction that adheres to the EIP-1559 update

How does Ethereum's P2P network work?

In a peer-to-peer network, users are both consumers and suppliers of network resources. But not all P2P frameworks are the same, and so the mechanisms for how information is shared, validated, and broadcast is critical to understanding the Ethereum network as a whole. 

On P2P networks, information is shared and stored via nodes. As of this writing, Ethereum has more than 300,000 full nodes. The following is an outline of how new full nodes are added, the relevant protocols, and the specific functions each node performs to process, verify, and validate new blocks on the Ethereum chain.

1. Nodes Discover One Another

Ethereum uses bootnodes to detect and discover new nodes on the network. Once a new node is willing to connect, it will send the bootnode an initialization request referred to as PING. The bootnode then responds  with a bonding PONG message.

Once this is established, the node queries the bootnode to supply it with a list of other nodes that are nearby.  Because Ethereum organizes nodes as leaves in a binary tree, the notion of distance refers to numerical proximity between any two nodes’s 160-bit IDs. 

The function of the bootnode is complete once the node can connect with available nearby nodes. The task of synchronization is then facilitated by the RPLx protocol.

2. Nodes Establish a Secure Connection

The RPLx protocol facilitates the synchronization of two nodes by allowing for the sending and receiving of packets (i.e. small chunks of data). Packets are dynamically enframed, using RLP encoding, as well as encrypted and authenticated. 

Using RPLx, nodes establish a secure connection and verify one another. Verification requires that both nodes send an authentication message followed by a message that includes the port, the IDs for both client and node, and the protocol and sub-protocol.

Once the nodes have authenticated each other, they can begin communicating using the Wire protocol. These two nodes are now considered peers, and peers are how a node communicates with the entire Ethereum network.

3. Nodes Synchronize State, Blocks, and Exchange Pooled Transactions

At this stage, a new full node on the Ethereum P2P network will harmonize with the state of the entire protocol and begin to exchange data. There is an important distinction that needs to be made here between nodes and clients. Though the terms are often used interchangeably, a client is the software that allows nodes to read blocks and smart contracts on Ethereum’s blockchain. 

All full nodes on Ethereum have three basic tasks with the Wire protocol: 

1. Synchronization

2. Block Propagation

3. Pending Transaction Propagation

3a. Chain and State Synchronization

Synchronization is divided into synchronization with the chain and synchronization with the state.

During synchronization with the chain, peers tender the difficulty rate and hash of their available blocks. The client with the highest difficulty rate downloads the headers of blocks. During state synchronization, on the other hand, peers authenticate the originality of data and download the block state.

3b. Block Propagation

During block propagation, blocks on the Ethereum P2P network are processed and broadcast. Once there is a new block, clients will verify it by sending it to their peers and approving the transactions that are in the block.

After the client has validated and processed the block, the node must broadcast the same to all the full nodes or peers in the network, allowing them an opportunity to contest its validity.

3c. Exchanging Pending (Pooled) Transactions

Miners have the responsibility of adding new blocks to the chain; therefore, all nodes that participated in verification must provide the miners with the processed pending transactions.

To begin this exchange, each peer must send the hashes of the pending transactions it has to one another. Because private transactions are sent directly to miners or block producers, nodes will not be able to discover propagate these types of transactions.

When all these tasks are completed, the miners may now add a new block to the Ethereum chain, and the Wire protocol begins again.

How are Ethereum transactions propagated?

Ethereum transactions are propagated within the entire network when a node signals that there is a new transaction in its collection of pooled transactions, and the peers query to fetch these transactions. 

This is how it happens:

1. The propagating node informs the network of the new transactions by publishing the NewPooledTransactionHashes message.

2. Alternatively, peers can query for these transactions by publishing the GetPooledTransactions message

How do transactions get broadcast after The Merge?

Since The Merge, Ethereum nodes have two separate node clients - an execution layer client and a consensus layer client - with separate responsibilities for handling transactions. In summary, the execution layer client is responsible for executing transactions and validates the state, and the consensus layer client is responsible for receiving and propagating new blocks.

Here's a bit more detail on how transactions operate in a post-merge environment:

Each node's consensus layer client is responsible for receiving, pre-validating, passing the block to the execution layer client, adding the block to the blockchain head once the EL client completes its tasks, and broadcasting over the network.

When the execution client receives a pre-validated block from the node's consensus layer client, it is responsible for executing transactions, validating the block's state, and then sending the validated black back to the consensus layer client.

Apart from these changes, all other modes of operation of the Ethereum P2P network remain the same since The Merge.

How are transactions broadcast when the CL client is also the block producer?

In post-merge Ethereum there will be block producers and block proposers, and how transactions and blocks are propagated after The Merge operate slightly differently when the consensus layer client is also the block producer. For information on this nuanced use case, read the Ethereum Foundation's networking layer docs.

Ethereum Transaction Propagation Summary

Ethereum's global peer-to-peer network requires nodes to find, verify, and securely communicate with each other to broadcast pending (pooled) transactions and newly mined blocks. Using a series of low-level networking protocols such as RLPx and the Wire Protocol, this process of peering and propagating information across Ethereum's global computer makes blockchain transactions possible.