抗审查叙事里有一条朴素规则：只要一笔交易被足够多的包含者写进包含列表，出块的构建者就必须把它塞进区块。FOCIL（EIP-7805）正是这样设计的，但它立刻碰到一个现实问题——构建者有权以交易无效为由拒绝，那么谁来核验这条拒绝是不是真的？核验若需要下载全量状态，抗审查就又建在信任上。EIP-8369 回答的就是这个问题的边界：哪些交易值得FOCIL替你强制，靠的是把它圈进两种仅验证型的部分无状态档案。
档案一：便宜到谁都验得起
Profile 1 覆盖现实中绝大多数流量：legacy、EIP-2930、EIP-1559 与 EIP-7702 四类交易。它们的验证之所以便宜，是因为检查项少且局部——余额够不够、nonce 对不对、Gas 上限定了多少，再加上载荷剩余空间。核验者不需要预执行整条链，只要交易被追加到载荷末尾时代码路径不炸。FOCIL 原文的省略检查规则（在载荷末尾试执行）对这类交易原样保留：交易要么在末尾有效，要么确实装不下。
档案二：可编程验证的妥协
帧交易（EIP-8141）把账户抽象验证做成可编程逻辑，有效性可能依赖键控 nonce、最近根、限定范围内的账户存储——这些状态不在交易旁边，末尾试执行成本高且不确定。Profile 2 的处理是换一个问法：不看末尾，看构建者声称的那个索引位置。构建者若声称交易在某一位置无效，核验者在该位置对着一个固定的验证状态面重放检查。代价被文档写得坦率：因为索引由构建者挑选，如果同区块里另一笔交易能移动验证依赖，这笔保护就更弱——交易必须在构建者可能声称的每一个索引上都保持有效，才算真正受FOCIL保护。
两件事FOCIL不负责
文档特意切开两个常被混淆的概念。其一，内存池准入不是FOCIL资格：交易可以走公共内存池、私有通道或直连提交，渠道只决定它能否被包含者看见，不决定它能否被强制包含。其二，档案之外的交易并非进了包含列表也没用，而是FOCIL不再替它担保——构建者仍可包含，规则不惩罚省略。这类交易要么贵到无法廉价证伪，要么落在既定状态面之外，强推到共识层就是把DoS攻击面摊开给所有人。
这份提案的体裁值得注意：它是 Informational，自己不设置任何共识规则，只是给 7805 与 8141 的后续扩展画参考模型——资格边界、状态面、预算三张图纸先摆上桌，让工程分歧发生在文档而非代码合并时。按官方页标注，它创建于 2026 年 8 月 5 日，Draft。对钱包和协议开发者的实际意义是：想吃到FOCIL的抗审查红利，交易类型与验证逻辑要贴着这两张档案的轮廓设计；偏离越远，被省略时能讨的理越少。
一张自查表
钱包或协议若在规划抗审查特性，可以按三个问题给自身交易定位：验证依赖是否声明在固定状态面内——若程序化验证要读任意链上数据再分支，它注定落在两种档案之外；是否愿意把验证逻辑约束在键控 nonce 与近期根的包围之内——recent roots 让隐私交易能引用最近状态而不泄露细节；以及是否接受被强制包含交易的内容全公开——档案保护可包含性，不自动保护隐私。三问全是的，FOCIL 的保护接近无条件；答案渐次偏离，抗审查等级就回到诚实构建者加事后惩罚的旧模式，那同样是可辩护的工程选择，只是别把它营销成协议级保证。
快速问答
问：仅验证型部分无状态是什么意思？ 答：执行不需要状态，但验证需要一小块可携带的证明或固定状态面；验证成本因此可预算。
问：不在这两种档案里的交易更容易被审查吗？ 答：只是少了FOCIL这一层强制；包含者若诚实收集包含列表仍然可以包含它们。
问：帧交易是什么？ 答：EIP-8141提出的把交易拆成多个角色签名帧的结构，为账户抽象与隐私交易提供统一入口。
风险提示：本文讨论未落地提案，不构成投资建议；交易可见性与协议规则以当前网络实际为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。