FedMarket: A Cryptocurrency Driven Marketplace for Mobile Federated Learning Services

Federated learning (FL) enables the training of a shared collaborative machine learning model while keeping all the confidential training data on distributed devices. The FL state-of-the-art considers a monopolist FL task publisher. However, we present a FL marketplace where multiple FL task publishers and mobile devices co-exist for a set of diverse and varying learning tasks. Mobile devices participating in the training of FL models provides pay-as-you-go (i.e. using blockchain-based cryptocurrencies) FL training services to the FL task publishers. In the proposed framework, multiple FL task publishers may compete with each other and the participating workers (i.e. mobile devices) can choose one FL task publisher over another for participation in the training of a global model. We utilize code offloading for enabling customized FL pipelines in mobile devices and mitigating the model heterogeneity inherent in varying and changing FL tasks published by the task publishers. Experimental results indicate the efficacy of the proposed framework.


I. INTRODUCTION
The pervasive and ubiquitous penetration of smart devices, e.g., smart mobile devices, smart wrist bands, body sensors, home appliances, and autonomous cars into day-to-day life generates a massive volume of data. These smart devices take leverage of machine learning technologies for improving the generalized user experience. On the other hand, corporations providing the application ecosystems for these smart devices are eager to collect and analyze the massive data distributed across the user devices both for making service improvements and making a business value out of the data. However, this data collection and analysis is not trivial in terms of storage and processing at the central servers. Moreover, enforcement of administrative and regulatory laws such as the European General Data Protection Regulation (GDPR), China's Cyber Security Law, and the United States California Consumer Privacy Act, restricts sharing and collecting user data. This scarcity of training data volume can hinder the performance The associate editor coordinating the review of this manuscript and approving it for publication was Meng-Lin Ku . of machine learning tasks carried out in corporations. Furthermore, the commercial competition between data aggregators and application service providers also restricts data sharing. Since, with these restriction in place the number of training samples would not be large enough to generalize the model which affect the performance of the trained model.
Federated learning (FL) is a distributed privacy-preserving machine learning technique that enables mobile devices to collaboratively train a shared global model without the need of uploading private local data to a central server to overcome the privacy concerns caused by centralized machine learning over confidential user data. Figure 1(a) presents the vanilla FL approach [1]. The pinnacle of success behind FL is mainly due to the decentralized training process of a collaborative machine learning model. This decentralization relaxes and distributes the computation and storage cost of the central server along with preserving the privacy of the private confidential data distributed across a range of user devices and application platforms (hereinafter referred to as workers). In FL, the workers individually and independently train their local machine learning models on their confidential data. The local model weights also referred to as local model updates (LMUs) are then delegated to a central aggregation server, while no training data is sent and it remains on the user devices. FL also minimizes the network traffic cost as only LMUs are shared while no data is being shared. After collecting local model weights from a qualified number of worker nodes, the central server aggregates the received weights generally by averaging to form a new global collaborative model, which will be delivered to the workers for the next round of model training. This distributed training iteration repeats until the global model converges to satisfying test accuracy. Through FL, the individual privacy of user data could be effectively preserved as no private data is shared among the user device and the central server. However, due to the lack or in-existence of monetary incentives user devices are reluctant to become workers for FL tasks. Furthermore, the user devices may be competing and reluctant to share their model parameters since the competitors also benefit from a trained global model [2].
Providing monetary incentives for monetizing the on-device FL can increase the expectation of user devices for participating in training the global predictive model. In this context, the notion of a market similar to crowdsourcing platforms such as amazon mechanical turk 1 seems a fitting substitute where the worker monetize their model parameters trained on their private data. In this manuscript, we perceive an FL market (presented in Figure 1(b)) where individuals can monetize execution of the FL process requested by an FL task publisher on their mobile device and provide focused LMUs to the FL task publisher server in compliance with the GDPR to safeguard the user's privacy. FL task publishers that are willing to pay the price to geographically dispersed different user devices for training the FL model on user's local data will publish their task specifications for interested worker mobile devices. In the perceived FL market the FL 1 https://www.mturk.com/ task publisher establishes on-demand ad-hoc FL networks of distributed mobile devices to complete a learning task. Therefore, unlike the conventional FL environments that consider a monopolist FL task publisher primarily with a single task, the FL market enables the competition between multiple FL task publishers (possibly with multiple numbers of tasks) with each other and enables the participants to choose one FL task publisher over another for participation in the training of a global model. FL task publishers can collect LMUs from a large crowd of users, which makes the market a useful channel for corporations and in the formation of private FL overlays. Individuals providing LMUs can control their FL process by managing how much wall clock time they register on the market including the price of each FL session. On the other hand, the FL task publishers can publish multiple tasks and provide monetary incentives for the LMUs to the users who subscribed to their tasks. Therefore, perceiving a double-sided FL market model where task publishers and individuals jointly operate the market for their rational benefits. Hereinafter, FL task publisher, task publisher, aggregator, FL aggregator, and buyer are used interchangeably. Similarly, worker, client, participant, mobile/user device, and seller are used interchangeably.
The FL marketplace (where mobile users sell LMUs and FL task publishers go to buy LMUs for an FL process) based on guidelines of electronic marketplaces in [3] perform three essential market functions: (a) matching of model sellers and model buyers; (b) facilitating the exchange of information regarding FL process, and the payments associated with market transactions; and (c) providing a legal and regulatory framework, that enables the efficient functioning of the market. Generally, the first two marketplace functions are provided by centralized intermediaries (i.e. business entities referred to as brokers/auctioneers), while the legal and regulatory framework falls under the umbrella of statutory rules and regulations set by governments. However, the centralized intermediaries might be dishonest and result in payment theft, collude, and contract manipulations and pose trust issues to VOLUME 10, 2022 the market participants (i.e. sellers and buyers) for executing the market functions. Furthermore, with the dynamic birth and death of agents in the marketplace, the conventional mode of payments through banking or credit transfers from the network operators (provided the FL task publisher have prior agreements with network operators) is not suitable for the FL marketplace to minimize the churning and free-riding of the worker nodes. To address the problem of trust associated with the payments, we consider blockchain technology [4], due to the consensus, provenance, ownership, immutability, finality, and access control attributes for executing the payment functions of the marketplace. More specifically we utilized the Ethereum blockchain protocol [5], [6] that supports a Turing-complete language and has its native cryptocurrency i.e. Ether. Ethereum virtual machine (EVM) in the ethereum blockchain network executes the code referred to as ''smart contract'' behind DApps and publishes the resulting output to the respective blockchain following a consensus method similar to Bitcoin [4]. The distributed nature of EVM makes smart contracts impossible to censor and eliminates trust issues posed by a centralized administrator in distributed applications such as the marketplace.
The main contributions of this article are summarized as follows: • We explored an FL environment where multiple FL servers may compete with each other and the participants can choose one FL server over another.
• We utilized blockchain as a means to trade and incentivize the mobile device workers for providing FL services to the FL task publishers.
• We devise a novel method to incentivize reputed workers with high-quality training data that is more useful for the collaborative global model of the task publisher.
• We utilize reverse code offloading to enable customized FL pipelines in mobile devices and to mitigate the model heterogeneity inherent in varying and changing FL tasks published by the task publishers.

