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
• Chain Reorgs
• Proposed Solutions
• Effect on Future Upgrades
• EIP-4844 Devnet 5 Updates

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 Articles

• EIP-4844 ready for Multi-Client Devnets
• Verkle Trees Research Progress
• Exploring EVMMAX Proposals & BLS12-381
• Why Ethereum Clients prefer SSZ over RLP?
• Partial SSZ Migration in the Cancun Upgrade
• Mega EOF Endgame Specification
• '0-Blob Txns' Omitted from EIP-4844 in Cancun Upgrade
• 4844 Specs includes KZG multi verify function
• Upcoming Changes to Ethereum Blockchain
• Transient Storage for Beginners: EIP-1153 Explained
• How Layer 3 in Future will look like?
• An Overview of Beacon Chain API

Related Videos

• The Future of Ethereum Goerli Testnet
• ETH Withdrawals: Everything You Need to Know
• Client Diversity
• Reth: Ethereum Execution Layer Client Written in Rust
• Sign-In with Ethereum: EIP-4361