Filecoin矿工和创始人胡安的问答环节如火如荼，虽然大家还想和胡安多聊一会，可说时迟那时快，问答时间已经结束，但此次大家的收获颇多，解决了心中很多的疑虑，也让中小矿工们对Filecoin主网的上线更有信心了。
没有及时参与问答环节的朋友可以看看以下我整理的资料，前二一个问题请查阅《Filecoin矿工与创始人胡安的“灵魂拷问”（一）》，IPFS/Filecoin社区，联系VX: liandaoxixi
22.矿工提问：有四个filecoin实现正在进行中，所有这些都必须符合规范。我们已经定义了mainnet启动的里程碑。问题是规格定稿日期是什么时候?我们将期待在日期和主要网推出之间，规范将保持不变。
官方：协议规范已经稳定下来——尽管文档本身需要更多的改进才能非常清晰和可读。我们将在未来几周内改进它，并在此基础上建立Filecoin改进建议(FIPS)流程。
23.矿工提问：团队20年有没有来中国的计划？
官方：我们很期待疫情过去之后来中国和大家见面！
24.矿工提问：矿机硬件是否会支持AMD的GPU在mainnet发布前，如rx580, rx480等?
官方：我们现在关注的是NVIDIA, AMD可能不会发生在mainnet之前。
25.矿工提问：目前有多少开发人员正在为启动mainnet而工作?
官方：Filecoin项目本身约有25名工程师全职从事该项目，但这只是在生态系统中工作的一小部分人。数以百计的工程师和研究人员为所有四个实现，Filecoin证明以及基于Filecoin的数十个项目贡献了代码，进行研究并提出请求。
26.矿工提问：对于未来256GB的内存来说，这是一个有挑战的条件吗?
官方：这是一个好问题。
我们的实现做了一些特别的权衡，例如，它更喜欢使用更多的RAM而不是做更多的计算，以获得一个“快速”的密封，但是这并不一定适用于所有的矿工。我们希望贡献者能够优化这段代码，使其最适合自己。
这里有很多权衡的空间，只是给你一些例子:
-目前大部分RAM都被DRG图填满，然而，这些图的这些边可以在本地计算。这意味着您可以释放大量内存，代价是您的一些CPU重新生成DRG图的边缘。
内存是非常快的计算，如果你愿意有一个较慢的密封，你可以使用其他存储设备，可以帮助增加您的CPU的吞吐量。
我不能保证上面的优化可以为您的挖掘设置带来有用的优化，我们还将尝试在主要实现中探索不同的权衡。
27.矿工提问：挖矿会消耗很多电吗，需要什么样的资源？
官方：电脑很耗电！但是，通常情况下，Filecoin挖矿的大部分电力都用于提供存储。它与纯工作证明加密货币的不同之处在于，它将大量的精力用于提供有用的真实世界服务和保护区块链。
28.矿工提问：在mainnet之前会有更多类似的问答环节吗?我觉得这些很棒，最好每个月有一次这样的问答环节。
官方：我们正在努力推进mainnet，但我们将尽我们最大的努力，在未来有更多的问答环节!
29.矿工提问：Filecoin网络上线后，每个节点是否需要一个独立的公共IP ?
官方：不需要
30.矿工提问：国际上的疫情很严重，疫情对美国的影响，是否还有对主网上线的影响，第一阶段能顺利完成吗，有什么新的变化吗?
官方：疫情非常严重。我们已经制定了应对疫情的计划，预计不会有任何影响。然而，如果情况急剧恶化，我们的开发队或矿工社区可能受到严重影响。我们将时刻关注事情如何发展，我们希望每个人都是安全的，不要生病!
在发布之后，我们将不能做太多——网络将与任何有能力参与的人一起继续运行，希望这种流行病能很快减缓下来，保持安全!
31.矿工提问：现在普通人参与的门槛真的很高，你将采取什么措施来降低这一障碍?你将如何平衡主要网络的安全性和受欢迎程度?
官方：三个答案
*存储挖掘*:我们需要各种尺寸的存储挖掘工具。我们预计小型存储挖掘将成为可能——在100兆TB的范围内。我们期望它会变得更容易，因为复制的校对变得更便宜，也就是说，大多数数据档案都希望放在安全、维护良好的存储架上。
*检索挖掘*:位于良好位置的小型矿商将能够进行检索挖掘——存储数据并为其提供服务。现在这个还不太完善，因为我们想让所有的东西都尽快出来，但是你很快就会看到其中的一些更充实的工作方式。你已经可以支付检索与支付渠道，现在任何人都可以存储的东西和服务他们。我们期待非常小的矿商能够以这种方式参与。
*其他角色:*我们期望其他挖掘角色随着时间的推移而发展——网络中的许多计算或活动都可以随着时间的推移而发展。例如，诸如修复、缓存或聚合之类的东西可以成为小型采矿者的挖掘角色。
32.矿工提问：有什么研究可以避免SNARK吗?我认为它对硬件要求来说太重了。
官方：这个问题虽然简短，但却是一个非常深刻和重要的研究问题。我花了一些时间来回复，我会把它分成两个问题:
问题1:我们能从目前的校样中去掉这些问题吗?
我们使用SNARKs来“压缩”Merkle树的证明，并检查一些SHA的正确性。如果我们不使用snark，我们的证明将会是几百kb而不是几百字节。
这是因为我们的向量承诺是一个Merkle树和它们的包含证明，尽管对数仍然是非常大的(在我们的证明中，一棵树的深度是30，这意味着一个Merkle树的包含证明大约是~1kb——我们需要数百个这样的证明!
用更好的矢量承诺来代替Merkle树可以帮助我们避免使用snark。我们有活跃的研究人员，最近发布了一个更新的ePrint (https://eprint.iacr.org/2020/149)更好的RSA矢量承诺。不幸的是，它们离实际还很远。
当前的复制证明是基于pe游戏的，我们必须使用向量承诺来承诺它。
构建复制的证据和更广泛的有用空间的证据，而不是基于pe，仍然是一个开放的(令人兴奋的)研究问题，我们也在研究。
问题2:我们是否可以减少对硬件的依赖?
是的，虽然这可能是幕后工作：
我们对我们的SNARK电路做了巨大的改进，使其比之前的任何结构都要小得多。
我们实现了GPU支持，比cpu运行速度快得多。
作为工程师和研究人员，我们非常致力于改进SNARK(去年有两篇由协议实验室撰写的关于SNARK改进的论文)，密码社区正在对SNARK进行重大改进。在接下来的几个月里，很可能会有更便宜的SNARK。
微信扫一扫 
