1,2]Department of Mathematics and Computer Science, Sri Sathya Sai Institute
of Higher Learning, Street, Puttaparthi, 515134, Andhrapradesh, India

# FLoW3 - Web3 Empowered Federated Learning

Venkata Raghava Kurada<EMAIL_ADDRESS>Pallav Kumar Baruah
<EMAIL_ADDRESS>[

###### Abstract

Federated Learning is susceptible to various kinds of attacks like Data
Poisoning, Model Poisoning and Man in the Middle attack. We perceive Federated
Learning as a hierarchical structure, a federation of nodes with validators as
the head. The process of validation is done through consensus by employing
Novelty Detection and Snowball protocol, to identify valuable and relevant
updates while filtering out potentially malicious or irrelevant updates, thus
preventing Model Poisoning attacks. The opinion of the validators is recorded
in blockchain and trust score is calculated. In case of lack of consensus,
trust score is used to determine the impact of validators on the global model.
A hyperparameter is introduced to guide the model generation process, either
to rely on consensus or on trust score. This approach ensures transparency and
reliability in the aggregation process and allows the global model to benefit
from insights of most trusted nodes. In the training phase, the combination of
IPFS , PGP encryption provides : a) secure and decentralized storage b)
mitigates single point of failure making this system reliable and c) resilient
against man in the middle attack. The system is realized by implementing in
python and Foundry for smart contract development. Global Model is tested
against data poisoning by flipping the labels and by introducing malicious
nodes. Results found to be similar to that of Flower.

###### keywords:

Federated Learning, Novelty Detection, Snowball Consensus Protocol, Web3
Technology

##  1 Introduction

There is a steep increase in the usage of the various wearable devices,
spanning from smartphones to smartwatches, that generates data which is quite
sensitive and private in nature. This data can be used to train machine
learning models and improve the performance. Transferring this data, over the
internet, to a datacenter raises concerns about data security and privacy.
This has driven the advent of Federated Learning[1]. Federated Learning faces
challenges from various attacks like Man in the middle attack, lack of
transparency and decision making power to the participating entities.

There are stringent data protection laws like GDPR [2] , Digital CCPA[3], DPDP
Act[4], that enforces a wide variety of restrictions while processing and
storing of the data. The synergy of the AI and Federated Learning is a
promising path to develop privacy centric machine learning models and enables
models to leverage on data while preserving the privacy. In this paper, we
demonstrate a way to fulfil this promise.

Federated Learning, is a machine learning paradigm where all the nodes are
arranged in a star topology with a central server and various edge devices
(nodes) connected to it. The central server will send the initial global model
to all the nodes. Upon receiving this model, the nodes will train the model on
the data that is locally available with the on-device hardware. After training
the model, the nodes send the model updates to the central server. The central
server will then implement a Federated Aggregation algorithm, thus creating a
new global model. This process repeats until the model converges.

There are works [5][6] demonstrating the feasibly preserving data privacy in
federated learning using security measures like Differential Privacy [7],
Homomorphic Encryption [8] Federated learning is widely used in different
domains ranging from health care to image classification on unlabelled data
[9] [10] [11]. Often times this type of setup is controlled by a single
organization in an isolated environment. There is a need for the decentralized
platform, one that can effectively enable Federated Learning to be adopted
widely. This platform should empower participants with a transparent decision-
making process and incentivise the participants for the active involvement of
the users.

Web3 [12] technology is a suite of distributed technologies like Blockchain
[13], Inter Planetary File System (IPFS) [14], Cryptocurrencies, Smart
Contract[15]. Instead of relying on central authorities to control and manage
user data, Web3 aims to distribute control among a network of participants. It
envisions the process of giving control back to the user. The blockchain
ensures transparency and trust, while storage is facilitated by various
distributed storage built on IPFS. This suite of technology relies on
distributed computing capability of its nodes to cater its computation needs.

Snowball Protocol[16] is a leaderless, probabilistic consensus protocol that
is scalable in nature. It is efficient in terms of communication, where each
node is required to communicate with a constant number of nodes, contributing
to its low overhead. These attributes make Snowball protocol a suitable choice
for the proposed platform.

Main contributions of this work are:

  * •

Design and implementation of federated learning system in decentralized way by
introducing a hierarchy between the nodes

  * •

Considering Federated Learning from a consensus prospect, bringing
transparency in the decision-making process.

  * •

Blockchain based trust calculation solution as a foolproof mechanism to
generate the model.

##  2 Literature Review

Federated learning was initially proposed by McMahain et al[1]. Konečný et
al[17] proposed a set of optimizations on representation of weights to reduce
the communication in federated learning setup. The process of Federated
Learning is susceptible to Data Poisoning Attack, Gradient Leakage Attacks, as
discussed in [18] [19]. In order to make the federated learning a successful
participatory platform, we need to have a profitable design. Xu et.al[20]
proposes a time based auction procedure that will be economically profitable
to both users and platform owners.

While [21][22][23] proposes to use the blockchain in order to tackle these
attacks, Kim et al[24] proposed BlockFL architecture where the model updates
were exchanged and verified, the work also performs the end to end latency
model of BlockFL.

