在协议中融入抗审查：谁来决定以太坊交易的链上确认？

正文：

在区块链领域，“抗审查”这一术语时常被提及。

许多人可能会将其视为一种带有政治色彩或无政府主义倾向的口号，但对于以太坊这一全球用户可接入的结算网络而言，抗审查更应被理解为一种明确的技术能力，而非单纯的政治立场。

假设你在 imToken 钱包中发起了一笔交易。

尽管签名正确、账户余额充足、Gas费用也合理，但交易却未能及时写入区块，钱包状态始终显示为“待处理”，而其他费用相近甚至更低的交易却陆续上链。

这时，我们就不得不思考：到底是谁有权决定一笔交易能否被纳入区块？如果以太坊仍需依赖少数中心化参与者来决定哪些交易上链，那么它与传统金融系统之间的区别就微乎其微。

因此，以太坊近年来探索了 FOCIL、FairFIL 等抗审查机制，旨在解答一个看似简单但极为重要的问题：如何确保所有符合协议规则的交易都能公平地进入区块？

要理解以太坊为何需要这些机制，首先需要明白一笔交易从钱包发出后，究竟经历了什么。

当用户在钱包中签署并发送交易时，该交易通常会进入以太坊的公共交易池，即内存池（Mempool），这更像是一个等待区，其中存放着大量尚未写入区块的交易。

进入等待区并不意味着交易已经上链，仍需有人挑选这些交易，决定它们的顺序，并组装成完整的区块，再提交给网络进行确认。

在以太坊升级为 PoS（权益证明）机制后，为了防止大型质押池利用 MEV（最大可提取价值）形成经济垄断，以太坊引入了 PBS（Proposer-Builder Separation，提议者与构建者分离）体系。在此架构下，处理每笔以太坊交易的流程被拆分为两个角色负责。

众所周知，近年来 MEV 策略愈发复杂。如果要求每名普通验证者独立完成交易排序和区块优化，将使得拥有更多资金、数据和技术能力的大型节点占据优势。

因此，将复杂的区块构建任务交由专业 Builder 负责，即便普通验证节点不具备高级套利能力，也能参与区块提议并获取相应收益，从而缓解 MEV 对质押去中心化的冲击。

然而，这也无意中带来了另一个问题，那就是区块构建权的过度集中。目前，超过 90% 的以太坊区块由少数几个专业 Builder 生产，而这些 Builder 通常具有明确的实体背景，容易受到特定国家或地区法律合规（如 OFAC 制裁名单）的外部压力，从而形成中心化风险。

因此，一旦这些主流 Builder 选择性地过滤某些敏感合约（例如 Tornado Cash）或特定地址的交易，这些交易可能会面临长时间无法被打包的困境，甚至有被“隐性封杀”的风险。

综上所述，普通用户眼中的以太坊是一个任何人都可以连接、转账和调用智能合约的开放网络，但从协议运行的角度来看，发送交易只是第一步，交易的生效还取决于其是否被某个区块构建者选择、排序并写入区块。

因此，以太坊讨论的“抗审查”并不仅仅是一个与政治、监管或制裁相关的宏大概念，它首先是一个切实的技术问题：

当一笔交易符合协议规则时，网络能否在合理时间内保证其获得进入区块的机会？

实际上，问题已经变得相当清晰：虽然 Builder 可以提高区块构建效率，但如果交易权长期集中在少数 Builder 手中，以太坊将再次面临新的中心化垄断风险。

为此，以太坊的研究者提出了 Inclusion Lists，通常称为“包含列表”。

这个名字可能听起来有些抽象，但其核心逻辑并不复杂——Builder 仍然负责区块的构建，但不能单独决定所有交易的去留，正常参与以太坊质押的验证节点也需要保留一部分权力，以便他们能够列举一些必须处理的交易。

可以将一个区块比作一班座位有限的公交车。

Builder 决定大部分乘客的排队和座位安排，以此通过更高效的组合提升整趟列车的收益；但验证节点也可以提交一份“必须上车名单”，只要名单中的交易仍然有效、愿意支付合理费用，并且区块有足够的空间，Builder 就无法仅凭个人偏好拒绝处理这些交易。

不过，谁来编制这张包含列表，以及如果有人故意漏掉交易该如何处理，仍然是两个亟待解决的问题。

FOCIL 和 FairFIL 便是朝着这两个方向发展的。

FOCIL（Fork-Choice Enforced Inclusion Lists）将决定交易是否必须被包含的权力，从单一提议者转移到由多方组成的“验证节点委员会”。

在每个出块周期内，网络会随机选出一组验证节点组成临时委员会，委员会中的每位成员独立观察网络内存池，并各自提交一份本地的包含列表。

这意味着，即便全网 99% 的 Builder 和提议者试图审查某笔交易，只要委员会中有 1 位诚实节点将该交易纳入列表，这笔交易就有机会进入协议约束。如果审查者希望继续将其排除，就不再只是影响一个人，而是需要同时绕过多个独立参与者。

因此，它的优势在于，不需要相信委员会中每个人都保持中立。

然而，仅有名单还不够。如果 Builder 在收到名单后仍选择不执行，包含列表就会变成一份没有约束力的建议。

为此，FOCIL 还引入了分叉选择规则（Fork-Choice Rule）作为硬性约束，要求全网负责投票验证的节点严格审查 Builder 提交的区块。一旦发现 Builder 违背委员会整合的包含列表，整个网络将直接拒绝为该区块投票。