绕开排序器的门：ZKsync 优先队列怎么强制你的交易上二层

排序器不听话时，用户还有一条路

Layer2 的正常交易路径是：用户把交易发给运营方的排序器，由它装入批次再提交到 L1。一旦排序器拒收、拖延或干脆罢工，用户有没有绕开它的办法？ZKsync 的官方回答是优先队列（priority queue）：任何用户都可以直接从 L1 发起一笔要在 L2 执行的操作，把它塞进一条公开队列，让运营方不得不处理。理解这条通道，比背一句抗审查口号有用得多——它贵在哪、慢在哪、谁有权装入，全在机制细节里。

L1 上发起的两种交易

官方文档把在 L1 发起的交易分成两类：priority operation，任何用户都能创建；升级交易，只在系统升级窗口内可创建。发起的入口是 BridgeHub 合约上的两个方法：requestL2TransactionDirect 与 requestL2TransactionTwoBridges。两者的差别被文档写得很直白：前者在 L2 侧看到的发送者就是你自己在 L1 的发送地址，后者的发送者则是请求中指定的第二座桥——多一段桥接适配，换来经由其他通道转入的能力。BridgeHub 收到请求后把资金转往共享桥，再把交易请求转给由 chainID 指定的 ZKsync Chain 合约。

入队前的检查与队列的消费方式

ZKsync Chain 合约在受理时会做两项检查：这笔交易是否可处理、提供的费用是否足以补偿运营方，通过后交易才被追加进优先队列。运营方看到队列里的优先交易后，把它装进批次执行。账户抽象环节在这条路径上被有意跳过：普通 L2 交易要靠签名证明所有权，而来自 L1 的交易，其发送者身份由 L1 合约的调用上下文保证——所以你在区块浏览器里会看到，从 L1 发起的 L2 交易，其发送者直接显示为 L1 地址。这套设计让充币、触发合约、紧急提现都能借同一条通道完成。

抗审查是真的，但有两段延迟与一段费用

抗审查叙事常被简化成进了队就一定会被执行，实际情况要拆两段看。入队这一步发生在 L1：只要交易被以太坊收录，它就进了队列，排序器无法把它从队里删掉；执行这一步却仍要等运营方把它装进批次。官方文档强调，优先交易与批次的对应关系会被逐笔验证——装批时按队列顶部的顺序弹出对应数量的优先交易并核对哈希链，运营方不能悄悄调包或插一笔假的进来。但何时装、装多快，取决于运营方的批次节奏；而在 L1 发起的 gas 成本由以太坊行情决定。优先队列因此更像一扇防爆门：正常时没人愿意走它，因为它比 L2 直发贵得多；门后确有权力逼运营方处理你的交易，只是时间要按两层的节拍来算。实操上还要注意身份形态的差别：走这条通道后，L2 上那笔交易的发送者由 L1 调用上下文决定，与从 L2 钱包直发的签名交易不共享同一套账户抽象校验，合约如果把发送者当作普通 L2 账户来对待，行为可能与预期不同。

滚动哈希与升级通道的历史课

官方文档还记录了一个防篡改细节的演化。早期系统把每笔优先交易的哈希通过系统日志发布到 L1、由 L1 计算滚动哈希，只要有一个哈希不对，整条就对不上；现行系统在 L2 内计算滚动哈希，文档明确担心虚拟机里哈希实现本身被改掉时整个值可被恶意构造，因此升级通道也改了设计——新架构中，升级不再以优先交易的形式从 L1 塞进队列。对用户的含义：队列里交易的顺序与内容可被核对，审查与篡改被分在两个层面处理。Atlas 时代多链共用 BridgeHub 入口，入队按 chainID 指向具体链，别把 A 链的入队当成 B 链的到账。

风险提示：本文为机制说明，不构成投资建议；合约接口与优先队列行为随 ZKsync 版本演进，L1 费用随行情波动，操作前请以 ZKsync 官方文档为准。