Differential Privacy introduces carefully calibrated noise to individual data
points before aggregation on the other hand, Homomorphic encryption enables
the required computations to be performed on the encrypted data, thus enabling
the compliances with the mentioned acts. In this work, we primarily focus on
designing a platform that relies on Web3 technologies to implement Federated
Learning in a transparent and hierarichal manner with privacy as a key factor.

###  2.1 Blockhain

Blockchain[13] was initially proposed by Satoshi Nakamoto. It is a
decentralized and distributed system that is immutable in nature. Blockchain
is constituted by blocks, which stores a set of transactions. Once a block is
full, the hash of the current block is stored in its successive block. If a
content of a previous block is modified, the change will be propagated via
hash through all blocks, thus facilitating a tamper proof mechanism.

Ethereum[15] with Ether as its native token, is one of the popular public
blockchain networks that was initially proposed by Valtamir Butanik. With the
introduction of the Smart Contract[15], the Ethereum blockchain has
transformed into a Turing complete machine. These Smart Contracts enable the
user to, programmatically, create a set of rules that can be executed on the
blockchain. Smart contracts, developed using Solidity, are utilized in various
fields such as supply chain management [25] and finance [26] to streamline
processes and ensure secure and transparent transactions.

###  2.2 Novelty Detection

Novelty detection[27] refers to the process of identification of abnormal
patterns that are present in huge amounts of normal data. In this case, the
emphasis is more on detecting whether an unseen observation is an outlier or a
novelty. Furthermore, the main idea is to learn the definition of the
”normality” by training a model on multiple positive instances that are not
anomalies. Based on the prediction of this trained model, a score is given to
an unseen observation. This score is then compared with the decision
threshold, thus determining the novelty of the observation. According to Marco
A.F. Pimente [27] the novelty detection can be classified in the following
types:

  * •

Probabilistic Novelty Detection: A type of novelty detection algorithms that
are based on the estimation of the generative probability density function of
the data. A threshold is imposed on the resultant distribution for novelty.
Based on which, a given point is classified as novelty or anomaly.

  * •

Distance Based Novelty Detection: In this type of algorithms, novelty of a
particular record is identified based on the distance by using various
clustering algorithms. Greater the distance from its neighbours, higher the
chances of being a anomaly.

  * •

Reconstruction Based Novelty Detection: In this type of novelty detection, a
model of the given normal data is created. This model is later used to create
or reconstruct new instances of data. The difficulty of reconstructing a new
data record is considered as metric. Higher the difficulty to generate the
data point, greater the chances of considering it as anomaly. Auto encoders
and PCA are widely used in this type of novelty detection

The proposed platform uses Local Outlier Factor[28] algorithm for novelty
detection.

###  2.3 Snowball Protocol

Snowball Protocol[16], is a leaderless Byzantine fault tolerance protocol from
the Snow family. Snowball is a single decree binary consensus protocol, that
is highly scalable and probabilistic in nature. This consensus protocol is
based on the meta stability and network subsampling, i.e. repeatedly polling a
random subset of participants to attain consensus. This concept of network
subsampling perturbs the conflicting, thus causing one of the decisions to
gain advantage over another decision. Unlike traditional consensus protocol,
there is no need for each node to acquire the accurate knowledge of the
participant of the decision-making process. A modified version of the snowball
protocol in synergy with Direct Acyclic graph is used in Avalanche[29]
blockchain as a consensus mechanism. The Snow Family of protocols are
quiescent and energy efficient as they do not require constant participation
of nodes when there is no decision-making process, unlike Proof of Work [13].

Algorithm 1 Snowball Protocol

1:function Snowball

2: $\text{decision1}\leftarrow 0,\text{decision2}\leftarrow 1$

3: $\text{prev\\_decision}\leftarrow 0,\text{count}\leftarrow 0$

4: $\text{confidence\\_counter}\leftarrow[0,0]$

5: $\text{decided}\leftarrow\text{false}$

6: $\text{final\\_decision}\leftarrow\text{NONE}$

7: while $\text{decided}\neq\text{true}$ do

8: $\text{opinion}\leftarrow\text{get opinion from }k\text{ peers}$

9:
$\text{confidence\\_counter}[0]\leftarrow\text{opinion.count}(\text{decision1})$

10:
$\text{confidence\\_counter}[1]\leftarrow\text{opinion.count}(\text{decision2})$

11: $\text{max\\_val}\leftarrow\text{max}(\text{confidence\\_counter})$

12:
$\text{max\\_ind}\leftarrow\text{confidence\\_counter.index}(\text{max\\_val})$

13: if $\text{max\\_val}>\alpha$ then

14: if $\text{max\\_ind}==\text{previous\\_decision}$ then

15: $\text{count}\leftarrow\text{count}+1$

16: else

17: $\text{previous\\_decision}\leftarrow\text{max\\_ind}$

18: $\text{count}\leftarrow 0$

19: end if

20: if $\text{count}\geq\beta$ then

21: $\text{decided}\leftarrow\text{true}$

22: $\text{final\\_decision}\leftarrow\text{max\\_ind}$

23: end if

24: end if

25: end while

26:end function

Snowball Protocol (Algorithm 1) has the following parameters.

  * •

Number of Nodes(N): Total number of nodes in the network that are
participating in the consensus.

  * •

Quorum Size(k): Number of nodes that are subsampled during decision-making.

  * •

