tl;dr: Recently, certain Layer 2 (L2) solutions have encountered issues with their deployments on Sepolia, attributed to EIP-7594, which modifies the proof formats. As we prepare for Fusaka, we strongly advise all blob originators to update their software to generate Cell Proofs instead of blob proofs.
Background
Background
An often overlooked element of EIP-7594 (PeerDAS) is its transformation of proof formats from blob proofs to cell proofs, facilitating downloads of specific portions of the blob for data availability sampling.
This modification could disrupt user applications that utilize blob transactions. While previously signed transactions remain valid, they will need cell proofs recalculated. Certain clients, particularly go-ethereum, will manage this via the RPC methods eth_sendTransaction and eth_sendRawTransaction (1). The conversion process from blob proofs to cell proofs takes approximately one second; hence, we advise originators of blob transactions to transition to cell proofs to minimize rpc layer overhead.
Transactions present in the txpool during the fork may be discarded by some implementations, while others will convert them to cell proofs. It would be wise to resend transactions with cell proofs shortly after the fork if they have not been processed by the chain. Some implementations may permit the dissemination of blob proof transactions up to a few minutes post-hard fork on the networking layer for enhanced stability.
Actionable changes
Actionable changes
If you are a blob transaction originator (e.g., an L2), it is essential to update your transaction-sending code to implement cell proofs.
All primary client libraries provide functionality for these proofs via ComputeCellsAndKZGProofs(), available across all major programming languages (2). You can find usage examples in all major languages within the client libraries (3).
Outlook
Outlook
Going forward, we will enhance our communication regarding these user-impacting changes through the Ethereum blog and increase community outreach to prevent any surprises for Ethereum users regarding protocol modifications.
We also urge L2s and stakeholders heavily reliant on the Ethereum roadmap to engage directly with the community and follow the ACD process. Teams should also aim to deploy contracts and test infrastructure on devnets shortly before transitioning to the first testnets. Additionally, utilizing the Ethereum package from Kurtosis can facilitate the creation of local networks with the latest specifications (4).
Although it’s unfortunate that blob originators discovered this change late in the hard fork process, it also signifies the testnet process’s efficacy in identifying such issues well before they could affect the mainnet.
(1): The go-ethereum client will perform the conversion exclusively via eth_sendRawTransaction from the current master branch and v1.16.5 onwards.
(2): See https://github.com/ethereum/c-kzg-4844 (c)
https://github.com/crate-crypto/go-eth-kzg (go)
https://github.com/crate-crypto/rust-eth-kzg (rust)
(3): Example for go-ethereum: https://github.com/ethereum/go-ethereum/blob/7c107c2691fa66a1da60e2b95f5946c3a3921b00/crypto/kzg4844/kzg4844_test.go#L194
(4): Ethereum package for Kurtosis: https://github.com/ethpandaops/ethereum-package
