{"id":"d10f4828-5140-4776-87c0-44834e92d3b6","arxiv_id":"2501.04265","paper_version":3,"verdict":"REJECT","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":3,"one_line_summary":"HiCoCS uses composite keys as per-transaction virtual sub-brokers to reduce MVCC conflicts in Hyperledger Fabric cross-shard transactions, claiming 3.5-20.2x throughput gains.","lead":"This paper proposes HiCoCS, a scheme for Hyperledger Fabric that uses composite keys to create per-transaction virtual sub-brokers, reducing write conflicts in cross-shard transactions. If it works, it could let enterprise blockchains handle many more simultaneous cross-shard transfers, but the privacy and accounting claims need scrutiny.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Privacy claim is internally unsupported: Algorithm 1 decrypts AES amounts where Theorem 1 assumes ciphertext-only operation, so the semi-trusted intermediary can see plaintext unless an unspecified trusted component runs the decryption.","rationale":"The reader's weakest assumption identifies the same load-bearing flaw as this stress-test pass. The central concurrency mechanism, creating per-transaction composite keys to reduce MVCC conflicts on an intermediary key, is credible for the workload evaluated, and the prototype is a genuine implementation effort. However, the paper's privacy contribution, which is presented in the abstract, in the contributions list, and as a formal security theorem, is not supported by the construction. Algorithm 1 places an AES decryption step inside the intermediary-oriented accumulation flow, and the proof of Theorem 1 simply asserts that the intermediary operates only in ciphertext space. Either the intermediary-controlled peer observes the plaintext amount, contradicting data confidentiality, or the scheme relies on an unspecified trusted component that performs the decryption, in which case the theorem's stated assumption is not established. The optional-privacy note in Section IV-C does not rescue this, because the paper still claims a proven privacy guarantee and evaluates the FHE-enabled mode as part of its results. The initiator-side MVCC conflict and the simulated baselines are additional limitations, but the privacy contradiction is more decisive because it breaks a stated security guarantee through an internal inconsistency, and it is the condition the reader already singled out. The concrete test proposed above would settle whether the implementation happens to use a trusted initiator-side oracle; if it does, the paper needs substantial revision to state that boundary and adjust the pseudocode and theorem, and until then the REJECT verdict stands.","tokens_in":22037,"tokens_out":14817,"duration_ms":150564,"concrete_test":"Run the released HiCoCS prototype in a minimal Fabric network with an initiator organization and an intermediary organization, both joined to the source channel. Configure the private data collection holding skey to be visible only to the initiator org, then have the intermediary org invoke cstxAcc/convert() on its own peer. Two outcomes are decisive: (1) if the intermediary's peer cannot access skey, the endorsement fails, showing Algorithm 1 as written cannot run at the intermediary; (2) if it can access skey (or if the chaincode logs Amounti at line 11), the intermediary can recover every transaction amount, refuting Theorem 1. If the code instead executes line 11 solely on an initiator-controlled peer, that fact must be stated as an explicit trust assumption and the pseudocode in Algorithm 1 corrected; the current text does not support Theorem 1.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section VI-A, Theorem 1 states that a PPT adversary masquerading as an intermediary cannot extract transaction amounts because 'the intermediary can only operate in the ciphertext space when processing transactions.' The described protocol does not deliver that condition. In Algorithm 1 (Section V-C), the incremental accumulation routine, whose stated input is the intermediary's key gj, executes at lines 10-16: it iterates over aesStrCipher, performs Amounti <- DecryptAES(skey, Vi), encodes the resulting plaintext amounts as a CKKS plaintext vector, and only then CKKS-encrypts. Fig. 7 diagrams exactly this AES-decrypt-to-plaintext conversion. The surrounding text tries to shield the intermediary by saying skey is in the initiator's private data collection and that Amounti is an intermediate value 'not available to the intermediary,' but no trusted execution environment or separate conversion oracle is defined in the system model. The intermediary is itself a member of the source channel (it owns assets on both channels), so if this code executes on any peer the intermediary operates, the plaintext is observable. If the code is intended to run only on initiator-controlled peers behind a convert() interface, then Theorem 1 depends on an unstated trust boundary; as written, the proof does not establish data confidentiality. This invalidation is not merely cosmetic: privacy-preserving cross-sharding is a listed contribution, is evaluated in Section VII-C, and supports the abstract's 'privacy preservation is enhanced using homomorphic encryption' claim. Section IV-C does call privacy 'an optional feature,' but the paper still presents it as a proven guarantee.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":20,"tokens_out":2365,"duration_ms":88522,"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":[{"comment":"","section":"VI-A and Algorithm 1, line 11"},{"comment":"","section":"Section IV-A and Section V-B"},{"comment":"","section":"Section V-A, V-B, and Theorem 2"},{"comment":"","section":"Section VII-B and VII-C"}],"minor_comments":[{"comment":"","section":"Table II"},{"comment":"","section":"Section VII-B"},{"comment":"","section":"Algorithm 2, line 17"},{"comment":"","section":"Section IV-A, Fig. 5 and Fig. 3"},{"comment":"","section":"Section VII-A"}],"recommendation":"major_revision","confidential_remarks":"The paper has a usable core idea and a real evaluation platform, but the confidentiality theorem is contradicted by the protocol pseudocode, and the source-channel deduction mechanism is not specified, leaving the main conflict-avoidance claim incomplete. Both are fixable in a revision, but they are not presentation issues. I also note that references [3]-[5] are self-citations to the authors' own papers; this is not unusual, but the introduction leans on them for the motivation without independent evidence of the 'more than 70% of inter-contract calls occur more than twice' statistic, which is cited to reference [12] in the text and should be verified. The lack of artifact release is a concern for an evaluation-driven paper; I would encourage the editor to make code release a condition of acceptance if the revision is otherwise satisfactory."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The composite-key virtual sub-broker idea is genuinely new for Hyperledger Fabric cross-sharding, and the paper does a good job showing its potential. But the privacy guarantee, as written, doesn't hold, and the initiator-side write contention is never addressed.\n\nThe core mechanism is elegant: instead of routing every CSTx through the intermediary's single ledger key, the chaincode writes each transaction to a unique composite key (intermediary-origin-destination-amount), creating a \"virtual sub-broker.\" That directly reduces MVCC write-write conflicts at the intermediary. Their prototype on Fabric shows large gains in success rate and throughput over a vanilla baseline, and the composite key reuse (CKPoE) seems sensible for reducing key bloat. This is a real, implementable contribution.\n\nThe main soft spot is the privacy proof. Theorem 1 assumes the intermediary operates only on ciphertexts, but Algorithm 1—the incremental accumulation routine—explicitly executes Amounti ← DecryptAES(skey, Vi) before encoding and CKKS-encrypting. The surrounding text says this happens behind a convert() interface in the source channel and that the plaintext is \"not available to the intermediary,\" but no trusted execution environment or separate conversion oracle is defined in the system model. If convert() runs on any peer the intermediary controls, the plaintext amounts are visible. The paper calls privacy an optional feature, but it still presents confidentiality as a theorem. That needs to be fixed or weakened, and the trust boundary made explicit.\n\nThe second gap is initiator-side contention. Every CSTx debits the initiator's account in the source channel. The composite keys split the intermediary's account, but the initiator's balance is still a single key. If the same initiator fires many concurrent CSTxs, those writes collide. The double-spending discussion in Section V-B doesn't address this. The paper should either explain how the deduction is serialized or acknowledge this as a limitation.\n\nThe evaluation is also weaker than the headline suggests. AHL+ and Meepo are simulated, not implemented, and there are no error bars. Code isn't available yet. The 3.5-20.2x numbers should be treated as indicative, not definitive.\n\nOverall, the paper deserves a serious referee. The mechanism is novel, the prototype is real, and the topic matters for permissioned blockchains. A good reviewer will ask for the privacy proof to be reworked or retracted, the initiator-side question to be answered, and the evaluation to be tightened. I'd engage with it if it crossed my desk; after a major revision, it could be a solid contribution.","headline":"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.","tokens_in":22920,"tokens_out":3398,"would_cite":false,"duration_ms":30326,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"HiCoCS claims per-transaction composite keys eliminate MVCC conflicts in Fabric cross-sharding, giving 3.5-20.2x throughput gains.","keywords":["cross-shard transaction","high concurrency","Hyperledger Fabric","MVCC conflict","composite key","virtual sub-broker","homomorphic encryption","CKKS"],"falsifier":"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.","tokens_in":21874,"feed_emoji":"⚡","tokens_out":7914,"duration_ms":73521,"temperature":0.7,"pith_summary":"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.","feed_headline":"Virtual sub-brokers boost cross-shard throughput 3.5-20x","feed_subtitle":"Each cross-shard payment gets its own composite key, so Hyperledger Fabric stops aborting concurrent transfers to one account.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the Hyperledger Fabric execute-order-validate model and MVCC environment that HiCoCS modifies.","marker":"[14]"},{"why":"Defines multi-version concurrency control, the version-checking mechanism that causes cross-shard aborts.","marker":"[27]"},{"why":"Motivates the composite-key data structure used to build virtual sub-brokers.","marker":"[34]"},{"why":"Provides the CKKS fully homomorphic encryption used for ciphertext accumulation of transaction amounts.","marker":"[39]"},{"why":"Introduces the broker/intermediary model for cross-shard transfers that HiCoCS replaces with virtual sub-brokers.","marker":"[6]"},{"why":"Documents the high abort rates of concurrent cross-shard transactions, the problem HiCoCS targets.","marker":"[19]"},{"why":"Serves as the 2PL baseline (AHL+) that HiCoCS compares against.","marker":"[29]"},{"why":"Serves as the OCC baseline (Meepo) that HiCoCS compares against.","marker":"[33]"}],"fun_headline_variants":["Cross-shard conflicts solved with virtual sub-brokers","HiCoCS speeds up cross-shard txns 3.5-20x","Virtual sub-brokers kill write conflicts in cross-shard","Permissioned blockchains get 20x cross-shard boost","Composite keys make cross-shard concurrent and private"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Cross-shard conflicts solved with virtual sub-brokers","HiCoCS speeds up cross-shard txns 3.5-20x","Virtual sub-brokers kill write conflicts in cross-shard","Permissioned blockchains get 20x cross-shard boost","Composite keys make cross-shard concurrent and private"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00024,"raw_usage":{"total_tokens":1537,"prompt_tokens":981,"completion_tokens":556,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":597,"completion_tokens_details":{"reasoning_tokens":469}},"tokens_in":597,"tokens_out":556,"duration_ms":4908,"temperature":1.0,"reasoning_tokens":469,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:37:11.813067+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Gordian: Efficient and scalable discovery of composite keys,","cited_arxiv_id":null,"evidence_quote":"Motivates the composite-key data structure used to build virtual sub-brokers."},{"cited_title":"Hyperledger fabric: a distributed operating system for permissioned blockchains,","cited_arxiv_id":null,"evidence_quote":"Supplies the Hyperledger Fabric execute-order-validate model and MVCC environment that HiCoCS modifies."},{"cited_title":"Multi-version concurrency control scheme for a database system,","cited_arxiv_id":null,"evidence_quote":"Defines multi-version concurrency control, the version-checking mechanism that causes cross-shard aborts."},{"cited_title":"Homomorphic encryption for arithmetic of approximate numbers,","cited_arxiv_id":null,"evidence_quote":"Provides the CKKS fully homomorphic encryption used for ciphertext accumulation of transaction amounts."},{"cited_title":"Brokerchain: A cross-shard blockchain protocol for account/balance- based state sharding,","cited_arxiv_id":null,"evidence_quote":"Introduces the broker/intermediary model for cross-shard transfers that HiCoCS replaces with virtual sub-brokers."},{"cited_title":"Prophet: Conflict-free sharding blockchain via byzantine- tolerant deterministic ordering,","cited_arxiv_id":null,"evidence_quote":"Documents the high abort rates of concurrent cross-shard transactions, the problem HiCoCS targets."},{"cited_title":"Towards scaling blockchain systems via sharding,","cited_arxiv_id":null,"evidence_quote":"Serves as the 2PL baseline (AHL+) that HiCoCS compares against."},{"cited_title":"Meepo: Multiple execution environments per organization in sharded consortium blockchain,","cited_arxiv_id":null,"evidence_quote":"Serves as the OCC baseline (Meepo) that HiCoCS compares against."}],"review_version":1}