Alpha($\alpha$): Minimum number of nodes required to decide the majority in a
quorum

  * •

Beta($\beta$): Minimum number of consecutive rounds in favour of a decision
required to terminate the consensus protocol.

A node taking part in the decision-making process starts in an undecided
state. Then the node proceeds to initiate a query to k nodes, thus initiating
the query process. Upon receiving a query, the undecided node will respond
with the state it received and initiate its own query. On the other hand, a
decided node will simply respond with its decision. After receiving k
responses, a node checks whether majority is found or not, using $\alpha$. If
majority is found, then the node updates the confidence counter with respect
to that specific decision. If the $\alpha$ fraction is not met, then the
confidence counter for the specific decision is reset to zero. This process
continues until one of the confidence counters reaches $\beta$.

###  2.4 Federated Learning

Federated learning[1], is a machine learning paradigm where the aim is to
create a centralized model without transmitting data to a centralized server.
Unlike conventional machine learning setting, where the data is transmitted to
a centralized server and the model training takes place in a highly controlled
environment, Federated Learning facilitates on device training of the model.

Federated Learning is arranged in a star-shaped setting, where the centralized
server is at the top, followed by the clients that train the actual model. To
enhance the privacy, instead of sending actual model weights to the
centralized server, only the model updates were sent to the centralized
server. The centralized server implements an aggregation algorithm, generally
Federation Average Algorithm, where the aggregation of the weights under a
federation is done. Based on the type of data a particular federated learning
deals with, FL can be classified into two types:

  * •

Horizontal Federated Learning: This type of federated learning is used for the
datasets which have similar features but different values. For example, “items
bought” of customer from two different stores.

  * •

Vertical Federated Learning: This type of setting is used for the data sets
which have overlapping features of the same instances. For example, data of a
particular user base in two different organizations

###  2.5 IPFS

Interplanetary Planetary File System(IPFS) [14] is a peer to peer distributed
file system that aims to connect all the nodes under the same file system.
This file system makes use of Merkel DAG to create a versioned file system and
to verify the integrity of the files. All the files in the IPFS are addressed
using unique Content Identifiers(CIDs). CIDs are constituted by the hash
function and a multicoded representing the version of the CID. SHA-1, SHA-256
or BLAKE2 are commonly used as hash functions.

As soon as a node in IPFS accesses a file or hypermedia content, it caches the
files that it downloaded, thus making it available to the other nodes in the
network. As the storage in these nodes is quite limited, this cache of the
nodes must be cleared periodically, this process is referred to as IPFS
garbage collection. Pinning is the process that ensures the data to be
accessible and prevents this garbage collection.

##  3 System Design And Architecture

In this section, we will provide an overview of the system architecture for
the proposed system, highlighting the key components and their interactions
and overall flow of the proposed model.

###  3.1 System Design

System design forms the foundation of a framework and aids in the development
of the system from its theory. The proposed system has 3 different roles
namely Node, Validator, Decentralized Aggregator arranged in hierarchical
structure as depicted in Figure 1. These are further explained in the
following section.

Figure 1: Architecture of Proposed Platform

####  3.1.1 Node

It is the basic building block of the proposed architecture. Nodes are used to
train the model with the data that is available locally. Nodes send the
encrypted model updates to Validators via IPFS.

####  3.1.2 Validator

Validator is a specialized node that oversees the process of federated
learning of the nodes in its federation. The validator computes a weighted
average of the model updates, weighted by the number of examples each node
used for training, thus creating the model. After the creation of the model,
the validator then trains a novelty detection model with the weights that are
submitted by the nodes. Later, the validator will participate in the Snowball
protocol to attain the consensus on the validity of the weights submitted by
the other validators.

####  3.1.3  Decentralized Aggregator

It is a specialized node responsible for generating of the global model. The
model generation can happen either by implementing the federated average
algorithm on accepted weights or by implementing weighted average, weighted on
influence derived from the blockchain. This node also initialises Snowball
protocol, where the validation of proposed weights occurs. From a conventional
federated learning context, a decentralized aggregator can be viewed as a
Centralized Server.

###  3.2 System Flow

Once the hierarchy, constituted by Decentralized Aggregator, Validators, and
Nodes is set up, the Decentralized Aggregator will invoke the smart contract
and collect surety from Validators. The validator will initialize the
federated learning process for its federation of nodes. After the completion
of training in the node, the weights are encrypted using the Pretty Good
Privacy (PGP)[30] encryption algorithm and uploaded to IPFS. The CID of the
uploaded file is then sent to the validator. The validator can access the
IPFS, retrieve the encrypted file, decrypt it, and obtain the decrypted
weights. The introduction of IPFS is done to prevent the man in the middle
attack as depicted in Figure 2.

Figure 2: Interaction With IPFS

At validator level, these weights were used a model using federated average
algorithm. Additionally, the validators also train their own novelty detection
models based on these weights. These novelty detection models will enable the
validators in identifying new or unusual patterns.

The weights of the model generated were then broadcast to all the validators,
where the Snowball protocol is used to attain consensus. The main goal of this
decision-making process is to determine the validity of the model generated by
a particular validator. If all the nodes reach a consensus for a specific set
of weights, then it is used in generation of the global model. The opinion of
each validator is recorded in the blockchain.

