BC-MFAIGC: The Blockchain-Enabled Mobile Federated Artificial Intelligence Generated Content

Abstract

With the rapid advancement of artificial intelligence, AI-generated content (AIGC) applications are becoming increasingly prevalent. However, it remains challenging to deliver high-quality AIGC services in edge scenarios that have real-time requirements and limited resources. In this paper, we propose BC-MFAIGC, a blockchain-enabled framework for mobile federated AIGC. The proposed BC-MFAIGC architecture coordinates edge computing, federated learning, and blockchain. Edge computing brings selected services closer to terminals, federated learning supports collaborative training without transferring raw user data, and blockchain provides transaction authentication, traceable update records, and governance functions. We evaluate the implemented denoising diffusion probabilistic model (DDPM) federated-training workflow under malicious updates using single-machine simulations. Under a medium-strength Gaussian weight-perturbation condition, the observed Fréchet Inception Distance (FID) increase is approximately 2.5% for BC-MFAIGC-Soft and 9.3% for NOBC-MFAIGC-Soft, compared with about 22% for FedAvg in the three-seed evaluation, while the worker-layer detection rate in the near-threshold regime is 9.03–14.29%, reflecting the difficulty of distinguishing malicious from benign updates when their score distributions overlap. Under the current attack condition, the mean FID across five seeds is 307.62 for BC-MFAIGC-Soft and 285.86 for NOBC-MFAIGC-Soft compared with 372.55 for FedAvg. The paired mean difference between BC-MFAIGC-Soft and FedAvg is $-64.93$ with an unadjusted 95% bootstrap CI ranging from $-96.64$ to $-29.53$. The corresponding difference between NOBC-MFAIGC-Soft and FedAvg is $-86.69$ with an unadjusted 95% bootstrap CI ranging from $-120.75$ to $-50.80$. Both comparisons have Holm-adjusted $p=0.25$. Separate protocol tests cover transaction authentication, block-integrity checking, and replay handling, and the simulated ledger configuration increases round wall-clock time by 8.6%.

1. Introduction

As GPU computing power and generative AI algorithms continue to advance, numerous AIGC products have emerged and begun to affect industrial production and daily life. These products can automatically or semi-automatically generate multimodal content such as text and images [1]. Products such as ChatGPT [2], DALL-E 3 [3], and DeepSeek-V3 [4] illustrate the rapid development of AIGC applications.

ChatGPT is a natural-language chatbot; DALL-E 3 is a text-to-image system developed by OpenAI; and recent models in the DeepSeek family further illustrate the expansion of large-scale generative systems. These products enable new forms of content creation and increasingly affect industrial production and daily life. AIGC can improve creative productivity and reduce the time and resources required for manual content creation. However, the practical deployment of AIGC still faces several challenges, which are described below.

Deploying an AIGC service in a cloud data center may not satisfy the real-time requirements of user terminals. Traditionally, AIGC service pre-training, fine-tuning, and inference are conducted in resource-intensive cloud data centers. However, the long transmission distance between a cloud data center and a mobile terminal may increase service latency. In addition, dynamic wireless communication can cause unstable connections and further increase response latency [5,6]. Therefore, satisfying the real-time requirements of user terminals while deploying AIGC service in a cloud data center remains challenging.

Mobile terminals with limited resources cannot support AIGC services by themselves. AIGC pre-training requires a large amount of computing resources, so it is difficult for mobile terminals to perform full model pre-training. For example, DeepSeek-V3 is a mixture-of-experts (MoE) model with 671 billion parameters. The pre-training of DeepSeek-V3 takes approximately 57 days, or 2.788 million GPU-hours, on a cluster of 2048 H800 GPUs. Mobile devices do not have sufficient computing, storage, and energy resources to train a model of this scale. Moreover, fine-tuning and inference also consume computing, storage, and energy resources. A model with insufficient resources may provide lower-quality AIGC services. General-purpose AIGC models may also fail to satisfy the diverse service requirements of mobile users. Therefore, deploying multiple vertical-specific AIGC models on mobile terminals remains challenging because of their limited resources [7].

Low-quality training datasets can reduce AIGC service performance. The performance of AIGC models depends on being trained with massive amounts of text data. For example, GPT-3 was trained on approximately 300 billion tokens [8]. Massive amounts of data provide the foundation for achieving high-quality AIGC services. An AIGC model may not achieve the desired performance when hardware resources are sufficient but the training dataset is insufficient. Insufficient datasets can lead to overfitting, underfitting, model instability, and poor generalization. For example, in image generation tasks, a model may perform well on the training set but fail in real-world scenarios [9]. Dataset quality also influences AIGC service performance. A poor dataset may not contain the key features of a target object, which can prevent the model from generating satisfactory results for mobile users. Therefore, obtaining massive, high-quality training datasets in real time remains challenging.

User privacy leakage can hinder the development of high-quality AIGC services. Massive training datasets collected from user terminals may contain private information, such as user preferences, locations, and behaviors. In addition, prompts provided by users may reveal personal information and increase privacy risks. AIGC models are often trained in cloud data centers, and training data are transmitted to these centers. Centralized data management may increase the risk of user privacy leakage [10]. Therefore, protecting user privacy while maintaining AIGC service quality remains challenging.

To address these challenges, we propose the blockchain-enabled mobile federated artificial intelligence generated content (BC-MFAIGC) architecture, as shown in Figure 1.

Figure 1. Overview of the BC-MFAIGC system.

Edge computing brings the cloud resources near user terminals to reduce the cloud service delay and improve the service reliability [11]. Hence, AIGC service providers (ASPs) can deploy the AIGC services on edge servers to satisfy the real-time AIGC service requirement of user terminals [7]. Meanwhile, the user terminal data can be transmitted to edge service for pre-training and fine-tuning of AIGC models. The decentralized edge computing architecture can reduce the risk of user privacy leakage. So, deploying the AIGC services on edge servers can not only reduce service response delay, but also reduce the risk of user privacy leakage.

Federated learning adopts a distributed architecture to train and preserve models, which can improve training efficiency and protect user privacy, among other benefits [10,12,13]. With these advantages, federated learning can be used for the training or fine-tuning of an AIGC model. With federated learning, each edge server can train the entire or a partial AIGC model; the aggregation node then integrates the parameters trained by the edge servers and transmits them back to each edge server, so that the edge server can update the AIGC parameters in real time. Meanwhile, user data are stored on the corresponding edge server and are not transmitted to the cloud data center, which reduces the risk of user privacy leakage. In addition, a reasonable incentive mechanism in the federated learning architecture can encourage users to participate in the process of AIGC model training or fine-tuning. Adopting a federated learning architecture for the training or fine-tuning of an AIGC model can therefore improve training efficiency and reduce the risk of user privacy leakage [12].

Blockchain has advantages of distributed data storage, point-to-point transmission, consensus mechanisms and encryption, which can support privacy protection in AIGC model training or fine-tuning [14]. With a blockchain system, user data can be encrypted during transmission, and smart contracts can enforce the conditions under which data are exchanged. Blockchain records also make data transmission traceable, which reduces the risk of privacy leakage, and decentralized storage reduces the risk of user data loss [15]. Combining a blockchain system with AIGC training-data management can therefore support user privacy protection and reduce the risk of data loss.

In this paper, we present BC-MFAIGC as a framework that coordinates edge computing, federated learning, and blockchain for AIGC service provision and update governance. Edge placement brings selected services closer to mobile terminals, federated learning supports collaborative training without transferring raw user data, and the blockchain layer records transactions and update events in the proposed workflow. We discuss a medical application scenario and conduct a simulation experiment for the implemented DDPM training workflow. The experiment examines generation quality with FID, malicious-update handling and protocol-layer behavior. Our contributions are summarized as follows:

• We present the BC-MFAIGC framework to coordinate edge computing, federated learning, and blockchain for AIGC service provision and update governance.
• A conceptual application of BC-MFAIGC to medical AIGC services under resource and privacy constraints is outlined.
• A simulation experiment is executed to evaluate the generation quality, the malicious-update detection and the protocol-layer contribution of BC-MFAIGC, covering the attack ratio, the local-model parameter sign-inversion isolation control and four protocol tampering scenarios.

