PeerDAS (Peer Data Availability Sampling) is a critical component of Ethereum's roadmap, designed to improve network scalability and reliability. With the PeerDAS Devnet-4 launch approaching in January 2025, client teams are working to test, refine, and prepare for this major milestone. This blog outlines the current state of PeerDAS testing, the challenges being addressed, and what’s next.
Devnet 4 Launch Timeline
The PeerDAS Devnet-4 launch is scheduled for mid to late January 2025. The activation of PeerDAS is tied to the Fulu Fork Epoch. These include updates to the PeerDAS specifications, improvements in network synchronization, and support for data column RPC functionality.
To ensure the network transitions smoothly, rigorous pre-devnet testing is underway, focusing on client interoperability and readiness.
Client Updates
Lighthouse has made significant strides in PeerDAS integration by activating it at the Fulu fork. The team resolved several peer-scoring issues that previously caused disconnections and network splits.
However, challenges remain, particularly during interoperability testing with Prysm, where state mismatches were observed after transitioning to Fulu. Further investigation is ongoing to address these issues.
The Prysm team replaced custody subnet counts with custody group counts, an important step toward compliance with the latest PeerDAS specifications. They also integrated the go-kzg library, which promises better performance compared to the older c-kzg library, though further optimization is needed.
In addition, Prysm has started implementing validator custody, a feature that aligns with PeerDAS but remains optional for clients.
Teku has successfully transitioned to the Fulu fork but continues to work on decoupling custody groups to enhance its implementation. While significant progress has been made, additional testing and debugging are required before declaring readiness for Devnet-4.
Lodestar rebased its code to align with the Fulu fork and resolved a persistent bug, which, although unrelated to Fulu, delayed some progress. The team is now focused on decoupling custody groups and aims to complete the testing of these changes in the coming weeks.
Grandine has implemented PeerDAS activation at Fulu and decoupled custody subnets from the core. The team is also stress-testing its reconstruction flow to identify and fix bugs that could hinder data availability under high-load scenarios.
Devnet 4 Specs
The PeerDAS Devnet-4 specs include EIP-7594, which defines the core of Peer Data Availability Sampling. The changes for Devnet-4 introduce a decoupling of network subnets from the DAS core and enhance the P2P layer with support for new APIs, such as engine_getBlobsV1.
These updates ensure that data column RPC functionality is in place before the Devnet launch. Furthermore, consensus specifications (v1.5.0-alpha.10) have been integrated to streamline client compatibility.
PeerDAS Devnet Test Scenarios
Multiple scenarios have been designed to evaluate client readiness and robustness under different conditions. The key test scenarios are outlined in the table below:
| Scenario | Description | Setup | Success Criteria |
|---|---|---|---|
| Scenario 1: Standard Run | All nodes transition from Deneb to Electra and finally to Fulu. | Varies: combinations of full and super nodes. | All slots in the first Fulu epoch are finalized. |
| Scenario 2: Sync in an Unfinalized Network | The network cannot finalize without the tested node. Fixture nodes are started first, followed by the tested node. | 1 full tested node, 1 full fixture node, and 2 super fixture nodes (or a super-tested node with variations). | The tested node syncs and the network finalizes as expected. |
| Scenario 3: Sync in a Finalized Network | The network finalizes without the tested node, which is started after finalization. | Same setup as Scenario 2. | The tested node syncs correctly after the network has finalized. |
| Scenario 4: Reconstruction | Nodes transition through all forks while super fixture nodes withhold some data, forcing reconstruction. | 1 super-tested node, 2 super fixture nodes (configured to withhold data), and 1 full fixture node. | The tested node reconstructs and reseeds missing data columns without missing or orphaning blocks. |
The progress toward PeerDAS reflects the collective efforts of Ethereum client teams to build a more scalable and reliable network. While significant milestones have been achieved, challenges such as state mismatches, custody group decoupling, and reconstruction bugs remain.
The upcoming tests and interop efforts will play a pivotal role in addressing these issues and ensuring readiness for the launch. As testing continues, it is essential for teams to collaborate, share insights, and refine their implementations.
References: PeerDAS Breakout Room #15
_____________________________________________________________________Disclaimer: The information contained in this website is for general informational purposes only. The content provided on this website, including articles, blog posts, opinions, and analysis related to blockchain technology and cryptocurrencies, is not intended as financial or investment advice. The website and its content should not be relied upon for making financial decisions. Read full disclaimer and privacy Policy.
For Press Releases, project updates and guest posts publishing with us, email to contact@etherworld.co.
Subscribe to EtherWorld YouTube channel for ELI5 content.
Share if you like the content. Donate at avarch.eth or Gitcoin
You've something to share with the blockchain community, join us on Discord!