Sometimes it might happen that, by the end of the Snowball protocol, none of
the proposed weights were accepted. In this case, the global model is
generated using weighted average weighted on influence of a particular
validator. Calculation of the trust score is an important step in finding out
influence. The Algorithm 2 is used to determine the trust score.

Algorithm 2 Trust Calculation

1:function
trust_calculation($\text{final\\_opinion},\text{individual\\_opinion}$)

2: $\text{trust\\_score}\leftarrow 0,\text{count}\leftarrow 0$

3: $\text{total}\leftarrow\text{len}(\text{final\\_opinion})$

4: while $\text{count}<\text{total}$ do

5: if
$\text{final\\_opinion}[\text{count}]==\text{individual\\_opinion}[\text{count}]$
then

6: $\text{trust\\_score}\leftarrow\text{trust\\_score}+10$

7: else

8: $\text{trust\\_score}\leftarrow\text{trust\\_score}-10$

9: end if

10: $\text{count}\leftarrow\text{count}+1$

11: end while

12: return $\max(\text{trust\\_score},1)$

13:end function

Algorithm 3 Blockchain Based Validator Influence Calculation

1:Let $O_{1},O_{2},\ldots,O_{n}$ be the opinions of $V_{1},V_{2},\ldots,V_{n}$
with respect to $W_{1},W_{2},\ldots,W_{n}$.

2:Let $w_{1},w_{2},\ldots,w_{x}$ be the accepted weights.

3:Let $C$ be the opinion obtained by consensus.

4:function Validator_Influence_Calculation($C$)

5: $opinions\leftarrow[O_{1},O_{2},\ldots,O_{n}]$

6: $accepted\\_weights\leftarrow[w_{1},w_{2},\ldots,w_{x}]$

7: $trust\leftarrow[]$

8: $residual\\_trust\leftarrow[]$

9: $max\\_influence\leftarrow\frac{1}{\zeta}$

10: $shared\\_influence\leftarrow 1-(accepted\\_weights.\text{length}\times
max\\_influence)$

11: for $y$ in $opinions$ do

12: $t\leftarrow\text{trust\\_calculation}(C,y)$

13: $trust.\text{add}(t)$

14: end for

15: $influence\leftarrow\text{standardization}(trust)$

16: for $y$ in $accepted\\_weights$ do

17: $influence[\text{weights.index}[y]]\leftarrow\text{max\\_influence}$

18: end for

19: for $y$ in $trust$ do

20: $t1\leftarrow y\times\text{residual\\_influence}$

21: $\text{shared\\_influence}.\text{add}(t1)$

22: end for

23:
$\text{final\\_influence}\leftarrow\text{influence}+\text{shared\\_influence}$

24:end function

The function takes two arguments, final_opinion which corresponds to the final
decision that is made by all the nodes after implementing Snowball protocol,
the second argument corresponds to individual_opinion of each validator. This
argument is obtained from the blockchain. The opinion of each validator is
compared to the final consensus of the whole network on a particular weight.
If both are the same, the trust score is incremented, else it is decremented.
Since the weights in weighted average cannot be negative, instead of negative
trust score, a minimum value is returned.

Input:

  * •

Let $W_{1},W_{2},\ldots,W_{n}$: Weights proposed by corresponding Validators
$V_{1},V_{2},\ldots,V_{n}$ respectively.

  * •

$x$: Number of accepted weights obtained from Snowball Protocol.

  * •

$\zeta$: Threshold value set to $i$.

Output: Generated model

Algorithm:

⬇

if (x >= $\zeta$)

{

Generate final model by Averaging the Accepted Weights;

}

else

{

Generate final model based on

Blockchain Based Validator Influence;

}

Figure 3: Algorithm for Model Generation

In order to offer a better control on the process of generating the global
model, we introduce a new parameter called Minimal Consensus Index($\zeta$).
Minimal Consensus Index corresponds to the minimum number of accepted weights
required to generate the global model using the Federated Averaging Algorithm.
If the number of accepted weights is less than the $\zeta$ then the global
model is generated based on the trust score of the validators. The value of
the $\zeta$ should lie between 0 and n, where n is the total number of
validators. The higher the value of ($\zeta$), the greater the chances of
generating the model based on validator trust score.

Based on the trust score and ($\zeta$) value, the individual influence is then
calculated as follows.

  * •

Trust Score is standardized to obtain the influence.

  * •

Maximum Influence, the inverse of $\zeta$, is awarded to all the accepted
weights.

  * •

The Shared Influence is then distributed evenly among all validators.

  * •

Final Influence is obtained by summing both the Maximum Influence and the
shared influence.

  * •

A Global Model is generated using a weighted average weighted by the Final
Influence.

Algorithm 3 depicts the influence calculation workflow. The final system flow
of the proposed platform is depicted in the Fig 3.

####  3.2.1 Example

Let C be the coordinator and V1,V2,V3,V4,V5 be the validators, let $\zeta$ be
5. After completion of training in node, the validator upon receiving model
updates, implement Federated Average Algorithm and generates the weights of
the model. Let W1,W2,W3,W4 and W5 be the weights that are generated by
V1,V2,V3,V4,V5 respectively. Then the Snowball protocol is invoked. Table 1
depicts the opinion of the validators with respect to proposed weights. Where,
1 represents the acceptance of the particular weight, and 0 represents the
rejection. It is evident that W1 and W5 are the accepted weights, as all the
validators have approved these weights.

