A Trusted Federated Learning Method Based on Consortium Blockchain

Abstract

Federated learning (FL) has gained significant attention in distributed machine learning due to its ability to protect data privacy while enabling model training across decentralized data sources. However, traditional FL methods face challenges in ensuring trust, security, and efficiency, particularly in heterogeneous environments with varying computational capacities. To address these issues, we propose a blockchain-based trusted federated learning method that integrates FL with consortium blockchain technology. This method leverages computational power registration to group participants with similar resources into private chains and employs cross-chain communication with a central management chain to ensure efficient and secure model aggregation. Our approach enhances communication efficiency by optimizing the model update process across chains, and it improves security through blockchain’s inherent transparency and immutability. The use of smart contracts for participant verification, model updates, and auditing further strengthens the trustworthiness of the system. Experimental results show significant improvements in communication efficiency, model convergence speed, and security compared to traditional federated learning methods. This blockchain-based solution provides a robust framework for creating secure, efficient, and scalable federated learning environments, ensuring reliable data sharing and trustworthy model training.

1. Introduction

In recent years, federated learning (FL) has emerged as a pivotal technique in distributed machine learning, allowing multiple clients to collaboratively train a model without sharing their raw data [1]. This approach is particularly advantageous in scenarios where privacy concerns are paramount, such as healthcare [2,3], finance [4], transportation systems [5,6], and personalized services [7]. FL provides a solution to data privacy challenges by ensuring that data remain decentralized, thus preventing the need for sensitive information to be transmitted to a central server. By aggregating only model parameters instead of raw data, FL significantly mitigates privacy risks, making it a preferred approach in various privacy-sensitive applications.

Despite these advantages, traditional federated learning models face several critical limitations: Handling Malicious Participants: In decentralized environments, ensuring that all participants act honestly is a significant challenge. Malicious participants may inject poisoned data or attempt to compromise the global model by sending false updates, leading to inaccurate or corrupted model results [8,9]. Communication Overhead: The frequent exchange of model updates between participants and the central server results in significant communication overhead, particularly when participants have varying computational capabilities and network conditions [10,11]. Model Reliability: Traditional FL systems often assume that all participants are equally trustworthy and capable, which can result in biased models when participants with limited data or computational power disproportionately influence the global model [12,13].

These challenges highlight the need for mechanisms that ensure the trustworthiness, security, and efficiency of the federated learning process, particularly in environments where participants may have heterogeneous capabilities and differing levels of trust. The integration of blockchain technology with FL offers a promising solution to these challenges, providing mechanisms for secure and transparent coordination between participants while addressing issues like malicious attacks, communication bottlenecks, and model fairness.

Blockchain technology [14], with its decentralized and immutable nature, offers a promising solution to the challenges faced by federated learning. Blockchain provides a transparent and tamper-resistant ledger that can be used to record all transactions and interactions between participants, ensuring data integrity and accountability. Additionally, blockchain’s consensus mechanisms can prevent malicious actors from disproportionately influencing the system, while smart contracts can automate processes such as participant verification and model updates.

The integration of blockchain with federated learning introduces several advantages: Enhanced Security and Trust: By leveraging blockchain’s decentralized ledger to record and verify all model updates, we ensure that no participant can tamper with the learning process. Smart contracts automate the validation of participants’ computations, ensuring that only valid updates are accepted and preventing adversarial interventions [15]. Improved Communication Efficiency: Blockchain enables the use of computational power-based grouping to cluster participants with similar resources into private chains. This approach reduces the communication overhead by facilitating intra-group communication and synchronizing model updates within private chains before aggregation on the central chain [16]. Model Integrity and Privacy: Cross-chain communication between private chains and a central management chain allows for secure aggregation of model updates without exposing sensitive participant data. This ensures that the global model remains robust and accurate while preserving the privacy of local data [17].

In particular, consortium blockchains, which are controlled by a group of pre-approved nodes, are particularly suitable for federated learning environments. Unlike public blockchains, consortium blockchains offer greater control over who can participate in the network, allowing for a more secure and scalable solution to federated learning tasks that require trust among participants [18]. Furthermore, the use of blockchain’s consensus mechanisms prevents malicious participants from corrupting the model, thereby improving the overall reliability and security of the system.

In this paper, we propose a novel federated learning framework that integrates FL with consortium blockchain technology, focusing on three key innovations:

• Smart Contract Design: We introduce a novel smart contract framework that automates the verification of participants, manages model updates, and ensures the auditability of the entire learning process. Smart contracts are utilized to validate the computational power of participants, prevent malicious updates, and provide transparency in model aggregation.
• Central Management Chain and Private Chains: To address scalability and privacy concerns, we propose a decentralized architecture that includes a central management chain and multiple private chains. The central management chain coordinates model aggregation and manages cross-chain communication, while private chains enable participants to train local models without exposing sensitive data. This structure ensures that the system is scalable, secure, and privacy-preserving.
• Cross-Chain Communication Protocol: A critical challenge in the blockchain–FL integration is the overhead introduced by cross-chain communication. We design an efficient cross-chain communication protocol that enables low-latency model aggregation and synchronization between the central management chain and private chains. This protocol ensures that updates are securely shared across chains while minimizing communication delays.

The primary goal of this work is to develop a blockchain-based trusted federated learning system that addresses the shortcomings of traditional FL approaches in heterogeneous environments. Specifically, our system aims to: Optimize Communication Efficiency: By grouping participants based on their computational power into private chains, we reduce the communication overhead and enhance the efficiency of model synchronization across participants. Ensure Trust and Security: Blockchain’s transparency and tamper-resistant properties, along with the automation provided by smart contracts, ensure that all model updates are legitimate and that the learning process remains secure from malicious attacks. Provide a Scalable and Reliable Solution: Our system is designed to scale efficiently across a variety of industries, providing a robust and privacy-preserving solution for decentralized machine learning tasks in sectors such as healthcare, finance, and smart cities.

The contributions of this paper are as follows:

• We propose a hybrid blockchain architecture that combines a central management chain and multiple private chains, addressing both scalability and privacy concerns in federated learning.
• We design and implement smart contracts that automate participant validation, model update management, and provide transparent audit logs, improving the security and trustworthiness of the learning process.
• We develop a cross-chain communication protocol that efficiently manages data exchange and model aggregation between chains, significantly reducing communication overhead.

The remainder of this paper is organized as follows. Section 2 presents an analysis of related work. Section 3 briefly describes the preliminaries. Section 4 describes the workflow and the architecture of the proposed scheme. Section 5 characterizes the security proofs. Section 6 compares the performance of our proposed scheme with that of other recent schemes. Finally, Section 7 draws the conclusions and outlines potential future directions for this research.

2. Related Work

2.1. Federated Learning

Federated learning (FL) has been widely studied as a solution to the challenges of decentralized machine learning. Traditional FL models, such as those introduced by McMahan et al. in their seminal work on federated averaging (FedAvg), allow multiple clients to collaboratively train a global model without sharing their raw data [1]. This method preserves data privacy by keeping data on local devices and only exchanging model parameters, thus mitigating the risk of data exposure. However, this approach also presents significant challenges, particularly in environments with heterogeneous participants, where varying computational power and data distribution lead to communication inefficiencies and model convergence issues [19,20].

Several works have aimed to improve the communication efficiency of federated learning. For instance, FedProx introduces a proximal term in the optimization process to address heterogeneity in data and client computational power [21]. Other approaches, such as model compression techniques and asynchronous updates, reduce the amount of data exchanged between the clients and the server [22,23,24]. Despite these advances, federated learning continues to struggle with scalability and communication overhead when deployed across a large number of heterogeneous devices.

In terms of privacy protection, differential privacy [25,26] and secure multi-party computation [27,28] have been integrated into FL to enhance the security of shared models. However, while these techniques protect data privacy, they often introduce additional computational overhead, making the learning process slower and more complex [29,30]. Additionally, traditional federated learning systems assume a trusted central aggregator, which can be a vulnerability if the central server is compromised.

2.2. Blockchain in Federated Learning

Blockchain technology has emerged as a promising solution to address several of the limitations of traditional federated learning [15,31,32]. With its decentralized and immutable nature, blockchain provides a transparent and tamper-proof ledger that ensures the integrity of model updates and promotes trust among participants. Several studies have explored the integration of blockchain with federated learning to decentralize trust and improve the security of the learning process [33,34,35].

One of the most prominent benefits of blockchain in federated learning is the ability to record all interactions and model updates on a shared ledger, enabling traceability and auditability. This ensures that any attempt to tamper with the model or data is easily detected. Smart contracts can be used to automate the verification of model updates and to enforce compliance with predefined rules, making the federated learning process more secure and trustworthy [36].

However, the integration of blockchain in FL also presents challenges. First, scalability is a major concern, as blockchain’s consensus mechanisms can introduce delays in environments with frequent model updates. This makes it difficult to achieve real-time security and efficiency. Second, the combination of blockchain with federated learning requires cross-chain communication, particularly in systems with multiple private chains, which can lead to resource management issues and further increase communication overhead [37,38].

