BlockSearch: Block-Centric Retrieval

Updated 5 July 2026

BlockSearch is a block-centric computational paradigm that organizes search, ranking, and synchronization around data blocks rather than isolated items.
It is applied across entity resolution, long-document ranking, sparse retrieval, blockchain optimization, and distributed ledger synchronization to improve processing efficiency.
By constructing, scoring, and selectively expanding blocks, BlockSearch reduces computational overhead while maintaining high accuracy in complex search spaces.

Searching arXiv for papers using or defining “BlockSearch” and closely related block-centric retrieval/blocking methods. BlockSearch denotes a family of block-centered computational paradigms in which search, selection, synchronization, or allocation is organized around blocks rather than isolated atomic items. In recent arXiv literature, the label appears in several technically distinct settings: candidate generation for entity resolution, key-block selection for long-document ranking, block-level sparse retrieval and million-token in-context retrieval, block-level text spotting, online block packing and builder/searcher mechanisms in blockchains, and block synchronization in BFT systems (Wang et al., 2024, Li et al., 2021, Mallia et al., 2024, Bannur et al., 2024, Eliezer et al., 16 Jul 2025, Kichidis et al., 19 Nov 2025, Gollapudi et al., 1 Jul 2026). This suggests that BlockSearch is best understood not as a single standardized algorithm, but as a recurring systems pattern in which blocks are first defined, then scored or certified, and finally used to restrict expensive downstream computation to the most relevant, available, or profitable regions of the search space.

1. Conceptual scope and recurring structure

Across the literature, the word “block” refers to markedly different objects: candidate buckets of records in entity resolution, short document segments in information retrieval, document-ID ranges in sparse inverted indexes, multi-line text groups in scene text understanding, feasible transaction sets in blockchain optimization, and missing data objects in BFT synchronization. What unifies these usages is not the data type, but the control strategy: a large space is partitioned into blocks, blocks are ranked or validated, and only a subset is explored in detail.

A common decomposition is visible across domains. First, blocks are constructed from local structure such as token overlap, punctuation-aware segmentation, storage conflicts, or document-ID ranges. Second, each block receives a local signal: a similarity score, an upper bound, a proof of availability, or a bid-derived welfare estimate. Third, a resource-aware policy decides whether to keep, expand, skip, or synchronize that block. This recurring decomposition is explicit in learned entity blocking, key-block long-document ranking, Block-Max Pruning, Beluga’s block synchronizer, and the million-token LM retriever named BlockSearch (Wang et al., 2024, Li et al., 2024, Mallia et al., 2024, Kichidis et al., 19 Nov 2025, Gollapudi et al., 1 Jul 2026).

Context	Block unit	Representative systems
Entity resolution	Candidate record bucket	NLSHBlock, HDB, Token Blocking, AtC, PIS
Long-document IR	Selected text block or passage	KeyB, KeyB2
Sparse / in-context retrieval	Document-ID range or in-context document block	BMP, BlockSearch
Scene text understanding	Multi-line text block	BTS-LLM
Blockchain systems	Feasible transaction block or missing consensus block	Online Block Packing, Boost+, Beluga, BlockSDN-VC

2. Entity blocking and record linkage

In entity resolution, blocking is the first stage of a two-phase pipeline: blocking generates a reduced candidate set, and matching applies a more expensive classifier only to candidate pairs. NLSHBlock formulates this as a learned locality-preserving problem. Records are serialized with [COL] and [VAL] markers, encoded by RoBERTa-base with maximum length 128 into 768-dimensional L2-normalized embeddings, then passed through a 768 → 768 → 1 projector trained with an LSH-inspired triplet loss using $R = 0.01$ and $c = 3$ . After training, the projector can be discarded and blocking is performed by $k$ -NN search over the fine-tuned embeddings using ANN backends such as HNSW or FAISS (Wang et al., 2024).

