理论与实践:以太坊Rollup的抗审查交易如何触发?

极客 Web3热度: 17389

昨天,以太坊二层网络Linea因黑客攻击停机,引发对Web3去中心化价值的质疑。各大二层针对抗审查提出解决方案,如Force Inclusion机制,允许用户在L1层面强制插入交易,继承抗审查能力。OptimismPortal合约将L1交易转换为L2交易,实现Force Inclusion。Arbitrum和zkSync也有类似机制,但设计复杂且缺乏文档。StarkNet无法实现Force Inclusion,可能是因为其零知识证明系统无法证明失败交易。Rollup需要Force Inclusion机制来绕过Sequencer,但需考虑对Sequencer的影响。

摘要由 Mars AI 生成
本摘要由 Mars AI 模型生成,其生成内容的准确性、完整性还处于迭代更新阶段。

原文作者:NIC Lin

原文来源:极客 Web3

就在昨天发生了一起震惊无数人的事情:由Metamask母公司Consensys推出的以太坊二层Linea主动停机了,官方称这么做的目的是为了降低Velocore黑客攻击事件的影响。而这不由得让人想起之前BSC链(BNB Chain)为了降低黑客攻击的损失,在官方主动协调下停机一事。每当人们谈论起这种事情,都会对Web3倡导的去中心化价值感到怀疑。

Rollup

当然,上述事件发生的核心原因,更多在于基础设施本身的不完善,即不够去中心化:如果一条链足够去中心化,那么就不该说停就停。由于以太坊二层的独特构造,大多数Layer2都依赖于中心化的Sequencer,虽然近些年去中心化排序器的论调越来越多,但考虑到二层的存在目的及其结构,我们大可以认为,Layer2的排序器大概率不会有多去中心化,最后可能还比不上BSC链的去中心化程度。如果事实真的如此,那么我们该怎么办?

其实对于二层而言,排序器不去中心化带来的最直接危害,在于抗审查性和活性。如果处理交易的实体(Sequencer)很少,那么它在是否为你服务这件事上就掌握了绝对权力:想拒绝你就拒绝你,而你可能没有办法。如何解决Layer2的抗审查问题,显然是一个重要的话题。

在过去的数年中,各大以太坊二层针对抗审查问题提出了各种各样的解决方案,比如Loopring和Degate以及StarkEx的强制提款与逃生舱功能、Arbitrum及其他OP Rollup的Force Inclusion功能,这些方法都可以在一定条件下对Sequencer产生制衡,以防止其无端拒绝任意用户的交易请求。

在今天的文章中,来自台北以太坊协会的NIC Lin现身说法,亲自实验了4个主流Rollup的抗审查交易功能,从工作流程和操作方法等方面深入的分析了Force Inclusion的机制设计,这对于以太坊社区和手握巨额资产的大户而言尤其具有参考价值。

Rollup交易审查与Force Inclusion

交易抗审查性(Censorship Resistance)对一条区块链来说非常重要,如果区块链能够任意审查并拒绝用户发起的交易,那就和一个Web2服务器没有两样。以太坊目前的交易抗审查能力来自于它为数众多的Validator,如果有人想审查Bob的交易、不让他的交易上链,要么就尝试买通网络中大部分Validator,要不就Spam整个网路,不断送出手续费比Bob更高的垃圾交易来抢占区块空间。不管是哪种方式,成本都会非常高。

注:在Ethereum目前的PBS架构中,审查交易的成本会降低不少,可以参考配合OFAC审查Tornado Cash交易的区块比例。当前的抗审查能力仰赖在OFAC及政府管辖范围之外的独立验证者及Relay。

但Rollup呢?Rollup不需要一大堆的Validator来确保安全性,即便Rollup只有一个中心化的角色(Sequencer)来产出区块,它也和L1一样安全。但安全和抗审查能力是两回事,即便一个Rollup和以太坊一样安全,但在只有一个中心化Sequencer的情况下,想审查任何用户的交易都行。

RollupSequencer可以拒绝处理用户的交易,导致用户资金被扣留无法离开该Rollup

Force Inclusion机制

与其要求Rollup有大量的去中心化的Sequencer,还不如直接利用L1的抗审查能力:

本来Sequencer就是要将交易数据打包送到L1的Rollup合约中,不如在合约里加入一个设计,让用户可以自行把交易插入到Rollup合约,这个机制就称为“Force Inclusion”。只要Sequencer没办法在L1层面审查用户,它就没法阻止用户在L1强制插入交易。这样一来,Rollup就可以继承L1的抗审查能力。

RollupSequencer无法审查使用者的L1交易,除非付出很高的成本

强制交易应该怎么生效?

如果允许通过Force Inclusion把交易直接写入到Rollup合约中(也就是立即生效),那Rollup的状态就会马上改变,例如Bob透过Force Inclusion机制插入一笔“转1000 DAI给Carol”的交易,如果交易立即生效,那最新的状态中Bob的余额会少1000 DAI,Carol会多1000 DAI。

Rollup如果Force Inclusion能直接把交易写进Rollup合约中并马上生效,那状态就会马上改变

如果此时Sequencer也在链下收集交易,并把下一批交易送到Rollup合约上,就有可能被Bob强制插入并立即生效的交易给影响到。这种问题要极力避免,因此Rollup一般不会让Force Inclusion交易立即生效,而是先让用户把交易插入到L1上的等待队列中,进入“准备中”状态。

Sequencer在把链下交易打包送上Rollup合约时,选择是否在交易序列里塞入前述交易,如果Sequencer一直无视这些处于“准备中”状态的交易,等窗口期结束后,用户可以把这些交易强制插入到Rollup合约中。

RollupSequencer可以决定在什么时候“顺便收入”等待队列中的交易

RollupSequencer还是可以拒绝处理等待队列中的交易

Rollup如果Sequencer长期拒绝,一段时间后任何人都可以通过Force Inclusion功能把交易强行插入到Rollup合约中

接下来我们将依序介绍Optimism、Arbitrum、StarkNet及zkSync等四个较有名的Rollup的Force Inclusion机制实现。

Optimism的Force Inclusion机制

首先介绍Optimism的Deposit流程,这个Deposit不单是指把钱存进Optimism,还包括“把用户向L2发送的信息”送进L2。L2节点在收到新存入的消息后,会将消息转换成一笔L2交易去执行,送到消息指定的接收方。

Rollup使用者从L1 Deposit给L2的消息L1CrossDomainMessenger合约

当一个用户要把ETH或ERC-20代币存进Optimism时,他会通过前端网页和L1上的L1StandardBridge合约互动,指定要存多少金额以及由哪个L2地址接收这些资产。

L1StandardBridge合约会将消息传递至下一层的L1CrossDomainMessenger合约,这个合约主要作为L1与L2之间互相通讯的组件,L1StandardBridge便通过这个通用的通讯组件和L2上的L2StandardBridge交流,决定谁可以在L2铸造代币,或是谁可以从L1解锁代币。

如果开发者需要开发一个在L1与L2之间互通、同步状态的合约,那他就可以搭建在L1CrossDomainMessenger合约之上。

Rollup使用者的消息透过CrossDomainMessenger合约从L1传递到L2

注:本文的部分图片中将CrossDomainMessager写成了CrossChainMessager

OptimismPortal合约

L1CrossDomainMessenger合约会再将消息送至最底层的OptimismPortal合约,OptimismPortal合约处理完后会抛出一个名为TransactionDeposited的事件,参数包含“发消息的人”、“收消息的人”,以及相关的执行参数。

接著L2的Optimism节点会监听OptimismPortal合约抛出的Transaction Deposited事件,并把event里的参数转换为一笔L2交易,这个交易的发起者会是Transaction Deposited事件参数里指明的“发消息的人”,交易接收者就是事件参数里“收消息的人”,其他交易参数也是由上述事件中的参数而来。

RollupL2节点会将OptimismPortalemit的Transaction Deposited事件参数转换成一笔L2交易

例如,这是某个用户透过L1StandardBridge合约存款0.01ETH的交易,这个消息及ETH一路传到OptimismPortal合约(地址是0xbEb5…06Ed),然后几分钟后被转换成L2交易:

消息发起者是L1CrossDomainMessenger合约;接收者是L2上的L2CrossDomainMessenger合约;消息内容是L1StandardBridge收到了BoB的0.01ETH存款。这之后还会触发一些流程,比如为L2StandardBridge增发0.01枚ETH,再由后者转给Bob。

具体怎么触发

