Beyond data sharing: enhancing IoT intrusion detection with blockchain-enabled federated learning

Abstract

Federated learning (FL) is a decentralized machine learning (ML) approach that can be used for intrusion detection in Internet of Things (IoT) devices. It involves the local training of AI models and their aggregation at a central server. This methodology eliminates the need for data sharing between IoT devices while fostering collaborative model improvement. Nonetheless, concerns arise from the lack of transparency regarding the shared local models and the aggregation techniques employed. This lack of transparency can potentially lead to model poisoning attacks and hinder collaborators from using alternative aggregation methods that better align with their specific use cases. To address this issue, this study proposes a blockchain-based approach using FL to ensure transparent, immutable records of model updates, thereby bolstering security and trust for intrusion detection in IoT devices. In contrast to traditional synchronization- or periodic-update-based approaches, this study proposes a novel time-independent aggregation method for FL blockchain, enabling greater flexibility. Furthermore, the proposed blockchain allows various users to utilize their own aggregation methods, rather than a fixed one, based on their needs, resources, and availability. We also developed a user interface for the proposed blockchain system to visualize various aspects of the method, such as model aggregation. The proposed system is tested using traditional metrics, such as AI model performance, as well as extensive user testing.

1 Introduction

In this era of big data, where large volumes of data can be collected to develop intrusion detection systems for Internet of Things (IoT) devices, there is often a need for centralized data aggregation in traditional machine learning (ML). This creates significant privacy risks and regulatory challenges, as IoT devices contain sensitive information about the traffic passing through them. Therefore, federated learning (FL) emerges as a promising solution that combines ML and decentralized systems to address these issues. FL, in essence, decentralizes the traditional model training process by distributing the computation across multiple edge devices, enabling local training without sharing the raw data. This approach not only addresses privacy concerns but also fosters collaboration to build more inclusive ML models (Zhang et al., 2022; Naik and Naik, 2024).

Although FL offers promising advances for IoT intrusion detection, it faces many challenges. One major concern is ensuring the integrity and security of model updates, as they may be tampered with or injected with harmful data during training. Moreover, maintaining trust among decentralized IoT devices and verifying the authenticity of model updates is difficult. These issues are further exacerbated by the lack of a transparent, immutable record of model training activities (Martineau, 2022). Integrating blockchain technology presents a strong solution to address these challenges. By leveraging the blockchain's decentralized and immutable ledger, each model update can be permanently recorded and verified, ensuring the integrity and transparency of the training process. Smart contracts can be employed to automate the validation of model updates, thereby enhancing trust among participating IoT devices and mitigating the risk of malicious attacks.

However, there is a lack of research on combining these two technologies to develop time-independent aggregation of IoT devices' local models. This project will develop an innovative blockchain framework specifically designed to store local model updates from IoT devices in a distributed manner. The approach allows the system to aggregate AI models without strict time constraints, thus providing flexibility in the aggregation process for intrusion detection. A key novelty of the proposed method is the use of time-independent AI model aggregation. Unlike conventional systems that rely on synchronized or periodic model updates, the proposed method allows updates at different times, overcoming challenges arising from device heterogeneity, intermittent connectivity, and disparate processing times. Furthermore, the proposed method also allows for flexible model aggregation. A group of IoT devices in a cluster can choose which models to aggregate based on needs, resources, availability, and performance requirements. Given our security context, and in alignment with (Arp et al., 2022), our design adheres to their recommendations; where decentralization and FL constraints preclude direct adoption, we explicitly document preprocessing steps, baselines, and per-class metrics, while ensuring transparency through detailed dataset descriptions, comprehensive reporting of model architectures and hyperparameters, and clear disclosure of methodological limitations. The major contributions of this work are as follows:

• This study develops a novel blockchain-based system for AI model aggregation in FL for network intrusion detection in IoT devices. The utilization of blockchain ensures that the model aggregation process remains secure, immutable, and transparent, enabling trust-building among IoT devices.

• It also introduces a flexible, time-independent method for aggregating AI models for federated clients within the blockchain system, reducing the need for synchronization and allowing greater adaptability in the aggregation process. This flexibility improves the overall efficiency and performance of IoT network intrusion detection systems.

• This study also develops and tests a user-friendly front-end interface for the proposed model. The front-end helps users visualize various aspects of the proposed system, including model updates and aggregation.

• This study measures the performance of the proposed blockchain-based system using both quantitative and qualitative approaches. Quantitatively, we measured model performance indicators such as accuracy, precision, and recall. Furthermore, we conducted extensive user testing to validate the functionality of the proposed method.

The remainder of the study is structured as follows: Section 2 reviews the relevant literature, Section 3 presents the background study, Section 4 describes the methodology, Section 5 details the implementation, Section 6 discusses the results, and Section 7 concludes the study.

2 Literature review

The major factors contributing to the effectiveness of an ML model can be summarized as the quality of the data, appropriate model complexity with properly tuned hyperparameters, the use of regularization techniques, and the size of the training data. In the case of supervised ML models, the size of the training data, along with accurate labeling, is particularly important. Ramezan et al. (2021) demonstrated in their study that the accuracy of ML models improves with increasing training sample size up to a certain point. Similarly, Barbedo (2018) showed how greater diversity in the data leads to better predictions. More data enables the model to learn more complex patterns and generalize better to unseen samples. For these reasons, there is a growing need to acquire vast amounts of diverse data from various sources. However, in today's age, with heightened privacy concerns and increasingly stringent privacy laws (Rimol, 2022), sharing data for ML model training has become more challenging. To overcome these restrictions, a special approach in ML called FL is used. This field focuses in particular on having multiple entities, referred to as clients, collaboratively train a model while ensuring that their data remain decentralized (Kairouz et al., 2021). This is in stark contrast to the common ML approach in which data are combined and stored centrally. The major advantage of this approach is that it does not require sharing the data.

2.1 FL in cybersecurity