The rest of this paper is organized as follows. Section 2 discusses the preliminaries of the BC-MFAIGC framework. Section 3 describes the BC-MFAIGC architecture, which outlines its workflow, core mechanisms, and a comparative analysis against existing technologies. Section 4 through Section 5 cover the application and evaluation: medical scenarios in Section 4, and simulation experiments and results with a discussion of system complexity and overhead in Section 5. Future research directions are outlined in Section 6, and Section 7 concludes the paper.

2. Preliminaries

In this section, various AIGC applications are described, and the key steps of AIGC are summarized. Then, the preliminaries of edge computing, federated learning and blockchain are introduced, successively. Finally, the feasibility of integrating AIGC, edge computing, federated learning, and blockchain is analyzed in detail.

In 2022, ChatGPT garnered significant global attention [2]. By 2025, DeepSeek-V3, known for its high performance and low cost, experienced explosive user growth [4]. Currently, as the core application area within the field of generative artificial intelligence (GAI) [16], AIGC is increasingly becoming an integral part of people’s production methods. AIGC applications of various types are being released continuously. The application scenarios have been extended to e-commerce [17], education [18], medical care [19], art [20] and other fields. Next, the types of applications of AIGC and their underlying principles will be introduced in detail. Figure 2 shows various types of AIGC application scenarios.

Figure 2. Various AIGC application scenarios.

AIGC workflows can include pre-training, fine-tuning and inference [13], as illustrated in Figure 3. The green arrows in Figure 3 indicate the workflow from the general large model to fine-tuning and then to the task-adapted model.

Figure 3. Key steps of AIGC.

Pre-training enables AIGC models to learn general patterns and representations from large-scale unlabeled data [12]. Pre-training requires substantial computing resources. Poor data quality or insufficient computing resources can impair generation quality and model performance. Fine-tuning uses task-specific labeled data to further train the model on the basis of pre-training [21].The purpose of fine-tuning is to update the model parameters so that they suit a specific task or domain [22]. Fine-tuning requires sufficient computing resources and labeled data from the specific industry. Fine-tuning techniques include full-parameter fine-tuning, partial layer freezing and parameter-efficient fine-tuning. Poor data or insufficient computing power can reduce the quality of the fine-tuned model’s outputs. Domain-specific data may contain trade secrets or personal information, making data access and privacy protection important considerations. Inference refers to generating specific content from input prompts or instructions after model training or fine-tuning [13]. Inference requires prompts and computing resources. Inference is generally supported by a cloud data center and can be performed either in real time or in batch mode. Low-quality prompts or insufficient computational resources can degrade the quality of the generated content. Prompts may also contain industry secrets or personal information, so inference raises privacy concerns. For real-time services, excessive response delay can impair the user experience.

The pre-training, fine-tuning and inference of traditional AIGC models require large amounts of data, storage and computing resources. Therefore, AIGC services are commonly deployed in resource-rich cloud data centers. However, mobile applications still face challenges related to service response delay, terminal resources, data governance and user privacy. The feasibility of integrating AIGC, edge computing, federated learning and blockchain is illustrated in Figure 4.

Figure 4. The possibility of combining the advantages of federated learning and blockchain into AIGC.

Edge computing is a distributed computing architecture that places data processing, storage and application services close to data sources [6]. The cloud–edge–terminal architecture can be used for AIGC service deployment. AIGC models can be trained in cloud data centers and deployed on edge servers, while lightweight or partial models can be deployed on mobile terminals. This arrangement brings selected AIGC services closer to mobile users and enables edge servers and mobile terminals to cooperate during inference, thereby supporting real-time service requirements and resource coordination. As a distributed machine learning technology, federated learning involves multiple participants collaboratively training models [23,24]. Under the cloud–edge–terminal architecture, mobile terminals can train local AIGC models and transmit model parameters to edge servers for regional aggregation. The regional parameters can then be further aggregated at the cloud level and distributed back to participating nodes. Because raw user data remain at local nodes, federated learning supports collaborative model training while reducing the need for centralized raw-data transmission. There is a risk of privacy leakage in the transmission of model parameters or gradients [10,24]. Federated learning can also provide a basis for incentive mechanisms that encourage participation in model training and fine-tuning. Blockchain is a decentralized distributed ledger technology [25]. The blockchain consists of a series of blocks arranged in chronological order. Each block contains transaction records that are verified and stored by multiple network nodes [14,26]. Blockchain can be integrated into the training workflow when model updates, data-use records or participation information need to be authenticated and traced. Digital signatures and transaction records provide a basis for identifying update sources and maintaining an auditable history, while smart contracts can define participation and reward–penalty rules. In this way, the blockchain layer complements federated learning by supporting update governance and traceable coordination among multiple parties.

3. BC-MFAIGC

In this section, the BC-MFAIGC architecture is described, and the level of the architecture is explained. Then, the workflow of the architecture is introduced and the workflow of model deployment is described in detail. Finally, the advantages of BC-MFAIGC are analyzed in detail.

3.1. The BC-MFAIGC Architecture

The BC-MFAIGC architecture integrates AIGC, edge computing, federated learning and blockchain with the aim of improving AIGC service quality and user privacy protection: edge computing builds the cloud–edge–terminal architecture for AIGC service deployment, federated learning enables collaborative AIGC model training or fine-tuning, and the blockchain layer is intended to protect mobile user privacy and to reduce the risk of mobile user data loss. As shown in Figure 5, the BC-MFAIGC architecture mainly includes four layers, i.e., hardware layer, network layer, control layer and application layer.

Figure 5. The four-layer structure of the BC-MFAIGC architecture.

Hardware layer. Edge computing is adopted to build the cloud-edge-terminal architecture for AIGC service deployment, which can provide rich and flexible resources for AIGC services. In particular, an AIGC model can be trained in the cloud data center and deployed on edge servers or on mobile terminals with sufficient resources, which brings the AIGC service closer to or onto mobile terminals and is intended to reduce the AIGC service response delay. The fine-tuning and inference of an AIGC model can be conducted through cooperation among the cloud data center, edge servers and user terminals based on federated learning.

Network layer.  Based on the infrastructure of BC-MFAIGC, the cloud-edge-terminal network layer is built. The BC-MFAIGC network layer supports communication for the federated learning and blockchain systems. For federated learning, mobile terminals act as the participating nodes, edge servers as the regional integration nodes, and the cloud data center as the global integration node. For the blockchain system, the cloud data center and edge servers act as full nodes and form the main chain that stores the global ledger, while mobile terminals act as light nodes because of their limited storage. The BC-MFAIGC network thus forms a decentralized blockchain network, which is intended to reduce the risk of user data loss.

Proxy blockchain layer. The proxy blockchain is a conceptual regional ledger layer associated with edge nodes. The cloud data center and edge servers maintain the main-chain or global-ledger layer, while the proxy layer supports local uploading and distribution of models and model parameters between edge servers and edge nodes.

Control layer. The control layer is the core of BC-MFAIGC. It consists of the control module of each node and makes decisions about pre-training, fine-tuning and inference. For AIGC pre-training, each node decides whether to share its own data through the blockchain system. For AIGC fine-tuning, mobile terminals decide whether to participate on the basis of their limited computing resources and energy. For AIGC inference, edge servers or mobile terminals decide whether to offload inference tasks to other nodes. For the blockchain system, each node decides whether to take part in the consensus process given its limited resources or energy.

Application layer. The BC-MFAIGC application layer covers scenarios that require AIGC inference, especially real-time AIGC inference. Deploying AIGC services on edge servers or on mobile terminals with sufficient resources can reduce the network transmission delay, which suits real-time application scenarios. The AIGC service can also adjust its parameters dynamically for a specific scenario through AIGC model fine-tuning with federated learning. In addition, the blockchain layer is intended to protect mobile user privacy and to reduce the risk of mobile user data loss in specific application scenarios.