当你想把交易强制收纳进Optimism的Rollup合约中时,你要达到的效果是让一笔“从你的L2地址在L2上发起并要执行的交易”能顺利执行,这时你应该用自己的L2地址把消息直接提交给OptimismPortal合约(注意OptimismPortal合约其实在L1上,但OP的地址格式和L1地址格式一致,你直接用和L2账户相同地址的L1账户调用上述合约即可)。

之后该合约抛出的Transaction Deposited事件转化的L2交易的“发起者”,才会是你的L2账户,此时交易格式和正常的L2交易一致。

Rollup从Transaction Deposited事件转换而成的L2交易中,发起人会是Bob自己;接收人是Uniswap合约;而且会附带指定的ETH,就像Bob自己发起L2交易一样

Rollup如果要调用Optimism的Force Inclusion功能,你要直接调用OptimismPortal合约的depositTransaction函数,将你想在L2执行的交易的参数填入

我做了一个简单的Force Inclusion实验,这条交易想达成这样一件事:在L2上用我的地址自转账(0xeDc1…6909),并附带一个“force inclusion”的文字讯息。

这是我透过OptimismPortal合约执行depositTransaction函数的L1交易,可以看到在其抛出的Transaction Deposited事件中,from和to都是我自己

Rollup剩下的opaque Data一栏里的值则编码了“调用deposit Transaction函数的人附带了多少ETH”、“L2交易发起者要把多少ETH发给接收者”、“L2交易GasLimit”及“给L2接收者的Data”等等信息。

将上述信息解码后分别会得到:

“调用deposit Transaction的人附加了多少ETH”:0,因为我并不是从L1存ETH到L2;

“L2交易发起者要把多少ETH发给接收者”:5566(wei)

“L2交易的GasLimit”:50000

“给L2接收者的Data”:0x666f72636520696e636c7573696f6e,也就是“force inclusion”这个字串的16进制编码

接着没多久就出现转换后的L2交易:一笔我转钱给自己的L2交易,金额是5566 wei,Data是“force inclusion”字串。而且可以注意到,在图中倒数第二行的Other Attributes中的TxnType(交易类型),显示是系统交易126(System),表示这笔交易不是我自己在L2发起的,是由L1交易的Deposited事件转换而来。

Rollup转换而成的L2交易

如果你要通过Force Inclusion调用L2合约、发送不同的Data,那无非就是将参数一一填入前面的deposit Transaction函数,只是要记得,要用和自己L2账户相同的L1地址去调用deposit Transaction函数,这样当Deposited Event转化为L2交易时,发起者就是你的L2账户。

SequencerWindow

前面提到的Optimism L2节点将Transaction Deposited事件转换成L2交易,其实这个Optimism节点指的是Sequencer,毕竟这关系到交易排序,所以只有Sequencer可以决定何时要将前述事件转换成L2交易。

在监听到TransactionDeposited事件时,Sequencer并不一定会马上将event转换成L2交易,可以有一段延时,这段时间的最大值称为SequencerWindow。

目前Optimism主网上的Sequencer Window为24小时,也就是当用户从L1存入一笔钱或Force Inclusion一条交易,最糟情况是24小时后才被收入到L2交易历史中。

Arbitrum的Force Inclusion机制

在Optimism中L1的Deposit操作会抛出一个Transaction Deposited事件,剩下的就是等待Sequencer收录上述操作;但在Arbitrum中发生于L1的操作(存钱或传消息给L2等)会被存在L1上的一个队列里,而不是单纯抛出个事件。

Sequencer会被给予一段时间将上述队列里的交易纳入L2交易历史,如果时间到了Sequencer都没有作为,那任何人都可以去替Sequencer完成。

RollupArbitrum会在L1合约维护一个Queue,如果Sequencer没有主动处理Queue里的交易,时间到了任何人都可以把Queue里的交易强制收录到L2交易历史中

Arbitrum的设计中,L1上发生的如存款等操作都要经由Delayed Inbox合约,顾名思义这里的操作都会延迟生效;另一个合约则是Sequencer Inbox,是Sequencer把L2交易上传到L1时的直接场所。每次Sequencer上传L2交易时,都可以顺便从Delayed Inbox取出一些待处理的交易一并写进交易历史中。

RollupSequencer写入新交易时可以顺便从DelayedInbox拿出交易一起写入

复杂的设计以及凡善可陈的参考资料

如果读者直接参考Arbitrum官方关于Sequencer及Force Inclusion的章节,会看到里面提到了Force Inclusion大致如何运作,以及一些参数名称和函数名称:

使用者先去DelayedInbox合约调用sendUnsignedTransaction函数,如果Sequencer没在约24小时内收录,那使用者可以调用SequencerInbox合约的forceInclusion函数。然后Arbitrum官方也没把函数的链接附加在官网文档里,只能自己去看合约代码里相对应的函数。

当找到sendUnsignedTransaction函数后,你发现竟然要自己填nonce值还有maxFeePerGas值。是哪个地址的nonce?是哪个网络上的maxFeePerGas?要怎么填比较好?没有文件参考,连Natpsec都没有。然后你还会在Arbitrum合约里发现一堆看着相似的函数:

sendL1FundedUnsignedTransaction、sendUnsignedTransactionToFork、sendContractTransaction、sendL1FundedContractTransaction,一样没有文件告诉你这些函数的区别、该怎么用、参数该怎么填,连Natpsec都没有。

Rollup

你抱著姑且一试的心态来试填参数并送出交易,想用试错的方式看能不能找出正确的用法,但发现这些函数全都会把你的L1地址做AddressAliasing,导致最终在L2上发起交易时的Sender根本是不一样的地址,于是你的L2地址一动不动。

sendL2Message

后来偶然点开Google搜索,才发现原来Arbitrum自己有一个Tutorial程式库,裡面有脚本示范怎么从L1发送L2交易(也就是Force Inclusion的意思),然后它列举的函数完全不是上面提到的任何一个,而是一个叫sendL2Message的函数,而且message参数要带入的竟然是用L2账户签完名的交易?

谁会知道要“通过Force Inclusion送给L2的消息”竟然会是一笔“签完名的L2交易”?而且没有任何文件及Natspec解释什么时候用及如何使用这个函数。

Rollup

结论:要手动产生一个Arbitrum的强制交易比较麻烦,建议就照著官方Tutorial跑Arbitrum SDK呗。Arbitrum不像其他Rollup有清楚的开发者文件及程式码附注,许多函数的用途和参数缺乏说明,导致开发者得花费比预期多更多的时间来接入和使用。我也在Arbitrum Discord上询问Arbitrum的人,但并没有得到令人满意的答案。

在Discord上询问,对方也只会叫我去看sendL2Message,没有想要解释其他函数的功能(甚至是Force Inclusion文档里提到的sendUnsignedTransaction)是什么用途、怎么用、什么时候用。

StarkNet的ForceInclusion机制

很遗憾地,StarkNet目前还没有ForceInclusion机制。只有两篇在官方论坛上讨论到Censorship及ForceInclusion的文章。

无法证明失败的交易

上述原因其实是因为,StarkNet的零知识证明系统没办法证明一笔失败的交易,所以不能允许Force Inclusion。因为如果有人恶意(或无意)Force Include一笔失败的、无法被证明的交易,那StarkNet就会直接卡住:因为交易被强制收入后,Prover就必须证明该笔失败交易,但它却没办法证明。

而StarkNet预期在v0.15.0版引入证明失败交易的功能,之后应该就可以进一步实现Force Inclusion机制。

zkSync的ForceInclusion机制

zkSync的L1->L2讯息传送以及Force Inclusion机制,都是透过MailBox合约的requestL2Transaction函数进行,使用者指定L2地址、calldata、附加的ETH数量、L2GasLimit值等,requestL2Transaction会将这些参数组合成一个L2交易,然后放进优先队列(PriorityQueue)中,Sequencer会在交易打包上传到L1时(通过commitBatches函数),说明要顺便从优先队列中拿出多少笔交易一起收录进L2交易记录中。

zkSync在Force Inclusion形式上和Optimism很像,都是以发起者的L2地址(与L1地址一致)去调用相关函数,并填入资料(被呼叫者、calldata等等),而不是像Arbitrum一样是填一笔签完名的L2交易;但在设计上则是和Arbitrum一样,都是在L1维护一个队列Queue,并由Sequencer从Queue中拿出用户直接提交的待处理交易,并写入交易历史中。

Rollup