II. RELATED WORK
The concept of FL under the definition of distributed artificial intelligence can be traced back to 1980 [7]. Google introduced the privacy-preserving FL concept for context predication in the virtual keyboard for their flagship android operating system [8]. Following this, the authors in [9] discuss the architectural concepts and potential applications of federated machine learning. The majority of the FL stateof-the-art literature can be classified into the performance of learning algorithms in terms of learning time/accuracy, client selection [10], training security [11]- [13], and incentive mechanism design [14]- [16]. Most of the existing FL studies generally assume a monopolist environment consisting of K workers collaborating with a single FL server. There are few articles such as [17], [18] which consider an FL system model comprising of multiple FL task publishers. Authors in [17] considered bandwidth allocation in wireless networks hosting multiple co-existing FL services. On the other hand, authors in [18] proposed a mechanism design oriented FL protocol on a public blockchain network to reward only well-contributing workers. However, the proposal presented in [18] is impractical in terms of the gas cost associated with the smart contract functions since the intensive workload is being delegated in the smart contracts. Furthermore, the overall time latency involved in the FL process will be very high due to the evaluation and voting process of all local models submitted for aggregation. Lastly, their proposed system cannot be generalized since it is bounded to a single model type (i.e. DNN). However, in a practical setting, every task publisher will be interested in training a different machine learning model in different time slots. In this response, we consider an alternate setting to this where multiple FL servers may compete with each other and the participants can choose one FL server over another to train the global model while provisioning monetary incentives to participating clients and handling the model heterogeneity and training data preparation using computational offloading.

