GMX:V神:伦敦升级后,链容量增加9%的三大原因_SNFTS币

注,昨日以太坊创始人V神发文《链容量为什么在伦敦升级之后增加了约9%?》,以下为全文编译。

观察一下以太坊每日Gas使用量的图表,我们可以发现每天平均使用的Gas从约920亿增加到了约1000亿:增加了9%。

那么,为什么会发生这种情况呢?

我认为,这一情况大致上可以从三个不同的原因上解释:(1)冰河时代的延迟,(2)伦敦升级前的区块没有被填满,以及(3)基费调整公式的不完善。

V神:潜在的以太坊PoW分叉不太可能获得长期广泛采用:8月8日消息,在周五晚上的ETHSeoul上,以太坊联合创始人Vitalik Buterin表示,潜在的以太坊PoW分叉不太可能获得长期的广泛采用。在问答环节中V神谈到了这种硬分叉对以太坊网络的潜在影响。V神表示,他没有看到该计划的有机方面,并声称这只是几个基本拥有交易所的局外人,主要是想赚快钱。不认为这(以太坊PoW分叉)会被大量、长期地采用。

但他承认,在此期间,一些市场可能会出现一些问题,并补充说,希望无论发生什么,都不会导致人们赔钱。这可能指的是交易所推出IOU产品,使交易员能够押注分叉代币的价值。目前有三家交易所提供此类产品。

此外,V神还谈到了ETC,称它为支持PoW价值和偏好的人提供了卓越的社区和卓越的产品。(The Block)[2022/8/8 12:10:28]

冰河时代的延迟

声音 | V神:2016年购买MKR并不难,我大部分钱就是这么来的:今天,V神在推特上回复网友称:“最早在2016年,在公开市场上(即oasisdex)购买MKR是可能的,而且并不难。我知道是因为我大部分的钱就是这么来的。他们当时并未拉高MKR。”[2019/3/31]

伦敦分叉推迟了冰期,当伦敦分叉开始时,冰期刚刚开始生效。在伦敦升级之前,平均区块时间约为13.5秒,而伦敦升级之后,平均区块时间回到了长期的正常水平,约为13.1秒。

声音 | V神:以太坊计划在2019年开始动手削减能源浪费:据人民网报道,以太坊创始人Vitalik Buterin近日在接受采访时表示,以太坊的耗电量惊人,这不仅造成了巨大的能源浪费,导致了污染和二氧化碳等环境问题,也将真正的消费者排挤在外。他表示,以太坊计划在2019年开始动手削减能源浪费,据目前开发人员预计,到 2019 年底,用以太坊新代码来交易,耗电量可望大幅减少 99% 。[2019/2/3]

这是区块速度3%的差异,也是链上Gas使用量增加9%其中3%。

Gas使用量:目标15M与最大15M

在伦敦升级之前,最大的区块Gas使用量为15M。但并不是所有的区块都使用了整个15M:即使是功能最完善的区块生产者也会留下0-20999的Gas未使用,因为剩余空间太小,无法容纳一个交易。除此之外,总有一些区块生产者会偶尔制造出空区块。4月份的一项分析表明,大约2%的区块是空的。总的来说,我们可以假设伦敦升级前的未使用空间约为2-3%。然而,伦敦升级后,1500M已不是最大值,而是目标。这意味着,如果包括空区块在内的平均Gas使用量低于15M,那么基费也将减少,直到平均数回到15M。

因此,这又占了这一现象原因的约2-3%。

基准费用调整中的数学缺陷

由于算术平均数和几何平均数之间的复杂关系,EIP1559公式并不能完美实现50%的使用率。一个0%的完整区块可以使基费减少12.5%,而100%的完整区块可以使基费增加12.5%。那么,如果你有一个0%的完整区块,然后是一个100%的完整区块,会发生什么?结果是,基准费用会乘以63/64。因此,为了使基费保持不变,你实际上需要的平均使用率略高于50%。

至于高于多少则取决于波动率是多少。理论上的最小波动偏差是零:这时50%的区块是完整区块,基费在每个区块中保持不变。而理论上最大的波动偏差是53.13%的区块是完整区块,而46.87%的区块是空区块;在这种情况下,基费将在平均53.13%的区块是完整区块时保持不变。而实际使用情况似乎在这两个极端的中间:从最近观察到的一个时间段的数据来看,51.5%是完整区块。

最近的数据分析也大致证实了后两个数字。

解决这一数学问题的一个可能方法是让基本费用调整机制更明确地呈指数增长:https://ethresear.ch/t/make-eip-1559-more-like-an-amm-curve/9082。这将建立一个硬性的不变因素,基础费用可以作为总“过剩”Gas使用量的直接函数计算(因此,对于任何水平的过剩Gas使用量,基费将不得不最终趋于无穷大)。

但现在,以太坊用户可以为伦敦升级带来的无意的6%的容量增长而欢欣鼓舞。

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

区块博客

[0:0ms0-8:551ms