BrokerChain: A Blockchain Sharding Protocol by Exploiting Broker Accounts

Guang Ye; Huawei Huang; Qinde Chen; Song Guo; Xiaowen Peng; Yue Lin; Zhaokang Yin; Zibin Zheng

REVIEW 5 major objections 5 minor 28 references

BrokerChain: A Blockchain Sharding Protocol by Exploiting Broker Accounts

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

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

Pith's one-line read Blockchain sharding can keep nearly all transactions local by splitting accounts across shards and routing the rest through broker accounts, the paper reports.

desk verdict Solid extended version of the INFOCOM 2022 BrokerChain paper, with a clear protocol and broad emulation, but the headline 7.4% cross-shard ratio rests on unmodeled broker liquidity. read the letter →

arxiv 2412.07202 v1 pith:AFZVNLZR submitted 2024-12-10 cs.CR

Huawei Huang , Zhaokang Yin , Qinde Chen , Guang Ye , Xiaowen Peng , Yue Lin , Zibin Zheng , Song Guo This is my paper · ORCID

classification cs.CR

keywords blockchainshardingstatecross-shardtransactionsaccountsegmentationbrokeraccountsworkloadbalancehotshardstransactionthroughput

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

BrokerChain is a sharding protocol for blockchains that keep account balances, and it claims to solve two problems at once: most transactions never have to leave their home shard, and the work is spread evenly so no shard becomes a bottleneck. Existing sharding schemes scatter related accounts across shards, so with many shards almost every payment is a cross-shard transaction and active accounts create hot shards. The paper's design splits each account's state across several shards (account segmentation) and routes the remaining cross-shard payments through broker accounts, so a payment that would cross shards becomes two ordinary local payments. In replay experiments with real historical Ethereum transactions, the paper measures the cross-shard ratio at 7.4% for BrokerChain versus 98.6% for Monoxide and LBF and 83.5% for Metis, together with higher throughput and lower confirmation latency. The protocol also bounds how long a cross-shard payment may stay unresolved, which the authors call duration-limited eventual atomicity.

What carries the argument

Two mechanisms carry the argument. First, the P-shard builds a weighted account-state graph from observed transactions, partitions it with a graph-partitioning heuristic into $S$ balanced sectors, and records the result in a state block; the modified Shard State Tree (mSST) stores a storage-map vector $\Psi$ per account so every shard knows, in $O(1)$ time, whether a given transaction is local or cross-shard. Second, for transactions that still cross shards, broker accounts with sufficient pledged tokens act as intermediaries: the payment is split into $\Theta_1$ (payer to broker, in the source shard) and $\Theta_2$ (broker to payee, in the destination shard), locked for $H_{\mathrm{lock}}$ blocks, with a failure-proof $\gamma$ returning tokens if $\Theta_2$ is not confirmed in time. This two-part structure converts a cross-shard transaction into two local ones and gives the protocol a deadline, which is what turns eventual atomicity into a bounded guarantee.

What would settle it

Feed the same Ethereum replay into the protocol with broker balances capped below the amounts they are asked to forward, or with a fraction of brokers that stop after signing $\Theta_1$; the central claim would fail if the 7.4% cross-shard ratio and roughly 276-second latency still held, because then the broker layer would not be doing the work the paper attributes to it.

Watch

Extended reading notes

Core claim

The central claim is that account-based state sharding can keep nearly all transactions inside a single shard without sacrificing workload balance. BrokerChain repartitions the account-state graph each epoch with a graph-partitioning heuristic, then applies account segmentation: one account's token balance, nonce, and code are stored in several shards under the same address, with a per-shard storage map telling each shard which parts it holds. Remaining cross-shard transactions are routed through broker accounts pledged with sufficient tokens; the raw transaction is split into two linked local transactions, $\Theta_1$ and $\Theta_2$, with a token-lock window $H_{\mathrm{lock}}$ and a failure-proof $\gamma$ for refunds. The paper argues this achieves duration-limited eventual atomicity and, in a replay of 1.67 million historical Ethereum transactions, reduces the average cross-shard ratio to 7.4% versus 98.6% for Monoxide and LBF and 83.5% for Metis, while also lowering the largest and most variable shard workloads.

Load-bearing premise

The protocol assumes the system can recruit enough accounts with sufficient tokens to act as brokers, but the paper explicitly leaves the incentive mechanism for making them do so to future work.