III. FedMarket: MARKETPLACE FOR MOBILE FEDERATED LEARNING SERVICES
The system architecture in figure 2 presents the participants of the system, buyers (i.e., FL task publishers), sellers (i.e., mobile devices) interacting via a broker (i.e. a central cloud service), and the ethereum distributed ledger. In FedMarket, mobile devices offer FL services in terms of executing the FL client processes for the FL task publishers with varying QoS attributes. In theory, there could be a large number of FL task publishers providing differential incentives to execute their FL tasks over mobile devices with minimum prices and better QoS. Mobile devices are interested to maximize their profit or revenue by selling their resources at a high price while meeting the requirement of the FL task publishers. To achieve their respective objectives, both the mobile devices and the FL task publishers compete strategically in the FL market. Furthermore, monetary incentives can enhance the motivation of mobile devices to subscribe to the learning task of the publishers [19]. To provision monetary incentive we consider decentralized escrow (similar to one proposed in [20]) based on Ethereum blockchain protocol [5], [6] for executing escrow functions of a marketplace.
A. FL TASK PUBLISHERS: BUYERS FL task publisher (i.e. buyer) is interested in buying the willingness of mobile devices (i.e. sellers) for the execution of FL worker tasks to train a collaborative global predictive model. For each task to publish the task publishers are required to submit the intermediate level bytecode of the ''ClientUpdate'' function of the vanilla FL algorithm [1] to the central broker. Depending upon the target device heterogeneity the publisher can register multiple flavors of the FL worker ClientUpdate function for a range of different device types. In vanilla FL participating mobile devices should agree on a particular model w so that the global machine learning model can be trained effectively by aggregating the model weights obtained from mobile applications. However, practically mobile devices/applications, craft their model architecture adaptive to their learning objective and application environments. Mobile applications due to privacy concerns not willing to share the model architecture details. Hence, the model architectures from different mobile applications exhibit heterogeneous model shapes and structures, making it impossible to perform aggregation by conventional FL. Model heterogeneity inherent in mobile environments has attracted considerable research attention due to its practical significance for intelligent mobile applications [21], [22].
On the other hand, in a marketplace where there are multiple FL task publishers, each of the publishers as illustrated in Figure 3 will be using a different type of machine learning algorithms in federated settings. Furthermore, each publisher for each task after a passage of time might be interested in training its predictive model using a different machine learning algorithm in federated settings.
To address the curse of model heterogeneity and changing dynamics of the required model by a task publisher in the FL marketplace we consider the notion of publishing the intermediate level bytecode of the ''ClientUpdate'' which is then dynamically loaded by selling agents using code offloading techniques. Dynamic code loading enables FL task publishers to inject their task-specific FL worker code into the selling agents. This will allow the seller for performing different types of tasks and will need not to maintain and inline itself with all possible buyers and the type of FL mechanism they are implementing. The buyer will implement the ClientUpdate procedure which result in transparency in term of heterogeneity of model architecture and machine learning mechanism from the seller's point of view. Furthermore, the task publisher implementation of the FL client also enables the task publisher to implement mechanism that ensure the freshness of the training data, along with capabilities of pre-processing and interactive data acquisition from the seller. VOLUME 10, 2022 In addition to the ClientUpdate function, for each task, the task publisher also needs to submit a test data set and a Model Accuracy Testing (MAT) application to the central broker server. The test data set posted by the FL task publisher is the data set used by the publisher to test the accuracy of the converged global collaborative model. This dataset and the MAT application will be used by the broker for verifying and cross-checking the accuracy reported by the task publisher for fair incentive delivery. Besides publishing the software packages (i.e., ClientUpdate function and the MAT application) and the test data set the buyer while posting an FL task in the marketplace needs to publish the following FL task parameters: • Date and time at which the buyers need LMUs from the mobile devices.
• Details of the FL task preferably using ontological representation such as described in [23].
• Desired price, the price buyer wants to pay a single seller for a complete session of FL client execution.
• Highest acceptable price, the highest price buyer wants to pay a single seller for a complete session of FL client execution.
• Number of workers, the number of sellers required by a buyer for executing the FL client algorithm.
• Top-κ percent workers to which the publisher will release the incentives. The crude behavior of the FL task publishing agent is presented as Algorithm 1. Once, the buying agent posts a task, and the broker publishes the task after approving through manual and automated profiling of the task for security and vulnerability analysis. The task publisher agent starts to listen to request from the selling agents, it autonomously (i.e. without user intervention) negotiates with selling agents trying to make the best possible deal. Buyer agents are discovered by interested FL sellers through the ontological representation and these buying agents can autonomously negotiate without user intervention and make decisions on its own once it is released into the marketplace. Autonomous negotiation is important for buying agents due to the possibility of involvement of a large number of selling agents interested in registering as a worker for the published task. Once a buying and selling agent has reached an agreement on a price and gotten their respective user's approval. At this stage, the buyer requests the broker for initializing an escrow between the buyer and seller using a blockchain smart contract. Next, the buyer agents deposit the agreed price into the escrow and start consuming the seller FL service by requesting seller model updates via the broker. Once the FL task is finished the buyer will request the final models from all the workers subscribed for the task via the broker to identify the reputed top-κ workers who will receive incentives.