Table 1: Opinion of the Validators Validator | W1111Accepted Weights | W2 | W3 | W4 | W5111Accepted Weights
---|---|---|---|---|---
V1 | 1 | 0 | 0 | 1 | 1
V2 | 1 | 0 | 1 | 1 | 1
V3 | 1 | 1 | 0 | 0 | 1
V4 | 1 | 0 | 0 | 0 | 1
V5 | 1 | 1 | 0 | 0 | 1
C | 1 | 0 | 0 | 0 | 1
|  |  |  |  |

If $\zeta$ is set to 5. The final model is generated using Validator influence
as depicted in Table 2 1\. Trust score is normalized, as $\zeta$ is set to 5
the maximum impact of each validator will be 0.2. Since W1 and W5 were
accepted, they were awarded a weightage of 0.2. All the validators will share
the remaining influence evenly among them. The sum of these two will yield the
final validator influence, which is used as weight in the weighted average
while generating the final model. The calculations are depicted in 2 If
$\zeta$ is set to 2 or 1 then the final model is generated by averaging the
accepted weights.

Table 2: Opinion of the Validators Title | W1 | W2 | W3 | W4 | W5
---|---|---|---|---|---
Trust Score | 30 | 10 | 30 | 50 | 30
Influence | 0.2 | 0.07 | 0.2 | 0.33 | 0.2
Residual Influence(for 0.6) | 0.12 | 0.04 | 0.12 | 0.20 | 0.12
Final Influence | 0.32 | 0.04 | 0.12 | 0.20 | 0.32
|  |  |  |  |

##  4 Opinion Collector

Opinion Collector is a smart contract used in the proposed platform.This
contract was constituted by getter and setter methods and used to maintain the
records in a much more transparent and distributed manner. One of the key
motivations to implement this smart contract is to conduct the decision-making
process as transparently as possible. Most of the functions in this smart
contract can only be invoked by the coordinator, this restriction placed to
ensure the authenticity of the data in Smart Contract

Algorithm 4 Opinion Collector Algorithm 5 Algorithm for OpinionCollector

function addValidator(address)

if $\text{msg.value}>0.005$ then

add it to list of validators

return (success)

else

return (failure)

end if

end function

function setup

if $\text{msg.sender}==\text{coordinator}$ then

Initialize mapping to store opinion called store with validator number of keys

end if

end function

function get_opinion

if $\text{msg.sender}==\text{coordinator}$ then

return store

end if

end function

function set_opinion($\text{key},\text{opinion}$)

if $\text{msg.sender is validator
or}\quad\text{msg.sender}==\text{coordinator}$ then

store[key] $\leftarrow\text{opinion}$

end if

end function

Algorithm 5 explains the functioning of the smart contract for the proposed
system. It has 4 functions that are used for implementing blockchain based
trust. Most of these functions are invoked by the coordinator to verify the
trustworthiness of the validators. This smart contract uses the following data
structures:

  * •

An array is used to keep track of the validators, by holding their public key,
valid_validators.

  * •

A mapping which has a unique identifier as key and its opinion as value, named
store.

The first function in the algorithm addValidator is to be invoked by the
coordinator whenever a new validator joins the proposed system. This function
takes the address as an argument and verifies if the validator paid the fee or
not. If paid, then the validator’s public key is added to valid_validators.
The second function setup is restricted to the coordinator, as it is used to
initialize the store. The third function get_opinion is also invoked by the
coordinator alone. This function basically returns the store mapping to the
coordinator. This mapping is used to calculate the trust of the validator. The
last function named set_opinion is the function that is invoked by both
validators and coordinator. This function is used to populate the store
mapping. It takes two arguments, namely key and opinion. The argument key
corresponds to the unique identifier of a particular validator, and opinion
corresponds to the validator’s opinion on the given set of weights.

##  5 Implementation

###  5.1 Technologies Used

####  5.1.1 Foundry:

Foundry [31] is an open source Rust based smart contract development tool kit
that is used for developing, testing and deploying Smart Contracts and other
decentralized applications to Ethereum blockchain. This toolkit leverages on
various key properties of Rust like being statically typed and compiled, thus
gaining in terms of performance and resources. This toolkit supports
”fuzzing”, fuzzing is the process of an automated testing process that tests
various edge cases and invalid input. Foundry is a combination of the
following tools:

  * •

Anvil: It can be used for setting up a local blockchain network that can be
used while developing the smart contract

  * •

Cast : It is a set of CLI commands that can be used to interact with the smart
contract like sending transactions and read data from the network. It provides
a set of sub commands that can be used for debugging smart contracts.

  * •

Forge: It is a set of CLI commands used for testing, developing and deploying
of the smart contract.

####  5.1.2 Python Socket.IO

Python Socket.io [32] is a python implementation of the Socket.IO protocol.
Socket.IO protocol facilitates real-time, bidirectional and event based
communication between a client and server. This protocol is based on the Web
Socket protocol, with HTTP polling as a fallback option. This library is used
to establish the communication between the node, validator, and coordinator.
The proposed solution leverages on the events based communication python
Socket.io provides.

####  5.1.3 Web3 Py

