Pith. sign in

REVIEW 3 major objections 5 minor 31 references

ContribChain: A Stress-Balanced Blockchain Sharding Protocol with Node Contribution Awareness

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

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

Pith's one-line read ContribChain claims that allocating nodes and accounts by node contribution values achieves stress balance and beats baselines in throughput and cross-shard transactions.

desk verdict 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. read the letter →

arxiv 2505.06899 v1 pith:AXMGLDUD submitted 2025-05-11 cs.NI

Xinpeng Huang , Wanqing Jie , Shiwen Zhang , Haofu Yang , Wangjie Qiu , Qinnan Zhang , Huawei Huang , Zehui Xiong
show 3 more authors
Shaoting Tang Hongwei Zheng Zhiming Zheng
This is my paper · ORCID
classification cs.NI
keywords blockchainshardingstressbalancenodecontributionaccountallocationcross-shardtransactionsLouvainalgorithmthroughput
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

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 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.

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 (3)
  1. [Section III-B, Eq. (1); Section IV-A, Theorem 2] 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.
  2. [Section III-D, Algorithm 1, lines 22-23] 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.
  3. [Section IV-B, Theorem 4] 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.
minor comments (5)
  1. [Section I, first sentence] The phrase 'has emerged as a promising a prominent technology' contains a doubled article; please revise.
  2. [Section III-C, Step 2] 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.
  3. [Section V-C, Fig. 7] 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.
  4. [Section V-E, Fig. 9(c)] 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.
  5. [Section V, general] 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%.

Circularity Check

1 steps flagged · score 6.0 of 10

Contribution values are defined as pro-rata shares of realized shard throughput, so P-Louvain/NACV balance a self-referential performance signal; the stress-balance claim rests on an accounting identity, not independent node capacity.

  1. self definitional [Section III-B Eq. (1); Section IV-A Theorem 2 (Eqs. 9-11); Section III-D P-Louvain input P]
    "The stage performance contribution value ∆p_e(n_i) quantifies the TPS (Transactions Per Second) contributed by node i during Epoch e. ... Theorem 2. The sum of the stage performance contribution values of the nodes within a shard during an epoch equals the shard’s TPS. ... p_K is estimated by summing the performance contribution values of nodes in shard K, as demonstrated in Section IV-A."

    By Eq. (1), each node's performance contribution is only its pro-rata share of transactions actually processed in whatever shard it occupies; Eq. (11) shows summing these values over a shard gives exactly that shard's realized TPS. P-Louvain then takes this same sum as the shard performance input P, and NACV uses the individual p values to move nodes so as to equalize shard processing time t(S)=workload/P. Thus the 'performance' being balanced is defined as the previous epoch's throughput—the very output the allocation is supposed to improve—rather than any independent node-capacity measurement.

full rationale

The only significant circularity is in the performance-contribution signal. Eq. (1) defines a node's stage performance contribution as its pro-rata share of transactions in the blocks its shard processed; Theorem 2 then proves that summing these values over a shard equals that shard's TPS. Section III-D uses that same sum as the shard performance input to P-Louvain, and Section III-C uses the individual p values to move nodes between shards by estimated processing time. So the 'performance' being balanced is, by construction, the realized throughput of the previous allocation, not an independently measured node capacity. This makes the stress-balance objective partly self-referential: a shard that was slow (low realized TPS) is labeled low-performance and given less load, which can reinforce, rather than correct, imbalance. Theorem 2 is a valid accounting identity but does not establish that historical pro-rata shares predict future processing capability. The other elements—security contribution from voting behavior, random verifiable node selection, and P-Louvain community detection—are not circular. Self-citations to BlockEmulator, BrokerChain, and CLPA are present but are not load-bearing for the central derivation; they are implementation and baseline references. Since the central capacity measure reduces by construction to the output it is used to balance, the score is 6 rather than 0-2.

Assumptions & free parameters 8 free parameters · 5 assumptions · 1 invented entities

The central claim rests on hand-set contribution weights (mu, theta, lambda, alpha), a data-selected account allocation frequency, an unvalidated assumption that historical contribution predicts future capacity, and the fidelity of the BlockEmulator environment. These dependencies are acknowledged only implicitly; no sensitivity analysis or independent validation is provided.

