Shapella Network upgrade is expected in late March 2023. Meanwhile, preparations for the next ethereum upgrade, Cancun-Deneb, are in full swing. Core Developers are working on EIP-4844 in parallel by finalizing the spec and testing the upgrade. During the EIP-4844 discussions, the topic of 0-blob transactions came up repeatedly. Lastly, Developers have agreed to completely ban blobless 4844 transactions.

Criticisms of 0-Blob Transactions

EIP-5793: eth/68 - Add tx type to tx announcement, i.e., Ethereum Wire Protocol which defines request and response messages for exchanging data between clients. It does not allow distinguishing between transactions containing blobs and some that don't, so 0-blob transactions would be treated as if they had blobs on the networking layer.

EIP-4844 introduces a new transaction type for blob transactions. Since these blob transactions are large, naively broadcasting them to peers could significantly increase bandwidth requirements. Similar issues could reoccur with future transaction types.

Currently, there is no current transaction type that encodes as SSZ and supports 0 blobs.

Advantages of Removing '0-blob' transactions.

Removing helps developers to enable a better structure in the code. There is no need for any new transaction type. This will simplify clients' initial implementation, and it's always easier to relax a constraint than add a new one.

Free the blobs

Developers discussed a new spec update to free blobs during the EIP-4844 Implementers' Call #15. This update reintroduces and further decouples blocks and blobs in EIP-4844 to improve network and processing performance.

Also, it should be noted that freeing the blobs doesn't bring in any EL changes, only CL. This design sends each blob on a separate subnet, thus maximizing the potential for parallelization and providing a natural path for growing the number of blobs per block.

SSZ Optional for blob transaction address

Blob transaction has a destination field for the address. It's currently a union for None or Address. SSZ union has not been used in the consensus and lacks spec testing. Developers have suggested replacing the union with a list. However, most consensus clients have implemented SSZ union despite needing more testing. There are also no official tests for SSZ unions.

Etan Kissling, Developer at Nimbus, has created a proposal to replace the union with a list or optional type. In addition, this proposal introduces a new type into SSZ to shed a single byte from the transaction.

Beacon API spec updates

Beacon API is the collection of RESTful APIs provided by Ethereum Beacon nodes. This API specification is for the beacon node, which enables users to query and participate in Ethereum 2.0 phase 0 beacon chain.

This specification aims to promote interoperability between various beacon node implementations. The Beacon API spec updates are in progress. This is needed for validators to sign individual blobs as they become decoupled.

EIP-4844 Implementers' Call #16 is scheduled today at 15:30 UTC. Core developers will further finalize the latest spec and testing updates of the Cancun upgrade.

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 contact@etherworld.co.

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.