3.2. Comparative Analysis with Existing Technologies

To further clarify the contributions of BC-MFAIGC, we compare it with other systems for provision. Table 1 shows a summary of the comparison across six key dimensions.

Table 1. Comparative analysis of BC-MFAIGC against standalone technologies.

Technology	Latency	Privacy	Data Quality	Attack Resistance	Mobility	Incentive
Edge Computing [6,7,11]	Low	Partial	Not guaranteed	No defense	Full	Not provided
Federated Learning [10,12]	Medium	Strong	Not guaranteed	Weak	Limited	Limited
Blockchain [14,15]	High	Strong	Traceable	Medium	Limited	Provided
BC-MFAIGC (Ours)	Low (target)	Strong (target)	Traceable + reward-penalty	Conditional	Full (target)	Provided

In Table 1, the entries for BC-MFAIGC describe the intended roles of its architectural components under the stated trust assumptions. Federated learning reduces the need for centralized raw-data transmission, while blockchain provides authentication, integrity, and traceability for recorded transactions. The attack-resistance comparison refers to the implemented medium-strength setting; the near-threshold behavior is analyzed separately in the malicious-node-ratio scan.

Table 1 compares how each standalone technology and BC-MFAIGC addresses the six requirements. Edge computing mainly supports low latency and mobility [6,7]. Federated learning supports private collaborative training by sharing model parameters instead of raw data, but its parameter aggregation remains vulnerable to poisoning attacks [10,12]. Blockchain supports traceable records and incentives, but its consensus process can add latency [14,15]. BC-MFAIGC coordinates these functions in one architecture.

To further differentiate BC-MFAIGC from existing work, we compare it with recent related architectures. Du et al. [7] focused on enabling AIGC services in wireless edge networks, addressing service latency and resource allocation, but did not incorporate federated learning or blockchain. Wang et al. [11] addressed offloading and quality control for AIGC services in edge computing networks, but lacked federated learning for privacy-preserving collaborative training and blockchain for trust and incentive mechanisms. Huang et al. [12] proposed federated learning-empowered AIGC in wireless networks, focusing on privacy preservation and collaborative training; that work discusses blockchain and edge integration as future directions, whereas BC-MFAIGC implements them as components of the architecture. Liu et al. [14] presented blockchain-empowered lifecycle management for AIGC products in edge networks, focusing on ownership protection and copyright verification, but did not incorporate federated learning for collaborative model training. In contrast, BC-MFAIGC combines edge computing, federated learning, and blockchain in a unified framework for mobile AIGC services. Its contribution lies in coordinating these components for privacy-preserving training and update management.

BC-MFAIGC is positioned against directly related architectures by comparing the scope and measurement of efficiency results, as well as their trust and incentive mechanisms. ProSecutor evaluates transfer-confirmation latency for service transactions [27], whereas this study measures wall-clock time for simulated training rounds. BFLC discusses committee-validation costs [28], and Li and Wu assess training convergence using global aggregation rounds [29]. Counts of validation operations and aggregation rounds do not, by themselves, provide measurements of elapsed time.

The trust and incentive mechanisms also concern different participants and decisions. ProSecutor uses provider reputation for service selection within a two-layer blockchain (roll-ups and Layer-2), without federated AIGC training. BFLC relies on committees to assess model updates and stores models and updates on-chain. Li and Wu use aggregator performance and consensus histories for miner selection and deep reinforcement learning for multiaggregator coordination. Their incentives concern service-quality-based payments, profit sharing based on update contributions and opportunities for future miner selection, respectively. In BC-MFAIGC, validators assess model updates, and the prototype assigns token rewards to workers, validators and miners according to their roles.

3.3. BC-MFAIGC Workflow

The traditional model of AIGC is usually trained by the central server. When faced with some sensitive datasets, AIGC’s model cannot use it for training. At the same time, a large amount of data is also at risk of leakage. AIGC services need to be provided by the central server, which will bring delay. The BC-MFAIGC architecture combines federated learning and blockchain to overcome the challenges in the training and service of traditional AIGC models. The following will introduce the process of BC-MFAIGC architecture in detail.

The workflow of BC-MFAIGC includes five business workflows: model deployment, fine-tuning, data trading, resource trading, and inference. Table 2 compares their participants, triggers, inputs, processing steps, and auditable outputs. The model deployment workflow is described step by step below and is shown in Figure 6. The five business workflows represent conceptual application processes. The experiments examine local training, update validation, aggregation and recording through federated DDPM training from random initialization. The evaluated steps correspond to the training and update processing components of the fine tuning workflow, rather than a complete business workflow.

Table 2. Comparison of the five BC-MFAIGC business workflows.

Workflow	Architecture-Level Participants	Trigger and Main Input	Key Processing	Output and Evidence Scope
Model deployment	Request nodes, edge nodes, full nodes, contracts.	Deployment request: identity, tokens, provision information.	Identity registration, certification, node selection, provision decision, signed transaction, consensus.	Deployed service and provision record.
Fine-tuning	Workers, aggregators, full nodes, contracts.	Need to adapt a deployed model; current model and local updates.	Local fine-tuning, update validation or filtering, aggregation, recording.	Updated model and update record.
Data trading	Data providers, request nodes, full nodes, contracts.	Data request or offer and matching transaction.	Submitted, checked by the blockchain workflow, recorded on-chain.	Trading record and auditable transaction history.
Resource trading	Provision nodes, request nodes, full nodes, contracts.	Resource request and provision information.	Provision queried, provider selected, decision executed, result recorded.	Provision result and record.
Inference	Request nodes, edge nodes or servers, model-provision nodes, record layer.	Inference request and service information.	Provider selected, service executed, result and transaction recorded.	A generated result and a service record.

Figure 6. The model deployment workflow for integrating federated learning and blockchain into AIGC services.

Identity register. A new node sends an identity registration request to a nearby blockchain full node. Each request triggers the corresponding smart contract for identity registration, in which the node registers its public key and wallet address; the private key is generated locally on the node and is never transmitted or registered on the chain (①–②).

Model deployment certification generation. The deployment request nodes send the deployment requests and the corresponding tokens to the blockchain system (③). Then, the corresponding smart contract is triggered to generate deployment request certification (④).

Model deployment. The deployment request nodes select the near edge nodes by querying the model provision node information within blockchain. Then, they send the deployment requests and the corresponding certification to the selected edge nodes (⑤). Furthermore, the edge nodes make the deployment provision decisions based on the system state and the corresponding deployment requests, and execute the corresponding deployment provision decision instructions (⑥). Meanwhile, the model deployment results will be transmitted to the deployment request nodes (⑦). Finally, the edge nodes send the model deployment results and the deployment request certification to the corresponding smart contract for token reward. Meanwhile, they certificate and sign for the model deployment transactions (⑧), and broadcast the transactions through the whole blockchain system (⑨).

Model provision record consensus. The uncertified blocks are generated by transaction packing on the blockchain full nodes, and submitted to the blockchain system for consensus in the entire network. The certified blocks are taken as the new blocks to add into blockchain, so that the model provision records can be entirely stored and traced (⑩).

The federated learning architecture between the edge server and the edge node is similar to the central server and edge server arrangement, but the coordination scope is different. The central server and edge server maintain records for the global and regional training processes, while the proxy blockchain is associated with edge-node interactions for uploading and distributing models and model parameters. Depending on the available resources, AIGC services may be provided by edge devices, edge servers, or central servers.

3.4. Design Rationale and Intended Benefits of BC-MFAIGC

