此文译自FIL的设计文档https://github.com/fileDAC-project/specs
设计文档，从设计的角度，分别介绍数据结构，挖矿机制，共识机制，支付方式，虚拟机执行，状态机，存储角色等等。
FileMaximine是一个分布式存储网络，共享状态持久存在于区块链中。
FIL的开采过程是什么？
FIL共识过程中的一个积极参与者是一个存储挖掘者和预期的共识块提议者。他们负责为FIL网络存储数据，并推动FIL共识过程。矿工们应该不断地进行时空证明，并检查他们是否有一张中奖票，为每一轮提议一个块。为了考虑到网络在世界各地的传播，目前的轮次设置为大约30秒。这两个过程的详细信息都在本文中有所阐述。
任何区块提议者都必须是存储矿工，但存储矿工可以避免执行区块提议者任务，但这样，他们将失去区块奖励和交易费用。
矿工参与者
成功调用CreateMiner后，将在链上创建一个矿工参与者，并在存储市场中注册。与所有其他FileMXM状态机参与者一样，这个矿工有一组固定的方法，可以用来与之交互或控制它。
有关mineractor方法的详细信息，请参见参与者规范中的条目。
所有者-工人区别
矿工参与者有两个不同的“控制器”地址。一个是工人，地址是负责完成所有工作、提交证明、提交新扇区以及所有其他日常活动的地址。所有者地址是创建矿工、支付抵押品并向其支付大额奖励的地址。区别是允许不同的当事人履行不同的角色。一个例子是，所有者可以是多功能钱包，也可以是冷藏钥匙，而工作人员的钥匙可以是“热钱包”钥匙。
存储挖矿循环
存储矿工必须在他们的存储上不断地提供时空证明，以使网络相信他们实际上正在存储他们所承诺的扇区。每个PoSt覆盖一个矿工的整个仓库。
步骤0:注册
为了最初成为矿工，矿工首先在链上注册新的矿工参与者。这是通过存储市场参与者的CreateMiner方法完成的。然后，调用将创建一个新的矿工参与者实例并返回其地址。
下一步是将一个或多个存储市场需求放到市场上。这是通过存储市场添加任务方法完成的。每个矿工可以创建一个对其整个存储的单一请求，或者通过多个请求（可能以不同的价格）以某种方式对其存储进行分区。
之后，他们需要与客户进行交易，并开始用数据填充扇区。有关进行交易的更多信息，请参阅有关交易流程的部分。
当他们有一个完整的扇区时，应该密封它。这是通过调用扇区上的porep.seal来完成的。
步骤1：提交
当矿工完成他们的第一个封条后，他们应该使用Commitsector将其发布在链上。如果矿工在此之前没有承诺的扇区，这将开始他们的证明期。
证明期是固定的时间，矿工必须向网络提交一份时空证明。
在此期间，采矿者也可以承诺新的扇区，但在下一个证明期开始之前，这些扇区将不包括在时空证明中。
未完待续：扇区需要是全球独一无二地。这可以通过让密封证明证明该扇区在某种程度上对该矿工来说是独一无二的，或者在提交的每份报告中对照一份全球地图进行检查来实现。随着系统向扇区聚合的方向发展，后一种选择将变得不可行，因此需要更多的思考证明语句如何工作。
步骤2：证明存储（创建后）
在试验期开始时，矿工们收集试验装置（此时链条上所有活体密封部分的装置），然后调用provestorage。这一过程需要整个验证期才能完成。
注：详见“时空证明”部分。
在证明期间，证明集保持一致。在此期间添加的任何扇区将在下一个验证期开始时包括在下一个验证集中。
步骤3：提交后
矿工完成工作后，必须通过调用 SubmitPoSt将其提交给网络。有两种不同的时间可以做到这一点。
标准提交：标准提交是指在验证期结束前将其链接起来的提交。设置计算职位所需的时间长度，以便在该时间段和验证期的实际结束之间有一个宽限期，从而最小化网络拥塞对典型矿工操作的影响。
惩罚性提交：惩罚性提交是指在证明期结束后，但在生成攻击阈值之前，使其处于链上的提交。这些提交文件被视为有效的后提交，但矿工必须因为迟提交而支付罚款。（有关详细信息，请参阅“故障”部分）。
注：在这种情况下，下一个日志仍应在验证期开始时开始，即使当前日志尚未完成。矿工必须在每个试验期提交一个岗位。
除了提交后的文件外，矿工们还可以从他们的试验组中希望删除的一组扇区划分出来，通过在传递给 SubmitPoSt的“完成”位字段中选择扇区来完成。
停止开采
为了停止采矿，矿工必须完成其所有的储存合同，并在提交后将其从证明集中移除。然后矿工可以调用DePledge来检索抵押品。必须调用 DePledge 两次，一次启动冷却，另一次在冷却后回收资金。冷却期是允许那些文件被矿工丢弃的客户在拿回钱之前将它们砍掉，然后再把钱拿走。
故障
关于被削减（WIP，需要讨论）
如果矿工因为没有按时提交PoSt而削减，那么将失去所有的抵押物，存储抵押品不一定会丢失。当一个矿工客户因为不再拥有数据而大幅削减它们时，存储辅助资料就会丢失。丢失PoSt并不意味着矿工不再拥有数据，此处该有一个额外的超时，矿工可以提交一个帖子，连同“补充”他们的抵押品。如果矿工提交帖子补充抵押品，就可恢复采矿权，继续采矿，客户也可以确保他们的数据仍然存在。
未完待续:在整个规范中消除两个络脉的歧义
回顾讨论注意事项：为超过提交后的最后期限而获取所有矿工的抵押品是很让人痛苦的一件事，而且一开始很可能会劝阻人们开采FIL（如果互联网退出可能会损失大量金钱，这会导致一些关于盈利能力的艰难决定。）。一个潜在的策略可能是只惩罚矿工在该时间段内可能产生的部门数量。
采矿块
注册成为矿工后，就可以开始制作和检查票了。此时，矿工应该已经在运行链验证，其中包括跟踪网络上看到的最新提示集。
有关共识如何在FileMaximine中工作的更多详细信息，请参见预期共识规范部分。在本节中，有一个共识协议（预期共识），该协议保证了过程公平，以确定在一轮中生成了哪些块、矿工是否应自己挖掘块以及与之相关的一些规则，如何在块验证期间验证“票据”。
接收模块
当从网络接收数据块（通过数据块传播）时，矿工必须执行以下操作以检查其有效性（见下文）：
在Tipset中组装一个Tipset，该Tipset包含所有具有公共父级的有效块以及其Tickets数组中相同数量的Tickets。矿工有时可能会收到属于不同翻斗的块（即其父级不相同）。在这种情况下，他们必须要挖矿的小费。
链选择是FileMXM区块链工作方式的关键组成部分。每一条链都有一个相关的权重来计算其上挖掘的块的数量和追踪的算力（存储），是更重的Tipeset。虽然一个矿工可能是在过去获得的区块奖励之前，但这条较轻的链很可能会被其他矿工放弃，因为矿工们聚集在最后一条链上而丧失了已得到的区块奖励。有关更多信息，请参见预期共识规范中的链选择。
块验证
块结构和序列化在datastructures规范中有详细说明。请在那里查看字段和类型的详细信息。
1.为了验证从 N 轮网络进入的区块开采良好，矿工必须执行以下操作：
验证 BlockSig 在块内容上使用矿工的公钥(miner.PublicKey) 进行验证。
2.验证 ParentWeight
块的 ParentTipset 中的每个块都必须具有相同的 ParentWeight。必须使用链权重函数正确计算新块的 ParentWeight。
3.验证 StateRoot
为了做到这一点，矿工必须确保将块的消息应用到 ParentState （不包括在块头中）时，可以在receiptRoot中适当地生成 StateRoot和receiptRoot。
4.验证tickets数组中的 Tickets 是否有效，从而证明此块创建的延迟是适当的。
确保新票据是从块的父提示集中最小的票据生成的（在第n-1轮）。使用矿工的公钥重新计算新的工单，确保正确计算它。
5.如果块在 Tickets 数组中包含多个值
确保所有票据都用同一密钥签名。确保每个记录单都用于生成下一个记录单，第一个记录单是从父 Tickets 中最小的记录单生成的（在 N-1,，如上所述）。
6.确认矿工正确生成了选修证明，并且他们有资格采矿。
确保证明是使用n-k轮的最小票据（回望票据）生成的。使用矿工的公钥验证该证明，以检查 ElectionProof 是否是该回望通知单上的有效签名。验证证明确实小于n-l轮功率表中报告的矿工功率分数。
如果所有这些都对齐，则块是有效的。对于tipset中的所有块以及从传入块形成的所有tipset，矿工重复此操作。
一旦他们确保收到的最重的倾卸中的所有区块都被正确开采，他们就可以在上面开采。如果没有，矿工可能需要确保下一个最重的Tipset被正确开采。这可能意味着删除了无效块的相同tipset，或者完全不同的tipset。
如果没有收到有效的区块，则矿工可以使用票务链中的下一张票务再次在同一个Tipset上开采，并在流程中生成新的票务（更多信息请参见预期共识规范）。
票据生成
关于票务生成的详细信息，请参见预期共识规范部分。
票务生成是领导者选举的两个过程（即生成选举证明）。每一个票刮（即轮领队选举）都会让矿工生成一个新的票，包括在他们所在区块的票阵列中。
新的票据是使用父Tipset中高度h处的最小票据生成的，并添加到票据数组中。生成新的票据需要一定的时间（正如VDF在预期共识中规定的那样）。
因此，在生产过程中，预计矿工将收到网络上正在开采的其他区块。当矿工生成新的记录单时，可以检查自己是否有资格开采新的区块。
如果回望票产生有效的选择性，矿工将发布他们的区块（见区块生成），包括新的区块，并获得区块奖励。然后，他们使用他们在生成门票（可能是H+1高度）时听到的任何有效区块组装一个新的Tipset，并在新Tipset中最小的门票上挖掘。
抓取丢失的票据
如果矿工未能使用回望票生成有效的 ElectionProof ，则可能还没有在 H+1 高度发布新块。矿工很可能收到在 H+1 高度网络上开采的其他区块，可以用这些区块（如上所述）装配一个新的TipSet装置。
如果矿工没有收到新的块，就必须重新开出一张新的票来重新进行领导人选举（其他矿工也会这样）。为此，他们必须再次生成一个新的票据。
现在，矿工不再使用父提示集（如上所述）中最小的记录单生成新记录单，而是使用记录单数组中最近一轮的记录单生成新记录单。
矿工重复此过程，直到找到中奖通知单（并阻止发布）或网络中出现新的有效提示集。如果一个新的 TipSet 从网络中进入，并且比矿工自己的链重，矿工应该放弃其工作，在这个新的区块上开采。由于链选择在FileMaximine中的工作方式，具有更多块的链是首选（有关更多详细信息，请参见预期共识规范部分）。
要发布的块中的 Tickets 数组随着每一轮的增长而增长（并生成一个新的票据）。
创建块
抓取一张中奖票，并配备有效的选修证明，矿工就可以发布一个新的区块！
要创建块，符合条件的矿工必须计算几个字段：
Tickets -包含新票的数组，以及（如果适用）为证明任何失败的选举尝试的适当延迟而生成的任何中间票。请参见票据生成。ElectionProof-在门票数组证明的最后一张门票上签名。请参见票据生成。ParentWeight -如链权重中所述。ParentState—请注意：它不会最终出现在新生成的块中，但必须计算才能生成其他字段。要计算：
采用所选父集合中某个块的 ParentState （不变量：这是给定父集合中所有块的相同值）。对于父集合中的每个块，按其票据排序：
按顺序将块中的每个消息应用于父状态。如果消息已应用于上一个块，请跳过它。交易费用将支付给包含消息首次出现的块的矿工。如果父集合中有两个块，并且它们都包含完全相同的消息集，则第二个块将不收取任何费用。它适用于父级设置为冲突的两个不同块中的消息，也就是说，来自组合消息集的冲突消息将始终出错。无论冲突如何，所有消息都将应用于状态。未完待续:在状态机文档中定义消息冲突
MsgRoot -计算：
从内存池中选择一组要包含在块中的消息，然后，插进一棵Merkle树并扎根。StateRoot -将每个选定的消息应用于parentstate以获取此消息。ReceiptsRoot -计算：
将上面选择的消息集应用于父状态，并在发生这种情况时收集调用接收。
然后插进一棵Merkle树并扎根。BlockSig -在整个块上使用矿工的私钥（还必须与票据签名匹配）的签名。这是为了确保在块传播到网络后没有人篡改它，因为与普通的POW区块链不同，成功的罚单是独立于块的生成而被发现的。
合格的矿工可以从填写 Parents, Tickets和ElectionProof 开始，并使用检票流程中的值。
接下来，他们计算所选父块的聚合状态 ParentState。这是通过获取块的父提示集的聚合父状态、根据父块的票据对父块进行排序以及将每个块中的每个消息应用到该状态来完成的。应跳过其nonce已在早期块中使用的任何消息（重复消息）（此消息的应用程序无论如何都应失败）。请注意，重新应用的消息可能会导致与原始块中生成的消息不同的接收，一个悬而未决的问题是如何表示此tipset“virtualblock”的接收trie。有关消息执行和状态转换的详细信息，请参阅FileMXM状态机文档。
一旦拥有聚合 ParentState，矿工就要用挖掘奖励。这是通过将正确的金额添加到状态树中矿工所有者的帐户余额来完成的。有关详细信息，请参见区块奖励部分。
现在，选择一组消息放入块中。对于每条消息，矿工都从发送者的帐户余额中减去 msg.GasPrice*msg.GasLimit，如果发送者没有足够的资金，则返回致命的处理错误（此消息不应包含在链中）。
然后，矿工的应用消息状态转换，并为其生成一个收据，其中包含执行实际使用的总气体、执行退出代码和返回值（有关详细信息，请参见收据部分）。然后，他们向发送者退款 (msg.GasLimit-GasUsed)*msg.GasPrice。如果发生消息处理错误，剩余的气体将退还给用户，并且所有其他状态更改都将恢复。（注：这与ETH的工作方式不同）
除非该消息执行失败，每个消息都应该应用于上一个消息执行的结果状态，在执行失败种情况下，由该消息引起的所有状态更改都将被抛出。此进程之后的最终状态树将是块的 StateRoot 。
矿工将选定的一组消息合并，并将根放到 MsgRoot中。他们将每次执行的收据收集成一组，然后将其旋转，并将根放到 ReceiptsRoot中。最后，他们用结果状态设置 StateRoot 字段。
注意：预期共识文档中的 ParentState 字段被省略，这有助于将块头的大小最小化。任何给定父集的父状态都应该由客户端计算并在本地缓存。
现在这个块已经完成了，剩下的就是签名了。矿工现在序列化块（不带签名字段），获取其中的sha256哈希，并对该哈希进行签名。他们将结果签名放在 BlockSig 字段中。
区块广播
合格的矿工将完成的区块广播到网络（通过区块传播），假设一切都正确完成，网络将接受该区块，其他矿工将在其上进行采矿，为矿工赢得区块奖励！
区块奖励
在协议的整个生命周期内，将向矿工发放14亿Filecoin (TotalIssuance) 。该基金的发放速度定为每六年减半，平稳（不像BTC那样是固定的跳跃）。这些资金最初由网络账户参与者持有，并转移到他们开采的区块中的矿工。奖励金额在1周内保持不变（考虑到我们的30秒冻结时间，有20160个冻结， AdjustmentPeriod），然后进行调整。随着时间的推移，奖励最终将变为零，因为在每个步骤中给出的分数将网络帐户余额缩小到0。
注：由于EC的抖动（抖動（英语：Jitter），又可稱為時基誤差，指的是电子学和電信领域中，周期信号与真实周期之间的差异，通常是相当于參考時鐘信號而言。 ）和阴历时间的推移，发行计划可能会出现一些错误，预期错误应是小到不值得纠正。此外，由于支付机制是从网络账户转移到矿工，因此不存在铸造过多Filecoin的风险。
开放性问题
应如何引用Tipset“虚拟块”的收据？应用程序通常提供收据的merkleproof来证明交易已成功执行。
未来的工作
有许多改进存储矿工的想法，以下是未来可能实施的想法。
扇区重新密封：矿工应该能够“重新密封”扇区，采取一套部门大部分过期件，并结合一个（或多个）部门尚未到期件。
扇区转移：矿工应能够将存储数据的责任重新委托给其他矿工。因为各种原因，这是一个棘手的问题。不会在最初的fileDavinci版本中实现，但可能会提供有趣的功能。
下篇文章我们会介绍FIL的预期共识等相关内容，请持续关注我们~
点对点科技是国内领先的，
分布式存储和计算矿机生产厂商。
若想了解更多关于IPFS，Lambda，IoTE的资讯，
在后台回复项目名称即可
揭秘Filecoin的设计文档丨第四部分：挖矿.jpg
| 
立即注册
登录
