Source-linked AI summary
Blockchained On-Device Federated Learning
Hyesung Kim, Jihong Park, Mehdi Bennis, Seong-Lyun Kim
TL;DR
The paper addresses how devices can train on-device models when local samples are insufficient while keeping raw data private and avoiding dependence on a central server. It proposes BlockFL, in which blockchain miners exchange and verify local model updates, generate blocks with PoW, and distribute the ledger for local global-model computation. It also formulates the end-to-end latency and derives a block generation rate that minimizes epoch latency while accounting for communication, computation, and PoW delays.
Problem
Each device lacks enough local samples for on-device model training, while vanilla FL relies on a failure-prone central server and does not reward local contributions.
Method
BlockFL uses blockchain miners to exchange and verify local model updates, record them in PoW-generated blocks, distribute the ledger, and let devices compute global updates locally.
Results
The paper formulates BlockFL’s end-to-end latency from communication, computation, and PoW delays and derives a latency-optimal block generation rate.
Takeaways & Limitations
Blockchain-based validation and rewards support federated training across devices without a central server while accounting for the added blockchain delay.
Abstract
from arXiv · showhide
By leveraging blockchain, this letter proposes a blockchained federated learning (BlockFL) architecture where local learning model updates are exchanged and verified. This enables on-device machine learning without any centralized training data or coordination by utilizing a consensus mechanism in blockchain. Moreover, we analyze an end-to-end latency model of BlockFL and characterize the optimal block generation rate by considering communication, computation, and consensus delays.
I. INTRODUCTION
BlockFL replaces vanilla FL’s central-server coordination with blockchain-based exchange, verification, and rewards for local model updates. It also models the resulting communication, computation, and PoW delays to optimize block generation.
- Motivation: On-device models need federated local updates because each device’s samples are insufficient for training alone.The approach preserves raw-data privacy by exchanging model weights and gradient parameters rather than raw samples.
- Motivation: Vanilla FL depends on a single central server, whose malfunction can distort global updates, and provides no reward for device contributions.Devices with more samples contribute more to global training, while uncompensated devices with few samples may be less willing to participate.
- BlockFL architecture: Rewards proportional to training sample sizes address participation incentives while blockchain validation supports federation with untrustworthy devices and avoids a single point of failure.The proposed reward mechanism is tied to devices’ training sample sizes.
- BlockFL architecture: BlockFL uses blockchain miners to exchange and verify local model updates, run PoW, record verified updates in blocks, and distribute them through a ledger.Each device computes the global model update from the newly downloaded block; miners may be devices or separate network-edge nodes.
- Latency analysis: BlockFL’s latency model includes communication, computation, and PoW delays, with latency minimized by adjusting the block generation rate through PoW difficulty.The analysis derives a latency-optimal block generation rate for the epoch latency averaged over the PoW process.
II. ARCHITECTURE AND OPERATION
BlockFL replaces the centralized FL server with a blockchain network that exchanges, verifies, and rewards local model updates. Its one-epoch operation combines local training, miner verification, block generation, propagation, and fork handling.
- Architecture: Each device trains a local model on its own data, uploads its model update to an associated miner, and participates in distributed regression training.The formulation uses mean squared error and local stochastic variance reduced gradient updates.
- Architecture: The blockchain replaces the central server, with miners recording verified local updates in block bodies and using headers containing prior-block pointers, λ, and PoW outputs.Candidate blocks are filled until reaching h + δmND or the waiting time Twait.
- Incentives and verification: Data rewards scale with device sample size, while mining rewards scale with the aggregate sample size of devices associated with a miner.Miners verify updates by comparing claimed sample sizes with corresponding local computation times; protected execution is cited as a practical guarantee.
- One-epoch operation: Miners cross-verify updates, run PoW, propagate the winning block, and require devices to use the resulting global update in the next epoch.A second block found during propagation creates a fork, causing some devices to apply an incorrect next local model update.
- One-epoch operation: BlockFL computes global model updates locally at devices, so a miner or device malfunction does not affect other devices’ global updates.This avoids the centralized server’s failure mode and prevents excessive computational overheads at miners.
III. END-TO-END LATENCY ANALYSIS
BlockFL learning latency is modeled from computation, communication, and block-generation effects across each epoch. The analysis derives an optimal block generation rate under a synchronous PoW approximation and explains the trade-off between forking and block-generation delays.
- One-epoch BlockFL latency model: Learning completion latency comprises computation, communication, and block generation delays.Computation includes local and global model updating; communication includes model uploads, downloads, and block propagation.
- One-epoch BlockFL latency model: Local and global model updating delays are determined by processed data or model sizes and device clock speed.The local updating delay is δdN_o/f_c, while the global updating delay is δ_mN_D/f_c.
- One-epoch BlockFL latency model: Communication latency includes local model uploading, global model downloading, and block propagation over allocated bandwidth and channel SNR.The model-upload and download expressions use bandwidth allocations and log2(1 + SNR) achievable rates; block propagation also depends on block and data sizes.
- Latency optimal block generation rate: The analysis derives λ∗ to minimize the epoch latency averaged over the PoW process.The derivation accounts for block-generation delay, forking occurrences, and the synchronous-start approximation for miners.
- Latency optimal block generation rate: Under the synchronous PoW approximation, the optimal rate follows from a convex latency expression in λ.The approximation adjusts Twait so miners synchronously start PoW, while earlier cross-verification completions wait until Twait.
- Latency optimal block generation rate: Higher λ increases forking frequency, whereas lower λ increases block-generation overhead and can also produce excessive latency.Thus, the latency-minimizing rate balances these opposing effects.
IV. NUMERICAL RESULTS AND DISCUSSION
Numerical results characterize how BlockFL latency changes with block generation, device and miner counts, energy constraints, and miner malfunction. They show tunable trade-offs between latency, robustness, and blockchain participation.
- Evaluation setup: BlockFL’s average learning completion latency is evaluated numerically against block generation rate, device count, miner count, energy constraints, and malfunction conditions.The evaluation covers the latency model and scalability behavior under varying system parameters.
- Block generation rate: Up to 1.5% separates the Proposition 1 latency minimum from the simulated minimum at the optimal block generation rate λ∗.The analytical minimum is consistently slightly longer than the simulated minimum.
- Miner scalability: A larger NM increases latency without malfunction through added cross-verification and block propagation delays, but can shorten latency under malfunction.With malfunction, devices associated with normally operating miners can restore distorted global model updates.
- Device scalability: A latency-optimal number ND of devices exists because more devices increase usable data while also enlarging blocks and exchange delays.These opposing effects produce a convex-shaped latency curve.
- Energy constraints: Under miner malfunction, a lower energy threshold θe yields shorter latency because more miners participate and produce more robust global model updates.Without malfunction, the lower threshold instead increases latency through additional cross-verification and block propagation delays.
- Blockchain security: The malicious-miner overtake probability approaches zero after only a few honest-mined blocks, while more miners further prevent takeover.The result is reported for a malicious miner attempting to create a longer competing blockchain.