昨天，加密货币社区被一则突发消息震惊：由Metamask母公司Consensys推出的以太坊二层网络Linea突然主动停机。官方解释这一举措是为了应对Velocore黑客攻击事件，这不禁让人联想到此前BSC链（BNB Chain）也曾为减轻黑客攻击损失而主动协调停机的事件。这类事件的发生，总让人对Web3所倡导的去中心化理念产生质疑。
这些事件的核心原因，往往在于基础设施本身的不完善，特别是去中心化程度不足。一个真正去中心化的区块链网络，不应该出现”说停就停”的情况。由于以太坊二层的特殊架构，大多数Layer2都依赖于中心化的Sequencer。虽然近年来关于去中心化排序器的讨论越来越多，但考虑到Layer2的设计初衷和架构特点，其排序器很可能难以实现高度去中心化，甚至可能还不如BSC链的去中心化程度。面对这种情况，我们需要思考的是：如何应对？对于Layer2而言，排序器中心化带来的最直接风险就是抗审查性和网络活性问题。当处理交易的实体（Sequencer）数量过少时，它就能单方面决定是否为你提供服务：它可以随意拒绝你的交易请求，而你却可能束手无策。
在过去的几年里，各大以太坊二层网络针对抗审查问题提出了多种解决方案。比如Loopring、Degate和StarkEx采用的强制提款与逃生舱功能，以及Arbitrum等OP Rollup的Force Inclusion功能。这些机制都能在一定程度上对Sequencer形成制衡，防止其无故拒绝用户的交易请求。在今天的文章中，来自台北以太坊协会的NIC Lin将亲自测试四个主流Rollup的抗审查交易功能，从工作流程和操作方式等角度深入分析Force Inclusion的机制设计，这对以太坊社区和持有大量加密资产的大户来说具有重要参考价值。
交易审查与Force Inclusion
交易抗审查性（Censorship Resistance）对区块链而言至关重要。如果一条区块链可以随意审查并拒绝用户发起的交易，那它与传统的Web2服务器就没有本质区别。以太坊目前的抗审查能力来源于其数量众多的验证者。如果有人想审查Bob的交易，阻止其上链，要么需要收买网络中大部分验证者，要么需要发送大量手续费更高的垃圾交易来抢占区块空间。无论哪种方式，成本都极其高昂。
需要注意的是，在以太坊目前的PBS架构中，审查交易的成本有所降低。当前的抗审查能力主要依赖于OFAC及政府管辖范围之外的独立验证者和Relay。
但Rollup的情况有所不同。Rollup不需要大量验证者来确保安全性，即便只有一个中心化的Sequencer负责生成区块，其安全性也能与L1相当。然而，安全性和抗审查能力是两个不同的概念。即使一个Rollup与以太坊一样安全，但在只有一个中心化Sequencer的情况下，它可以轻易审查任何用户的交易。
Sequencer可以拒绝处理用户交易，导致用户资金被困在Rollup中无法转出
Force Inclusion机制
与其要求Rollup拥有大量去中心化的Sequencer，不如直接利用L1的抗审查能力：既然Sequencer需要将交易数据打包发送到L1的Rollup合约中，不妨在合约中设计一个机制，允许用户自行将交易插入Rollup合约，这就是所谓的”Force Inclusion”机制。只要Sequencer无法在L1层面审查用户，就无法阻止用户在L1强制插入交易。这样，Rollup就能继承L1的抗审查能力。
Sequencer无法审查用户的L1交易，除非付出极高成本
强制交易应该如何生效？如果允许通过Force Inclusion直接将交易写入Rollup合约并立即生效，Rollup的状态就会立即改变。例如，Bob通过Force Inclusion机制插入一笔”转1000 DAI给Carol”的交易，如果立即生效，最新状态中Bob的余额将减少1000 DAI，而Carol的余额将增加1000 DAI。
如果Force Inclusion能直接将交易写入Rollup合约并立即生效，状态就会立即改变。此时如果Sequencer也在链下收集交易，并将下一批交易发送到Rollup合约，就可能被Bob强制插入的交易影响。为避免这种情况，Rollup通常不会让Force Inclusion交易立即生效，而是先让用户将交易插入L1上的等待队列，进入”准备中”状态。Sequencer在打包链下交易时，可以选择是否包含这些等待中的交易。如果Sequencer一直无视这些交易，在窗口期结束后，用户可以强制将这些交易插入Rollup合约。
Sequencer可以决定何时”顺便收入”等待队列中的交易
Sequencer仍可以拒绝处理等待队列中的交易
如果Sequencer长期拒绝，一段时间后任何人都可以通过Force Inclusion功能将交易强制插入Rollup合约。接下来，我们将依次介绍Optimism、Arbitrum、StarkNet和zkSync这四个知名Rollup的Force Inclusion机制实现。
Optimism的Force Inclusion机制
首先介绍Optimism的Deposit流程。这里的Deposit不仅指将资金存入Optimism，还包括”将用户发送给L2的信息”传递到L2。L2节点在收到新存入的消息后，会将其转换为一笔L2交易执行，并发送给消息指定的接收方。
用户从L1 Deposit给L2的消息
L1CrossDomainMessenger合约
当用户要将ETH或ERC-20代币存入Optimism时，会通过前端网页与L1上的L1StandardBridge合约交互，指定存入金额和接收资产的L2地址。L1StandardBridge合约会将消息传递给下一层的L1CrossDomainMessenger合约，该合约作为L1与L2之间的通用通信组件。L1StandardBridge通过这个组件与L2上的L2StandardBridge通信，决定谁可以在L2铸造代币，或谁可以从L1解锁代币。开发者如果需要开发在L1与L2之间互通、同步状态的合约，可以基于L1CrossDomainMessenger合约构建。
用户消息通过CrossDomainMessenger合约从L1传递到L2
注：本文部分图片中将CrossDomainMessager误写为CrossChainMessager
OptimismPortal合约
L1CrossDomainMessenger合约会进一步将消息发送至最底层的OptimismPortal合约。OptimismPortal合约处理完成后会触发名为TransactionDeposited的事件，参数包含”消息发送者”、”消息接收者”及相关执行参数。随后，L2的Optimism节点会监听OptimismPortal合约触发的Transaction Deposited事件，并将事件参数转换为一笔L2交易。这笔交易的发起者是事件参数中指定的”消息发送者”，接收者是事件参数中的”消息接收者”，其他交易参数也来自事件参数。
L2节点将OptimismPortal触发的Transaction Deposited事件参数转换为L2交易
例如，这是某用户通过L1StandardBridge合约存入0.01ETH的交易。该消息和ETH最终传递到OptimismPortal合约（地址0xbEb5…06Ed），几分钟后被转换为L2交易：消息发起者是L1CrossDomainMessenger合约；接收者是L2上的L2CrossDomainMessenger合约；消息内容是L1StandardBridge收到BoB的0.01ETH存款。随后还会触发一系列流程，如为L2StandardBridge增发0.01枚ETH，再由后者转给Bob。
具体触发方式
当你想通过Force Inclusion将交易纳入Optimism的Rollup合约时，目的是让一笔”从你的L2地址发起并在L2执行的交易”能够顺利执行。这时，你应该用自己的L2地址直接将消息提交给OptimismPortal合约（注意OptimismPortal合约实际上在L1上，但OP的地址格式与L1地址一致，你可以直接使用与L2账户相同地址的L1账户调用该合约）。之后，该合约触发的Transaction Deposited事件转换的L2交易的”发起者”就会是你的L2账户，此时交易格式与正常的L2交易一致。
从Transaction Deposited事件转换的L2交易中，发起人是Bob自己；接收人是Uniswap合约；并附带指定数量的ETH，就像Bob自己发起的L2交易一样
如果要调用Optimism的Force Inclusion功能，需要直接调用OptimismPortal合约的depositTransaction函数，并填入你想在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事件转换而来。
转换后的L2交易
如果你想通过Force Inclusion调用L2合约、发送不同的Data，只需将相应参数填入前面的deposit Transaction函数。但要记住，必须使用与L2账户相同地址的L1账户调用deposit Transaction函数，这样Deposited Event转换的L2交易的发起者才会是你的L2账户。
SequencerWindow
前面提到的Optimism L2节点将Transaction Deposited事件转换为L2交易，实际上这个节点指的是Sequencer，因为这涉及交易排序，只有Sequencer能决定何时将事件转换为L2交易。Sequencer监听到TransactionDeposited事件后，不一定会立即将其转换为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合约维护一个Queue，如果Sequencer不主动处理Queue中的交易，时间到期后任何人都可以强制将交易收录到L2交易历史中
在Arbitrum的设计中，L1上的存款等操作都需要通过Delayed Inbox合约处理，顾名思义这些操作都会延迟生效；另一个合约是Sequencer Inbox，这是Sequencer将L2交易上传到L1的直接场所。每次Sequencer上传L2交易时，都可以顺便从Delayed Inbox取出一些待处理交易一并写入交易历史。
Sequencer写入新交易时可以顺便从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注释都没有。
抱着试一试的心态填写参数并发送交易，试图通过试错找出正确用法，却发现这些函数都会对你的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上询问相关人员，但未获得令人满意的答案。在Discord上询问时，对方只会让我去看sendL2Message，不愿解释其他函数（甚至是Force Inclusion文档中提到的sendUnsignedTransaction）的用途、使用方法和适用场景。
StarkNet的ForceInclusion机制</h2
声明：文章不代表CHAINTT观点及立场，不构成本平台任何投资建议。投资决策需建立在独立思考之上，本文内容仅供参考，风险
自担！转载请注明出处：https://www.chaintt.cn/14233.html
声明：文章不代表CHAINTT观点及立场，不构成本平台任何投资建议。投资决策需建立在独立思考之上，本文内容仅供参考，风险 自担！转载请注明出处：https://www.chaintt.cn/14233.html
