干货：分析目前Testnet/3分布式挖矿的实现

还有不到1个月即将开启 Filecoin 第二阶段测试网，目前处于互操作性测试阶段，那么 FilCloud 今天给大家分析下在 testnet/3 分布式挖矿的实现问题。

Testnet/3 分布式挖矿的实现：

miner 支持添加多个本地存储路径，也就支持多磁盘了；worker 还不支持这个，但是应该加上非常容易；

每个 worker 都会起 http 服务，同时支持rpc服务和扇区文件获取或删除服务；

worker 启动时会主动让 miner 连接自己，而且 miner 会记录所有连接的 worker 的元数据信息，这些信息同样可以被其他 worker 获取（元数据信息可以勾画整个 worker 集合的几乎所有状态）；

承上一条，worker 获得其他 worker 的信息，也就可以访问其他 worker 的 rpc 服务和扇区文件获取或删除服务，也就是全面的互联互通（这点可以衍生 worker 之间的副本冗余功能，但是肯定不是好方式）；

复制证明方面，worker 支持 precommit/1，precommit/2，commit/2 任务，worker 在开始这些任务的时候会去检查 sector 是否在本地，不在就去向 miner 或其他 worker 获取；

复制证明方面，miner 支持 addpiece，commit/1，finalize 任务；

时空证明还是只由 miner 来负责，做的时候会去确认 sector 是否在本地，不在的话就去向 worker 获取下载（AcquireSector 接口）；

miner 分发复制证明任务时，会通过调度得到最适合的 worker，这里有个调度器，有根据 cpu/内存/磁盘过滤，也有根据本地是否有要做的 sector 来过滤，等等；

再列一下可能存在的问题（很多都是老的版本就存在的问题，依然没有识别并解决）：

因为 worker 和 miner 之间依然是 jsonrpc，然而 jsonrpc 的实现非常粗糙，虽然 2 月份加了重连机制，然而依然很难可靠地保障 worker 和 miner 的连接稳定性；

miner 对于 worker 的调度，依然非常简陋；调度器的实现是否好，直接影响大批量复制证明的整体效率；

miner 和 worker 之间共享 sector 的网络下载效率瓶颈，依然没有解决；

设计上的问题：

实现人员太过于沉迷于封装，试图把不同场景的接口实现在一起，间接导致实现变得复杂，而并没有增加多少新功能，也没解决多少老问题；

local 和 remote 等字眼出现非常频繁，不同语境下其实含义不一样，很容易混淆；

值得夸赞的点：

官方开发者还是花了很大精力在分布式挖矿上面，试图给到大家一个比较灵活强大的开箱即用的方案

相信后续会进一步完善到比较好的状态

非常感谢您对 IPFS&Filecoin 项目的持续支持。我们很高兴继续与您一起，为人类信息建立一个强大的，去中心化和高效的基础。

FilCloud 帮你迅速了解 IPFS 领域的热点技术和应用

公众号：filcloud

—-

编译者/作者：FilCloud

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。