Pith. sign in

REVIEW 3 major objections 5 minor 73 references

A Distributed Learned Hash Table

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Replacing random hashing with an order-preserving learned model makes range queries in DHTs nearly as cheap as single-key lookups, cutting latency and message cost by 80–90%+.

desk verdict A genuinely new combination—learned order-preserving hash inside a DHT—with a broad empirical study, but the range-query correctness argument has a gap that needs fixing before the central claims can be trusted. read the letter →

arxiv 2508.14239 v1 pith:RBNQF4PE submitted 2025-08-19 cs.NI

Shengze Wang , Yi Liu , Xiaoxue Zhang , Liting Hu , Chen Qian This is my paper
classification cs.NI
keywords learnedhashfunctiondistributedtablerangequeryrecursivemodelindexorder-preservinghashingfederatedupdateloadbalancingnetworkchurn
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Distributed hash tables distribute keys with random hashing, which scatters nearby keys across the network and makes range queries expensive: every key in the range must be found individually. This paper claims that a learned hash function—a recursive model trained on the cumulative distribution of keys—can replace the random hash and still spread keys evenly while placing nearby keys on nearby peers. On that basis, LEAD turns a range query into a single-key lookup followed by a short scan of successor peers, keeping latency nearly flat as the range grows from 500 to 10,000 keys and cutting message cost by 80–90% versus Chord-based batching and the MARQUES overlay in the paper's testbed and simulations. The paper also proposes a decentralized model-update protocol and a virtual-node balancer to keep the learned model accurate and the load even under churn, and it demonstrates the system on LLM KV-cache sharing and IPFS block retrieval. If correct, this gives DHTs an order-preserving property they historically lacked, without sacrificing single-key logarithmic lookup.

What carries the argument

The load-bearing object is the Learned Hash Function, implemented as a Recursive Model Index (RMI): a hierarchy of small models in which each stage picks the next model for a key, and leaf models predict the key's relative position in the dataset; a scale factor maps that position into the DHT's hashing space. Because the model approximates the key CDF, hash values preserve key order, which is what lets a range query walk the successor chain instead of scattering lookups. A separate consistent hash, PeerHASH, assigns peer identifiers and owns the routing/finger-table machinery, so the learned model never has to be correct for the system to function. Two supporting mechanisms carry the dynami

What would settle it

Construct a 490-node LEAD simulation with a key universe engineered so the CDF is adversarial—for example, keys arranged in fine-grained interleaved runs that no small recursive model can approximate—then measure messages per 5,000-key range query. If message count grows with range size (hundreds of messages) instead of staying near the single-key cost, the central claim fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that the random hash function in a DHT can be replaced by a learned hash function without losing the DHT's decentralized guarantees, and that doing so removes the two costs that make range queries slow: the need to search many keys and the scattering of those keys across many nodes. LEAD trains a Recursive Model Index to approximate the CDF of the key set, maps each key to an order-preserving hash value, and assigns ownership by a separate consistent-hash address space, so that keys close in value are owned by the same or neighboring peers. A range query hashes the start key, routes to its owner in logarithmically many hops, scans that peer's in-memory store, and

Load-bearing premise

The key distribution must be one that a statistical model can learn and that stays roughly stable; if keys arrive in a highly irregular or adversarial pattern, the learned hash gives little ordering benefit and performance falls back toward a plain DHT.

Editorial extensions

If this is right

  • Range queries in a DHT cost about the same as a single-key lookup: in the paper's 490-node simulations, LEAD uses fewer than 15 messages per 5,000-key range query, versus more than 200 for batched Chord and more than 50 for MARQUES.
  • Near-constant range-query latency holds across four real-world datasets (uniform, skewed popularity, temporal) as query range grows from 500 to 10,000 keys.
  • The system keeps working during model updates: correctness depends only on the address hash, and updates are triggered only after roughly 40% of keys are new, with each insertion's gradient update costing about 2.1 microseconds.
  • Churn resistance holds under uniform, exponential, and Pareto node lifetimes, with no loss of the range-query advantage.
  • Two case studies position LEAD as a general substrate: LLM KV-cache sharing approaches the latency of a centralized router while removing its bottleneck, and IPFS block-sequence retrieval needs far fewer hops than batched lookups.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper asserts, but does not measure, that performance reverts to a baseline DHT on adversarial or highly irregular key distributions; a direct experiment with an engineered worst-case CDF would test that fallback claim.
  • The same order-preserving learned hash could serve workloads where locality matters more than exact ordering, such as collocating semantically close embeddings or time-series telemetry, though the paper only sketches these applications.
  • Because correctness is decoupled from model quality, an operator could deploy LEAD with a weak initial model and improve it online—trading temporary load imbalance for zero data migration—an option traditional order-preserving overlays do not offer.
  • If the 40% update threshold generalizes beyond the tested datasets, LEAD's maintenance cost is extremely low; if it does not, the threshold itself becomes a tunable parameter that needs per-workload calibration.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes LEAD, a Chord-like DHT in which the random hash function is replaced by a learned, order-preserving hash built from a Recursive Model Index (RMI). Keys are mapped by the learned CDF to positions on the identifier ring, so keys close in key space land close on the ring; range queries then start at the successor of the first key and walk the successor chain to collect the requested keys. The design also includes virtual-node-based load balancing (Shadow Balancer) and a federated, asynchronous model update mechanism (FRM). The evaluation combines a 90-peer testbed and a 490-node PlanetLab-topology simulator, uses four 200M-key datasets, and compares against Chord with batched lookups and MARQUES. The paper reports 80--90%+ reductions in range-query latency and message cost, near-constant range-query latency, logarithmic single-key lookup cost, robustness under churn, and two application case studies (KV-cache management for LLM serving and IPFS).

