再探 Filecoin 费用机制：天价手续费如何应对？

燃料（Gas）费用高昂，老矿工无奈纷纷停工，趁这个时机调整一下矿池，但挡不住新进矿工的涌入，继续推高 Gas 费用。这个时候，大家就想问一句话，到底 Gas 费用能不能降下来了？什么时候能？怎么做？

每一次升级不少人都充满期待，但是，事实并非如此。当前的升级并不能够降低 Gas 消耗，也不能降低 Gas 费用。只是让 Gas 费用更趋合理。

Gas 费用能降下来吗？怎么降？要说清楚这个事情，我们一步一步来。

燃料（Gas）是什么？

在 Filecoin 网络中，Gas 是一条消息（交易）在网络中执行所需要耗费资源的度量。这里所谈的资源包括计算资源和存储资源，也就是说，是执行一个交易的成本。比如我们说，某一条 PreCommitSector 消息消耗 25,346,170 Gas，也就是说，对于这一条消息，Filecoin 通过处理这一条消息，改变网络状态，所需要花费的成本是 2 千 5 百多万 Gas。每一条消息都会需要网络执行，都会消耗网络资源，因此，都会消耗相应的 Gas。比如时空证明 WindowedPoSt 一般消耗 Gas 的量是 2 亿到 5 亿；而复制证明 ProveCommitSector 消耗 4 千万到 6 千万以上。一般的转账消息由于处理起来比较简单，消耗的 Gas 相对而言就少很多，大致在一百万之内。

每一条消息消耗的 Gas 数量与消息类型关系密切，比如证明消息消耗的多，这是因为其计算量大，同时也需要调用大量的状态信息，比如 Sector commits 进行计算，所以消耗大。而转账无论是存储还是计算消耗量都少很多。同时，同样类型的消息的 Gas 消耗在不同的情况下也不尽相同。这是因为当时的网络状态不同，需要的资源消耗就不一样。

举一个简单的例子，比如同时发送两条转账，向新地址转账消耗的 Gas 就比向老地址转账要多，这是因为向新地址转账时，网络需要首先创建这个地址，这就会多花费计算和存储资源，所以消耗就更多一些。这样一来，对于消息的发送者而言，发送消息的时候到底要支付多少 Gas 就比较难判断了。这个时候，就需要做一个合理的估计。

在发送的每一条消息里面，消息的发送者都可以为这一条消息消耗的 Gas 设置一个上限，如果执行的时候需要的 Gas 超过这个上限的话，消息就不被执行了。这个上限值就是消息发送者对此消息成本的一个估计和愿意支付的最大成本。这个估计很重要，尤其是在支持智能合约之后，有些消息的成本估计变得很困难，或者由于设计的原因出现 bug，没有上限可能导致消息发送者的巨大损失或者导致网络安全问题。

一般情况下，大家对发送消息做一个估计，并在估计的基础上加一个保险（比如 10～25%），用来设置这个上限：GasLimit。

燃料（Gas）费用的计算？

前面提到了每一条消息都需要计算资源，通过 Gas 来进行度量。任何资源都是需要成本的，计算资源也一样。Gas 数量乘以一个价格，就是这条消息执行的成本了。燃料（Gas）费用就是 Gas 的单价，比如说，Filecoin 里面定义 Gas 的最低费用为 100 attoFil，也就是 0.0000000000000001 Fil. 这种情况下，一条需要消耗 4 亿 （4e8) Gas 的 WdPoSt 消息，需要的费用就是：

100 attoFil * 4e8 = 40nanoFil = 0.00000004 Fil

非常低了，基本上可以忽略。

但是，如果 Gas 的单价涨到 4 nanoFil，也就是 0.000000004 Fil，这是当前网络的平均 Gas 费用单价，相对于最低的 100attoFil 来说，上涨了 4 千万倍。那么这个时候同样一条需要消耗 4 亿（4e8) Gas 的 WdPoSt 消息，需要的费用就是 1.6Fil，这一下吓人了吧。

在 Filecoin 的设计中，引入了 EIP-1559 的 Gas 费用调解机制，Gas 费用分为两个部分：1）基本费（baseFee）；2）小费（Premium）。基本费由网络自动计算，反映网络的拥堵程度或者说资源消耗情况，这部分费用会燃烧掉；而小费就是消息发送者支付给矿工的费用，通过支付费用希望矿工打包自己的消息。

当然，像 GasLimit 用来设置 Gas 消耗的总数量一样；Gas 的价格也可以设置一个上限，这个上限就是 feeCap。意思是消息发送者愿意支付的 Gas 的最高单价。

结合上面两个部分，我们得出结论，一个消息发送者愿意为她的这条消息支付的最高费用是：

GasLimit * feeCap

也即愿意支付的最高 Gas 数量和最高价格的乘积。

为什么需要 Gas 费用？

一句话，为了网络安全。无论什么系统，都有一个处理能力。对于去中心化的区块链系统而言，因为有大量的矿工共同维护网络，考虑的就是网络的一般处理能力。如果需要处理的消息（交易）超过网络的处理能力，网络安全就会出现问题，至少对于 Filecoin 而言，其出块就会受到影响，如果大量的消息拥堵，导致处理能力稍低的矿工很快被淘汰出网络，网路会被处理能力最强的矿工霸占。

