{"id":"f3c5e312-f3cf-409e-bfb3-4d1402bdd4d8","arxiv_id":"2505.06899","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":8,"one_line_summary":"ContribChain uses node contribution scores and a performance-aware Louvain variant for account placement to balance stress across blockchain shards, reporting 35.8% higher throughput and 16% lower cross-shard ratio in emulation.","lead":"ContribChain is a blockchain sharding protocol that assigns nodes and accounts to shards using each node's past performance and security record, so that no shard receives more work than its members can handle. In simulations with real Ethereum transactions, it reports 35.8% higher throughput and 16% fewer cross-shard transactions than two existing sharding methods.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Contribution values in Eq. (1) are confounded by shard assignment, so NACV may balance a self-referential quantity rather than true node capacity; the central stress-balance claim needs a validation test.","rationale":"The headline claim is that contribution-aware allocation yields stress balance and a 35.8% throughput gain. The mechanism's causal chain is: p(n_i) -> shard performance estimate -> NACV/P-Louvain allocation -> balanced processing time. The weakest link is the first arrow. Eq. (1) defines p(n_i) as the node's pro-rata credit for transactions in whatever shard it occupied, so p conflates node quality with shard luck. A node in a high-load shard naturally accumulates high p even if its own consensus/validation speed is low, and a node in a low-load shard accumulates low p even if fast. NACV's Step 4 then swaps nodes using p to equalize t(S)=workload/p-performance, and P-Louvain uses the same p to place accounts; the allocation is therefore reacting to a quantity that was itself generated by the prior allocation. This circularity is not resolved by Theorem 2, which only verifies that the p-sum equals TPS by construction. Without an independent measure of node capacity, the experimental stress-balance results in Section V could be an artifact of the simulator reinforcing its own proxy. Other limitations (asserted Theorem 4, no error bars, manually chosen f=4) are real but secondary; even with perfect security and reproducibility, the protocol would not deliver the central benefit if p is not a valid capacity signal. The proposed test, running NACV on a homogeneous-node population, would settle the concern. If the test fails, the paper would need to redefine the contribution metric or provide a separate capacity oracle; if it passes, the conditional accept stands. The reader identified the same underlying predictive-link concern, so no verdict adjustment is needed beyond the existing conditional disposition.","tokens_in":15091,"tokens_out":5669,"duration_ms":58956,"concrete_test":"Use BlockEmulator with homogeneous node capacities. For the first four epochs, inject transaction streams such that shard 1 receives roughly four times the TX volume of shard 2 (e.g., by targeting accounts assigned to shard 1), then compute p(n_i) via Eq. (1). If p values are systematically higher for nodes in shard 1 despite identical hardware, p is confounded by shard-level load. Then, from epoch 5 onward, enable NACV and compare shard processing-time variance and throughput against a no-NACV or random-allocation control. A capacity signal that actually measures node speed should not cause significant reallocation in a homogeneous population; a self-referential signal will, and if that reallocation fails to improve stress balance, the central mechanism is not validated.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central mechanism of ContribChain requires that the performance contribution value p(n_i) from Eq. (1) measures a node's intrinsic processing capability. It does not. Eq. (1) assigns each correctly behaving node the pro-rata share TX_j/nR_j of every successfully submitted block in the shard it happens to occupy. Consequently, p(n_i) is determined largely by the throughput of the node's assigned shard, not by the node's own speed. A slow node in a busy shard accumulates high p; a fast node in an idle shard accumulates low p. NACV (Section III-C) and P-Louvain (Section III-D) then use p to balance estimated processing time t(S), creating a circular signal: the allocation adjusts to a quantity that was produced by the previous allocation. Theorem 2 only proves the accounting identity that the sum of stage contributions equals shard TPS; it says nothing about whether p is a causal or predictive measure of future per-node capacity. If the signal is contaminated, NACV and P-Louvain balance the wrong objective, and the reported stress-balance improvements (Figs. 7 and 9) may be artifacts of the simulator's response to a self-referential rule rather than of genuinely balanced capacity. No independent measurement of node capacity is reported, and no ablation separates intrinsic node speed from shard-level throughput.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes ContribChain, a sharding protocol for account/balance-based blockchains that computes per-node performance and security contribution values from historical consensus behavior, then uses these values in two allocation algorithms: NACV for moving nodes among shards and P-Louvain for assigning accounts to shards, with the aim of balancing shard 'stress' (the alignment between shard processing capacity and workload). The authors implement the system on the BlockEmulator testbed, evaluate it with up to 30 million real Ethereum transactions, and report that P-Louvain reduces allocation execution time by 86% and the cross-shard transaction ratio by 7.5%, while full ContribChain improves throughput by 35.8% and reduces the cross-shard transaction ratio by 16% relative to CLPA and Monoxide.","tokens_in":15392,"tokens_out":6161,"duration_ms":63754,"significance":"If the node contribution values were a valid measure of intrinsic node capacity, the idea of jointly rebalancing node composition and account workload would be a useful step beyond transaction-layer load balancing. The evaluation is broad: it varies the number of shards, transaction volumes, arrival rates, account-allocation frequencies, and node delay/security settings, and it uses real Ethereum transactions on a public emulator. These are genuine strengths. The central risk is that the performance contribution value defined in Eq. (1) is an accounting identity that sums to shard TPS rather than an independent measurement of node capacity, and the P-Louvain pseudocode contains a sign error in its movement rule. The headline claims therefore need additional validation before the protocol can be considered established.","major_comments":[{"comment":"The stage performance contribution value p(n_i) is defined as a pro-rata share of the transactions in the blocks that the node's shard submits, and Theorem 2 proves only that these shares sum to the shard's TPS. Consequently, p is not an independent measure of a node's processing capability: a slow node in a busy shard receives a high p, while a fast node in an idle shard receives a low p. NACV and P-Louvain then optimize shard processing time using these values (Sections III-C and III-D), so the allocation is reacting to a signal that is itself a product of the previous allocation. The paper provides no independent measurement of node capacity and no ablation that separates intrinsic node speed from shard-level throughput. The reported stress-balance improvements in Figs. 7 and 9 could therefore follow from self-referential feedback rather than from balanced intrinsic capacity. Please add a validation experiment, for example with synthetic nodes of known speeds or a per-node throughput measurement that does not depend on shard assignment, and discuss what Eq. (1) can and cannot measure.","section":"Section III-B, Eq. (1); Section IV-A, Theorem 2"},{"comment":"The movement criterion in the Node Movement Phase is written as `if max(t'_from, t'_to) - max(t_from, t_to) > R_max` with R_max initialized to 0. A beneficial move should reduce the maximum processing time, so the left-hand side should be a decrease, not an increase. As printed, the condition will not be satisfied for any improving move, meaning the pseudocode would perform no account movements. This contradicts the text 'recording the maximum reduction R_max' and the reported efficiency and balance results. Please correct the sign and inequality, and confirm that the implementation matches the corrected pseudocode.","section":"Section III-D, Algorithm 1, lines 22-23"},{"comment":"The proof of W-Shard security is an assertion rather than a derivation. It states that if A-Shard is secure, NACV will distribute low-security nodes so as to minimize shard security variance, but no bound is derived on the adversarial proportion in any W-Shard after the swap operations, and the effects of the randomized selection and threshold-based termination on the worst-case distribution are not analyzed. Since security is part of the protocol's stated contribution, please either provide a formal argument or explicitly characterize the security behavior as an empirical property supported by the experiments in Section V-E.","section":"Section IV-B, Theorem 4"}],"minor_comments":[{"comment":"The phrase 'has emerged as a promising a prominent technology' contains a doubled article; please revise.","section":"Section I, first sentence"},{"comment":"The text says 'assign the average security and performance contributions pall and sall, respectively,' but the variables are then used as sall for security and pall for performance in the following conditions; please make the naming order consistent.","section":"Section III-C, Step 2"},{"comment":"The delay model L_s * j + L_n * i is introduced later in the same section but is needed to interpret the earlier Fig. 7(a)-(b); please define it before first use.","section":"Section V-C, Fig. 7"},{"comment":"The sentence 'The transaction backlog problem depicted in Fig. 1 occurs in shards other than shard 3, 4' is unclear; please rephrase to state exactly which shards exhibit backlogs and why.","section":"Section V-E, Fig. 9(c)"},{"comment":"The experiments do not report the number of repetitions or any error bars; adding these would substantially strengthen the comparisons in Figs. 6-9, especially where the reported improvements are around 7-16%.","section":"Section V, general"}],"recommendation":"major_revision","confidential_remarks":"The core concern is not stylistic: Eq. (1) and Theorem 2 define an accounting identity, and both NACV and P-Louvain optimize a quantity derived from that identity. I would ask the authors for a validation experiment that measures node capacity independently of shard assignment before accepting the stress-balance claim. In addition, the discrepancy between the Algorithm 1 pseudocode and the reported implementation is a reproducibility risk that the editor should ask the authors to resolve explicitly."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a real, publishable-in-principle contribution to blockchain sharding, with a genuinely new combination of contribution-aware node allocation and performance-aware account allocation. But the performance-contribution metric is partly an artifact of the shard a node sits in, so the headline 35.8% throughput gain may be balancing the protocol's own previous output rather than true node capacity. The paper deserves peer review, but it needs a validation test and a real security proof before I'd trust the numbers.\n\nWhat's new: most sharding papers do either node allocation or account/transaction allocation. ContribChain runs both, on the same node-contribution values, and evaluates them together on BlockEmulator with real Ethereum transactions. P-Louvain's time-efficiency and cross-shard results are broadly consistent across K, arrival rates, delays, and security settings. That internal consistency is genuine evidence, not just noise.\n\nThe soft spots are where the stress-test concern lands. Eq. (1) credits each correct node with a pro-rata share TX_j/n_Rj of every successfully submitted block in its shard. So p(n) mostly tracks shard throughput, not node speed. A slow node in a busy shard scores high; a fast node in an idle shard scores low. NACV and P-Louvain then use summed p values to estimate shard processing time and balance on it. Theorem 2 only proves the accounting identity that the sum of stage p's equals shard TPS; it doesn't validate p as a predictor of future capacity. Without an independent measurement of node capability, or an ablation separating node-intrinsic speed from shard-level load, the stress-balance gains in Figs. 7–9 could be artifacts.\n\nTheorem 4 is not a proof; it's a paragraph of intuition. The abstract's 16% cross-shard reduction is reported at f=6, while the throughput headline uses f=4; both f and the hand-set weights (µ, θ, λ, α, and an undefined β) are tuned on the same experiments without sensitivity analysis. No error bars, no repeated runs, no artifact link.\n\nNet: worth serious refereeing, especially in a networking/systems venue. The right referee report will ask for a cleaner metric, a validation experiment, and a proper security argument. I wouldn't cite the headline numbers as established, but I'd send it out.","headline":"A broad and internally consistent study of a genuinely new node-plus-account allocation scheme for sharding, but the performance-contribution metric is confounded by shard assignment, so the headline gains need a validation test before they carry the weight claimed.","tokens_in":15975,"tokens_out":3792,"would_cite":false,"duration_ms":37068,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"ContribChain claims that allocating nodes and accounts by node contribution values achieves stress balance and beats baselines in throughput and cross-shard transactions.","keywords":["blockchain sharding","stress balance","node contribution","account allocation","node allocation","cross-shard transactions","Louvain algorithm","throughput"],"falsifier":"Run a controlled emulator experiment in which each node's actual processing capacity is measured independently, while historical contribution values are held fixed; if the rank correlation between contribution score and measured capacity is near zero, or if NACV's performance adjustment fails to reduce shard processing-time variance, the central claim that contribution values track future capacity collapses.","tokens_in":1582,"feed_emoji":"⚖️","tokens_out":1982,"duration_ms":53624,"temperature":0.7,"pith_summary":"The paper argues that balancing transaction workload across shards is not enough: if shards contain nodes with different processing capacities, equally loaded shards experience different stress, and weaker shards fall behind. To fix this, the protocol scores every node from its historical consensus and transaction-processing behavior, then runs two allocation algorithms—NACV for nodes and P-Louvain for accounts—that match shard processing capacity to shard workload. On real Ethereum transactions replayed in an emulator, the combined protocol reports 35.8% higher throughput than CLPA and a 16% lower cross-shard transaction ratio, with lower and more stable shard processing times and security variance. The deeper claim is that a node's contribution score is a usable proxy for the processing capacity that node will bring to a shard in the next epoch.","feed_headline":"Contribution-aware sharding lifts throughput 35.8%","feed_subtitle":"Protocol matches shard capacity to workload, cutting cross-shard transactions by 16% over CLPA.","key_machinery":"The load-bearing machinery is the node contribution value, updated each epoch from Eq. (1) for performance and Eq. (4) for security, and smoothed into global values with a retention factor $\\alpha$. These values feed NACV, a swap-based node allocation algorithm that targets two variances at once—shard security variance and shard processing-time variance—and P-Louvain, a performance-aware extension of the Louvain community-detection algorithm that places accounts so that no shard's processing time dominates. The protocol also includes a verification procedure so other nodes can check that no boundary account move would reduce shard processing times, making the allocation result publicly verifiable.","core_discovery":"The central discovery is that shard stress—defined as the alignment between a shard's processing capacity and its workload—can be made the quantity that sharding protocols optimize, and that both sides of the alignment can be steered by one score. Each epoch, nodes receive a stage performance contribution value $\\Delta p_e(n_i)$, their pro-rata share of successfully processed transactions with penalties for incorrect votes on failed blocks, normalized by epoch duration; Theorem 2 shows the sum over a shard equals that shard's TPS. A separate security contribution value rewards correct leader and follower behavior, and global values are updated by exponential smoothing. NACV iteratively swaps nodes between shards to reduce variance in both shard security and estimated processing time, while P-Louvain extends community detection by moving accounts to the shard whose processing time is minimized. In the reported experiments, this dual allocation yields higher throughput, lower confirmation latency, shorter transaction-pool queues, and a lower cross-shard transaction ratio than CLPA and Monoxide.","pith_inferences":["Editorial extension: the paper leaves open whether contribution scores can be gamed by adaptive adversaries who behave well while accumulating score and then misbehave; a direct test would simulate such attackers and measure whether the exponential smoothing and penalty weights contain the damage.","Editorial extension: because shard stress is defined as processing-time alignment, the same framing could generalize to storage, bandwidth, or energy stress, not just consensus throughput.","Editorial extension: the predictive link between historical contribution and future capacity could be tested directly by comparing contribution values against independent per-node benchmarks, which the paper does not do.","Editorial extension: combining contribution-aware allocation with dynamic adjustment of shard count and allocation frequency—listed as future work—would test whether stress balance survives node churn and workload drift."],"forward_implications":["If the protocol is right, shard reconfiguration can use contribution scores to prevent transaction backlogs without a separate load-balancing mechanism.","Because P-Louvain keeps the cross-shard transaction ratio nearly constant as shard count and transaction count grow, the approach promises stronger scalability than hash-based or purely workload-based allocation.","One accounting mechanism—contribution values—simultaneously drives security balancing and performance balancing, so reputation and capacity need not be tracked separately.","The reported gains are largest when NACV and P-Louvain run together, indicating that node allocation and account allocation should be co-designed rather than optimized independently.","P-Louvain's verification check makes the account-allocation output checkable by other nodes, a property needed for permissionless sharded systems."],"supporting_citations":[{"why":"Provides Monoxide, the hash-based account-allocation baseline that ContribChain must beat in system experiments.","marker":"[5]"},{"why":"Provides CLPA, the community-detection account-allocation baseline used for system-level comparisons of throughput and stress balance.","marker":"[8]"},{"why":"Provides TxAllo, the Louvain-based account-allocation algorithm against which P-Louvain's time and allocation quality are measured.","marker":"[9]"},{"why":"Supplies the Louvain community-detection algorithm that P-Louvain extends with shard performance awareness.","marker":"[29]"},{"why":"Supplies the epoch-based sharding model, PBFT-style intra-shard consensus, and random A-Shard node selection assumptions.","marker":"[3]"},{"why":"Supplies the full-sharding reconfiguration model and the random node-selection security assumptions ContribChain builds on.","marker":"[4]"},{"why":"Provides the open-source blockchain emulator on which ContribChain and P-Louvain are implemented and evaluated.","marker":"[16]"},{"why":"Supplies the state-splitting account-allocation approach and the random node-selection method used for the A-Shard in epoch zero.","marker":"[1]"},{"why":"Provides the historical Ethereum transactions used as the evaluation dataset.","marker":"[31]"}],"fun_headline_variants":["Stress-balanced sharding: 35.8% higher throughput","Sharding that balances stress, not just load","Node contribution scoring drives shard stress balance","Matching shard capacity to workload boosts throughput 35.8%"],"cache_read_input_tokens":17920,"weakest_assumption_plain":"A node's past contribution score, computed from its share of properly confirmed transactions and its voting correctness, predicts how much processing capacity that node will contribute in the next epoch.","fun_headline_variants_meta":{"raw":{"variants":["Stress-balanced sharding: 35.8% higher throughput","Sharding that balances stress, not just load","Node contribution scoring drives shard stress balance","Matching shard capacity to workload boosts throughput 35.8%"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000205,"raw_usage":{"total_tokens":1393,"prompt_tokens":942,"completion_tokens":451,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":558,"completion_tokens_details":{"reasoning_tokens":385}},"tokens_in":558,"tokens_out":451,"duration_ms":4271,"temperature":1.0,"reasoning_tokens":385,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T22:30:27.531927+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run a controlled emulator experiment in which each node's actual processing capacity is measured independently, while historical contribution values are held fixed; if the rank correlation between contribution score and measured capacity is near zero, or if NACV's performance adjustment fails to reduce shard processing-time variance, the central claim that contribution values track future capacity collapses.","supporting_citations":[{"cited_title":"Monoxide: Scale out blockchains with asyn- chronous consensus zones,","cited_arxiv_id":null,"evidence_quote":"Provides Monoxide, the hash-based account-allocation baseline that ContribChain must beat in system experiments."},{"cited_title":"Achieving scalability and load balance across blockchain shards for state sharding,","cited_arxiv_id":null,"evidence_quote":"Provides CLPA, the community-detection account-allocation baseline used for system-level comparisons of throughput and stress balance."},{"cited_title":"Txallo: Dynamic transaction allocation in sharded blockchain systems,","cited_arxiv_id":null,"evidence_quote":"Provides TxAllo, the Louvain-based account-allocation algorithm against which P-Louvain's time and allocation quality are measured."},{"cited_title":"Rapidchain: Scaling blockchain via full sharding,","cited_arxiv_id":null,"evidence_quote":"Supplies the full-sharding reconfiguration model and the random node-selection security assumptions ContribChain builds on."},{"cited_title":"Estuary: A low cross-shard blockchain sharding protocol based on state splitting,","cited_arxiv_id":null,"evidence_quote":"Supplies the state-splitting account-allocation approach and the random node-selection method used for the A-Shard in epoch zero."}],"review_version":1}