1) FINDING TOP-κ REPUTED WORKER
The Top-κ reputed worker (i.e. seller) for a single FL task is identified by the FL task publisher after the FL task is completed to which the workers subscribed. Since all the mobile Post a test data set and MAT application to broker. 4: Post ClientUpdate bytecode to broker. 5: if broker approves everything then 6: Publish the FL task as T 7: while Receive worker request via broker until the number of required workers is achieved do 8: Negotiate for the best deal based upon desired price and highest acceptable price. 9: If the worker agrees with the proposed deal request broker to initialize the escrow smart contract. 10: Deposit negotiated amount into the smart contract. 11: Notify worker via the broker. 12: end while 13: end if 14: if Schedule Approaches then 15: FLServer(T ) 16: end if 17: end procedure 18: procedure FLServer(T ) 19: intialize w 0 20: for each round t = 1, 2 . . . do 21: S t ← (random set of m clients) m is the client participating rate ranging from (0, 1] 22: for each client k ∈ S t in parallel do 23: w k t+1 ← RequestUpdate(k, w t , T ) from the broker 24: n k n w k t+1 25: X k ← t 26: end for 27: end for 28: for each client k = 1, 2 . . . K do 29: w k c ← RequestModel(k, T ) from the broker 30: Send topWorkers list to broker. 34: end procedure devices report their final model to the FL task publisher via the broker. The task publisher then evaluate the accuracy of all the models and selects the top-k worker based upon the test accuracy to which the incentives should be provisioned. The task publisher computes the accuracy using the same test data set on which the accuracy of the global model is computed. Furthermore, this is the same data set that is being submitted to the broker while posting the FL task. The broker randomly selects three workers from the chosen top-k workers and recomputes the test accuracy to ensure the truthfulness of the reputation score reported by the task publisher. However, it is imperative that the workers might not be included in workers ← {1, . . . , K } List representing the set of all workers 3: A ← Create dictionary from A where the key is worker id and value is accuracy of the worker k 4: Sort(A ) 5: Iterate until desired threshold of κ-top percentage of worker are filtered. 6: α ← arg min k X workers k Using equation to select a cut off worker from the set of workers. 7: for each key k in A do Iterating the dictionary 8: if A α ≥ A k then Filtering rule 9: workers ← workers − {kth worker } Remove worker from the filtered list 10: remove kth key from A 11: if |workers| == K × κ then 12: break 13: end if 14: end if 15: end for 16: end while 17: return workers Final list of worker who will receive incentives 18: end procedure the final training rounds of the global model and their final submitted model accuracy will not be fairly comparable to each other. Since in each round of global model training the publisher randomly chooses the workers and requests their LMUs via the broker. To ensure that monetary incentives are provisioned to only workers with high-quality data suited for the global collaborative model which is of interest to the task publisher we devise the following strategy.
Let us consider X k = R, where 1 < R ≤ T represents the final global training round a worker k is included for providing LMU to train the global collaborative model, T represents the total number of global training rounds. A k represent the accuracy of the final local model submitted to the task publisher via the broker by each worker 1 < k ≤ K . A k is calculated by the task publisher using the test data set used for computing the accuracy of the global predictive model. Now the following equation finds the worker α with minimum final round iteration attendance from the list of K workers.
The accuracy of α worker is used as cut out point i.e. for all workers k if the A α > A k remove worker k from the list of the top-κ reputed workers. This process is repeated until the cardinality of the top-κ reputed workers' list shrinks to the percentage published by the task publisher. The top-α percentage of workers eligible to receive the monetary incentives are shortlisted using the iterative procedure ''FilterWorkers'' presented in Algorithm 2. Search and select a buyer based on task ontological parameters, schedule, and pricing. 3: Send request and negotiate with the selected buyer. 4: if buyer accept the request AND broker confirms the escrows then 5: Dynamically loads the ClientUpdate() procedure for the task from the broker. 6: end if 7: if Schedule Approaches then 8: Start FLWorker 9: end if 10: end procedure 11: procedure FLWorker Run on client k 12: while task finishing message not received from broker do 13: Received a request from the buyer with global model w to submit the LMU. 14: w ← ClientUpdate(w) 15: Send w to buyer via the broker. 16: end while 17: Send w to the broker. 18: end procedure 19: procedure ClientUpdate(w) This update procedure is dynamically loaded from the broker, it was originally published by the buyer with broker 20: B ← (split private data into batches of size B) Here the buyer can implement any pre-processing or data acquisition logic 21: for each local epoch i from 1 to E do 22: for batch b ∈ B do 23: w ← w − η∇ (w; b) 24: end for 25: end for 26: return w 27: end procedure B. MOBILE DEVICES: SELLER Mobile users are presented by selling agents which sells the user willingness for executing a client FL process published by an FL task publisher to perform local training over the mobile device private data and transmit LMUs to the respective FL task publisher. Algorithm 3 presents the generalized behavior of the FL task agent residing on the client mobile device, forthcoming paragraphs explain the working behavior of the selling agents.
A user can launch multiple selling agents. However, a single selling agent is associated at a time with a single FL task by a task publisher, on completion of the agreement or the FL task, the agent can sell its willingness for executing another FL task. The end-user has total control over the behavior of the selling agent. When the user first initializes the selling agent, they set various parameters from the ML-Schema ontology to guide the matchmaking behavior. The seller's goal is to receive the highest possible price for its resources. Exactly how to achieve this goal is left to the end-user controlling the seller agent. While the users are free in terms of how to achieve their objective. The crude heuristic is: begins searching willing buyers based on the ontological parameters such as model and data set characteristics, date and time at which the selling agent can execute the client FL process, and price ranges if there is any. If the search results do not show up any buyer, the user can change the search parameters accordingly. There may be no buyers (perhaps the search parameter of user interest is not listing any). In this case, the agent fails to achieve its goal.
In an FL marketplace where mobile device workers (especially when workers dynamically load the client FL process) serving an FL task publisher for a common learning task needs structural homogeneity of the data types in all workers. This type of heterogeneity is mainly caused due to the manual curating of the training data available at mobile devices illustrated in Table 1.
To address the structural homogeneity of the data types considering a large number of mobile devices in the FL marketplace the data acquisition for on-device FL is recorded by the onboard electro-mechanical sensors of the smart device. This data acquisition of automatically produced data is naturally supported by the dynamic code loading by the selling agent. Another type of automatically produced data is of system/application log files of the smart device. The user is not required to curate automatically produced data since it will accumulate as the individual uses the service. Trading of FL updates from the automatically produced data is important in the marketplace because of the scale of the users who can subscribe for the FL task relatively at a very low cost. Furthermore, the dynamic code loading of the FL task client in the selling agents allows the task publisher to ensure the freshness of the training data and also can be programmed to label the captured data manually by the end-user operating the selling agents, before the local machine learning execution.
The user can check on its selling agents, see who they have talked to. Once the user finds a buyer of interest, the selling agent will be configured by the user to send a request with the desired price for subscription as a worker to the FL task published by the buyer. If the buyer accepts the proposal and initializes an escrow contract with depositing the desired price into the smart contract marking the selling agent as a subscribed FL worker. At this point, the selling agents autonomously request the broker to migrate/offload the bytecode or binary such as ClientUpdate that implements the local model update mechanism. This reverse offloading mechanism is explained in the upcoming subsection. The selling agents should not offload the LMU mechanism directly from the buyers to minimize the security risk as the buyer might inject malicious code in the FL client to compromise the client device security. Instead, the code offloading should be from the broker to the mobile device, where the broker has the responsibility to analyze the LMU mechanism posted by the task publisher for any malicious intents.

