{"id":"1d79faf7-fd99-4779-8580-f2dad6d09fbf","arxiv_id":"2506.01614","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"high","formal_verification":"none","parameter_count":4,"one_line_summary":"A contrastive-learning embedding of transaction outputs is proposed to route incoming transactions to the shard holding their parent UTXOs, with accuracy claims against random allocation but no throughput validation.","lead":"This paper proposes using a machine learning model trained on historical transaction data to decide which validator shard should process a new Bitcoin-like transaction, aiming to reduce cross-shard communication. A generalist might read it because it applies contrastive learning to one of blockchain scaling's core bottlenecks: locating the parent outputs a transaction spends.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The no-lookup routing claim depends on parent-outpoint features that a spending transaction does not contain; identical child transactions referencing different parents are indistinguishable, so exact parent sharding is impossible.","rationale":"The reader's weakest assumption is exactly the load-bearing issue: Section III.B assumes that a feature vector built from data 'available with the incoming transaction' is sufficient to place a child transaction near its specific parent outpoint. In Bitcoin, the spending input does not carry the parent's amount or locking script, so the local features in Table I cannot be populated for the referenced outpoint without a lookup. This is not a disagreement with consensus or a style concern; it is an information-theoretic gap in the central mechanism. Two child transactions that differ only in which parent outpoint they reference are indistinguishable to the model, so exact parent-locating routing is impossible. The reported accuracy metrics measure whether parent-child pairs fall in the same cluster on held-out training-like data, but if the features are dominated by script type and output statistics, high co-location can occur without recovering the specific parent-child relationship needed to avoid cross-shard communication. The K-nearest-neighbor fallback in Section IV.A also acknowledges that the predicted shard is often wrong and that additional shards must be consulted, which reintroduces communication and undermines the elimination of lookups. The paper provides no code, hyperparameters, or system-level benchmarks, but the feature-sufficiency problem is sufficient on its own to reject the central claim as presently stated. Therefore the reader's REJECT verdict remains appropriate.","tokens_in":7062,"tokens_out":2873,"duration_ms":35250,"concrete_test":"Take a held-out child transaction and reconstruct its feature vector using only the fields present in its serialized bytes, as Section III.B claims. Then create two synthetic child transactions that are identical in every available feature (same input/output counts, same script types, same output amounts, same positional encodings) but reference parent UTXOs selected from two different learned shards. Feed both through the trained encoder and clustering model; if they receive the same shard assignment while their actual parents reside in different shards, the no-lookup routing claim fails for at least one of them. This directly tests whether the feature set can separate distinct parents that are indistinguishable from the incoming transaction's perspective.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that the model embeds parent-child spending patterns into its parameters and routes incoming transactions to the shard containing their parent UTXOs using only information available with the incoming transaction. This requires that a child transaction's feature vector be sufficient to identify, or at least locate, its specific parent outpoint. Section III.B and Table I violate this requirement: the 'Local' features are the amount and locking-script size of the outpoint, but a Bitcoin spending input contains only a txid and an output index, not the parent output's amount or script. Therefore, for a child transaction input, those local features are unavailable without a real-time lookup. The only parent-relevant information in the incoming transaction is generic: script types, output statistics, and positional encodings. Two child transactions that are byte-for-byte identical except for the txid:vout they reference will have identical feature vectors and hence identical embeddings and identical shard predictions, even if their parent UTXOs live in different shards. Thus the model cannot eliminate real-time parent lookups in general. The reported >90% co-location accuracy in Fig. 3 likely reflects clustering by script type and other coarse in-transaction statistics rather than true parent-child routing; this does not support the abstract's claim of reduced cross-shard communication and increased throughput. The paper's evaluation measures an embedding objective on held-out transaction pairs, not the downstream routing or system-level communication cost, and no code or baselines are provided, but the feature-sufficiency gap is the more fundamental obstacle.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a machine-learning framework for partitioning the UTXO set of a UTXO-based blockchain into shards and routing incoming transactions to the shard predicted to contain their parent UTXOs. The method encodes transaction outpoints using global features, local outpoint features, and positional encodings (Table I); trains an MLP encoder with triplet loss where positive pairs are parent-child outpoints and negatives are unrelated outpoints (Section III.C); and clusters the resulting embeddings into shards. The evaluation, on a BSV dataset of roughly 100 million transactions split 80/20, measures the probability that parent-child outpoints are assigned to the same shard (Section IV.A, Fig. 3) and reports distributions of positive-pair similarities and distances (Figs. 4-5). The central claim is that the model embeds parent-child spending patterns in its parameters and therefore eliminates real-time parent transaction lookups during inference, reducing cross-shard communication and increasing throughput.","tokens_in":7329,"tokens_out":4513,"duration_ms":47555,"significance":"The idea of learning a static routing function from transaction-local features is potentially interesting, and the scale of the historical dataset (6,000 BSV blocks, ~103 million transactions) is a genuine strength. However, the stated contribution—lookup-free routing to the exact parent UTXO's shard—is not supported by the feature design, and the evaluation is circular with respect to the training objective. The paper reports no throughput, latency, cross-shard ratio, or end-to-end communication measurements, and it does not compare against hash-based sharding (Teranode/Monoxide) or graph-partitioning baselines (Metis/CLPA) that it cites. If the result were to hold, it would be a modest algorithmic contribution to blockchain sharding, but as presented the empirical evidence does not establish the claimed scalability benefits.","major_comments":[{"comment":"The claimed lookup-free inference is not supported by the feature design. For a spending transaction, the only parent-specific information in the input is the referenced txid and output index, but the feature vector in Table I contains no parent txid, no output index, and no amount or locking-script data of the referenced parent UTXO: the 'Local' features describe the outpoint being considered (its own amount and locking-script size), not the parent outpoint being spent. Consequently, two structurally identical transactions that reference different parent UTXOs receive identical feature vectors and identical embeddings, so the model cannot route them to different parent shards. This is an information-theoretic limitation of the proposed architecture, not a tuning issue, and it invalidates the abstract's claim that the model 'eliminates the need for costly, real-time parent transaction lookups.' At best, the model can cluster by coarse in-transaction statistics and script types, which does not provide exact parent-child routing.","section":"III.B, Table I"},{"comment":"The evaluation is circular with respect to the central claim. Accuracy is defined as the probability that a parent-child outpoint pair lands in the same shard, which is exactly the quantity minimized by the triplet loss in Eq. (3) on the same historical dataset (80/20 train/test split, Section III.D). A high value on this metric shows only that the model satisfies its own training objective on held-out data; it does not measure cross-shard communication overhead, validation latency, or throughput. The paper reports no end-to-end measurements, no cross-shard ratio, and no comparison with the hash-based sharding of Teranode/Monoxide or with graph-partitioning baselines (Metis, CLPA) discussed in Section II, so the abstract's throughput and scalability conclusions are unsubstantiated.","section":"IV.A, Fig. 3"},{"comment":"The K-nearest-neighbor result is not an independent validation and, as stated, undermines the routing claim. The 'nearest shards' are determined by the same learned embedding distances used for the initial prediction, so improved K>0 accuracy is a self-consistency measure on the training objective rather than an evaluation of communication cost. Moreover, checking the 3 or 9 nearest shards to fetch the parent UTXO requires querying multiple shards before validation, which reintroduces the cross-shard communication that the method claims to eliminate; the paper does not quantify how this affects the purported savings.","section":"IV.A, K-nearest-neighbor paragraph"}],"minor_comments":[{"comment":"The heading 'Duel-Model Architecture' contains a typo; it should read 'Dual-Model Architecture.'","section":"III.A"},{"comment":"In the Related Work section, 'encodithrough' is a typo for 'encoding through.'","section":"II"},{"comment":"The text says 'Accuracy was measured by the probability of correctly assigning parent-child to the same shard (Fig. 2)', but Fig. 2 illustrates negative samples; the accuracy plot is Fig. 3. The figure references are mismatched.","section":"IV.A"},{"comment":"The phrase 'resulting in trivial solutions learnt (e.g., c)' refers to an undefined collapsed-embedding symbol; the collapsed constant should be defined explicitly (e.g., c as a constant vector) or the notation introduced.","section":"III.C.2"},{"comment":"The positional encoding feature is described only as 'Positional Encoding Vector for a given outpoint position within a transaction', but the construction is not explained; please specify how positional encodings are generated for outpoints and why they differentiate 'identical outpoints.'","section":"III.B, Table I"},{"comment":"The statement 'we saw ~10 distinct point clusters in the embedding space' is anecdotal and unsupported by any cluster-analysis or visualization; either provide a reproducible clustering analysis or remove the claim.","section":"IV.A"}],"recommendation":"reject","confidential_remarks":"The paper has a fundamental feature-information gap: the input representation does not contain the parent-specific information needed for exact lookup-free routing, and the evaluation metric is essentially the training objective itself. These are load-bearing issues that cannot be fixed within the manuscript's current scope. I recommend rejection, though the authors might reframe the work as an exploratory study of learned transaction-outpoint clustering and its correlation with spending behavior, with explicit acknowledgment of the routing limitations."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"First, the punchline: the paper's central claim — that a UTXO node can route transactions to shards using only features available in the incoming transaction, eliminating parent lookups — is not supported by the feature set. The local features listed in Table I (amount, locking-script size) cannot be computed for a parent outpoint at spend time, because a Bitcoin input carries only a txid and output index. Two byte-identical child transactions spending different parents therefore produce identical feature vectors, making exact parent-shard routing impossible.\n\nWhat is genuinely new: applying contrastive metric learning (triplet loss with online semi-hard mining) to UTXO outpoints for shard affinity is not present in the cited sharding literature, and the Bag-of-OP-Codes encoding is a domain-appropriate feature. The paper correctly identifies cross-shard parent-child dependencies as a real bottleneck in UTXO sharding.\n\nWhat the paper does well: the writing is clear, the training formulation is standard and sensible, and the random-allocation baselines are a reasonable sanity check. The plots show the embedding does separate parent-child pairs on the training objective.\n\nThe soft spots are, however, load-bearing. The feature-sufficiency problem is fundamental, not cosmetic. Even if you granted the feature vectors, the evaluation only measures the probability that held-out parent-child pairs land in the same cluster — which is exactly the objective minimized during training. There are no measurements of throughput, latency, cross-shard communication ratio, or comparisons with hash-based or graph-based sharding. No code or hyperparameters are provided, so the results are not reproducible. The nearest-neighbor tricks in Fig. 3 are a useful diagnostic but do not rescue the routing claim.\n\nSummary: this is a plausible exploratory idea that currently fails on its central promise. A serious referee would need substantial rework — at minimum a clear statement of what features are actually available at routing time, and an evaluation against a real system metric.\n\nMy recommendation: desk-reject in current form. The idea might be worth a rewrite, but as submitted the mechanism is broken and the evidence is thin.","headline":"The no-lookup routing claim is impossible with the proposed features, because a spending transaction does not contain its parent's local features — the idea is novel but the mechanism is broken.","tokens_in":7888,"tokens_out":5063,"would_cite":false,"duration_ms":51278,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims a UTXO node can route each incoming transaction to the shard containing its parent UTXOs using only features of the incoming transaction, with no blockchain lookups during inference.","keywords":["UTXO","blockchain sharding","contrastive learning","triplet loss","transaction routing","Bitcoin scalability","embedding","parent-child spending"],"falsifier":"The decisive check is to count, on the held-out set, how often the true parent UTXO is the only candidate with the same local features used by the model (amount, locking-script size, OP-code bag); if the parent is usually not unique among candidates, no model can reach high same-shard accuracy at K=0 because the input lacks the parent's identity.","tokens_in":6841,"feed_emoji":"⛓️","tokens_out":10154,"duration_ms":102180,"temperature":0.7,"pith_summary":"The paper sets out to remove the most expensive step in validating a transaction on a UTXO-based blockchain: finding the parent UTXOs that the transaction spends. It claims that a neural encoder trained with contrastive learning can store parent-child spending relationships in its weights, so at inference time the features of an incoming transaction alone are enough to embed it near its parents and route it to the correct shard. If true, cross-shard communication would drop sharply, allowing a node to validate transactions in parallel and scale throughput without per-transaction database lookups. The supporting experiments on about 102.8 million BSV transactions report that learned shard assignment beats random allocation, with above 90% accuracy for up to about ten shards and strong recovery of misplaced parents by checking neighboring shards.","feed_headline":"A learned embedding routes Bitcoin transactions without parent lookups","feed_subtitle":"Training on past transactions lets a node place each new one next to its parent UTXOs—no database lookups needed.","key_machinery":"The load-bearing mechanism is a learned embedding space for transaction outpoints, produced by a dual-model architecture. First, a feature vector is assembled per outpoint from global transaction statistics (input and output counts, output-amount statistics, script-size aggregate, encodings of the top unlocking and locking scripts), local outpoint attributes (amount, locking-script size), a Bag of OP Codes encoding of the locking script, and a positional encoding of the outpoint's position in the transaction. A multi-layer perceptron encoder projects these vectors so that, under Euclidean distance, parent-child outpoints are close and unrelated outpoints are separated; this is trained with triplet loss using online selection of semi-hard negatives, with hard negatives introduced later. A clustering model then partitions the learned embedding space and assigns shard IDs, so routing becomes a nearest-cluster lookup in the embedding rather than a lookup into the blockchain database.","core_discovery":"The discovery the paper puts forward is that spending relationships in a UTXO ledger can be captured statically, as parameters of a neural embedding, rather than dynamically by querying the ledger. Treating each transaction outpoint as a feature vector built only from data available with the incoming transaction, the framework trains a multi-layer perceptron with triplet loss and online semi-hard-negative mining so that a child outpoint and its parent outpoint are close under Euclidean distance. Parent-child pairs serve as positives; unrelated outpoints serve as negatives; the learned weights then replace the need to fetch parent transaction data at inference time. A separate clustering model partitions the embedding space into shards, and the shard ID of a new outpoint's embedding decides which validation microservice receives the transaction. On BSV data from 6,000 blocks, totaling about 102.8 million transactions, the paper reports parent-child co-location accuracy well above random allocation, with more than 90% accuracy up to roughly 10 shards and improved recovery of misplaced parents by scanning the nearest clusters.","pith_inferences":["An implication the paper leaves implicit is that its reported accuracy ceiling near ten shards, which roughly matches the number of natural script-type clusters in the embedding, suggests the model may be co-locating by script and amount style as much as by exact lineage; retraining with shuffled parent-child labels would reveal how much true lineage information the features actually carry.","The same embedding space could be reused for tasks the paper lists as future work, such as spending-behavior classification and load balancing, because transactions with similar economic and script shapes would already sit close together in the learned metric.","A practical extension is to make the neighbor-shard fallback confidence-aware: when an incoming outpoint lands near a cluster boundary, the node could speculatively fetch from the next-nearest shard, trading a little communication for a large gain in the probability of finding the parent UTXO.","Live deployment would need to monitor distribution drift, since the model is trained on a historical window and then frozen; a testable safeguard is periodic retraining on rolling blocks while tracking the anchor-positive distance distribution on fresh data."],"forward_implications":["A node could validate transactions in parallel across shards without waiting for parent-UTXO fetches, so throughput becomes bounded by local validation instead of cross-shard communication.","Shard assignment and transaction routing would be solved by one embedding, replacing hash-based random allocation with spending-aware placement.","Because inference uses only the incoming transaction's features, routing can be decided at the node's entry point with no extra ledger access per transaction.","When the top shard prediction misses, checking a small number of nearest shards recovers most parents, giving an explicit tunable trade-off between communication cost and co-location accuracy.","The training procedure is ledger-agnostic, consuming only historical spending records and script and amount features, so the same pipeline applies to any UTXO-based blockchain."],"supporting_citations":[{"why":"Supplies the triplet-loss objective that pulls parent-child outpoint embeddings together while separating unrelated outpoints.","marker":"[21]"},{"why":"Introduces online hard-negative triplet mining that the training procedure adapts for choosing informative negative pairs.","marker":"[20]"},{"why":"Provides the semi-hard and hard negative sampling strategy used to stage training and avoid embedding collapse.","marker":"[23]"},{"why":"Gives the positional encoding applied to outpoint position within a transaction, forming part of the feature vector.","marker":"[22]"},{"why":"Baseline random hash-based sharding that the paper contrasts with its spending-aware allocation.","marker":"[13]"},{"why":"Production UTXO node context whose throughput bottleneck motivates the need for lookup-free validation.","marker":"[12]"},{"why":"Contrast case: graph neural network embeddings of Bitcoin transactions that require parent lookups, which the paper aims to eliminate.","marker":"[17]"}],"fun_headline_variants":["ML embedding routes Bitcoin transactions without parent lookups","Contrastive learning embeds UTXOs to cut cross-shard traffic","ML sharding: spending patterns replace parent lookups","Neural embedding cuts Bitcoin parent lookups for fast validation"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the feature vector built from data present in an incoming transaction can identify the specific parent UTXO well enough to put child and parent in the same shard; if the parent's identity is not truly in those features, the observed co-location may only reflect script-type similarity, and the claimed lookup-free routing would collapse.","fun_headline_variants_meta":{"raw":{"variants":["ML embedding routes Bitcoin transactions without parent lookups","Contrastive learning embeds UTXOs to cut cross-shard traffic","ML sharding: spending patterns replace parent lookups","Neural embedding cuts Bitcoin parent lookups for fast validation"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000742,"raw_usage":{"total_tokens":3312,"prompt_tokens":948,"completion_tokens":2364,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":564,"completion_tokens_details":{"reasoning_tokens":2296}},"tokens_in":564,"tokens_out":2364,"duration_ms":16386,"temperature":1.0,"reasoning_tokens":2296,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T11:38:15.290423+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"The decisive check is to count, on the held-out set, how often the true parent UTXO is the only candidate with the same local features used by the model (amount, locking-script size, OP-code bag); if the parent is usually not unique among candidates, no model can reach high same-shard accuracy at K=0 because the input lacks the parent's identity.","supporting_citations":[],"review_version":1}