Listing
Status legend
🌚 Unstarted
🚧 In progress
❓ Unknown status
🚧 1. Poor fanout reachability for non-supernodes
<aside>
Resolution: 🟡 Prysm | 🔴 Lighthouse | 🔴 Teku | 🔴 Nimbus | 🔴 Lodestar | 🔴 Grandine
</aside>
Description
- PeerDAS requires block builders to publish columns across all 128 topics concurrently, but they subscribe only to a subset, concretely as many as the custody count designated by their active validator stake.
- For custody columns outside that subscription set, they rely on gossipsub’s fanout, which only works if they are connected to peers who are members of those topics.
- To our knowledge, clients aren’t doing anything special to ensure they have sufficient connected fanout peers on all column subnets, especially as their producer duty is approaching.
Remarks
- This isn’t a problem for supernodes. Moreover, if builders include only publicly available blobs that are widely present in mempools, the issue is mitigated because other nodes can autonomously construct and publish columns (with blobs obtained via getBlobsV2).
- This might be aggravated by supernode in-group peering below (supernodes refuse to peer with non-supernodes).
Potential solutions
- Have nodes track custody columns of peers they’re disconnected from, and reestablish connections ahead of their proposer duty to boost their connectivity temporarily.
- Or discover more peers through Discv5 if the number of peers in a particular subnet drops below some threshold.
Client statuses
- Prysm: As in devnet-4, Prysm hasn’t implemented it yet and it’s marked as a TODO item.
🚧 2. Supernodes clustering (in-group peering)
<aside>
Resolution: 🔴 Prysm | 🔴 Lighthouse | 🔴 Teku | 🔴 Nimbus | 🔴 Lodestar | 🔴 Grandine
</aside>