BC-MFAIGC combines edge placement, federated parameter exchange, and blockchain records to support mobile AIGC service provision and update management. These design choices lead to four expected advantages. An AIGC service deployed only in a cloud data center must transmit each request and its result between the mobile terminal and the remote center. That path depends on a stable wireless connection, and the response delay cannot be bounded in networks that are unstable or temporarily unavailable. Edge placement shortens the path by moving selected computation to edge servers near the terminals; when a model, or part of a model, is placed on a resource-rich terminal, the request can be served locally without a round trip to the cloud. BC-MFAIGC therefore brings AIGC services closer to or onto mobile terminals, which is intended to reduce the service response delay. In the BC-MFAIGC environment, an AIGC model can be deployed on edge servers, on resource-rich mobile terminals, or split between the two. Edge-server deployment lets mobile users reach the service over the wireless network, while terminal deployment lets a device run the service itself, which suits mobile scenarios with unstable or unavailable connectivity. When a single terminal cannot host a complete model, part of the model can be deployed locally and the terminal and its edge server can perform inference cooperatively. These are architectural design options, and the corresponding deployment benefits are not evaluated in the present experiments. In the BC-MFAIGC environment, a mobile terminal can share data or model parameters with cloud data centers, edge servers or other terminals for AIGC model training and fine-tuning. Blockchain records make each contribution traceable, and the reward-and-penalty mechanism attaches a consequence to recorded behavior: a terminal that repeatedly provides low-quality data can be identified through the traceability function and penalised, which is intended to discourage poor contributions and to support higher data quality. Application-specific data checks can be applied on top of this governance layer, and the present experiments evaluate update quality and detection behavior on CIFAR-10. In the BC-MFAIGC environment, each mobile terminal holds a registered public-key identity, and node-to-node communication is authenticated with it. Because transactions are recorded and traceable, a node that discloses data obtained from another node can be identified, and the reward-and-penalty mechanism provides a further disincentive. Federated learning complements this by exchanging model parameters instead of raw user data, so that user data remain on the local device. Taken together, these mechanisms are intended to reduce direct raw-data exposure and to provide an identity basis for coordinated update management. Privacy leakage through model updates and gradients is not quantified in the present experiments.

4. Medical Use Case

In the conceptual medical application scenario, BC-MFAIGC could coordinate edge computing, federated learning, and blockchain to support medical AIGC services involving sensitive patient data and mobile devices with limited resources.

In the edge medical environment, patient data are diverse and sensitive, and a medical AIGC model is typically trained and deployed in a cloud data center. Mobile users of such a service may experience high latency [19], and deploying such models is difficult for edge users with limited resources. High-quality medical data are also important for medical AIGC services, and data security requires explicit attention.

In medical scenarios, especially real-time diagnostic assistance or continuous monitoring, low response delay is important. The cloud-edge collaboration in BC-MFAIGC places selected computation closer to users. Federated learning supports local model updates without transferring raw data, while the blockchain layer records update transactions and identity information. Together, these mechanisms provide a basis for coordinating medical AIGC services across cloud, edge, and terminal nodes.

Mobile medical devices may have limited computing, storage, and energy resources. A possible deployment could place a lightweight model on the device and rely on edge-assisted training or inference. Federated learning can update model parameters collaboratively with edge servers or other devices, while blockchain provides a trusted channel for recording model-parameter exchanges. This arrangement supports mobile AIGC applications such as primary care, community screening, family health management, skin-lesion analysis, and arrhythmia warning.

The quality of medical data directly affects the reliability of diagnosis. Blockchain provides life-cycle traceability for recorded data and model updates, federated learning supports the integration of multi-source information without transferring raw data, and edge computing can perform data cleaning, standardization, and labeling near the data source. The combination of these mechanisms supports the data-governance process of medical AIGC services.

Medical data contain sensitive information such as medical history, genetic data, and imaging data. Federated learning allows patient data to remain on local devices while model updates are transmitted to edge servers. Access control and blockchain transaction records provide additional mechanisms for managing data use and tracing model interactions.

5. Experiments

5.1. BCFLDIF Training Algorithm

Algorithm 1 presents the BCFLDIF training process, where BCFLDIF stands for Blockchain-based Federated Learning for Diffusion; it integrates three core mechanisms: the blockchain incentive mechanism, the federated aggregation strategy, and the edge scheduling rule.

The BCFLDIF algorithm embodies three core design principles:

Blockchain Incentive Mechanism. Each round rewards workers for submitted updates, validators per validated transaction, and the winning miner per packaged transaction [14]. Rewards accumulate as stake and are used to select among candidate blocks. A node with $K_o=6$ consecutive negative votes is blacklisted and loses future rewards; forfeiture of accumulated stake is a design objective that the current prototype does not implement.

In BC-MFAIGC, token rewards are allocated for recorded contributions and accumulate as stake for block selection. Participation incentives depend on the rewards earned, the resources consumed, and the expected duration of participation. Within the broader literature on blockchain tokens, Shankar [30] examines tokenized securities for green real estate financing, focusing on liquidity and transparency.

Federated Aggregation Strategy. The hard and soft variants process checked worker updates. The raw score subtracts the denoising loss of the validator-local model from the loss of the submitted model. Both losses use the shared scoring subset. Raw-score votes compare the score with the frozen threshold. Hard filtering selects updates from the raw-score vote counts. By contrast, soft aggregation uses separate normalized-score eligibility flags and bounded trust weights. Soft aggregation first uses records with positive eligibility flags. When no eligible record is available, the vote-count fallback can still admit an update. The fallback accepts a positive majority or a tie in the raw-score votes. A persistent blacklist of $K_o$ consecutive negative votes provides permanent exclusion, forming a two-tier defense against poisoned gradients. The trust weight is $w\left(s\right)=a_{\min }+(1-a_{\min })\sigma [-\lambda (\tilde{s}-t_s)]$ with $\tilde{s}=(s-c)/\gamma$ and $\sigma \left(z\right)=1/(1+e^{-z})$. Here, s is the validation-score difference between the submitted update and the local model used by the validator. The constants c and $\gamma >0$ center and scale the score, $t_s$ is the transition point in the normalized score, $\lambda$ controls the sigmoid steepness, and $a_{\min }$ is the minimum trust weight. Parameter values follow the experimental configuration in Section 5.3.1. Lower normalized scores give larger trust weights. The median combines eligible validator weights. The vote-count fallback uses weights from positive raw-score votes. Hard filtering uses equal weights for admitted updates.

Algorithm 1 BCFLDIF: Blockchain-based Federated Learning for Diffusion Training.

1: Input: N devices, K rounds, local epochs E, learning rate $\eta$, threshold $\tau$, knock-out rounds $K_o$, noise scale $\sigma$, unit reward R   2: Output: Trained global DDPM model ${\mathbf{w}}_g$   3: Initialize ${\mathbf{w}}_g^0$ and distribute to N devices; Rivest-Shamir-Adleman (RSA) keys, blockchain init, stake $\leftarrow 0$   4: Partition CIFAR-10 to obtain non-IID client data   5: Register with the nearest edge server   6: for  $k=1$  to  K  do   7:    Assign roles by seeded count: workers $\mathcal{W}$, validators $\mathcal{V}$, miners $\mathcal{M}$   8:    for each worker $w\in \mathcal{W}$ in parallel do   9:       Train E epochs: ${\mathbf{w}}_w\leftarrow {\mathbf{w}}_w-\eta \nabla {\ell }_{\mathrm{DDPM}}$ (Adam, batch size B) 10:       if malicious: ${\mathbf{w}}_w\leftarrow \mathrm{Attack}\left({\mathbf{w}}_w\right)$    (noise $\mathcal{N}(0,{\sigma }^2)$ or sign inversion) 11:       Compute the submitted model delta: $\Delta {\mathbf{w}}_w\leftarrow {\mathbf{w}}_w-{\mathbf{w}}_g^{k-1}$ 12:       Send signed $t{x}_w=\{{\mathbf{w}}_w,P{K}_w,R\}$ to validators 13:    end for 14:    for each validator $v\in \mathcal{V}$ do 15:       Verify $t{x}_w$ signature; score $s_w\leftarrow \mathcal{L}({\mathbf{w}}_w;{\mathcal{D}}_v)-\mathcal{L}({\mathbf{w}}_v^{\mathrm{loc}};{\mathcal{D}}_v)$ 16:       if $s_w>\tau$: vote negative else: vote positive 17:       Compute eligibility and trust weight; record both with the raw vote. 18:    end for 19:    for each miner $m\in \mathcal{M}$ do 20:       Package checked validation records into $bl{k}_m$; mine, sign, reward $R·\left|tx\right|$; propagate to peers 21:    end for 22:    Pick block from highest-stake miner; verify and append to chain 23:    for each device i do 24:       Apply selection with vote fallback; use median trust weights for soft aggregation. 25:       ${\mathbf{w}}_g^k\leftarrow {\sum }_{w\in {\mathcal{E}}^k}{\alpha }_w({\mathbf{w}}_g^{k-1}+\Delta {\mathbf{w}}_w)/{\sum }_{w\in {\mathcal{E}}^k}{\alpha }_w$    (${\alpha }_w=1$ under hard filtering, trust weight under soft aggregation; see the trust weighting rule; ${\mathcal{E}}^k=\varnothing \Rightarrow {\mathbf{w}}_g^{k-1}$) 26:       for each w with negative-vote majority: if each of the last $K_o$ rounds records a majority of negative votes for w: blacklist else: discounted reward 27:       end for 28:       Credit reward R by role; accumulated balance selects candidate blocks 29:    end for 30:    All devices load ${\mathbf{w}}_g^k$; log losses, scores and stake 31: end for 32: return  ${\mathbf{w}}_g^K$