1) REVERSE CODE OFFLOADING
Generally, computational offloading is a software-level solution which to some extent augments the capabilities of resource constraint mobile devices by remote execution of the complete or partial compute-intensive application at a remote computing infrastructure. Typically computational offloading is considered for enhancing the energy consumption and execution time for the programs executing on resource constraint mobile devices [24].
The most popular and common technique to leverage the computational power of the cloud in mobile devices is code migration. This technique involves the delegation of code execution by migrating a platform-independent intermediate code (i.e. byte code) to remote cloud servers [25] presented in Figure 4(a).
Many attempts (such as [26]- [28]) have been done in past to enable remote execution using code migration for improving the performance and battery consumption of mobile devices. Most of these code migration-based offloading attempts rely on programmers to specify program partitions using code annotation and skeletons [25].
In our proposed marketplace framework we consider the same concept of code migration for reverse code offloading presented in Figure 4(b), in which the broker offloads the FL intermediate code implementing the LMU (i.e. the client update) mechanism to the mobile device to mitigate the model heterogeneity issues due to the variety of ML tasks posted in the marketplace for collaborative processing. Reverse code offloading brings transparency to the distributed mobile devices concerning the implementation of the model update mechanism and enables the mobile devices to register as a worker for any FL task they are interested/willing to participate. Furthermore, the task publishers curated code offloading to the mobile device enables the task publisher to modify the FL pipeline on the distributed crowd of mobile devices subscribed as workers for the FL task. The client update mechanism published by the task publisher can contain procedures for customized data pre-processing, labeling of automatically produced data, and interactive data acquisition, along with semantics for executing the client update if and only if the freshness of local data meet certain criterion.