2.3. Challenges in Existing Systems

While the integration of blockchain into federated learning has shown great potential, several challenges remain unresolved:

• Real-Time Security: Blockchain’s consensus algorithms, while ensuring security, can introduce latency, making it difficult to achieve real-time verification of model updates. This is particularly problematic in time-sensitive applications such as real-time health monitoring and autonomous driving.
• Cross-Chain Communication: In blockchain-based federated learning systems that use multiple private chains, ensuring efficient and secure communication between these chains and the central management chain is a challenge. Existing methods struggle with optimizing cross-chain transactions and managing resources effectively.
• Resource Management: Managing computational and communication resources across heterogeneous devices is complex. Blockchain, with its decentralized architecture, requires additional computational resources for maintaining the ledger and executing consensus protocols, which can further exacerbate the resource limitations of certain federated learning participants.

In summary, while blockchain enhances the security and trustworthiness of federated learning, it introduces new challenges related to efficiency, scalability, and resource management. Further research is needed to optimize blockchain-based federated learning systems, particularly in the areas of cross-chain communication and real-time security, to fully realize their potential.

3. Preliminary

3.1. Blockchain Basics

Blockchain technology is a distributed ledger that maintains a continuously growing list of ordered records, called blocks, which are linked using cryptographic techniques. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data, making the chain tamper-resistant and immutable.

In this work, we focus on consortium blockchains, which are semi-decentralized networks managed by a group of trusted participants. Formally, let $P=\{p_1,p_2,\dots ,p_n\}$ represent the set of participants in the consortium blockchain. Each participant $p_i\in P$ is granted permission to read and validate transactions. The blockchain’s state is updated via a consensus algorithm, typically Proof of Authority (PoA) or Byzantine Fault Tolerance (BFT), ensuring that a majority of participants agree on the blockchain’s state at any time.

Table 1. Performance comparison of blockchain types.

Feature	Public Blockchain	Consortium Blockchain	Hybrid Blockchain
Transaction Throughput (TPS)	Low (10–20)	High (200–1000)	Medium (50–200)
Latency (ms)	High (minutes to hours)	Low (seconds)	Medium (seconds to minutes)
Resource Usage	High	Low	Medium
Consensus Mechanism	PoW/PoS	PoA	Combination of PoW/PoA
Energy Consumption	High	Low	Medium
Privacy	Minimal	High	Moderate
Scalability	Limited	High	Moderate
Cost	High	Low	Moderate

presents a comparison of public, consortium, and hybrid blockchains based on critical features such as transaction throughput, latency, resource usage, privacy, scalability, and cost. The consortium blockchain was selected for the proposed system based on the following considerations:

• Efficiency and Scalability: Consortium blockchains achieve significantly higher transaction throughput (200–1000 TPS) and lower latency (seconds) compared to public blockchains, making them suitable for federated learning, where frequent model updates are required.
• Privacy and Security: Consortium blockchains restrict access to authorized participants, ensuring a high level of privacy critical for domains like healthcare and finance. Public blockchains, in contrast, expose all transaction data to the network, which compromises privacy.
• Cost-Effectiveness: Consortium blockchains operate on lightweight consensus mechanisms (e.g., Proof of Authority), avoiding the energy-intensive processes of public blockchains, such as Proof of Work, thereby reducing operational costs.
• Trust Model: The semi-trusted nature of consortium blockchains aligns well with federated learning, where participants (e.g., hospitals, financial institutions) are known entities. A fully decentralized trust model, as in public blockchains, is unnecessary in such environments.

Smart contracts, denoted as $SC$, are self-executing contracts with the terms of the agreement directly encoded into the blockchain. In the federated learning system, a smart contract $S{C}_{FL}$ governs the interactions between participants. Let ${\mathcal{M}}_i$ represent the local model of participant $p_i$. The smart contract ensures that only verified updates ${\mathcal{M}}_i^{\mathrm{update}}$ are integrated into the global model ${\mathcal{M}}_{\mathrm{global}}$ based on pre-defined rules.

Thus, the blockchain maintains security and trust using the following:

• Decentralized trust: No single participant controls the ledger.
• Immutability: Past model updates are irreversible.
• Smart contract enforcement: Automation of model verification and aggregation.

3.2. Federated Learning Architecture

Federated Learning (FL) is a decentralized machine learning framework where multiple clients collaboratively train a global model without sharing their raw data. Each client $p_i$ trains a local model ${\mathcal{M}}_i$ on its private dataset $D_i$, and the model parameters ${\theta }_i$ are sent to a central aggregator to update the global model ${\mathcal{M}}_{\mathrm{global}}$.

Formally, let:

• $P=\{p_1,p_2,\dots ,p_n\}$ represent the set of participants;
• ${\theta }_i^{\left(t\right)}$ denote the local model parameters of participant $p_i$ at training round t;
• $\mathcal{A}$ be the aggregation function used to update the global model.

The update process for the global model is defined as

$${\theta }_{\mathrm{global}}^{(t+1)}=\mathcal{A}({\theta }_1^{\left(t\right)},{\theta }_2^{\left(t\right)},\dots ,{\theta }_n^{\left(t\right)})$$

where ${\theta }_{\mathrm{global}}^{(t+1)}$ represents the updated global model parameters after aggregation at round $t+1$.

Each client solves a local optimization problem:

$${\theta }_i^{(t+1)}=arg\underset{{\theta }_i}{min}{\mathcal{L}}_i({\theta }_i;D_i)$$

where ${\mathcal{L}}_i$ is the local loss function specific to the data $D_i$ of participant $p_i$.

The global update process repeats until convergence, typically following a predefined number of rounds or a convergence threshold on the global loss function ${\mathcal{L}}_{\mathrm{global}}$. In the traditional FL setup, the aggregation function $\mathcal{A}$ is often a weighted average:

$$\mathcal{A}({\theta }_1,{\theta }_2,\dots ,{\theta }_n)=\sum _{i=1}^n{\displaystyle \frac{|D_i|}{{\sum }_{j=1}^n\left|D_j\right|}}{\theta }_i$$

where $|D_i|$ denotes the size of the local dataset of participant $p_i$.

3.3. Challenges in Secure Federated Learning

While FL provides privacy by keeping data local, several challenges persist, particularly in ensuring security and efficient model updates.

• Privacy Risks: Although FL prevents raw data from being shared, the exchange of model parameters ${\theta }_i$ can still leak information about the local data. For instance, membership inference attacks allow adversaries to infer whether specific data samples were part of a participant’s dataset. Mathematically, given a set of model updates $\Theta =\{{\theta }_1,{\theta }_2,\dots ,{\theta }_n\}$, an adversary can compute gradients ${\nabla }_{{\theta }_i}$ and exploit them to reconstruct private information from $D_i$.
• Malicious Data and Model Poisoning: A participant may upload poisoned model parameters ${\theta }_i^{\mathrm{poison}}$ to corrupt the global model. The goal of an adversary $p_{\mathrm{mal}}$ is to maximize the global loss ${\mathcal{L}}_{\mathrm{global}}$ by sending manipulated parameters:

  $${\theta }_{\mathrm{mal}}^{(t+1)}={\theta }_{\mathrm{mal}}^{\left(t\right)}+\delta$$

  where $\delta$ represents the adversarial perturbation that negatively influences model performance.
• Communication Bottlenecks: In FL, model parameters must be exchanged between the participants and the central server during each training round. The total communication cost $C_{\mathrm{comm}}$ can be expressed as

  $$C_{\mathrm{comm}}=\sum _{i=1}^n\left|{\theta }_i\right|·N_{\mathrm{rounds}}$$

  where $|{\theta }_i|$ is the size of the model parameters transmitted by participant $p_i$, and $N_{\mathrm{rounds}}$ is the number of communication rounds. In large-scale settings with many participants and rounds, this communication cost can become a bottleneck.
• Asynchronous Updates and System Heterogeneity: In practice, participants may have different computational capabilities and network conditions, leading to asynchronous updates. Let ${\tau }_i$ represent the local computation time of participant $p_i$, and ${\tau }_{\mathrm{global}}$ be the time required for a global aggregation round. The straggler effect arises when ${max}_i{\tau }_i\gg {min}_i{\tau }_i$, slowing down the overall learning process and leading to suboptimal global model updates.

3.4. Formal Problem Definition

To address these challenges, we define the federated learning problem with blockchain integration as follows:

• Objective: Minimize the global loss function ${\mathcal{L}}_{\mathrm{global}}$ under secure, privacy-preserving conditions using blockchain for model aggregation and participant validation.
• Constraints:

  –

  Ensure ${\theta }_{\mathrm{global}}^{\left(t\right)}$ is updated only with verified, non-malicious updates.

  –

  Minimize communication costs $C_{\mathrm{comm}}$.

  –

  Maintain privacy by preventing information leakage through model updates.

The formal optimization problem can be expressed as