Significance. If the central claim holds, LEAD is a notable contribution: it is a clean, practical idea that brings learned indexes into the DHT setting and directly attacks the long-standing range-query limitation of DHTs. The evaluation is extensive and grounded in real datasets and network traces, and the authors state that implementation and simulation code will be released. The paper also contains several system-level optimizations (model auto-selection, anchor/scale adaptive leaves, transient-coordinator model aggregation) that go beyond a naive application of RMI. However, the range-query correctness of the scheme rests on an order-preservation property that is not established, and the asynchronous model-update correctness argument is incomplete. These are load-bearing gaps rather than presentation issues, and the paper should not be accepted before they are addressed.

major comments (3)
  1. [Section III-E2, Eqs. (1)-(2), Table I, Appendix C] The range-query algorithm is exact only if LearnedHASH is order-preserving on the actual key set: the query hashes K, jumps to its successor S, then walks S's successors 'until all n keys are retrieved.' This is correct only if the keys in [K, K+n) occupy a contiguous VID interval. However, the RMI is trained with squared-error loss (Eq. 2) with no monotonicity regularizer, and Table I reports maximum log2 errors of 18.63--25.79, so non-monotone predictions cannot be excluded. Appendix C's correctness argument covers single-key lookups only; the sentence 'As long as the keys are stored in sorted order across the ring, which our learned hash function aims to ensure' explicitly leaves the key property as an assumption. Without a monotonicity guarantee or a verification/fallback mechanism, the query can terminate with n keys that are not exactly [K, K+n) or traverse extra peers, breaking bo
  2. [Section III-E3 and Appendix C] The FRM mechanism changes the learned CDF, and therefore changes the VID to which a given key maps. The paper does not state whether existing keys are re-hashed or migrated when a new model version is adopted. If they are not, then a lookup using the new model and a lookup using the old model can disagree on the owner of the same key. The 'safe forwarding rule' in Appendix C assumes that Chord invariants determine the true owner, but the key's position on the ring is determined by LearnedHASH(K), which is version-dependent. The assertion that 'correctness is never compromised by model error' is therefore not supported by the cited mechanisms. Please define the ownership rule during model skew and prove convergence for queries issued with stale model versions.
  3. [Appendix B] The hop-bound calculation does not establish the claimed O(log(mn)) range-query cost for general query sizes. The symbol n is used both for the number of physical nodes and for the range-query length, and the expression ceil(mn^2/V - 1/2) is only meaningful under this conflation. For an arbitrary range of N keys, the expected number of additional hops after S is Nmn/V - 1/2, which can be large when N is not negligible relative to V/(mn). The condition n^2 << V is not a property of the query workload. State the bound with distinct variables and explicit conditions (e.g., N < V/(2mn)), or present the near-constant latency as an empirical observation rather than a derived guarantee.
minor comments (5)
  1. [Section III-B, Eq. (1)] Equation (1) and its explanatory lines contain garbled notation and typos ('aB', 'bfi', 'determimines'). The formal definition of the learned hash should be rewritten with consistent subscripts and defined variables.
  2. [Section IV-B and Figs. 6-9] All latency and message plots report averages without confidence intervals or standard deviations. The testbed section states each query was repeated ten times; this is too few to support the tight claims ('less than 150 ms', '80-90%+ reduction') without error bars or a statistical test.
  3. [Introduction, Section IV-C] The abstract and introduction claim 'more than tenfold' latency reduction, but the reported numbers in Section IV-C (e.g., 1300 ms vs. <150 ms for 4000 keys) correspond to roughly 9x. Please reconcile the claim with the data, or report the larger range where the factor exceeds ten.
  4. [Appendix (overall)] The appendix contains duplicated and misnumbered material: two copies of the IPFS case study, repeated Fig. 12 captions, and duplicate Related Work text. Please reorganize the appendix and fix the figure numbering.
  5. [Section IV-C10] The sentence 'our real-world testbed confirms ... overhead' is stated without a figure or table; if these measurements are included, they should be plotted or tabulated in the main evaluation.

Circularity Check

1 steps flagged · score 2.0 of 10

