在 PBS 把“选交易”变成 builder 的生意之后（builder 与提案流程见 bundle 是什么？builder 和验证者怎么合作），一个遗留问题浮出水面：builder 可以静默不出价包含某些交易——它不需要作恶，只需要不感兴趣。抗审查从此从“矿工贪钱所以不设黑名单”的激励论证，变成需要结构兜底的工程问题。Inclusion List（EIP-7805 方向的机制）就是当前的兜底样本：让“有一批交易必须进某个窗口”成为共识层规则。
机制：先投票清单，后强制执行
设想把交易生命周期切成两拍。第一拍，验证者集合按现有投票节奏，各自声明愿意担保的一小组交易，合并成一份“近期必须被包含”的清单，清单随链状态维护——交易一旦入围，获得一个截止高度；第二拍，出块者在自己的窗口内必须包含清单内全部未过期交易，验证者按此校验区块有效性。对 builder 而言，清单是外部注入的约束输入；对普通用户而言，含义是“只要这笔交易被担保进清单，最迟在截止高度前它会出现在链上，无论哪个 builder 接单”——交易在广播后进入待确认阶段的这一段落，与内存池生命周期的关系见 区块链交易的一生：从构造签名到最终确认。
为什么需要它：审查的经济学
不依赖这类机制的抗审查链条是概率式的：总有 builder 贪你的优先费、总有 slot 的搜索者不设筛选。但“概率上抗得住”在特定场景不够用——清算、协议运维交易、以及被针对性过滤的普通转账，等不起概率。强制包含清单把这层保险写进协议状态：审查者必须同时控制验证者投票集合才能拒单，这比收买单点 builder 或单 slot 矿工贵得多——成本从“买通渠道”升级为“控制多数投票”。这与 MEV 中继时代“排序权与打包权分离”的治理逻辑一脉相承（MEV 与 PBS 背景见 以太坊MEV与PBS是什么？交易排序的市场原理）。
边界与权衡
清单不是无限的：容量、每交易驻留窗口、防垃圾的入场费设计都是参数（具体取值以提案文本为准），设计目标是拒绝清单沦为刷量通道。另一条边界是语义：强制“被包含”不等于强制“被执行成功”——包含后交易仍可能因余额、滑点、前置状态变化而 revert（交易状态语义见 交易卡在“等待中”怎么办？Pending 状态的排查、加速与取消邻域话题）。最后是版本诚实：截至本文写作，该类机制属于提案与实验方向，以太坊主网是否启用、何时启用，以官方路标与 EIP 状态为准，本文不作为现状描述。
快速问答
- “和私有交易通道什么关系？“私有通道（大额单避开公共内存池，见 私有交易通道是什么？大额交易为什么要用它）解决“不想被看见”，Inclusion List 解决“必须被包含”，是两个方向，可同框。
- “我的钱包能用吗？“机制生效在共识与协议层，钱包侧感知是“交易更难被静默漏掉”，体验不改变（待确认体验的现实基线见 RPC 限流与 429 报错怎么处理？钱包连接排查指南邻域的钱包故障排查语境）。
- “会抬Gas吗？“被担保交易获得的是包含机会不是插队权，费用市场照常工作；参数若设计出“担保拍卖”，那是另一层设计选择。
- “它能保护清算人吗？“这是动机场景之一：清算与协议运维交易有稳定的“必须上链”需求，正是该机制相对纯激励方案最被强调的增益。
常见误区
- 误区一：把它读成“抗审查彻底解决”。清单限制的是“静默排除”，公开拒绝（全清单争议交易的窗口博弈）仍需治理与生态冗余应对。
- 误区二：把提案当已上线功能。引用时严格区分：设计意图、实验实现、主网激活三态，只有最后一态才配“现状”二字。
- 误区三：认为强制包含零成本。每笔担保交易都占用共识注意力与带宽，清单容量参数的本质是“抗审查强度与共识开销的汇率”。
小结
从“矿工贪婪所以链中立”到“投票清单 + 强制包含”，抗审查完成了一次从叙事到协议的进化。Inclusion List 类设计的价值不在优雅，在诚实：它承认市场的自发抗审查有尾部风险，于是把最坏情况写成规则。判断同类提案时记住一句话——看它把审查的边际成本抬高到谁头上、抬高多少，就理解了它的成色。
风险提示：本文不构成投资建议。提案状态以官方文本为准，勿据路线图配置交易策略。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。