Original author: AR Short, HC Leligou and E. Theocharis*
Original title: Execution of a Federated Learning process within a smart contract*
Original link: https://ieeexplore.ieee.org/document/9427734 *Original source: IEEE International Conference on Consumer Electronics (ICCE) , 2021
Notes Author: quangaoyuan
Note Editor: quangaoyu an
A. R. Short, H. C. Leligou and E. Theocharis, "Execution of a Federated Learning process within a smart contract," 2021 IEEE International Conference on Consumer Electronics (ICCE), 2021, pp. 1-4, doi: 10.1109/ICCE50685.2021.9427734.
0x00 keyword
Blockchain, Federated Learning, Smart Contracts, Verification Algorithms
0x01 Summary
High-quality datasets have always been valuable for creating machine learning (ML) models. Therefore, it makes sense to provide rewards to users who participate in the federated learning (FL) process using such datasets. In this competitive scenario, we designed a solution that leverages blockchain networks, smart contracts, and model validation algorithms to coordinate the training process, record user performance, and provide rewards in a transparent manner.
0x02 INTRODUCTION
Federated Learning (FL) is a promising machine learning (ML) technique that allows models to be trained in a decentralized manner. This process provides improvements in privacy since participating users only share gradients (in the form of model updates), not actual data. In recent years, researchers have proposed ways to combine the FL process with blockchain technology to provide improvements in different aspects. More specifically, research has shown that such solutions can provide improved auditability [1][2], accountability [3], the ability to store model updates in a decentralized manner [4], and improved security [5], and can be used to facilitate incentive mechanisms [6].
This paper proposes and details the architectural design of such a solution, where the FL process is coordinated by smart contracts running on a private blockchain network. Smart contracts are responsible for validating contributions, computing global models, and recording user performance to support incentive programs. To the best of our knowledge, a similar approach (i.e. running a validation algorithm in a smart contract to validate model updates and in turn provide rewards/incentives) has not been proposed or researched. It is worth mentioning that some of the terminology used in this article is specific to HyperLedger Fabric (HLF); however, similar principles may apply to other private blockchain networks. The solutions described in this article are designed to provide improvements in:
A. Safety
Running a model update verification algorithm in a smart contract can prevent model poisoning attacks [7]. In this attack scenario, an adversary may send malicious model updates to affect the performance of the global model, change its behavior, or prevent other users from accessing it [8]. In solutions that use some kind of incentive scheme, this verification process is required. Otherwise, malicious users may benefit from this scheme by sending empty or worthless contributions, while degrading the performance of the global model.
B. Incentive Program
To achieve trust, smart contracts can be used to record the performance of each participating user. The distributed ledger of a blockchain network is the perfect medium for storing rewards in a transparent manner because it is decentralized. For example, HLF can be configured so that at least a certain percentage of nodes are required to reach consensus. Furthermore, a higher level of transparency can be achieved by executing the verification algorithm in the smart contract, which is especially important in our setup since the output of this algorithm is used to compute incentives.
We envision that this solution will be valuable in situations where higher levels of trust are required, as it enables competing entities to synergistically improve and use shared machine learning, while highlighting active users. The location of the blockchain nodes depends on the use case. For example, when a small number of competing industries or associations cooperate in the FL process, they may choose to host one node each (i.e., the node is closer to the end user). Alternatively, a trusted third party is required to host the solution.
The following sections describe the algorithms used for validation and reward computation (Section 2), the training process coordinated by the smart contract (Section 3), an example of an incentive scheme (Section 4), the functional specification that the smart contract needs to support (Section 4). Section V), Distributed Ledger Data Structure Specification (Section VI), followed by Conclusions and Future Work (Section VII).
0x03 Verify Contribution
Computing the next global model version during the FL process typically involves averaging the model weights received from all contributions, taking into account the number of samples each client has [9]. However, since the training in the FL process is performed at the edge, the data is not transmitted nor collected at the central location. Therefore, assessing the honesty of users' statements about the amount of data used in the training process is a challenge. An attacker may exploit this incompetence by falsely reporting that he uses large data samples in order to maximize his impact on the global model. It has been shown that a known good validation dataset (kept secret from the end user) as well as a validation algorithm can be used to evaluate the contribution of a single model independent of the number of data samples, providing some degree of protection against the types of attacks described above [7] .
Our proposed solution also uses a validation algorithm in the decision-making process, depending on the incentive scheme used. In its simplest form, we can offer rewards to users whose contributions pass the validation test.
0x04 Learning Process Overview (Workflow)
Each round of training consists of three main processes. In the first process, the participating user requests and receives weights for the current model version. In this step, a smart contract is invoked, which in turn queries the ledger for relevant data. It should be noted that the ledger is not changed at this stage.
After downloading the latest model version, end users can use it or train locally. The resulting gradients (in the form of model weights) are then sent back to the blockchain network. In this step, a function of the smart contract is called, which is responsible for the following tasks: a) receive gradients as input from the end user, b) verify the quality of the update by executing the model update verification algorithm, c) according to the result of the verification algorithm, Discard or save user contributions on the ledger.
The final process in the FL workflow is to perform joint aggregation, for example by averaging all meaningful contributions stored in the ledger, and use the result to create the next model version. This process should be triggered to execute at predefined intervals based on a specific use case, such as when a certain contribution goal is reached or when a certain time elapses. If the training epoch is very short, there may not be enough contributions to generate a model with significant improvement. On the other hand, if the training epochs are long, users will delay downloading the better-performing model version, resulting in degraded learning performance. The last process ends the training round.
0x05 Possibilities of Rewards
After each round of training, the performance of each user (in terms of useful contributions) can be recorded in the ledger. During training, user contributions are evaluated against a validation algorithm. The output of this validation function can be used as a measure of user performance. In its simplest form, the distributed ledger will store deltas representing the number of successful contributions (i.e. model updates that the validation algorithm deems useful). These scores can be viewed in the same way as cryptocurrency tokens, as they are stored on a secure medium and can be exchanged for rewards. In a commercial setting, tokens can be exchanged for money to compensate users for their efforts in performing local training and providing useful model updates for the FL process. In other use cases, tokens can be exchanged for other services, such as accessing downloads and using complementary machine learning (ML) models. Alternatively, the lack of tokens could be seen as an indication of misbehaving or inefficient users, and thus could be used to bar them from further participation in the federated learning process.
0x06 Smart Contract Function
This section discusses the minimum functionality that should be implemented in a smart contract to support the workflow discussed in the previous section.
The first function is responsible for letting participating users get the latest model version during the first training round. The function is defined as GetLatestModelParameters(), which queries the ledger and returns the multi-dimensional weight table corresponding to the latest model version. This function is called once by each participating user. However, since only simple queries are performed against the ledger, we expect the computational requirements to be low.
Figure 1 below shows the interaction between the user, the smart contract, and the distributed ledger during the early stages of the training round (download of model weights).
Figure 1. Interaction between users, smart contracts and distributed ledgers - requests for the current model version (model weights)
A second smart contract function SubmitModelWeights(weights) is required to facilitate the functionality of the second step of the training round (ie when the training round is active). When executed, it will receive model updates from the user as input (in the form of weights), then run the validation algorithm, and finally store the contribution into the ledger. We define "weights" in the above function as a multidimensional table of model weights, corresponding to individual contributions. This function is also called by the user and can optionally return a contribution evaluation result from the validation algorithm. Two methods of storing contributions to the ledger are considered. The first approach involves only storing successful contributions, i.e. those that improve the accuracy of the model. Another option is to store all contributions along with metrics (derived by the validation algorithm). Depending on the specific use case, we can choose the first approach, as it provides performance benefits (as the ledger is written less frequently), or the second approach provides greater auditability. In both cases, it is expected that a moderate amount of computational resources will be required, as the function is called by each participating user, calls an external CPU-intensive ML verification library, and is expected to affect the state of the ledger.
Figure 2 below shows the interaction between the user, the smart contract, and the distributed ledger during a user-submitted model update.
Figure 2. Interaction between users, smart contracts, and distributed ledgers - submission of model weights (user contributions)
The last function CalculateNextModelVersion() is required to create the next model version and by doing so end the current training epoch. Unlike the first two functions, it is not called by the end user. For this reason, an external trigger should be created, as described in the previous section. The next model version is created by performing a joint average of the contributions held in the ledger. The resulting multidimensional matrix is stored in the ledger for use in the next round of training. Although this function writes to the ledger, it is only called once per training round. Aside from the fact that it uses simple mathematical matrix calculations, it is not expected to require a lot of computational resources.
Figure 3 below illustrates the interaction between smart contracts and distributed ledgers during the creation of the next model version.
Figure 3. The interaction between the smart contract and the distributed ledger to create the next model version (end of training round)
The following table summarizes the characteristics of smart contract functions used to predict resource requirements. TR stands for training epoch.
Table I. Resource Requirements for Features
| function | Attributes | ||
| execution frequency |
whether to change the ledger |
Estimated required resources |
|
| GetLatestModelParam eaters |
once per user per |
no | Low |
| SubmitModelWeights | once per user per |
Yes | high |
| CalculateNextModelV ersion |
once per |
Yes | Low |
0x07 Distributed ledger operations and data structures
The proposed architecture diagram is based on the concept of a key-value pair database. This type is used by HyperLedger Fabric (HLF) as a state database. Smart contract operations are used to read or write the current state of the database. Each ledger transaction will create, update, or delete (and thus modify) key-value pairs in the ledger. However, since HLF belongs to the blockchain family, an immutable sequence of blocks contains all transactions that affect the current state of the database. A copy of the ledger is propagated to all network members.
The following table summarizes the operation of the federated learning process and the minimum key-value pairs required to record rewards. The key "identity" below is the index group value. For example, we will provide each participating user with a key-value pair of ModelUpdate and Reward variables.
| Key | Value |
| ModelWeights | A multidimensional matrix containing the weights for the current model version |
| ModelUpdate(identity) | A multidimensional matrix containing the weights (one for each [identity]) |
| Reward(identity) | Value is proportional to the quantity/quality of user contributions (one per [identity]) |
0x08 Conclusion and future work
The solution proposed in this paper describes how a private blockchain network can be used in a unique way to support FL processes. It improves trust and security by running verification algorithms in smart contracts executed between multiple nodes. The network can be configured to require consensus among a certain percentage of nodes.
In the future, we intend to implement this solution using the following tools and techniques: a) HyperLedger Fabric, b) an algorithm for validating updates and providing rewards [7] and c) Tensorflow (an open source machine learning tool). Areas of interest include i) feasibility of running machine learning libraries in smart contracts, ii) impact on consensus when the results of verification algorithms are not identical between nodes (e.g. rounding errors), iii) imposed performance The overhead goes through the blockchain network, iv) the performance impact of different design choices (e.g. recording all contributions to the ledger vs only recording useful contributions, v) specification of the hardware (compute, memory) requirements of the solution.