Editorial extensions

If this is right

If the 7.4% cross-shard ratio holds as the shard count grows, sharded blockchains can add shards without the near-total cross-shard overhead that currently caps their throughput.
A bounded resolution time for cross-shard transactions means users can be told a worst-case confirmation latency, which is something hot-shard schemes cannot offer.
Because broker accounts absorb the remaining cross-shard traffic, the throughput and latency numbers depend on there being enough solvent, willing brokers; the paper's evaluations fix $K=40$.
The workload-balance results, including lower variance and a lower largest shard workload, directly address the hot-shard failure mode that makes Monoxide-style sharding unpredictable.
Account segmentation at the protocol layer gives users the benefit of multi-account load spreading without requiring them to manage multiple accounts themselves.

Reading between the lines

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

A consequence the paper leaves implicit is that the same account-segmentation idea could apply outside blockchain sharding, for example to any replicated state machine where hot keys create bottlenecks; the storage-map vector is a general way to spread a logical account's state across replicas while preserving a single address.
The reported gains are measured on one historical Ethereum replay with $K=40$ brokers; a natural stress test is to vary the fraction of transactions that must pass through brokers or to cap broker balances, which would reveal how quickly the 7.4% ratio degrades.
Because the incentive mechanism is explicitly future work, a real deployment would need to show that brokers can be compensated without introducing new attack surface; until then, the protocol's availability rests on an unmodeled economic assumption.

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.

Desk Editor's Note

read the letter

Colleague,

You should know this before reading: the core BrokerChain mechanism was already published at INFOCOM 2022, so the novelty here is in the added security analysis, design detail, and expanded experiments—not in the central idea. The paper is honest about this, citing the conference version. That said, the protocol is clearly specified and the evaluation is substantial: they implement it in BlockEmulator, replay real Ethereum transactions, and compare against Monoxide, LBF, and Metis.

The new material: a P-shard security model with a failure-probability bound, more detail on the state-block data structure and account segmentation, and a wider set of simulations including pressure tests, queue-size behavior, and the effect of the number of broker accounts. The measured 7.4% cross-shard ratio against 98.6% for Monoxide and LBF is the headline, and the workload-balance heatmaps back up the qualitative claim.

Soft spots, in order of importance. First, the broker incentive problem is deferred. Section IV states that a broker needs "a sufficient amount of tokens" and that the incentive mechanism is "left as our future work." All experiments fix K=40 brokers and never measure how much capital those brokers must lock up, nor the fee required to make that rational. Since every cross-shard transfer becomes two intra-shard transfers through a broker who fronts the full value, the 7.4% ratio is an upper bound under an unvalidated liquidity assumption. If brokers are capital-constrained, either the ratio rises or the added costs eat the gains. That is the single biggest gap.

Second, the formal security analysis has a small but real error: Theorem 3's Eq. (2) omits the binomial coefficient C(ϑ·S, N) that appears in Eq. (3) and in the derivation. It may be a typo, but the printed formula is wrong as written. The "duration-limited eventual atomicity" in Section V-D is also informal, and the failure-case description is confusing (Op3 in the failure case says Θ1 is included in a block at shard #2, which contradicts the success-case flow). This needs tightening.

Third, the state graph is partitioned on the same historical dataset that is later replayed, so the partition is optimized for the test set. The comparisons to Monoxide and LBF are fair, but the absolute numbers likely overstate what you would get on unseen workloads. No BrokerChain code or data artifacts are shipped, which compounds the reproducibility concern.

Overall, this is a decent extended version with a coherent design and meaningful experiments, but the performance claims are conditional on broker participation that is never modeled. A clean formal model of the atomicity guarantee, a proper incentive and capital-lockup analysis, and a corrected Eq. (2) would address the main gaps.

For peer review: yes, send it out. The design is coherent and the evaluation is substantial; a good referee can push for the missing pieces. I would not cite it over the INFOCOM version unless you care specifically about the security analysis.

Referee Report

5 major / 5 minor

Summary. The paper proposes BrokerChain, a state-sharding protocol for account-based blockchains. It combines state-graph partitioning (via Metis) with account segmentation, in which a single address can hold partial balances in multiple shards, and introduces broker accounts that convert cross-shard transactions into two intra-shard transactions. The paper provides a security analysis (PBFT shard failure probabilities, double-spending resistance) and reports emulation results on the authors' BlockEmulator replaying historical Ethereum transactions, claiming lower cross-shard TX ratios (7.4% vs 83.5-98.6% for baselines), higher throughput, lower latency and queue size, and better workload balance.

