联邦学习-区块链论文笔记：Blockchained On-Device Federated Learning

• 链接：

IEEE Xplore Full-Text PDF:​ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8733825

• 作者：Hyesung Kim （延世大学团队） 一点感悟：区块链和联邦学习这块儿韩国大学这边起步很早，很经典的文章都能看到他们的身影。
• Motivation：随着联邦学习的流行，谷歌团队也提出了vanilla FL模型。但是该模型存在3个缺陷：

1）依赖唯一的中心服务器。该服务器一旦被攻击，将影响下属所有client客户端的模型训练进度；
2）没有奖励机制。如果没有及时的激励，一些拥有大批数据的机构或组织将没有足够的动力去分享数据去参与模型训练；
3）原始模型的训练完成延时较长。中心server服务器需要等所有的client客户端完成本地训练，才能进行global model aggregation.一旦本地client客户端出现问题，那么将影响整个进程。 

• Idea：或者说整个FL-blockchained模型一次迭代的步骤为：

1）本地模型更新：任意一个本地节点Di完成Ni次本地迭代，更新模型参数wi; 
2）本地模型上传：本地节点Di向附近关联的矿工Mi上传三个指标：本地模型参数wi，损失函数差值，以及模型计算时间； 
3）交叉验证：矿工将上传的本地节点信息广播至其他矿工，剩余矿工用自带的标准数据集来验证，达标者方可入block； 
4）块生成：每个矿工通过pow共识机制来挖坑； 
5）块广播：一旦有新的block生成，立马向其他矿工发送ACK标识，终止其他矿工继续挖矿； 
6）全局模型下载：本地节点Di从相关联的矿工Mi下载全局模型； 
7）全局模型更新：golbal model通过fedavg策略来更新，包括损失函数也是均方根误差函数。 

Evaluation：主要从算力、通信、块生成速率三个方面来比较模型延迟的快慢

1）通常来讲，块生成速率越快，模型延迟越长； 
2）在client不会发生故障的前提下，本地上传参数所引入的noise越大，延时越长； 
3）在client会发生故障的前提下，本地上传参数所引入的noise越大，延时越小； 
4）在miner不会发生故障的前提下，挑选阈值越小，延时越长，由于交叉验证和块传播的时间变成了； 
5）总的来说，矿工数量的增加，还是能够减少模型延迟的 

Thoughts：这篇文章算是开山之作吧，作者提出了两点值得思考：

1）共识机制可以是PoS或者BFT；

2）奖励制度可以更加完善，不仅仅是根据本地节点的数据量，还可以考虑数据质量

---

插播一点广告，如果也有做联邦学习+区块链，或者是隐私保护计算这块，热烈欢迎交流！！！