如果你透过zkSync的官方桥去Deposit ETH,像是这笔交易,它便是去呼叫MailBox合约的requestL2Transaction函数,它会将这个Deposit ETH的L2交易放进优先队列中抛出一个NewPriorityRequest事件。因为合约把L2交易资料编码成一串bytes字串所以不易读,改成看这笔L1交易的参数的话,会看到参数中L2的接收方也是交易的发起人(因为是Deposit给自己),所以过一阵子这笔L2交易被Sequeuncer从优先队列拿出,并收录进交易历史时,它会在L2上被转换成一笔自己转给自己的交易,而转帐的金额就是交易发起人在L1的Deposit ETH交易中带上的ETH金额。

Rollup

L1Deposit交易中,交易发起者和接收者都是0xeDc1…6909,金额是0.03ETH,calldata为空

Rollup

L2上会出现一笔0xeDc1…6909自己转帐给自己的交易,交易类型(TxnType)是255,也就是系统交易接着我直接像之前实验OP的强制交易功能一样,调用zkSync的requestL2Transaction函数,发了一笔自转账:没有带任何ETH,calldata带入“force inclusion”字串的HEX编码。接著它被转换成L2上一笔自己转自己的交易,calldata裡是“force inclusion”的十六进制字串:0x666f72636520696e636c7573696f6e。

Rollup

当Sequencer把交易从PriorityQueue拿出来并写进交易历史中,在L2上就会转换成相对应的L2交易

透过requestL2Transaction函式,使用者可以用和L2地址一样的L1账户,在L1提交资料,指定L2接收方、附带的ETH金额以及calldata。如果使用者要call其他合约、带不同Data,那一样就是将参数一一填入requestL2Transaction函数。

还没有让使用者强制收录的功能

虽然L2交易放到优先队列中后,会顺便计算出这笔L2交易被Sequencer收录的等待期限,但目前zkSync设计中并没有让使用者能强制执行的Force Inclusion函数,等于是只做半套。也就是虽然有“收录等待期限”,但实际上还是“看Sequencer要不要收入”:Sequencer可以等到过期后才收入,也可以永远不再收入优先队列中任何交易。

未来zkSync应该要加入相关函数,让使用者可以在收入有效期过了但都还没被Sequeuncer收录时,能强制把交易包含进L2交易历史,如此才是真正有效的Force Inclusion机制。

总结

L1靠为数众多的验证者们来确保网路的“安全性”及“抗审查能力”,Rollup因为都是由少数甚至单一的Sequencer来写入交易,抗审查能力更弱。因此Rollup需要有Force Inclusion机制来让使用者可以绕过Sequencer,将交易写入历史中,避免被Sequencer审查导致无法使用也无法把资金撤离该Rollup。

Force Inclusion让使用者可以强制将交易写入历史中,但在设计上需在“交易是否能立即插入历史、立即生效”上做选择。如果允许交易立即生效,那就会对Sequencer产生负面影响,因为L2上等待被收入的交易都可能会被L1强制收入的交易所影响。

因此目前Rollup的Force Inclusion机制都会先让L1上插入的交易进入等待状态,并让Sequencer有一段时间窗口来反应、来选择要不要收入这些等待中的交易。

zkSync和Arbitrum都是在L1维护一个队列Queue,用来管理使用者从L1送出的L2交易或给L2的讯息。Arbitrum称为DelayedInbox;zkSync称为PriorityQueue

zkSync送出L2交易的方式和Optimism比较像,都是以L2地址去L1上发送消息,如此转换为L2交易后,其发起人才会是该L2地址。Optimism送L2交易的函数称为depositTransaction;zkSync称为requestL2Transaction。而Arbitrum则是生成一笔完整的L2交易并签名,然后透过sendL2Message函数送出,Arbitrum在L2上会透过签名还原签名者来作为L2交易的发起人。

StarkNet目前还没有Force Inclusion机制;zkSync则是像做了半套的Force Inclusion,—有PriorityQueue且每个Queue裡的L2交易都有收录有效期限,但这个有效期限目前只是装饰用,实际上Sequencer可以选择完全不收入任何PriorityQueue裡的L2交易

声明:本文为入驻“MarsBit 专栏”作者作品,不代表MarsBit官方立场。
转载请联系网页底部:内容合作栏目,邮件进行授权。授权后转载时请注明出处、作者和本文链接。未经许可擅自转载本站文章,将追究相关法律责任,侵权必究。
提示:投资有风险,入市须谨慎,本资讯不作为投资理财建议。
免责声明:本文不构成投资建议,用户应考虑本文中的任何意见、观点或结论是否符合其特定状况,及遵守所在国家和地区的相关法律法规。