Significance. If the performance claims held under realistic participation constraints, the protocol would be a useful step toward reducing hot shards and cross-shard overhead in account-based sharding. The manuscript is clearly structured, the protocol is specified in enough detail to implement, and the authors ship an open-source emulator with an extensive experimental comparison. However, the central gain comes from the broker mechanism, whose capital requirements and incentive compatibility are not evaluated, and some baseline and security-analysis issues need to be resolved before the headline claims are acceptable.

major comments (5)

[Section IV and Section VII-E] The reported performance gains are conditional on an unvalidated broker-liquidity assumption. Section IV states that a broker must have 'a sufficient amount of tokens' and defers the incentive mechanism to future work, while Section VII-B fixes K=40 and Section VII-E reports the 7.4% cross-shard TX ratio. Every converted cross-shard TX requires a broker to front v tokens in the destination shard and wait Hlock for reimbursement, yet no experiment measures peak broker capital lockup, the distribution of balances across brokers, or the compensation needed for rational participation. Under capital-constrained or fee-charging brokers, either the CTX ratio rises or the added cost and delay negate the throughput and latency advantages. The evaluation should be presented as an upper-bound demonstration, or supplemented with experiments varying broker capital and incentive costs.
[Section VI-B, Eq. (2)] Eq. (2) is not a correct expression for the M-shard failure probability as written. The inner summation over n_1,...,n_S does not enforce \sum n_i = N, so it includes configurations outside the support of the conditional distribution given by Eq. (8). For a concrete counterexample, S=1, ϑ=1, β=0 gives P=0 from Eq. (2), whereas the true probability that the single M-shard fails is φ. The proof of Theorem 3 should either state the support constraint explicitly or retain the normalizing binomial coefficient in the summation; as it stands, the numerical security claims in Fig. 12 rest on an incorrect formula.
[Section VII-A] The baseline comparisons are not against state-of-the-art sharding systems. The paper cites LBF to reference [27], which is a genetic algorithm for cloud task scheduling, not a blockchain sharding protocol, and Metis [21] is a graph-partitioning heuristic that does not by itself define consensus or cross-shard transaction handling. Presenting these as 'baselines' alongside Monoxide in the throughput and CTX-ratio comparisons does not support the abstract's claim of outperforming state-of-the-art methods. The authors should either implement and compare actual sharding protocols (e.g., RapidChain or Pyramid) or precisely state that the comparison is against account-placement heuristics.
[Section V-D and Section IV-B] The 'duration-limited eventual atomicity' property is not proven. In the failure case, the refund depends on the destination shard including Θ1 as a confirmation and the source shard receiving the failure proof γ before Hsource+Hlock; however, if γ is lost, the paper only states that it 'can be reconstructed and launched again by the destination shard,' without bounding this process by Hlock. Since a lost or delayed γ can push the refund beyond the advertised token-lock duration, the claim that every cross-shard TX is completed within Hlock needs either a proof with explicit deadlines for proof reconstruction or a weaker statement.
[Section III-C and Section V-A] Account segmentation with per-shard nonces introduces a cross-shard replay risk that the double-spending analysis in Section V-A does not cover. Because the same address can have independent nonce fields in different shards and Θraw does not bind the source shard, a signed transaction that is valid in one shard can also be valid in another shard where the account has a segment with the same current nonce. This allows the same signed transfer to be executed multiple times against different partial balances. The protocol should bind each transaction to a specific shard segment (for example, by including the shard ID in Θraw and validating it) or should prove that the nonce mechanism is globally consistent across segments.

minor comments (5)

