Pith. sign in

REVIEW 4 major objections 5 minor 51 references

HiCoCS: High Concurrency Cross-Sharding on Permissioned Blockchains

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

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

Pith's one-line read HiCoCS claims per-transaction composite keys eliminate MVCC conflicts in Fabric cross-sharding, giving 3.5-20.2x throughput gains.

desk verdict Novel composite-key virtual sub-broker trick for Fabric cross-sharding is plausible and worth a referee, but the privacy proof is under-specified and same-initiator concurrency remains a real gap. read the letter →

arxiv 2501.04265 v3 pith:L6GRJIVL submitted 2025-01-08 cs.DC

Lingxiao Yang , Xuewen Dong , Zhiguo Wan , Di Lu , Yushu Zhang , Yulong Shen This is my paper · ORCID
classification cs.DC
keywords cross-shardtransactionhighconcurrencyHyperledgerFabricMVCCconflictcompositekeyvirtualsub-brokerhomomorphicencryptionCKKS
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 the main obstacle to high-concurrency cross-shard transactions in permissioned blockchains is not network capacity but the version-checking mechanism that aborts transactions whenever multiple transfers touch the same intermediary account. Its proposed scheme, HiCoCS, sidesteps this by giving each cross-shard transaction its own virtual sub-broker, implemented as a composite key on the existing intermediary node, so concurrent writes hit distinct ledger keys instead of one contended key. The paper further claims that a homomorphic-encryption module lets intermediaries batch-accumulate amounts in ciphertext, and that a composite-key reuse protocol cuts the storage overhead. Evaluations report throughput gains of 3.5-20.2x, success-rate gains of 2.2-8.1x, and latency reductions of 43.9-62.0% against a vanilla Fabric cross-shard design and two baselines. If correct, this would make Fabric-based enterprise sharding practical under heavy inter-shard traffic without adding expensive intermediary nodes.

What carries the argument

The load-bearing object is the composite key built from the intermediary, initiator, receiver, and amount ciphertext, written as $g_j-O_a-D_b-V_i$ and stored in the state database. Each such key is a virtual sub-broker: a separate ledger slot that makes concurrent cross-shard transactions write to distinct keys. The rest of the design, including the transaction pool, incremental accumulation, CKPoE reuse, and CKKS homomorphic summation, exists to feed and clean up these keys. The paper's data-confidentiality argument relies on intermediaries operating only on ciphertexts, while its eventual-atomicity argument relies on the uniqueness of each composite key to roll back exactly the failed transaction.

What would settle it

Instrument the prototype's convert() interface to log every DecryptAES call; if any such call executes inside an intermediary process, then that intermediary sees plaintext amounts and the claimed data confidentiality is refuted. A cheaper check is to rerun the f=90% skew experiment with FHE enabled and see whether the transaction success rate stays above 95% and the throughput ratio against the vanilla baseline remains at least 3.5.

Watch

Extended reading notes

Core claim

The central discovery is that MVCC conflicts in cross-shard processing can be converted into a non-issue by having the smart contract create a composite key for every incoming cross-shard transaction. These composite keys act as virtual sub-brokers that share the intermediary's workload, so N simultaneous transfers write N distinct state entries instead of contending for one account balance. On top of this, the paper moves the per-account accumulation of incoming amounts into CKKS ciphertexts, so the intermediary can sum a batch of transactions without exposing individual amounts, and periodically summarizes the pool via a Composite Key Proof of Equivalence to reclaim space. The paper claims this preserves eventual atomicity via message-passing while eliminating the write-write conflicts that plague 2PL and OCC schemes under high skew.

Load-bearing premise

The scheme assumes an intermediary can process transactions honestly while only ever seeing ciphertexts; if any intermediary-controlled step decrypts a transaction amount, the confidentiality claim fails.

Editorial extensions

