抗审查交易如何强制上链？SkyNet与强制上链的逻辑

链上世界有一个被反复提起却很少被真正拆开讨论的问题：当一笔交易被矿工、验证者或排序器有意忽略时，它还能不能上链？这不是一个纯技术问题，而是公链叙事里最核心的政治经济学问题。抗审查从来不是一句口号，它需要具体的机制来兜底。最近围绕 SkyNet 这类“强制上链”基础设施的讨论升温，恰好把这个老问题重新推到了台前。我想借这个机会，把强制上链的逻辑从头到尾捋一遍，看看它到底靠什么成立，又在哪里露出破绽。

抗审查到底在抗什么

先把概念拆清楚。抗审查不是“没有人能阻止我发交易”，而是“即使有人想阻止，我仍然有一条可走的路”。这两句话差别很大。前者是理想，后者是工程目标。公链的抗审查能力，本质上取决于是否存在一条不依赖单一中介的替代路径。

审查发生的层次比大多数人想象的要多。最表层是 RPC 层，你的交易根本没进内存池；往下一层是内存池策略，节点按手续费或地址黑名单过滤；再往上是区块构建者，他们决定哪些交易进入区块；最顶层是共识层，如果多数验证者达成一致要排除某类交易，那问题就变成了社会共识层面的对抗。

不同层次的审查，需要不同的破解手段。RPC 层被卡，换个节点就行；内存池被过滤，可以直接把交易塞给矿工或构建者；构建者联合抵制，就需要绕过他们的通道；共识层对抗，那基本只能靠分叉或社会协调。强制上链要解决的，主要是中间那几层——构建者和排序器的选择性忽略。

强制上链的几种经典路径

直接广播与私有通道

最朴素的办法是把交易直接发给区块生产者。以太坊的 proposer-builder separation 之后，这条路变成了发给 builder 或通过 MEV-Boost 的中继。问题在于，如果 builder 本身参与审查，私有通道也就失效了。所以这条路只能解决“公开内存池被过滤”的问题，解决不了“构建者主动抵制”。

链上强制包含机制

这是更硬核的一层。思路是：在协议或合约层面规定，某类交易必须在限定时间内被打包，否则触发惩罚或降级。ERC-4337 的 bundler 体系里已经有类似的讨论，账户抽象让“交易意图”可以绕过传统的内存池路径。更激进的设计是把“包含权”做成一种可验证的承诺，构建者如果不履行，会被罚没质押。

这类机制的关键在于可验证性。你怎么证明一笔交易“本可以被包含却没有被包含”？这需要一套时间戳和状态证明的体系，否则惩罚无从谈起。

强制上链的极端形式：escape hatch

当常规通道全部失效时，最后的兜底是“逃生舱”。比如某些 L2 设计的 forced inclusion 机制：用户可以把交易直接发到 L1 的合约里，L2 的排序器如果在规定时间内不处理，L1 合约就允许用户单方面推进状态。Optimism 和 Arbitrum 都有类似设计，虽然实际触发次数极少，但它的存在本身就是一种威慑。

这类机制的逻辑很清晰：不依赖你好心，而是让你不处理的成本高于处理。排序器可以不打包，但代价是状态被强制推进，它失去对排序的控制权。这是一种用“退出权”换“包含权”的设计。

SkyNet 在这套逻辑里站在哪

SkyNet 这类项目的定位，通常落在“构建者与用户之间的中立通道”上。它的核心主张是：交易不应该只依赖少数几个构建者的善意，而应该有一条可验证、可追责的强制包含路径。

从公开的设计思路看，SkyNet 试图做几件事。一是把交易广播和区块构建解耦，让交易在进入构建者视野之前就获得某种“包含承诺”。二是引入可验证的包含证明，让“被忽略”这件事变得可举证。三是通过经济惩罚约束构建者的选择性行为。

这套逻辑成立的前提有三个。第一，承诺必须可验证，不能是口头保证。第二，惩罚必须可执行，质押和罚没要真能落地。第三，逃生路径必须独立于被审查的通道，否则就是循环论证。第三点最容易被忽略，也最致命——如果你的强制上链通道本身依赖被审查的构建者，那它只是个摆设。

强制上链的真实难点

可验证性的成本

证明“一笔交易被无理忽略”在技术上并不轻松。你需要证明交易在某个时间点已经有效可用，且构建者有能力和机会包含它。这涉及到时间戳的可信度、状态的一致性、以及构建者能力的界定。门槛设得太低，惩罚会被滥用；设得太高，机制形同虚设。

经济博弈的脆弱性

强制包含靠的是“不包含的代价大于包含的成本”。但如果审查者愿意承担这个代价呢？如果审查的动机足够强，罚没就成了可以接受的成本。这时候机制就从“阻止审查”退化成“给审查定价”。这是所有经济约束型方案的共同软肋。

逃生舱的中心化悖论

逃生舱要求有一条独立于主通道的路径。但这条路径本身由谁维护？如果由同一批验证者维护，独立性就是假的；如果由另一批人维护，那又引入了新的信任假设。L2 的 forced inclusion 之所以能成立，是因为 L1 本身足够去中心化。对于 L1 层面的强制上链，这个“更底层”的依托在哪里，是个绕不开的问题。

强制上链不是万能药

有必要泼一盆冷水。强制上链解决的是“交易能否进入区块”，解决不了“交易进入区块后是否被正确处理”。它可以对抗排序器的选择性忽略，但对抗不了共识层的系统性排斥。当审查来自多数共识时，强制上链机制本身也会被多数改写。

所以它的定位应该是：提高审查的成本和可见性，而不是消灭审查。一个健康的公链生态，需要的是多层防御——RPC 多样性、内存池开放、构建者竞争、强制包含兜底、以及最终的社会层协调。任何单一机制被当成银弹，都会在真实对抗中露馅。

SkyNet 这类项目的价值，不在于它承诺了一个无审查的乌托邦，而在于它把“包含权”从一个模糊的期望，变成了一个有约束、可追责的工程问题。这个转向本身就有意义。至于它能不能在真实的经济博弈里站住脚，要看它的可验证性做得够不够硬，逃生路径够不够独立，以及罚没机制能不能真的让审查者疼。

抗审查从来不是靠宣言实现的，是靠一层层可验证的约束堆出来的。强制上链是其中一块砖，重要，但不是全部。看清它站在哪、能扛多少、在哪里会裂，比盲目相信它更有价值。