Edge Scheduling Rule. Devices register with the nearest edge server. Let U denote the transmitted model-update size and $B_{\mathrm{link}}$ the link bandwidth. The corresponding transmission delay is $T_{\mathrm{delay}}=U/B_{\mathrm{link}}$. The all-in-one network mode, in which $aio=1$, emulates a permissioned blockchain with mutual reachability, reflecting realistic wireless edge constraints. This mode runs a single blockchain-governed workflow; a multi-proxy-chain deployment is not instantiated in the reported experiments.

5.2. Theoretical Analysis

This section analyzes the complexity, overhead, and security properties of the BC-MFAIGC architecture, providing a deeper analysis beyond the experimental validation.

5.2.1. Complexity and Overhead

Let W, V, and M denote the numbers of workers, validators, and miners, N the number of devices, S the number of edge servers, d the model parameter count, and E the number of local epochs. In each round, worker updates, validator broadcasts, and block propagation have the respective orders $O\left(Wd\right)$, $O\left(V^{2}d\right)$, and $O\left(MWd\right)$, giving a per-round communication order of $O\left((W+V^2+MW)d\right)$, while worker training dominates the computation at $O\left(E\right|{\mathcal{D}}_i\left|d\right)$ per worker and scheduling requires $O\left(NS\right)$ lookups. These are symbolic orders rather than measured quantities.

5.2.2. Security Analysis

Threat Model and Evaluation Scope. The study examines a simulated permissioned proof-of-stake workflow in which malicious workers may submit manipulated model updates. Validators and miners are assumed to follow the configured protocol rules for validation, block selection, blacklisting, and rewards. The evaluation concerns model-update handling and traceability of update records under the stated validator and miner assumptions.

Validation, Consensus, and Penalties. In the proposed design, validators filter anomalous updates through the validation-score comparison before aggregation, and the stake-based procedure selects and records blocks, so that every accepted update leaves a traceable record. A node whose updates are negatively voted in $K_o=6$ consecutive rounds is blacklisted and loses the future earnings it would otherwise have collected, which is intended to create a progressive disincentive for sustained attacks. Multi-validator faults, stake manipulation and identity-creation attacks are outside the present evaluation.

Privacy-Preserving Workflow. Raw training data are not transmitted between participants: federated participants exchange model parameters, and public-key identities authenticate transactions. Model updates and gradients remain a residual privacy channel, as noted in Section 2, and the identity mechanism provides authentication rather than anonymity. Differential privacy can be integrated as an orthogonal enhancement to the local training step.

5.3. Experimental Setup

The formal quality experiments compare eight methods for federated DDPM training on CIFAR-10 under clean and attack conditions. Each combination of method and condition uses five random seeds. All formal runs use the same budget of 300 communication rounds.

5.3.1. Experimental Configurations

(1)

System Configuration

The experiments run on a single machine with an NVIDIA RTX 4080 SUPER GPU and fourteen logical devices. Each round assigns nine workers, two validators, and three miners, except for the committee roles described in Section 5.3.3. Local training uses Adam with gradient accumulation and the parameters in Table 3.

Table 3. Experimental parameter configuration.

Item	Value
Local training per round	1 epoch
Mini-batch size	128 images
Learning rate	0.001
Gradient accumulation	4 mini-batches
Initial diffusion variance ${\beta }_0$	${10}^{-4}$
Final diffusion variance ${\beta }_{T-1}$	$2\times {10}^{-2}$
Time-embedding dimension	128
Unit contribution reward	1 token

The DDPM [31] uses a convolutional encoder and decoder with a time embedding to predict the added Gaussian noise. Diffusion follows a linear noise schedule, and sampling clips predicted clean images to the range from $-1$ to 1.

(2)

Protocol Design

BC-MFAIGC-Soft and NOBC-MFAIGC-Soft share the validation rule, trust-weighted aggregation and equivalent signature, payload-integrity, and freshness checks. BC adds block generation, propagation, and recording, with proof of stake governing block selection.

(3)

Attack Configuration

In each attack round, three of the nine current workers are randomly selected to add zero-mean Gaussian noise with standard deviation $\sigma =0.05$ to their local model weights after training and before submission. Clean runs contain no malicious workers.

(4)

Threshold Calibration

The raw threshold is fixed at $\tau \approx 0.1669$, the empirical 99th percentile of 5400 validation scores from ten independent clean runs of 30 rounds each. The fixed normalization, eligibility and trust parameters for soft aggregation are given in the supplement.

(5)

Independent Network Timing Configuration

A separate benchmark evaluates offline collaborative model updates and governance on a single host with five workers, two validators, and three additional nodes serving as miners in the blockchain workflow. All five methods communicate over loopback connections using Transmission Control Protocol (TCP), with the same fair scheduling and a budget of 1,000,000 application frame bytes per second on each directed logical link. GPU resources are shared with background tasks.

Three timing repetitions per method use the same initial model and fixed workload seed. The CIFAR-10 workload provides 256 images per training node and 64 separate scoring images, with one local epoch, batch size 128, Adam at learning rate 0.001 and a raw threshold of 0.1.

BC and NOBC apply the same validation, node verification, aggregation, and applicable retrieval checks, with BC adding proposal exchange, consensus, and chain commit. Hard filtering gives admitted updates unit weights. FedAvg aggregates at a coordinator and distributes a single global model. Implementation details are given in the supplement.

5.3.2. Data Collection

To model non-IID client data, the 50,000 CIFAR-10 training images [32] are partitioned among fourteen clients using a label-based Dirichlet distribution with $\alpha =0.5$. Each training seed determines a client partition that is reused across all methods.

A fixed stratified split divides the 10,000 test images into 2000 scoring images and 8000 FID-reference images with no overlap between the two subsets. NOBC-MFAIGC-Soft and BC-MFAIGC-Soft validate updates on the shared public scoring subset without sharing raw client training images.

5.3.3. Comparison Methods

We compare NOBC-MFAIGC-Soft and BC-MFAIGC-Soft with Federated Averaging (FedAvg) [23], coordinate-wise median (CM), trimmed mean (TM) [33], norm clipping (NC) [34], one-pass Multi-Krum [35], and an adaptation of blockchain-based federated learning with committee consensus (BFLC) [28].

FedAvg and the robust baselines aggregate deltas relative to the current global model without validator scoring. FedAvg weights updates by local sample count, CM takes the median at each coordinate, and TM averages after trimming three values from each tail. NC clips deltas at the median submitted ${\ell }_2$ norm. The empirical one-pass Multi-Krum configuration uses $n=9$, $f=3$, and $m=6$.