Web3 py[33] is a python library that enables developers to interact with
Ethereum blockchain. It is widely used in decentralized applications to
initiate transactions, interact with smart contracts and for reading and
writing data to the blockchain. One of the key features, the ability to
interact with smart contracts using Solidity. Web3.py was derived directly
from the Web3.js JavaScript API, but is centered more around the needs of
Python developers. With Web3py, the developers can integrate Ethereum
functionality into their code, thus building a decentralized application.

###  5.2 Implementation Canvas

Nodes and Validators are connected using the web socket connection. This
communication was implemented using python-socketio. This type of
communication is event based. Weights of the trained model are encrypted using
PGP wrapper for python[34], the cipher is then uploaded to IPFS using
ipfshttpclient [35]. The default encryption algorithm used for this process is
RSA-2048. The obtained CID is then sent to the endpoint in the receiver, where
the reverse of the above-mentioned process takes place. Smart Contract used in
the proposed method is invoked by the address and the functional interaction
are done by the web3.py module.

##  6 Distinguishing Features of Proposed Model

###  6.1 Transparent decision-making process

Blockchain, as mentioned in the previous section, serves as a distributed and
immutable ledger where the record of the decision-making process is
maintained. This record includes the individual opinion of the validator on
models submitted by the other validator. The availability of the data on the
blockchain ensures the authenticity of the information, enhancing the
transparency in the decision-making process. In scenarios where the number of
accepted weights is less than $\zeta$, the data stored in the blockchain is
used to create the global model.

###  6.2 Resilient against attacks

As mentioned in the previous section, the IPFS in conjunction with Encryption
prevents Man in the middle attack. Since IPFS is a distributed file system,
there is no single point of failure. This combination reduces the
centralization of the whole system. Since only the CID is only communicated
between the nodes, it significantly reduces the inter-nodal communication.
This streamlined approach optimizes efficiency, leading to a highly robust
network architecture.

###  6.3 Hierarchical Structure

The arrangement of the nodes in a hierarchy provides advantages which include
reduction in impact of attacks and improves the scalability. Validators
requirement to pay a participation fee adds an extra layer of trustworthiness
to the system, as this fee acts as a guarantee of their credibility.
Furthermore, the implementation of the federated algorithm in two level
enhances the robustness.

###  6.4 Validation of Weights

The combination of the Novelty Detection and Snowball protocol ensures that
the global model is generated by the the weights that are accepted by all the
validators, thus making the proposed model resilient against the data
poisioning attacks. As snowball protocol is scalable and need a constant
communication cost, there is minimum overhead. This enforces creation of the
better model that would be resilient against attacks. Furthermore, in absence
of the trust the influence based final model generation ensures the model to
be learned from the most trusted validator.

##  7 Results

###  7.1 Setup

For testing the performance of the proposed model, we have conducted
experiments on a system with following configurations:

  * •

AMD Ryzen 5 4600H with Radeon Graphics @ 3.0GHz

  * •

16 GB of memory with Pop! OS 22.04 LTS

The proposed model’s performance evaluation utilized three datasets: Mushroom
Dataset [36], Pima Indians Diabetes Database [37], and Thyroid Disease Data
Set [38]. These datasets were partitioned into test and train sets, with the
model trained on the train data and validated against the test set. Test
accuracy served as the primary metric for evaluation. Due to the inherent
imbalance in the Pima Indians Diabetes Database and Thyroid Disease Data Set,
class weights were employed during the model generation process to address
this imbalance. Logistic Regression and SGDClassifier models, were considered
for this experiment. Each experiment is repeated 10 times to minimize
randomness.

All experiments were carried out with 5 validators,with its federation
consisting of 2 nodes. The Snowball protocol’s parameters $\alpha$,$\beta$,k
are set to 3, 3, and 4, respectively, on the other hand, the Minimal Consensus
Index is varied from 0 to 5.

To simulate label flipping, two new metrics were introduced:

  * •

Flip: This parameter indicates the number of validators with malicious data in
the entire network.

  * •

Proportion: This parameter represents the fraction of labels flipped, ranging
from 0 to 8.

If Flip, Proportion were set to 2,4 respectively, 2 validators out of 5 were
generating 40 % of the label flipped data. The obtained results were compared
with the Flower framework.

###  7.2 Observations

Figure 4: Evaluation on Diabetic Dataset

Figure 5: Evaluation on Mushroom Dataset

Figure 6: Evaluation on Thyroid Dataset

The dotted line in the plots signifies the test accuracy of the Flower-
generated models. Generally, as the magnitude of the flip and proportion
increases, the overall model performance decreases. Specifically, for lower
$\zeta$ values, the models generated by the proposed platform exhibit
significant oscillations. However, for higher $\zeta$ values, the proposed
platform’s models remain stable under various attacks, albeit with a decrease
in accuracy. Overall, it can be concluded that the performance of the proposed
platform is comparable to Flower, except for a few specific cases.

In the Diabetics dataset (Figure 6), for Logistic Regression, the accuracy of
the proposed platform’s model remains stable compared to the Flower-generated
models. While Flower models perform well in the absence of attacks, their
accuracy declines during attacks, especially with lower $\zeta$ values,
leading to significant oscillations. Regarding SGDClassifier, the models
generated by the proposed platform outperform Flower models in most cases.
However, in extreme scenarios where the flip parameter is set to 3, the
Flower-generated models surpass the proposed platform’s performance.

