从理论到实践:解析以太坊Rollup实现抗审查交易的机制
本文实验了4个主流Rollup的抗审查交易功能,从工作流程和操作方法等方面深入的分析了Force Inclusion的机制设计,这对于以太坊社区和手握巨额资产的大户而言尤其具有参考价值。
作者:NIC Lin,Taipei Ethereum Meetup负责人
原文标题:《Rollup的Force Inclusion機制介紹》
就在昨天发生了一起震惊无数人的事情:由Metamask母公司Consensys推出的以太坊二层Linea主动停机了,官方称这么做的目的是为了降低Velocore黑客攻击事件的影响。而这不由得让人想起之前BSC链(BNB Chain)为了降低黑客攻击的损失,在官方主动协调下停机一事。每当人们谈论起这种事情,都会对Web3倡导的去中心化价值感到怀疑。
当然,上述事件发生的核心原因,更多在于基础设施本身的不完善,即不够去中心化:如果一条链足够去中心化,那么就不该说停就停。由于以太坊二层的独特构造,大多数Layer2都依赖于中心化的Sequencer,虽然近些年去中心化排序器的论调越来越多,但考虑到二层的存在目的及其结构,我们大可以认为,Layer2的排序器大概率不会有多去中心化,最后可能还比不上BSC链的去中心化程度。如果事实真的如此,那么我们该怎么办?
其实对于二层而言,排序器不去中心化带来的最直接危害,在于抗审查性和活性。如果处理交易的实体(Sequencer)很少,那么它在是否为你服务这件事上就掌握了绝对权力:想拒绝你就拒绝你,而你可能没有办法。如何解决Layer2的抗审查问题,显然是一个重要的话题。
在过去的数年中,各大以太坊二层针对抗审查问题提出了各种各样的解决方案,比如Loopring和Degate以及StarkEx的强制提款与逃生舱功能、Arbitrum及其他OP Rollup的Force Inclusion功能,这些方法都可以在一定条件下对Sequencer产生制衡,以防止其无端拒绝任意用户的交易请求。
在今天的文章中,来自台北以太坊协会的NIC Lin现身说法,亲自实验了4个主流Rollup的抗审查交易功能,从工作流程和操作方法等方面深入的分析了Force Inclusion的机制设计,这对于以太坊社区和手握巨额资产的大户而言尤其具有参考价值。
交易审查与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的情况下,想审查任何用户的交易都行。
Force Inclusion机制
与其要求Rollup有大量的去中心化的Sequencer,还不如直接利用L1的抗审查能力:
本来Sequencer就是要将交易数据打包送到L1的Rollup合约中,不如在合约里加入一个设计,让用户可以自行把交易插入到Rollup合约,这个机制就称为“Force Inclusion”。只要Sequencer没办法在L1层面审查用户,它就没法阻止用户在L1强制插入交易。这样一来,Rollup就可以继承L1的抗审查能力。
强制交易应该怎么生效?
如果允许通过Force Inclusion把交易直接写入到Rollup合约中(也就是立即生效),那Rollup的状态就会马上改变,例如Bob透过Force Inclusion机制插入一笔“转1000 DAI给Carol”的交易,如果交易立即生效,那最新的状态中Bob的余额会少1000 DAI,Carol会多1000 DAI。
如果此时Sequencer也在链下收集交易,并把下一批交易送到Rollup合约上,就有可能被Bob强制插入并立即生效的交易给影响到。这种问题要极力避免,因此Rollup一般不会让Force Inclusion交易立即生效,而是先让用户把交易插入到L1上的等待队列中,进入“准备中”状态。
Sequencer在把链下交易打包送上Rollup合约时,选择是否在交易序列里塞入前述交易,如果Sequencer一直无视这些处于“准备中”状态的交易,等窗口期结束后,用户可以把这些交易强制插入到Rollup合约中。
接下来我们将依序介绍Optimism、Arbitrum、StarkNet及zkSync等四个较有名的Rollup的Force Inclusion机制实现。
Optimism的Force Inclusion机制
首先介绍Optimism的Deposit流程,这个Deposit不单是指把钱存进Optimism,还包括“把用户向L2发送的信息”送进L2。L2节点在收到新存入的消息后,会将消息转换成一笔L2交易去执行,送到消息指定的接收方。
L1CrossDomainMessenger合约
当一个用户要把ETH或ERC-20代币存进Optimism时,他会通过前端网页和L1上的L1StandardBridge合约互动,指定要存多少金额以及由哪个L2地址接收这些资产。
L1StandardBridge合约会将消息传递至下一层的L1CrossDomainMessenger合约,这个合约主要作为L1与L2之间互相通讯的组件,L1StandardBridge便通过这个通用的通讯组件和L2上的L2StandardBridge交流,决定谁可以在L2铸造代币,或是谁可以从L1解锁代币。
如果开发者需要开发一个在L1与L2之间互通、同步状态的合约,那他就可以搭建在L1CrossDomainMessenger合约之上。
注:本文的部分图片中将CrossDomainMessager写成了CrossChainMessager
OptimismPortal合约
L1CrossDomainMessenger合约会再将消息送至最底层的OptimismPortal合约,OptimismPortal合约处理完后会抛出一个名为TransactionDeposited的事件,参数包含“发消息的人”、“收消息的人”,以及相关的执行参数。
接著L2的Optimism节点会监听OptimismPortal合约抛出的Transaction Deposited事件,并把event里的参数转换为一笔L2交易,这个交易的发起者会是Transaction Deposited事件参数里指明的“发消息的人”,交易接收者就是事件参数里“收消息的人”,其他交易参数也是由上述事件中的参数而来。
例如,这是某个用户透过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交易一致。
我做了一个简单的Force Inclusion实验,这条交易想达成这样一件事:在L2上用我的地址自转账(0xeDc1…6909),并附带一个“force inclusion”的文字讯息。
这是我透过OptimismPortal合约执行depositTransaction函数的L1交易,可以看到在其抛出的Transaction Deposited事件中,from和to都是我自己
剩下的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事件转换而来。
如果你要通过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完成。
Arbitrum的设计中,L1上发生的如存款等操作都要经由Delayed Inbox合约,顾名思义这里的操作都会延迟生效;另一个合约则是Sequencer Inbox,是Sequencer把L2交易上传到L1时的直接场所。每次Sequencer上传L2交易时,都可以顺便从Delayed Inbox取出一些待处理的交易一并写进交易历史中。
复杂的设计以及凡善可陈的参考资料
如果读者直接参考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都没有。
你抱著姑且一试的心态来试填参数并送出交易,想用试错的方式看能不能找出正确的用法,但发现这些函数全都会把你的L1地址做AddressAliasing,导致最终在L2上发起交易时的Sender根本是不一样的地址,于是你的L2地址一动不动。
sendL2Message
后来偶然点开Google搜索,才发现原来Arbitrum自己有一个Tutorial程式库,裡面有脚本示范怎么从L1发送L2交易(也就是Force Inclusion的意思),然后它列举的函数完全不是上面提到的任何一个,而是一个叫sendL2Message的函数,而且message参数要带入的竟然是用L2账户签完名的交易?
谁会知道要“通过Force Inclusion送给L2的消息”竟然会是一笔“签完名的L2交易”?而且没有任何文件及Natspec解释什么时候用及如何使用这个函数。
结论:要手动产生一个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中拿出用户直接提交的待处理交易,并写入交易历史中。
如果你透过zkSync的官方桥去Deposit ETH,像是这笔交易,它便是去呼叫MailBox合约的requestL2Transaction函数,它会将这个Deposit ETH的L2交易放进优先队列中抛出一个NewPriorityRequest事件。因为合约把L2交易资料编码成一串bytes字串所以不易读,改成看这笔L1交易的参数的话,会看到参数中L2的接收方也是交易的发起人(因为是Deposit给自己),所以过一阵子这笔L2交易被Sequeuncer从优先队列拿出,并收录进交易历史时,它会在L2上被转换成一笔自己转给自己的交易,而转帐的金额就是交易发起人在L1的Deposit ETH交易中带上的ETH金额。
L1Deposit交易中,交易发起者和接收者都是0xeDc1…6909,金额是0.03ETH,calldata为空
接着我直接像之前实验OP的强制交易功能一样,调用zkSync的requestL2Transaction函数,发了一笔自转账:没有带任何ETH,calldata带入“force inclusion”字串的HEX编码。
接著它被转换成L2上一笔自己转自己的交易,calldata裡是“force inclusion”的十六进制字串:0x666f72636520696e636c7573696f6e。
透过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交易
免责声明:文章中的所有内容仅代表作者的观点,与本平台无关。用户不应以本文作为投资决策的参考。
你也可能喜欢
![](https://img.bitgetimg.com/multiLang/web/7496f6d592d0a4078897d1753b46c935.webp)
中国证监会原主席肖钢畅谈 Web3:RWA 是金融回归本源的生动实践
Web3 的发展可以为做好五篇大文章提供有力的支撑,推动金融服务实体经济的发展
速览获 Amber Group、Polygon 等投资的 AI+DePIN 项目 EMC
8 月 16 日,EMC Layer 1 区块链测试网正式启动,用户可通过“挖矿”获得 EMC 代币。
![](https://img.bitgetimg.com/multiLang/web/04432831a9e272d10f2bcaf34b40b54c.jpeg)