[Section VII-C and VII-F] There are several typos in the evaluation text: 'BrokChain' in Section VII-C and 'BorkerChain' in Section VII-F should be 'BrokerChain'; 'RapaidChain' in Section II should be 'RapidChain'; 'firsts-half' in Section V-A should be 'first-half'; and 'seting' in Section VII-E should be 'setting'.
[Section VII-A] The experimental settings do not state the number of epochs used for the measurements in Figs. 13-16 and 18-20, nor how broker accounts are initialized (initial balances, number of segments per broker). Adding this information is necessary for reproducibility.
[Section V-B] The recommendation to set Hlock to at least 20 times the average cross-shard TX latency is presented without derivation or citation; please justify this factor or label it as empirical.
[Section III-B] The description of vertex weights is circular: 'the vertex weight is calculated by the sum of the associated edges’ weight,' but edge weights are defined as the number of TXs associated with the pair, and the graph is updated from TXs; please clarify what is included in an account's weight and how isolated vertices are handled.
[Figure 10(c)] The failure-case diagram and the corresponding text in Section IV-B are hard to follow (e.g., what it means for Θ1 to be 'included in a block located at shard #2' when Θ1 is a source-shard transaction). A clearer description of the proof-of-inclusion mechanism would improve the atomicity argument.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: BrokerChain's performance is measured via an open emulator against standard baselines; only minor self-citation and an unvalidated broker-incentive assumption are noted.

full rationale

The paper's central claims are not circular. BrokerChain is an implemented protocol whose throughput, latency, queue size, workload balance, and 7.4% cross-shard TX ratio are measured outputs of BlockEmulator replaying historical Ethereum TXs, not fitted parameters renamed as predictions. Section VII-D explicitly varies the broker count K and reports saturation, and Section VII-E reports the CTX ratio after running the protocol, so the headline number is an experimental result rather than a construction-level tautology. The state-graph partition is optimized with Metis on the same historical TX family, but the protocol builds each epoch's graph from preceding TX blocks and applies the partition to the next epoch (Section III-B), giving a time-ordered evaluation rather than training on the test set. The only self-referential elements are the authors' own conference version [28] and BlockEmulator [26], neither of which supplies a load-bearing uniqueness or correctness theorem. The deferred broker incentive mechanism (Section IV: 'The design of such an incentive mechanism is left as our future work') and the reliance on brokers having 'a sufficient amount of tokens' are real feasibility limitations, but they are assumptions about external liquidity and participation, not circular reductions. No equation in the paper is equivalent to its input by definition, and the security analysis derives failure probabilities from standard PBFT binomial assumptions rather than from the paper's own conclusions.

Assumptions & free parameters 3 free parameters · 5 assumptions · 2 invented entities

The protocol's advertised gains rest on four principal load-bearing inputs: a split-account world-state model, a predict-next-epoch workload assumption, PBFT and random-shard security assumptions, and the availability of solvent brokers. The numerically tuned parameters in the evaluation are K=40 and the Hlock heuristic, with lambda=18 as a chosen security target. None of these are derived from first principles.

free parameters (3)

K (number of broker accounts) = 40
Set to 40 in experiments; performance saturates beyond K=40 as shown in Fig. 17. The paper does not derive an optimal or minimum K from protocol requirements.
Hlock (token-lock duration) = recommended at least 20x average CTX latency
Chosen by the payer in Op1; Section V-B gives an empirical heuristic tied to measured latency, not a derived bound from network or adversary assumptions.
lambda (security target) = 18
Used in Remarks 2 and 3 to size P-shard and M-shards. It is a design choice rather than a value derived from a stated threat model or economic analysis.

assumptions (5)

standard math PBFT intra-shard consensus tolerates at most floor((m-1)/3) Byzantine nodes per shard.
Used to set the failure thresholds in Theorems 2 and 3 in Section VI.
domain assumption Nodes are randomly assigned to shards so the malicious proportion in each shard equals the global proportion phi.
Assumed in Theorems 2 and 3. The paper recommends the Cuckoo rule to enforce this but does not prove that the rule achieves uniform randomness under an adaptive adversary.
ad hoc to paper An account state can be split into partial balances at the same address, distinguished only by nonce, and treated as one logical account.
Core to account segmentation in Section III-C. This departs from the standard Ethereum world-state model and requires wallet and node changes; its user-facing semantics are not formally specified.
domain assumption The transaction graph of the current epoch is predictive of the next epoch's workload distribution.
State-graph partitioning uses Metis on TXs observed during epoch t to assign states for epoch t+1 in Section III-B. If workloads shift rapidly, balance and CTX improvements could degrade.
domain assumption A broker account holds sufficient tokens in the destination shard to front the transferred value before receiving the locked refund from the source shard.
Required in Op4 and Op5 of Section IV-A. No capital requirements or broker credit model are provided, and the incentive mechanism is explicitly left as future work.

