Ethereum's core developers discussed in detail about the testing of EIP-4844 testing progress in the latest EIP-4844 Implementors Call #20. The conversation revolved around the specs and testing progress of Devnet-5 from the devs of different client teams. We should be expecting EIP-4844 Devnet-5 by early next week.
- Deneb (EIP-4844) Devnet-5 Spec
- Lighthouse Testing Progress
- Prsym Multi-Client Devnet Readiness
- Proposed PRs in Devnet-5
- EIP-4844 Engine API Updates
Deneb (EIP-4844) Devnet-5 Spec
Some Notable changes have been made to the Deneb (EIP-4844) Devnet-5 spec since the last devnet, such as switching the blob transaction type to 0x03 and decoupling blobs and blocks. The Execution Layer (EL) builds on top of Shanghai, which includes banning zero blob transactions, changing the blob transaction type to 0x03, and decoupling blobs (to be merged soon). In terms of Engine API updates, there are plans to add corresponding proofs to BlobsBundleV1 (not yet merged) and merge getPayloadV3 & getBlobsBundleV1. For the Beacon API, adding blob signing endpoints is optional.
Lighthouse Testing Progress
The Lighthouse team has reported progress on several aspects, including passing Deneb EF tests for spec release v1.3.0-rc.5. However, this release candidate does not include the TX type update. The team is also working on single block + blob lookups and fixing gossip verification issues. While they could potentially achieve a devnet target in one week, they would prefer a two-week timeframe.
Prsym Multi-Client Devnet Readiness
Several tests have been conducted on the Devnet using various Prysm nodes. These tests have successfully demonstrated state transition passing spec tests, validators signing and broadcasting blobs, nodes syncing blocks and blobs by range, as well as handling blobs by root in special cases. With these positive outcomes, Prysm appears to be fully prepared for Multiclient Devnet.
Proposed PRs for Devnet-5
Several PRs have been proposed for review and merge in relation to Devnet-5 specifications. These include adding corresponding proofs to BlobsBundleV1 and updating EIP-4844 to decouple blobs. Additionally, there is an optional inclusion to consider, which involves adding blob signing endpoints.
EIP-4844 Engine API Updates
The Unknown Payload error code in EIP-4844 was updated to match the regular engine API unknown payload error code.
Also, a decision was made to add a blobsBundle field to the getPayloadV3 response. This change removes the blockHash field from the BlobsBundleV1 data type and ensures consistency between the getPayloadV3 and corresponding getBlobsBundleV1 calls.
EIP-4844 Implementers' Call #21 is scheduled on May 1st at 15:30 UTC. Core developers will further finalize the latest spec and testing updates of the Dencun upgrade.
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
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!