BCFLStrategy: Device Selection for Blockchain-Enabled FL

[v1nayh3g]

Hey everyone,

I recently published a paper in IEEE TCAS-II (DOI: 10.1109/TCSII.2023.3322340) on optimizing device selection in Blockchain-Enabled Federated Learning (BCFL) to minimize the massive latency and energy hits from miner verification overhead.

I built the solver into a custom Flower Strategy (BCFLStrategy) that wraps FedAvg. It dynamically selects the mathematically optimal subset of devices per round based on their computation/uplink constraints vs the blockchain consensus penalty ($A_{fork}$).

It's currently published as a standalone PyPI package (bcfl-optimizer): https://github.com/v1nayh3g/bcfl-optimizer

Since BCFL is getting pretty popular, would this be useful to have natively in Flower (maybe in a contrib/experimental folder)? If there's interest, I'd be happy to clean it up and submit a PR!

[WilliamLindskog]

Hi @v1nayh3g,

This would be very interesting! Feel free to open a PR that follows the new flwr Message API format, and we'll review it.

Thanks for opening this thread!

Best regards,
William

[JiwaniZakir]

This is a feature proposal rather than a bug, so the relevant entry point would be Flower's strategy interface in flwr/server/strategy/ — specifically how FedAvg exposes configure_fit and aggregate_fit hooks that a wrapping strategy like BCFLStrategy would override for custom client selection logic. The main integration concern worth flagging is that Flower's built-in client_manager.sample() uses a simple random sampling model, so the blockchain-aware subset selection would need to either subclass SimpleClientManager or bypass it entirely in configure_fit, which can have implications for compatibility with Flower's virtual client engine. The flwr/server/strategy/fedavg.py num_fit_clients method is likely where the device count logic would need to be intercepted or replaced.