The empirical motivation is that practical ER rarely aligns with fixed lexical metrics such as Jaccard. NLSHBlock therefore learns a task-specific similarity space from labeled pairs or augmentation. On the Magellan benchmarks, the supervised variant reports F1 values of 0.916 on Abt–Buy, 0.162 on Amazon–Google, and 0.080 on Walmart–Amazon at target recall levels, while the candidate set on Abt–Buy is reduced to 1,092 pairs versus 2,184 for Sparkly and 57,781 for HDB. In semi-supervised matching, replacing Sudowoodo’s original blocking with NLSHBlock improves F1 by +2.2 on average over five datasets using only 500 labeled pairs (Wang et al., 2024).

At much larger scale, Hashed Dynamic Blocking extends Dynamic Blocking by combining hashed blocking keys, MinHash-based LSH, Count-Min Sketch approximate counting, Bloom filters, and XOR-based membership deduplication. Its LSH configuration is governed by the standard MinHash banding probability

$LSH(b,w,j) = 1 - (1 - j^w)^b,$

and the system is designed to minimize data movement by representing records only through a 64-bit record ID and 128-bit hashed blocking keys. On a 530 million row industrial dataset, HDB detects 68 billion candidate pairs in less than three hours at a cost of \$307, while the paper reports linear time complexity scaling in the 1M–107M range (Borthwick et al., 2020).

A complementary line of work evaluates classical schema-agnostic and schema-aware blockers for Web entities. “Benchmarking Blocking Algorithms for Web Entities” compares Token Blocking, Attribute Clustering Blocking, and Prefix–Infix(–Suffix) Blocking, and shows that effectiveness depends strongly on whether datasets are “central” and vocabulary-aligned or “peripheral” and heterogeneous. Token Blocking is a robust schema-agnostic baseline, Attribute Clustering improves efficiency when attribute vocabularies are aligned, and PIS is effective when URI naming policies are informative (Efthymiou et al., 2020).

3. Long-document ranking and block-based retrieval engines

In long-document information retrieval, BlockSearch refers to selecting a small set of key blocks from a long document before applying a heavy ranker. KeyB segments documents with the CogLTX dynamic-programming algorithm into blocks of at most 63 tokens, computes local query-block scores using TF–IDF, BM25, or a BERT block scorer (“BinB”), selects the highest-scoring blocks under a 512-token budget, restores them to document order, and then feeds the synthetic short document to Vanilla BERT or PARADE. Training uses a pairwise hinge loss over positive and negative documents (Li et al., 2021).

This block-pre-ranking stage materially changes the efficiency–effectiveness trade-off. On Robust04, KeyB(vBERT) $_{\text{BinB}}$ reaches MAP 0.2722 and nDCG 0.4768, while KeyB(PARADE5) $_{\text{BinB2}}$ reaches MAP 0.2779 and nDCG 0.4778 using only five passages. On TREC 2019 Deep Learning document ranking, KeyB(vBERT) $_{\text{BinB}}$ reports NDCG@10 0.707 and MAP 0.281, exceeding IDCM at 0.679 and 0.273, respectively (Li et al., 2021).

