0%

用EtherScan调查Starknet手续费下降99%的真实原因

在本文中,LXDAO的作者0xSamo通过对EtherScan进行灵活运用,对Starknet的链上核心组件、optimistic/zk rollup手续费结构、EIP-4844的blob机制、SHARP系统的费率进行了探索,向大家昭示了Starknet手续费下降99%的真相:坎昆升级降低DA手续费只是辅助原因,真实原因是Starknet发币后国库有了其他收入来源,不必再依赖于手续费创收,所以大幅度下调了L2 Gas Price基准。

前言

EIP-4844作为The Merge之后以太坊最大的升级,吸引了足够多的关注。这次升级引入的Blob临时存储空间,相当于为以太坊这列火车增加了侧挂车厢,在不影响火车原有运行状态的前提下,提供了更便宜的DA空间。

Optimism、StarkNet、Arbitrum等Layer2项目都在短时间内支持了EIP-4844,并获得了显著的降费效果,以下是LXDAO国库在Optimism上为贡献者发放工资时生成的交易,在EIP-4844前后的Gas费竟然相差了100倍。

但在惊喜的同时,我们发现StarkNet作为ZK Rollup的代表,居然也获得了惊人的降费效果,从以前动不动就超过1美元的gas水准,下降到了0.01美元。

Starknet的手续费为何能降这么多

OP Rollup与ZK Rollup对一层DA空间的需求不同

这两者对DA空间的依赖程度是极为不同的。OP Rollup会将近期交易的所有细节,包括用户签名等数据,打包压缩后全部上传到一层网络。它不需要在一层网络进行太多的验算任务,几乎所有的成本都在使用一层网络的DA空间上。

相比之下,ZK Rollup对上链的数据拥有更高的压缩率。比如,它可以不上传Layer2交易的数字签名,仅依靠ZK Proof来确保交易有效;并且,ZK Rollup不需要打包所有交易细节,只需将状态的变化结果打包上链。

举个例子,在二层网络上,有100个用户在USDC/USDT交易对进行了交易,每次交易后,资产合约里的USDC、USDT的余额都会发生变化。对OP Rollup来说,这些交易行为背后产生的DA数据,就是100条交易、200个账户的400次余额变动;

而对ZK Rollup来说, 资产合约共计发生的200次变化,可以压缩为2次最终的状态汇总变更,大大减小了DA数据的体积。

ZK Rollup验证ZKP消耗的额外Gas

了解了两者区别之后,大家的第一印象也许是ZK Rollup的Gas费会比较低,但实操过的同学们应该都知道,在EIP-4844之前,StarkNet、ZkSync等ZK Rollup,其费用显著高于OP Rollup,特别是StarkNet,因为采用了STARK算法,其零知识证明的尺寸更大, 转账费用往往高于其他Layer2。

(2023年某时刻各L2费用表格)

ZK Rollup没有一上线就将OP Rollup碾压的原因很简单:它虽然对交易数据有更高的压缩率,节省了向一层传输数据的费用,但它要在一层网络上验证零知识证明,增加了计算费用。

Blob只能降低DA费用,对计算部分没有多少帮助,相比于OP Rollup,ZK Rollup在EIP-4844上获得的好处更少,所以当我们看到Starknet从手续费死贵的状态,快速实现了美分级别gas费后,很难不让人惊讶。

探索Starknet的手续费组成

ZK Rollup往往比OP Rollup更复杂。下图是Optimism排序器向一层网络发布DA数据时,生成的交易记录,任何人都能理解为什么EIP-4844落地后,OP的交易费用下降了两个数量级。

但在调查Starknet手续费来源时,本文作者经历了相当大的困难,因为Starknet不同组件之间的交互关系要更为复杂。下面让我们来重溯这整个流程。

消失的一层DA

因为有了探索Optimism手续费结构的经验,我们很自然想到,找到Starknet向主网提交数据的合约地址就可以了,这种关键合约肯定在Etherscan的Gas消耗榜榜上有名,应该是不难找的,比如还没适配EIP-4844的Scroll,其合约至今还挂在Gas消耗榜的顶端。

当我们搜索Starknet关键词之后,会在EtherScan上找到Operator、Core Contract、Memory Page Fact Registry3个相关组件,但第三个看起来和DA相关的合约,在接近两年前就停止使用了。

目前我们能看到Starkent的Operator在不断和Core Contract交互,不断地调用“Update State”函数。