If this is right

  • Transaction success rate stays above 95% even at high skew, where the baselines degrade sharply, so retry storms largely disappear.
  • Because composite keys are created by smart-contract API calls rather than new peers, adding concurrency headroom costs little in CPU and memory compared with adding intermediary accounts.
  • Batch settlement under CKKS ciphertexts lets one periodic settlement close many cross-shard transactions, with decrypted-sum error below $10^{-5}$, effectively negligible against transaction fees.
  • Composite key reuse cuts memory utilization by about 31.6% and ComKeyPool query time by about 8.3% in the reported tests.
  • Doubling the shard count from 16 to 32 nearly doubles throughput in the reported experiments, indicating the scheme scales with the network.

Reading between the lines

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

  • The privacy guarantee is load-bearing on where Algorithm 1's DecryptAES call runs; if that call executes inside an intermediary-controlled chaincode, the intermediary has access to plaintext amounts and the ciphertext-only assumption collapses.
  • The composite-key trick is portable to any ledger whose smart contracts can form structured keys, such as Solidity-based mappings, even without Fabric's dedicated composite-key API.
  • The reported performance advantage is largest under high-contention workloads; under near-uniform traffic, the overhead of key creation, pool queries, and CKKS operations may outweigh the conflict savings, so the practical deployment question is where the crossover lies.
  • Batch settlement gives eventual rather than immediate atomicity, so applications requiring strict cross-shard atomicity on demand would need an additional assurance layer beyond what HiCoCS provides.
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

4 major / 5 minor

Summary. The paper proposes HiCoCS, a cross-shard transaction scheme for Hyperledger Fabric that aims to reduce MVCC conflicts under high concurrency by creating per-transaction composite keys (virtual sub-brokers) on intermediary accounts, and to protect transaction amounts from semi-trusted intermediaries using CKKS homomorphic encryption. It also introduces a composite-key reuse protocol (CKPoE) for efficiency. The evaluation on a Fabric prototype reports transaction success rates and throughput improvements of 2.2-8.1x and 3.5-20.2x over three baselines, with modest overhead when FHE is enabled.

Significance. If the concurrency mechanism is sound, the paper addresses a real and under-studied problem: MVCC conflicts in permissioned-blockchain cross-shard settings. The virtual sub-broker idea is simple and plausibly effective when the actual contention point is the intermediary's hot account, and the paper provides a prototype with quantitative comparisons. However, two load-bearing issues—the source-channel deduction mechanism and the confidentiality proof—are not resolved in the manuscript, and both are central to the stated contributions. The empirical claims are also weakened by the lack of released code and by the simulation of two of the three baselines. The privacy-preservation contribution, in particular, is contradicted by the paper's own pseudocode, and the concurrency claim is under-specified at the exact point where the initiator's own account is updated.

major comments (4)
  1. [VI-A and Algorithm 1, line 11]
  2. [Section IV-A and Section V-B]
  3. [Section V-A, V-B, and Theorem 2]
  4. [Section VII-B and VII-C]
minor comments (5)
  1. [Table II]
  2. [Section VII-B]
  3. [Algorithm 2, line 17]
  4. [Section IV-A, Fig. 5 and Fig. 3]
  5. [Section VII-A]

Circularity Check

1 steps flagged · score 4.0 of 10

Throughput claims are empirical and self-contained; the privacy proof is circular because Theorem 1 assumes the ciphertext-only property it must prove, and Algorithm 1 as written decrypts AES amounts.

  1. other [Section VI-A (Theorem 1 proof); Section V-C (Algorithm 1, Lines 10-16)]
    "According to the security properties of the CKKS encryption algorithm [39], the intermediary can only operate in the ciphertext space when processing transactions. ... First, the intermediary traverses aesStrCipher and calls the AES decryption function to decrypt each Vi to get the amount of each CSTx, i.e., line 11."

    The theorem's conclusion is exactly the invariant asserted as a premise: that the semi-trusted intermediary only ever sees ciphertexts. The proof imports this invariant from CKKS without establishing that the protocol enforces it; however, Algorithm 1, which the surrounding text attributes to the intermediary, executes DecryptAES(skey, Vi) at line 11. The attempted rescue (skey is stored in the initiator's private data collection; Amounti is an intermediate value not available to the intermediary) is not part of the proof and does not follow from CKKS security. As written, the data-confidentiality guarantee reduces to the unproven assumption that the intermediary never runs the decryption step, which is the very proposition being proved.