KeyB2 revisits the same idea in the LLM regime. Documents are again segmented into 63-token blocks, but local block scoring can be performed by BM25, a cross-encoder, or a bi-encoder, and only the top blocks filling a 480-token budget are passed to a Llama-based reranker. The final LLM score is produced from the last token of the sequence query: {Q} document: {D'}</s>. On TREC DL19, KeyB2(Llama3) $_{\text{cross}}$ reaches NDCG@10 0.731 and MAP 0.298, while on fine-tuned Robust04 it reaches P@20 0.4799, NDCG@20 0.5593, and MAP 0.2923. The same work reports lower reranking time and lower GPU memory than RankLLaMA, while preserving the central KeyB insight that only a small fraction of a long document should reach the expensive model (Li et al., 2024).

A related but structurally different retrieval lineage uses fixed document-ID blocks as the unit of pruning rather than semantic text segments. “Faster Learned Sparse Retrieval with Block-Max Pruning” partitions the corpus into blocks of $b$ consecutive document IDs, precomputes per-term block maxima $\mathrm{BM}(t,j)$ , and evaluates block upper bounds

$c = 3$ 0

Blocks are processed in decreasing $c = 3$ 1, and exact top- $c = 3$ 2 retrieval is safe once the current threshold $c = 3$ 3 satisfies $c = 3$ 4. On SPLADE, safe retrieval with $c = 3$ 5 reports 10.5, 23.1, and 66.9 ms for $c = 3$ 6, and approximate retrieval can reach 1.6 ms with RR@10 35.01 using a raw BM index (Mallia et al., 2024).

4. Multimodal BlockSearch and million-token in-context retrieval

In scene text understanding, block-level text spotting treats multi-line blocks rather than characters, words, or isolated lines as the semantic unit. BTS-LLM is a three-stage pipeline: line detection and grouping with Unified Detector, line recognition with PARSeq retrained to support spaces, and an LLM-based stage that orders lines within each block and may correct OCR errors using semantic context. The prompt is framed as a Python-style function your_task receiving line texts and bounding boxes; if no meaningful ordering can be inferred, the system falls back to geometric ordering (Bannur et al., 2024).

The evaluation emphasizes block-level reconstruction quality rather than line detection alone. On a HierText-derived block-level benchmark, BTS-LLM reports Sentence-Transformer cosine 0.7407, BERTScore 0.7862, BLEURT 0.6123, Jaro-Winkler similarity 0.8502, Ratcliff-Obershelp 0.7870, and normalized Levenshtein distance 0.2614. The significance is that the block, rather than the line, becomes the retrieval and reconstruction unit for downstream translation or search (Bannur et al., 2024).

The paper “Can LLMs Actually Retrieve In-Context? Drowning in Documents at Million Token Scale” introduces a 0.6B LM retriever named BlockSearch. It uses random four-digit document identifiers, block-sparse document attention, in-batch shared corpora, and an on-policy auxiliary loss for digit decoding. The system is trained on corpora of roughly 25k tokens but evaluated up to about one million tokens. The paper diagnoses failure at extreme lengths as an attention dilution effect: even when some heads still rank the gold document highest in pre-softmax score, the gold document’s normalized contribution collapses because irrelevant documents dominate the softmax denominator (Gollapudi et al., 1 Jul 2026).

Two interventions are then introduced: length-aware attention adjustments such as SSMax-style rescaling and document-level sparse attention routing. With these modifications, the model matches dense retrieval on widely studied benchmarks such as MS MARCO and NQ at the million-token scale, while outperforming the concurrent model MSA despite being 7 times smaller. On LIMIT, which requires a different notion of similarity, it significantly outperforms dense retrieval and achieves a 3 times higher score (Gollapudi et al., 1 Jul 2026).

5. Blockchain block allocation and block building

In blockchain optimization, BlockSearch often denotes search over feasible transaction sets under capacity, time, and incentive constraints. “Online Block Packing” formalizes this as an online, multi-period, multidimensional knapsack with block capacity vector $c = 3$ 7, transaction demand vectors $c = 3$ 8, and quasi-patient time-discounted values $c = 3$ 9. The paper proves that the greedy fractional block-by-block algorithm is $k$ 0-competitive, gives $k$ 1-approximation for constant $k$ 2 without slackness, and provides a constant-factor online approximation with $k$ 3 slackness and extension for fully patient bidders in arbitrary dimension (Eliezer et al., 16 Jul 2025).

This formulation turns “block search” into a welfare-maximizing search over feasible block contents. The paper also proves lower bounds: even with two resources and fully patient bidders, any online algorithm must lose a constant fraction of offline welfare, and myopically reasonable algorithms asymptotically face a $k$ 4 barrier as $k$ 5 grows. The result is a mathematically explicit notion of BlockSearch as online block selection under adversarial arrivals (Eliezer et al., 16 Jul 2025).

Boost+ addresses a different part of the blockchain stack: who gets to build the block and under what incentives. It decouples transaction collection from transaction ordering via a TEE-based mechanism, gives all builders equal access to collected transactions, and compares builder algorithms against a default algorithm. The mechanism makes truthful bidding a dominant strategy for all builders; for searchers, truthful reporting is dominant whenever the default algorithm dominates competing builders, and remains dominant for all conflict-free transactions even when builders may win. The empirical default algorithm finds the best block in 53.2% of sampled blocks, with median absolute gap 0.0033 ETH and median relative gap 8.6% when not best (Zhang et al., 3 Feb 2026).

6. Block synchronization and propagation in distributed ledgers

Beluga shifts BlockSearch from “which transactions belong in a block” to “how missing blocks are located and retrieved.” It introduces the block synchronizer as a modular abstraction inside modern BFT stacks, with explicit properties of Round-Progression, Round-Termination, Block availability, and Causal availability. The paper also identifies a new pull-induction attack in which an adversary selectively withholds blocks so that honest validators issue redundant, uncoordinated pulls, exhausting bandwidth and stalling progress (Kichidis et al., 19 Nov 2025).

Beluga answers this with a scarcity-aware synchronizer combining best-effort push, reputation-guided parent selection, implicit proof-of-availability (ImPoA), and a hybrid live-versus-bulk pull policy. Integrated into Mysticeti, Beluga sustains optimal optimistic-path performance and, under attack, delivers up to 3x higher throughput and 25x lower latency than prior designs; the paper states that the Sui blockchain adopted Beluga in production (Kichidis et al., 19 Nov 2025).

At the network layer, BlockSDN-VC treats transaction dissemination itself as a block-search problem over propagation paths. The system centralizes virtual-coordinate computation and forwarding control in an SDN controller, uses K-means clustering over coordinates, and combines controller-aware early outburst with cluster kick-off and random escape edges. In geo-distributed simulations, BlockSDN-VC cuts median latency by up to 62% and accelerates convergence fourfold over prior schemes while keeping control-plane overhead under 3%. In a real blockchain environment, it increases confirmed-transaction throughput by 17% under adversarial workloads without modifying existing clients (Jia et al., 30 Sep 2025).

7. Extended usages, limits, and research directions

The term also appears in more metaphorical but structurally related senses. “Single Block On” describes a BlockSearch-type system for cross-platform privacy enforcement: search and match identities across applications using configurable strictness levels, CRML, and SSO/LDAP/REST integration so that a user can block once and have the block propagated everywhere. “(B)LOCKBOX” describes a BlockSearch-style layer over software building blocks, code hashes, devices, and execution traces stored across a public software/device blockchain and a non-public execution-flow blockchain (Ranjan et al., 12 Jun 2025, Heiland et al., 2022).

Across these literatures, several limits recur. Learned block selectors often outperform fixed heuristics but weaken formal guarantees; NLSHBlock explicitly lacks classical $k$ 6 LSH guarantees, and Boost+ leaves searcher sybil resistance open. Block-based IR systems trade semantic focus against the risk of discarding globally relevant but locally weak evidence. Million-token retrieval exposes softmax normalization as a scaling bottleneck rather than a simple model-capacity issue. Blockchain synchronizers can achieve optimal common-case latency only if block search under faults is explicitly resource-aware (Wang et al., 2024, Zhang et al., 3 Feb 2026, Gollapudi et al., 1 Jul 2026, Kichidis et al., 19 Nov 2025).

Future directions identified in the literature include extending neural LSH beyond entity resolution and studying formal links between learned hashing losses and classical LSH guarantees, speeding learned block selection in long-document IR, measuring downstream gains from block-level OCR reconstruction, developing privacy-preserving identity resolution for interoperable block lists, and strengthening mechanism design against searcher sybil attacks in TEE-based block building (Wang et al., 2024, Li et al., 2021, Bannur et al., 2024, Ranjan et al., 12 Jun 2025, Zhang et al., 3 Feb 2026). As a research theme, BlockSearch is therefore less a single method than a cross-domain abstraction for making large structured spaces tractable by reasoning at the level of blocks.