BFLC uses an eleven-client learning pool with nine workers and two committee members, alongside three fixed miners. Committees use local denoising loss to select six updates and elect the next committee. We adapt the classification task to DDPM generation and replace the original practical Byzantine fault tolerance (PBFT) backend with proof of stake. Detailed aggregation, scoring, and election rules are provided in the supplement.

5.3.4. Metrics

(1)

Generation Quality

FID evaluation [36] uses 5000 generated images and the fixed 8000-image reference subset. The evaluator extracts 2048-dimensional pooled features using the FID-specific InceptionV3 implementation in pytorch-fid. Lower FID indicates a closer match between the generated and reference feature distributions.

(2)

Training Loss

The DDPM is trained to predict sampled Gaussian noise by minimizing the MSE [31]. Equation (1) defines the loss for a mini-batch of B images with D scalar elements per image.

$${\mathcal{L}}_{\mathrm{MSE}}={\displaystyle \frac{1}{BD}}{\displaystyle \sum _{i=1}^B}{∥{\mathit{ϵ}}_{\theta }\left({\mathbf{x}}_{i,t_i},t_i\right)-{\mathit{ϵ}}_i∥}_2^2,$$

(1)

Each diffusion step $t_i$ is sampled uniformly from zero to $T-1$, where $T=1000$ is the number of diffusion steps. Each noise vector ${\mathit{ϵ}}_i$ is drawn from a standard Gaussian distribution. The cumulative coefficient is ${\overline{\alpha }}_t={\prod }_{j=0}^t(1-{\beta }_j)$, where ${\beta }_j$ is the diffusion noise variance at step j. For a clean image ${\mathbf{x}}_i$ with values ranging from $-1$ to 1, the forward process forms ${\mathbf{x}}_{i,t_i}=\sqrt{{\overline{\alpha }}_{t_i}}{\mathbf{x}}_i+\sqrt{1-{\overline{\alpha }}_{t_i}}{\mathit{ϵ}}_i$. The network predicts the added noise as ${\mathit{ϵ}}_{\theta }({\mathbf{x}}_{i,t_i},t_i)$.

(3)

Model-Layer Metrics

The raw-score detection rate is the fraction of malicious-update validation records with scores above the raw threshold. The raw false-positive rate (FPR) is the corresponding fraction for benign-update validation records. The benign eligibility-exclusion rate is the fraction of benign-update validation records that fail the soft-aggregation eligibility rule. These validator-level decisions do not directly measure final update omission because final selection also uses the vote-count fallback.

Rates are summarized as unweighted means across five training seeds.

(4)

Protocol Metrics

In the earlier Stage 2 protocol tests, H0 covers normal processing and H1 tests transaction tampering. H2 tests block tampering and H3 tests historical replay. Run-level event coverage is the fraction of runs in which all expected protocol events are recorded. Rejection-path counts summarize logged rejection events and do not represent event-level rejection probabilities.

(5)

Statistical Analysis

Formal quality results use the training seed as the experimental unit. FID is summarized by the mean with an unadjusted pointwise 95% confidence interval obtained from 20,000 bootstrap resamples of training seeds. Prespecified paired contrasts use two-sided exact sign-flip tests, with Holm correction applied separately to four FID contrasts and four contrasts of raw FPR or benign eligibility exclusion. Significance is assessed using adjusted p-values at the 0.05 level.

Earlier Stage 1 and Stage 2 FID comparisons were reported using Welch t tests with three seeds per configuration. The supplement details the prespecified contrasts and exact-test resolution.

(6)

Round Completion Time and Application Traffic

Round completion time runs from the start of round control until signed acknowledgements confirm that all ten nodes have installed the same global model. It includes worker training, validator reference training and scoring, communication, required model retrieval, verification, consensus where applicable, aggregation, and installation. Times are reported as the mean and sample SD across three repetitions.Transfer includes associated dispatch and processing. Application traffic counts framed messages in decimal megabytes (MB), excluding transport and network headers. The supplement provides the complete stage definitions and measurement details.

5.3.5. Experimental Results and Discussion

Table 4 summarizes FID for eight methods after 300 communication rounds under clean conditions and Gaussian-noise attacks with $\sigma =0.05$. Values are reported as means with unadjusted 95% bootstrap confidence intervals across five training seeds.

Table 4. Generation quality under clean and attack conditions.

Method	Clean Mean FID	95% CI	Attack Mean FID	95% CI
FedAvg	299.04	276.10 to 321.98	372.55	354.89 to 389.37
NOBC-MFAIGC-Soft	312.15	290.48 to 338.67	285.86	264.06 to 307.65
BC-MFAIGC-Soft	304.01	284.13 to 321.19	307.62	290.71 to 326.11
CM	331.11	305.82 to 356.40	333.19	304.33 to 362.72
TM	328.10	299.35 to 356.85	322.85	311.04 to 338.03
NC	354.00	333.79 to 372.63	351.24	337.10 to 366.51
Multi-Krum	327.49	302.17 to 352.82	319.12	292.53 to 345.72
BFLC	280.85	263.79 to 297.90	317.11	292.31 to 341.91

(1)

Training Performance and Generation Quality

(i)

Training and Aggregation Performance.

Figure 7a shows the validation MSE defined by Equation (1) under clean conditions in the earlier Stage 1 experiments, which used 100 communication rounds and three random seeds. Stage 1 uses ten devices with roles reassigned each round. One device is assigned to each of the worker, validator, and miner roles. Each remaining device receives one of the three roles with equal probability. FedAvg, NOBC-MFAIGC, and BC-MFAIGC show rapid reductions in validation MSE from approximately 0.91. Over the final 10 rounds, the mean validation MSE ranges from 0.106 to 0.107 across the three methods. The supplement provides the full Stage 1 configuration. Under the Stage 1 attack condition with 30% malicious nodes, FedAvg has a mean MSE of about 0.183 over the final rounds. Figure 7b shows larger fluctuations in the FedAvg curve. The corresponding mean MSE values for NOBC-MFAIGC and BC-MFAIGC are about 0.112 and 0.111, respectively. These values remain close to the clean-condition values for the two MFAIGC configurations.

Figure 7. Training process and aggregation dynamics: (a) clean and (b) medium-strength attack conditions; (c) clean and (d) attack conditions for local updates and round-end aggregation.

Figure 7c,d compare the validation MSE of local worker models with the validation MSE of the corresponding round-end aggregated models. Under clean conditions, the mean absolute difference over the last 20 rounds is about 0.002 for all three configurations. Under attack, the difference increases to about 0.023 for FedAvg but remains below 0.0015 for both MFAIGC configurations. The MSE in these panels measures the DDPM denoising loss during training and validation, not the pixel-level distance between generated and real images. FID is used separately to evaluate generation quality under clean and attack conditions.

(ii)

Generation Quality under Clean and Attack Conditions.

To examine FedAvg under a stronger perturbation, the current experiments use $\sigma =0.05$, run for 300 communication rounds and evaluate five random seeds per configuration. Figure 8a compares the eight methods under clean conditions, while Figure 8b shows their performance under attack. FedAvg’s mean FID increases from 299.04 to 372.55. All five seeds have higher FID under attack, with paired increases ranging from 11.41 to 120.99 FID points. The mean paired increase is 73.51 FID points, and the unadjusted 95% confidence interval obtained by bootstrap resampling of seed pairs ranges from 38.65 to 102.83. The exact test gives $p=0.0625$ before Holm adjustment and $p=0.25$ after adjustment.

Figure 8. Generation quality under (a) clean and (b) attack conditions. Points represent individual seeds, squares represent means, and error bars show pointwise 95% bootstrap confidence intervals.

(iii)

Effect of Malicious-Node Ratio.

The earlier Stage 2 ratio scan varies the malicious-node ratio across 0%, 10%, 30%, and 50% while fixing the noise scale at 0.005. FedAvg, NOBC-MFAIGC-Hard, and BC-MFAIGC-Hard are evaluated with three random seeds and 100 communication rounds for each ratio. The filtering methods use the frozen threshold of 0.0134860123. Figure 9a shows no monotonic FID trend as the malicious-node ratio increases. Across the four ratios, the FID ranges are 44.89 for FedAvg, 23.13 for NOBC-MFAIGC-Hard, and 20.25 for BC-MFAIGC-Hard. The pooled hard-filtering results differ from FedAvg by 34.58, −13.10, 4.29 and 14.70 FID at 0%, 10%, 30%, and 50%, respectively. All four confidence intervals include zero, and the rank-correlation tests are not significant.