Minor circularity in the analytic hop bound; central empirical results are self-contained.

  1. self definitional [Appendix B, Shadow Balancer Analysis]
    "With V key-value pairs managed in the network, each peer manages an average of V/mn key-value pairs. Upon reaching S, the query retrieves an average of V/2mn keys. If the query is not completed, it continues on S's successors, each of which retrieves V/mn keys. Consequently, after reaching S, the query needs an additional ⌈mn2/V − 1/2⌉ hops ... Therefore, the range query requires less than one additional hop after reaching S, and it can be resolved within log(mn) hops with high probability."

    The hop-count analysis assumes the learned hash distributes keys uniformly over the ring (each peer holds V/mn keys) and that a queried range maps to contiguous successors. That uniformity/contiguity is exactly the property LearnedHASH is trained to approximate (Eqs. 1-2 minimize squared position error, with no monotonicity regularizer) and is not guaranteed; Table I reports max log2 errors of 18-26. The analytical O(log n) range-query claim is thus derived from the very property the design is supposed to provide, making the bound equivalent to the assumption. The empirical latency/message measurements in Section IV-C are independent of this analysis and do not reduce to the same assumption, so the paper's central empirical claims remain self-contained.

full rationale

The paper's headline 80-90% latency/message improvements are empirical results from testbed and simulation (Section IV), comparing measured end-to-end range-query performance against Chord, Marques, and batch-query baselines. Those measurements do not derive from the learned model's fitted parameters or from any equation in the paper, so they are not circular. The only load-bearing analytical derivation is Appendix B's range-query hop bound, which assumes a perfectly uniform learned hash (each peer storing V/mn keys) and contiguous key-to-ring mapping. This assumes the very property the model is trained to approximate but never guarantees: Eq. 2 is a squared-error loss with no monotonicity enforcement, and Table I reports substantial prediction errors. Hence the formal O(log n)-hop argument is self-definitional under an ideal-CDF assumption. This is a minor circularity because it is not the basis for the empirical evaluation, and the paper itself flags the underlying fragility: Appendix C states that correctness requires keys be 'stored in sorted order across the ring, which our learned hash function aims to ensure' and concedes that for irregular/adversarial distributions performance 'would gradually revert toward the baseline DHT.' These passages are explicit limitations, not covert derivations. No load-bearing self-citations were found; the references to learned-index foundations [27, 28, 31, 33, 34] are external and independently established. Overall, the central claims are empirically supported and only the analytic complexity bound shows a self-definitional idealization, warranting a low score of 2.

Assumptions & free parameters 4 free parameters · 4 assumptions · 0 invented entities

The central claim rests on the fitted RMI model parameters and on the empirical choice of update threshold and virtual node count. No genuinely new physical or conceptual entity is introduced; the Shadow Balancer and FRM are recombinations of known concepts.

free parameters (4)
  • RMI leaf model parameters = Varies by dataset
    The recursive model is trained to minimize prediction error on a training sample of the key distribution. The central claim of order-preserving mapping depends on these fitted parameters.
  • Model update threshold = 40%
    The paper empirically identifies 40% new keys as the point where model updates are triggered. This is a design parameter fitted to the tested datasets.
  • Number of virtual nodes per physical node = 10
    The paper selects 10 virtual nodes per physical node based on load-balancing experiments (Fig. 11). This parameter affects load distribution and range query locality.
  • Scale factor S and branching factor B = Not precisely specified
    These RMI hyperparameters control the mapping from relative position to hash space and the number of leaf models. They are tuned during model training and affect the accuracy of the order-preserving hash.
assumptions (4)
  • standard math Chord routing invariants: successor and finger table lookups guarantee O(log N) single-key lookup and correct ring navigation.
    The correctness and complexity of LEAD's single-key lookup and the convergence of range queries rely on the proven Chord invariants, which are cited from [7] and used in Appendix C.
  • domain assumption The four SOSD datasets (osmc64, face64, amzn64, wiki64) are representative of real-world key distributions for distributed key-value systems.
    The generalizability of the 80-90%+ performance claim beyond these datasets is an implicit assumption. The paper acknowledges in Appendix C that adversarial or irregular distributions may not benefit.
  • domain assumption The PlanetLab latency dataset and the p2psim+ simulator accurately model real network conditions.
    All simulation results depend on the fidelity of the network simulator and the latency model. The paper provides no validation of the simulator against real-world large-scale DHT deployments.
  • ad hoc to paper The federated model update preserves a valid CDF approximation and converges under churn.
    The correctness proof for asynchronous updates (Appendix C) assumes version-monotone models and safe forwarding, but the argument is informal and does not rigorously establish convergence or that the averaged leaf parameters still approximate a valid CDF.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Distributed Learned Hash Table." pith.science (2026). https://pith.science/paper/RBNQF4PE

@misc{pith2026250814239,
  author       = {Pith},
  title        = {Pith review of: A Distributed Learned Hash Table},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RBNQF4PE}},
  note         = {Machine review of arXiv:2508.14239}
}
read the original abstract