C. BROKER
The broker being the central manager of the system is responsible for providing a platform for connecting buyers, and sellers. Broker act as a third-party intermediary operating between sellers and buyers. The intermediary business model recognizes that there is value in providing platform services for connecting FL task publishers and participants. This realization of business value motivates the broker to be the custodian for the escrow and avoid scenarios of unwanted troubles, theft, collude, and contract manipulations. The intermediary seeks to act as a trusted agent, providing the opportunity and means for participants (i.e. workers) to monetize and profit from their profiles following the incentive mechanism of decentralized blockchain-based escrows [20]. The general services and behavior exposed by a broker are presented as Algorithm 4 and explained in forthcoming paragraphs.
In the proposed networked economy model for FL, the broker collects all buy-bids and sell-bids and provides access for the blockchain smart contract to execute the incentive functions. The broker allows buyers and sellers to find a matching themselves through the process of bidding. However, the matching that results is not necessarily stable. For example, seller A might end up selling its FL service to buyer B, but would have preferred to sell its willingness to execute FL services to buyer C instead had A known about C (perhaps A just didn't see C's listing in her search results).
On the other hand, the broker should provide a software development library (SDL) for the publisher to write standardized FL aggregator, ClientUpdate and MAT agent applications. This SDL will provide baseline classes, interfaces, and hooks that need to be implemented in respective software packages to allow the broker to communicate with agents in a homogenous manner. SDL will enable the broker to maintain a uniform application programmable interface (API) services for pushing the global model into the FL worker and can pulling the respective LMU from the FL worker at each iteration of global training triggered by the FL task publishers. Furthermore, the utilization of SDL will enable the broker for a systematic online static analysis and offline security analysis to detect any malicious intents of the buyer on the intermediate code packages registered by the FL task publishers. The publisher can be allowed to connect with sellers if and only if the posted FL client intermediate packages do not have any malicious code. Through this loose coupling in the development of agents, the broker can implement state-of-the-art security features in the SDL for agent communication transparent to the market participant.
Once an FL process is started by the task publisher, the broker act as a relay node between the worker and task publisher as illustrated in figure 5, where as K k=1 n k n w k (t+1) represents the naive aggregation presented in the seminal FL proposal [1]. The buyer calls the RequestUpdate broker service to pull LMUs from a seller k for FL task T . The broker pushes the received global model from buyer to seller and in response receives LMUs from the seller. Broker as a relay node instead of direct communication between the task publisher and the mobile devices in the FL process is incorporated due to the following three reasons.
• The first reason to avoid direct communication between the task publisher and the mobile devices is due to the security/privacy concerns of the worker mobile device especially in an environment where the workers need to load the task publisher curated/developed client update mechanism.
• The second reason of broker as relay node correspond to the network access issues, where the FL task publisher aggregator is not reachable by a public IP address i.e. the publisher is operational behind a NAT, practically allowing any internet-connected device to act as a global model aggregator.
• The last reason is to maintain a record of the final local models of each worker mobile to ensure fair incentive provisioning. VOLUME 10, 2022 Upon completion of the FL process, the buyer calls RequestModel broker service for all the worker to request their respective final local models. This will also serve as a termination signal for the selling agents to stop the FL worker process. Upon delegating the final local models of all the workers to the buyer the broker will wait to receive the list of top-κ sellers from the buyer. Next, the broker will verify the list of top-κ workers and if the broker found the buyer truthful. Then, only escrows to the top-κ sellers are released while keeping some percentage as the service fee. Otherwise, if the buyer is found untruthful, the broker will penalize the buyer by releasing the escrows to all the subscribed workers for the respective task, while keeping the service fee. This penalization of the FL task publisher motivates the task publisher to be truthful while reporting the top-κ workers.

IV. PERFORMANCE EVALUATION AND EXPERIMENTAL RESULTS
In this section, we evaluate the FL process imposed by the proposed framework along with ensuring the provisioning of monetary incentives in terms of cryptocurrencies. However, features such as the optimal matching and price determination between buyers and sellers are the scope of our future research. Furthermore, in the proposed framework the matching is primarily initiated by the user actions behind the mobile device to find a suitable task of interest. All the agents are developed using python and the agents use Web3.py to interact with the ethereum network. The ethereum test-net is implemented using Go Ethereum blockchain implementation. For simplicity of the incentive analysis in the marketplace, the ethereum test-net is configured with zero gas for running a transaction or contract, and all the agents call the smart contract function with zero gas limit. Furthermore, each of the platform agents is configured with an ethereum network address that is used to interact with the underlying ethereum test-net for depositing and receiving cryptocurrency from the escrow smart contract.
In our simulation experiments, we introduce two FL task publishers each with a single task and 400 worker mobile devices, whereas we hard-wired 200 worker mobile devices to each task. In practice, the number of tasks an FL task publisher can post depends on the policy of the broker which can allow as many tasks as required. On the other hand, for the seller considering the computational capacity of the mobile devices their participation should be restricted, in our Algorithm 4 BrokerService 1: procedure ListenBuyers Run in cyclic fashion listening buyer requests for task publishing 2: Receive FL task details from buyers.

3:
Receive MAT application and test dataset for the task.

4:
Receive ClientUpdate byte code for the FL task. Security analysis of software packages.

