The document presents a literature survey on combatting model poisoning attacks in blockchain-enabled federated learning for healthcare, highlighting various methodologies that enhance security and privacy. Key approaches discussed include the MinVar algorithm for model updates, decentralized frameworks using blockchain, and utilizing secure multi-party computation for encrypted model verification. However, challenges like high computational complexity, increased storage demands, and limitations in existing defense mechanisms are noted.

1. Combating Poisoning Attacks in
Blockchain - Enabled Federated Learning
in Healthcare
under the Guidance of
Mr K. Govindasamy
Department of Information Technology, MIT
Presented by
Krupa Janani G (2021506040)
Gowri R (2021506025)
Hemnath N M (2021506026)
Sasikala S (2021506324)
IT5712 PROJECT I

2. Literature Survey
S. No. Title Methodology Advantage Limitations
1
Blockchain for Federated
Learning Toward Secure
Distributed Machine
Learning Systems: A
Systemic Survey​
Presents an in-depth survey of Blockchain-based
Federated Learning (BCFL), covering its
architecture, structural design, and platform
deployment.
BCFL enhances privacy and
security in federated learning
by leveraging blockchain's
decentralized, transparent, and
tamper-proof characteristics.
The combination of blockchain
and federated learning
increases communication costs
and poses scalability
challenges in real-world
applications.
2
Defending Against Model
Poisoning Attacks in
Federated Learning: A
Variance-Minimization
Approach​
Proposes the MinVar algorithm, which assigns
different weights to local updates in federated
learning to defend against model poisoning attacks.
MinVar is effective in
minimizing the impact of
malicious updates, particularly
in non-I.I.D. data scenarios.
The computational complexity
of MinVar can be high, though
a data-sampling technique
helps reduce it.
3
When Machine Learning
Meets Blockchain: A
Decentralized, Privacy-
preserving, and Secure
Design​
(
Integrates decentralized machine learning with
blockchain, using a differential privacy scheme and
Byzantine attack-resilient mechanisms.
Provides strong privacy
preservation and security
against malicious participants
without the need for a central
server.
The computational overhead,
particularly due to
cryptographic methods and
consensus mechanisms, can
reduce system efficiency.
4
Blockchain-based Federated
Learning Framework with
Committee Consensus
Proposes a decentralized federated learning
framework using blockchain and committee
consensus mechanism
Reduces malicious attacks and
improves the stability of the
global model
High storage and
computational burden on
blockchain nodes​
(rf7)
5
Blockchain-Based Federated
Learning With SMPC Model
Verification Against
Poisoning Attack for
Healthcare Systems
Utilizes Secure Multi-Party Computation (SMPC)
for encrypted model verification and blockchain for
secure aggregation in healthcare systems.
Provides robust privacy and
security for federated learning
models, preventing poisoning
attacks.
The use of SMPC can lead to
increased computational
overhead and delays​
(rf2).

3. Literature Survey
S.No Title Methodology Advantage Limitations
6
PyTorch: An Imperative
Style, High-Performance
Deep Learning Library
Introduces a Pythonic deep learning library
focused on dynamic eager execution with GPU
acceleration
Combines ease of use and
performance, widely
adopted in research
May sacrifice some speed
for usability compared to
static graph libraries​
(rf6)
7
Privacy-Preserving
Byzantine-Robust
Federated Learning via
Blockchain Systems
Proposes a federated learning model using
blockchain and homomorphic encryption to resist
poisoning attacks
Enhances privacy and
robustness with Byzantine-
resilient and encrypted
gradients
Computational overhead due
to fully homomorphic
encryption​
(rf5)
8
FLDetector: Defending
Federated Learning Against
Model Poisoning Attacks
via Detecting Malicious
Clients
Detects malicious clients in Federated Learning
by checking the consistency of their model
updates across iterations.
Effectively detects malicious
clients without needing a
clean validation dataset.
Limited effectiveness if the
malicious clients' updates
are statistically similar to
benign clients' updates​
(rf4).
9
Incentive Mechanism for
Horizontal Federated
Learning Based on
Reputation and Reverse
Auction
Uses a reverse auction combined with reputation
to incentivize participants in federated learning
under budget constraints.
Ensures participants with
reliable data quality are
selected within budget
constraints.
Assumes honest reporting of
bids and data quality, which
may not always be true​
(rf3).
10
Data and Model Poisoning
Backdoor Attacks on
Wireless Federated
Learning, and the Defense
Mechanisms: A
Comprehensive Survey
Comprehensive analysis of attack and defense
strategies for data/model poisoning backdoor
attacks on wireless federated learning.
Provides a thorough review
of defense mechanisms to
counter backdoor attacks
Many existing defense
mechanisms are still
limited in addressing all
types of attacks effectively.

5. MODULES
FEDERATED
LEARNING
SYSTEM
BLOCKCHAIN
INITIALIZATION
BLOCKCHAIN
& FL Linking
TESTING AND
EVALUATION
ATTACK
DETECTION and
PREVENTION
ATTACK
SIMULATION
MODULE 1 MODULE 2 MODULE 3
MODULE 4
MODULE 5
MODULE 6

6. Federated Learning Module –Setup
Dataset used – Breast Tumour dataset
3 classes : normal , benign, malignant
CNN Model used – DenseNet121
Federated Learning algorithm used : FedAVG
INITIAL EXPERIMENTATION – Simple neural network IN FedAVG :
Algorithm :
global_model <- SimpleNN(input_shape=(128, 128, 1), num_classes=3)
for round in range(n_rounds):
client_models <- [Train_Model(Copy_Model(global_model), Get_Batches(Load_Dataset(data), batch_size=16))
for data in client_datasets]
client_data_sizes <- Get_Client_Data_Sizes(client_datasets)
global_model <- Σ (client_model_i * client_data_sizes[i]) / Σ client_data_sizes # Weighted FedAvg
return global_model
normal benign malignant
•Model Structure: 3 layers, 16384-
128-64-3 neurons.
•Weight Initialization: Random
initialization using PyTorch defaults.
•Forward Pass: Reshaped input
processed with ReLU.

7. DENSENET 121
IMPLEMENTATION :
10 clients – each run 4 epochs
Accuracy Range:
•Minimum Accuracy: 69.19%
•Maximum Accuracy: 87.26%
Global model’s accuracy after FedAVG :
79.88%
DenseNet121 Model Architecture
•ADVANTAGES :
• Efficient Feature Propagation: Better feature extraction
in grayscale.
• Fewer Parameters: Deep but with lower overfitting risk.
•Better Gradient Flow: Stabilizes training in deeper
networks.
• Feature Reuse: Maximizes use of limited features.
• Proven Success: Widely effective in medical imaging.
TOOLS USED :
Libraries : PyTorch, Torchvision, NumPy, Requests
•Flask: Backend API for communication.
•IPFS: Decentralized model and metadata storage.

8. Storing clients’ model and metadata files in
IPFS : Upload model and metadata files to IPFS
Get the CIDs (Content Identifiers) for the uploaded files
Store the CIDs in Blockchain Smart Contracts
Use the Smart Contracts to access the model and
metadata files using the stored CIDs
Clients or stakeholders can retrieve the models by
querying the smart contracts for the relevant CIDs
Retrieve the models and metadata from IPFS using the
CIDs for further use ( model aggregation , evaluation)
Currently has 20 files:
 10 clients’ metadata
files(reputation, stake,
model’s metrics –
accuracy,precision,recall,
f1-score)
 Model files (.pth)which
mainly have weights

9. BLOCKCHAIN METHODOLOGY
Completed Environment Setup Smart Contract Creation & Deployment
NEXT STAGE Testing & Interaction Frontend Integration
. Blockchain Data Retrieval Testing & Validation
. Public Blockchain Deployment (Ethereum)
. Monitoring & Maintenance
Up to Date and Future

10. Simulates a local Ethereum
blockchain for testing and
development with pre-
funded accounts
BLOCKCHAIN SOFTWARE Req.
GANACHE
METAMASK
• Ethereum Tokens
• Transactions
• Interaction with BC
Visual Studio
Code (VS Code)
• Frontend
• Smart Contracts(only
for writing)
Remix IDE
Web-based IDE
• Writing
• Compiling
• Deploying
Smart Contracts
Web3.js or
Ethers.js
For interacting with the
Ethereum blockchain and
smart contracts from the
frontend.
Alchemy
API
• Connect Ethereum
Public Network
• Facilitating deployment
and interaction with SC

11. Blockchain Implemented Parts
Ethereum - GETH INITIALISED
1.Started the Nodes
2.Created Account for Transactions
and Increasing ETH

12. Blockchain Implemented Parts
Ganachae - Initialised
1.Took One Address
and linked with MetaMask.

13. Blockchain Implemented Parts
Linked
METAMASK
1.Took the Private Key.
2.Added it to the MetaMask.

14. After Implementing Smart Contract

15. POISONING ATTACKS DETECTION AND MITIGATION
Proposers Reward-and-Slash
Input: MajorityDecision (majority decision), ClientsSet
(clients), ProposersSet (proposers), ClientAsset (client asset),
RequiredStakeForProposing (stake), ProposerStakePool
(proposers' stake)
if MajorityDecision == -1 then
for client in ProposersSet do
if ClientAsset ≥ RequiredStakeForProposing then
ClientAsset -= RequiredStakeForProposing
ProposerStakePool += RequiredStakeForProposing
else
ProposerStakePool += ClientAsset
ClientAsset = 0
ClientsSet -= {client} //slashing the client
else
if ProposerStakePool > 0 then
for client in ProposersSet do
ClientAsset += ProposerStakePool / |ProposersSet|
//distribution among clients equally
ProposerStakePool = 0
Voters Reward-and-Slash
Input: Input: MajorityDecision (majority decision), ClientsSet
(clients), VotersSet (voters), CorrectVotersSet (voters with
correct votes), ClientAsset (client asset),
RequiredStakeForVoting (stake), VoterStakePool (voters' stake)
for client in VotersSet CorrectVotersSet do (incorrectVoters)
if ClientAsset ≥ RequiredStakeForVoting then
ClientAsset -= RequiredStakeForVoting .//slashing
VoterStakePool += RequiredStakeForVoting
else
VoterStakePool += ClientAsset
ClientAsset = 0
ClientsSet -= {client}
for client in CorrectVotersSet do
ClientAsset += VoterStakePool / |CorrectVotersSet| //reward
VoterStakePool = 0

16. NEXT- ATTACKS IMPLEMENTATION – DETECTION AND
MITIGATION METHODS POSSIBLE :
Attack Name Implementation in Our Case Detection Methods Mitigation Methods
Poisoning Attack
A malicious client sends
manipulated model weights or
gradient updates during training
to corrupt the global model's
performance.
- Monitor deviation in local updates
from the expected norms (outlier
detection).
- Implement a voting mechanism
among honest clients.
- Validate performance metrics such
as accuracy drop.
- Use blockchain for secure
aggregation.
- Employ anomaly detection
algorithms based on local updates.
Free-Rider Attack
A client submits low-quality or
random updates without training
but still receives rewards or
contributions in global
aggregation.
- Check consistency between model
updates and the provided stake,
reputation, and accuracy.
- Implement reward-based
participation, slashing the reputation
and stake for free-riders.
- Periodically request validation of
the client's training efforts (random
audits).
- Use zero-knowledge proofs to
validate training without revealing
data.
Model Inversion Attack
An adversary uses the model
parameters or gradients shared by
clients to infer sensitive training
data.
- Analyze unusual access patterns or
queries on the global model.
- Use differential privacy (add noise
to gradients or model weights).
- Detect gradients that leak
information through differential
privacy methods.
- Apply homomorphic encryption on
local model updates.
Sybil Attack
Multiple fake clients are created
by the adversary to control a large
portion of the aggregation
process, skewing the global
model.
- Use blockchain to validate the
authenticity of each client.
- Implement identity verification
using decentralized identifiers (DIDs).
- Monitor unusual patterns of clients
submitting updates at the same time
or originating from the same source.
- Limit the number of contributions
from the same network or
geographic region.

17. Thank You.