Ghimire and Rawat (2022) explain in depth the application of FL in cybersecurity. In particular, the authors survey various use cases in IoT and provide an exhaustive list of works and the types of issues addressed by these works. The issues range from privacy and latency to DDoS resilience and resource-constraint management, along with the domains they address. This study also provides insights into the observed models and datasets used. In particular, the study highlights the use of servers that aggregate results before they are sent for central aggregation. Das et al. examined the current challenges in anomaly detection in IoT. These include infrastructure-, data-, operational-, and application-specific challenges (Das et al., 2023). Regarding these challenges, this research proposes multiple solutions, including transfer learning, FL, and online learning. Transfer learning involves incremental learning from a previously trained model, whereas online learning involves updating the model as needed (Das et al., 2023). However, in both cases, the raw training data must be shared. Bagaa et al. (2020) used the cost of each operation instead to determine the intrusion. Pan et al. (2022) took an interesting approach by using energy consumption to detect anomalous behavior. While this approach does not show the exact accuracy, it demonstrates how continuous deployment and monitoring using these models are useful for quick response.

As seen above, FL can address most privacy-related issues. This approach, however, heavily depends on blindly trusting the central server that performs the aggregation. It also lacks any method to verify the integrity of the passed data and is vulnerable to Sybil attacks and model poisoning (Jere et al., 2021). Even in the case of such an attack, a benign client is unable to identify the malicious clients or take any action against the attack. Apart from these benefits, the use of ML in security-critical contexts such as intrusion detection requires careful methodological consideration, as mentioned by (Arp et al. (2022) and needs further security constraints.

2.2 Blockchain-enabled FL

A possible solution to the challenges highlighted above is to run an FL system on a blockchain. Nguyen et al. (2021) demonstrated such an application. This research models both internal and external threats, discussing the major problems faced in such an approach, such as communication and resource costs, incentives for contribution, and the security threats it faces. The research also compares the various approaches used across domains. Overall, it highlights the lack of centralized servers and single points of failure, as well as the scalability and trust-building advantages of this approach. Meanwhile, Do et al. (2024) conducted a comparative study between the FL method with separate models and the centralized approach, extensively comparing the two on various metrics. This serves to point out the negligible difference in the accuracy of the two. The survey by Ali et al. (2024) provides an excellent analysis of the state of IoT anomaly detection using FL, covering all possible approaches, including blockchain. The detailed attacks are poisoning, denial-of-service (DoS), malware and ransomware, Byzantine, jamming, shilling, zero-day exploits, and privacy-leakage attacks. The authors discussed in detail the advantages of a blockchain-based approach for addressing trust issues in the system. Moreover, this study discusses the available labeled IoT anomaly detection datasets in detail. Finally, a set of recommendations is provided for integrated blockchain- and FL-enabled approaches in intrusion detection. Many of these have been followed in the project.

Rawat et al. suggested the Federated Blocks with Cohere-Consensus Mechanism (FBCC). By considering two of the most prevalent FL attacks, namely data poisoning attacks and model poisoning attacks (Rawat and Kumar, 2023). The architecture of the present study consists of a decentralized network of nodes that collaboratively train a DNN. The blockchain ledger ensures secure and transparent communication between nodes. The system runs on a smart contract that allows programming of the ledger. The contracts, designed to automatically execute when certain conditions are met, automate the training process, while consensus mechanisms ensure the validity of model updates. The research provides a good basis for the blockchain approach. However, there is no control over the consensus mechanism. Since the smart contract is immutable once deployed, it is impossible to vary the aggregation timing according to our needs. Similarly, as discussed above, since all nodes are treated equally, intrusions can go unnoticed and unverified.

Abdulrahman et al. (2021) proposed client selection by considering multiple criteria for IoT-based FL. In their research, a filtering engine was proposed to select several clients based on time, energy, memory, and CPU. The aggregation is responsible for updating the federated average function. However, this approach leads to high latency during training. Furthermore, Mohammed et al. proposed selecting clients using a heuristic method that finds the best clients for FL. After selecting the candidates, the global model is generated. This research evaluated the performance of the proposed work for the worst-case scenario (Mohammed et al., 2021). However, this method requires the model already to have some knowledge of the unseen test cases.

Narayanan et al. created a blockchain-based FL intrusion detection model. The approach consists of three steps: client selection using an auction algorithm, secure channel selection, and finally FL (Narayanan and Paul, 2023). The auction game theory (Shoham and Leyton-Brown, 2009) is used to select the most efficient clients based on trust, energy, bandwidth, and network conditions. The study then discusses the use of an algorithm, the Base Criterion Method (BCM), to select a secure channel based on stability, path loss, noise, channel quality, and trust. For the FL setting, the authors propose an Optimized Backpropagation-based Deep Belief Network (OB-DBN) algorithm. The proposed model has three Restricted Boltzmann Machine (RBM) layers for training both the local and global models. This makes the model suitable for unsupervised learning as well. While these approaches address many issues in FL with blockchain, they do not include any analysis of potential attacks. The model also ends up accepting aggregates that most clients would not accept, but only a few would. Furthermore, the approach requires more computation and storage due to a double blockchain. This approach illustrates the idea of storing information on a client for later use in determining trustworthiness during decision-making.

Ashraf et al. used FL blockchain in the healthcare environment. The edge server is responsible for identifying attacks using an Artificial Neural Network (ANN) model. The local model values are updated in the blockchain during FL. The model uses a cloud-assisted blockchain layer (Ashraf, 2022). Hussein et al. (2023) surveyed popular consensus algorithms for blockchains, such as Proof of Stake, Delegated Proof of Stake (DPoS), Raft, and Paxos. Among these, the consensus mechanism of interest is Delegated Proof of Stake (DPoS), in which a node delegates its votes to a trusted voter to cast them on its behalf. This system enables better acceptance and decision-making by relying on better-informed parties. A part of this approach has been used in this project. Mothukuri et al. proposed an intrusion detection system for IoT with blockchain. The proposed work has four major units: vendor, blockchain, smart contract, and central coordinator. The model used here is a bidirectional long short-term memory (LSTM) network. Its performance was evaluated on the UNSW-NB15 and BoT-IoT datasets, which showed that the system detected false alarms exceptionally well (Mothukuri et al., 2022).

To summarize, FL offers an approach to ML that preserves data privacy while enabling collaborative model training across distributed devices for cybersecurity threat detection, as shown in Ghimire and Rawat (2022). Despite its promise, challenges such as data integrity, transparency, and trust among participants persist (Das et al., 2023; Jere et al., 2021). To address this issue, this study proposes a blockchain-enabled FL approach that ensures AI model aggregation is safe and secure. Most AI model aggregation methods rely on synchronization or periodic updates, whereas the proposed method enables aggregation in a time-independent manner. This flexibility enhances the performance of network IoT anomaly detection. The proposed blockchain-enabled ML system also includes a front-end interface that has undergone extensive user testing.

3 Background

This section provides a concise overview of the main technologies and acronyms referenced in the manuscript.

3.1 Federated learning

Federated learning is a technique for training AI models in a distributed manner. In this technique, the models are located at the clients where the data originates. It is assumed that all the clients have the same model architecture. Subsequently, the models are trained locally by the clients. After training, the clients send their models to the server, where they are aggregated to form the global model. The aggregated model is sent back to the clients, where it is used and retrained. The main advantage of this technique is that the data does not leave the client, thereby preserving privacy, and there is no need to transfer large amounts of data (Martineau, 2022).

3.2 Blockchain

Blockchain is a distributed ledger where information about any activity (called transactions) is stored in blocks. These blocks are connected through hash functions, making them difficult to modify. Furthermore, such chains are stored not only on a single server but in a distributed manner across multiple locations. When a block is added, that is, when new information is included, a proof of work is performed. This makes blockchain resistant to tampering because any adversary would first need to modify all the blocks in the chain and also control at least 50% of the network (Hussein et al., 2023).

3.3 InterPlanetary file system (IPFS)

IPFS is a decentralized storage system optimized for distributed content/data sharing. In this technique, rather than storing data directly on the blockchain, which is costly, model files are stored on IPFS, and only their content identifiers (CIDs) are kept on the blockchain.

3.4 Intrusion detection in IoT

Network intrusion detection is used to identify malicious traffic in a network using the information contained in the packet headers. The technique helps to detect malicious traffic by looking for abnormal traffic patterns. Nowadays, AI models can analyze packet headers efficiently (Eskandari et al., 2020).

4 Methodology

Figure 1 shows the high-level architecture of the proposed system for developing a smart contract that transparently aggregates models on a blockchain platform, complemented by a user-friendly front end for accessing the aggregated models. The smart contract serves as the backbone of the system, facilitating the transparent aggregation of model updates. All model updates are recorded on the blockchain in a tamper-proof manner, allowing for transparent auditing and verification of the aggregation at any time by any participant. Furthermore, smart contract functionality can enforce consensus rules and verify the authenticity of model updates, enhancing trust among participants. The front-end interface provides users with a user-friendly means to access the aggregated models and interact with the system, making it accessible to non-technical users. The front end can retrieve information about the aggregated models and consensus results. The choice of blockchain technology for model aggregation and a user-friendly front end for accessing the aggregated models is justified by the need for transparency, security, and usability in FL scenarios. By combining these approaches, we created a robust and accessible framework for transparently aggregating models while ensuring the integrity and security of the process.

Figure 1

4.1 System design

The system is designed with the participation of n organizations. Each organization is treated as a user of the blockchain and a client of the federated model. Hence, the terms “user," “client," and “organization" will be used interchangeably throughout this study. Each organization has n branches that gather the data and train on it. The detailed process of aggregating AI models in the proposed FL-based framework is represented in Figure 2 and also explained in the following steps.

Figure 2

Step 0:the system begins by deploying the smart contract to the blockchain. The initialization of the system is to share the base model B with all the users of the blockchain.

Step 1:after the branches obtain the base model, it is trained locally using the private dataset to create a local model L. This new set of model parameters is called the local update. The terms “model" and “update" mean the same in this context and will also be used interchangeably. In this way, each branch has trained local models L₁, L₂, …, L_n respectively for the branches 1, 2, …, n. Now these updates are sent to the organization and aggregated into an organization aggregate M. These aggregates can also be called “models" or “updates."

Step 2:step 1 is carried out across every organization from 1, 2, …, n to get the organization aggregates M₁, M₂, …, M_n respectively. These aggregates are sent by the organizations to the blockchain.

Step 3:now the blockchain holds all the aggregates from M₁ to M_n. Any organization can read the aggregated models on the blockchain transparently. They can download all the aggregates to create their own aggregates or use them as is, depending on their needs.

Step 4:the organization aggregates are then aggregated into a global aggregate. This model is the proposed global aggregate P₁ until it is accepted as the global aggregate by the majority.

Step 5:a vote is held among all the voters in the system on whether to accept this proposed global model P₁. The voters are trusted users given the right to vote on this decision. Each voter casts an irreversible vote for or against the acceptance. This voting is recorded by the contract and is available for future reference. If the majority of votes are for the model, it is accepted; otherwise, we move to Step 8.

Step 6:if the majority of votes approve the model, then the proposed aggregate model P₁ is accepted as the Global Aggregate Model G₁.

Step 7:this global model G₁ is now available for all organizations to download and use.

Step 8:in the meantime between Steps 3 to 8, any of the local branch models can be updated with new data or fresh training. Based on these updates, the organization's aggregates can also be revised at each step. Assume some of the organization models have been updated—for example, odd models such as . These updates are sent to the blockchain at any time between Steps 3 and 8.

Step 9:now, based on the organization updates sent, the aggregates stored on the blockchain are a mix of older and newer updates. The newer updates replace the older ones, i.e., if are the new updates sent, then the stored models M₁, M₃, …, M_n are replaced by these. The blockchain now contains the models .

Step 10:furthermore, any organization can download this new set of aggregates to create their updated global model or for any other purposes needed. The next iteration again begins from Step 4.

Similarly, the blockchain will iterate through the proposed aggregates P₁, P₂, P₃, …, P_i, where i denotes the iteration. Once these models are accepted, they become the global models G₁, G₂, G₃, …, G_j, where G_j is the j_th model to be accepted. Every model can be updated as needed; only the latest version of each model is stored and considered for aggregation. All older models and change logs are still stored on the chain if needed.

The sequence of the proposed method is also provided in Figure 3. This approach allows any organization to download all other organizations' aggregates and use them for the purposes needed—be it testing them individually, creating its own aggregate based on a more suitable one, or even verifying the global aggregate. Similarly, in the case of a malicious update, clients can verify and locate the adversary themselves.

Figure 3

4.2 Constraints

• Due to the limited storage capacity of blockchains, which can lead to exponentially increasing storage costs, other decentralized storage solutions such as the InterPlanetary File System (IPFS) are used (Kumar et al., 2021).

• Due to the limited computing power of the blockchain, an authorized user has to aggregate the organization's aggregates and send them to the smart contract.

• Due to the high complexity involved, the approach was fixed to a single model with a fixed number of parameters in a deployed instance.

4.2.1 Assumptions

• The organizations have a model that is useful for all participants and a common aggregate evaluation metric.

• All organizations have accepted the chosen authorized admin users and voters at the start, even if these can be changed later.

• Voters will provide an unbiased vote on the acceptance of the proposed model.

• The participating organizations are assumed to have the required setup and resources.

• The network latency of all participants is within an acceptable range.

• The clients handle uploading any files to the IPFS network and ensure they persist.

• The majority of voters cast their votes within an acceptable, finite time.

4.3 Model aggregation

The proposed method uses Algorithms 1, 2 for reaching consensus in a time-independent manner. We used the term time-independent aggregation to describe a workflow in which organizations may upload updated model parameters to the blockchain at arbitrary times, without requiring alignment to fixed training rounds or synchronous update schedules. Unlike asynchronous FL, which maintains staleness-aware weighting functions and continuous server-side optimization (Xu et al., 2023), our approach provides a mechanism for retrieving the most recent set of organization-level updates recorded on-chain and aggregating them whenever a proposed global model is needed. The novelty lies in decoupling update submission times from the aggregation process via transparent blockchain storage, rather than in proposing an alternative aggregation algorithm. After the system creates a global aggregate from all the organization aggregates, a vote is held to decide whether it will be accepted as the global aggregate. To prevent data poisoning by an individual or the premature end of the voting period, the system requires at least 50.

Require: Caller is allowed to vote / Caller is voter
Require: Proposed Aggregate Exists
Ensure: voted_status[iteration_number][voter] = False {voter has not voted}
1: if vote is True then
2:   for_votes ← for_votes + 1
3: else if vote is False then
4:   against_votes ← against_votes + 1
5: end if
6: voters_participating ← voters_participating + 1
7: voted_status[iteration_number][voter] = True {Record voter's vote}

Require: Caller can decide
Require:voters_participating > 50%
Ensure: Proposed aggregate Exists
  iffor_votes > against_votesthen
    Global Aggregate ← proposed Global Aggregate
  else
    remove proposed Global Aggregate
  end ifiteration_number ← iteration_number+1
  for_votes ← 0
  against_votes ← 0
  voters_participating ← 0

5 Implementation details

The project has used Python version 3.11 for all the simulations. Truffle Suite v5.11 is used to run a local Ethereum blockchain and deploy the smart contract. Flask 3.0.2 is used to run a local front-end application.

5.1 Dataset

The dataset used is Aposemat IoT-23, a labeled dataset of malicious and benign IoT network traffic (Garcia et al., 2020). This dataset contains IoT network traffic flows collected in real time from StratosphereIPS, which involved running the chosen IoT malware on Raspberry boards. The connection log files used to extract this dataset were generated with the Zeek network analyzer and manually labeled in the lab (Garcia et al., 2020). The front-end application is built using the Flask framework. Flask is a lightweight Python web framework known for its simplicity and flexibility, often used to build web applications and APIs.

5.1.1 Data preprocessing

The dataset has 21 columns, including timestamp, unique ID, port, and IP addresses of the sender and receiver, protocol used, service, duration, local origin and response, missed bytes, history, origin and receiver packets, IP bytes, and finally the label of the packet. The dataset has 1,584,674 samples. Checking the labels, we see that they are incorrectly formatted and hence fix them. The raw data is cleaned as shown in Figure 4. The data is reduced to six main attack types, which are:

• Okiru attack: this label has the most samples and indicates that the connections have characteristics of an Okiru botnet. It also includes the horizontal port scans performed to gather information for further attacks.

• Benign Type-1 and Type-2: this label indicates that no suspicious or malicious activities were found in the connections. It is divided into two types to facilitate easier identification of the two ongoing activities in the samples.

• DDoS attack: this label indicates that a Distributed Denial of Service attack is being executed by the infected device. These traffic flows are detected as part of a DDoS attack due to the number of flows directed to the same IP address.

• C&C attack: this label indicates that the infected device was connected to a C&C server. Connections to the suspicious server are periodic, including samples in which suspicious files are being downloaded.

• Malicious attack: this label indicates that there was some type of attack from the observed infected device to another host.

Figure 4

5.1.2 Dataset split

The dataset is split into a training and a testing set. The testing set is 30% of the total dataset. The training set is then split into six datasets of different sizes to create local models, as shown in Figure 5. Except for the last two sets, which are identical and balanced, the rest of the sets are created without a few labels to resemble real local data variations. The test set has 475,403 samples, which is 30% of the dataset. The split of the test set into different values is shown in Figure 6. The six test sets are divided equally among three organizations, such that each organization has an aggregate formed from two local updates.

Figure 5

Figure 6

5.2 Federated model

The model is an artificial neural network with six layers, as shown in Figure 7. The input layer accepts a vector of 24 parameters. This is followed by the first dense layer. The second layer is a dropout layer with a 20% drop rate. A dropout layer randomly sets a fraction of inputs to zero during training to prevent overfitting. The third layer is a dense layer of 50 neurons that uses the ReLU activation function. The fourth layer is a dense layer of 20 neurons with the ReLU activation function, followed by the fifth layer, a dropout layer with a 30% dropout rate. Finally, the output layer is the last dense layer, which uses a softmax function to assign the output to one of the seven possible multiclass labels. The softmax function converts the inputs into probabilities for the outcome among the others.

Figure 7

The model trains using the categorical cross-entropy loss function. This loss is calculated based on the dissimilarity between the predicted and true probability distributions. The penalty that applies is the logarithmic difference between the predicted and actual class probabilities (Neuralthreads, 2021). The model uses adam as the optimizer. The Adam optimizer combines the benefits of the Momentum and RMSProp optimizers (Kingma and Ba, 2014). The model was trained with a batch size of 32 and 1 epoch per local model. It adjusts the learning rate for each layer based on past gradients and their squared deviation.

5.2.1 Aggregation

In this chosen approach, the Federated Averaging (FedAvg) algorithm is applied as the core aggregation method. FedAvg operates by having each client train its local model on its respective data and sending the model updates to the smart contract. These updates are then aggregated by averaging the model parameters.

Furthermore, the global model is created by incorporating the knowledge from all clients while preserving data privacy, since the raw data is not shared. This averaging process ensures that the global model converges toward a consensus across distributed data sources. This model is then generalized for all clients.

5.3 Blockchain

• Smart contract functionality: the blockchain supports the creation of decentralized applications (DApps) using smart contracts that can be automated and self-executing.

• Programmability: ethereum's scripting language, Solidity, supports building complex logic and functionalities into smart contracts, thus expanding the scope of its products.

• Token support: the blockchain has its own standard contracts for tokens, thus supporting a variety of token applications.

Truffle Suite is used for supporting Dapp development on the Ethereum chains. It supports running a local ethereum testnet and was hence used. ERC-721 is a non-fungible token standard used for representing unique digital assets on Ethereum (Verma et al., 2022). Since each token is distinct, allows ownership tracking and can store values, it was chosen to store the local updates of individual branches of an organization.

5.3.1 Organization management

Each participant organization will be treated as a user of the smart contract. Each organization will have an organization aggregate. An enumerable set contract will store the list of all organizations that have aggregated and stored an aggregate. This allows iterating over it sequentially and accessing all stored data, which is useful for aggregation when creating a global aggregate.

5.3.2 Storage

InterPlanetary File System (IPFS) is a decentralized system for sharing and storing files in a peer-to-peer manner within a distributed file system (Kumar et al., 2021). Since blockchain has very limited storage and storing data can be expensive, a decentralized format of storage, such as IPFS, is used to store the model updates. These updates can only be accessed using a unique hash assigned to the file, called a Content Identifier (CID). This CID is stored in the token URI for local updates and in the organization aggregate for organizational updates.

5.3.3 Data processing in blockchain

The blockchain has limited computational power and cannot process data on its own. Hence, the smart contract will allow an authorized user to aggregate all the organization's aggregates into a global aggregate proposal. This proposal is then stored on the smart contract for a decision. For convenience, the same user is authorized to declare the end of the voting period. While a fixed time-to-end voting approach is possible and would be uniform, it would also restrict the time period and number of voters who can participate, thus allowing updates that may not be accepted by the actual majority and leading to the problems discussed in the literature review.

5.3.4 Authorization

The proposed blockchain implements controls over who can modify the data. This is done by restricting actions to those permitted for certain roles assigned to users via the AccessControl contract. The restrictions set are:

• Tokens can only be minted by accounts with the minter role.

• Tokens that belong to an organization and the organization's own aggregate can only be changed by the owner, i.e., the organization itself.

• Only organizations with the voter role are allowed to vote for a proposed global model. These votes are immutable and recorded.

• The ability to add or remove organizations from the system, set a proposed global aggregate, and end voting is authorized only for a user with the admin role.

• The ability to assign roles and manage organizations is restricted to users with the admin role.

While the smart contract is designed to allow each role to have multiple users, for convenience, the system uses only one admin account here.

5.4 Front-end application

The application has a web interface with a login system using credentials (Figure 8). This helps keep track of the users using this application. Once a user is registered and logged in, they are taken to the home screen, which displays the available functionalities for interaction. Also, the user must store or update their Ethereum account address and private keys to use the features.

Figure 8

These functionalities include viewing the proposed aggregate, global aggregate, other organization details, token details, and organization aggregates. The user can also view either aggregates of all organizations or tokens of a particular organization. They can also download these model updates as a compressed file for use as needed. The organization can set, update, or remove its aggregate. The user can also burn or update a token they own. Voters can vote for the proposed global aggregate, and minters can mint tokens. Other than this, the users can also download IPFS files using a CID or upload a file and get a CID in return.

The authorized account, i.e., admin account, has access to some additional functionality. These are to add or remove organizations, grant or revoke roles, set a proposed global aggregate, and make decisions on it. This account can also view statistical information such as the number of registered organizations, the number of aggregates, and the total number of tokens owned by an organization.

6 Results

6.1 Federated model performance

To evaluate the system, we present quantitative results for all stages of the federated workflow. These include the accuracies of the six local models (Figure 9), the performance of organization-level aggregates (Figures 10–12), and the global model evaluation (Tables 1, 2). These results constitute the algorithmic evaluation referenced in the Introduction and Methodology sections, and together they provide a complete quantitative assessment of the proposed approach. As shown, model 2 has the lowest accuracy, at 20.58%. Models 1 and 3 perform much better at 79.11% and 79.24%, respectively. The last three models, 0, 4, and 5, perform exceptionally well with accuracies of 84.32%, 87.05%, and 86.96%, respectively.

Figure 9

Figure 10

Figure 11

Figure 12

However, since the datasets were created with variations, we will also check label-wise accuracies in Figure 10. As seen from these, the first model is the only one to perform poorly on label 1. Model 2 performs well for label 0, unlike every other model, but performs badly for labels 4 and 5. Model 3 performs badly for label 3. The performances of models 4 and 5 are nearly identical, with minute variations in labels 1 and 2. Every model except model 2 performs badly on label 0 while performing well on label 1, except model 0. No model does better on label 2.

Then, every two models are aggregated to form an organization aggregate. The first two models (0 and 1) are aggregated into organization aggregate 0, the next two models (2 and 3) are aggregated into organization aggregate 1, and finally, the last two models (4 and 5) are aggregated into organization aggregate 2.

We then check the accuracy of the 3 models as shown in Figure 11. The first and last models perform exceptionally well with 86% accuracy, but the organization's aggregate 2 performs at only 51.40%.

Checking the accuracy label-wise in Figure 12, we observed that aggregates 0 and 2 perform almost identically, overlapping perfectly except for a slight difference at label 2. These two models perform well on labels 1, 3, 4, and 5; however, they perform badly on label 0. All models perform badly on label 2 even after aggregation. Aggregate 1 also performs poorly on labels 3 and 5, but performs well on label 0.

Finally, we aggregated these three into a global model. The global model's report is shown in Table 1. According to the report, the accuracy is 87%. While this is lower than the best aggregate, it is better than the worst.

Label-wise, we observed that the accuracies for labels 3, 4, and 5 have fallen relative to the aggregates, while labels 1 and 2 have remained similar. Label 0 has risen slightly compared to aggregates 0 and 2 but has reduced drastically compared to aggregate 1.

Now, by creating a confusion matrix as shown in Table 2, most of the misclassified labels have ended up in label 5, with 39,024 from label 0, 1,455 from label 1, 4,130 from label 2, and 15,982 from label 3.

We can now compare and contrast this with a centralized training setup that does not aggregate models, i.e., training the model on the entire dataset and then testing it. The report of this model is shown in Table 3. As seen in the report, even the normal model has low accuracy on label 0 and 0% accuracy on label 4, which has only 1,282 samples. Conversely, the model achieves extremely high accuracy of 85% on label 1 and 90%+ on labels 3 and 5, which have the largest sample counts. This leads the model's total accuracy to 87%.

Now, comparing the accuracies for each label using the confusion matrix shown in Table 4, we immediately notice that label 4 has been entirely misclassified as label 5, except for two samples in label 0. As with the federated model, most misclassifications are assigned to label 5, with 8,220 from label 4, 4,223 from label 2, 2,193 from label 1, and 43,947 from label 0. Other than this, label 1 and label 0 have some misclassifications between them, with 1,251 label 1 samples in label 0 and 1,492 label 0 samples in label 1.

Overall, we can see that while the centralized model achieves higher accuracy and better classification for classes with large sample sizes, the FL model's accuracy is only slightly lower, but its classification is better for labels with smaller sample sizes.

6.2 Blockchain approach

Our implementation of the federated model within a blockchain framework showed its applicability and usefulness. It has been shown that blockchain's inherent properties of immutability and transparency can be used to store models without tampering and to make them visible to any user as and when needed.

Similarly, the voting algorithm provides a decentralized method for tracking votes on the model and storing them for reference and immutability. The decision algorithm also provides a decentralized consensus method for accepting a global aggregate that can run independently of time and provide generalized acceptance. As demonstrated by the model evaluation, participating organizations can securely contribute to a global model without compromising data privacy.

Any data provided by organizations can be verified due to the transparency, thus preventing any compromise in integrity or poisoning of the model. Even if the model is poisoned, simple verification of the model update will quickly reveal the problem. Similarly, most Sybil attacks will fail due to the division and restriction of roles. The adversary is severely restricted even when taking over a few accounts of some roles. For an attack to succeed, the adversary has to compromise the majority of users in every role.

In this implementation, the blockchain layer serves as a governance and transparency mechanism within the FL workflow rather than as a modification to the underlying learning algorithm. Model weight files are stored off-chain using the InterPlanetary File System (IPFS), whereas only metadata, such as content identifiers, organization addresses, vote counts, and role information, is recorded on-chain via smart contracts deployed on Ethereum. Once a model update reference is recorded on-chain, it cannot be altered or deleted; instead, new versions are appended, and the contract updates a pointer to the most recent accepted aggregate, preserving immutability while maintaining version traceability. This structure enhances auditability by allowing participants to verify the provenance and history of submitted updates. While the blockchain layer does not inherently prevent model poisoning or Byzantine behavior, it provides transparency and accountability mechanisms that facilitate detection and governance-based mitigation of anomalous contributions. Role-based access control within the smart contract restricts actions such as aggregate submission, voting, and administrative management, thereby reducing the risk of unauthorized manipulation of the workflow. The decentralized voting mechanism further ensures that acceptance of a global model depends on majority agreement under the stated trust assumptions, rather than unilateral control. Functional testing confirms that these governance and traceability mechanisms operate as designed, supporting secure and auditable collaboration among participating organizations without altering the standard FedAvg aggregation process.

6.3 Testing

A total of 25 tests were conducted to evaluate the functionality of the application. Testing is recorded with the test name, test type, expected output, actual output, and test success. A total of 10 unit tests, 10 integration tests, and five functional tests were conducted, all of which passed. The table of tests is shown in Tables 5–7. The tables show that the core parts of the project application were tested for both valid and invalid actions.

6.4 Front-end demonstration

The front end opens to a basic homepage that leads to the login and sign-up pages, as shown in Figure 13. The sign-up page asks for the username, password, and confirmation of the password, whereas for logging in, only a username and password are required.

Figure 13

Logging in leads to the homepage of the user, as shown in Figure 14. The top section displays the user's Ethereum account details, including the address and key. This is followed by the address of the base model used in the contract. The base model address is retrieved from the smart contract when the front end is started. Finally, there are two buttons to display the address of the current global aggregate and the iteration of the running global model. Opening the update-Ethereum-account-details option displays a dialog box to enter the new address and private key to update.

Figure 14

Figure 15 shows the functions used to interact with the smart contract. The token-details section allows checking the attached URI and token-owner name by using the token ID. Similarly, the organization-details section allows a user to find an organization's name and aggregate using its account address, as shown in Figure 16. The token-management panel allows the user to create, update, or destroy a token. However, creating a token is allowed only for users who have the minting role. Similarly, the updating and destroying functions can only be performed by the token owner. The organization-aggregate section allows the user to set, update, or remove the aggregate address for their organization. The global-aggregation section allows the user to see the address of a proposed but not yet accepted aggregate. If the user has permission to vote, they can vote for or against the acceptance of this model as the global aggregate.

Figure 15

Figure 16

Finally, the get-aggregates section allows a user to download all organization aggregates or the local updates of an organization from all its branches via the zip-tokens button. Both options will download a zip file containing all the weight-update files. The download-average option will instruct the server to average all the organization-aggregate weights and download a global-aggregate weight. Similarly, the average-tokens option will create and download an organization aggregate using all its tokens.

Admin accounts are those whose associated Ethereum address has been assigned the admin role, giving them access to additional functionalities (see Figure 17). In this system, the deploying account is set as the admin. When a user logs in to an admin account, an extended panel appears with various administrative controls. Within this panel, the manage-organization section enables the admin to add new organizations to the blockchain by specifying an address and name, or to remove existing ones. A separate function displays the number of active organizations, and another checks whether a given address corresponds to a registered organization. The role-management section allows the admin to grant or revoke roles for any account, and the token-management section shows both the total number of tokens in circulation and the token balance of any organization. The aggregate-management section allows the admin to view how many organizations have created an organization aggregate, set a new aggregate, and use the Make-Decision function to accept or reject the proposed aggregate.

Figure 17

Using the IPFS button on the navigation bar takes the user to an IPFS-file-functions section, as shown in Figure 18. This implementation uses the Pinata API for upload and storage. Hence, the user has to create an API key and a private API key to use the available functions. The download function uses the CID to retrieve a file from the IPFS network, while the upload section accepts a file as input and then displays its CID. Opening the update API keys section displays a small form to update the API and Private API keys, as shown in Figure 19.

Figure 18

Figure 19

7 Conclusions and future work

The project proposed a time-independent aggregation method for blockchain as a medium to immutably store, transparently share, and provide a decentralized approach to time-independently reach consensus on the global model accepted by the majority of organizations for FL systems. As demonstrated in this project, FL is used to partition the chosen large dataset into smaller parts, each processed separately. These are then uploaded to the blockchain for transparent availability. The uploaded data is then accessed by users for aggregation as and when needed. The aggregation is then run for all aggregated organizations to create a global model. The voting system ensures that only a generally accepted aggregate is accepted as the global aggregate. As shown in the evaluation section, we aggregate local models into organization-level aggregates that any organization can use or aggregate as needed. We then aggregate them into a global aggregate using FedAvg and compare the results with those of a normal model trained on shared data. This shows that while the normal model achieved 87% accuracy, the federated model was more sensitive to low-sample classes and had a slightly lower accuracy of 86%.

Furthermore, our theoretical analysis has demonstrated the security and efficiency of the blockchain approach. By leveraging the advantages of blockchain and decentralized systems, we showed a time-independent consensus mechanism for model-aggregate acceptance. Finally, the front end makes it accessible for non-technical users and provides a friendly GUI for interaction.

While the proposed framework demonstrates the feasibility and usability of a blockchain-enabled, time-independent FL system, we acknowledge several important limitations. First, our evaluation relies on Federated Averaging, which is known to be vulnerable to poisoning attacks and does not incorporate robust aggregation mechanisms such as Krum, trimmed mean, or coordinate-wise median. These defenses could be integrated into future versions of the framework to provide stronger resilience against adversarial organizations. Second, the current reliance on human voting for global model acceptance introduces latency and may be less robust than automated anomaly-detection techniques. Future work may incorporate automated validators or lightweight statistical detectors to assist or complement the voting process. Third, model updates stored via IPFS and referenced on-chain may reveal information through gradients or parameter structures, since secure aggregation and formal privacy guarantees are not applied in this proof-of-concept system. We emphasize that our blockchain design is compatible with such enhancements, and incorporating these mechanisms forms a promising direction for future work. Future extensions will incorporate robustness evaluations and formal threat-modeling guidelines to further align with ML-security best practices as mentioned in (Arp et al. 2022).

References

• 1

  AbdulrahmanS.ToutH.MouradA.TalhiC. (2021). FedMCCS: multicriteria client selection model for optimal IoT federated learning. IEEE Internet Things J. 8, 4723–4735. doi: 10.1109/JIOT.2020.3028742

  • CrossRef
  • Google Scholar

• 2

  AliS.LiQ.YousafzaiA. (2024). Blockchain and federated learning-based intrusion detection approaches for edge-enabled industrial IoT networks: a survey. Ad Hoc Netw. 152:103320. doi: 10.1016/j.adhoc.2023.103320

  • CrossRef
  • Google Scholar

• 3

  ArpD.QuiringE.PendleburyF.WarneckeA.PierazziF.WressneggerC.et al. (2022). “Dos and don'ts of machine learning in computer security," in 31st USENIX Security Symposium (USENIX Security 22), 3971–3988.

  • Google Scholar

• 4

  AshrafE.AreedN. F. F.SalemH.AbdelhayE. H.FaroukA. (2022). FIDChain: federated intrusion detection system for blockchain-enabled IoT healthcare applications. Healthcare10:1110. doi: 10.3390/healthcare10061110

  • Pubmed Abstract
  • CrossRef
  • Google Scholar

• 5

  BagaaM.TalebT.BernabeJ. B.SkarmetaA. (2020). A machine learning security framework for IoT systems. IEEE Access8, 114066–114077. doi: 10.1109/ACCESS.2020.2996214

  • CrossRef
  • Google Scholar

• 6

  BarbedoJ. G. A. (2018). Impact of dataset size and variety on the effectiveness of deep learning and transfer learning for plant disease classification. Comput. Electron. Agric. 153, 46–53. doi: 10.1016/j.compag.2018.08.013

  • CrossRef
  • Google Scholar

• 7

  DasT.ShuklaR. M.SenguptaS. (2023). What could possibly go wrong? Identification of current challenges and prospective opportunities for anomaly detection in internet of things. IEEE Netw. 37, 194–200. doi: 10.1109/MNET.119.2200076

  • CrossRef
  • Google Scholar

• 8

  DoP. H.LeT. D.VishnevskyV.BerezkinA.KirichekR. (2024). A horizontal federated learning approach to IoT malware traffic detection: an empirical evaluation with N-BaIoT dataset. doi: 10.23919/ICACT60172.2024.10471929

  • CrossRef
  • Google Scholar

• 9

  EskandariM.JanjuaZ. H.VecchioM.AntonelliF. (2020). Passban IDS: an intelligent anomaly-based intrusion detection system for IoT edge devices. IEEE Internet Things J. 7, 6882–6897. doi: 10.1109/JIOT.2020.2970501

  • CrossRef
  • Google Scholar

• 10

  GarciaS.ParmisanoA.ErquiagaM. J. (2020). IoT-23: a labeled dataset with malicious and benign IoT network traffic [Data set]. Zenodo. doi: 10.5281/zenodo.4743746

  • CrossRef
  • Google Scholar

• 11

  GhimireB.RawatD. B. (2022). Recent advances on federated learning for cybersecurity and cybersecurity for federated learning for internet of things. IEEE Internet Things J. 9, 8229–8249. doi: 10.1109/JIOT.2022.3150363

  • CrossRef
  • Google Scholar

• 12

  HusseinZ.SalamaM.El-RahmanS. (2023). Evolution of blockchain consensus algorithms: a review on the latest milestones of blockchain consensus algorithms. Cybersecurity6:30. doi: 10.1186/s42400-023-00163-y

  • CrossRef
  • Google Scholar

• 13

  JereM. S.FarnanT.KoushanfarF. (2021). A taxonomy of attacks on federated learning. IEEE Secur. Priv. 19, 20–28. doi: 10.1109/MSEC.2020.3039941

  • CrossRef
  • Google Scholar

• 14

  KairouzP.McMahanH. B.AventB.BelletA.BennisM.BhagojiA. N.et al. (2021). Advances and open problems in federated learning. Found. Trends Mach. Learn. 14, 1–210. doi: 10.1561/9781680837896

  • CrossRef
  • Google Scholar

• 15

  KingmaD. P.BaJ. (2014). Adam: a method for stochastic optimization. arXiv preprint arXiv:1412.6980.

  • Google Scholar

• 16

  KumarS.BhartiA. K.AminR. (2021). Decentralized secure storage of medical records using blockchain and IPFS: a comparative analysis with future directions. Secur. Priv. 4:e162. doi: 10.1002/spy2.162

  • CrossRef
  • Google Scholar

• 17

  MartineauK. (2022). What is federated learning?IBM Research Blog. Available online at: https://research.ibm.com/blog/what-is-federated-learning

  • Google Scholar

• 18

  MohammedI.TabatabaiS.Al-FuqahaA.BouananiF.QadirJ.QolomanyB.et al. (2021). Budgeted online selection of candidate IoT clients to participate in federated learning. IEEE Internet Things J. 8, 5938–5952. doi: 10.1109/JIOT.2020.3036157

  • CrossRef
  • Google Scholar

• 19

  MothukuriV.KhareP.PariziR. M.PouriyehS.DehghantanhaA.SrivastavaG.et al. (2022). Federated-learning-based anomaly detection for IoT security attacks. IEEE Internet Things J. 9, 2545–2554. doi: 10.1109/JIOT.2021.3077803

  • CrossRef
  • Google Scholar

• 20

  NaikD.NaikN. (2024). “An introduction to federated learning: working, types, benefits and limitations," in Advances in Computational Intelligence Systems, eds. N. Naik, P. Jenkins, P. Grace, L. Yang, and S. Prajapat (Cham: Springer Nature Switzerland), 3–17. doi: 10.1007/978-3-031-47508-5_1

  • CrossRef
  • Google Scholar

• 21

  NarayananU.PaulV. (2023). Twin chain: a blockchain based federated learning intrusion detection system using optimized backpropagation based neural network for edge assisted IoT networks. Preprint. doi: 10.21203/rs.3.rs-3214924/v1

  • CrossRef
  • Google Scholar

• 22

  Neuralthreads (2021). Categorical Cross-Entropy Loss—The Most Important Loss Function.

  • Google Scholar

• 23

  NguyenD. C.DingM.PhamQ.-V.PathiranaP. N.LeL. B.SeneviratneA.et al. (2021). Federated learning meets blockchain in edge computing: opportunities and challenges. IEEE Internet Things J. 8, 12806–12825. doi: 10.1109/JIOT.2021.3072611

  • CrossRef
  • Google Scholar

• 24

  PanH.YinZ.JiangX. (2022). High-dimensional energy consumption anomaly detection: a deep learning-based method for detecting anomalies. Energies15:6139. doi: 10.3390/en15176139

  • CrossRef
  • Google Scholar

• 25

  RamezanC. A.WarnerT. A.MaxwellA. E.PriceB. S. (2021). Effects of training set size on supervised machine-learning land-cover classification of large-area high-resolution remotely sensed data. Remote Sens. 13:368. doi: 10.3390/rs13030368

  • CrossRef
  • Google Scholar

• 26

  RawatP.KumarP. (2023). “Blockchain based federated deep learning framework for malware attacks detection in IOT devices," in 2023 14th International Conference on Computing Communication and Networking Technologies (ICCCNT), 1–10. doi: 10.1109/ICCCNT56998.2023.10306828

  • CrossRef
  • Google Scholar

• 27

  RimolM. (2022). Gartner Identifies Top Five Trends in Privacy through 2024. Accessed May 31, 2022.

  • Google Scholar

• 28

  ShohamY.Leyton-BrownK. (2009). Multiagent Systems: Algorithmic, Game-Theoretic, and Logical Foundations. New York, NY: Cambridge University Press. A recent textbook; see Chapter 11, which presents auction theory from a computational perspective.

  • Google Scholar

• 29

  VermaR.DhandaN.NagarV. (2022). “Application of truffle suite in a blockchain environment," in Proceedings of Third International Conference on Computing, Communications, and Cyber-Security (Cham: Springer). doi: 10.1007/978-981-19-1142-2_54

  • CrossRef
  • Google Scholar

• 30

  XuC.QuY.XiangY.GaoL. (2023). Asynchronous federated learning on heterogeneous devices: a survey. Comput. Sci. Rev. 50:100595. doi: 10.1016/j.cosrev.2023.100595

  • CrossRef
  • Google Scholar

• 31

  ZhangT.GaoL.HeC.ZhangM.KrishnamachariB.AvestimehrA. S.et al. (2022). Federated learning for the internet of things: applications, challenges, and opportunities. IEEE Internet Things Mag. 5, 24–29. doi: 10.1109/IOTM.004.2100182

  • CrossRef
  • Google Scholar