5:
if software packages pass the security analysis then 6: Publish FL task T for clients. 7: end if 8: end procedure 9: procedure SearchBuyers Called by the sellers 10: Receive search parameters from sellers.

11:
Return list of all matching active FL tasks to the seller. 12: end procedure 13: procedure BidonTask Called by the sellers 14: Receive a bid proposal from seller for a particular task. 15: Notify the FL task publisher about the proposal. 16: while the task publisher either rejects or accepts do 17: negotiating messages between seller and buyer 18: end while 19: if task publisher accepts the bid then 20: init escrow over blockchain b/w publisher and seller. 21: Inform the task publisher about the contract address.

22:
Wait for publisher escrow deposit to smart contract. 23: if task publisher deposit escrow amount then 24: pair the task publisher and the mobile device. if buyer and seller is paired for the given task then 33: offload the buyer registered bytecode for task T . 34: end if 35: end procedure 36: procedure RequestUpdate(k, w, T ) Callable by the buyer only 37: if requesting buyer and seller k is paired for the given task T then 38: Push current global model w to worker k for task T . 39: Pull LMU w k from worker k for task T . 40: Push w k to the buyer. 41: end if 42: end procedure 43: procedure RequestModel(k, T ) Callable by the buyer only 44: if requesting buyer and seller k is paired for the given task T then 45: Send task finishing signal to the seller k.

46:
Pull and store final local model from seller k for the given task T and delegate it to the requesting buyer. 47: end if 48: if local model of all sellers is delegated to the buyer the given task then 49: Wait until the List of Top-κ workers is received from the buyer. 50: Choose Random 3 workers from the top workers' list. 51: Confirm the accuracy of the randomly chosen workers using MAT and the data set submitted by the buyer. 52: if buyer reported truthfully then 53: Release escrow amount to the Top-κ workers. 54: Release the remaining deposit to the buyer. 55: else 56: Release escrow amount to all workers. 57: end if 58: end if 59: end procedure simulation we consider a seller to participate in a single task at a time. The details of the task published by the task publishers with the broker are presented in Table 2. The first task publisher publishes Task 1 to train a collaborative logistic regression global model on the MNIST dataset [29]. While the second task publisher published Task 2 for training a collaborative model using LSTM on Fashion-MNIST dataset [30]. In a crowdsource scenario like the one considered in this manuscript, the data distribution would generally be classified as non-IID. In our experiments, we considered non-IID data distribution in the clients, where the individual clients mostly hold 5 different classes. According to Table 2 each of the task publishers has acquired the services of worker mobile devices on a fixed rate of 10 ethers for the execution of the FL process, hence the task publishers deposited 10 ether to the escrow smart contract of each worker with a total deposit of 2000 ethers for the complete learning task. The broker fee on each escrow is 2%. The task publishers are willing to incentivize up to 50% of the total 200 workers hired, these workers are filtered through the Top-κ procedure. The task publisher in practice can set the number of global iteration to any other stopping condition such as time, or convergence to a particular level of accuracy, herein our simulation is set to 100 global iterations for Task 1 and 1000 global iterations for Task 2, and one local iteration at the client for both the tasks.

A. LEARNING PERFORMANCE
The learning performance of Task 1 is presented in Figure 6, while Figure 7 presents for Task 2. In our simulation setting the mean final global model accuracy of five experiments on Task 1 is 87.18%, while for Task 2 it is 84.074%. Note that, the number of global and local rounds can also play a significant role in improving the accuracy of the global round. However, in our experiments, it is fixed. Compared to the state-of-the-art the reported accuracy can be low since our objective here in this manuscript is not to investigate and improve the learning performance of FL algorithms. Rather the objective is to outline a mechanism for trading mobile device FL services whereby monetizing mobile device workers with high-quality data learning performance. The learning performance plotted in Figure 6 and Figure 7 indicates the acceptable and consistent performance of the FL process in each run of the experiment, wherein each experiment the data distributions hosted in clients varies.

B. FILTERING HIGH-QUALITY WORKERS
High-quality workers' clients in the FL process are identified using the proposed Top-κ filtering procedure presented in section III-A1. Table 3 presents the Top-κ clients filtered in each of the experiments for both the tasks. In the first part of Table 3, each row presents the Top-κ clients by listing the client device ids which are selected in the Top-κ filtering procedure while executing the experiment. In the second part of the Table 3 In each of the experiments, the reported accuracy statistics both for the global model and the local clients model are computed using the same test dataset (as explained in the Top-κ filtering procedure). It is noted, that in all of the experiments of Task 1 and Task 2, the best local model submitted by a client outperforms the global model accuracy, except the 5th experiment of Task 2, where the global model accuracy is 84.49% while the accuracy of the best local model submitted by a client is 84.38%. The extra processing steps of testing accuracy of the final local model of all clients proposed in this manuscript enable the task publisher to choose a more suitable model from the local model as a replacement for the global model. Since the accuracy of the final local models and global model is computed using the same dataset, the task publisher can replace the global model with a representative final local model of best-performing clients as a new global model. However, doing so in each global iteration rather than at the end of the FL process will be computationally very expensive for the FL task publisher, and also the resulting global model, in that case, would not be generalized rather than personalized in a case in each global iteration the same client provides the best model. Lastly, the  final local model submission can be avoided for communication efficacy, in that case, the task publisher has to keep a record of the last model submitted by each of the clients.