invented entities (2)

Broker account
purpose: Intermediary account that splits a cross-shard TX into two intra-shard TXs and fronts the value transfer in the destination shard.
Its existence and solvency are assumed in Section IV, and the incentive mechanism is deferred to future work, so there is no falsifiable handle outside the paper showing that enough solvent brokers will materialize.
P-shard (partition shard)
purpose: A dedicated shard that builds and partitions the account state graph and produces state blocks each epoch.
Introduced as a new shard type in Section III-A. It adds a system-wide coordination point; its security is analyzed but its liveness and performance are not independently evidenced.

how reviews work

0 comments

Cite this review

Pith. "Pith review of BrokerChain: A Blockchain Sharding Protocol by Exploiting Broker Accounts." pith.science (2026). https://pith.science/paper/AFZVNLZR

@misc{pith2026241207202,
  author       = {Pith},
  title        = {Pith review of: BrokerChain: A Blockchain Sharding Protocol by Exploiting Broker Accounts},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AFZVNLZR}},
  note         = {Machine review of arXiv:2412.07202}
}

read the original abstract

State-of-the-art blockchain sharding solutions such as Monoxide, can cause severely imbalanced distribution of transaction (TX) workloads across all blockchain shards due to the deployment policy of their accounts. Imbalanced TX distributions then produce hot shards, in which the cross-shard TXs may experience an unlimited confirmation latency. Thus, how to address the hot-shard issue and how to reduce crossshard TXs become significant challenges of blockchain sharding. Through reviewing the related studies, we find that a crossshard TX protocol that can achieve workload balance among all shards and simultaneously reduce the quantity of crossshard TXs is still absent from the literature. To this end, we propose BrokerChain, which is a cross-shard blockchain protocol dedicated to account-based state sharding. Essentially, BrokerChain exploits fine-grained state partition and account segmentation. We also elaborate on how BrokerChain handles cross-shard TXs through broker accounts. The security issues and other properties of BrokerChain are analyzed rigorously. Finally, we conduct comprehensive evaluations using an opensource blockchain sharding prototype named BlockEmulator. The evaluation results show that BrokerChain outperforms other baselines in terms of transaction throughput, transaction confirmation latency, the queue size of the transaction pool, and workload balance.

Figures

Figures reproduced from arXiv: 2412.07202 by the authors.

**Figure 1.** Ratio of cross-shard transactions vs the number of shards (i.e., S). Iteration 0 1 2 3 4 5 6 7 Shard # : Hot Shards 0 10000 20000 30000 40000 [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗

**Figure 2.** When feeding 80000 TXs for each iteration of blockchain consensus, [PITH_FULL_IMAGE:figures/full_fig_p001_2.png] view at source ↗

**Figure 3.** Four major phases of BrokerChain protocol in an epoch t. There are two types of shards in BrokerChain, i.e., the partition shard (P-shard) and mining shards (M-shard). Here, we only use two M-shards to illustrate how BrokerChain protocol works. : 𝐵" : 𝐵"#$ : 𝐵"#% : The final TX block generated in each epoch of M-shard #1 : The final TX block generated in each epoch of M-shard #2 : P-shard : M-shard #1 : M-shard #2 :… view at source ↗

Figures from the paper (15 more)

**Figure 4.** Figure 4: Illustration of how blocks connect between epochs (e.g., Bt−1 is a state block generated in epoch t-1 but followed by the first transaction blocks of M-shards in epoch t). by M-shards, and keeps updating the state graph of all accounts. Once all TX blocks have been gen…

**Figure 6.** Figure 6: Comparison of account segmentation results between Monoxide and [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]

**Figure 7.** Figure 7: Data structure of the modified Shard State Tree (mSST). 2019/01 2019/07 2020/01 2020/07 2021/01 2021/07 2022/01 2022/07 2023/01 250 500 750 1000 1250 Chain data Size (GB) (a) Ethereum storage 2019/01 2019/07 2020/01 2020/07 2021/01 2021/07 2022/01 2022/07 2023/01 10 15…

**Figure 10.** Figure 10: The success and failure cases during the handling of CTXs. A success case includes all five operations: Op1-Op5, while a failure case typically indicates that Θ2 is not received by shard #2 within shard #1’s block-height interval [Hcurrent, Hcurrent + Hlock/2]. When r…

**Figure 11.** Figure 11: Theoretical failure probability of the P-shard. can ensure each cross-shard TX is done within the predefined token-lock duration Hlock. When the cross-shard TX is successfully processed, the payer account’s pledged tokens will be received by the payee account. Otherw…

**Figure 12.** Figure 12: Theoretical failure probability of the M-shard. in all M-shards; the symbol shard i (i ∈ N +) as the Mshard whose ID is i ∈ [S]; the integer ni ∈ N +(i ∈ [S]) denote the number of malicious nodes in shard i; and the integer β ∈ N + denote the threshold for the number…

**Figure 13.** Figure 13: The throughput under different methods, while varying Tx arrival rate within {3200, 5000, 8000, 16000} TXs/Sec and increasing # of shards. 8 16 24 32 40 52 64 Number of Shards 0 2 4 6 Latency (sec) 1e2 Monoxide [8] LBF [27] Metis [21] BrokerChain (a) TX arrival rate=3…

**Figure 14.** Figure 14: The Latency under different methods, while varying Tx arrival rate within {3200, 5000, 8000, 16000} TXs/Sec and increasing # of shards. VII. PERFORMANCE EVALUATION A. Settings TX-driven Testbed BlockEmulator. To evaluate the proposed BrokerChain, we first developed a…

**Figure 15.** Figure 15: Throughput and latency vs the # of shards and TX arrival rates, while maximizing system performance to its full potential. simulate increasing workloads, and the number of shards (i.e., S) is increased from 8 to 64. Overall, those results show that BrokerChain outperf…

**Figure 16.** Figure 16: Queue size of the TX pool while changing the arrival rate of transactions. Monoxide LBF Metis BrokerChain (K=10) BrokerChain (K=40) BrokerChain (K=60) BrokerChain (K=80) BrokerChain (K=100) 0 1 2 3 4 Workloads 1e5 Total System Workloads The Largest Workload of All Sha…