full rationale

The core throughput and success-rate contributions are measured against the vanilla Fabric baseline, AHL+, and Meepo, not derived from the system's own parameters. No fitted values are renamed as predictions, and the composite-key mechanism makes write conflicts structurally absent by giving each CSTx a unique key containing a timestamp; that is a design property, not a circular derivation. The 3.5-20.2x throughput figure is an experimental observation on a 16-shard/64-node and 32-shard/128-node prototype. Minor self-citations (refs [3]-[5]) motivate the setting but do not carry the derivation. The only substantial circularity is in Theorem 1's security proof, where the premise that the intermediary operates only in ciphertext space is equivalent to the theorem's conclusion, and Algorithm 1's AES-decrypt step contradicts that premise unless an unstated trust boundary is assumed. Because the privacy guarantee is one of the paper's listed contributions, this step prevents a 0-2 score, but it does not undermine the independent empirical throughput claim, so the score stays at 4 rather than 6+.

Assumptions & free parameters 3 free parameters · 6 assumptions · 3 invented entities

The central design rests on standard cryptographic assumptions plus two assumptions specific to this paper: that intermediaries never see plaintext (contradicted by Algorithm 1) and that initiator balance updates do not introduce MVCC conflicts (unsubstantiated). No parameters are fitted to data, but several implementation-level constants are hand-chosen.

free parameters (3)
  • CKKS scaling factor Delta
    Algorithm 1 line 14 multiplies plaintext amounts by Delta to control precision; the value is chosen by the implementer, not fitted to data.
  • Ciphertext batch and slot group size n
    Algorithm 1 lines 22-23 loop ceil(batch/n) times; these sizes are implementation choices affecting performance and are not derived from the problem.
  • Exchange rate Crate
    Algorithm 1 line 25 multiplies the summed ciphertext by Crate; it is a domain input for cross-shard asset conversion, not fitted.
assumptions (6)
  • standard math CKKS homomorphic encryption is semantically secure and supports the stated arithmetic (additions and multiplications) within a bounded noise budget.
    Invoked in Section III-D and Theorem 1 via reference [39].
  • domain assumption Hyperledger Fabric's composite key API and MVCC validation work as described, so writes to distinct composite keys do not conflict.
    Section III-C; the entire conflict-avoidance mechanism depends on this.
  • domain assumption At least one honest intermediary joins both source and target channels.
    Stated in Section IV-B threat model; needed for service availability.
  • domain assumption Fabric channels acting as shards are secure and reliable.
    Stated in Section IV-B; the protocol does not defend against channel-level failures.
  • ad hoc to paper The intermediary never sees plaintext transaction amounts, despite Algorithm 1 line 11 decrypting each Vi.
    Assumed in Theorem 1 but contradicted by the algorithm in Section V-C; this is a load-bearing inconsistency.
  • ad hoc to paper Funds can be deducted from the initiator's account without creating an MVCC conflict for concurrent transactions from the same initiator.
    Section IV-A step 3 transfers assets from initiator to intermediary but no mechanism for updating the initiator's balance key is specified; Fig. 4 shows a single initiator O1 with four concurrent transactions.
invented entities (3)
  • Virtual sub-broker
    purpose: A per-transaction composite key ledger entry that absorbs cross-shard transfer amounts instead of writing to a single intermediary account.
    The core novel artifact; only the paper's own prototype demonstrates it, and the paper does not ship code or a formal specification.
  • ComKeyPool
    purpose: Composite-key transaction pool that batches pending CSTxs before settlement.
    Internal data structure; no independent verification.
  • CKPoE protocol
    purpose: Composite Key Proof of Equivalence to reuse composite keys and reduce storage overhead.
    Protocol sketched in Algorithm 2; no formal proof or implementation artifact provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of HiCoCS: High Concurrency Cross-Sharding on Permissioned Blockchains." pith.science (2026). https://pith.science/paper/L6GRJIVL

