Rollup最大的信任风险:无法忽视的“人治”问题_USD:男生突然把网名改成Ethereal

作者:林克,《极客Web3》

导语:自Solana逐步衰落和OP发行Token以来,Layer2和Rollup似乎成为了无数Web3从业者新的港湾。随着熊市的持续蔓延和FTX暴雷出局、Multicoin损失惨重,以太坊的竞争对手们陆续淡出了Web3这个大舞台,不断失去了和ETH一较高下的底气。越来越多的人开始将Rollup视为新一轮叙事核心,越来越多的项目如同雨后春笋般在L2上扎堆涌现。

但这一切是否是“虚假的繁荣”,是否是“随时可能被戳破的泡沫”?Rollup和L2真的如同大多数人所鼓吹的那般美好吗?它真的像人们所认知的那样安全吗?且不谈许多OP Rollup没有欺诈证明,Rollup的安全隐患还有哪些?

本文受到L2BEAT近期发布的“Upgradeability of Ethereum L2s”启发,针对Rollup升级背后的多签与委员会信任风险(立即升级Rollup合约,卷走用户资产)及此前关于Rollup的老生常谈,联想到前不久的Multichain,综合聊下L2为何不像许多人所想的那么“美好”。

Rollup运作原理简述:

以太坊Rollup = Layer1上的一组合约 + Layer2网络自己的节点。

Layer2网络节点这个群体可以拆分出几类角色,其中最重要的当属定序器(Sequencer)。它接收Layer2上发生的交易请求,决定它们的执行次序,然后把交易序列打包为批次(Batch),传送给Rollup项目在Layer1上的合约(下文中将统称为Rollup合约)。

Layer2的全节点可以直接从定序器处获取交易序列,也可以读取定序器发到Layer1上的交易批次(Batch),但后者具备比前者更高的最终确定性(不可更改性)。通常,当一批交易被定序器传送到Layer1上后,这批交易的次序便不可变更(只要以太坊不发生区块回滚,Rollup的交易序列就不会变更)。

由于交易执行会更改区块链账本的状态,所以除了交易次序外,Layer2全节点还需要和定序器同步账本状态,这样才能保证一致性。

因此,定序器不光要往Layer1的Rollup合约传送交易批次,还要把交易执行后的状态更新结果(Stateroot/State diff)传送至Layer1。

不难看出,L1(以太坊)实际上充当了L2节点们的公告板,它要远比L2自己的网络更去中心化、更Trustless、更安全。对L2的全节点而言,只要获取了L1上的Rollup交易序列 + 最开始的Stateroot,就可以还原出L2的区块链账本,计算得出最新的Stateroot。如果L2全节点自己算出的Stateroot和定序器发布到L1的Stateroot不一致,就说明定序器存在欺诈行为。

最直观的假想案例是:L2的定序器可不可以盗取用户资产。比如,它可不可以伪造一些本不该发生的交易(ps:把某些L2用户的Token转移至定序器运行者的地址,然后再把这些Token转移到L1上)。这类问题可以归结为:定序器发布了错误的交易数据或错误的Stateroot后,该怎么办?

针对定序器的欺诈风险,不同类型的Rollup有不同的应对措施。Optimistic Rollup(乐观Rollup)允许L2全节点提供欺诈证明(Fraud Proof),证明定序器在L1发布的数据存在错误。比如Arbitrum设置了一个节点白名单,允许白名单上的L2节点发布欺诈证明。

除此之外,考虑到大多数交易所和私营跨链桥项目方都会运行L2全节点,可以立即发现错误,大多数Rollup定序器盗币的成功率基本为0(因为它最后要套现,还是要在交易所完成,或者把盗来的币转移至L1后再另谋出路)。

(图中的Aggregator实际就是定序器)

但对于没有欺诈证明的Optimism,定序器可以通过Rollup自己的跨链桥bridge合约来盗币。比如,定序器运行者可以伪造交易指令,将其他人在L2的资产转移至自己的地址,再通过Rollup自带的bridge合约,把盗来的币转移至L1。因为没有欺诈证明,OP的全节点无法对错误交易发起挑战,所以理论上,OP的定序器可以盗取用户在L2的资产(只要它真的想这么做)。

解决这种问题的方法是“社会共识”(靠社区成员和社交媒体等舆论监督),或者靠OP官方的信用背书。

有趣的是,近期某交易所降低了Arbitrum 和 Optimism 用户向所内转币的延时(从100个L2区块降低到1个L2区块),这其实是信任ARB和OP的定序器不会作恶(默认它们是有官方背书的中心化服务器)。