如果我们翻到坎昆升级激活前后的链上记录,会发现Operator的“Update State”行为确实产生了细节变化,首先函数名更改为“UpdateStateKzgDA” ,其次,旧的状态更新函数会向Core Contract传送ProgramOutput、onchainDataHash和onchainDataSize,而新版函数中上传的是ProgramOutput和KzgProof。

这里的KzgProof,俗称KZG承诺,起到的作用类似于Blob的datahash,和Blob中存放的数据有着对应关系。值得注意的是,新版本的状态更新函数,消耗的gas比旧版本的更多。那么问题来了,Starknet到底为何能够把手续费降得这么低?原因到底是什么?

更多资料参考LXDAO旗下的Layer2科普网站MyFirstLayer2:

https://layer2.myfirst.io/zh#3.3-optimistic-rollup

第一次挫败后的分析

虽然第一次探索不太成功,但我们仍然能得到一些推论和猜想。看过 MyFirstLayer2的小伙伴一定知道Rollup的核心问题就是DA问题(数据可用性),而它们都是将关键数据上传到主网,来解决数据可用性问题,这样一来,所有人都能轻松访问到需要获取的数据。

我们都知道,Blob里的数据只是一串乱码一样的二进制文本,而一层网络只保证Blob数据上传后不被某些恶意节点篡改,但不负责验证这些数据的内容,当然,一层部署的智能合约也无法直接读取Blob里的内容。

因此,如果仍由一层来验证ZK Proof,那ZK Proof肯定不能放在Blob里,所以 我们可以判断,Starknet能够有如此显著的降费效果,与ZKP的关系不大,一定是因为State diff的存放位置变更所致。

下面的任务显然就是确认,Starknet到底把State diff放在哪里了?过去是放在哪儿的,现在究竟是不是放Blob里面。

此外,只能在UpdateState函数的输入参数里找到一个StateRoot也不禁让人怀疑,Starknet是否把原本应该直接上传至主网的数据,改为发送至自己的链下DAC (数据可用性委员会)来,如果真的是这样,那之前Starknet高昂的收费就完全没有道理,只能解释为……

SHARP系统

所幸和 @0xYandhii 讨论之后,让我醍醐灌顶,Starknet在通用型主网上线之前,第一个产品其实是StarkEX,包括去中心化衍生品交易所dYdX也是那个时期的产物。

在主网上线后,原先的产品没有被放弃,而是转而与主网共享一个验证器合约,即SHARP: Shared Proving and Verifying System系统,然后我们找到了 SHARP Blockchain Writer、SHARP Verifier等相关合约。

打开区块浏览器查询相关交易,可以发现SHARP Blockchain Writer进行了以下4类操作:

不难看出1、2、4是与ZKProof相关的函数,而第3个函数,显然是向一层网络写入数据的步骤,是最有可能与State diff上传相关的功能。

我们推测,1、2、4三个函数的调用手续费,在Blob升级前后没有显著变化,而第3个函数的使用成本,应该显著的降低了,这样就能解释Starknet为何降费效果如此显著。

于是笔者继续翻阅区块浏览器,在EIP-4844前倒数第二个旧版本、倒数第一个版本,已经升级后的最新版本3个时段各取一个验证周期,统计4个函数每次调用时,各自消耗的Gas究竟如何。

结果如下,令人挠头。

第3个和数据发布相关的函数,其费用有下降一半,但从其在一整轮ZK Proof验证过程中的费用占比来说,这个DA费用下降水平证明不了我们前面提出的假设。

探索走到这里几乎就到了山穷水尽的一步,笔者感觉自己就像三体世界里坐在大型粒子对撞机前的物理学家,每个脑细胞都在尖叫着:This doesn't make sense ! 我甚至去 Starknet社区发了一篇帖子询问,但也许是因为问题太复杂,英文社区迟迟没有人回应。

SHARP系统GasUsed探索

至此,我们还剩最后一个小Trick ,之前下载的交易数据csv里面,只有Gas费消耗的ETH ,没有GasPrice、Gaslimit等信息,所以无法排除Gas单价波动对统计结果的影响。于是笔者写了脚本将之前涉及的每一笔交易实际消耗的 GasUsed(Gaslimit 里被使用掉的部分)统计了出来。

这一次我们终于发现了端倪。可以看到在坎昆升级之前,那个名叫Register Continuous Memory Page的函数,在每次DA数据上传时会触发2次,一次消耗5万的gas,另一次消耗30万gas。

而坎昆升级之后,几乎所有调用Register Continuous Memory Page函数的交易,都只消耗5万gas。

