IEEE Computational Intelligence Magazine - August 2022 - 29

Before delving into each step, the key
designs in BLADE-FL are elaborated as follows.
B. SC Design
SCs are self-executing contracts defining rules
for negotiating, verifying the fulfillment of
rules, and executing the agreement using formal
code. The BLADE-FL framework relies
on SCs
to enable trusted dynamic client
selections in terms of desired distributed learning services,
without relying on a centralized authority. Moreover, BC-FL
enables all clients to verify the learning results that are recorded
on the blockchain, whereby distributed clients can be
incentivized to participate and untrusted learning models can
be detected. Based on the verification results, the reputation of
each distributed client can be automatically updated, making
the selection of learning nodes more reliable. In addition, the
design of SCs in the BC-FL also includes the aggregating
rules, and thus provides a fair and open rewarding of feedback
for participating clients. The SC in BC-FL enables three main
functions as follows.
Function 1: Learning task publishing. A task publisher
broadcasts an FL task through an SC to all users. The SC contains
the task requirements (e.g., the data size, training accuracy,
latency, etc.), the aggregating rules, and rewards paid by the
task publisher.
Function 2: Dynamic bidding for requests and automatic
incentive. Distributed training nodes, acting as auctioneers, bid
for the task by replying with their costs and capabilities. Note
that to enforce accountability, each training client must stake a
deposit to the SC. The task replies from training nodes are
recorded on the blockchain by the SC. Then, the SC selects
training clients with more valuable replies (e.g., higher capability
and lower cost) as the bid winners to jointly execute the FL
task. The training clients that lose the bidding will reclaim their
deposits from the SC, while the deposits made by winners will
be automatically refunded if the learning results are verified to
be trustworthy afterwards.
Function 3: Learning results aggregation and rewards feedback.
Before generating a new block, each client will aggregate
the uploaded models according to the aggregating rule in the
SC, in which the contribution of each one in the aggregated
model is also recorded in the newly generated block. Then, the
SC is automatically triggered to reward the miner that helps
aggregate the learning model and the training clients that contribute
to the FL process.
C. BLADE-FL Design
The main purpose of BLADE-FL is to enable trusted cooperative
ML among distributed nodes. The decentralized accountability
enables all miners to verify the quality of uploaded
models that are recorded on the blockchain. In addition, distributed
training nodes can be motivated to participate in the
FL process and misbehaving ones can be recognized from the
low-quality FL services they provide. The key steps follow.
Local model updating and uploading: Training nodes
are bid winners with capable devices and available sets of data
samples. In each learning iteration, each training node updates
a local ML model in a parallel manner by using the global
model and its local data samples, and broadcasts its local model
in the network. In the present work, local updates can be
received by all of the miners through the gossip protocol [12]
over the P2P network. In this context, the aggregation process
in traditional FL is decentralized to each client that stores the
uploaded models in its respective model pool.
Model aggregation: After collecting the uploaded models
in the pool, each client calculates the global model updates
according to the aggregating rule in the SC. In the proposed
architecture, the clients are designed to aggregate the learning
parameters truthfully through a distributed ledger. Similar to
the prevailing block structure in [6], each block in a ledger
consists of body and header parts. Specifically, the body stores
the local model updates, such as the local data size and computing
time of the associated training node and the aggregated
learning parameters. The header contains the information
of a pointer to the previous block, block generation rate, and
output value, such as the proof of work (PoW), in the consensus
protocol.
Model recording and publishing: The clients record the
aggregated models in their blocks and publish the recorded
models by broadcasting the generated block to the entire network.
The blocks can be generated by using distributed or
lightweight consensus protocols, such as PoW, proof of stake
(PoS), delegated PoS (DPoS), etc. [13]. In this paper, PoW is
considered due to its strong security over decentralized networks,
and a synchronous schedule is used to ensure that all of
the miners start mining at the same time.
Once a client finds the hash value, its candidate block
becomes a new block, and the generation rate of this block is
controlled by the PoW difficulty. Then, this generated block is
broadcast to all of the other miners in the framework. All of the
other miners must verify the nonce and the aggregated results
contained in this block. For example, clients can compare the
aggregated results with the one in the publishing block or use a
public testing dataset to justify the effectiveness of the uploaded
models. If the verification result is correct, other clients will
accept it as a legal block and record it; otherwise, others will
discard this generated block and continue to mine the previous
legal block.
Reward allocation: The task publisher provides learning
rewards for the participating training nodes, and the
AUGUST 2022 | IEEE COMPUTATIONAL INTELLIGENCE MAGAZINE 29
As a secure technology, blockchain has the
capability to tolerate a single point of failure with
distributed consensus, and it can further implement
incentive mechanisms to encourage participants to
effectively contribute to the system [5].
IEEE Computational Intelligence Magazine - August 2022

Table of Contents for the Digital Edition of IEEE Computational Intelligence Magazine - August 2022
