[Paper] SI-ChainFL: Shapley-Incentivized Secure Federated Learning for High-Speed Rail Data Sharing

Source: arXiv - 2603.07992v1

Overview

The paper introduces SI‑ChainFL, a federated‑learning (FL) framework designed for high‑speed rail (HSR) operators who need to share traffic‑flow insights without exposing raw sensor data. By marrying Shapley‑value‑based contribution incentives with a blockchain‑driven decentralized aggregation, the authors tackle two chronic FL pain points: (1) free‑riding and model‑poisoning attacks, and (2) the single‑point‑of‑failure risk of a central aggregator.

Key Contributions

• Contribution‑aware incentive model: Uses a multi‑dimensional Shapley value (rare‑event utility, data diversity, quality, and timeliness) to fairly reward participants.
• Rare‑positive driven client clustering: A lightweight pre‑clustering step that dramatically cuts the combinatorial cost of Shapley estimation while preserving accuracy.
• Blockchain‑based consensus for aggregation: Decentralized global model merging where only clients with sufficient Shapley scores can propose/validate blocks, eliminating a central server.
• Robustness against poisoning: Demonstrates resilience to up to 90 % malicious clients in targeted model‑poisoning (PA) attacks.
• Real‑world validation: Experiments on standard vision benchmarks (MNIST, CIFAR‑10/100) and a proprietary HSR flow dataset, showing a 14.12 % accuracy gain over the state‑of‑the‑art RAGA scheme.
• Theoretical guarantee: Provides an upper bound on the performance loss introduced by the decentralized aggregation and Shapley approximation.

Methodology

1. Quantifying Contributions

   • Each client’s update is evaluated through a Shapley value that aggregates four factors:
     1. Rare‑event utility – how much the update improves prediction on low‑frequency (but safety‑critical) rail events.
     2. Data diversity – the uniqueness of the client’s feature distribution compared to the federation.
     3. Data quality – signal‑to‑noise ratio and labeling correctness.
     4. Timeliness – latency between data capture and model submission.
   • The exact Shapley computation is NP‑hard, so the authors first cluster clients based on “rare‑positive” signals (i.e., updates that improve rare‑event metrics). Within each cluster, a Monte‑Carlo sampling approximates the Shapley contribution, cutting runtime by ~70 % in practice.

2. Incentive‑linked Blockchain Aggregation

   • A permissioned blockchain (e.g., Hyperledger Fabric) hosts the FL process.
   • Eligibility rule: Only clients whose Shapley score exceeds a dynamic threshold can propose a new block containing their local model update.
   • Consensus: A lightweight Byzantine Fault Tolerant (BFT) protocol (PBFT‑style) validates the block, ensuring that at least a quorum of honest, high‑contributing nodes agree on the aggregated model.
   • The global model is computed by a weighted averaging where weights are proportional to the verified Shapley scores, guaranteeing that higher‑quality contributions dominate the final model.

3. Security & Attack Model

   • The framework assumes partial adversarial control (up to 90 % of participants) that may launch model‑poisoning (PA) attacks or attempt free‑riding.
   • By tying block‑creation rights to Shapley incentives, malicious nodes that submit low‑quality or harmful updates are automatically excluded from the consensus process.

Results & Findings

• Computation overhead: The clustering‑accelerated Shapley estimation adds ~0.15 s per round on a typical edge device (ARM Cortex‑A53), negligible compared to local training time.
• Network overhead: Blockchain block size stays under 200 KB (model diff + metadata), fitting comfortably within 5G/rail‑specific private LTE links.
• Security: The BFT consensus tolerates up to f = ⌊(n‑1)/3⌋ Byzantine nodes; with n = 20 participants, the system remains safe even when 6 are malicious, and the incentive filter pushes the effective f lower.

Practical Implications

• For rail operators: Enables cross‑company or cross‑departmental traffic‑flow forecasting without exposing proprietary sensor logs, improving schedule optimization and safety alerts.
• For developers building FL pipelines: Demonstrates a concrete recipe for fair incentive mechanisms (Shapley‑based) that can be plugged into existing FL libraries (e.g., TensorFlow Federated, PySyft).
• Edge‑device deployment: The lightweight clustering step and modest blockchain payload make the approach viable on constrained on‑board computers (e.g., Raspberry Pi‑class controllers).
• Security‑by‑design: By making block‑creation a privilege earned through contribution, the system naturally discourages free‑riding and reduces the attack surface for model‑poisoning—useful for any federated scenario where participants may be semi‑trusted (smart‑city IoT, collaborative automotive fleets).
• Regulatory compliance: Decentralized aggregation sidesteps the need for a single data custodian, aligning with emerging data‑sovereignty regulations in transportation sectors.

Limitations & Future Work

• Shapley approximation bias: Although clustering speeds up computation, the Monte‑Carlo estimate can still deviate from the exact Shapley value, especially when client data distributions are highly skewed.
• Permissioned blockchain assumption: The current design relies on a known set of participants; extending to fully open, permission‑less settings would require additional Sybil‑resistance mechanisms.
• Scalability to hundreds of clients: Experiments capped at 20 participants; larger federations may need hierarchical clustering or sharding of the blockchain.
• Dynamic incentive thresholds: The paper uses a static threshold for block eligibility; adaptive thresholds based on system load or attack intensity could further improve robustness.

Future research directions include integrating differential privacy with the Shapley incentive to protect individual data contributions, exploring cross‑chain interoperability for multi‑operator rail networks, and evaluating the framework on real‑time streaming data (e.g., live sensor feeds) to assess latency guarantees.

Authors

• Mingjie Zhao
• Cheng Dai
• Fei Chen
• Xin Chen
• Kaoru Ota
• Mianxiong Dong
• Bing Guo

Paper Information

• arXiv ID: 2603.07992v1
• Categories: cs.DC
• Published: March 9, 2026
• PDF: Download PDF