通过 Gas 费用的调节，并同时辅助一些惩罚措施，来形成一个反馈系统，在网络拥堵的时候调高 Gas 单价，在网络空闲的时候调低单价，保障网络的顺畅。同时也可以防止垃圾消息泛滥和对网路的攻击。具体的做法是，设置一个网络处理能力值，在消息消耗 Gas 的总量（具体就是计算 GasLimit 的和）超过这个值的时候，提高 baseFee，低于这个值的时候，降低 baseFee。为了快速调节，调节的方式是指数调节。这也是为什么大家看到 Gas 费用的改变非常快的原因。

最近两次升级对 Gas 费用的调整有帮助吗？

当 Gas 费用高企，很多人希望 Filecoin 团队采取措施，降低 Gas 费用。这里有一个十分简单的办法，那就是人为调高系统的处理能力。但是这件事是不能武断地就这么干的。如果设置的处理能力超过了网络中节点一般处理能力的话，一方面提高了网络进入的门槛，另一方面网络的安全性就下降了。

那么为什么团队不直接把 Gas 费用降低一些呢？到底有没有办法降低 Gas 费用呢？

前面讲了一个理由，为了网络安全，不能想怎么设置就怎么设置。必须要考虑网络的情况和真实地反映消息的实际成本。但是，最近两次升级不是都对 Gas 消耗产生影响了吗？怎么回事。

现在来说一下这两次升级。

V1.2 升级调整了一些消息处理模块的 Gas 消耗的值，这个调整的主要原因是之前的版本设置相对武断了一些，这一次把它合理化。具体调整如下：

大家可以直接看到的就是，PoSt 的验证费用大大降低了。那么这对 WdPoSt 的消耗产生了积极的影响，更省钱了。但是，对存储相关的操作费哟哦那个又都升高了。这是因为当网络数据越来越多，存储的消耗成本也越来越高，这之前对存储的消耗哦估计不足，所以进行调整。这个调整后，大家看到的情况就是 PreCommitSector 和 ProveCommitSector 消息费用不降反升了。尤其是对于大矿工而言，增加算力时对存储的访问量更大，其消息消耗的燃料费更高。

所以，这一次升级并不是要调整燃料费，或者说降低燃料费，而是让其更加合理。

V1.3 的升级主要解决一个问题，WindowedPoSt 的燃料消耗还是太大了。尤其是小矿工受不了。同时，这个消息是控制类的消息，不得不发。怎么办，想一个办法，是不是可以少燃烧或者不燃烧这部分。这个想法在前期讨论中被提出来。当然还有很多其他想法，但这个想法目前实现起来相对比较简单。最后成文为 FIP009 （其中在前期相关工作中一节提到 Steven004 提出的类似想法）。这个升级仅仅调整的是 WdPoSt 的燃烧部分，但 Gas 消耗的计算没有发生变化。

因此，任何认为通过这次升级能够降低 Gas 费用的想法都是不现实的。

到底如何能够降低 Gas 费用呢？

综上所述，我们知道 Gas 费用涉及到系统的安全问题，与系统处理能力有关系，不能随意调整。那么能够做的就两个方面：1）系统处理能力的提升；2）大家根据 Gas 费用自己掌握发送消息的节奏，对目前而言就是增长算力的节奏。

目前最为现实的，而且是持续比较现实的，Filecoin 的参与者都需要考虑的就是无论算法如何优化，网络性能如何增强，网络还是会出现拥堵，因此，这些情况都需要靠大家共同面对和处理，这个部分不是开发者能够解决的。这个燃料费本身就是为了调节，因此涨跌是正常现象，要平常心对待。这与现实的经济生活是一样的，靠市场调节。

另外，当 Filecoin 的生态越来越繁荣，Filecoin 网络的处理能力也需要进一步提升，不然较低的处理能力也会阻碍网络和生态的发展。这部分的工作也是当前最重要的工作之一。目前已经在考虑的多个提案都与 Filecoin 网络性能的提升有关，比如说：

FIP007: 提升 HAMT 和 AMT 的性能和安全性：HAMT 和 AMT 是 Lotus 里面存储状态最主要的数据结构，其性能的提升有助于整个网络性能的提升

FIP008: 批量处理 Pre-commitments：目前每个 Sector 的 precommit 都是一个单独的消息。如果支持批量发送的话，可以省掉不少消息，对存储的访问和更新也可以一次性处理，因此可以提升性能

进一步，根据 FIP008 的思路，Prove-Commitments 也可以批量处理。这个目前在处理上已经是批量处理了。但消息发送还是单独发送。

一些更加激进的方案：考虑到目前消息处理的资源消耗最大的都是验证证明消息，也就是 PoRep 和 PoSt。那么有一个想法，那就是干脆不验证。这就大大节省时间了。可以极大地降低资源消耗。那么不验证不是可以造假吗？其实不然，类似于共识错误的惩罚。在考虑绝大多数人不会造假的情况下，考虑一个检举机制来防止造假。那么，只要有一些节点愿意在链下验证，并进行检举就可以了。

何时可以看到上述想法实现？

根据目前核心开发组的讨论，在新年假期之后，FIP007 会进入下一个版本之中，发布的时间窗口可能在一月下旬；FIP008 视实现情况在同一个版本实现或者放到下一个版本。

对于无需证明的激进方案，还有一些问题需要探讨。比如说安全性问题，如果有人大量造假是否会带来比较大的问题，对于检举者如何奖励，检举的期限等等都还需要探索。这需要更长一些时间。