$$\underset{\Theta }{min}{\mathcal{L}}_{\mathrm{global}}(\Theta ),\mathrm{subject}\mathrm{to}{\theta }_i^{\mathrm{update}}\in {\mathcal{SC}}_{FL},C_{\mathrm{comm}}\le C_{max},\mathrm{privacy}\left({\theta }_i\right)\ge {ϵ}_{\mathrm{DP}}$$

where ${\mathcal{SC}}_{FL}$ denotes the set of model updates validated by the smart contract, $C_{max}$ is the maximum allowable communication cost, and ${ϵ}_{\mathrm{DP}}$ represents a differential privacy bound ensuring that the privacy leakage remains within acceptable limits.

4. Proposed Scheme

4.1. System Architecture

The proposed system integrates federated learning with consortium blockchain technology, ensuring secure, transparent, and efficient model training across distributed participants. The architecture is composed of two key components: a Central Management Chain (CMC) and multiple Private Chains grouped by participants’ computational power, as Figure 1 shows. Grey boxes represent leader nodes that communicate with the CMC, white boxes denote ordinary nodes in private chains responsible for local model training, and arrows indicate the flow of model parameters and updates within and across chains.

• Central Management Chain: This is the core blockchain that manages global model aggregation and cross-chain communication. It acts as the orchestrator of the entire system, receiving updates from private chains and executing smart contracts to ensure model consistency and security. The CMC records global model parameters and logs all transactions for auditable and transparent operations.
• Private Chains: Each private chain is formed by a group of participants with similar computational power. Participants train local models on their respective datasets, and model parameters are periodically shared within their private chain. Once the local models are updated and validated, the private chain sends aggregated model updates to the CMC.

Let $P_i=\{p_1,p_2,\dots ,p_m\}$ represent the set of participants in the i-th private chain, where all participants share similar computational resources. These private chains are isolated from each other but communicate with the CMC through smart contracts and routing protocols.

The architecture ensures that participants with different levels of computational power are grouped appropriately, optimizing both communication efficiency and model update frequencies across the system.

4.2. Cross-Chain Communication

Cross-chain communication is a critical aspect of the proposed architecture. Communication between the private chains and the central management chain is facilitated through cross-chain routing protocols and smart contracts. This setup ensures secure and efficient transfer of model updates between chains.

• Routing Protocols: Cross-chain routing is responsible for handling requests and data exchange between the CMC and private chains. When a private chain completes its local model aggregation, the routing protocol forwards the aggregated parameters to the CMC. Similarly, the CMC, after updating the global model, disseminates the new model parameters to all private chains through the routing protocol.
• Smart Contracts: Smart contracts automate the validation and management of model updates. Specifically, the Model Update Contract (MUC) ensures that the model updates sent from private chains meet predefined criteria before being incorporated into the global model, as Algorithm 3 shows below. Each cross-chain communication instance is logged using smart contracts to ensure transparency and accountability.

Let $S{C}_{\mathrm{MUC}}$ denote the smart contract responsible for verifying model updates. The process can be described as

$${\theta }_{\mathrm{global}}^{(t+1)}=S{C}_{\mathrm{MUC}}({\theta }_1^{\left(t\right)},{\theta }_2^{\left(t\right)},\dots ,{\theta }_n^{\left(t\right)})$$

where ${\theta }_{\mathrm{global}}^{(t+1)}$ represents the updated global model parameters after validation and aggregation.

4.3. Model Update Process

The model update process follows a hierarchical structure involving both private chains and the CMC, as Figure 2 shows. The steps in this process are outlined below:

• Local Model Training: Each participant $p_i$ in a private chain trains a local model ${\mathcal{M}}_i$ on its dataset $D_i$. After completing local training, each participant shares its model parameters ${\theta }_i$ with other members in the same private chain.
• Private Chain Aggregation: Within each private chain $P_i$, the participants’ model parameters are aggregated using an averaging function ${\mathcal{A}}_i$, forming the private chain’s local global model ${\theta }_{\mathrm{local},i}$:

  $${\theta }_{\mathrm{local},i}^{(t+1)}={\mathcal{A}}_i({\theta }_1^{\left(t\right)},{\theta }_2^{\left(t\right)},\dots ,{\theta }_m^{\left(t\right)})$$

  where ${\theta }_{\mathrm{local},i}$ represents the aggregated model parameters from the private chain. The process is shown in Figure 3.
• Cross-Chain Communication to CMC: The aggregated model from each private chain is sent to the CMC via the cross-chain routing protocol. The CMC aggregates these models using the weighted aggregation function ${\mathcal{A}}_{\mathrm{global}}$:

  $${\theta }_{\mathrm{global}}^{(t+1)}={\mathcal{A}}_{\mathrm{global}}({\theta }_{\mathrm{local},1}^{\left(t\right)},{\theta }_{\mathrm{local},2}^{\left(t\right)},\dots ,{\theta }_{\mathrm{local},k}^{\left(t\right)})$$
  The global model ${\theta }_{\mathrm{global}}$ is updated by weighting the contributions from each private chain based on their computational power.
• Redistribution of Global Model: Once the global model ${\theta }_{\mathrm{global}}$ is updated, it is distributed back to all private chains. Each participant receives the updated global model, which it uses as the starting point for the next round of local training.

This iterative process continues until the global model converges, ensuring that local models are continuously refined while maintaining privacy and security.

4.4. Computational Power-Based Chain Grouping

In order to optimize both communication efficiency and model update frequency, participants are grouped into private chains based on their computational power. This method, referred to as Computational Power-Based Chain Grouping, ensures that participants with similar resources work together, reducing the disparity in model training times and update frequencies, as Figure 4 shows.

Let $C\left(p_i\right)$ denote the computational power of participant $p_i$, and let PrivateChain_j represent a private chain with participants having similar computational power. The grouping is defined as

$${\mathit{PrivateChain}}_j=\{p_i\mid {\alpha }_j\le C\left(p_i\right)\le {\beta }_j\}$$

where ${\alpha }_j$ and ${\beta }_j$ define the computational power range for chain j. This method ensures that model updates within each private chain are synchronized, reducing delays caused by stragglers and improving the overall efficiency of the system.

Additionally, participants with higher computational power contribute more frequently to the global model updates. This is facilitated by varying the update frequency of different private chains based on the computational resources of their members.

4.5. Smart Contracts

In the proposed consortium blockchain-based federated learning (CBFL) system, various smart contracts are deployed to handle tasks such as participant management, computational power-based grouping, and model aggregation. These contracts ensure the transparency, security, and efficiency of the federated learning process. Below, we detail each contract with its respective pseudocode to clarify the operations and functions involved.

4.5.1. Supervisory Contract

In a trusted federated learning framework, the Supervisory Contract is responsible for recording and supervising all operations within the system. By logging detailed information of each operation—such as the participant’s address, operation type, result, and timestamp—the Supervisory Contract ensures transparency and traceability. All log entries are encrypted using the management chain’s public key to guarantee that only authorized participants can view the data. This contract operates under a “pre-emptive prevention, real-time monitoring, and post-event accountability” framework to prevent and detect potential malicious activities. The pseudocode for the Supervisory Contract is provided below as Algorithm 1.

Algorithm 1 Supervisory Contract

1: contract SupervisoryContract 2: function logOperation(p, $op$, $res$, t) 3:     $L=\mathrm{encrypt}(p,op,res,t,k_{\mathrm{mc}})$ {Encrypt log L with management chain key $k_{\mathrm{mc}}$} 4:     $\mathrm{store}\left(L\right)$ 5: end function 6: $\hspace{1em}$ 7: function monitorOperations(p) 8:     ${\mathcal{L}}_p=\mathrm{retrieveLogs}\left(p\right)$ 9: for all $l\in {\mathcal{L}}_p$ do 10:     if l indicates suspicious activity then 11:      alertManagement(l) 12:     end if 13: end for 14: end function

4.5.2. Computational Power Registration Contract

The Computational Power Registration Contract handles the admission and grouping of participants based on their computational power. This contract assigns each new participant to an appropriate computational power group by assessing their computational capabilities $C\left(p\right)$ and assigning them to private chains with participants of similar power levels. A hyperparameter $\gamma$ is introduced to control the strictness of computational power alignment: lower values of $\gamma$ enforce stricter grouping. This approach improves communication efficiency and optimizes model update frequency. The pseudocode for the Computational Power Registration Contract is shown below as Algorithm 2.

Algorithm 2 Computational Power Registration Contract

1: contract ComputationalPowerRegistrationContract 2: function registerParticipant(p, $C\left(p\right)$) 3: if  $\mathrm{checkTrustworthiness}\left(p\right)$  then 4:    group ← assignGroup($C\left(p\right)$) 5:    if group does not exist then 6:      createNewPrivateChain(group) 7:    end if 8:    addParticipantToGroup(p, group) 9: else 10:    rejectParticipant(p) 11: end if 12: end function 13: $\hspace{1em}$ 14: function assignGroup($C\left(p\right)$) 15:     for each power range $({\alpha }_j\gamma ,{\beta }_j\gamma )$ 16:       if ${\alpha }_j\gamma \le C\left(p\right)\le {\beta }_j\gamma$ 17:          return group j

