原文作者：A. R. Short, H. C. Leligou and E. Theocharis*
原文标题：Execution of a Federated Learning process within a smart contract*
原文链接：https://ieeexplore.ieee.org/document/9427734*原文来源：IEEE International Conference on Consumer Electronics (ICCE), 2021
笔记作者：quangaoyuan
笔记小编：quangaoyuan
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.
区块链、联合学习、智能合约、验证算法
高质量的数据集对于创建机器学习（ML）模型一直很有价值。因此，向使用此类数据集参与联合学习（FL）过程的用户提供奖励是有意义的。在这一竞争场景中，我们设计了一个利用区块链网络、智能合约和模型验证算法的解决方案，以协调培训过程、记录用户表现并以透明的方式提供奖励。
联邦学习（FL）是一种很有前途的机器学习（ML）技术，允许以分散的方式对模型进行训练。由于参与用户只共享渐变（以模型更新的形式），而不是实际数据，因此该过程在隐私方面提供了改进。近年来，研究人员提出了将FL过程与区块链技术结合起来的方法，以便在不同方面提供改进。更具体地说，相关研究表明，此类解决方案可以提供改进的可审计性[1][2]，可问责性[3]，能够以分散的方式存储模型更新[4]，提高安全性[5]，并可用于促进激励机制[6]。
本文提出并详细说明了这种解决方案的体系结构设计，其中FL流程由运行在私有区块链网络上的智能合约进行协调。智能合约负责验证贡献，计算全球模型，并记录用户的绩效，以支持激励计划。据我们所知，尚未提出或研究类似的方法（即在智能合约中运行验证算法，以验证模型更新，进而提供奖励/激励）。值得一提的是，本文中使用的一些术语是特定于HyperLedger Fabric（HLF）的；然而，类似的原则可能适用于其他私有区块链网络。本文描述的解决方案旨在在以下方面提供改进：
A.安全
在智能合约中运行模型更新验证算法可以防止模型中毒攻击[7]。在这种攻击场景中，对手可能会发送恶意模型更新，以影响全局模型的性能、改变其行为或阻止其他用户访问它[8]。在使用某种激励方案的解决方案中，需要这种验证过程。否则，恶意用户可能会通过发送空的或毫无价值的贡献而从这种方案中获益，同时降低全局模型的性能。
B.激励计划
为了实现信任，可以使用智能合约记录每个参与用户的表现。区块链网络的分布式账本是以透明方式存储奖励的完美媒介，因为它是分散的。例如，可以配置HLF，以便至少需要一定比例的节点才能达成共识。此外，通过在智能合约中执行验证算法，可以实现更高级别的透明度，这在我们的设置中尤为重要，因为该算法的输出用于计算激励。
我们设想，在需要更高级别信任的情况下，该解决方案将是有价值的，因为它可以使竞争实体协同改进和使用共享机器学习，同时突出活跃用户。区块链节点的位置取决于用例。例如，当少数竞争行业或协会在FL过程中进行合作时，他们可能会选择每个托管一个节点（即，该节点更接近最终用户）。另一种选择是，需要一个受信任的第三方来托管解决方案。
以下各节描述了用于验证和奖励计算的算法（第二节）、由智能合同协调的培训流程（第三节）、激励方案示例（第四节）、智能合同需要支持的功能规范（第五节），分布式分类账数据结构规范（第六节），随后是结论和未来工作（第七节）。
在 FL 过程中计算下一个全局模型版本通常涉及对从所有贡献中收到的模型权重进行平均，同时还要考虑每个客户拥有的样本数量 [9]。然而，由于 FL 过程中的训练是在边缘执行的，因此数据不会传输，也不会在中心位置收集。因此，评估用户关于训练过程中使用的数据量的陈述的诚实度是一项挑战。攻击者可能会利用这种无能，虚假报告他使用大数据样本，以最大化他对全局模型的影响。已经证明，已知良好的验证数据集（对最终用户保密）以及验证算法可用于评估单个模型的贡献，而不依赖于数据样本大小数，从而提供一定程度的保护以免受上述攻击类型[7]。
我们提出的解决方案还在决策过程中使用验证算法，具体取决于所使用的激励方案。以最简单的形式，我们可以向贡献能够通过验证测试的用户提供奖励。
每轮培训包括三个主要过程。在第一个过程中，参与用户请求并接收当前模型版本的权重。在此步骤中，将调用智能合约，进而查询分类帐以获取相关数据。应该注意的是，在这个阶段账本没有被改变。
下载最新的模型版本后，最终用户可以使用它，也可以进行本地培训。然后将生成的梯度（以模型权重的形式）发送回区块链网络。在此步骤中，调用智能合约的一个函数，该函数负责以下任务：a）从最终用户接收梯度作为输入，b）通过执行模型更新验证算法来验证更新的质量, c) 根据验证算法的结果，丢弃或保存账本上的用户贡献。
FL 工作流中的最后一个过程是执行联合聚合，例如通过平均存储在分类帐中的所有有意义的贡献，并使用结果来创建下一个模型版本。这个过程应该被触发以根据特定的用例以预定义的时间间隔执行，例如当达到某个贡献目标或经过某个时间时。如果训练轮次非常短，则可能没有足够的贡献来生成具有显着改进的模型。另一方面，如果训练轮次很长，用户将延迟下载性能更好的模型版本，从而导致学习性能下降。最后一个过程结束了训练轮。
在每一轮训练完成后，可以在账本中记录每个用户的表现（在有用的贡献方面）。在训练过程中，根据验证算法评估用户贡献。这个验证函数的输出可以作为衡量用户表现的指标。在最简单的形式中，分布式账本将存储增量，表示成功贡献的数量（即验证算法认为有用的模型更新）。这些分数可以被视为与加密货币令牌相同的方式，因为它们存储在安全介质上，并且可以交换奖励。在商业环境中，代币可以用金钱交换，以补偿用户在执行本地训练和为 FL 过程提供有用的模型更新方面所做的努力。在其他用例中，代币可以交换为其他服务，例如访问下载和使用补充机器学习 (ML) 模型。或者，令牌的缺乏可能被视为行为不端或效率低下的用户的指示，因此可能被用来禁止他们进一步参与联邦学习过程。
本节讨论应在智能合约中至少实现的功能，以支持上一节中讨论的工作流。
第一个功能负责让参与用户在第一轮训练阶段获得最新的模型版本。该函数定义为 GetLatestModelParameters()，查询账本并返回与最新模型版本对应的多维权重表。该函数由每个参与用户调用一次。然而，由于只对分类帐执行简单的查询，我们预计计算要求会很低。
下面的图 1 显示了在训练轮的早期阶段（模型权重的下载）用户、智能合约和分布式账本之间的交互。
图 1. 用户、智能合约和分布式账本之间的交互——当前模型版本的请求（模型权重）
需要第二个智能合约函数 SubmitModelWeights(weights) 来促进训练轮第二步的功能（即当训练轮处于活动状态时）。执行时，它将接收来自用户的模型更新作为输入（以权重的形式），然后运行验证算法，最后将贡献存储到分类帐中。我们将上述函数中的“权重”定义为模型权重的多维表，对应于个人贡献。该函数也由用户调用，可选择返回验证算法得出的贡献评估结果。考虑了两种将贡献存储到分类帐的方法。第一种方法只涉及存储成功的贡献，即那些提高模型准确性的贡献。另一种选择是将所有贡献与度量（由验证算法导出）一起存储。根据具体的用例，我们可以选择第一种方法，因为它提供性能优势（因为分类账的编写频率较低），或者第二种方法提供更高的可审计性。在这两种情况下，预计将需要适量的计算资源，因为该函数由每个参与用户调用，调用外部 CPU 密集型 ML 验证库，并且预计会影响分类帐的状态。
下面的图 2 显示了在用户提交模型更新期间用户、智能合约和分布式账本之间的交互。
图 2. 用户、智能合约和分布式账本之间的交互——模型权重的提交（用户贡献）
需要最后一个函数 CalculateNextModelVersion() 才能创建下一个模型版本，并通过这样做结束当前的训练轮次。与前两个函数不同，它不是由最终用户调用的。出于这个原因，应该创建一个外部触发器，如上一节所述。下一个模型版本是通过对账本中保存的贡献执行联合平均来创建的。生成的多维矩阵存储在分类帐中，以便在下一轮训练中使用。尽管此函数写入账本，但每轮训练只调用一次。除了它使用简单的数学矩阵计算这一事实外，预计不需要很多计算资源。
下面的图 3 说明了在创建下一个模型版本期间智能合约和分布式账本之间的交互。
图 3. 智能合约和分布式账本之间的交互以创建下一个模型版本（训练轮结束）
下表总结了用于预测资源需求的智能合约功能的特征。 TR 表示训练回合。
表 I. 功能的资源需求
| 函数 | 属性 | ||
| 执行频率 |
是否更改帐本 |
预计所需资源 |
|
| GetLatestModelParam eters |
once per user per |
否 | 低 |
| SubmitModelWeights | once per user per |
是 | 高 |
| CalculateNextModelV ersion |
once per |
是 | 低 |
所提出的架构图基于键值对数据库的概念。这种类型被 HyperLedger Fabric (HLF) 用作状态数据库。智能合约操作用于读取或写入数据库的当前状态。每个账本交易将在账本中创建、更新或删除（并因此修改）键值对。然而，由于 HLF 属于区块链家族，一个不可变的区块序列包含所有影响数据库当前状态的交易。账本的副本会传播给所有网络成员。
下表总结了联邦学习过程的操作以及记录奖励所需的最低限度的键值对。下面的键“身份”是指数组值。例如，我们将为每个参与用户提供一个 ModelUpdate 和 Reward 变量的键值对。
| Key | Value |
| ModelWeights | 包含当前模型版本权重的多维矩阵 |
| ModelUpdate(identity) | 包含权重的多维矩阵（每个 [identity] 一个） |
| Reward(identity) | 价值与用户贡献的数量/质量成正比（每个[identity]一个） |
本文提出的解决方案描述了如何以独特的方式使用私有区块链网络来支持 FL 流程。它通过在多个节点之间执行的智能合约中运行验证算法来提高信任和安全性。网络可以配置为要求一定比例的节点之间达成共识。
在未来，我们打算使用以下工具和技术来实施该解决方案：a）HyperLedger Fabric，b）验证更新和提供奖励的算法 [7] 和 c）Tensorflow（开源机器学习工具）。感兴趣的领域包括 i) 在智能合约中运行机器学习库的可行性，ii) 当验证算法的结果在节点之间不完全相同时（例如舍入误差）对共识的影响，iii) 施加的性能开销通过区块链网络，iv) 不同设计选择对性能的影响（例如，记录对分类帐的所有贡献与仅记录有用的贡献，v) 解决方案的硬件（计算、内存）要求规范。