之前我们取的样本太少,正好那一次升级后,正是主网Gas费暴涨的时期,这影响了我们的统计结果,导致我们认为,Register Continuous Memory Page函数的调用成本,在坎昆升级前后都没发生什么变化,而当我们对统计数据进行更广泛的采纳时,很快就发现了问题所在。

按照这个思路我们重新整理了 3 个时刻的 GasUsed 数据,这回合理了许多。至此可以证实,与DA数据上传相关的Register Continuous Memory Page函数,确实在坎昆升级后手续费显著降低,这应该就是原本存放State Diff的步骤,而坎昆升级后,DA数据转移至了Blob中。

后续我们在L2beat网站上找到了Starknet的产品结构示意图,可以发现,State diff确实是通过上述函数来存放至以太坊链上的。

最终,我们根据GasUsed的数量计算(以目前随机抽取的较小样本量来宽泛估计),得出结论:Starknet在坎昆升级之后,DA费用大概有4~10倍的变化,略低于一个数量级。

这也符合我们最开始的猜测:在EIP-4844升级后,ZK Rollup获得的好处并不如 OP Rollup那么多。

总结

经过以上探索,我们终于理清了Starnet手续费大幅下降的原因,其结论还是有点耐人寻味。

DA费用大降,但解释不了两个数量级的降幅

可以明确,Starnet之前是把每个Batch中包含的状态变化数据,直接上传到一层网络中的,现在则是将这部分数据放在了Blob中,因此可以在DA数据这部分手续费中,获得略小于一个数量级的降费效果。

但该如何解释Starknet手续费下降99%这个结果?单纯靠DA降费显然远不够。唯一合理的解释就是:Starknet在坎昆升级前,确实“心黑”向用户收了太多手续费。在STRK发币前,Starknet的所有活动、社区激励都需要资金,除了烧投资人的钱之外,在向用户收取的ETH和实际消耗的ETH之间设置剪刀差,可能是Starknet维系运营的方式之一,这才使得此前Starknet的Gas费如此之高。

现在,STRK代币发行为Starknet带来了足够的资金,是时候让Gas回到合理的水准了,趁着坎昆升级把绑在脚上的沙袋一起拆下,展现出的降费效果确实惊艳了许多人。

Rollup历史数据丢失问题

OP Rollup在升级之后,将原本存储在交易Calldata里的数据,转移到Blob这个临时储存区后,其实牺牲了一点去信任性。

在此前,Calldata空间的数据是永久储存的,意味着任何人都能从以太坊主网里下载到足够的历史数据,来验证和同步OPR当前的状态。

但坎昆升级之后,Blob的数据有过期淘汰的设定,如果全网没有任何一个实体保存过去的Blob数据,那么OPR的历史交易记录有可能会丢失。

虽然当前最新的二层网络状态仍然能被保护——因为Blob的保存期限超过OP的 7-14天挑战期,所以每个Blob在即将过期之前,它所对应的二层状态仍然是可信的,这最新的十几天的交易记录滚动地维护着OPR的安全性。

ZK Rollup如果要享受Blob带来的好处,同样需要把重要的二层状态数据,从Calldata空间转移到Blob空间里去。这意味着在一段时间后,我们也不再能像以前一样,依靠一层网络提供的数据来Replay二层的状态。

也许这将成为一种常态,今后所有的二层网络,都依靠Blob维护最新状态的安全,而每一条L2也需要自己另外想办法解决历史交易数据存储问题,如此在安全和效率之间取得更好的平衡。

OP与ZK的融合趋势

过去,第一代的OP Rollup率先上线,而第一代的ZK Rollup上线后没有带来更具竞争力的Gas费。到后续OP Stack、Polygon SDK带来的模块化风潮,OP Stack 甚至计划在将来引入ZK技术来降低挑战期。

这无疑都指向一个事实:OP与ZK两种技术路线并不是你死我活的竞争,他们会互相借鉴,有融合的趋势,只不过这一次是“高贵”的 ZK 向“简单粗暴”的OP学习的一次。

很难想象二层网络的技术在短短两三年之间演化到如此的地步,也许这就是区块链世界的魅力吧。

参考资料:

[1]FeedTheFed. Data availability with EIP4844[EB/OL]. (2024-02-11)[2024-04-16]   https://community.starknet.io/t/data-availability-with-eip4844/113065.h

[2] L2BEAT research team. Starknet[EB/OL]. [2024-04-16].https://l2beat.com/scaling/projects/starknet?selectedChart=activity#contracts.

日期: 2024-04-24 09:10

返回

上一页:如何看待后市加密行情?

下一篇:NEAR:为何AI需要Web3?Web3究竟会给AI带来什么样的颠覆式进步