4.5.3. Model Update Contract

The Model Update Contract is responsible for aggregating model parameters from each private chain to form a global model on the central management chain. To ensure that the contributions of participants from different computational power levels are proportionate, this contract applies weighted averaging, assigning specific weights based on each chain’s computational power level. The resulting global model is distributed to each private chain to support the next round of training. This layered aggregation method maintains both efficiency and trustworthiness within the CBFL system. The pseudocode is presented below as Algorithm 3.

Algorithm 3 Model Update Contract

1: contract ModelUpdateContract 2: function updateGlobalModel($\left\{M_j\right\}$) 3: $\widehat{M}=0$ {Initialize weighted global model} 4: for all j in $\{1,2,\dots ,k\}$ do 5:  $w_j=\mathrm{getWeight}\left({\mathrm{compLevel}}_j\right)$ 6:  $\widehat{M}=\widehat{M}+M_j·w_j$ 7: end for 8: $M_{\mathrm{global}}={\displaystyle \frac{\widehat{M}}{{\sum }_{j=1}^k{w}_j}}$ 9: distributeModel($M_{\mathrm{global}}$) 10: end function

4.5.4. Private Chain Model Fusion Contract

The Private Chain Model Fusion Contract facilitates the aggregation of local model parameters within each private chain to produce a sub-global model. Each participant uploads its local model parameters after each training round, and the contract computes the average to form the sub-global model for that chain. This sub-global model is then sent to the central management chain for further aggregation. This contract not only consolidates models within each chain but also prepares them for secure transmission across chains via a leader node. The pseudocode is shown below as Algorithm 4.

Algorithm 4 Private Chain Model Fusion Contract

1: contract PrivateChainModelFusionContract 2: function fuseModels() 3: $M_{\mathrm{local}}=0$ 4: $n=\left|\right\{p_i\left\}\right|$ {Number of participants in the private chain} 5: for all $p_i\in \{p_1,p_2,\dots ,p_n\}$ do 6:  $M_{\mathrm{local}}=M_{\mathrm{local}}+M_{p_i}$ 7: end for 8: $M_{\mathrm{fused}}={\displaystyle \frac{M_{\mathrm{local}}}{n}}$ 9: storeSubGlobalModel($M_{\mathrm{fused}}$) 10: end function 11: $\hspace{1em}$ 12: function sendToManagementChain() 13: leaderNode ← selectLeaderNode() 14: leaderNode.sendModelToManagementChain($M_{\mathrm{fused}}$) 15: end function

4.6. Security Features

To maintain security throughout the federated learning process, several mechanisms are employed:

• Auditable Logging: Every interaction, including model updates and cross-chain communications, is logged on the blockchain. These logs are immutable and can be audited to ensure that all actions adhere to predefined protocols.
• Consensus Algorithms: The system uses a Proof of Authority (PoA) consensus algorithm in the central management chain, ensuring that only trusted nodes validate model updates and cross-chain communications. The PoA algorithm minimizes the risk of malicious actors influencing the system while ensuring efficiency.
• Smart Contract-Based Regulation: Smart contracts enforce the rules governing the federated learning process, including participant validation, model update criteria, and reward mechanisms. These contracts ensure that only valid model updates are incorporated into the global model and that participants follow the agreed-upon protocols.
• Tamper-Resistant Model Updates: By utilizing blockchain’s immutability, the system ensures that, once a model update is recorded, it cannot be altered. This prevents tampering with model updates, further ensuring the integrity of the global model.

These security features collectively ensure that the system remains trustworthy, even in the presence of potentially malicious participants.

5. Security Analysis

5.1. Trust Model

The proposed federated learning system operates under a decentralized trust model, where no single participant or entity has complete control over the model aggregation process. This trust model is enforced through the use of blockchain technology, which ensures the data integrity, transparency, and auditability of all operations.

• Data Integrity: Every transaction, including model updates and participant interactions, is recorded immutably on the blockchain. Let $T_i^{\left(t\right)}$ represent the transaction recording the model update ${\theta }_i^{\left(t\right)}$ from participant $p_i$ at round t. Each transaction $T_i^{\left(t\right)}$ is linked to its predecessor via a cryptographic hash $h\left(T_{i-1}^{(t-1)}\right)$, ensuring that the history of updates cannot be altered:

  $$h\left(T_i^{\left(t\right)}\right)=H(T_{i-1}^{(t-1)},{\theta }_i^{\left(t\right)},\mathrm{timestamp},\mathrm{other}\mathrm{metadata})$$

  where $H(·)$ represents the cryptographic hash function. This guarantees that any tampering with past records will break the chain’s integrity.