@misc{pith2026250104265,
  author       = {Pith},
  title        = {Pith review of: HiCoCS: High Concurrency Cross-Sharding on Permissioned Blockchains},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/L6GRJIVL}},
  note         = {Machine review of arXiv:2501.04265}
}
read the original abstract

As the foundation of the Web3 trust system, blockchain technology faces increasing demands for scalability. Sharding emerges as a promising solution, but it struggles to handle highly concurrent cross-shard transactions (\textsf{CSTx}s), primarily due to simultaneous ledger operations on the same account. Hyperledger Fabric, a permissioned blockchain, employs multi-version concurrency control for parallel processing. Existing solutions use channels and intermediaries to achieve cross-sharding in Hyperledger Fabric. However, the conflict problem caused by highly concurrent \textsf{CSTx}s has not been adequately resolved. To fill this gap, we propose HiCoCS, a high concurrency cross-shard scheme for permissioned blockchains. HiCoCS creates a unique virtual sub-broker for each \textsf{CSTx} by introducing a composite key structure, enabling conflict-free concurrent transaction processing while reducing resource overhead. The challenge lies in managing large numbers of composite keys and mitigating intermediary privacy risks. HiCoCS utilizes virtual sub-brokers to receive and process \textsf{CSTx}s concurrently while maintaining a transaction pool. Batch processing is employed to merge multiple \textsf{CSTx}s in the pool, improving efficiency. We explore composite key reuse to reduce the number of virtual sub-brokers and lower system overhead. Privacy preservation is enhanced using homomorphic encryption. Evaluations show that HiCoCS improves cross-shard transaction throughput by 3.5-20.2 times compared to the baselines.

Figures

Figures reproduced from arXiv: 2501.04265 by the authors.