Figure 9. Effect of the malicious-node ratio under the near-threshold setting: (a) FID for FedAvg and the two hard-filtering methods; (b) worker-layer detection rate for the hard-filtering methods.

At the 0% ratio, the pooled FID of the two hard-filtering methods is 325.18 ± 38.98, compared with 290.60 ± 21.03 for FedAvg. This difference occurs without malicious nodes and suggests that hard filtering can remove useful benign updates.

Figure 9b reports worker-layer detection rates for the two filtering methods at 10%, 30%, and 50%; FedAvg has no filtering layer and is omitted. The worker-layer rates for NOBC-MFAIGC-Hard are 13.66%, 9.03%, and 10.01%, while the rates for BC-MFAIGC-Hard are 14.29%, 10.29%, and 9.89%. The rates decrease from 10% to 30% and change little at 50%. Vote-layer rates show the same pattern, decreasing from 19.88% to 15.09% for NOBC-MFAIGC-Hard and from 21.43% to 14.76% for BC-MFAIGC-Hard.

With the threshold frozen at the 99th percentile of the calibration scores, detection remains low at this noise scale. At the 0% ratio, NOBC-MFAIGC-Hard and BC-MFAIGC-Hard produce worker-layer false-positive rates of 0.467% and 0.200%, and vote-layer rates of 1.000% and 0.600%, respectively.

(2)

Malicious-Update Detection Performance

(i)

Detection and False-Negative Rates.

Table 5 reports rates calculated from validator records. Both MFAIGC variants have a raw detection rate of 100% and a corresponding false negative rate of zero for every attack seed. Detection and false negative rates are not applicable (N/A) under clean conditions because the clean runs contain no malicious updates.

Table 5. Validator-level update decisions.

Method	Condition	Benign Raw FPR	Benign Eligibility Exclusion	Malicious Raw Detection
NOBC-MFAIGC-Soft	clean	0.107%	11.55%	N/A
NOBC-MFAIGC-Soft	attack	0.089%	11.01%	100.00%
BC-MFAIGC-Soft	clean	0.189%	11.48%	N/A
BC-MFAIGC-Soft	attack	0.117%	11.20%	100.00%

(ii)

Benign False-Positive Rates.

Table 5 reports raw FPR and benign eligibility exclusion separately. All four comparisons between the two MFAIGC variants give $p=1.0$ after Holm adjustment.

Differences are calculated by subtracting the rate for the nonblockchain variant from the rate for the blockchain variant. The raw FPR difference is 0.081 percentage points under clean conditions, with an unadjusted 95% bootstrap confidence interval ranging from 0.004 to 0.226 percentage points. Under attack, the difference is 0.028 percentage points and the corresponding interval ranges from negative 0.039 to 0.100 percentage points. The benign eligibility exclusion difference is negative 0.067 percentage points under clean conditions and 0.189 percentage points under attack.

(iii)

Validator Decisions on Malicious Updates.

At the validator level, all recorded malicious updates in both MFAIGC variants receive scores above the raw threshold and fail the soft aggregation eligibility rule.

(3)

Ablation Study of Aggregation Strategies

Figure 8b and Table 4 compare aggregation methods under attack. CM and TM record mean FIDs of 333.19 and 322.85, respectively, while NC and Multi-Krum record 351.24 and 319.12.

Under attack, the blockchain variant minus FedAvg contrast gives a paired mean difference of negative 64.93 FID points and an unadjusted 95% bootstrap confidence interval from negative 96.64 to negative 29.53. The corresponding difference for the nonblockchain variant is negative 86.69 FID points with an interval from negative 120.75 to negative 50.80. The exact tests give $p=0.0625$ for both contrasts before Holm adjustment and $p=0.25$ after adjustment.

The earlier Stage 1 ablation compares soft aggregation and hard filtering within NOBC-MFAIGC and BC-MFAIGC under clean and attack conditions. The comparison uses three random seeds. Figure 10 reports FID for the four method-condition combinations.

Figure 10. FID ablation of soft aggregation and hard filtering under (a) clean and (b) attack conditions.

Under clean conditions, hard filtering increases FID by 28.48 for NOBC-MFAIGC and decreases FID by 14.19 for BC-MFAIGC. Under attack conditions, hard filtering decreases FID by 19.12 for NOBC-MFAIGC and by 21.27 for BC-MFAIGC.

With three seeds per group, all four confidence intervals for the soft-versus-hard FID differences include zero. The corresponding p-values are $0.272$, $0.499$, $0.301$, and $0.295$, respectively. None of the comparisons is statistically significant. Hard filtering improves the observed FID under attack for both methods, whereas the clean-condition effects differ between NOBC-MFAIGC and BC-MFAIGC.

(4)

Blockchain Protocol Evaluation

The two MFAIGC variants use equivalent update checks and the same validation and aggregation rules but differ in blockchain processing. In Figure 8b, the mean FID is 307.62 for the blockchain variant and 285.86 for the nonblockchain variant.

The paired mean difference for the blockchain variant minus the nonblockchain variant is 21.76 FID points, with an unadjusted 95% bootstrap confidence interval from negative 5.14 to 44.17. The exact test based on sign flips gives $p=0.1875$ before Holm adjustment and $p=0.25$ after adjustment.

Different worker execution orders can change training random draws despite matching role assignments, limiting attribution of FID and FPR differences to blockchain processing alone. BFLC records the lowest mean clean FID among the eight methods at 280.85 in Figure 8a. Under attack, its mean FID is 317.11 in Figure 8b, a descriptive increase of 36.26 FID points.

The earlier Stage 2 experiments examine sign inversion of local model parameters and protocol operation. The first test compares BC-MFAIGC and NOBC-MFAIGC under the same local-model parameter sign-inversion attack. The second test disables model filtering and evaluates signature, block-integrity, transaction-ordering, and replay checks.

(i)

Blockchain Ablation under Local-Model Parameter Sign Inversion.

The sign-inversion control compares BC-MFAIGC and NOBC-MFAIGC under the same model architecture, data partition, trust evaluation, and aggregation rule. The attacker submits the negated local model $-{\mathbf{w}}_w$ instead of the trained model ${\mathbf{w}}_w$. Relative to the previous global model, the submitted delta is $-{\mathbf{w}}_w-{\mathbf{w}}_g^{k-1}$. The attack therefore negates the local model rather than the local model delta. The two configurations enable or disable the blockchain workflow. FID is the primary outcome, while detection and benign false-positive rates describe the control conditions.

Figure 11a reports FID values of 315.40 ± 13.51 for NOBC-MFAIGC and 330.77 ± 29.54 for BC-MFAIGC. The NOBC-minus-BC difference is $-15.37$, with a 95% confidence interval ranging from $-77.51$ to 46.77 and $p=0.476$. The interval includes zero, so the experiment shows no significant FID difference between the two configurations.

Figure 11. Isolation control under the local-model parameter sign-inversion condition: (a) FID; (b) malicious-update detection rate; (c) pooled benign false-positive rate; (d) per-seed detection rate; (e) per-seed benign false-positive rate.

Figure 11b records 473/473 rejected malicious updates for NOBC-MFAIGC and 543/543 for BC-MFAIGC. Figure 11d shows a 100% detection rate for both configurations across all three seeds.

BC-MFAIGC records 9, 14, and 9 benign rejections across the three seeds. NOBC-MFAIGC records 5, 9, and 2 benign rejections across the three seeds. BC-MFAIGC records a pooled false-positive rate of 1.73% based on 32 rejections among 1849 benign records. NOBC-MFAIGC records a pooled false-positive rate of 0.89% based on 16 rejections among 1807 benign records. The earlier experiments with negated local models give a pooled FPR difference of 0.85 percentage points. Figure 11e shows the rates for each training seed. Pooled rates are descriptive only because repeated validator records are not independent experimental units.

