# Defending Against Poisoning Attacks in Federated Learning with Blockchain

Nanqing Dong  Zhipeng Wang  Jiahao Sun  Michael Kampffmeyer  William
Knottenbelt  and Eric Xing  Fellow, IEEE The first two authors contributed
equally to this work. This work was supported in part by FLock.io under the
FLock Research Grant. (Corresponding author: Nanqing Dong.)N. Dong is with the
Shanghai Artificial Intelligence Laboratory, Shanghai, 200232, China. (email:
dongnanqing@pjlab.org.cn)Z. Wang and W. Knottenbelt are with the Department of
Computing, Imperial College London, London, SW7 2AZ, UK. (emails:
<EMAIL_ADDRESS>w.knottenbelt@imperial.ac.uk)J. Sun is with
FLock.io, London, WC2H 9JQ, UK. (email: sun@flock.io)M. Kampffmeyer is with
the Department of Physics and Technology at UiT The Arctic University of
Norway, 9019 Tromsø, Norway. (email: michael.c.kampffmeyer@uit.no)E. Xing is
with the Machine Learning Department, School of Computer Science, Carnegie
Mellon University, Pittsburgh, PA 15213, USA; and also with Mohamed bin Zayed
University of Artificial Intelligence, Masdar City, Abu Dhabi, UAE (email:
<EMAIL_ADDRESS>
###### Abstract

In the era of deep learning, federated learning (FL) presents a promising
approach that allows multi-institutional data owners, or clients, to
collaboratively train machine learning models without compromising data
privacy. However, most existing FL approaches rely on a centralized server for
global model aggregation, leading to a single point of failure. This makes the
system vulnerable to malicious attacks when dealing with dishonest clients. In
this work, we address this problem by proposing a secure and reliable FL
system based on blockchain and distributed ledger technology. Our system
incorporates a peer-to-peer voting mechanism and a reward-and-slash mechanism,
which are powered by on-chain smart contracts, to detect and deter malicious
behaviors. Both theoretical and empirical analyses are presented to
demonstrate the effectiveness of the proposed approach, showing that our
framework is robust against malicious client-side behaviors.

Federated learning has been a promising solution to utilize multi-site data
while preserving users’ privacy. Despite the success of integrating blockchain
with federated learning to decentralize global model aggregation, the
protection of this integration from clients with malicious intent in federated
scenarios remains unclear. This paper presents the first formulation of this
problem and the proposed stake-based aggregation mechanism shows robustness in
detecting malicious behaviors. The results in this work not only pose a new
research direction in federated learning, but can also benefit a wide variety
of applications such as finance and healthcare.

Blockchain, Deep Learning, Federated Learning, Trustworthy Machine Learning

##  1 Introduction

Nowadays, machine learning (ML), or more specifically, deep learning, has
transformed a broad spectrum of industries, ranging from finance to
healthcare. In current ML paradigms, training data are first collected and
curated, and then ML models are optimized by minimizing certain loss criteria
on the training data. A common underlying assumption in the learning
environment is that the training data can be instantly accessed or easily
distributed across computing nodes without communication constraints, _i.e.
missing_ data are _centralized_.

However, in a system with multiple _clients_ (_i.e. missing_ data holders), to
ensure data centralization, clients have to upload local data to a centralized
device (_e.g. missing_ a central server) to conduct the centralized training
described above. Despite the success of centralized training in various deep
learning applications [1, 2, 3], there is growing concern about data privacy
and security, especially when the local data held by the clients are private
or contain sensitive information. Especially, to ensure data governance,
strict data regulations have been established [4, 5].

Figure 1: A stake-based aggregation mechanism for FL with blockchain. In each
round, the proposers are randomly selected from the participating clients to
perform local training and upload local updates to the blockchain. Then,
voters download the aggregated local updates from the blockchain, perform
local validation, and vote for acceptance or rejection. If the majority of
voters vote for accepting the global aggregation, the global model will be
updated, and the proposers and the voters who vote for acceptance will be
rewarded. Conversely, if the majority of voters vote for rejection, the global
model will not be updated, and the proposers and the voters who vote for
acceptance will be slashed.

To address the aforementioned concern, federated learning (FL) has been
proposed [6]. In a typical FL system, a central server [7] is responsible for
aggregating and synchronizing model weights, while a set of clients manipulate
multi-site data. This facilitates data governance, as clients only exchange
model weights or gradients with a central server instead of uploading local
data to the central server, and has led to FL becoming a standardized solution
to utilize multi-site data while preserving privacy.

Though FL perfectly implements _data decentralization_ , a trustworthy central
server is required in the system. In such a system design, the central server
in fact has privileges over clients, as the central server determines the
global aggregation and synchronization. If the central server is compromised
or manipulated by a malicious party, the clients are vulnerable if the central
server intentionally distributes problematic model updates. This can
potentially increase the cost of system management and maintenance. Towards
avoiding this single point of failure, many efforts have been made to
decentralize the central server, and one particularly promising solution is to
use a blockchain as decentralized storage [8].

Originally proposed for cryptocurrencies, a blockchain is a distributed ledger
that can record the state transition information among multiple parties [9,
10], without relying on a centralized server. Blockchain technology has gained
widespread attention for its potential to revolutionize a variety of
industries, such as finance [9], healthcare [11], and supply chain management
[12]. By leveraging the decentralized nature of the blockchain, FL can benefit
from increased security, privacy, and efficiency, as well as reduced reliance
on centralized servers [13]. Concretely, in FL with blockchain, each client
participating in the learning process uploads their local model updates to the
blockchain, where they are stored in _blocks_ , the metadata of a blockchain
system. These blocks are then used to aggregate the local model updates into a
global model, which can be downloaded by the clients. The use of blockchain
_smart contracts_ [9], which are computer programs triggered by blockchain
events, ensures that the global aggregation process is performed automatically
and transparently, without the need for human intervention or centralized
control.

Though integrating blockchain with existing FL systems can partially solve the
threat to the central server, it cannot guarantee the quality of uploaded
model updates from the clients. That is to say, blockchain-enabled FL systems
are still vulnerable to client-side malicious attacks [14]. In this work, we
define malicious behaviors as actions that intentionally decrease the learning
performance (_e.g. missing_ accuracy and convergence) of the global model via
poisoning attacks (such as data poisoning [15] or model poisoning [14]).
Instead of hacking the central server, the attackers can sabotage the FL
systems by manipulating the clients. This work focuses on defending against
client-side poisoning attacks. One solution is to combine blockchain-enabled
FL with cryptographic protocols, such as Fully Homomorphic Encryption (FHE)
[16] and Secure Multi-Party Computation (SMPC) [17], to mitigate malicious
behaviors from the client side. However, the adoption of these intricate
cryptographic protocols introduces significant computational overhead for FL
participants, thus impairing the system performance. Besides, the malicious
clients can still attack the system without breaching the protocols. It is
challenging to address malicious behaviors without substantially compromising
the efficiency of a blockchain-based FL system.

We propose a generic framework that can integrate an FL system with a
blockchain system and can defend against poisoning attacks without adopting
complex cryptographic protocols. The proposed defense mechanism is motivated
by _proof-of-stake_ (PoS) [18], a _consensus mechanism_ in blockchain, and
_The Resistance_ [19], a role-playing board game. PoS has an incentive
mechanism that encourages honest behaviors by _rewarding_ it and punishes
dishonest behaviors via _slashing_. _The Resistance_ , on the other hand, has
two mismatched competing parties, where the party with a larger size is
denoted as the resistance force and the other party is denoted as the spies.
In _The Resistance_ , there is a voting mechanism where, in each round, each
player conducts independent reasoning and votes for a player, and the player
with the highest votes will be deemed as a “spy” and kicked out of the game.
The goal of the resistance force is to vote out all the spies while the spies
aim to impersonate the resistance force and survive until the end. Based on
these two concepts, this work proposes a novel majority-voting mechanism for
global aggregation where each participating client independently validates the
quality of aggregated local updates and votes for acceptance of the global
update. The aggregation mechanism is stake-based where participating clients
stake assets111In practice, the staked assets can be linked with
cryptocurrency or real currency to increase the financial cost of malicious
attacks. or _tokens_ (a quantitative measurement of the asset, which can be
used to indicate the trustworthiness of the client in our system) for their
own actions. There are two types of actions, proposing (uploading local
updates) and voting. If the majority vote is to accept the global aggregation,
a proposer will be refunded with its staked tokens and a voter who votes for
acceptance will not only be refunded but also be rewarded with the staked
tokens from the voters who vote for rejection, and vice versa. The overall
procedure of the stake-based aggregation mechanism is illustrated in Fig. 1.
To the best of our knowledge, this is the first work that integrates the
majority voting and incentive mechanisms in the FL and blockchain literature.

We evaluate the proposed framework on a practical financial problem, namely
loan default prediction. We simulate the FL and blockchain environment for the
Lending Club Kaggle challenge dataset and ChestX-ray14 dataset [20], to
conduct experiments in a controllable setting and to provide insights into the
problem of interest. We empirically show that an FL system can maintain robust
performance under malicious attacks by introducing the proposed stake-based
aggregation mechanism.

The contributions of this work are summarized as follows:

We formulate the problem of decentralized federated learning with blockchain
in the presence of poisoning attacks.

For the first time, we introduce a novel stake-based aggregation mechanism
designed to fortify federated learning systems against poisoning attacks. In
contrast to prior solutions, our mechanism boasts the distinct advantage of
seamless integration into any blockchain enabled with smart contracts, all
without necessitating alterations to the foundational consensus structure of
the underlying blockchain. This approach not only enhances security but also
simplifies accessibility, rendering it a more user-friendly option for
federated learning participants.

We evaluate the robustness of the proposed framework in a simulated
environment and provide initial empirical insights into the problem of
interest. The findings show evidence that stake-based FL is an under-explored
research problem with potential advantages compared with existing FL paradigms
in terms of defending against poisoning attacks.

The rest of the paper is organized as follows. Sec. 2 reviews the related work
on FL and blockchain computing. Sec. 3 formulates the problem of interest,
defines the key concepts, and lists the necessary assumptions. Sec. 4 presents
the method and theoretical result. Sec. 5 and Sec. 6 provide the experimental
details on two different setups. Sec. 7 concludes this work.

Figure 2: Blockchain workflow overview. The sender broadcasts the issued transaction to the P2P network, which will be confirmed by the miners. The confirmed transaction will be stored on a public blockchain and can be read by the recipient. Blockchain miners typically adopt a consensus mechanism to achieve an agreement on the state of the blockchain. Table 1: Comparison of existing blockchain-based FL solutions. Framework | Technique | Incentive Mechanism | Cryptocurrency Incentive | Blockchain Agnostic | Attack Mitigation
---|---|---|---|---|---
[16] | FHE | ✗ | ✗ | - | ✓
[17] | SMPC | ✗ | ✗ | - | ✓
[21] | DP | ✗ | ✗ | - | ✓
[22] | DP-GAN | ✗ | ✗ | - | ✓
[23] | incentive mechanism | ✓ | ✓ | - | ✗
[24] | reputation + reverse auction | ✓ | ✓ | - | ✗
[25] | blockchain + reward only | ✓ | ✓ | ✗ | ✓
[13] | committee consensus | ✓ | ✓ | ✗ | ✓
[26] | committee consensus | ✓ | ✓ | ✗ | ✓
Ours | majority vote + reward & slash | ✓ | ✓ | ✓ | ✓

##  2 Related Work

In this section, we review the recent progress on blockchain-based FL, and
highlight the difference between the proposed method and existing studies.

###  2.1 Blockchain

Blockchains refer to distributed ledgers that operate on a global peer-to-peer
(P2P) network, as exemplified by popular cryptocurrencies such as Bitcoin [27]
and Ethereum [9]. Users can freely join or leave the blockchain system,
without a central authority in place to ensure common agreement on the
distributed ledgers. Instead, users rely on consensus protocols [18, 28], such
as proof-of-work (PoW) or PoS, to achieve agreement in a distributed setting.

As shown in Fig. 2, a blockchain transaction typically involves a sender who
transfers digital assets, such as cryptocurrencies, to a recipient. The sender
authorizes the transaction with a digital signature combining transaction
details and their private key. The transaction is then broadcasted over a P2P
network to _miners_ , who are participants in the network responsible for
verifying and adding new blocks of transactions to the blockchain. Miners
validate and confirm the transaction using consensus protocols, to ensure that
the transaction is legitimate and not a duplicate or fraudulent transaction.
Once confirmed, the transaction is added to a block, which is then linked to
the previous block using cryptographically hash functions [29], forming a
chain of blocks (_i.e. missing_, blockchain). The block is then propagated to
all the participants in the network, creating a decentralized, immutable
record of the transaction. The combination of cryptography and consensus
protocols enhances the security, transparency, and decentralization of
transactions, underscoring blockchain’s potential across various applications
[30, 11, 12, 31, 32].

Another key feature of blockchain technology is the use of smart contracts
[9], which are quasi-Turing-complete programs that can be executed within a
virtual machine. When a transaction is initiated, a smart contract is
typically used to encode the terms and conditions of the transaction, such as
the amount, currency, and time of transfer. The smart contract is then stored
on the blockchain network and executed automatically when the predefined
conditions are met.

###  2.2 Federated Learning with Blockchain

Traditional FL faces challenges [33, 34, 35], such as privacy and security
concerns (_e.g. missing_, poisoning attacks), unreliable communication, and
difficulty in reaching a consensus among the parties. Blockchain, on the other
hand, provides a decentralized, secure, and transparent platform for data
storage and sharing. This makes the use of blockchain for FL a promising
direction to potentially address privacy and security concerns by allowing
parties to keep their data private while still contributing to the training
process. Additionally, blockchain can provide a secure communication channel
for FL participants and ensure the integrity of the FL process.

Current blockchain-based FL designs [35, 36, 8, 37, 38] have been broadly used
in diverse fields [39, 40, 41]. For example, Ma  _et al_. [25] propose a
blockchain-assisted decentralized FL (BLADE-FL) framework, to prevent
malicious clients from poisoning the learning process. Li  _et al_. [13]
analyze the impact of lazy clients on the learning performance of BLADE-FL and
propose optimization for minimizing the loss function. Cui  _et al_. [22]
propose a blockchain-based decentralized and asynchronous FL framework for
anomaly detection in IoTs by using a model named DP-GAN. Qu  _et al_. [26]
introduce a committee-based blockchain consensus algorithm for decentralized
FL to prevent the single point of failure and poisoning attacks in FL.

Despite the potential benefits of combining FL with blockchain, several
challenges remain. For instance, FL systems are still vulnerable to client-
side malicious attacks [14] and lack incentive-compatible mechanisms to
motivate FL participants to behave honestly during the training process. For
instance, Miao  _et al_. [16] leverage cosine similarity and blockchain to
counteract poisoning attacks and penalize malicious clients. Their designs
also rely on cryptographic techniques such as FHE. Kalapaaking  _et al_. [17]
adopt SMPC to enhance the security of blockchain-based FL which can mitigate
poisoning attacks for healthcare systems. Yan  _et al_. [21] integrate
differential privacy (DP) techniques with blockchain to mitigate the issues of
a single point of failure or untrusted aggregation caused by a malicious
central server in privacy-preserving federated learning. However, using FHE,
SMPC, or DP, instead of incorporating incentive mechanisms, may introduce an
additional computation burden for clients or the server.

Several incentive mechanisms [23, 24] have recently been proposed to encourage
participants and enhance model accuracy in blockchain-based FL. However, it
remains unclear how to effectively utilize the blockchain infrastructure and
leverage its inherent incentive mechanism (_i.e. missing_ cryptocurrencies) to
incentivize trustworthy FL behaviors and penalize malicious clients.
Furthermore, to thwart potential malicious activities, such as poisoning
attacks, existing blockchain-based FL solutions [8, 36, 25, 13, 26] have
pointed out that participants can engage in both the FL training process and
the block validation in PoS-based blockchains or mining activities in PoW-
based blockchains. These design choices not only raise the entry barrier for
regular users wishing to partake in blockchain-based FL systems but also add
complexity to the fundamental consensus mechanism.

In this work, we introduce a PoS-based reward-and-slash mechanism for the FL
system. We compare our solution with existing work in Table 1. Our solution
can be seamlessly integrated into any smart-contract-enabled blockchain
without requiring modifications to the underlying consensus design (_i.e.
missing_, our design is blockchain agnostic). This approach facilitates the
participation of any FL users, making it more accessible and user-friendly.

##  3 Problem Formulation

This section introduces the problem of interest, the definition of the
malicious behaviors considered, and the underlying assumptions in this work.
The main definitions and notations adopted in this work are summarized in
Table 2.

###  3.1 Setup

There are $K>1$ clients in a federated system. Let
$\mathcal{K}=\\{1,2,\cdots,K\\}$ denote the set of all clients. Let
$\mathcal{D}_{k}$ denote the local data stored in client $k$, we have
$\mathcal{D}_{k}\cap\mathcal{D}_{l}=\emptyset$ for $k\neq l$ and
$k,l\in\mathcal{K}$. Each local dataset $\mathcal{D}_{k}$ can be randomly
split into a training set and a test set, which are both private to client
$k$. In addition to $K$ clients, a blockchain plays the role of a parameter
server [7] for global aggregation. Let $f_{\theta}$ be the model of interest.
In the parameter server, the parameter set $\theta_{0}^{0}$ is randomly
initialized at round $0$ and $K$ clients download $\theta_{0}^{0}$ from the
blockchain as $K$ local copies $\\{\theta_{k}^{0}\\}_{k=1}^{K}$ for full
synchronization. During the federated optimization phase, a set of
$\mathcal{K}_{p}^{t}$ clients is randomly selected for round $t$. For each
$k\in\mathcal{K}_{p}^{t}$, the client $k$ updates $\theta_{k}^{t-1}$ by
training on the training set of $\mathcal{D}_{k}$ independently for a number
of local epochs. Then, the blockchain aggregates updated
$\\{\theta_{k}^{t}\\}_{k\in\mathcal{K}}$ collected from all the $K$ clients to
update $\theta_{0}^{t}$. The $K$ clients then synchronize with the parameter
server, _i.e. missing_ $\theta_{k}^{t}\leftarrow\theta_{0}^{t}$. To facilitate
data governance, as required in among others the medical domain [5, 4], we
assume that the patient’s data (either raw data or encoded data) in a client
can not be uploaded to the blockchain or other clients, _i.e. missing_ only
parameters $\\{\theta_{k}\\}_{k=0}^{K}$ and _metadata_ (_e.g. missing_ the
statistics of data) [42, 43] can be exchanged between the blockchain and the
clients. It is worth mentioning that this work focuses on the interactions
between FL and blockchain, where blockchain computing (or _mining_ , in a more
fashionable sense) and the application of additional privacy-preserving
techniques [44] are considered orthogonal research directions and thus beyond
the scope of this work.

###  3.2 Malicious Behaviors

The definition of malicious behavior in this work is an action that
intentionally decreases the global model performance. There are two types of
actions for each client that interact with the federated system, _i.e.
missing_ a client can propose (_i.e. missing_ be a _proposer_) and vote (_i.e.
missing_ be a _voter_). Proposing is to upload local model or gradient updates
to the parameter server, while voting is a peer-review process to validate the
“virtually” aggregated model updates. The technical details of the two actions
are described in Sec. 4. There are thus two corresponding malicious behaviors.
The first malicious behavior is to propose harmful local model updates and the
second one is to vote dishonestly. More specifically, in the second case, a
client votes for approval when it is aware that the proposed model updates are
poisoned and votes for rejection when there is no evidence that indicates that
the proposed model updates are poisoned. It is worth mentioning that the
clients themselves might not intentionally attack the FL system as they can be
compromised by attackers. For simplicity, we define the clients that have
malicious behaviors as _malicious clients_ in this work, denoted as
$\mathcal{K}_{m}$. We use $\eta$ to denote the ratio of malicious clients
among all clients, _i.e. missing_
$\eta=\frac{|\mathcal{K}_{m}|}{\mathcal{K}}$, where $|\cdot|$ is the
cardinality of a set.

###  3.3 Assumptions

There are six important assumptions in this work.

A1: The goal of malicious behaviors is to decrease the global model
performance. This is also reflected in Sec. 3.2. Under these assumptions,
behaviors that are harmful to the system but do not influence the global model
performance are beyond the scope of discussion in this work. An example is
eavesdropping, _i.e. missing_ cloning the model specifications.

A2: All clients are rational. This means that both honest and malicious
clients expect to maximize their gain or minimize their loss while achieving
their goals.

A3: Following previous studies on blockchain [13], we assume that $\eta$ is
strictly smaller than $50\%$. This means there are always more honest clients
than malicious clients in a federated system.

A4: There is no capacity constraint on the hardware, including computing,
communication, and storage, allowing us to solely focus on the algorithmic
side of the problem.

A5: The underlying blockchain of the FL system of interest is running securely
with a consensus protocol that ensures the validity and integrity of
transactions and blocks. While the security of the blockchain is crucial for
the overall security of the FL system, addressing the malicious miners falls
outside the scope of this study.

Table 2: Summary of main definitions and notations.

Notation | Description
---|---
blockchain-based FL | FL framework with a blockchain architecture
FedAVG | Federated Averaging [6], a FL algorithm
non-IID | Non-independently and identically distributed
$\mathcal{K}$ | Set of participating clients at round $t$
$K_{v}^{t}$ | The selected set of voters
$\mathcal{K}_{p}^{t}$ | Set of proposers at round $t$
$a^{t}$ | Majority voting decision at round $t$
$M_{k}$ | Asset of client $k$
$\gamma_{p}$ | Staked tokens for proposing
${pool}_{p}$ | Pool for storing proposers’ stake

##  4 Method

In this section, we first introduce the basics of federated aggregation in
Sec. 4.1, and describe the local validation and majority voting in Sec. 4.2
and Sec. 4.3. We then propose a novel incentive mechanism in Sec. 4.4. A
theoretical analysis on malicious voting is presented in Sec. 4.5. We then
describe the whole training pipeline in Sec. 4.6. Finally, the analysis of
computational cost is provided in Sec. 4.7.

Figure 3: A round-based training process. In the initial state (indexed as ①),
both honest (black) and malicious (red) clients exist in an FL system. In the
final state (indexed as ⑥), all malicious clients are expected to be removed
from the system. To reach the final state from the initial state, multiple
rounds of training are required. Here are two possible scenarios, the proposed
aggregation is either approved (the upper branch) or denied (the lower branch)
by the voters. In each round (within the dotted blue line), a subset of
clients are randomly selected as proposers, and another subset of clients are
randomly selected as voters. The proposers and voters interact with the
blockchain following the order of orange arrows (from ② to ⑤).

###  4.1 Federated Aggregation

In this work, we illustrate the proposed framework in the context of the
seminal FL method, FedAVG [6]. At the end of round $t$, the local models
$\\{\theta_{k}^{t}\\}_{k=1}^{K}$ are uploaded and aggregated as a weighted
average:

$\theta_{0}^{t}=\sum_{k=1}^{K}a_{k}\theta_{k}^{t},$ (1)

where $a_{k}=\frac{n_{k}}{N}$. The metadata $n_{k}=|\mathcal{D}_{k}|$ is the
number of local training examples stored in client $k$ and
$N=\sum_{k=1}^{K}n_{k}$ is the total number of training examples in the $K$
clients.

###  4.2 Local Validation

In contrast to standard FL algorithms, the aggregated global model is not
recorded in a block directly. Instead, $\tilde{\theta}_{0}^{t}$, a copy of
$\theta_{0}^{t}$ is downloaded by a randomly selected set of clients, denoted
as _voters_ , $\mathcal{K}_{v}^{t}$. A voter $k$ runs a local inference with
$\tilde{\theta}_{0}^{t}$ on its local test set and outputs a local validation
score. The local validation score $s^{t}_{k}$ is a scalar, which can be linked
with common metrics of ML tasks222For example, common evaluation metrics
include accuracy for classification, mean Intersection over Union (mIOU) for
semantic segmentation, and mean average precision (mAP) for object detection..
If $s^{t}_{k}$ is not lower than a threshold, the voter votes for accepting
this aggregated model; otherwise, the voter votes against it. The threshold
can be based on a validation score $s^{t-1}_{k}$ acquired in the previous
round. In the training of ML tasks, the scores can be volatile due to the
characteristics of the tasks. Thus, a hyperparameter $\epsilon\in(0,1)$ is
introduced to control the tolerance of performance decrease in a single round.
Mathematically, the $k$-th voter has the following score.

$v_{k}^{t}=\begin{cases}\phantom{+}1,&s^{t}_{k}\geq(1-\epsilon)s^{t-1}_{k}\\\
-1,&s^{t}_{k}<(1-\epsilon)s^{t-1}_{k}\end{cases}$ (2)

It is worth mentioning that the likelihood of the attackers consistently
manipulating the scores by fooling all the randomly selected voters (_e.g.
missing_ via adversarial attacks [45]) diminishes quickly towards zero as the
number of epochs increases. According to A4, the majority of voters are
honest. It is thus difficult to attack (either via data poisoning or model
poisoning) as the validation set of each client is private.

###  4.3 Majority Voting

The majority voting process for whether to apply the global aggregation
operation at round $t$ can be described below. Here, we use a binary variable
$a^{t}$ to denote the decision.

$a^{t}=\begin{cases}\phantom{+}1,&\sum_{k\in\mathcal{K}_{v}}v_{k}>0\\\
-1,&\sum_{k\in\mathcal{K}_{v}}v_{k}\leq 0\end{cases}$ (3)

If $a^{t}=1$, the global aggregation will be finalized and recorded in the
block; otherwise, the global aggregation will be discarded.

###  4.4 Asset Redistribution

As there are two independent actions, there are two parallel reward-and-slash
designs for proposing and voting. For both actions, the randomly selected
proposers and voters are required to stake a fixed sum of tokens before they
act. If some of these actors fail to stake (they do not have enough tokens
left), they lose their access to the blockchain and are removed from the FL
system permanently. Proposers will be rewarded with tokens accumulated in an
independent pool (if there are any tokens left in the pool) if the global
aggregation is approved and lose their stakes if the global aggregation is
rejected. The reward-and-slash design for the proposers is illustrated in
Algorithm 1. For the voters, the majority party will not only take back their
stakes but also be rewarded with the staked tokens lost by the minority party.
The reward-and-slash design for the voters is illustrated in Algorithm 2. In
the following section, Sec. 4.5, we demonstrate that under the proposed design
and assumptions in Sec. 3.3, malicious voters have no incentive to make
dishonest votes. Note, Sec. 4.4 highlights the key difference between the
proposed voting mechanism and traditional majority voting as the voting is
directly linked with the incentive mechanism.

1:$a^{t}$: Majority voting decision at round $t$

2:$\mathcal{K}$: Set of participating clients at round $t$

3:$\mathcal{K}_{p}^{t}$: Set of proposers at round $t$

4:$M_{k}$: Asset of client $k$

5:$\gamma_{p}$: Staked tokens for proposing

6:${pool}_{p}$: Pool for storing proposers’ stake

7:if $a^{t}==-1$ then

8: for $k\in\mathcal{K}_{p}^{t}$ do

9: if $M_{k}\geq\gamma_{p}$ then

10: $M_{k}\leftarrow M_{k}-\gamma_{p}$

11: ${pool}_{p}\leftarrow{pool}_{p}+\gamma_{p}$

12: else

13: ${pool}_{p}\leftarrow{pool}_{p}+M_{k}$

14: $M_{k}\leftarrow 0$

15: $\mathcal{K}^{t}\leftarrow\mathcal{K}^{t}\setminus\\{k\\}$

16:else

17: if ${pool}_{p}>0$ then

18: for $k\in\mathcal{K}_{p}^{t}$ do

19: $M_{k}\leftarrow M_{k}+\frac{{pool}_{p}}{|\mathcal{K}_{p}^{t}|}$

20: ${pool}_{p}\leftarrow 0$

Algorithm 1 Reward-and-slash design for a set of randomly selected proposers.

1:$a^{t}$: Majority voting decision at round $t$

2:$\mathcal{K}$: Set of participating clients at round $t$

3:$\mathcal{K}_{v}^{t}$: Set of voters at round $t$

4:$\mathcal{K}_{m}^{t}$: Set of voters at round $t$ with $v_{k}^{t}==a^{t}$

5:$M_{k}$: Asset of client $k$

6:$\gamma_{v}$: Staked tokens for voting

7:${pool}_{v}$: Pool for storing voters’ stake

8:for $k\in\mathcal{K}_{v}^{t}\setminus\mathcal{K}_{m}^{t}$ do

9: if $M_{k}\geq\gamma_{v}$ then

10: $M_{k}\leftarrow M_{k}-\gamma_{v}$

11: ${pool}_{v}\leftarrow{pool}_{v}+\gamma_{p}$

12: else

13: ${pool}_{v}\leftarrow{pool}_{v}+M_{k}$

14: $M_{k}\leftarrow 0$

15: $\mathcal{K}^{t}\leftarrow\mathcal{K}^{t}\setminus\\{k\\}$

16:for $k\in\mathcal{K}_{m}^{t}$ do

17: $M_{k}\leftarrow M_{k}+\frac{{pool}_{v}}{|\mathcal{K}_{m}^{t}|}$

18:${pool}_{v}\leftarrow 0$

Algorithm 2 Reward-and-slash design for a set of randomly selected voters.

###  4.5 Theoretical Analysis on Malicious Votes

In this section, we theoretically show that malicious voters in the proposed
framework have no incentive to make dishonest votes.

######  Theorem 1 (Honest Voting Hypothesis)

When all clients are rational, a malicious client should not make a malicious
vote.

######  Proof 4.2.

Let $\mathcal{K}_{v}$ denote a randomly selected set of voters and
$n_{v}=|\mathcal{K}_{v}|$. For client $k\in\mathcal{K}_{v}$, let
$\gamma_{v}>0$ denote the staked tokens for voting, _i.e. missing_ client $k$
must stake $\gamma_{v}$ to participate in the voting, otherwise, it will be
removed from the system.

Let us consider a multi-agent scenario, where malicious clients can collude.
No matter how the malicious clients cooperate, there are two types of
malicious clients. The first type behaves maliciously to achieve the goal of
sabotaging the FL training, _i.e. missing_, lowering the global performance.
The second type acts honestly to hide themselves and survive to be able to
implement the complex policy to sabotage the FL training at the a later stage.
If the malicious clients belong to the second type, they are factually
“honest” ones.

Let $r$ be the ratio of malicious clients in $\mathcal{K}_{v}$, there are
$r\cdot n_{v}$ malicious clients in $\mathcal{K}_{v}$ and $(1-r)\cdot n_{v}$
honest clients. If $r\cdot n_{v}<(1-r)\cdot n_{v}$, _i.e. missing_ $r<0.5$,
each malicious client will lose $\gamma_{v}$; if $r\cdot n_{v}>(1-r)\cdot
n_{v}$, _i.e. missing_ $r>0.5$, each malicious client will gain
$\frac{(1-r)\cdot n_{v}\cdot\gamma_{v}}{r\cdot
n_{v}}=\frac{1-r}{r}\gamma_{v}$. The expected return $\mathcal{R}$ of a
malicious client will be

$\begin{split}\mathcal{R}&=\int_{0}^{0.5}-\gamma_{v}dr+\int_{0.5}^{1}\frac{1-r}{r}\gamma_{v}dr\\\
&=-0.5\gamma_{v}+((\ln(1)-1)-(\ln(0.5)-0.5))\gamma_{v}\\\
&=-(\ln(0.5)+1)\gamma_{v}<0\end{split}$ (4)

Under A2, each client is rational. As $\mathcal{R}<0$, in the long run, a
malicious client will lose all tokens and be removed from the system. So, a
given client has no reason to make a dishonest vote resulting in honest votes
by all clients.

Theorem 1 will further be empirically validated in Sec. 5.2.1.

If A2 holds, we are certain that the malicious voters will reach a consensus
internally before they act to win the majority vote. Intuitively, all
malicious voters can be considered as a group together. In this case, this
”group” will behave exactly as the single malicious client in Theorem 1 based
on the same reasoning. The proof is omitted.

###  4.6 Training

Each round consists of the following steps: proposer selection, local
training, global aggregation, local validation, majority voting, token
redistribution, and block creation (recording _state_ 333For example, the
state can record the global model and tokens of each client. information). The
above steps are repeated in multiple rounds until certain stopping criteria
are fulfilled. The complete training process is depicted in Fig. 3. The
stopping criteria could be a fixed amount of training epochs, which is
commonly adopted in ML.

###  4.7 Computation Complexity and Cost

For proposers, the primary computational cost is driven by the local training
algorithm, mirroring the structure of traditional FL. For voters, their
computation cost stems from evaluating the aggregated global model. In
addition to mining blocks, miners engage in further computations by
consolidating global model updates, akin to the responsibilities of a
centralized aggregator in traditional FL. The overall computational complexity
is contingent upon the underlying training network backbone.

The communication and storage costs are outlined as follows. We assume the
model size is $M$. During an epoch, the communication cost for a client (_i.e.
missing_, a proposer or a voter) is $O(M)$. And the storage cost on the
blockchain is $O(K\cdot M)$, where $K$ is the number of clients.

##  5 Experiments

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 4: Token distribution results for malicious voters when all proposers are honest. The malicious voters’ tokens decrease quickly as the number of epochs increases and a large $\gamma_{p}$ leads to a high decreasing rate. This empirically validates our proof of Theorem 1. The solid line denotes the mean over 5 runs with different random seeds and the shaded region denotes 1 standard deviation around the mean. Table 3: Performance comparison under different values of the ratio of malicious clients ($\eta$). The reported numbers of the performance are mean and standard deviation under 5 random seeds. Model | $\eta=0.1$ | $\eta=0.2$ | $\eta=0.3$ | $\eta=0.4$
---|---|---|---|---
FedAVG w/ mal | $0.963\pm 0.017$ | $0.946\pm 0.034$ | $0.801\pm 0.222$ | $0.709\pm 0.266$
FedAVG w/ block (Ours) | $0.965\pm 0.008$ | $0.969\pm 0.003$ | $0.952\pm 0.020$ | $0.955\pm 0.021$
FedAVG w/o mal | $0.975\pm 0.004$ | $0.975\pm 0.004$ | $0.975\pm 0.004$ | $0.975\pm 0.004$
_Oracle_ | $0.971\pm 0.007$ | $0.971\pm 0.007$ | $0.971\pm 0.007$ | $0.971\pm 0.007$

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 5: Federated training under different values of the ratio of malicious
clients ($\eta$). Each subfigure shows the training AUROCs when the training
time (_i.e. missing_ the number of epochs) increases. The solid lines are the
mean AUROCs and the shaded regions are 1 standard deviation around the means.
We compare the performances of FedAVG with blockchain (i.e., w/ Block), FedAVG
with malicious clients (i.e., w/ mal), and FedAVG without malicious clients
(i.e., w/o mal). We observe that FedAVG w/ Block significantly outperforms
FedAVG w/ mal, while being comparable with FedAVG w/o mal, the performance
upper bound under this setup.

###  5.1 Experimental Setup

We first evaluate the proposed framework in a simulated environment.

####  5.1.1 Data and Task

We consider a standard binary classification task, namely loan default
prediction. We use the Kaggle Lending Club
dataset444https://www.kaggle.com/datasets/wordsforthewise/lending-club to
simulate a realistic financial application scenario. We pre-process the raw
dataset by dropping all entries with missing values. For the labels, we only
keep “Fully Paid” and “Charged Off” to simplify the task as a binary
classification task. We randomly select $80\%$ of the data as the training set
and use the rest of the data as the test set. The training set is split into
$K$ subsets of equal size and distributed across $K$ clients. Within each
client, $20\%$ of the local data are randomly selected as the validation set.

####  5.1.2 Implementation

There are $K=50$ clients in the system and each client is initialized with 64
tokens. We use a 3-layer multi-layer perceptron (MLP) as the network backbone.
Apart from the last layer, each layer of the MLP has 128 hidden nodes. We use
a standard Adam [46] optimizer with fixed learning rate $10^{-3}$ and batch
size 128. No data augmentation is applied. We use the binary accuracy as both
the local validation score and evaluation metric. In our experiments,
malicious clients are randomly selected before the training according to the
ratio $\eta$. In each training round, if a malicious client is selected as the
proposer or voter, it will act maliciously as described in Sec. 4.555If a
malicious client acts honestly, then it will be considered as an honest one
and makes no harm to the system. We consider a simple data poisoning attack
[14], where malicious clients are trained to confuse the model. Specifically,
the local models are trained to lower the model performance by using the wrong
labels, but maintaining a low weight divergence from the aggregated weights
from the last round. All baselines are implemented in PyTorch 1.12.1 [47] on
one NVIDIA Tesla T4 GPU. We leverage Ethereum smart contracts to deploy our
reward-and-slash design in a private blockchain and simulate the training
process using the Python library
Web3.py666https://web3py.readthedocs.io/en/v5/. We set $\epsilon=0.05$ based
on empirical experience.777We notice that too small $\epsilon$ can cause large
oscillation, which slows the convergence, and too large $\epsilon$ can
facilitate the convergence at the expense of decreased detection performance,
_i.e. missing_ the system fails to remove the majority of malicious clients.

####  5.1.3 Baselines

So far, there is no such blockchain-based FL baseline suitable for the
comparative evaluation of counteracting malicious behaviors in our problem
setting. It is worth mentioning that the proposed framework can be integrated
with the existing FL method. In our experiments, we use FedAVG as the backbone
FL method to illustrate our defending mechanism. We consider 4 baselines. The
first one is an _Oracle_ approach, a centralized baseline without malicious
attacks. The _Oracle_ should provide the upper-bound performance of the
experiment. The second one is FedAVG without malicious attacks (denoted as
FedAVG w/o mal), which is equivalent to FedAVG under $\eta=0$ and should
provide the upper-bound performance for a decentralized environment. The third
one is FedAVG under malicious attacks (denoted as FedAVG w/ mal), where $\eta$
of clients are malicious. The fourth one is the proposed method, FedAVG with
blockchain under malicious attacks (denoted as FedAVG w/ block). For FL
baselines, $10\%$ of clients are randomly selected to perform local training
at each epoch. For FedAVG w/ block, we simply use the remaining $90\%$ of the
clients as voters.

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 6: Token distribution results for clients when setting the parameter
for slashing proposers as $\gamma_{p}=8$. The expected average token of
malicious proposers fluctuates down during the training process.

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.4.

(c) $\eta$ = 0.1.

(d) $\eta$ = 0.4.

Figure 7: (a)-(b) Number of award and slash epochs for clients when setting
the parameter for slashing proposers as $\gamma_{p}=8$. (c)-(d) The number of
slash epochs increases when the number of malicious proposers increases.

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 8: Token distribution results for malicious clients when choosing
$\gamma_{p}=2,4,8,16,$ and $32$. The expected average token of malicious
proposers exhibits a higher rate of decrease when a large value of
$\gamma_{p}$ is selected.

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 9: Token distribution results for honest clients when choosing
$\gamma_{p}=2,4,8,16,$ and $32$. The expected average token of honest
proposers displays a higher rate of growth when a large value of $\gamma_{p}$
is selected.

###  5.2 Results

####  5.2.1 Empirical Analysis on Malicious Voters

To empirically validate the theoretical result in Sec. 4.5, we first simulate
a hypothetical scenario where there are only honest proposers. As there are
more honest proposers than malicious proposers at each round on average, the
effect of malicious weights can be seen as slowing the convergence and
decreasing the global performance, which will be validated in Sec. 5.1.3.
Here, we further simplify the scenario to focus on the behavior of malicious
voters. As shown in Fig. 4, given the set of the hyperparameter for slashing
voters $\gamma_{r}=\\{2,4,8,16,32\\}$, the malicious voters will be eliminated
from the system shortly (_i.e. missing_ their average tokens decline to $0$
within $\approx 40$ epochs).

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 10: Malicious proposers survival time with various $\gamma_{p}$. The
expected survival time of malicious proposers declines as $\gamma_{p}$
increases.

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 11: Honest proposers survival time with various $\gamma_{p}$. A large
$\gamma_{p}$ can also decrease the expected survival time of honest proposers
when the malicious rate $\eta$ is large. This is because, in each epoch, the
randomly selected proposers will be all slashed when the performance of the
aggregated global model does not increase.

(a) $\eta$ = 0.1.

(b) $\eta$ = 0.2.

(c) $\eta$ = 0.3.

(d) $\eta$ = 0.4.

Figure 12: Global accuracy results when choosing $\gamma_{p}=2,4,8,16,$ and
$32$. The global accuracy is not sensitive to the value of $\gamma_{p}$ but
the convergence tasks more epochs for larger $\eta$.

####  5.2.2 Comparison with Baselines

Following Theorem 1 and Sec. 5.2.1, we now are certain that there will be no
de facto malicious voters. Thus, in the following experiments, we focus on the
scenarios where malicious clients only upload harmful weights but make honest
votes. We evaluate the proposed framework against the baselines described in
Sec. 5.1.3. We provide the learning curves in Fig. 5 and the accuracy for all
four approaches after convergence (the mean accuracy of the last 50 epochs) in
Tab. 3. The performance of FedAVG w/ block is competitive with FedAVG w/o mal
(_i.e. missing_ $\eta=0$) and consistently outperforms FedAVG w/ mal. As
$\eta$ increases, the performance of FedAVG w/ mal decreases significantly,
with a larger standard deviation and increased instability. In contrast,
FedAVG w/ block maintains robust performance, with only slightly lower results
compared to FedAVG w/o mal.

####  5.2.3 Analysis of Token Distributions

Fig. 6 depicts the average tokens remaining in honest and malicious proposers
during the FL training process when $\gamma_{p}=8$. We observe that honest
proposers gradually accumulate more tokens while malicious proposers own fewer
tokens as training progresses. Eventually, most malicious proposers lose the
eligibility to participate in staking and are removed from the FL system, as
their remaining tokens are insufficient. Looking more closely at the case
where few malicious proposers are in the system (Fig. 6(a)), we note that
proposals are initially accepted until a revert and slash step is performed
around epoch 32 (indicated by the sudden drop in tokens for malicious
proposers). As more malicious proposers are in the system (Fig. 6(d)), revert
and slash steps occur more frequently. This is further highlighted by Fig.
7(a) and 7(b), which demonstrates for each epoch if it corresponds to an award
or a revert and slash step. Fig. 7(c) and 7(d) further provide the cumulative
sum over the number of award and slash epochs, illustrating that the majority
of the epochs consist of award epochs and that the fraction of revert and
slash episodes increases with the rising fraction of malicious proposers.
Finally, we depict the average tokens remaining in honest and malicious
proposers under various configurations of $\gamma_{p}$ in Fig. 8 and Fig. 9.
We observe the same phenomenon as Fig. 6, which aligns with the expectations
of our system design and reinforces the effectiveness of our approach.

####  5.2.4 Survival Analysis of Clients

As shown in Fig. 10, the anticipated survival time of malicious proposers
experiences a decrease as $\gamma_{p}$ increases. This effect can be
attributed to the incentive mechanism in place, whereby a higher value of
$\gamma_{p}$ results in a greater penalty for proposers who act maliciously.
Fig. 11 shows the survival time of honest proposers under different values of
$\gamma_{p}$ and exhibits noteworthy behavior. In cases where the malicious
ratio $\eta$ is high, the expected survival time of honest proposers may
decrease with a large $\gamma_{p}$. This is due to the fact that, in each
epoch, all randomly selected proposers will be slashed if the performance of
the aggregated global model does not show improvement. Therefore, it is worth
noting that balancing the token slashing parameter $\gamma_{p}$ is crucial,
because setting an excessively high value can harm honest proposers, whereas a
small value can lead to slow convergence (see Fig. 12).

####  5.2.5 Sensitivity to Malicious Client Ratio

The results presented in Fig. 5 demonstrate the robustness of our proposed
method, FedAVG w/ block, against different malicious client ratios, as its
performance remains unaffected even under large $\eta$ values. However, it is
important to note that the malicious client ratio can impact the token
distribution and survival time of clients. Specifically, when there are more
malicious clients present in the system, honest clients tend to accumulate
more assets on average (_c.f_. Fig. 9(a) \- 9(d)). Nevertheless, they also
face a higher risk of being slashed during an epoch, which can ultimately
shorten their survival time (_c.f_. Fig. 11(a) \- 11(d)).

####  5.2.6 Limitations

In this work, as the experimental results aim to evaluate the robustness of
the proposed framework, several practical challenges are simplified, _e.g.
missing_ staleness [48], storage, and privacy [44]. Further, the proposed
method requires more computational power than traditional methods due to
mining (blockchain computing) and voting. Finally, large models have gained in
popularity in practical applications, _e.g. missing_ ViT [49] and GPT-3 [50].
This raises the question of how to efficiently handle on-chain aggregation for
large models. Future work thus will aim to address these limitations to
facilitate the research and development of FL with blockchain.

###  5.3 Cost Analysis

In our experiments, we adopt the Kaggle Lending Club
dataset888https://www.kaggle.com/datasets/wordsforthewise/lending-club to
simulate a realistic financial application scenario. The total client number
is $K=50$. For each client, the generated model update file is with a size of
$587$KB. Therefore, the communication cost incurred by a proposer or a voter
is $587$KB and the storage cost on the blockchain is $587\times 50$KB
$=28.66$MB.

##  6 Additional Experiments

In Sec. 5, we examine the performance of the proposed system on a simple
learning task on IID data. In this section, we further evaluate the robustness
of the proposed system with a more complex task on non-IID data.

(a) $\eta=0.1$ (b) $\eta=0.2$ (c) $\eta=0.3$ (d) $\eta=0.4$

Figure 13: Federated training under different values of ratio of malicious
clients ($\eta$). The solid lines are the mean AUROCs and the shaded regions
are 1 standard deviation around the means. Table 4: Performance comparison
under different values of ratio of malicious clients ($\eta$). The reported
numbers are mean and standard deviation under 5 random seeds.

Model | $\eta=0.1$ | $\eta=0.2$ | $\eta=0.3$ | $\eta=0.4$
---|---|---|---|---
FA w/ M | $0.677\pm 0.014$ | $0.640\pm 0.012$ | $0.594\pm 0.030$ | $0.483\pm 0.080$
FA w/ B | $0.683\pm 0.008$ | $0.688\pm 0.024$ | $0.676\pm 0.023$ | $0.673\pm 0.021$
FA w/o M | $0.695\pm 0.004$ | $0.695\pm 0.004$ | $0.695\pm 0.004$ | $0.695\pm 0.004$
_Oracle_ | $0.733\pm 0.014$ | $0.733\pm 0.014$ | $0.733\pm 0.014$ | $0.733\pm 0.014$

###  6.1 Experimental Setup

####  6.1.1 Data and Task

We consider a standard multi-label classification (MLC) task [51] to simulate
a realistic clinical application scenario. We use the ChestX-
ray14999https://nihcc.app.box.com/v/ChestXray-NIHCC dataset [20] and leverage
the first $6{\times}10^{4}$ chest X-ray images (CXRs) as our non-IID dataset.
We use $80\%$ of the data as the training set and use the rest of the data as
the test set. The training set is split into $K$ subsets of equal size and
distributed across $K$ clients in a non-IID fashion. Within each client,
$20\%$ of local data are randomly selected as the validation set. Because
ChestX-ray14 has a long-tailed label distribution, we choose the 10 most
common diseases to ensure that each client can contain labels for all diseases
of interest.

####  6.1.2 Implementation

There are $K=50$ clients in the system and each client is initialized with 64
tokens. Following [51], we use DenseNet121 [52] as the network backbone. We
use a standard Adam [46] optimizer with fixed learning rate $10^{-3}$ and
batch size 256. We process each CXR with instance normalization [53] and no
data augmentation is applied. We use the mean area under the receiver
operating characteristic curve over the 10 diseases as both the local
validation score and evaluation metric. We set $\epsilon=0.05$ and $\gamma=32$
based on empirical experience. The rest of the implementation details follow
Sec. 5.1.2.

####  6.1.3 Baselines

We consider the same four baselines as in Sec. 5.1.3.

###  6.2 Results

We run each baseline with 5 random seeds and report both mean and standard
deviation under different values of $\eta$. The training results are
visualized in Fig. 13.

####  6.2.1 Performance Comparison

FedAVG w/ block shows competitive performance with FedAVG w/o mal (_i.e.
missing_ $\eta=0$) and outperforms FedAVG w/ mal consistently. In addition to
the learning curves in Fig. 13, we also report the mean AUROCs for all 4
methods after they fully converge in Tab. 4. When $\eta$ increases, the
performance of FedAVG w/ mal drops significantly and becomes more unstable
(_i.e. missing_ larger standard deviation). FedAVG w/ block remains robust
performance and is only slightly lower than FedAVG w/o mal.

####  6.2.2 Convergence Analysis

It can be shown that FedAVG w/ block converges faster than both FedAVG w/o mal
and FedAVG w/ mal under various values of $\eta$. We hypothesize that the
proposed global aggregation mechanism can facilitate federated optimization.
Intuitively, this can be explained with gradient descent. FedAVG averages
gradients optimized for different directions at different clients, which might
not be an optimal global gradient. Under malicious attacks, gradients from
malicious clients are intentionally optimized away from the optimal direction,
which slows down the training process of FedAVG. However, the proposed
consensus mechanism mitigates this issue as it only aggregates when consensus
is achieved.

Figure 14: Tokens of honest and malicious clients when $\eta=0.3$ and
$\gamma=32$.

####  6.2.3 Token Analysis

As we use tokens to filter out malicious clients, we plot the average tokens
left in honest and malicious clients (_e.g. missing_ Fig. 14). After enough
training epochs, honest clients will have more tokens and malicious clients
will have fewer tokens. At the end of training, almost all malicious clients
do not have enough tokens to stake, _i.e. missing_ they are removed from the
FL system. It is worth mentioning that $\gamma$ has only trivial effect on the
learning performance but large $\gamma$ can overkill honest clients and small
$\gamma$ can cause slow convergence.

####  6.2.4 Impact of Non-IID Data

Due to the non-IID nature of the medical task, the task setup in this section
is more complex than the binary classification task in the previous section.
In contrast to Sec. 5, there are two important findings. First, the proposed
method is robust under the non-IID setup. Second, surprisingly, while the task
is more difficult, the performance gain between the proposed method and the
baselines becomes larger.

##  7 Conclusion

In this work, we explore an under-explored research direction, namely using FL
and blockchain to defend against poisoning attacks. The defense mechanism is
twofold. We use on-chain smart contracts to replace the traditional central
server and propose a stake-based majority voting mechanism to detect client-
side malicious behaviors. We not only provide a solution to the problem of
interest, but also show the robustness of the proposed method and provide the
first empirical understanding of the problem. Last but not least, the results
of this work suggest that the integration of FL and blockchain is an emerging
solution to trustworthy ML. We believe that blockchain can not only play an
important role in decentralization and the incentivization of participants for
real-world FL applications in fields such as finance and medicine, but also
can be leveraged to defend against poisoning attacks.

## Acknowledgment

The authors would like to thank Shuoying Zhang from FLock.io and Shuhao Zheng
from the School of Computer Science, McGill University for the helpful
discussion. The authors would also like to thank Yizhe Wen and Xinyang Wang
from FLock.io for the experimental simulation.

## References

  * [1] K. He, X. Zhang, S. Ren, and J. Sun, “Deep residual learning for image recognition,” in _CVPR_ , 2016, pp. 770–778.
  * [2] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, Ł. Kaiser, and I. Polosukhin, “Attention is all you need,” in _NIPS_ , vol. 30, 2017, pp. 6000–6010.
  * [3] V. Mnih, K. Kavukcuoglu, D. Silver, A. A. Rusu, J. Veness, M. G. Bellemare, A. Graves, M. Riedmiller, A. K. Fidjeland, G. Ostrovski _et al._ , “Human-level control through deep reinforcement learning,” _Nature_ , vol. 518, no. 7540, pp. 529–533, 2015.
  * [4] European Commission, “General data protection regulation,” 2016. [Online]. Available: https://ec.europa.eu/info/law/law-topic/data-protection/data-protection-eu_en
  * [5] US Department of Health and Human Services, “Health insurance portability and accountability act,” 2017. [Online]. Available: https://www.cdc.gov/phlp/publications/topic/hipaa.html
  * [6] B. McMahan, E. Moore, D. Ramage, S. Hampson, and B. A. y Arcas, “Communication-efficient learning of deep networks from decentralized data,” in _AISTATS_. PMLR, 2017, pp. 1273–1282.
  * [7] M. Li, D. G. Andersen, A. J. Smola, and K. Yu, “Communication efficient distributed machine learning with the parameter server,” in _NIPS_ , 2014, pp. 19–27.
  * [8] Y. Qu, M. P. Uddin, C. Gan, Y. Xiang, L. Gao, and J. Yearwood, “Blockchain-enabled federated learning: A survey,” _ACM Computing Surveys_ , vol. 55, no. 4, pp. 1–35, 2022.
  * [9] G. Wood, “Ethereum: A secure decentralised generalised transaction ledger,” _Ethereum Project Yellow Paper_ , vol. 151, pp. 1–32, 2014.
  * [10] X. Chen, J. Ji, C. Luo, W. Liao, and P. Li, “When machine learning meets blockchain: A decentralized, privacy-preserving and secure design,” in _IEEE International Conference on Big Data_. IEEE, 2018, pp. 1178–1187.
  * [11] L. Soltanisehat, R. Alizadeh, H. Hao, and K.-K. R. Choo, “Technical, temporal, and spatial research challenges and opportunities in blockchain-based healthcare: A systematic literature review,” _IEEE Transactions on Engineering Management_ , 2020.
  * [12] M. M. Queiroz, R. Telles, and S. H. Bonilla, “Blockchain and supply chain management integration: a systematic review of the literature,” _Supply Chain Management: An International Journal_ , vol. 25, no. 2, pp. 241–254, 2020\.
  * [13] Y. Li, C. Chen, N. Liu, H. Huang, Z. Zheng, and Q. Yan, “A blockchain-based decentralized federated learning framework with committee consensus,” _IEEE Network_ , vol. 35, no. 1, pp. 234–241, 2021.
  * [14] E. Bagdasaryan, A. Veit, Y. Hua, D. Estrin, and V. Shmatikov, “How to backdoor federated learning,” in _AISTATS_ , vol. 108. PMLR, 2020, pp. 2938–2948.
  * [15] V. Tolpegin, S. Truex, M. E. Gursoy, and L. Liu, “Data poisoning attacks against federated learning systems,” in _ESORICS_ , 2020, pp. 480–501.
  * [16] Y. Miao, Z. Liu, H. Li, K.-K. R. Choo, and R. H. Deng, “Privacy-preserving byzantine-robust federated learning via blockchain systems,” _IEEE Transactions on Information Forensics and Security_ , vol. 17, pp. 2848–2861, 2022\.
  * [17] A. P. Kalapaaking, I. Khalil, and X. Yi, “Blockchain-based federated learning with smpc model verification against poisoning attack for healthcare systems,” _IEEE Transactions on Emerging Topics in Computing_ , 2023.
  * [18] S. Bano, A. Sonnino, M. Al-Bassam, S. Azouvi, P. McCorry, S. Meiklejohn, and G. Danezis, “Sok: Consensus in the age of blockchains,” in _ACM Conference on Advances in Financial Technologies_ , 2019, pp. 183–198.
  * [19] Wikipedia, “The resistance (game),” accessed: 2023-02-12. [Online]. Available: https://en.wikipedia.org/wiki/The_Resistance_(game)
  * [20] X. Wang, Y. Peng, L. Lu, Z. Lu, M. Bagheri, and R. M. Summers, “Chestx-ray8: Hospital-scale chest x-ray database and benchmarks on weakly-supervised classification and localization of common thorax diseases,” in _CVPR_ , 2017, pp. 2097–2106.
  * [21] X. Yan, Y. Miao, X. Li, K.-K. Raymond, X. Meng, and R. H. Deng, “Privacy-preserving asynchronous federated learning framework in distributed iot,” _IEEE Internet of Things Journal_ , 2023.
  * [22] L. Cui, Y. Qu, G. Xie, D. Zeng, R. Li, S. Shen, and S. Yu, “Security and privacy-enhanced federated learning for anomaly detection in iot infrastructures,” _IEEE Transactions on Industrial Informatics_ , vol. 18, no. 5, pp. 3492–3500, 2021.
  * [23] K. Toyoda and A. N. Zhang, “Mechanism design for an incentive-aware blockchain-enabled federated learning platform,” in _IEEE International Conference on Big Data_. IEEE, 2019, pp. 395–403.
  * [24] J. Zhang, Y. Wu, and R. Pan, “Incentive mechanism for horizontal federated learning based on reputation and reverse auction,” in _Proceedings of the Web Conference 2021_ , 2021, pp. 947–956.
  * [25] C. Ma, J. Li, L. Shi, M. Ding, T. Wang, Z. Han, and H. V. Poor, “When federated learning meets blockchain: A new distributed learning paradigm,” _IEEE Computational Intelligence Magazine_ , vol. 17, no. 3, pp. 26–33, 2022\.
  * [26] Y. Qu, C. Xu, L. Gao, Y. Xiang, and S. Yu, “Fl-sec: Privacy-preserving decentralized federated learning using signsgd for the internet of artificially intelligent things,” _IEEE Internet of Things Magazine_ , vol. 5, no. 1, pp. 85–90, 2022.
  * [27] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
  * [28] J. Garay and A. Kiayias, “Sok: A consensus taxonomy in the blockchain era,” in _Topics in Cryptology–CT-RSA 2020: The Cryptographers’ Track at the RSA Conference 2020, San Francisco, CA, USA, February 24–28, 2020, Proceedings_. Springer, 2020, pp. 284–318.
  * [29] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “Sok: Research perspectives and challenges for bitcoin and cryptocurrencies,” in _2015 IEEE Symposium on Security and Privacy_. IEEE, 2015, pp. 104–121.
  * [30] V. Gatteschi, F. Lamberti, C. Demartini, C. Pranteda, and V. Santamaría, “Blockchain and smart contracts for insurance: Is the technology mature enough?” _Future Internet_ , vol. 10, no. 2, p. 20, 2018.
  * [31] J. Bao, D. He, M. Luo, and K.-K. R. Choo, “A survey of blockchain applications in the energy sector,” _IEEE Systems Journal_ , vol. 15, no. 3, pp. 3370–3381, 2020.
  * [32] A. Reyna, C. Martín, J. Chen, E. Soler, and M. Díaz, “On blockchain and its integration with iot. challenges and opportunities,” _Future Generation Computer Systems_ , vol. 88, pp. 173–190, 2018.
  * [33] P. Kairouz, H. B. McMahan, B. Avent, A. Bellet, M. Bennis, A. N. Bhagoji, K. Bonawitz, Z. Charles, G. Cormode, R. Cummings _et al._ , “Advances and open problems in federated learning,” _Foundations and Trends® in Machine Learning_ , vol. 14, no. 1–2, pp. 1–210, 2021\.
  * [34] Y. Wan, Y. Qu, W. Ni, Y. Xiang, L. Gao, and E. Hossain, “Data and model poisoning backdoor attacks on wireless federated learning, and the defense mechanisms: A comprehensive survey,” _arXiv preprint arXiv:2312.08667_ , 2023\.
  * [35] H. Zhang, S. Jiang, and S. Xuan, “Decentralized federated learning based on blockchain: concepts, framework, and challenges,” _Computer Communications_ , vol. 216, pp. 140–150, 2024.
  * [36] J. Zhu, J. Cao, D. Saxena, S. Jiang, and H. Ferradi, “Blockchain-empowered federated learning: Challenges, solutions, and future directions,” _ACM Computing Surveys_ , vol. 55, no. 11, pp. 1–31, 2023.
  * [37] H. Kim, J. Park, M. Bennis, and S.-L. Kim, “Blockchained on-device federated learning,” _IEEE Communications Letters_ , vol. 24, no. 6, pp. 1279–1283, 2019.
  * [38] J. Weng, J. Weng, J. Zhang, M. Li, Y. Zhang, and W. Luo, “Deepchain: Auditable and privacy-preserving deep learning with blockchain-based incentive,” _IEEE Transactions on Dependable and Secure Computing_ , vol. 18, no. 5, pp. 2438–2455, 2019.
  * [39] D. C. Nguyen, M. Ding, Q.-V. Pham, P. N. Pathirana, L. B. Le, A. Seneviratne, J. Li, D. Niyato, and H. V. Poor, “Federated learning meets blockchain in edge computing: Opportunities and challenges,” _IEEE Internet of Things Journal_ , vol. 8, no. 16, pp. 12 806–12 825, 2021.
  * [40] M. Ali, H. Karimipour, and M. Tariq, “Integration of blockchain and federated learning for internet of things: Recent advances and future challenges,” _Computers & Security_, vol. 108, p. 102355, 2021.
  * [41] D. Li, D. Han, T.-H. Weng, Z. Zheng, H. Li, H. Liu, A. Castiglione, and K.-C. Li, “Blockchain for federated learning toward secure distributed machine learning systems: a systemic survey,” _Soft Computing_ , vol. 26, no. 9, pp. 4423–4440, 2022.
  * [42] N. Dong, M. Kampffmeyer, I. Voiculescu, and E. Xing, “Federated partially supervised learning with limited decentralized medical images,” _IEEE TMI_ , 2022.
  * [43] N. Dong, M. Kampffmeyer, and I. Voiculescu, “Learning underrepresented classes from decentralized partially labeled medical images,” in _MICCAI_. Springer, 2022, pp. 67–76.
  * [44] M. Abadi, A. Chu, I. Goodfellow, H. B. McMahan, I. Mironov, K. Talwar, and L. Zhang, “Deep learning with differential privacy,” in _ACM SIGSAC Conference on Computer and Communications Security_ , 2016, pp. 308–318.
  * [45] I. J. Goodfellow, J. Shlens, and C. Szegedy, “Explaining and harnessing adversarial examples,” _arXiv preprint arXiv:1412.6572_ , 2014.
  * [46] D. P. Kingma and J. Ba, “Adam: A method for stochastic optimization,” in _ICLR_ , 2015.
  * [47] A. Paszke, S. Gross, F. Massa, A. Lerer, J. Bradbury, G. Chanan, T. Killeen, Z. Lin, N. Gimelshein, L. Antiga _et al._ , “Pytorch: An imperative style, high-performance deep learning library,” in _NIPS_ , vol. 32, 2019\.
  * [48] W. Dai, Y. Zhou, N. Dong, H. Zhang, and E. Xing, “Toward understanding the impact of staleness in distributed machine learning,” in _ICLR_ , 2019.
  * [49] A. Dosovitskiy, L. Beyer, A. Kolesnikov, D. Weissenborn, X. Zhai, T. Unterthiner, M. Dehghani, M. Minderer, G. Heigold, S. Gelly _et al._ , “An image is worth 16x16 words: Transformers for image recognition at scale,” in _ICLR_ , 2021.
  * [50] T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell _et al._ , “Language models are few-shot learners,” in _NIPS_ , vol. 33, 2020, pp. 1877–1901.
  * [51] P. Rajpurkar, J. Irvin, K. Zhu, B. Yang, H. Mehta, T. Duan, D. Ding, A. Bagul, C. Langlotz, K. Shpanskaya _et al._ , “Chexnet: Radiologist-level pneumonia detection on chest x-rays with deep learning,” _arXiv preprint arXiv:1711.05225_ , 2017.
  * [52] G. Huang, Z. Liu, L. Van Der Maaten, and K. Q. Weinberger, “Densely connected convolutional networks,” in _CVPR_ , 2017, pp. 4700–4708.
  * [53] W. Dai, N. Dong, Z. Wang, X. Liang, H. Zhang, and E. P. Xing, “Scan: Structure correcting adversarial network for organ segmentation in chest x-rays,” in _Deep Learning in Medical Image Analysis and Multimodal Learning for Clinical Decision Support_ , 2018, pp. 263–273.