• Transparency: All participants can verify the sequence of transactions and model updates stored on the blockchain. The transparency of the system is achieved by allowing all participants to audit the blockchain’s contents, which include the model updates and decisions made by the smart contracts.
• Auditability: Smart contracts enforce predefined rules governing model updates. Let $S{C}_{\mathrm{MUC}}$ be the Model Update Contract, which verifies each model update before it is incorporated into the global model:

  $$S{C}_{\mathrm{MUC}}\left({\theta }_i^{\left(t\right)}\right)=\left\{\begin{array}{cc}\mathrm{valid},\hfill & \mathrm{if}\mathrm{update}\mathrm{satisfies}\mathrm{predefined}\mathrm{criteria}\hfill \\ \mathrm{invalid},\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$
  All validations are logged on the blockchain, providing a transparent and auditable history of model updates. This ensures that only valid updates are included in the final model.

5.2. Privacy Protection

The proposed federated learning system enhances privacy protection in the following ways:

• Local Data Retention: Participants in the system do not share raw data; instead, they retain their data locally and only share model parameters. Let $D_i$ represent the local dataset of participant $p_i$. Instead of sharing $D_i$, each participant trains a local model ${\mathcal{M}}_i$ and shares only the parameters ${\theta }_i$. This ensures that sensitive information in $D_i$ is never exposed to other participants or the central authority.
• Decentralized Data Exchange: The use of blockchain enables decentralized, secure data exchanges. Model parameters ${\theta }_i$ are exchanged through the blockchain using cryptographic techniques that ensure the confidentiality of the updates. Each update is encrypted before being transmitted over the blockchain, and only authorized participants with the correct decryption keys can access the model updates. Let $E_k\left({\theta }_i\right)$ represent the encryption of ${\theta }_i$ with key k, ensuring that

  $$\mathrm{Only}\mathrm{participants}\mathrm{with}\mathrm{key}k\mathrm{can}\mathrm{decrypt}{\theta }_i=D_k\left(E_k\left({\theta }_i\right)\right)$$
  This prevents unauthorized access to model updates and ensures that, even in the event of an eavesdropping attack, no useful information is leaked.
• Differential Privacy: To further enhance privacy, the system can employ differential privacy techniques to protect participants’ data from being inferred through model updates. Let ${\theta }_i^{\mathrm{priv}}$ represent a differentially private version of the model parameters. The differential privacy mechanism adds noise $\eta$ to the model parameters before they are shared:

  $${\theta }_i^{\mathrm{priv}}={\theta }_i+\eta$$

  where $\eta \sim \mathcal{N}(0,{\sigma }^2)$ is Gaussian noise with variance ${\sigma }^2$. This ensures that the contribution of any individual data point in $D_i$ is obfuscated, providing an additional layer of privacy protection.

5.3. Resilience to Attacks

The system is designed to be resilient against several types of attacks, including model poisoning, data tampering, and collusion among malicious participants, among others.

5.3.1. Defense Against Model Poisoning Attacks

In a model poisoning attack, a malicious participant attempts to corrupt the global model by sending manipulated model updates. Let ${\theta }_{\mathrm{mal}}^{\left(t\right)}$ represent the poisoned model parameters sent by a malicious participant $p_{\mathrm{mal}}$. The goal of the adversary is to maximize the global loss function ${\mathcal{L}}_{\mathrm{global}}$ by corrupting the global model. However, the use of blockchain mitigates this attack in two ways:

• Cross-chain validation: Model updates are aggregated within each private chain and verified by the Model Update Contract $S{C}_{\mathrm{MUC}}$. This contract checks the consistency of the updates, ensuring that poisoned updates do not deviate significantly from the valid updates sent by other participants:

  $$S{C}_{\mathrm{MUC}}\left({\theta }_{\mathrm{mal}}^{\left(t\right)}\right)=\left\{\begin{array}{cc}\mathrm{invalid},\hfill & \mathrm{if}|{\theta }_{\mathrm{mal}}^{\left(t\right)}-\mathbb{E}\left[{\theta }^{\left(t\right)}\right]|>\delta \hfill \\ \mathrm{valid},\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

  where $\mathbb{E}\left[{\theta }^{\left(t\right)}\right]$ is the expected value of the valid model updates and $\delta$ is a threshold parameter.
• Weighted Aggregation: Even if a poisoned update is included, the blockchain’s consensus and aggregation mechanisms reduce its impact on the global model by weighting contributions based on the participant’s trust score and computational power. Therefore, the effect of any individual malicious participant is minimized.

5.3.2. Defense Against Data Tampering

Any attempt to tamper with model updates after they have been recorded on the blockchain will be detected due to the immutability of the blockchain. Suppose an adversary tries to replace a valid model update ${\theta }_i^{\left(t\right)}$ with a tampered version ${\theta }_i^{*\left(t\right)}$. Since every transaction is linked to the previous one via cryptographic hashes, the change in ${\theta }_i^{*\left(t\right)}$ would invalidate the hash $h\left(T_i^{\left(t\right)}\right)$, thus revealing the tampering attempt:

$$h\left({\theta }_i^{*\left(t\right)}\right)\ne h\left({\theta }_i^{\left(t\right)}\right)$$

This ensures that all recorded model updates are verifiable and secure from tampering.

5.3.3. Defense Against Collusion Among Malicious Participants

Coordinated manipulations by malicious participants pose a significant threat to federated learning systems. These attacks occur when multiple malicious participants collaborate to submit fraudulent updates, amplifying the impact of each malicious participant. This makes it much harder to detect and defend against the attack.

To address this threat, we introduce a behavior analysis and monitoring mechanism that tracks the behavior of participants over time. The system monitors update patterns and flags suspicious activity that deviates from normal behavior. If a significant number of participants exhibit similar suspicious behavior, the system detects a coordinated attack and triggers an additional validation step before model aggregation.

To prevent coordinated attacks, we utilize the Proof of Authority consensus algorithm, which ensures that only trusted nodes in the Central Management Chain can validate model updates. In the case of coordinated attacks, where malicious participants attempt to submit false updates in unison, the PoA consensus algorithm helps filter out such manipulations by requiring multiple trusted nodes to validate the updates.

When multiple participants collude to manipulate the global model, their updates must be validated by the trusted PoA nodes. If the updates deviate from the expected patterns, they are excluded from aggregation. This significantly reduces the impact of coordinated manipulations.

The PoA mechanism can be mathematically represented as follows:

$$R_{\mathrm{threshold}}=\sum _{i=1}^k{R}_i<R_{\mathrm{trusted}},$$

where $R_i$ is the reputation score of participant i and $R_{\mathrm{trusted}}$ is the total reputation score of trusted nodes. A coordinated attack is only successful if the reputation score of the colluding participants exceeds the allowed threshold, which is regularly monitored and updated to ensure the integrity of the model.

In addition to PoA, we implement a reputation-based aggregation system that assigns weights to participants based on their historical behavior. Participants with higher reputation scores are given greater influence on the global model, while malicious participants who attempt coordinated manipulations are downweighted or excluded.

The aggregation rule is adjusted as follows:

$${\mathcal{M}}_{\mathrm{global}}=\sum _{i=1}^n{\displaystyle \frac{R_i}{{\sum }_{j=1}^n{R}_j}}{\mathcal{M}}_i,$$

where $R_i$ is the reputation score of participant i and ${\mathcal{M}}_i$ is their model update. This weighted aggregation ensures that the global model is not disproportionately influenced by malicious participants, even in the presence of coordinated attacks.

5.3.4. Defense Against Adaptive Adversarial Attacks

Adaptive adversarial attacks are a form of attack where the adversary adjusts their strategy based on feedback from the system. In the context of federated learning, adversarial participants can subtly modify their updates over time, making their malicious behavior difficult to detect. These attacks are particularly dangerous because they can bypass static defenses, such as traditional model poisoning techniques, by exploiting weaknesses in the aggregation process.

To defend against adaptive adversarial attacks, we introduce a dynamic defense mechanism that continuously adapts to the evolving attack strategy. The core of this defense mechanism is a feedback-driven aggregation process, where model updates are dynamically weighted based on their historical contribution to the global model’s performance. If a participant’s updates start to deviate from expected patterns or lead to a degradation in model accuracy, the system reduces the weight of that participant’s contribution in subsequent aggregations.

The mathematical formulation of the dynamic weighting is as follows:

$${\mathcal{M}}_{\mathrm{global}}=\sum _{i=1}^n{w}_i\left(t\right){\mathcal{M}}_i,$$

where $w_i\left(t\right)$ is the dynamic weight of participant i at time t. This weight is computed based on the performance degradation observed over a period of time, ensuring that adaptive attacks are quickly detected and mitigated.

5.3.5. Defense Against Model Inversion Attack

Model inversion attacks aim to reconstruct the original training data from the outputs of the model. In our proposed system, we mitigate the risk of model inversion attacks using differential privacy.

Let $\mathcal{M}$ be the global model, and let x represent a training sample. The output of $\mathcal{M}$ on an input x is denoted as $\mathcal{M}\left(x\right)$. To provide privacy guarantees, we add noise to the model output using a differential privacy mechanism. Specifically, we add Gaussian noise with variance ${\sigma }^2$ to the model output:

$$\mathcal{M}\left(x\right)=f\left(x\right)+\mathcal{N}(0,{\sigma }^2),$$

where $f\left(x\right)$ represents the original model output and $\mathcal{N}(0,{\sigma }^2)$ is Gaussian noise with zero mean and variance ${\sigma }^2$. This ensures that the model output does not reveal sensitive information about any individual data point.

The level of privacy protection is quantified using ϵ-differential privacy, which guarantees that the output of the model does not change significantly when a single data point is added or removed from the training dataset. Formally, the model satisfies $ϵ$-differential privacy if

$$Pr[\mathcal{M}\left(x\right)=y]\le e^{ϵ}Pr[\mathcal{M}\left(x^{\prime }\right)=y],$$

for any pair of datasets x and $x^{\prime }$ differing by one data point.

To ensure that our model provides strong privacy protection, we select $\sigma$ such that the privacy guarantee holds with a desired $ϵ$ value, which bounds the information leakage to attackers. This mathematical formulation provides formal security guarantees against model inversion attacks.

5.3.6. Defense Against Membership Inference Attack

Membership inference attacks aim to determine whether a given data point x was part of the training dataset. To mitigate this attack, we apply a regularization technique to the training process, which reduces the model’s overfitting to the training data.

We quantify the risk of membership inference using the following definition: the model’s output for a data point x is a probability distribution over the possible classes. Let $\mathcal{M}\left(x\right)$ be the model output for a given sample x, and let $\mathcal{M}\left(x^{\prime }\right)$ be the model output for a sample $x^{\prime }$ not in the training set. The difference between these outputs can be used to detect membership:

$$\Delta =\left|Pr[\mathcal{M}\left(x\right)\in {\mathcal{D}}_{train}]-Pr[\mathcal{M}\left(x^{\prime }\right)\in {\mathcal{D}}_{train}]\right|.$$

We aim to minimize $\Delta$, ensuring that the model cannot distinguish between training and non-training samples, thereby preventing membership inference attacks. By employing regularization techniques, we ensure that $\Delta$ remains small, reducing the model’s ability to disclose membership information.

Formally, this is achieved by minimizing the loss function with a regularization term:

$$\mathcal{L}={\mathcal{L}}_{\mathrm{original}}+{\lambda \left|\right|\theta \left|\right|}_2,$$

where ${\mathcal{L}}_{\mathrm{original}}$ is the original loss function, $\theta$ represents model parameters, and $\lambda$ is a regularization coefficient that controls the trade-off between the original loss and regularization. The regularization reduces the model’s sensitivity to individual training samples, thus mitigating the risk of membership inference.

5.3.7. Experimental Results and Analysis

To validate the effectiveness of our proposed defense mechanisms against various adversarial attacks, we conducted experiments using the FashionMNIST and CIFAR-10 datasets, which are widely adopted benchmarks in machine learning research. These datasets provide a challenging yet practical setting to evaluate the robustness of our proposed defense mechanisms, as they simulate real-world scenarios with diverse data distributions.

Table 2. Evaluation of attack resistance on FashionMNIST and CIFAR-10.

Attack Type	Dataset	ASR Without Defense (%)	ASR with Defense (%)	Model Accuracy (%)
Model Inversion	FashionMNIST	85	12	88.5
	CIFAR-10	80	15	87.5
Membership Inference	FashionMNIST	72	18	89.2
	CIFAR-10	70	20	87.8
Model Poisoning	FashionMNIST	55	15	90.1
	CIFAR-10	50	18	88.3

summarizes the attack success rates (ASRs) and model accuracy under various adversarial scenarios across the FashionMNIST and CIFAR-10 datasets. On FashionMNIST, the attack success rate (ASR) for model inversion decreased from 85% (baseline) to 12% after applying differential privacy. On CIFAR-10, the ASR reduced from 80% to 15%. These results demonstrate the effectiveness of our approach across datasets with varying complexity. On FashionMNIST, our regularization technique reduced the ASR for membership inference from 72% (baseline) to 18%. On CIFAR-10, the ASR decreased from 70% to 20%. The high model accuracy on both datasets (89.2% for FashionMNIST and 87.8% for CIFAR-10) indicates that the proposed defenses effectively mitigate attacks while preserving learning performance. On FashionMNIST, the ASR for model poisoning reduced from 55% (baseline) to 15%, while maintaining a model accuracy of 90.1%. On CIFAR-10, the ASR decreased from 50% to 18%, with a model accuracy of 88.3%. These results highlight the system’s robustness against malicious updates. The proposed defense mechanisms consistently demonstrate their effectiveness in mitigating model inversion, membership inference, and model poisoning attacks.

6. Performance Comparison and Evaluation

In this section, we evaluate the performance of our proposed consortium blockchain-based federated learning (CBFL) scheme using public datasets and compare it to traditional FL approaches. This evaluation focuses on key metrics such as communication efficiency, model accuracy, and security enhancements. We describe the experimental setup, present the results, and discuss the observed benefits and potential trade-offs.

6.1. Experimental Setup

1. Datasets: The evaluation uses two benchmark datasets, FashionMNIST and CIFAR-10, which are widely used in federated learning research. The FashionMNIST dataset consists of 60,000 training samples and 10,000 test samples, with each image being a 28 × 28 grayscale image of clothing items labeled from 0 to 9. The CIFAR-10 dataset contains 60,000 color images, each sized 32 × 32 pixels, categorized into 10 classes with 6000 images each. We partition the datasets into non-IID distributions using the Dirichlet distribution with varying parameters to simulate different real-world data distribution scenarios. Moreover, To evaluate the performance of our proposed blockchain-based federated learning system in real-world scenarios, we use two challenging datasets: ISIC 2017 Task 3 dataset: A dataset designed for lesion diagnosis classification, consisting of dermoscopic images with labels for different types of skin lesions, such as melanoma, benign nevi, and other dermatological conditions. NuCLS dataset: A large-scale dataset containing over 220,000 annotated nuclei from breast cancer images, used for the classification of different cell types, including malignant cancer cells, benign cells, and other cell classifications. Both datasets present complex classification tasks that involve a large variety of lesions or cell types, making them ideal benchmarks for testing the effectiveness of our blockchain-based federated learning system in medical image classification.

2. Hardware and Software: Experiments were conducted on a Linux server with the following specifications, as shown in

Table 3. Hardware and software setup.

Hardware and Software	Setup
CPU	Intel(R) Core(TM) i9-9900X CPU @ 3.50 GHz
Memory	128 G
GPU	NVIDIA GeForce RTX 2080 Ti × 8
CUDA Version	12.0
Programming Language	python3.9
Operating System	Ubuntu 18.04.6 LTS
Federated Learning Framework	Pytorch 1.10.2

.

3. Model: We employed the LeNet-5 convolutional neural network (CNN) for image classification, which includes convolutional and pooling layers followed by fully connected layers. The model structure allows for efficient feature extraction and classification, making it suitable for benchmark datasets like FashionMNIST and CIFAR-10.

4. Evaluation Metrics:

• Model Accuracy: The primary evaluation metric is the test set accuracy, calculated as the ratio of correctly classified images to the total number of test samples.
• Convergence Speed: To measure communication efficiency, we use the Time of Accuracy (ToA@x) metric, where x represents a target accuracy. The ToA@x metric records the number of communication rounds needed to reach a specified accuracy level.
• Security Overhead: We also measure the computational overhead introduced by blockchain integration, particularly in cross-chain communication and validation processes.

6.2. Experimental Results

6.2.1. Effect of Blockchain Integration on Communication Efficiency and Accuracy

We first evaluate the impact of the proposed consortium blockchain-based federated learning (CBFL) scheme on model performance. The CBFL approach is compared against traditional FedAvg without blockchain integration, assessing its effects on accuracy and communication efficiency under different data distributions and various levels of computational power alignment, controlled by the parameter $\gamma$. This parameter $\gamma$ determines the strictness of computational power alignment in the private chains, where a smaller $\gamma$ implies stricter alignment among participants’ computational power and is expected to optimize communication efficiency and model update frequency. To ensure a fair comparison, FedAvg uses the same number of participant groups as CBFedAvg, but it does not utilize the $\gamma$ parameter for group formation. Instead, FedAvg participants are divided into groups of equal size, matching the number of groups in CBFedAvg for each experiment.

The computational power of each participant $C\left(p_i\right)$ can be estimated based on their resources (e.g., CPU cores, memory, GPU units). We introduce a hyperparameter $\gamma$ to flexibly control the computational power alignment strictness within private chains. By setting a computational power threshold range, $\gamma$ adjusts the distribution of participants across different computational power groups:

$${\mathrm{PrivateChain}}_j=\{p_i\mid {\alpha }_j·\gamma \le C\left(p_i\right)\le {\beta }_j·\gamma \}$$

where ${\alpha }_j$ and ${\beta }_j$ represent the computational power range for the j-th group, $C\left(p_i\right)$ is the computational power of participant i, and $\gamma$ is the hyperparameter adjusting participant alignment within this range. A smaller $\gamma$ enforces stricter alignment, ensuring participants within a private chain have similar computational capabilities. Conversely, a larger $\gamma$ allows for broader computational power ranges, resulting in looser alignment.

The experiments were conducted under various settings of $\gamma$ (e.g., $\gamma =0.5,1,2$) to group participants into private chains based on their computational power alignment. Figure 5 and Figure 6 show the training curves for different computational power alignment levels on FashionMNIST and CIFAR-10 datasets, respectively. In these two figures, FedAvg participants are divided into groups of equal size, matching the number of groups in CBFedAvg for each experiment. As shown in

Table 4. Training results for different computational power alignment levels.

Algorithm	Computational Power Alignment ($\mathit{\gamma }$)	Average Accuracy			Highest Accuracy			[email protected] [email protected]
		F-MNIST	CIFAR-10		F-MNIST	CIFAR-10		F-MNIST	CIFAR-10
FedAvg	-	0.8318	0.6498		0.8567	0.6809		393	-
CBFedAvg	$\mathit{\gamma }=\mathbf{0.5}$	0.8759	0.7254		0.8916	0.7375		90	210
FedAvg	-	0.8631	0.7046		0.8713	0.7121		175	669
CBFedAvg	$\mathit{\gamma }=\mathbf{1.0}$	0.8892	0.7468		0.8982	0.7609		72	173
FedAvg	-	0.8778	0.7115		0.8803	0.7153		127	462
CBFedAvg	$\mathit{\gamma }=\mathbf{2.0}$	0.8913	0.7401		0.8962	0.7506		95	186

, the introduction of the hyperparameter $\gamma$ allowed us to analyze its effects on model performance:

1. Small $\mathit{\gamma }$(e.g., $\mathit{\gamma }=\mathbf{0.5}$): This strict computational power alignment enhances model convergence speed and accuracy due to better alignment in participants’ computational power. For instance, in the FashionMNIST dataset, CBFedAvg achieved an average accuracy of 0.8759, a highest accuracy of 0.8916, and only required 90 communication rounds to reach the target accuracy. While strict alignment increases communication overhead, it significantly improves both convergence speed and accuracy.

2. Larger $\mathit{\gamma }$(e.g., $\mathit{\gamma }=\mathbf{2.0}$): Looser computational power alignment reduces communication overhead but results in a slight decrease in convergence speed and model accuracy. For example, in the CIFAR-10 dataset, CBFedAvg achieved an average accuracy of 0.7401, with [email protected] increasing to 186 rounds. This suggests that, although a larger $\mathit{\gamma }$ reduces communication costs, it may negatively impact model performance in terms of accuracy and convergence.

The selection of $\mathit{\gamma }$ should consider the computational resource heterogeneity among participants and the specific requirements of the application. The following guidelines are proposed:

• High accuracy and fast convergence: For applications requiring precise results and rapid convergence (e.g., healthcare diagnostics or financial forecasting), a smaller $\mathit{\gamma }$ (e.g., $\mathit{\gamma }=\mathbf{0.5}$) is recommended. This ensures strict computational power alignment, reducing variance within private chains and enhancing model consistency.
• Bandwidth-constrained or heterogeneous environments: In scenarios with limited communication bandwidth or highly diverse participant capabilities, a larger $\mathit{\gamma }$ (e.g., $\mathit{\gamma }=\mathbf{2.0}$) may be preferable to reduce communication overhead, even if convergence speed slightly decreases.
• Balanced trade-offs: For general-purpose federated learning tasks, a moderate $\mathit{\gamma }$ (e.g., $\mathit{\gamma }=\mathbf{1.0}$) provides a good balance between communication efficiency and model accuracy.

In summary, selecting an optimal $\mathit{\gamma }$ balances communication efficiency and model performance, allowing us to tailor computational power alignment to the specific requirements of federated learning environments.

6.2.2. Influence of IID and Non-IID Data on Performance

To assess the robustness of our consortium blockchain-based federated learning (CBFL) scheme under varying data distribution scenarios, we conducted experiments with different levels of data heterogeneity. The Dirichlet parameter $\mathit{\alpha }$ was set to simulate independent and identically distributed (IID) data, slightly IID ($\mathit{\alpha }=\mathbf{0.5}$), and worst-case non-IID ($\mathit{\alpha }=\mathbf{0.1}$) conditions. This parameter allows us to emulate real-world scenarios where data distributions among participants are often unbalanced.

The experimental setup followed these configurations:

• IID Scenario: All participants have an evenly distributed dataset, ideal for federated learning as all clients contribute equally to the global model.
• Slightly IID Scenario ($\mathit{\alpha }=\mathbf{0.5}$): Data are moderately skewed across participants, with some variability in data distribution. This scenario reflects a more practical setting wherein data are not uniformly distributed.
• Non-IID Scenario ($\mathit{\alpha }=\mathbf{0.1}$): Data distribution is highly uneven, with each participant having a limited subset of data classes. This represents the most challenging scenario for model convergence and accuracy.

The experimental results in

Table 5. Training results under different data distributions.

Dataset		FashionMNIST			CIFAR-10
		IID	$\mathit{\alpha }=\mathbf{0.5}$	$\mathit{\alpha }=\mathbf{0.1}$	IID	$\mathit{\alpha }=\mathbf{0.5}$	$\mathit{\alpha }=\mathbf{0.1}$
FedAvg	Average Accuracy	0.9118	0.8631	0.7522	0.8120	0.7046	0.6680
	Highest Accuracy	0.9127	0.8713	0.7811	0.8134	0.7121	0.6772
	[email protected] [email protected]	24	175	-	66	669	-
CBFedAvg	Average Accuracy	0.9308	0.9032	0.8366	0.8328	0.7459	0.7367
	Highest Accuracy	0.9315	0.9040	0.8417	0.8336	0.7508	0.7492
	[email protected] [email protected]	20	58	-	49	148	206

and Figure 7 and Figure 8 reveal several key insights.

1. IID Setting: Under the ideal IID condition, the CBFL scheme demonstrates a limited improvement in model accuracy compared to the traditional FedAvg algorithm. Specifically, the average accuracy improvement is 1.90% for FashionMNIST and 2.07% for CIFAR-10. This marginal gain occurs because, in this scenario, each participant’s data distribution is similar, minimizing the need for enhanced participant grouping mechanisms provided by CBFL.

2. Non-IID Setting ($\mathit{\alpha }=\mathbf{0.5}$): In the moderately heterogeneous data setting, the accuracy of the CBFL model is significantly higher than FedAvg. CBFL achieves an accuracy improvement of 4.01% for FashionMNIST and 4.12% for CIFAR-10, which confirms that CBFL’s enhanced participant grouping based on computational power-based chain grouping contributes to improved training results under slightly unbalanced data distributions.

3. Extreme Non-IID Setting ($\mathit{\alpha }=\mathbf{0.1}$): When the data are highly skewed, CBFL outperforms FedAvg with even greater accuracy gains of 8.45% for FashionMNIST and 6.87% for CIFAR-10. This shows that CBFL’s ability to select participants with more representative and balanced data significantly benefits the model’s overall accuracy. In this scenario, CBFL also demonstrates resilience by achieving the target accuracy more efficiently than FedAvg, reducing communication rounds by 69% on average.

In summary, the CBFL scheme consistently outperforms FedAvg, particularly in challenging non-IID conditions. These findings highlight CBFL’s robustness and efficacy in handling data heterogeneity, leveraging computational power-based chain grouping to optimize model training and improve convergence under diverse real-world data distribution scenarios. Our scheme shows enhanced accuracy and faster convergence in non-IID scenarios compared to traditional FedAvg, highlighting the consortium blockchain-based federated learning scheme’s ability to improve robustness under diverse data distributions.

6.2.3. Impact of Consortium Blockchain-Based Grouping with Different FL Algorithms

This section evaluates the adaptability and performance optimization provided by the consortium blockchain-based grouping (CBG) module when integrated with various federated learning (FL) aggregation algorithms, including FedAvg [1], FedProx [21], and FedIR [39]. While these algorithms typically rely on random participant grouping, the integration of our blockchain-based grouping mechanism allows for more strategic participant grouping, which can significantly enhance model accuracy and communication efficiency, especially under non-IID conditions. The CBG module is designed to be modular and can be decoupled and integrated with different FL methods to demonstrate its compatibility across multiple aggregation strategies.

As shown in

Table 6. Performance comparison of different FL algorithms with and without CBG integration.

Algorithm	Average Accuracy		Highest Accuracy		[email protected] [email protected]
	F-MNIST	CIFAR-10	F-MNIST	CIFAR-10	F-MNIST	CIFAR-10
FedAvg	0.8631	0.7046	0.8713	0.7121	175	669
FedProx	0.8747	0.7100	0.8802	0.7192	143	401
FedIR	0.8786	0.7202	0.8827	0.7266	106	293
CBFedAvg	0.9032	0.7459	0.9042	0.7508	58	148
CBFedProx	0.9061	0.7627	0.9153	0.7708	53	139
CBFedIR	0.9118	0.7823	0.9186	0.7854	48	118

, the integration of the CBG module significantly improves the performance of each baseline FL algorithm in terms of both model accuracy and communication efficiency. Figure 9 and Figure 10 show the training curves of each algorithm on FashionMNIST and CIFAR-10 datasets, respectively. The following insights can be drawn from the results:

1. Performance Gains with FedAvg: When integrating CBG with FedAvg (denoted as CBFedAvg), the average accuracy on the FashionMNIST and CIFAR-10 datasets improved from 0.8631 to 0.9032 and from 0.7046 to 0.7459, respectively. This improvement is particularly notable given that FedAvg typically relies on random participant grouping, which can lead to suboptimal accuracy under non-IID conditions. By using CBG, participant grouping becomes more strategic, contributing to better model convergence and accuracy.

2. Optimization with FedProx and FedIR: The performance of both FedProx and FedIR is further enhanced by CBG integration. For example, CBFedProx achieved an average accuracy of 0.9061 on FashionMNIST and 0.7627 on CIFAR-10, representing an improvement of 3.15 and 5.27 percentage points, respectively, over the baseline FedProx. Similarly, CBFedIR achieved the highest accuracy across both datasets, reaching 0.9118 on FashionMNIST and 0.7823 on CIFAR-10. These results underscore the adaptability of the CBG module, which can be embedded into multiple FL algorithms to improve model accuracy and convergence efficiency across various data distributions.

3. Communication Efficiency: The CBG-enhanced algorithms require significantly fewer communication rounds to reach the target accuracy (ToA). For example, CBFedAvg on CIFAR-10 requires only 148 rounds to achieve 70% accuracy ([email protected]), compared to 669 rounds for the baseline FedAvg. This demonstrates that CBG integration not only improves accuracy but also accelerates convergence, making the training process more communication-efficient.

4. Modular Flexibility: The CBG module is designed to be compatible with various FL algorithms, highlighting its modular flexibility. This adaptability allows CBG to be integrated as a coupling mechanism with different FL aggregation methods, demonstrating its robustness and potential to optimize performance in diverse FL scenarios.

In summary, the consortium blockchain-based grouping module consistently enhances the performance of traditional FL algorithms by improving both accuracy and communication efficiency, particularly in non-IID data settings. The CBG module can be easily integrated with a range of FL algorithms, thereby providing a versatile tool to address the limitations of conventional random grouping methods in federated learning.

6.3. Extended Experimental Validation in Real Scenarios

In addition to the basic image classification datasets (MNIST, CIFAR-10) used in the preliminary experiments, we extend the evaluation of the proposed system by applying it to two more complex and realistic datasets for medical image classification. Specifically, we use the ISIC 2017 Task 3 dataset for lesion diagnosis classification and the NuCLS dataset for nucleus classification. These datasets represent challenging tasks in the domain of medical image analysis, where data privacy, model integrity, and classification accuracy are critical.

6.3.1. ISIC 2017 Dataset for Lesion Diagnosis Classification

The ISIC 2017 Task 3 dataset consists of dermoscopic images with labels corresponding to different types of skin lesions, including melanoma, benign nevi, and other dermatological lesions. This dataset presents a complex classification problem, as it includes various types of skin lesions with diverse appearances. The goal is to classify each image into one of several predefined lesion classes.

We use the ResNet-50 model, which has been widely used in image classification tasks, to perform this task. The model is trained in a federated learning manner, where participants use local data to train the model, and model updates are securely aggregated using the proposed blockchain-based framework. We evaluate the performance of the model using standard classification metrics such as accuracy, precision, recall, and F1-score.

Table 7. Classification performance on ISIC 2017 Task 3 dataset.

Model	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
Baseline FL	88.2	85.4	84.6	85.0
CBFL	91.7	89.5	88.1	88.8

presents the performance comparison between the blockchain-based federated learning system and baseline federated learning models that do not incorporate blockchain. The results show that our blockchain-based system outperforms the baseline models in terms of classification accuracy and other evaluation metrics.

6.3.2. NuCLS Dataset for Nucleus Classification

The NuCLS dataset contains more than 220,000 annotated nuclei from breast cancer images sourced from The Cancer Genome Atlas (TCGA). The annotations were made by pathologists, pathology residents, and medical students. The task involves classifying the individual nuclei into various categories, such as malignant cancer cells, benign cells, and other types of cell classifications. This dataset provides a large and challenging classification task that can be used to develop and validate algorithms for nuclear detection, classification, and segmentation.

For this experiment, we use a DenseNet-121 model, which has shown high performance in medical image classification tasks. The model is trained using federated learning, with local data being used for training and model updates being securely aggregated through the blockchain. We evaluate the performance using accuracy, precision, recall, and F1-score metrics.

Table 8. Nucleus classification performance on NuCLS dataset.

Model	Accuracy (%)	Precision (%)	Recall (%)	F1-Score (%)
Baseline FL	85.3	82.1	81.4	81.7
CBFL	88.6	86.4	85.8	86.1

presents the classification performance comparison on the NuCLS dataset between the blockchain-based federated learning system and a baseline federated learning system.

As shown in Table 8, the blockchain-based federated learning system outperforms the baseline system in terms of all evaluation metrics. The use of blockchain ensures the integrity of the model updates, reducing the impact of malicious participants and enhancing the overall robustness of the system.

The experimental results on both the ISIC 2017 Task 3 dataset and the NuCLS dataset demonstrate the effectiveness of our blockchain-based federated learning system in real-world, privacy-sensitive medical image classification tasks. Our system provides significant improvements in model accuracy, precision, recall, and F1-score compared to baseline federated learning models, thanks to the security and trust provided by blockchain technology.

These results highlight the potential of using blockchain-based federated learning for large-scale medical image analysis tasks, where data privacy and model integrity are crucial. The proposed system is scalable, robust, and effective in real-world applications, making it a promising solution for privacy-preserving collaborative learning in healthcare.

6.4. Blockchain-Induced Latency Analysis

Blockchain introduces inherent latency due to its transaction validation, block generation, and consensus process. These delays are particularly important in real-time applications, where timely model updates are critical. The primary sources of blockchain-induced latency in our system include the following:

• Consensus Delay: The Proof of Authority (PoA) consensus algorithm introduces latency proportional to the number of validator nodes, as each transaction must be validated and signed by these nodes.
• Transaction Processing Delay: Each submitted model update is treated as a transaction on the blockchain. The time required to validate and package these transactions into a block adds to the system latency.
• Block Generation Time: The interval between successive blocks determines how quickly transactions are confirmed. Shorter intervals reduce latency but may lead to increased computational overhead and potential for chain forks.

The total latency can be expressed as

$${\mathit{L}}_{\mathrm{total}}={\mathit{L}}_{\mathrm{consensus}}+{\mathit{L}}_{\mathrm{transaction}}+{\mathit{L}}_{\mathrm{block}},$$

where ${\mathit{L}}_{\mathrm{consensus}}$, ${\mathit{L}}_{\mathrm{transaction}}$, and ${\mathit{L}}_{\mathrm{block}}$ represent the delays due to consensus, transaction validation, and block generation, respectively.

To quantify the impact of blockchain-induced latency, we measure the system’s response time, defined as the duration from when a participant submits a local update to when the global model incorporates the update.

Table 9. Response time metrics for different configurations.

Configuration	Average Response Time (ms)	Max Response Time (ms)	Impact on Accuracy (%)
PoA (5 validators)	150	300	−0.2
PoA (10 validators)	230	450	−0.5
Dynamic Block Size (PoS)	180	400	−0.3
Batch Aggregation	100	200	−0.1

summarizes the results under different blockchain configurations.

The results show that, while increasing the number of validators or block size improves security and scalability, it also increases response time. However, the impact on model accuracy remains minimal under these configurations.

To reduce the latency introduced by the blockchain, we propose the following strategies: Optimized Consensus Algorithm: We employ a lightweight Proof of Authority (PoA) consensus algorithm, which reduces validation time by relying on a small set of trusted validators. Experimentally, we find that reducing the number of validators from 10 to 5 decreases average latency by 35%. Batch Aggregation: Instead of submitting individual model updates as separate transactions, we aggregate updates from multiple participants into a single transaction. This approach reduces the number of blockchain transactions, lowering average latency by up to 30%. Hierarchical Blockchain Architecture: In scenarios with high transaction loads, we adopt a hierarchical blockchain architecture. Local updates are first validated on subchains, and only aggregated results are submitted to the main chain. This significantly reduces the load on the main chain and improves response times.

Table 10. Effectiveness of latency mitigation strategies.

Strategy	Average Latency Reduction (%)	Accuracy Impact (%)
Optimized Consensus (PoA)	35	−0.1
Batch Aggregation	30	−0.05
Hierarchical Blockchain	40	−0.2

demonstrates the effectiveness of these strategies in reducing response time.

6.5. Discussion

The results demonstrate several advantages of our blockchain-based federated learning system over traditional approaches:

• Enhanced Communication Efficiency: The consortium blockchain-based federated learning system optimizes participant grouping, leading to fewer communication rounds needed for model convergence, particularly under non-IID conditions.
• Improved Model Accuracy: The scheme provides robust accuracy improvements in non-IID scenarios by enforcing controlled and validated participant grouping, ensuring that diverse and representative data contribute to the global model.
• Security and Computational Overhead: While blockchain integration adds computational overhead due to consensus mechanisms and cross-chain communication, the enhanced security and auditability offset these costs. The tamper-resistant and auditable nature of blockchain provides added value in sensitive applications.

In summary, the performance comparison highlights that the proposed consortium blockchain-based FL system achieves superior accuracy, communication efficiency, and security compared to traditional FL approaches, making it highly suitable for applications requiring stringent data privacy and trust.

7. Conclusions

In conclusion, our study introduces a blockchain-based federated learning (FL) system that significantly enhances trust, privacy, and efficiency in distributed machine learning environments. By leveraging the decentralized nature of blockchain technology, along with smart contracts and computational power-based participant grouping, the proposed system addresses key challenges associated with traditional federated learning, including the risk of malicious participants, data privacy concerns, and communication bottlenecks.

7.1. Theoretical and Practical Implications

Our research introduces both theoretical advancements and practical solutions in the following areas:

• Theoretical Implications: From a theoretical perspective, this study contributes to the field by formalizing a trust model for federated learning based on blockchain technology. The integration of blockchain ensures that model updates are auditable, verifiable, and tamper-resistant, establishing a decentralized trust framework. Additionally, the system’s cross-chain communication and smart contract-based validation processes provide a solid theoretical foundation for handling secure data exchanges in distributed learning environments.
• Practical Implications: Practically, the system enhances the efficiency and security of federated learning processes. By grouping participants based on their computational power, we optimize model update frequency and reduce communication delays. The use of blockchain provides a secure infrastructure for federated learning, making the system applicable in various industries where data privacy and trust are critical, such as healthcare, finance, and smart cities. Moreover, the system’s ability to retain data locally ensures compliance with stringent privacy regulations, such as GDPR, while still enabling collaborative model training.

7.2. Limitations

While our approach offers significant improvements over traditional federated learning systems, it is not without limitations:

• Cross-Chain Communication Latency: Although the use of cross-chain communication protocols ensures secure data transmission, there is an inherent latency associated with blockchain transactions, particularly in large-scale networks with numerous participants. This latency may affect the timeliness of model updates in real-time applications.
• Computational Overhead: The additional computational requirements for maintaining the blockchain, verifying transactions, and executing smart contracts introduce overhead that may not be suitable for participants with very limited resources. Although computational power-based grouping mitigates this to some extent, further optimization is required to ensure scalability across a broader range of devices.
• Security Beyond the Current Model: While the proposed system defends against common threats such as model poisoning and data tampering, more sophisticated attacks, such as adaptive adversarial attacks, require the integration of advanced security measures like homomorphic encryption and zero-knowledge proofs. These additions could further enhance the system’s robustness but may also increase computational complexity.

7.3. Future Work

The following areas offer potential for future research and improvements:

• Optimizing Cross-Chain Communication: Future work can focus on reducing the latency of cross-chain communications. Developing more efficient routing protocols and transaction validation mechanisms could significantly improve the system’s scalability and real-time performance.
• Advanced Security Mechanisms: Incorporating advanced cryptographic techniques, such as homomorphic encryption or secure multi-party computation, can enhance the privacy and security of model updates. These methods would allow for secure computation on encrypted data, ensuring that sensitive information remains confidential even during model aggregation.
• Broadening Application Scope: The proposed blockchain-based FL system has the potential to be extended to other machine learning paradigms, such as unsupervised and reinforcement learning. Additionally, its application in domains like the Internet of Things (IoT), where data privacy and secure communication are paramount, could further demonstrate the practical utility of the system.

In summary, while the proposed blockchain-based federated learning system makes considerable progress in addressing trust, privacy, and efficiency challenges, future research is needed to refine its scalability, security, and applicability across a wider range of use cases and computational environments.