free parameters (8)
  • mu (reward weight in security contribution) = 0.9
    Hand-set in Eq. (4); controls the reward side of the security score and, together with theta, the tolerance threshold in Eq. (8). No sensitivity analysis is reported.
  • theta (penalty weight in security contribution) = 1.5
    Hand-set in Eq. (4); must satisfy theta > mu. It directly determines how quickly low correct-vote ratios push the security score negative.
  • lambda (leader weight factor) = 2
    Hand-set in Eq. (4) to weight leader behavior above follower behavior; the value is asserted without justification.
  • alpha (retention factor for global contribution values) = 0.7
    Hand-set in Eqs. (5)-(6); controls how much history is kept. The paper only says it is generally set greater than 0.5.
  • beta (parameter listed in Other Settings) = 2
    Reported as a set parameter in Section V-A but never used or defined in the protocol; suggests a leftover or omitted mechanism.
  • f (account allocation frequency) = 4 epochs
    Chosen from the sweep in Section V-C (Fig. 6c) because it maximized TPS; therefore the headline performance depends on a data-driven choice.
  • T_NA (node allocation period) = 80 s
    Set in experiments; controls how often NACV reruns and affects the balance between reconfiguration overhead and adaptivity.
  • NACV thresholds (I_thre, Var_s_thre, Var_t_thre)
    Algorithm stopping conditions in Section III-C are left without concrete values, so the exact number of swap iterations and the achieved variance depend on undisclosed implementation choices.
assumptions (5)
  • domain assumption PBFT consensus is safe when fewer than one third of nodes in a shard are malicious.
    Used to set the A-Shard failure probability in Eq. (12) and to justify the security threshold for W-Shards in Section IV-B.
  • domain assumption VRF-based randomness followed by PoW or PoS yields unpredictable, unbiased, verifiable node identities and shard assignments.
    Inherited from prior sharding protocols [3],[4]; the paper uses it in Phase 1 and in Theorem 3 without re-deriving it.
  • domain assumption Relay Transaction mechanism from Monoxide provides atomic cross-shard transactions.
    The protocol relies on this mechanism for cross-shard TX atomicity (Section III-A) but does not analyze its cost or failure modes.
  • ad hoc to paper A node's historical contribution value is a valid predictor of its future processing capacity and security behavior.
    This is the central premise of NACV and P-Louvain (Sections III-C and III-D); the paper asserts it but does not validate it against independent measurements.
  • domain assumption BlockEmulator faithfully represents sharded blockchain behavior, and the chosen Ethereum transaction window is a representative workload.
    All quantitative claims in Section V rest on this emulation setup; no cross-platform or cross-period validation is reported.
invented entities (1)
  • Node contribution values (global security value s_e and global performance value p_e)
    purpose: Quantify each node's performance and security from historical behavior and use them as the basis for NACV and P-Louvain.
    These are new ledger entries defined in Section III-B with no external benchmark; the only derived property (Theorem 2) is a definitional equality with shard TPS.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ContribChain: A Stress-Balanced Blockchain Sharding Protocol with Node Contribution Awareness." pith.science (2026). https://pith.science/paper/AXMGLDUD

@misc{pith2026250506899,
  author       = {Pith},
  title        = {Pith review of: ContribChain: A Stress-Balanced Blockchain Sharding Protocol with Node Contribution Awareness},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AXMGLDUD}},
  note         = {Machine review of arXiv:2505.06899}
}
read the original abstract

Existing blockchain sharding protocols have focused on eliminating imbalanced workload distributions. However, even with workload balance, disparities in processing capabilities can lead to differential stress among shards, resulting in transaction backlogs in certain shards. Therefore, achieving stress balance among shards in the dynamic and heterogeneous environment presents a significant challenge of blockchain sharding. In this paper, we propose ContribChain, a blockchain sharding protocol that can automatically be aware of node contributions to achieve stress balance. We calculate node contribution values based on the historical behavior to evaluate the performance and security of nodes. Furthermore, we propose node allocation algorithm NACV and account allocation algorithm P-Louvain, which both match shard performance with workload to achieve stress balance. Finally, we conduct extensive experiments to compare our work with state-of-the-art baselines based on real Ethereum transactions. The evaluation results show that P-Louvain reduces allocation execution time by 86% and the cross-shard transaction ratio by 7.5%. Meanwhile, ContribChain improves throughput by 35.8% and reduces the cross-shard transaction ratio by 16%.

