{"id":"b47e8fbd-415f-4d75-9792-af0062926298","arxiv_id":"2507.07637","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"HLF-FSL, a Hyperledger Fabric orchestration layer for federated split learning, matches centralized FSL accuracy on CIFAR-10 and MNIST while reducing per-epoch time versus Ethereum-based implementations.","lead":"This paper describes a system that runs Federated Split Learning on the Hyperledger Fabric blockchain, removing the central server that normally coordinates training. The authors report that the system matches standard FSL accuracy on CIFAR-10 and MNIST while being faster than Ethereum-based alternatives, and they argue it is ready for enterprise use.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The described use of Fabric transient fields for activations/gradients is not implementable: transient data is not retrievable by TxID after commit, so the protocol's core data exchange must rely on unstated off-chain storage.","rationale":"The reader's weakest_assumption (byte-identical FedAvg hashes for the client-executed aggregation) is a real correctness risk, but it arises only at the periodic aggregation step. My concern is strictly more fundamental: the mechanism the paper relies on for exchanging intermediate activations and gradients in every split-learning iteration, HLF transient fields, cannot be retrieved post-commit by TxID in Hyperledger Fabric. If the implemented system actually works, it must be using a different, unstated data channel (most likely IPFS/OCS), which would invalidate the paper's description of its own privacy architecture and would require re-evaluating the measured epoch time and the claim of 'minimal blockchain overhead' from an OCS-based data plane. This keeps the paper in CONDITIONAL territory: the core accuracy/latency numbers may survive, but the protocol description and privacy contribution need major correction. I therefore do not change the reader's verdict level, but I add a distinct and more basic correctness condition that should be verified before acceptance.","tokens_in":20758,"tokens_out":7763,"duration_ms":91336,"concrete_test":"Inspect the open-source prototype's data path: determine whether zi and ∇zi Li are ever read from a Fabric transient map keyed by TxID, or whether they are always written to and read from IPFS/OCS. Then run a minimal Fabric v2.5 experiment: invoke a chaincode with a transient payload, commit the transaction, and from a separate client attempt to retrieve the transient payload using the transaction ID after commit. If retrieval fails (as Fabric semantics dictate), Algorithm 1 lines 5–20 cannot work as written. Additionally, grep the prototype for 'getTransient' and check whether the server's and clients' retrieval of intermediate data actually goes through IPFS hashes.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The architecture's data plane depends on Hyperledger Fabric transient fields to exchange intermediate activations zi and gradients ∇zi Li between clients and the Server Entity. Algorithm 1 (lines 5–20) and Section IV-B state that the Server Entity 'fetches actual zi from Transient map (using TxID from event)' and that clients 'fetch actual ∇zi Li from Transient map (via TxID)'. In Fabric v2.5, transient data is passed only in the transaction proposal, is visible to endorsing peers during chaincode execution, and is deliberately excluded from the transaction payload and ledger. After the transaction commits, there is no ledger or chaincode API to retrieve transient data by transaction ID; the data is discarded by the peers. Consequently, a client cannot send zi to the Server Entity via a transient field and have the server retrieve it later, and the server cannot make ∇zi Li available to a client through the same mechanism. Unless the prototype actually stores every zi and ∇zi Li in IPFS/OCS (or pushes it through a side channel), the described protocol cannot execute a single training round. If the implementation does use OCS, then the paper's stated 'transient fields' privacy contribution is not what was evaluated, and the claimed privacy/overhead results must be reinterpreted. This is more fundamental than the aggregation hash-consensus issue raised by the reader, because it affects every round of training, not just the periodic FedAvg step.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes HLF-FSL, a decentralized Federated Split Learning (FSL) architecture built on Hyperledger Fabric, removing the central coordinator by using chaincode for orchestration, transient fields and Private Data Collections (PDCs) for privacy, and client-executed FedAvg for aggregation. The authors report CIFAR-10 accuracy of 94.14% versus 94.7% for centralized FSL, MNIST accuracy of 99.43%, an average CIFAR-10 epoch time of 30m38s versus 1h25m for their prior Ethereum-based SL system, and scalability experiments for up to 25 clients. The paper claims these results demonstrate enterprise-grade viability for collaborative learning in sensitive domains.","tokens_in":20957,"tokens_out":4292,"duration_ms":50038,"significance":"If the architecture operated as described, the paper would make a useful contribution: it provides a permissioned-blockchain alternative to centralized FSL, ships an open-source prototype, and reports measured accuracy and latency rather than fitted predictions. The comparison to centralized FSL and to an Ethereum baseline is appropriate. However, the core data-exchange mechanism and the client-aggregation consensus rule are not implementable as written, and the experimental tables lack the error bars promised by the text. These issues affect the central claims of privacy, decentralization, and scalability, so the significance can only be assessed after a substantive revision.","major_comments":[{"comment":"The described use of transient fields for activations and gradients is not implementable in Hyperledger Fabric v2.5. Transient data exists only in the transaction proposal during chaincode execution; after commit, peers discard it and no API retrieves it by TxID. Therefore Algorithm 1 line 10 ('fetches actual zi from Transient map (using TxID from event)') and line 20, as well as the corresponding text in Section IV-B, describe an operation that cannot execute a single training round. If the prototype actually stores activations and gradients in off-chain storage (OCS/IPFS), the paper must state this explicitly, because the claimed privacy contribution based on transient fields would not be what was evaluated, and the overhead results in Table VI would need to be reinterpreted.","section":"IV-B, IV-C, Algorithm 1 (lines 5-20)"},{"comment":"The client-executed aggregation consensus rule assumes that every client computing FedAvg over the same retrieved parameter list obtains a byte-identical parameter vector, so that a two-thirds majority of equal hashes is meaningful. This requires identical numerical libraries, data types, serialization order, and summation order across all client organizations. The manuscript does not state or test this assumption, and the only fallback when hashes diverge is to revert to the previous global model, which could stall training indefinitely. The paper should either specify a canonical arithmetic/serialization protocol and experimentally verify hash agreement across heterogeneous clients, or replace hash-based consensus with an error-tolerant verification mechanism.","section":"IV-C (endGlobalModel) and Algorithm 1 (lines 27-33)"},{"comment":"Section V states that experiments 'were repeated to report mean and standard deviation, ensuring statistical rigor,' but no standard deviations, confidence intervals, or number of runs are reported in Tables III, IV, V, or VI. The central accuracy-parity claim (94.14% vs. 94.7%) relies on a 0.56% difference that may be within run-to-run noise for N=10 clients, so the claim is not currently assessable. The authors should report means with standard deviations and the number of repeated runs for all reported metrics.","section":"VI-A, Table III"},{"comment":"The server fs batch processing times in Table V are non-monotonic: N=10 yields 3.25s, N=15 yields 1.85s, N=20 yields 13.48s, and N=25 yields 26.32s. This non-monotonicity is inconsistent with the scalability conclusion that the system operates efficiently with an elevated number of simultaneous clients, and no explanation or error bars are provided. The authors should clarify whether this reflects uncontrolled batching order, resource contention, or measurement artifacts, and should provide variance information before drawing scalability conclusions.","section":"VI-C, Table V"}],"minor_comments":[{"comment":"The text reports 'PyTorch (v3.9)', but PyTorch does not have a version 3.9; the authors should specify the PyTorch version and the Python version separately.","section":"V"},{"comment":"There are typos: 'mmonetary payment, knownn as gas fee' and 'prohibitevely expensive' should be corrected.","section":"II-B"},{"comment":"The citation [29] is mismatched: the text refers to 'Lu et al., 2022' survey of blockchain FL schemes, but reference [29] is a different paper on smart contracts; the intended survey should be identified and cited correctly.","section":"III-B"},{"comment":"The text states Dirichlet concentration parameters alpha in {0.1, 0.5, 0.9}, while the Figure 7 caption mentions {0.1, 0.3, 0.5, 0.9}; these should be reconciled.","section":"VI-B, Figure 7"},{"comment":"The description says triggerClientAggregation is 'invoked periodically or by a designated coordinator role', which reintroduces a central coordinator and contradicts the paper's claim of no central coordinator; the caller of this function should be specified in a way consistent with the decentralization claim.","section":"IV-C (triggerClientAggregation)"},{"comment":"The reported average zi size of approximately 48-49 MB per transaction is difficult to reconcile with the claim that activations are passed via transient fields; if such data were placed in a transaction proposal, it would create enormous network and memory overhead, while if it is stored off-chain, the table should report the off-chain transfer cost rather than per-transaction size.","section":"Table VI"}],"recommendation":"major_revision","confidential_remarks":"The transient-field retrieval issue is the most serious problem: it affects every training round and, as written, makes the protocol unexecutable. If the available GitLab prototype actually uses off-chain storage for activations and gradients, the paper can be repaired by describing that design and revising the privacy and overhead claims accordingly. I would ask the authors to clarify the implementation path in their revision response and to reconcile the reported experiments with the described protocol."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: the combination of FSL with Hyperledger Fabric is a real contribution, and the measured accuracy parity is credible, but the paper misdescribes the core data-exchange mechanism. Fabric transient fields are visible only to endorsing peers during chaincode execution. They are not stored on the ledger and there is no API to retrieve them by transaction ID after commit. So Algorithm 1's 'fetch zi from Transient map (using TxID from event)' (lines 10 and 20) and the Section IV-C chaincode description cannot execute as written. The authors do mention an OCS fallback ('or OCS (using hash)'), and the code is public, so the prototype probably actually moves activations and gradients through IPFS/client storage with only hashes on-chain. If so, the 'transient fields' privacy claim in Section IV-D is not what was evaluated, and the measured latencies reflect OCS transfers. This is load-bearing, not cosmetic.\n\nCredit where due: the architecture is a sensible repurposing of known components — Fabric chaincode orchestrating the FSL lifecycle, PDCs for hash references, and a client-executed FedAvg with endorsement-policy consensus — and the comparison to the authors' own Ethereum-based SL is honest and concrete (30m38s vs 1h25m per epoch). Shipping the prototype is exactly the right thing to do.\n\nOther soft spots, descending: (1) The paper claims repeated runs but reports no error bars anywhere; Tables III and IV give single numbers. (2) Table V is non-monotonic: server batch time is 3.25s at N=10, drops to 1.85s at N=15, then jumps to 13.48s at N=20 and 26.32s at N=25. That pattern needs an explanation before the scalability argument holds. (3) 'Minimal blockchain overhead' in the abstract sits awkwardly next to the 5x per-epoch slowdown vs in-memory FSL; the text later acknowledges this, but the framing overclaims. (4) The endGlobalModel consensus rule assumes byte-identical FedAvg across clients with different numerical libraries and summation order; the paper doesn't state or test this, and the only fallback (revert to previous global model) could stall training.\n\nWho this is for: researchers working on blockchain-coordinated collaborative learning will get a useful (if cautionary) case study. It deserves serious peer review: a referee should check the public code against the description, ask for error bars and an explanation of Table V, and require the authors to either implement the transient-field claim correctly or drop it and re-evaluate with OCS as the stated data plane.","headline":"A plausible HLF-coordinated FSL system with a real prototype, but the data plane as described cannot work because Fabric transient fields are not retrievable by TxID — the paper must be revised to say how activations and gradients are actually exchanged.","tokens_in":21607,"tokens_out":5090,"would_cite":false,"duration_ms":54398,"reading_group":"maybe","serious_thinker":"no","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A permissioned blockchain can coordinate federated split learning without a central server, matching centralized accuracy.","keywords":["federated split learning","Hyperledger Fabric","permissioned blockchain","chaincode orchestration","private data collections","decentralized aggregation","privacy-preserving machine learning","IoT"],"falsifier":"Instrument the endGlobalModel chaincode to record, across all aggregation rounds, how often fewer than two-thirds of submitted global-model hashes match; any such round reverts to the previous model, and a realistic run where clients use different numerical libraries or summation orders would show whether the consensus rule actually holds.","tokens_in":20479,"feed_emoji":"🔗","tokens_out":4705,"duration_ms":46032,"temperature":0.7,"pith_summary":"This paper tries to show that federated split learning (FSL), which normally depends on a central server to host part of the model and aggregate updates, can run instead on a permissioned blockchain called Hyperledger Fabric. The proposed system, HLF-FSL, uses Fabric's smart contracts (chaincode) to orchestrate the training rounds, with raw data and intermediate activations exchanged through transient fields and private data collections so they never persist on the ledger. On CIFAR-10 the authors report 94.14% test accuracy versus 94.7% for a centralized FSL baseline, and an average epoch time of 30m38s versus 1h25m for an Ethereum-based split-learning system. The point of the claim is that enterprise users in regulated domains could get the privacy and auditability of a blockchain without sacrificing learning quality or paying public-blockchain latency and gas costs.","feed_headline":"Hyperledger Fabric runs split learning with no central server","feed_subtitle":"CIFAR-10 hits 94.14 percent accuracy and per-epoch time drops versus Ethereum-based systems.","key_machinery":"The load-bearing mechanism is the chaincode-driven, client-executed aggregation protocol, culminating in the endGlobalModel consensus rule: each client independently computes FedAvg over the same retrieved parameter set and submits a hash, and the chaincode accepts a new global model only if more than two-thirds of submitted hashes match. This replaces a trusted aggregator with a hash-consensus check. Privacy is carried by Hyperledger Fabric's transient fields for ephemeral activations and gradients and by Private Data Collections for access-controlled hashes of intermediate data, client updates, and the global model, with large parameters stored off-chain and only references on the ledger.","core_discovery":"The central claim is that a permissioned blockchain can replace the central coordinator in federated split learning without hurting accuracy and with better per-epoch time than public-blockchain approaches. In HLF-FSL, clients run the client-side submodel $f_c$ and the server entity runs $f_s$, while Hyperledger Fabric's chaincode manages model registration, activation and gradient hash exchange, and aggregation triggers. Clients compute the FedAvg global model off-chain, submit hashes of their results, and chaincode commits a new global model only when more than two-thirds of submissions match. The paper reports 94.14% final test accuracy on CIFAR-10 (centralized FSL: 94.7%; Ethereum-based SL: 90.25%), 99.43% on MNIST, graceful degradation under non-IID Dirichlet partitions, and stable SDK latencies as clients scale from 1 to 25.","pith_inferences":["The hash-consensus rule generalizes to any off-chain computation that is deterministic across participants, so the same pattern could verify other multi-party computations, not just FedAvg.","A testable extension is measuring how often client-computed FedAvg hashes actually diverge across organizations using different numerical libraries or summation orders; the paper does not report this.","The privacy claim is about hiding intermediate artifacts from the ledger, not mathematical confidentiality; coupling with differential privacy or homomorphic encryption, named as future work, would be needed for stronger guarantees.","Validation on image classification could extend to NLP or object detection, since the orchestration logic is not vision-specific."],"forward_implications":["Centralized FSL accuracy can be preserved when coordination moves to a permissioned blockchain: 94.14% versus 94.7% on CIFAR-10.","Per-epoch training time drops relative to Ethereum-based split learning on the same task: 30m38s versus 1h25m.","The architecture degrades gracefully under non-IID data, with Dirichlet partitions tracking the IID convergence curve.","Off-chain storage of parameters and on-chain hash references keep ledger growth small, on the order of 145 KB of references per epoch in the N=10 run.","MNIST results (99.43% accuracy, 7m20s per epoch) suggest the mechanism transfers to simpler models and datasets."],"supporting_citations":[{"why":"Defines the FedAvg-based FSL training loop that HLF-FSL replaces the central coordinator for.","marker":"[9]"},{"why":"Provides the permissioned blockchain, MSP, chaincode, and Private Data Collection features the architecture builds on.","marker":"[10]"},{"why":"Prior Ethereum-based split-learning system used as the main baseline for accuracy and epoch-time comparison.","marker":"[11]"},{"why":"Block-FeST is compared as a prior FSL-plus-Ethereum framework with centralized elements.","marker":"[12]"},{"why":"Documents Hyperledger Fabric's Private Data Collections, the mechanism used for access-controlled hash storage.","marker":"[18]"},{"why":"Shows activations and gradients can leak information in split learning, motivating the privacy design.","marker":"[22]"},{"why":"Demonstrates reconstruction attacks on split learning intermediate data, supporting the need for off-ledger handling.","marker":"[23]"},{"why":"Supplies the CIFAR-10 benchmark dataset used for the main accuracy and timing experiments.","marker":"[35]"}],"fun_headline_variants":["Blockchain replaces central server in split learning","Hyperledger Fabric orchestrates federated split learning","Decentralized federated split learning on Hyperledger","No central server: blockchain-based split learning","HLF-FSL: decentralized split learning for IoT"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The aggregation rule assumes every client computes a byte-identical FedAvg result from the same parameters, so that matching hashes are a dependable consensus signal; if numerical libraries or summation orders differ, hashes may diverge and training can stall.","fun_headline_variants_meta":{"raw":{"variants":["Blockchain replaces central server in split learning","Hyperledger Fabric orchestrates federated split learning","Decentralized federated split learning on Hyperledger","No central server: blockchain-based split learning","HLF-FSL: decentralized split learning for IoT"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000175,"raw_usage":{"total_tokens":1256,"prompt_tokens":887,"completion_tokens":369,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":503,"completion_tokens_details":{"reasoning_tokens":296}},"tokens_in":503,"tokens_out":369,"duration_ms":4019,"temperature":1.0,"reasoning_tokens":296,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-06T18:35:58.098250+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Instrument the endGlobalModel chaincode to record, across all aggregation rounds, how often fewer than two-thirds of submitted global-model hashes match; any such round reverts to the previous model, and a realistic run where clients use different numerical libraries or summation orders would show whether the consensus rule actually holds.","supporting_citations":[{"cited_title":"Splitfed: When federated learning meets split learning,","cited_arxiv_id":null,"evidence_quote":"Defines the FedAvg-based FSL training loop that HLF-FSL replaces the central coordinator for."},{"cited_title":"Hyperledger fabric: a distributed operating system for permissioned blockchains,","cited_arxiv_id":null,"evidence_quote":"Provides the permissioned blockchain, MSP, chaincode, and Private Data Collection features the architecture builds on."},{"cited_title":"Blockchain support for verifiable split learning,","cited_arxiv_id":null,"evidence_quote":"Prior Ethereum-based split-learning system used as the main baseline for accuracy and epoch-time comparison."},{"cited_title":"Block-fest: A blockchain-based federated anomaly detection framework with computation offloading using transformers,","cited_arxiv_id":null,"evidence_quote":"Block-FeST is compared as a prior FSL-plus-Ethereum framework with centralized elements."},{"cited_title":"Private Data Collections,","cited_arxiv_id":null,"evidence_quote":"Documents Hyperledger Fabric's Private Data Collections, the mechanism used for access-controlled hash storage."},{"cited_title":"Eluding secure aggregation in federated learning via model inconsistency,","cited_arxiv_id":null,"evidence_quote":"Shows activations and gradients can leak information in split learning, motivating the privacy design."},{"cited_title":"Can we use split learning on 1d cnn models for privacy preserving training?","cited_arxiv_id":null,"evidence_quote":"Demonstrates reconstruction attacks on split learning intermediate data, supporting the need for off-ledger handling."},{"cited_title":"Cifar-10 (canadian institute for advanced research),","cited_arxiv_id":null,"evidence_quote":"Supplies the CIFAR-10 benchmark dataset used for the main accuracy and timing experiments."}],"review_version":1}