Vitalik: 存储的定价应该独立于执行吗?

来源 | ethresear.ch作者 | Vitalik Buterin特别感谢 @barnabe 在早些时候提出了类似的想法。正如我关于资源定价的旧文章里详细讨论的那样,以太坊的 gas 实际上是为三种不同的资源付费。
存储不同于其他两项开销。带宽和计算消耗的都是短暂开销,它触碰到短暂存储界限是这样的情况:一个节点在一个区块内能做多少计算或数据下载是有限度的,一旦该区块被打包了,下载和验证该区块的开销基本上都会消失 (未来只有少数同步节点需要处理它)。另一方面,存储则是一项永久的开销。如果一个区块的状态大小增加 100 MB,这个区块在当下被处理没有问题,但当一系列这样的区块持续生成一个月后,整个以太坊会变得不可用。一时严重的状态增长带来的突发影响是可以忽略不计的,但长期的影响则是最严重的,因为每生成一个状态都永久地增加网络的负荷。采用了 state expiry 和弱无状态方案后,长期来说状态的影响肯定会大大减少:状态不再永久成为网络的负担,一个状态将只会在一年内增加网络负荷,而且即使在那一年里,也只有少数节点需要实际存储该状态。但即使如此,这个长期开销还是会存在的,且仍然需要被定价。存储大小的一般情况 vs 最坏情况无论是在当前的协议 (普遍认为是不可持续的),还是有 state expiry 的改良方案,对状态建模的一个弱点是状态膨胀的一般与最坏情况间有巨大差异。想想当前的协议。当前状态的总容量是大约 5.5 亿个对象,或约 32 GB (不包括 trie 的开销)。如果我们把在前一年没有被触及的状态都拿走,状态总容量很容易下降一半。那最坏的情况是什么?创建合约代码按每字节 200 gas 来收费,如果我们把一个区块分为三个事务,每个事务创建一个合约,我们可以用 “12334800 gas + 3 * 55000 gas” 作为合约创建开销来创建三个 20558 字节的合约。假设平均出块时间是 13.1 秒,那么每年会出31556925 / 13.1 = 2408925 个区块,因此,一年的状态大小增长是~61800 * 2408925 = 148871600381.67938字节,或大约 138 GB。这接近 10 倍的差异是非常显著的!而且 16 GB 特别符合现实消费者的硬件 RAM (如果不行,我们可以修改 gas 价格或状态失活期使其可行),但 138 GB 是办不到的。如果我们可以使最坏的情况更接近于一般情况,那就更好了。基于 EIP 1559 的两个方案解决这个问题的一个自然方法是,用 EIP-1559 对短暂和永久开销定价,但使调整期 (adjustment period) 不一样。对于短暂的开销,在单个区块里会有 10% 的变化幅度。但是对于永久的开销,我们会让价格调整得更慢。如果我们以 AMM 开销曲线机制作为基础,对于存储,我们可以考虑有一个条曲线代表每个月的目标比率是 1 GB,开销增长取决于我们比目标高出多少。例如,每超出目标 1 GB,存储开销可能翻倍。在这个参数里,最坏情况区块的存储价格可能需要大约 3 天时间才会翻倍。如果存储增长超过目标 10 GB,存储开销会比正常情况下高出 1000 倍,使得进一步填充存储在经济上变得不可行。
实现这点有两个方法:
还有两个混合选项:
还需注意的是,state expiry 的路线图是包括移除 gas 返还的。这是由于技术原因,存储槽不能“变空”然后可用于返还;它们只能被设为 0,而 0 的记录必须保留在状态里,直到该 epoch 结束且该状态失活。这大大减少了以前存储租金方案尝试的困扰。
原文链接:https://ethresear.ch/t/should-storage-be-priced-separately-from-execution/9101

原创文章,作者:惊蛰财经,如若转载,请注明出处:http://www.xmlm.net/wang/6804.html

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注