Mitigating Ethereum Chain re-org scenario with Deneb Upgrade

Blob Transactions, Chain Reorgs, Proposed Solutions, Effect on Future Upgrades & EIP-4844 Devnet 5 Updates

Mitigating Ethereum Chain re-org scenario with Deneb Upgrade

A chain reorg isn't ideal but may happen when a blockchain network has to abandon one chain and switch to another one. In standard Ethereum transactions, when a reorg happens, transactions from orphaned blocks are resurrected and returned to the transaction pool. However, with EIP-4844, blob transactions have their blobs discarded from the chain after a certain period. This makes it impossible to resurrect these transactions during a reorg, as the necessary blob data is no longer available. In this blog, we will see how Ethereum will mitigate this issue in the post-Deneb upgrades.

Blob Transactions

Blob transactions are a new type of transaction introduced in Ethereum through EIP-4844 as part of the Dencun upgrade. These transactions are designed to handle more complex and larger data structures, which allows Ethereum to support a wider range of applications and use cases. EIP-4844 introduces transactions with 128KB ephemeral data blobs, which are dropped after one month, resulting in zero long-term storage usage. To manage block space, EIP-4844 caps the number of data blobs per block.

Chain Reorgs

Chain reorganization happens when a blockchain undergoes a temporary fork and later abandons the shorter chain for the longer one. As more blocks are added, one chain becomes longer than the other, and the network eventually adopts the longer chain as the main one. Transactions on the abandoned chain are either reinserted into the main chain or dropped if they are invalid or already included in the main chain. Since blob transactions are decoupled from regular transactions, reconstructing them after a chain reorg might only be possible using transactions seen in the public mempool.

However, many transactions, such as MEV transactions and bundles, bypass the mempool. As blob transactions are not fully bundled in blocks, their storage and retrieval become more complex during syncing. The nodes need to ensure they have access to the necessary blob data when reconstructing the blockchain state. To facilitate the resurrection of transactions during reorgs, the network could store blob data for longer periods, though this may negate some of the storage benefits provided by EIP-4844.

Proposed Solutions

Core developers have proposed two solutions to mitigate this issue:

  1. Passing blob data from CL to EL: One way to ensure that all blob transactions can be reconstructed, even those bypassing the mempool, is to have the consensus layer (CL) pass the blob data for every block to the execution layer (EL). The EL can then cache this data until the block is finalized.
  2. Resubmitting transactions: Another solution is to require users who have submitted transactions bypassing the mempool to resubmit their transactions in the event of a chain reorg.

Effect on Future Upgrades

Péter Szilágyi prefers the first solution, which involves communicating the blob data to the EL, even though it may increase the load on the EL. However, this solution could break down the abstraction between the EL and CL layers and reinforce the assumption that nodes store full copies of blob data. This could become an issue in the future if upgrades implement data availability sampling (DAS).

EIP-4844 Devnet 5 Preparations

Developers have been running devnets for EIP 4844 since October 2022. In the latest Consensus All Core Devs meeting, Tim Beiko announced that the fifth devnet for EIP-4844 will launch next week. Paritosh Jayanthi was currently conducting trial runs with Ethereum JS (EL) and Lodestar (CL). There was a minor change to the Engine API, which merges the getPayloadV3 and getBlobsBundleV1 calls into one. This change will be merged into the EIP-4844 specifications on GitHub soon, and it will be available for testing on devnet #5. Client teams were urged to review the change as soon as possible.

In the latest Execution All Core Devs meeting, Core Developers announced that Devnet 5 was launched with 1000 validators and 6 clients.

Related Videos


Disclaimer: The information contained on this web page is for education purposes only. Readers are suggested to conduct their own research, review, analyze and verify the content before relying on them.

To publish press releases, project updates and guest posts with us, please email at

Subscribe to EtherWorld YouTube channel for ELI5 content.

Support us at Gitcoin

You've something to share with the blockchain community, join us on Discord!

Follow us at Twitter, Facebook, LinkedIn, and Instagram.

Share Tweet Send
You've successfully subscribed to
Great! Next, complete checkout for full access to
Welcome back! You've successfully signed in
Success! Your account is fully activated, you now have access to all content.