(ii)

Protocol Verification under Tampering and Replay Attacks.

The earlier Stage 2 protocol tests disable model filtering to examine protocol processing. The blockchain configuration checks signatures, block integrity, and transaction ordering before applying updates and records the results of these checks. The earlier nonblockchain configuration applies updates without blockchain checks. In contrast, the formal comparison over 300 rounds uses equivalent update checks in both MFAIGC variants.

Figure 12 summarizes protocol paths and event coverage. For the NOBC-MFAIGC controls corresponding to H0, H1, and H3, the mean direct-no-chain application counts are 500, 500, and 540, respectively.

Figure 12. Protocol paths and coverage verification: (a) injected and rejected events under H1–H3; (b) applications completed without the chain; (c) expected event coverage of H0–H3.

Figure 12c reports 100% run-level event coverage for each H0–H3 scenario, with all expected protocol events recorded in the three runs. Each H1–H3 scenario injects about nine events per run. The mean rejection-event counts are 27, 14.67, and 27 for H1, H2, and H3, respectively. These counts represent protocol-processing records rather than event-level probabilities. The event coverage records signature, transaction-tampering, block-tampering, and historical-replay checks in the tested scenarios.

(5)

Runtime and Communication Overhead

Table 6 compares the five methods under the same clean workload. Wall time is reported as the mean ± SD across three repetitions, while the stage columns report mean durations in seconds.

Table 6. Measured round completion time and additive stage breakdown.

Config.	Cond.	Wall (s)	Train (s)	Score (s)	Transfer (s)	Aggregate/Install (s)	Other (s)
FedAvg	clean	10.342 ± 0.189	1.248	0.000	8.951	0.143	0.000
NOBC Soft	clean	13.193 ± 0.062	1.294	0.360	10.770	0.693	0.076
NOBC Hard	clean	12.965 ± 0.214	1.081	0.389	10.726	0.693	0.077
BC Soft	clean	13.823 ± 0.628	2.066	0.308	10.567	0.726	0.157
BC Hard	clean	12.996 ± 0.217	1.246	0.281	10.638	0.698	0.133

FedAvg has the shortest mean round time at 10.34 s. The BC and NOBC variants take from 12.96 to 13.82 s, approximately 1.3 times the FedAvg round time under this fixed workload.

Transfer is the largest component for all five methods, accounting for 8.95 s in FedAvg and 10.57 to 10.77 s in the validated workflows. Worker update distribution takes 4.44 s in FedAvg and 4.53 to 4.63 s in the validated workflows, while publication with required model retrieval takes 4.50 s and 5.32 to 5.52 s, respectively. The validated workflows deliver 45 complete model copies compared with 14 for FedAvg, while separate directed links can transfer concurrently.

The observed BC minus NOBC mean difference is 0.63 s for Soft and 0.03 s for Hard. These are whole workflow differences rather than isolated ledger overhead. Worker training, signing, and storage alone take 2.07 s for BC Soft compared with 1.29 s for NOBC Soft, a difference larger than their total round time gap. Soft and Hard retain all five benign updates in this clean workload, so the number of contributing updates remains unchanged.

(6)

Discussion and Limitations

After 300 communication rounds, FedAvg has higher FID under attack than under clean conditions on all five matched seeds. The two MFAIGC variants have lower mean FID than FedAvg under attack, but the prespecified paired tests do not establish a statistically significant advantage. Absolute FID values indicate limited generation quality.

Both MFAIGC variants flag all malicious validation records under the formal Gaussian attack with $\sigma =0.05$, and the earlier local-model sign-inversion test reports 100% detection. In the earlier near-threshold ratio scan at $\sigma =0.005$, worker-layer detection for the hard-filtering variants ranges from 9.03% to 14.29%, with no monotonic FID trend across the tested malicious-node ratios.

The H0 to H3 tests exercise normal processing, transaction and block tampering, and historical replay, recording all expected protocol events in the tested runs. The formal BC/NOBC comparison uses equivalent update checks and filtering rules. For offline collaborative model updates and governance, the independent timing study gives FedAvg the lowest mean round time at 10.34 s, compared with 12.96 to 13.82 s for the validated workflows. Transfer stages account for the largest share of round time.

The quality evaluation uses CIFAR-10 with Dirichlet partitioning at $\alpha =0.5$, fourteen logical devices, and five seeds. The independent timing study uses ten logical nodes and three repetitions of a fixed workload; both studies run on a single host. The tested Gaussian perturbations and model sign inversion do not adapt to the validation threshold. The findings apply only to these non-adaptive attacks. Model replacement, backdoors, adaptive attacks, Sybil attacks, and malicious validator or miner behavior are untested.

6. Future Research Directions

This section outlines several promising research directions that extend the BC-MFAIGC framework.

AIGC Generation Quality Evaluation. Generation quality is reported with the Fréchet Inception Distance (FID) on the trained diffusion model, under clean, medium-strength, near-threshold, and sign-flip conditions as well as across malicious-node ratios of 0–50%. Future work should complement FID with further generative-quality measures such as the Inception Score (IS), and should examine how BC-MFAIGC affects generation quality across system configurations, datasets, and model scales that were not covered here.

Inference Latency and Training Efficiency. The trade-off between blockchain consensus latency and AIGC service response time requires quantitative modeling. Future work should measure end-to-end latency across network types and integrate the consensus layer with the inference scheduler.

Privacy Leakage Quantification. BC-MFAIGC includes several privacy-protecting mechanisms, but adversarial modification of information remains a risk. Future work should quantify such risks with differential-privacy bounds or mutual-information leakage measures.

Theoretical Convergence Analysis. A formal study of how the BC-MFAIGC training process works under the FedAvg rule with blockchain-based validation filtering is still an open theoretical problem. The architecture’s theoretical foundation would be stronger if we could establish convergence bounds under Byzantine node assumptions.

Resource Coordination. Edge participants may have limited computing resources. It remains open how to allocate scarce resources across cloud, edge, and end devices and how to place models appropriately under resource constraints.

Incentive Mechanism Optimization. Incentive and traceability designs depend on the application domain, so domain-adaptable frameworks are needed. Consensus and incentive computations also add delay, which must be reduced to avoid degrading service quality.

Blockchain Contribution Evaluation. Future work will compare blockchain-based update management with nonblockchain implementations using equivalent checks to clarify the blockchain-specific security contribution.

Full Life-Cycle Management. Managing AIGC models across their life cycle, including versioning, rollback, deprecation, and access revocation, remains an open engineering direction.

7. Conclusions

In this paper, we present BC-MFAIGC as a framework that coordinates edge computing, federated learning, and blockchain for mobile AIGC service provision and update management. Edge placement, federated parameter exchange, and blockchain records provide the architectural basis for addressing service latency, resource constraints, data governance, and privacy risks. The medical scenario illustrates how the framework can be applied to a privacy-sensitive AIGC service. We also conduct simulation experiments for the implemented AIGC model-training workflow. Under the medium-strength Gaussian weight-perturbation condition, the FID increase of the MFAIGC soft-aggregation variants is 2.5–9.3%, compared with about 22% for FedAvg, although neither variant has a statistically significant advantage in attack-condition FID over FedAvg. The worker-layer detection rate in the near-threshold regime is 9.03–14.29%. The attack-ratio scan, protocol audit, and runtime analysis further examine the operating range and processing cost of the workflow. The blockchain layer contributes signature verification, block-integrity checking, replay handling, and auditable update records, and adds 8.6% to the round wall time in the simulated ledger configuration. These findings support the feasibility of the implemented training and update-management workflow under the studied conditions. The evaluation uses CIFAR-10 and a single-machine simulation with 10 homogeneous nodes; broader mobile deployments, heterogeneous data and hardware, additional attack models, and end-to-end service metrics remain directions for future work.