**Figure 17.** Figure 17: Effect of the number of segmented accounts (i.e., [PITH_FULL_IMAGE:figures/full_fig_p013_17.png]

**Figure 18.** Figure 18: The workload performance under different methods, while fixing S=64, NTX=8e4 and K=40. CDF stands for cumulative distribution function. S = 16 S = 32 S = 64 0.8 1.0 1.2 1.4 1.6 Total System Workloads 1e5 Monoxide [8] LBF [27] Metis [21] BrokerChain (a) Total system wo…

**Figure 19.** Figure 19: The effect of shard # on the total, the largest and the variance of workloads, while varying S within {16, 32, 64}, and fixing NTX=8e4, K=40. NTX = 8e4 NTX = 12e4 NTX = 16e4 1 2 3 Total System Workloads 1e5 Monoxide [8] LBF [27] Metis [21] BrokerChain (a) Total system…

**Figure 20.** Figure 20: The effect of TX # on the total, the largest and the variance of workloads, while varying NTX within {8e4, 12e4, 16e4}, and fixing S=64, K=40. Chronological Replay Epoch 0 1 2 3 4 5 6 7 Shard ID : Hot Shards : Cold Shards 0 10000 20000 30000 40000 (a) Heatmap of trans…

**Figure 21.** Figure 21: The heatmap comparison of transaction workloads yielded by Monoxide and BrokerChain. Parameters are set to S=8, NTX=8e4 for each epoch. variance, the lower largest shard workload, and the lower cross-shard TX ratio than other baselines. F. Visual Comparison of M-Shard…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 26 canonical work pages

[27]

An improved genetic algorithm using greedy strategy toward task scheduling optimization in cloud environments,

Z. Zhou, F. Li, H. Zhu, H. Xie, J. H. Abawajy, and M. U. Chowdhury, “An improved genetic algorithm using greedy strategy toward task scheduling optimization in cloud environments,” Neural Computing and Applications, vol. 32, no. 6, pp. 1531–1541, 2020

work page 2020
[21]

A fast and high quality multilevel scheme for partitioning irregular graphs,

G. Karypis and V . Kumar, “A fast and high quality multilevel scheme for partitioning irregular graphs,” SIAM Journal on scientific Computing, vol. 20, no. 1, pp. 359–392, 1998

1998
[1]

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,” in Proc. of ACM SIGSAC Conference on Computer and Communications Security (CCS’16), 2016, pp. 17–30

work page 2016
[2]

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,” in Proc. of IEEE Symposium on Security and Privacy (SP’18). IEEE, 2018, pp. 583–598

work page 2018
[3]

Chainspace: A Sharded Smart Contracts Platform,

M. Al-Bassam, A. Sonnino, S. Bano, D. Hrycyszyn, and G. Danezis, “Chainspace: A Sharded Smart Contracts Platform,” in Proc. of Network and Distributed System Security Symposium (NDSS’18) , 2018

work page 2018
[4]

RapidChain: Scaling Blockchain via Full Sharding,

M. Zamani, M. Movahedi, and M. Raykova, “RapidChain: Scaling Blockchain via Full Sharding,” in Proc. of ACM SIGSAC Conference on Computer and Communications Security (CCS’18) , 2018, pp. 931– 948

work page 2018
[5]

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 Proc. of IEEE International Conference on Distributed Computing Systems (ICDCS’19), 2019, pp. 525–535

work page 2019
[6]

Prism: Deconstructing the blockchain to approach physical limits,

V . Bagaria, S. Kannan, D. Tse, G. Fanti, and P. Viswanath, “Prism: Deconstructing the blockchain to approach physical limits,” in Proc. of the ACM SIGSAC Conference on Computer and Communications Security (CCS’19), 2019, pp. 585–602

work page 2019

Show all 28 references

[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,” in Proc. of the international conference on management of data (SIGMOD’19) , 2019, pp. 123–140

2019
[8]

Monoxide: Scale out Blockchains with Asyn- chronous Consensus Zones,

J. Wang and H. Wang, “Monoxide: Scale out Blockchains with Asyn- chronous Consensus Zones,” in Proc. of 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI’19) . Boston, MA: USENIX Association, Feb. 2019, pp. 95–112

2019
[9]

On sharding open blockchains with smart contracts,

Y . Tao, B. Li, J. Jiang, H. C. Ng, C. Wang, and B. Li, “On sharding open blockchains with smart contracts,” in Proc. of IEEE 36th International Conference on Data Engineering (ICDE’20) , 2020, pp. 1357–1368

2020
[10]

MVCOM: Scheduling Most Valuable Committees for the Large-Scale Sharded Blockchain,

H. Huang, Z. Huang, X. Peng, Z. Zheng, and S. Guo, “MVCOM: Scheduling Most Valuable Committees for the Large-Scale Sharded Blockchain,” in Proc. of IEEE International Conference on Distributed Computing Systems (ICDCS’21) . IEEE, 2021, pp. 629–639

2021
[11]

Practical Byzantine fault tolerance,

M. Castro, B. Liskov et al. , “Practical Byzantine fault tolerance,” in Proc. of Symposium on Operating Systems Design and Implementation (OSDI’99), vol. 99, no. 1999, 1999, pp. 173–186

1999
[12]

SkyChain: A Deep Reinforcement Learning-Empowered Dynamic Blockchain Shard- ing System,

J. Zhang, Z. Hong, X. Qiu, Y . Zhan, and W. Chen, “SkyChain: A Deep Reinforcement Learning-Empowered Dynamic Blockchain Shard- ing System,” in Proc. of 49th International Conference on Parallel Processing (ICPP’20), 2020, pp. 1–11

2020
[13]

Bitcoin: A peer-to-peer electronic cash system,

S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Tech. Rep., 2008. [Online]. Available: https://bitcoin.org/bitcoin.pdf

2008
[14]

Ethereum: A secure decentralised generalised trans- action ledger,

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

2014
[15]

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
[16]

Pyramid: A layered sharding blockchain system,

Z. Hong, S. Guo, P. Li, and W. Chen, “Pyramid: A layered sharding blockchain system,” in Proc. of IEEE Conference on Computer Com- munications (INFOCOM’21). IEEE, 2021, pp. 1–10

2021
[17]

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 (TII), vol. 15, no. 10, pp. 5715–5722, 2019

2019
[18]

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
[19]

Securing structured overlays against identity attacks,

K. P. Puttaswamy, H. Zheng, and B. Y . Zhao, “Securing structured overlays against identity attacks,” IEEE Transactions on Parallel and Distributed Systems (TPDS) , vol. 20, no. 10, pp. 1487–1498, 2008

2008
[20]

Towards a Scalable and Robust DHT,

B. Awerbuch and C. Scheideler, “Towards a Scalable and Robust DHT,” Theory of Computing Systems , vol. 45, no. 2, pp. 234–260, 2009

2009
[22]

The elliptic curve digital signature algorithm (ECDSA),

D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digital signature algorithm (ECDSA),” International journal of information security, vol. 1, pp. 36–63, 2001

2001
[23]

Kademlia: A Peer-to-Peer Information System Based on the XOR Metric,

P. Maymounkov and D. M. Eres, “Kademlia: A Peer-to-Peer Information System Based on the XOR Metric,” in Revised Papers from the First International Workshop on Peer-to-peer Systems(IPTPS’02) , 2002, pp. 53–65

2002
[24]

A collaborative intrusion detection approach using blockchain for multimicrogrid sys- tems,

B. Hu, C. Zhou, Y .-C. Tian, Y . Qin, and X. Junping, “A collaborative intrusion detection approach using blockchain for multimicrogrid sys- tems,” IEEE Transactions on Systems, Man, and Cybernetics: Systems , vol. 49, no. 8, pp. 1720–1730, 2019

2019
[25]

A novel methodology-based joint hypergeometric distribution to analyze the security of sharded blockchains,

A. Hafid, A. S. Hafid, and M. Samih, “A novel methodology-based joint hypergeometric distribution to analyze the security of sharded blockchains,” IEEE Access, vol. 8, pp. 179 389–179 399, 2020

2020
[26]

BlockEmulator: An Emulator Enabling to Test Blockchain Sharding Protocols ,

H. Huang, G. Ye, Q. Chen, Z. Yin, X. Luo, J. Lin, T. Li, Q. Yang, and Z. Zheng, “ BlockEmulator: An Emulator Enabling to Test Blockchain Sharding Protocols ,” arXiv preprint arXiv:2311.03612 , 2023

2023 arXiv
[28]

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,” in Proc. of IEEE Conference on Computer Communications (INFOCOM’22). IEEE, 2022, pp. 1968–1977. Huawei Huang (SM’22)...

2022

Pith tools

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

[1] [27]

An improved genetic algorithm using greedy strategy toward task scheduling optimization in cloud environments,

Z. Zhou, F. Li, H. Zhu, H. Xie, J. H. Abawajy, and M. U. Chowdhury, “An improved genetic algorithm using greedy strategy toward task scheduling optimization in cloud environments,” Neural Computing and Applications, vol. 32, no. 6, pp. 1531–1541, 2020

work page 2020

[2] [21]

A fast and high quality multilevel scheme for partitioning irregular graphs,

G. Karypis and V . Kumar, “A fast and high quality multilevel scheme for partitioning irregular graphs,” SIAM Journal on scientific Computing, vol. 20, no. 1, pp. 359–392, 1998

1998

[3] [1]

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,” in Proc. of ACM SIGSAC Conference on Computer and Communications Security (CCS’16), 2016, pp. 17–30

work page 2016

[4] [2]

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,” in Proc. of IEEE Symposium on Security and Privacy (SP’18). IEEE, 2018, pp. 583–598

work page 2018

[5] [3]

Chainspace: A Sharded Smart Contracts Platform,

M. Al-Bassam, A. Sonnino, S. Bano, D. Hrycyszyn, and G. Danezis, “Chainspace: A Sharded Smart Contracts Platform,” in Proc. of Network and Distributed System Security Symposium (NDSS’18) , 2018

work page 2018

[6] [4]

RapidChain: Scaling Blockchain via Full Sharding,

M. Zamani, M. Movahedi, and M. Raykova, “RapidChain: Scaling Blockchain via Full Sharding,” in Proc. of ACM SIGSAC Conference on Computer and Communications Security (CCS’18) , 2018, pp. 931– 948

work page 2018

[7] [5]

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 Proc. of IEEE International Conference on Distributed Computing Systems (ICDCS’19), 2019, pp. 525–535

work page 2019

[8] [6]

Prism: Deconstructing the blockchain to approach physical limits,

V . Bagaria, S. Kannan, D. Tse, G. Fanti, and P. Viswanath, “Prism: Deconstructing the blockchain to approach physical limits,” in Proc. of the ACM SIGSAC Conference on Computer and Communications Security (CCS’19), 2019, pp. 585–602

work page 2019