不同于乐观Rollup,除了依靠L2全节点外,ZK Rollup通过有效性证明Validity Proof(往往与ZK Proof相混淆)解决定序器欺诈问题。ZK Rollup网络里有一种称为Prover的节点,专为定序器发布的交易批次Batch生成有效性证明。同时,L1上有专门验证有效性证明的合约(一般称为Verifier),只要交易批次及Stateroot/State diff对应的证明通过Verifier合约的验证,便被最终确认(Finalized)。ZK Rollup的官方bridge只会给通过有效性证明验证的提款交易放行,显然这要比Optimism可靠太多。

理论上来说,OP Rollup的安全性靠L2全节点来保证(至少要有1个能发布欺诈证明的诚实节点)。ZK Rollup的安全由L1上的Verifier合约保证(由L1节点完成交易最终确认)。表面上看,它们都可以“继承L1的安全性”(借助L1完成交易的最终确认/结算),以太坊最大主义者甚至将其称作“等价于L1的安全性”(与L1的交易结果最终性一致),但实际情况却并非如此,甚至是远非如此。

首先,ZK Rollup的有效性证明生成速度极为缓慢,定序器可以在1秒内执行几千笔交易,但为这几千笔交易生成Proof最多可能要几小时。但这个问题也容易解决,主流的ZKR基本都会通过切分Proof生成任务、交由不同的Prover节点并行处理的方式,大幅提高Proof生成速度。

其次,要考虑L2节点在L1发布数据的延迟。因为定序器或Prover每次往L1发送数据,都会有一个固定成本(就好比每次运货都要消耗一个集装箱)。频繁在L1上发布数据是不划算甚至亏本的,所以定序器和Prover会尽量减少在L1上发布数据的频率,等一次性凑够了大量的数据再打包发布。

换言之,当用户数量不足、发起的交易笔数不够多时,定序器会延迟向L1发布数据。比如在去年用户较少时,Optimism半小时才向L1发送一次交易批次。现在,因为用户多了起来,这个问题得到了有效解决。与OP不同的是,Starknet采用了减少State diff发布频率的方式降低数据成本,这使得Starknet的交易最终确认延时被拉长到了7~8小时。

除此之外,多数ZK Rollup为了进一步降低成本,往往会“聚合许多个Proof,再一次性发到L1上”。也就是说,Prover不会在生成一个Proof后就立刻发到L1,而是等多个Proof都生成完,聚合在一起,再发给L1的Verifier合约。(其实聚合Proof的过程,就是用一个Proof来包含掉验证多个Proof产生的计算步骤)

这样做的后果是,Proof的发布频率进一步降低了,交易从发起到最终确认的延时进一步拉长了。

根据区块浏览器显示,Polygon ZKEVM的交易确认延时大概是30~50分钟,Starknet和Zksync Era在7小时以上。显然这只是“部分继承L1的安全性”,与以太坊支持者们所说的“等价于L1的安全性”有很遥远的距离。

当然,以上问题都可以靠技术进步来解决,在不久的未来实现。比如很多项目方在研发高性能硬件,降低有效性证明的生成时间;Optimism也承诺将很快发布欺诈证明系统;以太坊的Danksharding方案将把Rollup的数据成本降低几十倍甚至更高,这可以有效解决上面罗列的问题。

与Defi等应用类项目一样,Rollup网络的运转需要依靠L1上的相关合约,而这些合约是“可升级”的,也就是说部分代码可以更换(大多数Rollup都用了代理合约),并且可以在多签或安全委员会的授权下立刻进行。先说结论:Rollup可以通过少数人控制的多签或安全委员会,快速更改L1上的合约代码,然后盗取用户资产。

首先“Rollup合约为什么需要升级”和“它是怎么升级的”。以太坊上的合约代码在部署后,是不可更改的,但Rollup在开发过程中难免存在各种各样的bug,可能导致错误的结果;同时Rollup也在频繁的进行产品迭代,需要频繁增加新的功能;更极端的情况下,还可能有黑客攻击Rollup合约,所以Rollup合约需要有可升级性,这往往通过代理合约来实现。

代理合约其实是以太坊合约开发中常用的一种方法,就是将合约的数据和业务逻辑分开,分别保存在不同的合约中。数据(状态变量)存储在代理合约中,业务逻辑(函数)保存在逻辑合约中。代理合约(Proxy)通过delegatecall,将函数的执行过程全权委托给逻辑合约(Implementation),再把最终的结果返回给调用者(Caller)。

代理模式下的合约升级,只需要将代理合约指向新的逻辑合约(改写代理合约里存储的逻辑合约的地址)。大多数Rollup项目都采用了这种给合约升级的方法,可谓简单粗暴。

不难想到,Rollup的合约可升级其实是巨大的雷:如果升级后的合约里包含恶意的代码,比如把Rollup自带的Bridge合约的提款放行条件加以修改,或者把Verifier合约判定有效性证明正确性的条件加以更改,定序器就可以盗币(原理在前面讲了)。