Distributed Hash Tables (DHTs) are pivotal in numerous high-impact key-value applications built on distributed networked systems, offering a decentralized architecture that avoids single points of failure and improves data availability. Despite their widespread utility, DHTs face substantial challenges in handling range queries, which are crucial for applications such as LLM serving, distributed storage, databases, content delivery networks, and blockchains. To address this limitation, we present LEAD, a novel system incorporating learned models within DHT structures to significantly optimize range query performance. LEAD utilizes a recursive machine learning model to map and retrieve data across a distributed system while preserving the inherent order of data. LEAD includes the designs to minimize range query latency and message cost while maintaining high scalability and resilience to network churn. Our comprehensive evaluations, conducted in both testbed implementation and simulations, demonstrate that LEAD achieves tremendous advantages in system efficiency compared to existing range query methods in large-scale distributed systems, reducing query latency and message cost by 80% to 90%+. Furthermore, LEAD exhibits remarkable scalability and robustness against system churn, providing a robust, scalable solution for efficient data retrieval in distributed key-value systems.

Figures

Figures reproduced from arXiv: 2508.14239 by the authors.

Figure 1
Figure 1. Micro benchmark of Range Query Performance [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. LEAD System Design Key Position CDF of Key-value Pairs Learned Hash Function Hashing Space Map Recursive Model Train Key Distribute Hash Value LEAD Overlay [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 5
Figure 5. Range Query in LEAD relationships in order-preserving hash values. Range queries in LEAD are handled based on the order-preserving key mapping by the Learned Hash Function. To execute a range query for a sequence of n successive key-value pairs starting from key K, the initiating peer P first applies the Learned Hash Function to hash K (as shown in [PITH_FULL_IMAGE:figures/full_fig_p005_5.png] view at source ↗
Figures from the paper (8 more)
Figure 6
Figure 6. Figure 6: Latency of range queries on various datasets in the real-machine testbed [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Latency of range queries on various datasets from large-scale simulations [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Number of messages of each range query on various datasets. [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Latency of range queries under various conditions [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: Comparison of Key-Value Pair Distribution [PITH_FULL_IMAGE:figures/full_fig_p008_10.png]
Figure 12
Figure 12. Figure 12: Latency vs. RMI Models 500 1000 2000 4000 8000 10000 Query Range 800 810 820 830 840 850 860 870 880 890 900 Range Query Latency (ms) RMI PGM RadixSpline [PITH_FULL_IMAGE:figures/full_fig_p009_12.png]
Figure 15
Figure 15. Figure 15: KV Cache Management 0 10 20 30 40 50 Number of Messages 0.00 0.25 0.50 0.75 1.00 CDF IPFS LEAD [PITH_FULL_IMAGE:figures/full_fig_p010_15.png]
Figure 16
Figure 16. Figure 16: Memory cost and latency for range queries of a blockchain Fig. 17. Range Query Benchmark in Blockchain [PITH_FULL_IMAGE:figures/full_fig_p015_16.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

73 extracted references · 66 canonical work pages

  1. [1]

    Towards efficient and reliable llm serving: A real- world workload study,

    Y . Wang, Y . Chen, Z. Li, Z. Tang, R. Guo, X. Wang, Q. Wang, A. C. Zhou, and X. Chu, “Towards efficient and reliable llm serving: A real- world workload study,” arXiv e-prints, pp. arXiv–2401, 2024

    work page 2024

  2. [3]

    Sglang: Efficient execution of structured language model programs,

    L. Zheng et al., “Sglang: Efficient execution of structured language model programs,” in Proc. of NeurIPS , 2024

    work page 2024

  3. [4]

    Do large language models need a content delivery network?

    Y . Cheng, K. Du, J. Yao, and J. Jiang, “Do large language models need a content delivery network?” arXiv preprint arXiv:2409.13761 , 2024

    arXiv 2024

  4. [5]

    Cachegen: Kv cache compression and streaming for fast large language model serving,

    Y . Liu, H. Li, Y . Cheng, S. Ray, Y . Huang, Q. Zhang, K. Du, J. Yao, S. Lu, G. Ananthanarayanan, M. Maire, H. Hoffmann, A. Holtzman, and J. Jiang, “Cachegen: Kv cache compression and streaming for fast large language model serving,” in Proceedings of the ACM SIGCOMM 2024 Conference, 2024

    work page 2024

  5. [7]

    Chord: A scalable peer-to-peer lookup service for internet applications,

    I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A scalable peer-to-peer lookup service for internet applications,” ACM SIGCOMM, vol. 31, no. 4, 2001

    work page 2001

  6. [8]

    Resource discovery for distributed computing systems: A comprehensive survey,

    J. Zarrin, R. L. Aguiar, and J. P. Barraca, “Resource discovery for distributed computing systems: A comprehensive survey,” Journal of parallel and distributed computing , vol. 113, pp. 127–166, 2018

    work page 2018

  7. [9]

    A survey on content-centric technologies for the current internet: Cdn and p2p solutions,

    A. Passarella, “A survey on content-centric technologies for the current internet: Cdn and p2p solutions,” Computer Communications , vol. 35, 2012

    work page 2012

  8. [10]

    A survey and comparison of consistent hashing algorithms,

    M. Coluzzi, A. Brocco, P. Contu, and T. Leidi, “A survey and comparison of consistent hashing algorithms,” in 2023 IEEE ISPASS, 2023

    work page 2023

Show all 73 references
  1. [11]

    Design and evaluation of ipfs: a storage layer for the decentralized web,

    D. Trautwein, A. Raman, G. Tyson, I. Castro, W. Scott, M. Schubotz, B. Gipp, and Y . Psaras, “Design and evaluation of ipfs: a storage layer for the decentralized web,” in ACM SIGCOMM 2022, 2022, pp. 739–752

    2022

  2. [12]

    Apache cassandra: Open source nosql database

    Apache, “Apache cassandra: Open source nosql database.” [Online]. Available: https://cassandra.apache.org/

  3. [13]

    Cassandra: a decentralized structured storage system,

    A. Lakshman and P. Malik, “Cassandra: a decentralized structured storage system,” ACM SIGOPS, vol. 44, no. 2, pp. 35–40, 2010

    2010

  4. [14]

    The Tor Project | Privacy & Freedom Online — torproject.org,

    “The Tor Project | Privacy & Freedom Online — torproject.org,” https: //www.torproject.org/, [Accessed 13-05-2025]

    2025

  5. [15]

    Namecoin

    Namecoin, “Namecoin.” [Online]. Available: https://www.namecoin.org/

  6. [16]

    Bittorrent: The world’s most popular torrent client

    L. BitTorrent, “Bittorrent: The world’s most popular torrent client.” [Online]. Available: https://www.bittorrent.com/

  7. [17]

    Preble: Ef- ficient distributed prompt scheduling for llm serving,

    V . Srivatsa, Z. He, R. Abhyankar, D. Li, and Y . Zhang, “Preble: Ef- ficient distributed prompt scheduling for llm serving,” arXiv preprint arXiv:2407.00023, 2024

    2024 arXiv

  8. [18]

    Fog and IoT: An Overview of Research Opportunities,

    M. Chiang and T. Zhang, “Fog and IoT: An Overview of Research Opportunities,” IEEE Internet of Things Journal , 2016

    2016

  9. [19]

    VERID: Towards Verifiable IoT Data Management,

    X. Li, M. Wang, S. Shi, and C. Qian, “VERID: Towards Verifiable IoT Data Management,” in Proceedings of ACM/IEEE IoTDI , 2019

    2019

  10. [20]

    Blockchain verification and validation: Tech- niques, challenges, and research directions,

    D. Marijan and C. Lal, “Blockchain verification and validation: Tech- niques, challenges, and research directions,” Computer Science Review , vol. 45, p. 100492, 2022

    2022

  11. [21]

    A collaborative ledger storing model for lightweight blockchains based on chord ring,

    Z. Nie, J. Li, F. Duan, and Y . Lu, “A collaborative ledger storing model for lightweight blockchains based on chord ring,” The Journal of Supercomputing, vol. 80, no. 4, pp. 5593–5615, 2024

    2024

  12. [22]

    Efficient range query processing in peer-to-peer systems,

    D. S. Li, J. Cao, X. C. Lu, and K. C. C. Chan, “Efficient range query processing in peer-to-peer systems,” IEEE Transactions on Knowledge and Data Engineering , vol. 21, no. 1, pp. 78–91, 2009

    2009

  13. [23]

    Fissione: a scalable constant degree and low congestion dht scheme based on kautz graphs,

    D. Li, X. Lu, and J. Wu, “Fissione: a scalable constant degree and low congestion dht scheme based on kautz graphs,” in IEEE INFOCOM 2005, 2005

    2005

  14. [24]

    Dbst: A scalable peer-to-peer distributed information system supporting multi-attribute range query,

    S. Ahmed, A. Shome, and M. Biswas, “Dbst: A scalable peer-to-peer distributed information system supporting multi-attribute range query,” in 2021 ICSCT, 2021, pp. 1–6

    2021

  15. [25]

    Marques: Distributed multi-attribute range query solution using space filling curve on dths,

    A. Sen, A. S. M. S. Islam, and M. Y . S. Uddin, “Marques: Distributed multi-attribute range query solution using space filling curve on dths,” in 2015 NSysS, 2015, pp. 1–9

    2015

  16. [26]

    Effective peer-to-peer design for supporting range query in internet of things applications,

    B. Djellabi, M. Younis, and M. Amad, “Effective peer-to-peer design for supporting range query in internet of things applications,” Computer Communications, vol. 150, pp. 506–518, 2020

    2020

  17. [27]

    The case for learned index structures,

    T. Kraska, A. Beutel, E. H. Chi, J. Dean, and N. Polyzotis, “The case for learned index structures,” in ACM SIGMOD 2018 , 2018, pp. 489–504

    2018

  18. [28]

    Cdfshop: Exploring and optimizing learned index structures,

    R. Marcus, E. Zhang, and T. Kraska, “Cdfshop: Exploring and optimizing learned index structures,” in ACM SIGMOD 2020 , ser. SIGMOD ’20. New York, NY , USA: Association for Computing Machinery, 2020

    2020

  19. [29]

    p2psim, a simulator for peer-to-peer protocols,

    T. Gil, F. Kaashoek, J. Li, R. Morris, and J. Stribling, “p2psim, a simulator for peer-to-peer protocols,” 2003

    2003

  20. [30]

    Survey of research towards robust peer-to-peer networks: Search methods,

    J. Risson and T. Moors, “Survey of research towards robust peer-to-peer networks: Search methods,” Computer Networks, vol. 50, no. 17, 2006

    2006

  21. [31]

    Sosd: A benchmark for learned indexes,

    A. Kipf, R. Marcus, A. van Renen, M. Stoian, A. Kemper, T. Kraska, and T. Neumann, “Sosd: A benchmark for learned indexes,” arXiv preprint arXiv:1911.13014, 2019

    1911 arXiv

  22. [32]

    Network latency esti- mation for personal devices: A matrix completion approach,

    R. Zhu, B. Liu, D. Niu, Z. Li, and H. V . Zhao, “Network latency esti- mation for personal devices: A matrix completion approach,” IEEE/ACM Transactions on Networking , vol. 25, no. 2, pp. 724–737, 2017

    2017

  23. [33]

    Radixspline: a single-pass learned index,

    A. Kipf, R. Marcus, A. van Renen, M. Stoian, A. Kemper, T. Kraska, and T. Neumann, “Radixspline: a single-pass learned index,” in Proceedings of the Third International Workshop on Exploiting Artificial Intelligence Techniques for Data Management, ser. aiDM ’20. New York, NY ,...

    2020

  24. [34]

    The pgm-index: a fully-dynamic com- pressed learned index with provable worst-case bounds,

    P. Ferragina and G. Vinciguerra, “The pgm-index: a fully-dynamic com- pressed learned index with provable worst-case bounds,” VLDB 2020 , 2020

    2020

  25. [35]

    Efficient memory management for large language model serving with pagedattention,

    W. Kwon, Z. Li, S. Zhuang, Y . Sheng, L. Zheng, C. H. Yu, J. Gonzalez, H. Zhang, and I. Stoica, “Efficient memory management for large language model serving with pagedattention,” inProceedings of the 29th Symposium on Operating Systems Principles , 2023, pp. 611–626

    2023

  26. [36]

    Loogle: Can long- context language models understand long contexts?

    J. Li, M. Wang, Z. Zheng, and M. Zhang, “Loogle: Can long- context language models understand long contexts?” arXiv preprint arXiv:2311.04939, 2023

    2023 arXiv

  27. [37]

    Gen- torrent: Scaling large language model serving with an overley network,

    F. Fang, Y . Hua, S. Wang, R. Zhou, Y . Liu, C. Qian, and X. Zhang, “Gen- torrent: Scaling large language model serving with an overley network,” arXiv preprint arXiv:2504.20101 , 2025

    2025

  28. [38]

    Kademlia: A peer-to-peer information system based on the xor metric,

    P. Maymounkov and D. Mazieres, “Kademlia: A peer-to-peer information system based on the xor metric,” in International Workshop on Peer-to- Peer Systems. Springer, 2002, pp. 53–65

    2002

  29. [39]

    Ipfs/kubo: An ipfs implementation in go

    Ipfs, “Ipfs/kubo: An ipfs implementation in go.” [Online]. Available: https://github.com/ipfs/kubo

  30. [40]

    Prefix hash tree: An indexing data structure over distributed hash tables,

    S. Ramabhadran, S. Ratnasamy, J. M. Hellerstein, and S. Shenker, “Prefix hash tree: An indexing data structure over distributed hash tables,” in Proceedings of the 23rd ACM symposium on principles of distributed computing, vol. 37. St. John’s Newfoundland, Canada, 2004

    2004

  31. [41]

    An adaptive protocol for efficient support of range queries in dht-based systems,

    J. Gao and P. Steenkiste, “An adaptive protocol for efficient support of range queries in dht-based systems,” in Proceedings of the 12th IEEE International Conference on Network Protocols, 2004. ICNP 2004. IEEE, 2004, pp. 239–250

    2004

  32. [42]

    Alex: an updatable adaptive learned index,

    J. Ding, U. F. Minhas, J. Yu, C. Wang, J. Do, Y . Li, H. Zhang, B. Chandramouli, J. Gehrke, D. Kossmann et al. , “Alex: an updatable adaptive learned index,” in ACM SIGMOD 2020 , 2020, pp. 969–984

    2020

  33. [43]

    Apex: a high-performance learned index on persistent memory,

    B. Lu, J. Ding, E. Lo, U. F. Minhas, and T. Wang, “Apex: a high-performance learned index on persistent memory,” arXiv preprint arXiv:2105.00683, 2021

    2021 arXiv

  34. [44]

    Updatable learned index with precise positions,

    J. Wu, Y . Zhang, S. Chen, J. Wang, Y . Chen, and C. Xing, “Updatable learned index with precise positions,” arXiv preprint arXiv:2104.05520 , 2021

    2021 arXiv

  35. [45]

    Xindex: a scalable learned index for multicore data storage,

    C. Tang, Y . Wang, Z. Dong, G. Hu, Z. Wang, M. Wang, and H. Chen, “Xindex: a scalable learned index for multicore data storage,” in 25th ACM SIGPLAN, 2020, pp. 308–320

    2020

  36. [46]

    Finedex: a fine-grained learned index scheme for scalable and concurrent memory systems,

    P. Li, Y . Hua, J. Jia, and P. Zuo, “Finedex: a fine-grained learned index scheme for scalable and concurrent memory systems,” VLDB 2021, 2021

    2021

  37. [47]

    A survey on learning to hash,

    J. Wang, T. Zhang, N. Sebe, H. T. Shen et al., “A survey on learning to hash,” IEEE transactions on pattern analysis and machine intelligence , vol. 40, no. 4, pp. 769–790, 2017

    2017

  38. [48]

    Hash function generation by neural network,

    M. Tur ˇcaník and M. Javurek, “Hash function generation by neural network,” in 2016 NTSP, 2016, pp. 1–5. 11

    2016

  39. [49]

    Order preserving hashing for approximate nearest neighbor search,

    J. Wang, J. Wang, N. Yu, and S. Li, “Order preserving hashing for approximate nearest neighbor search,” in 21st ACM Multimedia , 2013, pp. 133–142

    2013

  40. [50]

    Can learned models replace hash functions?

    I. Sabek, K. Vaidya, D. Horn, A. Kipf, M. Mitzenmacher, and T. Kraska, “Can learned models replace hash functions?” Proc. VLDB Endow. , vol. 16, no. 3, p. 532–545, nov 2022

    2022

  41. [51]

    A seven-dimensional analysis of hashing methods and its implications on query processing,

    S. Richter, V . Alvarez, and J. Dittrich, “A seven-dimensional analysis of hashing methods and its implications on query processing,”PVLDB, vol. 9, no. 3, pp. 96–107, 2015

    2015

  42. [52]

    Keep the cost down: A review on methods to optimize llm’s kv-cache consumption,

    L. Shi, H. Zhang, Y . Yao, Z. Li, and H. Zhao, “Keep the cost down: A review on methods to optimize llm’s kv-cache consumption,” arXiv preprint arXiv:2407.18003, 2024

    2024 arXiv

  43. [53]

    Cacheblend: Fast large language model serving for rag with cached knowledge fusion,

    J. Yao, H. Li, Y . Liu, S. Ray, Y . Cheng, Q. Zhang, K. Du, S. Lu, and J. Jiang, “Cacheblend: Fast large language model serving for rag with cached knowledge fusion,” in Proceedings of the Twentieth European Conference on Computer Systems , 2025, pp. 94–109

    2025

  44. [54]

    Milvus: A purpose-built vector data management system,

    J. Wang, X. Yi, R. Guo, H. Jin, P. Xu, S. Li, X. Wang, X. Guo, C. Li, X. Xu et al., “Milvus: A purpose-built vector data management system,” in Proceedings of the 2021 International Conference on Management of Data, 2021, pp. 2614–2627

    2021

  45. [55]

    Pinecone

    Pinecone, “Pinecone.” [Online]. Available: https://www.pinecone.io/

  46. [56]

    Available: https://ai.meta.com/tools/faiss/

    [Online]. Available: https://ai.meta.com/tools/faiss/

  47. [57]

    Retrieval- augmented generation for knowledge-intensive nlp tasks,

    P. Lewis, E. Perez, A. Piktus, F. Petroni, V . Karpukhin, N. Goyal, H. Küttler, M. Lewis, W.-t. Yih, T. Rocktäschel et al. , “Retrieval- augmented generation for knowledge-intensive nlp tasks,” Advances in neural information processing systems , vol. 33, pp. 9459–9474, 2020

    2020

  48. [58]

    Vector database management techniques and systems,

    J. J. Pan, J. Wang, and G. Li, “Vector database management techniques and systems,” in Companion of the 2024 International Conference on Management of Data , 2024, pp. 597–604

    2024

  49. [59]

    Infinite-llm: Efficient llm service for long context with distattention and distributed kvcache,

    B. Lin, C. Zhang, T. Peng, H. Zhao, W. Xiao, M. Sun, A. Liu, Z. Zhang, L. Li, X. Qiu et al. , “Infinite-llm: Efficient llm service for long context with distattention and distributed kvcache,” arXiv preprint arXiv:2401.02669, 2024

    2024 arXiv

  50. [60]

    Kv-runahead: Scalable causal llm inference by parallel key-value cache generation,

    M. Cho, M. Rastegari, and D. Naik, “Kv-runahead: Scalable causal llm inference by parallel key-value cache generation,” in Forty-first Interna- tional Conference on Machine Learning , 2024

    2024

  51. [61]

    Preserve: Prefetching model weights and kv-cache in distributed llm serving,

    A. C. Yüzügüler, J. Zhuang, and L. Cavigelli, “Preserve: Prefetching model weights and kv-cache in distributed llm serving,” arXiv preprint arXiv:2501.08192, 2025

    2025 arXiv

  52. [62]

    Edge ai: a survey,

    R. Singh and S. S. Gill, “Edge ai: a survey,” Internet of Things and Cyber- Physical Systems, vol. 3, pp. 71–92, 2023

    2023

  53. [63]

    Communication- efficient edge ai: Algorithms and systems,

    Y . Shi, K. Yang, T. Jiang, J. Zhang, and K. B. Letaief, “Communication- efficient edge ai: Algorithms and systems,” IEEE Communications Surveys & Tutorials, vol. 22, no. 4, pp. 2167–2191, 2020

    2020

  54. [64]

    Algorithmic Nuggets in Content Delivery,

    B. M. Maggs and R. K. Sitaraman, “Algorithmic Nuggets in Content Delivery,” ACM SIGCOMM Computer Communication Review , 2015

    2015

  55. [65]

    Blockchain challenges and opportunities: A survey,

    Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain challenges and opportunities: A survey,” International journal of web and grid services, vol. 14, no. 4, pp. 352–375, 2018

    2018

  56. [66]

    A survey of blockchain from the perspectives of applications, challenges, and opportunities,

    A. A. Monrat, O. Schelén, and K. Andersson, “A survey of blockchain from the perspectives of applications, challenges, and opportunities,” Ieee Access, vol. 7, pp. 117 134–117 151, 2019. 12 APPENDIX A. Benchmark Details In our microbenchmark, the Centralized Table (C-Table) ba...

    2019

  57. [67]

    Specifi- cally, we apply LEAD on a distributed collaborative ledger sys- tem [21]

    Case study III: Blockchain application: We perform a case study to show how LEAD can improve data retrieval performance in practice for blockchain applications. Specifi- cally, we apply LEAD on a distributed collaborative ledger sys- tem [21]. Blockchain applications, particul...

  58. [68]

    Learned Hash Function

    In contrast, for LEAD, the CIDs were managed by the learned hash function within SHA-1’s hashing space. The key operation tested was a typical user request for a resource. In this scenario, an edge server retrieves all the blocks containing the metadata for the requested resou...

  59. [69]

    It indicates that learned models produce a similar or reduced number of hash collisions compared to traditional hash functions

    discusses the potential to replace traditional hash functions with learned models. It indicates that learned models produce a similar or reduced number of hash collisions compared to traditional hash functions. There has been no exploration into integrating learned index struc...

  60. [70]

    Vector Databases and Retrieval-Augmented Generation: Vector search engines such as Milvus [54], Pinecone [55], and Meta’s FAISS [56] shard billions of embeddings but rely on static partitioners or HNSW graphs that must be rebuilt as data drift. By hashing product-quantization ...

  61. [71]

    Large-Scale LLM Serving and Decentralized Inference: Looking forward, we see LEAD as a compelling sub- 15 strate for next-generation AI serving stacks, especially for sharding the ever-growing KV caches and model adapters that dominate large-language-model (LLM) inference. By ...

  62. [72]

    LEAD can hash composite keys 〈device-ID, timestamp 〉 so that adjacent time ranges map to adjacent roadside or gateway peers

    Edge-AI and IoT Data Lakes: Massive edge deploy- ments generate time-series telemetry that must be queried by geographic window or recency [62], [63]. LEAD can hash composite keys 〈device-ID, timestamp 〉 so that adjacent time ranges map to adjacent roadside or gateway peers. T...

  63. [73]

    demand-responsive

    Content-Delivery Networks and caches: Modern CDNs already rely on consistent hashing to place objects across Point of Presences (PoPs) [9], but these static hashes ignore temporal popularity skew, leading to cache imbalance and cold-start misses. Integrating LEAD at the cache-...

  64. [74]

    Cross-chain and indexing: Inter-ledger stacks need fast, ordered look-ups across heterogeneous blockchains [65], [66]. A LEAD overlay per chain—bridged via light-client proofs—would supply uniform range queries over block-height or asset-ID without a trusted indexer, complemen...

  65. [75]

    Harden LEAD against adversarial behaviour: A promis- ing complementary effort is to harden LEAD against adversarial behaviour. Because the learned hash derives from live data, attackers might (i) inject skewed keys to distort the CDF, (ii) return bogus model parameters to misr...

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.