In the Mushroom dataset (Figure 6), for Logistic Regression, the Flower
implementation outperforms the proposed model, albeit by a small margin.
Notably, when $\zeta$ is set to 0 and 1, the test accuracy of the models
fluctuates considerably. In the case of SGD Classifier, models generated using
Flower significantly outperforms the models generated by the proposed
platform.

In the Thyroid dataset (Figure 6), concerning Logistic Regression, the
accuracy of the proposed platform’s model remains stable, unlike the Flower-
generated models. Flower models perform well in the absence of attacks, but
their accuracy declines during attacks. Regarding SGD Classifier, the
performance of the models generated by the platform is comparable to those
created using Flower. Notably, the proposed platform’s models exhibit relative
stability in accuracy, whereas Flower models tend to oscillate.

##  8 Conclusion and Future Work

In this paper, we discussed a new system to implement Federated learning in a
decentralized manner. In the proposed system, the nodes in the network are
arranged in a tree shaped configuration. Novelty detection in conjunction with
Snowball protocol is used to create a scalable and robust federated learning
setting. Blockchain is used as a record keeper which maintains the record of
decision-making process, thus bring transparency. By the design choices made,
the proposed system is robust against Man in the middle attack, Data Poisoning
and Model Poisoning attacks.

Further work can be done in the following lines, implementing complex machine
learning algorithms like Neural Networks, CNNs, LSTMs, implementing consensus
protocols like RAFT, leveraging on highly scalable networks like Avalanche,
Polkadot instead of Ethereum. Usage of better trust and influence calculation.

Acknowledgments The authors dedicate this work to Bhagwan Sri Sathya Sai Baba,
the Founder Chancellor of SSSIHL, for being a constant source of inspiration.

## Declarations

  * •

Funding: Not Applicable

  * •

Conflict of Interest:On behalf of all authors, the corresponding author states
that there is no conflict of interest

  * •

Ethical standards This article does not contain any studies with human
participants or animals performed by any of the authors

  * •

Informed Consent: Not Applicable

  * •

Author contribution: VRK contributed to the final version of the manuscript.
PKB supervised the project.

  * •

Code Availability: Code will be available publicly in github after acceptance.

