Network
Launch Date
Consensus
Note
Sepolia
Oct 2021
PoW
Like-for-like representation of Ethereum
Görli
Jan 2019
PoA
Proof-of-Authority
Kiln
Mar 2022
PoS
Post-Merge (for ETH2), shadow fork of the mainnet
Kintsugi
Dec 2021
PoS
DEPRECATED, use Kiln; post-Merge (for ETH2)
Ropsten
Nov 2016
PoW
DEPRECATED, use Sepolia; the Merge to happen on Jun 8, 2022
Rinkeby
Apr 2017
PoA
DEPRECATED, use Görli and Görli Faucet
Kovan
Mar 2017
PoA
DEPRECATED, use Sepolia or Görli
List of active and deprecated Ethereum testnets, including Kintsugi.
Features
Optimistic rollup 
ZK-rollup 
Proof
Uses fraud proofs to prove transaction validity. 
Uses validity (zero-knowledge) proofs to prove transaction validity. 
Capital efficiency
Requires waiting through a 1-week delay (dispute period) before withdrawing funds. 
Users can withdraw funds immediately because validity proofs provide incontrovertible evidence of the authenticity of off-chain transactions. 
Data compression
Publishes full transaction data as calldata to Ethereum Mainnet, which increases rollup costs. 
Doesn't need to publish transaction data on Ethereum because ZK-SNARKs and ZK-STARKs already guarantee the accuracy of the rollup state. 
EVM compatibility
Uses a simulation of the Ethereum Virtual Machine (EVM), which allows it to run arbitrary logic and support smart contracts. 
Doesn't widely support EVM computation, although a few EVM-compatible ZK-rollups have appeared. 
Rollup costs
Reduces costs since it publishes minimal data on Ethereum and doesn't have to post proofs for transactions, except in special circumstances. 
Faces higher overhead from costs involved in generating and verifying proofs for every transaction block. ZK proofs require specialized, expensive hardware to create and have high on-chain verification costs. 
Trust assumptions
Doesn't require a trusted setup. 
Requires a trusted setup to work. 
Liveness requirements
Verifiers are needed to keep tabs on the actual rollup state and the one referenced in the state root to detect fraud. 
Users don't need someone to watch the L2 chain to detect fraud. 
Security properties 
Relies on cryptoeconomic incentives to assure users of rollup security. 
Relies on cryptographic guarantees for security. 
Start building
on Alchemy.
Sign up for free
Start building on Optimism.
Sign up for free
Start building on Arbitrum.
Sign up for free
Start building on Ethereum.
Sign up for free
Start building on Polygon.
Sign up for free
Start building on Starknet.
Sign up for free
Start building on Flow.
Sign up for free
kiln faucet
Get free Kiln ETH.
Start building today
Goerli faucet
Get free Goerli ETH.
Start building today
mumbai faucet
Get free Mumbai Matic.
Start building today
rinkeby faucet
Get free Rinkeby
ETH.
Start building today
Start building on Ethereum.
Get started for free
Start building on Ethereum.
Get started for free
Start building on Flow.
Get started for free
Start building on Polygon.
Get started for free
Start building on Starknet.
Get started for free
Start building on Optimism.
Get started for free
Start building on Solana.
Get started for free
Start building on Solana.
Sign up for beta access
Start building on Solana.
Join the waitlist
Arbitrum logo
Start building on Arbitrum.
Get started for free
curl 
https://release.solana.com/v1.10.32/solana-install-init-x86_64-pc-windows-msvc.exe 
--output 
C:\solana-install-tmp\solana-install-init.exe 
--create-dirs
Ethereum
TRANSACTION PROPAGATION OVERVIEW

How are blockchain transactions broadcast?

Learn How Ethereum Transactions are Propagated Across the Ethereum Network
Last Updated:
September 7, 2022

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 miners (and block producers after The Merge) can find and mine pending transactions in the mempool.

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

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

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 mined, 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?

After The Merge, which is expected to be around September 14th when the Total Terminal Difficulty (TTD) hits 58750000000000000000000, Ethereum nodes will 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 after 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.

ALCHEMY SUPERNODE - ETHEREUM NODE API

Scale to any size, without any errors

Alchemy Supernode finally makes it possible to scale blockchain applications without all the headaches. Plus, our legendary support will guide you every step of the way.

Get started for free
Supernode footer
Ethereum
TRANSACTION PROPAGATION OVERVIEW

How are Ethereum transactions propagated (broadcast)?

Learn How Ethereum Transactions are Propagated Across the Ethereum Network
Last Updated:
September 7, 2022
Don't miss an update
Sign up for our newsletter to get alpha, key insights, and killer resources.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

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 miners (and block producers after The Merge) can find and mine pending transactions in the mempool.

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

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

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 mined, 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?

After The Merge, which is expected to be around September 14th when the Total Terminal Difficulty (TTD) hits 58750000000000000000000, Ethereum nodes will 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 after 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.

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 miners (and block producers after The Merge) can find and mine pending transactions in the mempool.

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

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

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 mined, 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?

After The Merge, which is expected to be around September 14th when the Total Terminal Difficulty (TTD) hits 58750000000000000000000, Ethereum nodes will 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 after 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.

Build blockchain magic with Alchemy

Alchemy combines the most powerful web3 developer products and tools with resources, community and legendary support.

Get started for free