但问题在于,又不能不允许Rollup合约可升级,理由在前面说的很清楚。权衡之下,绝大多数Rollup会通过DAO治理、安全委员会或多签授权,用人治的方式来决定要不要升级Rollup的合约。除此之外,还会通过时间锁Timelock,来为合约升级设置延时窗口期。

考虑到大多数的DAO提案都有自动化的执行流程(通过链上合约来实现),即便要升级合约,也要先获取足够多的投票,然后再经过时间锁Timelock规定的延时(往往要经过很多天),升级合约的操作才会执行。如果有人想搞恶意的合约升级,需要通过治理攻击的方式度过DAO治理这关(比如发生在Tornado Cash上的治理攻击),但这样做的成本很高,要先获取足够多的Token才行,正常情况下不会成功。即便治理攻击成功了,由于有时间锁的限制,用户会有足够多的时间把资产从L2撤出,Rollup官方也会有足够多的时间采取紧急措施。

看起来时间锁是解决恶意的合约升级的法宝。但问题在于,所谓的“Rollup官方可采取的紧急措施”,其实就是绕开DAO治理和时间锁,通过多签或者安全委员会授权,立即升级Rollup合约。考虑到目前主流的Rollup托管了动辄几十亿美元的用户资产,由多签和安全委员会来授权的“合约可立即升级”,是终极的应急措施,但也是悬在所有用户头顶上的达摩克利斯之剑。

显然这是信任最大化问题:你需要信任Rollup官方不会有盗取你的资产的念头。如果从Trustless的角度来考虑(尼克萨博的视角),所有由多签和安全委员会控制的Rollup都是不安全的。Avalanche创始人Emin Gun Sirer和Solana创始人Anatoly、著名黑子Justin Bons都曾强调过这类问题。

根据知名L2研究机构L2 BEAT发布的报告“Upgradeability of Ethereum L2s”,及L2BEAT数据可视化网站显示,Arbitrum、Optimism、Loopring(路印)、ZKSync Lite、ZkSync Era、Starknet、Polygon ZKEVM等主流Rollup都存在多签或委员会授权的可升级合约,并且可以绕开时间锁限制。

dYdX虽然有一个EOA地址可以绕开DAO治理升级合约,但受到时间锁限制(至少有2天的延时)。Immutable X则存在14天的合约升级延时,所以,按照L2BEAT的说法,dYdX和Immutable X要比其他已上线主网的主流Rollup更Trustless。

那么该怎么降低多签和安全委员会带来的信任风险?答案其实和Multichain事件类似:可以归结为反女巫问题。必须要保证,多签/委员会由多个不同的、无高度利益重合的、串谋风险低的实体来控制。目前看来,除了加大DAO去中心化治理的成熟度、邀请有名望有信誉的名人或机构来参与多签/委员会以外,似乎没有什么太好的办法。而以上场景似乎早已在现实世界的民主中屡见不鲜。

当然,也可以通过时间锁给多签/委员会管理的合约升级行为加以限制,但这需要针对许多因素进行权衡,因为多签/委员会的存在目的就是为了快速处理一些紧急情况;同时,如果Rollup项目方在去信任化问题上没有什么坚定的决心,这个问题也不可能被解决。

所以,尽管不同的Rollup项目通过精妙的机制设计,可以在绝大多数时候保障用户资产的安全,但由于存在多签和委员会,Rollup发生黑天鹅事件的概率并不为0。即便多签和委员会成员串谋的概率只有万分之一,考虑到L2托管的资产价值(假设为100亿美元),L2用户资产每天的风险仍高达100万美元。联想到Multichain事件,着实令人毛骨悚然。

所以我个人认为,就像Polynya此前所说的那样,以太坊生态内的大多数资金仍然会倾向于在L1流通和锁仓,而非L2,Rollup生态长期内都无法捕获以太坊生态内的大部分价值。对于大户和鲸鱼,以太坊主网显然是一个比L2更合适、更可靠的资金去处。所以,很多人此前考虑的“L2的崛起会不会导致L1的冷清”,其实早已有了答案。

正如东野圭吾在其著作中所说,人心要远比数学公式更难捉摸,更难理解,更为复杂,也更难改变。许多事情无法靠单纯的技术手段来解决,但凡涉及到“人性”的因素,永远都是这个世上最不可控、最难预测、也最需要严肃对待的问题。在此,请让我们牢记康德墓碑上的那句传世经典:

“有两样事物始终围绕着我的心灵,我越是加深对他们的思考,心中唤起的惊奇和敬畏越是日渐加深:这便是 内心的道德律和头顶灿烂的星空。

极客 Web3

个人专栏

阅读更多

Foresight News

金色财经 Jason.

白话区块链

金色早8点

LD Capital

-R3PO

MarsBit

深潮TechFlow

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

金宝趣谈

[0:15ms0-8:75ms