C. REPLAYING FL PROCESS
A replay of the FL process with only Top-κ clients is performed to check whether the final global model achieved by aggregating the local models of only Top-κ participants will result in an acceptable model accuracy or not. This replay process ensures the efficacy of Top-κ filtering procedure. In the replay process, in each global round, all the Top-κ clients have been polled for aggregation i.e. all 100 clients participated in each round no random selection of clients. The random selection of client participation is ignored to ensure a fair comparison with the original experiments. Since in the original experiments in each round almost 100 random clients participate in each global round. Figure 8 presents the replay of each experiment of Task 1, while Figure 9 presents the replay of each experiment of Task 2. The results in Figure 8 and 9 indicate that the fairness of incentives that will be provisioned to the Top-κ participant. In particular, the last sub-plot of Figure 8 and 9 present the comparison between the global test accuracy of the original experiment, and the replay experiment. These subplots indicate for some instances replaying the FL process with only Top-κ participant outperforms the accuracy achieved in the original experiment, this ensure that Top-κ participant have high-quality and useful training data for the said training task. Note that while replaying in each experiment the data hosted by the client in the original experiment and the replay experiment is kept same for fair comparison.

D. MONETARY INCENTIVES
Before the task starts the task publishers of both Task 1 and Task 2 has deposited 10 ether as an escrow for each client totaling 2000 ethers for each of the tasks. On the completion of the task, the broker releases the escrow amount to the clients' ids listed in Table 3. Since the client determined in Table 3 are the high-quality worker in the FL process, these workers are shortlisted by Algorithm 2. To support the intermediary business model of the broker to provide the FL market platform, the broker deducts 2% on each successive release of the escrow to the client devices. The clients' id listed in Table 3 received 9.8 ethers after finishing the task since 2% is deducted by the broker as a fee. The broker fee is a policy matter of the broker and can change from broker to broker, in the case of multi-brokerage systems. On the other hand, 1000 ethers are returned to each of the task publisher's initial deposits of 2000 ethers. As the task publisher is only willing to provide incentives to 50% of the subscribed workers that possess high-quality training data.

V. CONCLUSION
Providing monetary incentives for monetizing the on-device FL can increase the expectation of user devices for participating in training the global predictive model. This paper proposed FedMarket, a brokerage market framework that enables multiple FL task publishers and mobile devices to co-exist for a set of diverse and varying learning tasks. The proposed framework utilize cryptocurrencies as means to trade FL services and employed a decentralized escrow approach over the blockchain smart contract to provide monetary incentives to FL worker with high-quality training data for participating in an FL task. FedMarket employs code offloading in mobile devices to enable customized FL pipelines in mobile devices and mitigate the model heterogeneity inherent in varying and changing FL tasks published by the task publishers. In the future, we will investigate the proposed framework as a design of double auction-based mechanisms for FL markets where task publishers and worker devices co-exist for a set of diverse and varying learning tasks. LATIF U. KHAN received the M.S. degree (Hons.) in electrical engineering from the University of Engineering and Technology (UET), Peshawar, Pakistan, in 2017, and the Ph.D. degree in computer science and engineering from Kyung Hee University (KHU), South Korea. He is currently working as a Postdoctoral Research Fellow at KHU. He is also working as a leading Researcher with the Intelligent Networking Laboratory under a project jointly funded by the prestigious Brain Korea 21st Century Plus and Ministry of Science and ICT, South Korea. Prior to joining the KHU, he has worked as a Faculty Member and a Research Associate at UET. He has published his works in highly reputable conferences and journals. His research interests include analytical techniques of optimization and game theory to edge computing, end-to-end network slicing, and federated learning for wireless networks. OWAIS HAKEEM received the bachelor's degree in computer science from the University of Peshawar, in 2012, and the master's degree in computer science from COMSATS University Islamabad (CUI), in 2017, where he is currently pursuing the Ph.D. degree. He is currently working as a Lecturer with the Department of Computer Science, School of Systems and Technology, University of Management and Technology, Lahore, Pakistan. He has published various research articles in prestigious international conferences and journals. His research interests include intelligent autonomous vehicles, edge computing, the Internet of Things, and wireless-based cyber-physical systems.