## References

  *   * McMahan et al. [2017] McMahan, B., Moore, E., Ramage, D., Hampson, S., Arcas, B.A.: Communication-efficient learning of deep networks from decentralized data. In: Artificial Intelligence and Statistics, pp. 1273–1282 (2017). PMLR
  * European Parliament and of the Council [2016] European Parliament and of the Council: Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) (2016). https://eur-lex.europa.eu/eli/reg/2016/679/oj Accessed 2023-10-18
  * [3] BUKATY, P.: The California Consumer Privacy Act (CCPA): An Implementation Guide. IT Governance Publishing. http://www.jstor.org/stable/j.ctvjghvnn Accessed 2023-10-18
  * Government of India [2023] Digital Personal Data Protection Act, 2023. https://www.meity.gov.in/writereaddata/files/Digital%20Personal%20Data%20Protection%20Act%202023.pdf. Accessed: October 20, 2023 (2023)
  * Wei et al. [2020] Wei, K., Li, J., Ding, M., Ma, C., Yang, H.H., Farokhi, F., Jin, S., Quek, T.Q., Poor, H.V.: Federated learning with differential privacy: Algorithms and performance analysis. IEEE Transactions on Information Forensics and Security 15, 3454–3469 (2020)
  * Wang et al. [2023] Wang, B., Li, H., Guo, Y., Wang, J.: Ppflhe: A privacy-preserving federated learning scheme with homomorphic encryption for healthcare data. Applied Soft Computing 146, 110677 (2023)
  * Dwork [2008] Dwork, C.: Differential privacy: A survey of results. In: International Conference on Theory and Applications of Models of Computation, pp. 1–19 (2008). Springer
  * Naehrig et al. [2011] Naehrig, M., Lauter, K., Vaikuntanathan, V.: Can homomorphic encryption be practical? In: Proceedings of the 3rd ACM Workshop on Cloud Computing Security Workshop, pp. 113–124 (2011)
  * Stephanie et al. [2022] Stephanie, V., Khalil, I., Atiquzzaman, M., Yi, X.: Trustworthy privacy-preserving hierarchical ensemble and federated learning in healthcare 4.0 with blockchain. IEEE Transactions on Industrial Informatics (2022)
  * Ahmed et al. [2020] Ahmed, L., Ahmad, K., Said, N., Qolomany, B., Qadir, J., Al-Fuqaha, A.: Active learning based federated learning for waste and natural disaster image classification. IEEE Access 8, 208518–208531 (2020)
  * Brik et al. [2020] Brik, B., Ksentini, A., Bouaziz, M.: Federated learning for uavs-enabled wireless networks: Use cases, challenges, and open problems. IEEE Access 8, 53841–53849 (2020)
  * Yu et al. [2022] Yu, G., Wang, X., Wang, Q., Bi, T., Dong, Y., Liu, R.P., Georgalas, N., Reeves, A.: Towards web3 applications: Easing the access and transition. arXiv preprint arXiv:2210.05903 (2022)
  * Nakamoto [2008] Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system. Decentralized business review (2008)
  * Benet [2014] Benet, J.: Ipfs-content addressed, versioned, p2p file system. arXiv preprint arXiv:1407.3561 (2014)
  * Buterin et al. [2014] Buterin, V., et al.: A next-generation smart contract and decentralized application platform. white paper 3(37), 2–1 (2014)
  * Rocket et al. [1906] Rocket, T., Yin, M., Sekniqi, K., Renesse, R., Sirer, E.G.: Scalable and probabilistic leaderless bft consensus through metastability (2019). arXiv preprint arXiv:1906.08936 (1906)
  * Konečnỳ et al. [2016] Konečnỳ, J., McMahan, H.B., Yu, F.X., Richtárik, P., Suresh, A.T., Bacon, D.: Federated learning: Strategies for improving communication efficiency. arXiv preprint arXiv:1610.05492 (2016)
  * Tolpegin et al. [2020] Tolpegin, V., Truex, S., Gursoy, M.E., Liu, L.: Data poisoning attacks against federated learning systems. In: Computer Security–ESORICS 2020: 25th European Symposium on Research in Computer Security, ESORICS 2020, Guildford, UK, September 14–18, 2020, Proceedings, Part I 25, pp. 480–501 (2020). Springer
  * [19] Wei, W., Liu, L., Loper, M., Chow, K., Gursoy, M., Truex, S., Wu, Y.: A framework for evaluating gradient leakage attacks in federated learning. arxiv 2020. arXiv preprint arXiv:2004.10397
  * Xu et al. [2023] Xu, B., Zuo, L., Jin, J., Han, L., Hu, K.: Cab: a combinatorial-auction-and-bargaining-based federated learning incentive mechanism. World Wide Web, 1–22 (2023)
  * Mammen [2021] Mammen, P.M.: Federated learning: Opportunities and challenges. arXiv preprint arXiv:2101.05428 (2021)
  * Qu et al. [2022] Qu, Y., Uddin, M.P., Gan, C., Xiang, Y., Gao, L., Yearwood, J.: Blockchain-enabled federated learning: A survey. ACM Computing Surveys 55(4), 1–35 (2022)
  * Nguyen et al. [2021] Nguyen, D.C., Ding, M., Pham, Q.-V., Pathirana, P.N., Le, L.B., Seneviratne, A., Li, J., Niyato, D., Poor, H.V.: Federated learning meets blockchain in edge computing: Opportunities and challenges. IEEE Internet of Things Journal 8(16), 12806–12825 (2021)
  * Kim et al. [2019] Kim, H., Park, J., Bennis, M., Kim, S.-L.: Blockchained on-device federated learning. IEEE Communications Letters 24(6), 1279–1283 (2019)
  * Blossey et al. [2019] Blossey, G., Eisenhardt, J., Hahn, G.: Blockchain technology in supply chain management: An application perspective (2019)
  * Ali et al. [2020] Ali, O., Ally, M., Dwivedi, Y., et al.: The state of play of blockchain technology in the financial services sector: A systematic literature review. International Journal of Information Management 54, 102199 (2020)
  * Pimentel et al. [2014] Pimentel, M.A., Clifton, D.A., Clifton, L., Tarassenko, L.: A review of novelty detection. Signal processing 99, 215–249 (2014)
  * Breunig et al. [2000] Breunig, M.M., Kriegel, H.-P., Ng, R.T., Sander, J.: Lof: identifying density-based local outliers. In: Proceedings of the 2000 ACM SIGMOD International Conference on Management of Data, pp. 93–104 (2000)
  * Tanana [2019] Tanana, D.: Avalanche blockchain protocol for distributed computing security. In: 2019 IEEE International Black Sea Conference on Communications and Networking (BlackSeaCom), pp. 1–3 (2019). IEEE
  * Garfinkel [1995] Garfinkel, S.: PGP: Pretty Good Privacy. O’Reilly Media, Inc., , (1995)
  * [31] Foundry Book: Introduction to Foundry. https://book.getfoundry.sh/
  * [32] SocketIO Contributors: Python SocketIO Documentation. https://python-socketio.readthedocs.io/en/stable/. Accessed: 18 October 2023
  * [33] Web3.py Home Page. https://web3py.readthedocs.io/en/stable/. Last accessed on 2023/08/10
  * GnuPG Contributors [2023] GnuPG Contributors: GNU Privacy Guard Documentation. https://gnupg.readthedocs.io/en/latest/. Accessed on 18 Ocotber 2023 (2023)
  * Contributors [2023] Contributors: IPFS-Toolkit-Python. https://github.com/emendir/IPFS-Toolkit-Python. Accessed: 18 October 2023 (2023)
  * [36] Mushroom. UCI Machine Learning Repository. DOI: https://doi.org/10.24432/C5959T (1987)
  * Repository [n.d.] Repository, U.M.L.: Pima Indians Diabetes Database. Kaggle (n.d.). https://www.kaggle.com/datasets/uciml/pima-indians-diabetes-database
  * Hussein [2023] Hussein, Y.: Thyroid Disease Data Set. https://www.kaggle.com/datasets/yasserhessein/thyroid-disease-data-set. Accessed on 18 October 2023 (2023)