search

iammcy / BFLC-demo

This project proposes a decentralized federated learning framework based on blockchain, that is, a Block-chain-based Federated Learning framework with Committee consensus (BFLC). Without a centralized server, the framework uses blockchain for the global model storage and the local model update exchange.
MIT License
103 stars 24 forks source link

节点问题 #12

Closed YhanJude closed 2 years ago

YhanJude commented 2 years ago

请问训练节点上传的梯度参数，是传给共识中的领导节点了，还是传给共识中除了领导节点的剩余节点呀

iammcy commented 2 years ago

训练节点可以将梯度参数上传给共识节点中的其中一个，代码是统一设置成上传到同一个共识节点，领导节点只是负责打包出块。

YhanJude commented 2 years ago

只给一个共识节点验证，安全性怎么办呀

iammcy commented 2 years ago

也不是只给一个共识节点验证的意思，关于安全性： 对于新区块的安全，使用的是fisco中pbft共识算法（不是raft算法），虽然只发送信息给一个共识节点，但是在共识过程会由所有共识节点验证 对于上传梯度参数的安全，是由本文的委员会方法，即所有共识节点链下验证。

YhanJude commented 2 years ago

是其中一个共识节点拿到了梯度参数，然后广播给其他共识节点吗

iammcy commented 2 years ago

是其中一个共识节点拿到了梯度参数，然后广播给其他共识节点吗

是的，在共识过程有广播这一个步骤

YhanJude commented 2 years ago

如果其中一个共识节点是一个恶意节点，不广播信息或者篡改了参数怎么办呀

iammcy commented 2 years ago

如果其中一个共识节点是一个恶意节点，不广播信息或者篡改了参数怎么办呀

这个是涉及到区块链交易同步的原理，之前说错了，应该是在共识之前已经有交易同步，把交易广播给其他共识节点的操作了，至于不广播交易或者篡改了交易，应该在区块链的交易不可篡改原理有解释，这涉及到加密算法和数据存储结构。

YhanJude commented 2 years ago

请问训练节点是区块链上的节点，还是本地客户端呀

iammcy commented 2 years ago

是本地客户端

YhanJude commented 2 years ago

这种跟训练节点发送梯度参数到区块链，领导节点打包梯度参数，然后发送给共识委员会中的成员验证，验证后再发送给领导节点，有什么区别呀

iammcy commented 2 years ago

不好意思，不是很明白您想比较的是什么，代码实现的也差不多是这样

YhanJude commented 2 years ago

就是请问这个委员会共识和PBFT共识有什么区别呀

iammcy commented 2 years ago

首先“委员会”在区块链中：委员会共识是一种共识的策略，而PBFT共识是一种共识的算法，委员会共识在区块链中很早已经有了，主要用于解决BFT中共识效率和可扩展性的问题，也就是说委员会内部采用的共识算法PBFT可以替换成其他BFT算法都没有关系，只是本文代码委员会内部的共识采用的是PBFT。 而委员会在联邦设置中本文提出是相当于k-折交叉验证的思想，主要解决模型拜占庭攻击问题（而BFT等算法是无法解决联邦场景下的模型攻击问题的） 另外，联邦的委员会机制的另一个作用是下一轮委员会的选举，可以契合区块链中的委员会共识机制的委员会选举，当然，本文代码主要是半模拟实现，重点利用合约实现联邦委员会的功能，针对区块链委员会共识策略模拟的解释见这里的回复

YhanJude commented 2 years ago

请问可以改变fisco的pbft共识算法吗

iammcy commented 2 years ago

目前fisco支持调用的共识算法应该只有raft、pbft、rpbft，其中rpbft与区块链委员会共识机制相似。根据场景需求是可以改用其他共识算法的，至于自己实现其他共识算法，这个我不是很清楚。

ddc123456 commented 2 years ago

您好！请问在 #9 中，您说的在发布者角色中定义模型，然后在合约中定义一个接收模型参数接口，是直接在main.py的run_sponsor中上传模型参数，还是在run_one_node中上传模型参数？

ddc123456 commented 2 years ago

您好！这个节点产生的区块是保存在预编译合约定义的数据库的表中么？通过区块链浏览器能看到区块高度等，但是看不到保存的模型参数以及训练轮数。请问如何查看区块以及区块中的内容？

iammcy commented 2 years ago

您好！请问在 #9 中，您说的在发布者角色中定义模型，然后在合约中定义一个接收模型参数接口，是直接在main.py的run_sponsor中上传模型参数，还是在run_one_node中上传模型参数？

是在run_sponsor中上传定义的初始模型

iammcy commented 2 years ago

您好！这个节点产生的区块是保存在预编译合约定义的数据库的表中么？通过区块链浏览器能看到区块高度等，但是看不到保存的模型参数以及训练轮数。请问如何查看区块以及区块中的内容？

区块中的不一定所有交易或数据都存储在这个合约定义的表中，还可能在另外的表中。webase应该是有提供查看数据的服务的，具体你可以查看webase的文档，应该在数据导出和可视化查询部分

ddc123456 commented 2 years ago

您好！在main函数中，不是run_one_node先执行么，run_sponsor是最后append在process_pool中，在run_sponsor中上传定义的初始模型，前面的进程不久出错了么？

iammcy commented 2 years ago

您好！在main函数中，不是run_one_node先执行么，run_sponsor是最后append在process_pool中，在run_sponsor中上传定义的初始模型，前面的进程不久出错了么？

你可以调整一下执行的顺序，在不违背FL下都是可以的（trainer节点可以先检查一下是否能获取到模型，再执行后面的训练任务）