Figure 1
Figure 1. The MVCC conflict and a cross-shard example in Hyperledger Fabric. [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Hyperledger Fabric’s transaction processing flow. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. An example illustrating the HiCoCS. • Initiator. As an initiator user of CSTxs, it first transfers assets in the source channel to an intermediary account. • Intermediary group. It consists of multiple intermediary nodes, each of which should be satisfied with owning assets on both the source and target channels. An intermediary summarizes and processes multiple CSTxs in a unified manner to realize cross-shard asset… view at source ↗
Figures from the paper (10 more)
Figure 5
Figure 5. Figure 5: Building blocks of HiCoCS. • Efficiency. The system can process CSTxs efficiently and cost-effectively, i.e., it is characterized by high throughput, low confirmation latency, and low resource overhead. • Security. The security of CSTxs includes (i) Data con￾fidentiali…
Figure 6
Figure 6. Figure 6: Composite key construction. composite key, including composite key summarization and regeneration operations. It hands over the updated simplified ComKeyPool to the incremental accumulation module. • Ciphertext conversion & computation mechanisms first convert the tran…
Figure 7
Figure 7. Figure 7: Ciphertext conversion process. is represented in complex space, if an operation is performed on a real number, the imaginary part of the complex number needs to be set to zero first, i.e., line 12. Then, the array (Amounts) is encoded as a CKKS plaintext m(X) in intege…
Figure 8
Figure 8. Figure 8: Composite key reuse. decryption results and records them in its ledger. The plaintext code for the amount to be transferred to the receiver of the target channel is as follows inAmount = encoder.Decode(DecryptCKKS(sk, CfinalSum)). The plaintext code for the amount ulti…
Figure 9
Figure 9. Figure 9: Comparison of concurrency performance under varying skewness [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]
Figure 10
Figure 10. Figure 10: Comparison of concurrency performance under varying block sizes. [PITH_FULL_IMAGE:figures/full_fig_p010_10.png]
Figure 11
Figure 11. Figure 11: Dynamic performance comparison for varying numbers of transactions. [PITH_FULL_IMAGE:figures/full_fig_p011_11.png]
Figure 12
Figure 12. Figure 12: A quantitative comparison of system overhead and performance [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]
Figure 13
Figure 13. Figure 13: Performance comparison before and after composite key reuse [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]
Figure 15
Figure 15. Figure 15: Performance comparison of HiCoCS before and after enabling privacy [PITH_FULL_IMAGE:figures/full_fig_p012_15.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

51 extracted references · 49 canonical work pages

  1. [1]

    An overview of blockchain technology: Architecture, consensus, and future trends,

    Z. Zheng, S. Xie, H. Dai, X. Chen, and H. Wang, “An overview of blockchain technology: Architecture, consensus, and future trends,” in 2017 IEEE international congress on big data (BigData congress). IEEE, 2017, pp. 557–564

    work page 2017

  2. [2]

    Microthingschain: blockchain-based controlled data sharing platform in multi-domain iot,

    X. Zhu, J. Zheng, B. Ren, X. Dong, and Y . Shen, “Microthingschain: blockchain-based controlled data sharing platform in multi-domain iot,” Journal of Networking and Network Applications , 2021

    work page 2021

  3. [3]

    Ti-biov: Traffic information interaction for blockchain-based iov with trust and incentive,

    W. Tong, X. Dong, Y . Zhang, Z. Zhang, L. Yang, W. Yang, and Y . Shen, “Ti-biov: Traffic information interaction for blockchain-based iov with trust and incentive,” IEEE Internet of Things Journal , 2023

    work page 2023

  4. [4]

    Asyncsc: An asynchronous sidechain for multi-domain data exchange in internet of things,

    L. Yang, X. Dong, Z. Wan, S. Gao, W. Tong, D. Lu, Y . Shen, and X. Du, “Asyncsc: An asynchronous sidechain for multi-domain data exchange in internet of things,” in IEEE INFOCOM 2025-IEEE Conference on Computer Communications, 2025

    work page 2025

  5. [5]

    Optimal hub placement and deadlock-free routing for payment channel network scalability,

    L. Yang, X. Dong, S. Gao, Q. Qu, X. Zhang, W. Tian, and Y . Shen, “Optimal hub placement and deadlock-free routing for payment channel network scalability,” in 2023 IEEE 43th International Conference on Distributed Computing Systems (ICDCS) . IEEE, 2023

    work page 2023

  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,” in IEEE INFOCOM 2022-IEEE Conference on Computer Communications, 2022, pp. 1968–1977

    work page 2022

  7. [7]

    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 Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 17–30

    work page 2016

  8. [8]

    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 2018 IEEE symposium on security and privacy (SP) . IEEE, 2018, pp. 583–598

    work page 2018

Show all 51 references
  1. [9]

    Rapidchain: Scaling blockchain via full sharding,

    M. Zamani, M. Movahedi, and M. Raykova, “Rapidchain: Scaling blockchain via full sharding,” in Proceedings of the 2018 ACM SIGSAC conference on computer and communications security, 2018, pp. 931–948

    2018

  2. [10]

    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 Proceedings 2018 Network and Distributed System Security Symposium , 2018

    2018

  3. [11]

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

    J. Wang and H. Wang, “Monoxide: Scale out blockchains with asyn- chronous consensus zones,” in 16th USENIX symposium on networked systems design and implementation (NSDI 19) , 2019, pp. 95–112

    2019

  4. [12]

    Pyramid: A layered sharding blockchain system,

    Z. Hong, S. Guo, P. Li, and W. Chen, “Pyramid: A layered sharding blockchain system,” in IEEE INFOCOM 2021-IEEE Conference on Computer Communications, 2021, pp. 1–10

    2021

  5. [13]

    Cochain: High concurrency blockchain sharding via consensus on consensus,

    M. Li, Y . Lin, J. Zhang, and W. Wang, “Cochain: High concurrency blockchain sharding via consensus on consensus,” in IEEE INFOCOM 2023-IEEE Conference on Computer Communications , 2023

    2023

  6. [14]

    Hyperledger fabric: a distributed operating system for permissioned blockchains,

    E. Androulaki, A. Barger, V . Bortnikov, C. Cachin et al., “Hyperledger fabric: a distributed operating system for permissioned blockchains,” in Proceedings of the thirteenth EuroSys conference , 2018, pp. 1–15

    2018

  7. [15]

    A hierarchical sharding protocol for multi-domain iot blockchains,

    W. Tong, X. Dong, Y . Shen, and X. Jiang, “A hierarchical sharding protocol for multi-domain iot blockchains,” in 2019 IEEE International Conference on Communications . IEEE, 2019, pp. 1–6

    2019

  8. [16]

    Scaling blockchain via layered sharding,

    Z. Hong, S. Guo, and P. Li, “Scaling blockchain via layered sharding,” IEEE Journal on Selected Areas in Communications , vol. 40, no. 12, pp. 3575–3588, 2022

    2022

  9. [17]

    Benzene: Scaling blockchain with cooperation-based sharding,

    Z. Cai, J. Liang, W. Chen, Z. Hong, H.-N. Dai, J. Zhang, and Z. Zheng, “Benzene: Scaling blockchain with cooperation-based sharding,” IEEE Transactions on Parallel and Distributed Systems , vol. 34, no. 2, pp. 639–654, 2022

    2022

  10. [18]

    Neuchain: a fast permissioned blockchain system with deterministic ordering,

    Z. Peng, Y . Zhang, Q. Xu, H. Liu, Y . Gao, X. Li, and G. Yu, “Neuchain: a fast permissioned blockchain system with deterministic ordering,” Proceedings of the VLDB Endowment , vol. 15, no. 11, pp. 2585–2598, 2022

    2022

  11. [19]

    Prophet: Conflict-free sharding blockchain via byzantine- tolerant deterministic ordering,

    Z. Hong, S. Guo, E. Zhou, J. Zhang, W. Chen, J. Liang, J. Zhang, and A. Zomaya, “Prophet: Conflict-free sharding blockchain via byzantine- tolerant deterministic ordering,” in IEEE INFOCOM 2023-IEEE Confer- ence on Computer Communications , 2023

    2023

  12. [20]

    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,” in 2022 41st International Symposium on Reliable Distributed Systems (SRDS). IEEE, 2022, pp. 284–294

    2022

  13. [21]

    A flexible sharding blockchain protocol based on cross-shard byzantine fault tolerance,

    Y . Liu, X. Xing, H. Cheng, D. Li, Z. Guan, J. Liu, and Q. Wu, “A flexible sharding blockchain protocol based on cross-shard byzantine fault tolerance,” IEEE Transactions on Information Forensics and Security, vol. 18, pp. 2276–2291, 2023

    2023

  14. [22]

    Gridb: Scaling blockchain database via sharding and off-chain cross-shard mechanism,

    Z. Hong, S. Guo, E. Zhou, W. Chen, H. Huang, and A. Zomaya, “Gridb: Scaling blockchain database via sharding and off-chain cross-shard mechanism,” Proceedings of the VLDB Endowment , vol. 16, no. 7, pp. 1685–1698, 2023

    2023

  15. [23]

    Lightcross: Sharding with lightweight cross-shard exe- cution for smart contracts,

    X. Qi and Y . Li, “Lightcross: Sharding with lightweight cross-shard exe- cution for smart contracts,” in IEEE INFOCOM 2024-IEEE Conference on Computer Communications , 2024, pp. 1681–1690

    2024

  16. [24]

    X-shard: Optimistic cross-shard transaction processing for sharding-based blockchains,

    J. Xu, Y . Ming, Z. Wu, C. Wang, and X. Jia, “X-shard: Optimistic cross-shard transaction processing for sharding-based blockchains,” IEEE Transactions on Parallel and Distributed Systems , 2024

    2024

  17. [25]

    Sharon: Secure and efficient cross-shard transaction processing via shard rotation,

    S. Jiang, J. Cao, C. L. Tung, Y . Wang, and S. Wang, “Sharon: Secure and efficient cross-shard transaction processing via shard rotation,” in IEEE INFOCOM 2024 - IEEE Conference on Computer Communications , 2024, pp. 2418–2427

    2024

  18. [26]

    Sok: Public blockchain sharding,

    M. M. Al Barat, S. Li, C. Du, Y . T. Hou, and W. Lou, “Sok: Public blockchain sharding,” in 2024 IEEE International Conference on Blockchain and Cryptocurrency (ICBC) . IEEE, 2024, pp. 766–783

    2024

  19. [27]

    Multi-version concurrency control scheme for a database system,

    S. Muro, T. Kameda, and T. Minoura, “Multi-version concurrency control scheme for a database system,” Journal of Computer and System Sciences, vol. 29, no. 2, pp. 207–224, 1984

    1984

  20. [28]

    An empirical evaluation of in-memory multi-version concurrency control,

    Y . Wu, J. Arulraj, J. Lin, R. Xian, and A. Pavlo, “An empirical evaluation of in-memory multi-version concurrency control,” Proceedings of the VLDB Endowment, vol. 10, no. 7, pp. 781–792, 2017

    2017

  21. [29]

    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 Proceedings of the 2019 international conference on management of data , 2019, pp. 123–140

    2019

  22. [30]

    Aeolus: Distributed execution of permissioned blockchain transactions via state sharding,

    P. Zheng, Q. Xu, X. Luo, Z. Zheng, W. Zheng, X. Chen, Z. Zhou, Y . Yan, and H. Zhang, “Aeolus: Distributed execution of permissioned blockchain transactions via state sharding,” IEEE Transactions on Industrial Informatics, vol. 18, no. 12, pp. 9227–9238, 2022

    2022

  23. [31]

    Service-aware dynamic sharding approach for scalable blockchain,

    S. K. Set and G. S. Park, “Service-aware dynamic sharding approach for scalable blockchain,” IEEE Transactions on Services Computing , vol. 16, no. 4, pp. 2954–2969, 2022

    2022

  24. [32]

    Channels: Horizontal scaling and confidentiality on permissioned blockchains,

    E. Androulaki, C. Cachin, A. De Caro, and E. Kokoris-Kogias, “Channels: Horizontal scaling and confidentiality on permissioned blockchains,” in 14 Computer Security: 23rd European Symposium on Research in Computer Security, 2018, pp. 111–131

    2018

  25. [33]

    Meepo: Multiple execution environments per organization in sharded consortium blockchain,

    P. Zheng, Q. Xu, Z. Zheng, Z. Zhou, Y . Yan, and H. Zhang, “Meepo: Multiple execution environments per organization in sharded consortium blockchain,” IEEE Journal on Selected Areas in Communications, vol. 40, no. 12, pp. 3562–3574, 2022

    2022

  26. [34]

    Gordian: Efficient and scalable discovery of composite keys,

    Y . Sismanis, P. Brown, P. J. Haas, and B. Reinwald, “Gordian: Efficient and scalable discovery of composite keys,” in Proceedings of the 32nd International Conference on Very Large Data Bases , ser. VLDB ’06. VLDB Endowment, 2006, p. 691–702

    2006

  27. [35]

    A survey on homomorphic encryption schemes: Theory and implementation,

    A. Acar, H. Aksu, A. S. Uluagac, and M. Conti, “A survey on homomorphic encryption schemes: Theory and implementation,” ACM Computing Surveys (Csur) , vol. 51, no. 4, pp. 1–35, 2018

    2018

  28. [36]

    Privacy preserving in blockchain based on partial homomorphic encryption system for ai applications,

    S. Yaji, K. Bangera, and B. Neelima, “Privacy preserving in blockchain based on partial homomorphic encryption system for ai applications,” in 2018 IEEE 25th International Conference on High Performance Computing Workshops (HiPCW). IEEE, 2018, pp. 81–85

    2018

  29. [37]

    Privacy-aware quadratic optimization using partially homomorphic encryption,

    Y . Shoukry, K. Gatsis, A. Alanwar, G. J. Pappas, S. A. Seshia, M. Srivastava, and P. Tabuada, “Privacy-aware quadratic optimization using partially homomorphic encryption,” in 2016 IEEE 55th Conference on Decision and Control (CDC) . IEEE, 2016, pp. 5053–5058

    2016

  30. [38]

    Privacy-preserving machine learning with fully homomorphic encryption for deep neural network,

    J.-W. Lee, H. Kang, Y . Lee, W. Choi, J. Eom, M. Deryabin, E. Lee, J. Lee, D. Yoo, Y .-S. Kim et al., “Privacy-preserving machine learning with fully homomorphic encryption for deep neural network,” IEEE Access, vol. 10, pp. 30 039–30 054, 2022

    2022

  31. [39]

    Homomorphic encryption for arithmetic of approximate numbers,

    J. H. Cheon, A. Kim, M. Kim, and Y . Song, “Homomorphic encryption for arithmetic of approximate numbers,” in Advances in Cryptology– ASIACRYPT 2017: 23rd International Conference on the Theory and Applications of Cryptology and Information Security , 2017, pp. 409–437

    2017

  32. [40]

    Experiences threat modeling at microsoft

    A. Shostack, “Experiences threat modeling at microsoft.” MODSEC@ MoDELS, vol. 2008, p. 35, 2008

    2008

  33. [41]

    ML-DDoS: A blockchain- based multilevel DDoS mitigation mechanism for IoT environments,

    R. F. Hayat, S. Aurangzeb, M. Aleem et al., “ML-DDoS: A blockchain- based multilevel DDoS mitigation mechanism for IoT environments,” IEEE Transactions on Engineering Management , 2022

    2022

  34. [42]

    Advanced encryption standard,

    D. Selent, “Advanced encryption standard,” Rivier Academic Journal , vol. 6, no. 2, pp. 1–14, 2010

    2010

  35. [43]

    Towards understanding and demystifying bitcoin mixing services,

    L. Wu, Y . Hu, Y . Zhou, H. Wang, X. Luo, Z. Wang, F. Zhang, and K. Ren, “Towards understanding and demystifying bitcoin mixing services,” in Proceedings of the Web Conference 2021 , 2021, pp. 33–44

    2021

  36. [44]

    A detailed and real-time performance monitoring framework for blockchain systems,

    P. Zheng, Z. Zheng, X. Luo, X. Chen, and X. Liu, “A detailed and real-time performance monitoring framework for blockchain systems,” in Proceedings of the 40th international conference on software engineering: software engineering in practice , 2018, pp. 134–143

    2018

  37. [45]

    Efficient liquidity providing via margin liquidity,

    Y . Jeong, C. Jeoung, H. Jeong, S. Han, and J. Kim, “Efficient liquidity providing via margin liquidity,” in 2023 IEEE International Conference on Blockchain and Cryptocurrency (ICBC) . IEEE, 2023, pp. 1–3

    2023

  38. [46]

    Mneme: A mobile distributed ledger,

    D. Chatzopoulos, S. Gujar, B. Faltings, and P. Hui, “Mneme: A mobile distributed ledger,” in IEEE INFOCOM 2020-IEEE Conference On Computer Communications, 2020, pp. 1897–1906

    2020

  39. [47]

    Enterprise Ethereum Alliance,

    “Enterprise Ethereum Alliance,” https://entethalliance.org/, 2024

    2024

  40. [48]

    ChainMaker,

    “ChainMaker,” https://chainmaker.org.cn/, 2024

    2024

  41. [49]

    On the security of homomorphic encryption on approximate numbers,

    B. Li and D. Micciancio, “On the security of homomorphic encryption on approximate numbers,” in Advances in Cryptology–EUROCRYPT 2021: 40th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Zagreb, Croatia, October 17–21, 2021, Proceed...

    2021

  42. [51]

    He has produced more than 100 research peer-reviewed journal and conference papers

    He is currently a Professor with the College of Computer Science and Technology, Nanjing Uni- versity of Aeronautics and Astronautics, China. He has produced more than 100 research peer-reviewed journal and conference papers. His research interests include multimedia security ...

    2002

  43. [2014]

    His research interests include trusted computing, cloud computing, system and network security

    Currently, he is an associate professor with the school of Computer Science and Technology, Xidian University. His research interests include trusted computing, cloud computing, system and network security. Yushu Zhang (Senior Member, IEEE) received the B.S. degree from the Sc...

    2010

Pith tools

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