Scalability limitations of Kademlia DHTs when enabling Data Availability Sampling in Ethereum

TL;DR

This work investigates whether a Kademlia-based DHT can support Data Availability Sampling for Ethereum’s DankSharding, using a configurable DAS-DHT simulator validated against IPFS experiments. The study finds that while DHT lookups can achieve sub-second latency at the 90th percentile under favorable conditions, the seeding burden of distributing hundreds of thousands of small samples across thousands of nodes presents a major scalability bottleneck. Single-seeder and centralized seeding approaches quickly become impractical within ETH DAS time constraints, and even distributed seeding via GossipSub or alternative routing strategies carry substantial trade-offs in load, latency, and privacy. The results suggest that a pure DHT-based seeding path may be insufficient for scalable DAS, motivating exploration of hybrid or alternative data availability mechanisms that maintain decentralization while reducing seeding overhead.

Abstract

Scalability in blockchain remains a significant challenge, especially when prioritizing decentralization and security. The Ethereum community has proposed comprehensive data-sharding techniques to overcome storage, computational, and network processing limitations. In this context, the propagation and availability of large blocks become the subject of research to achieve scalable data-sharding. This paper provides insights after exploring the usage of a Kademlia-based DHT to enable Data Availability Sampling (DAS) in Ethereum. It presents a DAS-DHT simulator to study this problem and validates the results of the simulator with experiments in a real DHT network, IPFS. Our results help us understand what parts of DAS can be achieved based on existing Kademlia DHT solutions and which ones cannot. We discuss the limitations of DHT solutions and discuss other alternatives.

Figures (11)

• Figure 1: Block split proposal for DankSharding's DAS.
• Figure 2: Description of the DHT components in the dht simulator, and an example of the internal logic of their interaction.
• Figure 3: CDF of the DHT hops while performing 100 concurrent retrievals in the IPFS network.
• Figure 4: CDF of the time to finish $100$ sets of $80$ concurrent retrievals from the IPFS network.
• Figure 5: CDF of the simulated number of hops while looking for $200$ concurrent keys with different overheads with $k=20$, $alpha=3$, and $beta=20$.