Figures

Figures reproduced from arXiv: 2505.06899 by the authors.

Figure 1
Figure 1. The stress imbalance issue in dynamic environments. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Workflow of ContribChain during epoch e. In ContribChain, Phase 3 is executed every f epochs. The stage security contribution value, ∆se(ni), reflects the security performance of node i in Epoch e, and is computed as: ∆se(ni) = µ · (λ · NMRi + NF Ri) − θ · (λ · NMW i + NFW i) λ · (NMRi + NF Ri) + NMW i + NFW i . (4) Among them, NMRi and NMW i are the numbers of correct and incorrect behaviors by node i as a leader, … view at source ↗
Figure 3
Figure 3. Data Structure of the System Summary Block. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (6 more)
Figure 4
Figure 4. Figure 4: Data Structure of the State Block. Upon entering Epoch e + 1, after node and account alloca￾tion, A-Shard constructs two MMPTs with the updated infor￾mation of nodes and accounts. The roots of the two MMPTs are stored in the header of the State Block, as illustrated in…
Figure 5
Figure 5. Figure 5: Performance of account allocation algorithms with varying [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: TPS and transaction confirmation latency changes with TX arrival rate, [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: TPS and transaction confirmation latency changes with node delay settings or both node security and delay settings. [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 8
Figure 8. Figure 8: Cross-shard Ratio and queue size of the TX pool. In (a), [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 9
Figure 9. Figure 9: (a) and (b) show the impact of K and delay settings on workload distribution and total system workload. (c) shows the processing time of shards. (d) shows the variance in shard security values under three node security and delay settings. all transactions are processed…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 23 canonical work pages

  1. [1]

    Estuary: A low cross-shard blockchain sharding protocol based on state splitting,

    L. Jia, Y . Liu, K. Wang, and Y . Sun, “Estuary: A low cross-shard blockchain sharding protocol based on state splitting,”IEEE Transac- tions on Parallel and Distributed Systems, 2024

    work page 2024

  2. [2]

    A secure sharding protocol for open blockchains,

    L. Luu, V . Narayanan, C. Zheng, K. Baweja, S. Gilbert, and P. Saxena, “A secure sharding protocol for open blockchains,” inProceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 17–30

    2016

  3. [3]

    Omniledger: A secure, scale-out, decentralized ledger via sharding,

    E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, and B. Ford, “Omniledger: A secure, scale-out, decentralized ledger via sharding,” in2018 IEEE Symposium on Security and Privacy (SP). IEEE, 2018, pp. 583–598

    2018

  4. [4]

    Rapidchain: Scaling blockchain via full sharding,

    M. Zamani, M. Movahedi, and M. Raykova, “Rapidchain: Scaling blockchain via full sharding,” inProceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 931– 948

    work page 2018

  5. [5]

    Monoxide: Scale out blockchains with asyn- chronous consensus zones,

    J. Wang and H. Wang, “Monoxide: Scale out blockchains with asyn- chronous consensus zones,” in16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), 2019, pp. 95–112

    work page 2019

  6. [6]

    Brokerchain: A cross-shard blockchain protocol for account/balance- based state sharding,

    H. Huang, X. Peng, J. Zhan, S. Zhang, Y . Lin, Z. Zheng, and S. Guo, “Brokerchain: A cross-shard blockchain protocol for account/balance- based state sharding,” inIEEE INFOCOM 2022-IEEE Conference on Computer Communications. IEEE, 2022, pp. 1968–1977

    work page 2022

  7. [7]

    Towards scaling blockchain systems via sharding,

    H. Dang, T. T. A. Dinh, D. Loghin, E.-C. Chang, Q. Lin, and B. C. Ooi, “Towards scaling blockchain systems via sharding,” inProceedings of the 2019 International Conference on Management of Data, 2019, pp. 123–140

    work page 2019

  8. [8]

    Achieving scalability and load balance across blockchain shards for state sharding,

    C. Li, H. Huang, Y . Zhao, X. Peng, R. Yang, Z. Zheng, and S. Guo, “Achieving scalability and load balance across blockchain shards for state sharding,” in2022 41st International Symposium on Reliable Distributed Systems (SRDS). IEEE, 2022, pp. 284–294

    work page 2022

Show all 31 references
  1. [9]

    Txallo: Dynamic transaction allocation in sharded blockchain systems,

    Y . Zhang, S. Pan, and J. Yu, “Txallo: Dynamic transaction allocation in sharded blockchain systems,” in2023 IEEE 39th International Confer- ence on Data Engineering (ICDE). IEEE, 2023, pp. 721–733

    2023

  2. [10]

    Lb-chain: Load-balanced and low- latency blockchain sharding via account migration,

    M. Li, W. Wang, and J. Zhang, “Lb-chain: Load-balanced and low- latency blockchain sharding via account migration,”IEEE Transactions on Parallel and Distributed Systems, vol. 34, no. 10, pp. 2797–2810, 2023

    2023

  3. [11]

    Account migration across blockchain shards using fine-tuned lock mechanism,

    H. Huang, Y . Lin, and Z. Zheng, “Account migration across blockchain shards using fine-tuned lock mechanism,” pp. 271–280, 2024

    2024

  4. [12]

    Smartchain: A dynamic and self-adaptive sharding framework for iot blockchain,

    T. Cai, W. Chen, J. Zhang, and Z. Zheng, “Smartchain: A dynamic and self-adaptive sharding framework for iot blockchain,”IEEE Transactions on Services Computing, 2024

    2024

  5. [13]

    Dqn-based optimization framework for secure sharded blockchain systems,

    J. Yun, Y . Goh, and J.-M. Chung, “Dqn-based optimization framework for secure sharded blockchain systems,”IEEE Internet of Things Jour- nal, vol. 8, no. 2, pp. 708–722, 2020

    2020

  6. [14]

    Sharding for blockchain based mobile edge computing system: A deep reinforcement learning approach,

    S. Yuan, J. Li, J. Liang, Y . Zhu, X. Yu, J. Chen, and C. Wu, “Sharding for blockchain based mobile edge computing system: A deep reinforcement learning approach,” in2021 IEEE Global Communications Conference (GLOBECOM). IEEE, 2021, pp. 1–6

    2021

  7. [15]

    Sharded blockchain for collaborative computing in the internet of things: Com- bined of dynamic clustering and deep reinforcement learning approach,

    Z. Yang, R. Yang, F. R. Yu, M. Li, Y . Zhang, and Y . Teng, “Sharded blockchain for collaborative computing in the internet of things: Com- bined of dynamic clustering and deep reinforcement learning approach,” IEEE Internet of Things Journal, vol. 9, no. 17, pp. 16 494–16 509, 2022

    2022

  8. [16]

    Blockemulator: An emulator enabling to test blockchain sharding protocols,

    H. Huang, G. Ye, Q. Chen, Z. Yin, X. Luo, J. Lin, Q. Yang, and Z. Zheng, “Blockemulator: An emulator enabling to test blockchain sharding protocols,”arXiv preprint arXiv:2311.03612, 2023

    2023 arXiv

  9. [17]

    A survey of state-of-the-art on blockchains: Theories, modelings, and tools,

    H. Huang, W. Kong, S. Zhou, Z. Zheng, and S. Guo, “A survey of state-of-the-art on blockchains: Theories, modelings, and tools,”ACM Computing Surveys (CSUR), vol. 54, no. 2, pp. 1–42, 2021

    2021

  10. [18]

    Towards a scalable and robust dht,

    B. Awerbuch and C. Scheideler, “Towards a scalable and robust dht,” inProceedings of 18th Annual ACM Symposium on Parallelism in Algorithms and Architectures, 2006, pp. 318–327

    2006

  11. [19]

    Commensal cuckoo: Secure group par- titioning for large-scale services,

    S. Sen and M. J. Freedman, “Commensal cuckoo: Secure group par- titioning for large-scale services,”ACM SIGOPS Operating Systems Review, vol. 46, no. 1, pp. 33–39, 2012

    2012

  12. [20]

    Practical byzantine fault tolerance,

    M. Castro, B. Liskovet al., “Practical byzantine fault tolerance,” in OsDI, vol. 99, no. 1999, 1999, pp. 173–186

    1999

  13. [21]

    Building blocks of sharding blockchain systems: Concepts, approaches, and open problems,

    Y . Liu, J. Liu, M. A. V . Salles, Z. Zhang, T. Li, B. Hu, F. Henglein, and R. Lu, “Building blocks of sharding blockchain systems: Concepts, approaches, and open problems,”Computer Science Review, vol. 46, p. 100513, 2022

    2022

  14. [22]

    Solida: A blockchain protocol based on reconfigurable byzantine consensus,

    I. Abraham, D. Malkhi, K. Nayak, L. Ren, and A. Spiegelman, “Solida: A blockchain protocol based on reconfigurable byzantine consensus,” arXiv preprint arXiv:1612.02916, 2016

    2016 arXiv

  15. [23]

    Enhancing Bitcoin security and performance with strong consistency via collective signing,

    E. K. Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and B. Ford, “Enhancing Bitcoin security and performance with strong consistency via collective signing,” in25th USENIX Security Symposium (USENIX Security ’16), 2016, pp. 279–296

    2016

  16. [24]

    Chainspace: A sharded smart contracts platform,

    M. Al-Bassam, A. Sonnino, S. Bano, D. Hrycyszyn, and G. Danezis, “Chainspace: A sharded smart contracts platform,”arXiv preprint arXiv:1708.03778, 2017

    2017 arXiv

  17. [25]

    Optchain: optimal transactions placement for scalable blockchain sharding,

    L. N. Nguyen, T. D. Nguyen, T. N. Dinh, and M. T. Thai, “Optchain: optimal transactions placement for scalable blockchain sharding,” in 2019 IEEE 39th International Conference on Distributed Computing Systems (ICDCS). IEEE, 2019, pp. 525–535

    2019

  18. [26]

    Challenges and pitfalls of partitioning blockchains,

    E. Fynn and F. Pedone, “Challenges and pitfalls of partitioning blockchains,” in2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W). IEEE, 2018, pp. 128–133

    2018

  19. [27]

    Spring: Improving the throughput of sharding blockchain via deep reinforcement learning based state placement,

    P. Li, M. Song, M. Xing, Z. Xiao, Q. Ding, S. Guan, and J. Long, “Spring: Improving the throughput of sharding blockchain via deep reinforcement learning based state placement,” inProceedings of the ACM on Web Conference 2024, 2024, pp. 2836–2846

    2024

  20. [28]

    Double-spending with a sybil attack in the Bitcoin decentralized network,

    S. Zhang and J.-H. Lee, “Double-spending with a sybil attack in the Bitcoin decentralized network,”IEEE Transactions on Industrial Informatics, vol. 15, no. 10, pp. 5715–5722, 2019

    2019

  21. [29]

    Fast unfolding of communities in large networks,

    V . D. Blondel, J.-L. Guillaume, R. Lambiotte, and E. Lefebvre, “Fast unfolding of communities in large networks,”Journal of Statistical Mechanics: Theory and Experiment, vol. 2008, no. 10, p. P10008, 2008

    2008

  22. [30]

    A next-generation smart contract and decentralized application platform,

    V . Buterinet al., “A next-generation smart contract and decentralized application platform,”white paper, vol. 3, no. 37, pp. 2–1, 2014

    2014

  23. [31]

    Ethereum: A secure decentralised generalised trans- action ledger,

    G. Woodet al., “Ethereum: A secure decentralised generalised trans- action ledger,”Ethereum project yellow paper, vol. 151, no. 2014, pp. 1–32, 2014

    2014

Pith tools

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