2

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

 3 years ago
source link: https://news.ethereum.cn/Eth1.x/should-storage-be-priced-separately-from-execution
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client
存储的定价应该独立于执行吗? · Ethereum Community Network
ETH   $ 2183.52   3.03%      Gas:  7 Gwei          Epoch / Slot : 50046 / 1601472       活跃验证者 : 189984       Join Us

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

存储会带来永久网络负荷,Vitalik 提出用 1559 对其独立定价的方案


Vitalik Buterin       2021-07-09

来源 | ethresear.ch

特别感谢 @barnabe 在早些时候提出了类似的想法。

正如我关于资源定价的旧文章里详细讨论的那样,以太坊的 gas 实际上是为三种不同的资源付费。

  • 带宽 (事务中必须被下载的数据)
  • 计算 (验证和执行事务所需时间)
  • 存储 (历史记录,但更重要的是状态,例如账户余额、nonces、合约代码和合约存储)

存储不同于其他两项开销。带宽和计算消耗的都是短暂开销,它触碰到短暂存储界限是这样的情况:一个节点在一个区块内能做多少计算或数据下载是有限度的,一旦该区块被打包了,下载和验证该区块的开销基本上都会消失 (未来只有少数同步节点需要处理它)。另一方面,存储则是一项永久的开销。如果一个区块的状态大小增加 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 倍,使得进一步填充存储在经济上变得不可行。

实现这点有两个方法:

  1. 用 gas 购买存储。也就是说,用 SSTORE 创建一个新的存储槽,这会像今天一样消耗 gas,但消耗 gas 的数量是会变的。这有一个缺点,即保留了时间点的错误激励 (用户会选择在周末 gas 价格低的时候增加存储,尽管这样对网络并没有好处)。
  2. 用 ETH 购买存储。事务 (和调用) 会需要提供 gas 以外的另一种资源 (我们会称之为 mana 😄),这种资源除了用不同的参数,会以与 gas 相似的机制进行收费。这个方法的缺点是它使调用规则变得复杂,且要求新增一个操作码 CALL。

还有两个混合选项:

  1. 我们可以用 ETH 来定价存储,但以 gas 来收费。(因此,如果基本费用上涨 2 倍,然后填充一个存储槽所需的 gas 会自动减半)。我们可以把用来扩大存储的 ETH 从 EIP-1559 的 gas 价格更新规则、甚至区块 gas limit 里排除出去。
  2. 对 gas 进行更全面的改革,把它拆分为三个概念:gas、执行点、和存储点。1 gas = 1 wei;一个分配 gas 的事务只意味着它把一些 wei 转化为一种特殊形式,可用于支付各种资源。在它如何在调用和子调用间的传递方式上,这种形式的运作形式与 gas 一样。但是,现在有两种开销是由 AMM 来管理的:执行点的开销和存储点的开销。不同于执行处理一个操作码现在消耗的是 N gas,它消耗的是 N 执行点,意味着对 N * execution_point_cost gas 收费。填充一个存储槽消耗 1 个存储点,因此 storage_point_cost gas 会被收费。

还需注意的是,state expiry 的路线图是包括移除 gas 返还的。这是由于技术原因,存储槽不能“变空”然后可用于返还;它们只能被设为 0,而 0 的记录必须保留在状态里,直到该 epoch 结束且该状态失活。这大大减少了以前存储租金方案尝试的困扰。

ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源,文章版权归原作者所有,转载须注明原文出处以及ethereum.cn,若需长期转载,请联系[email protected]进行授权。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK