内存池里读不到的那个数
一笔交易要证明”我花的这个承诺，在某个版本的隐私树里存在”，最直接的方式是验证它依赖的树根确实被某个应用写进过链上状态。问题是公共内存池的验证规则不允许交易在执行前任意读取别人账户的存储——否则一个恶意合约就能让验证节点为攻击者承担状态读取成本。EIP-8141 帧交易的验证模型因此默认：内存池检查只做不依赖任意存储的事。EIP-8272（2026年5月起草，Draft 状态）为这个缺口开了一扇受控的窗：一个写进规范的 VERIFY 帧，专门核验”最近的根”。
三元组和一张表
机制围绕一张共享的 recent root 合约展开。任何应用要发布自己的根，就往这张表写：键由写入者地址加盐派生的 source_id 配上槽号，值是那个 32 字节的根。交易侧则携带一个 VERIFY 帧，里面是一到十六个三元组（source_id、槽、根）。验证器合约逐项查表：这张表在这个槽位存的根，是不是就等于交易声明的这个根。由于同一个键的条目除了链重组不会改变，交易在内存池停留期间，它核验过的事实不会在它脚下偷偷变化——这正是”recent root”这个名字要买断的确定性。检查失败，交易直接被判定无效；通过后，交易的账户验证帧还能借帧交易已有的自省机制读到这些已验证的三元组，避免重复工作。
设计上的几个克制
提案的取舍值得逐条看。不往交易信封加新字段，而是复用帧结构里的 canonical VERIFY 帧，信封保持原样；三元组完整放进帧数据而不是只放哈希，让验证无需求助于外部服务；在公共内存池里给这个检查设了验证预算，防止用海量三元组轰炸验证节点；帧在序列里的位置固定靠前，保证根检查先于账户验证发生。合约地址与键的派生常数细节以提案表格为准，部分标注待定。
快速问答
问：这跟交易直接调用根检查合约有何区别？ 答：普通调用发生在执行阶段，内存池节点不承担义务；VERIFY 帧是协议定义的预执行检查，客户端必须做、做完可缓存，且失败即无效——把”依赖某个应用状态”这件事从隐式调用变成显式声明。
问：一个应用忘了写根会怎样？ 答：对应键查无此值，核验失败，交易不进块；写入方应用需要自己保证按槽发布。
一次验证的完整旅程
设想一笔隐私池支出交易。隐私应用早先按槽发布过一棵承诺树的根。用户构造帧交易：先挂一个 VERIFY 帧，列出（该应用的 source_id、根所在槽、用户证明所依据的根）三元组；协议在内存池阶段调 recent root 合约核对，等值成立才继续排队。节点的视角同样简单——它无需理解隐私树的逻辑，只需比对存储里一个值与交易里一个值。验证需求被压缩成一次查表，这是帧类提案常见的杠杆：把”要执行才知道”的事前移到”看一眼就判定”。
谁来写根、多久写一次
发布根的应用侧责任值得展开：写入者按槽推进，根一旦写入就不再移动，重组才会改写。应用若更新树却忘了发布新根，交易只能引用旧槽的旧根，隐私池支出依赖的正确性由写入纪律保障。窗口选择在 Rationale 里也做了权衡——引用范围太短会把合法交易挤出内存池，太长则放大重组期的错误引用概率，提案用固定槽窗口换确定性。对索引器而言这张表还有个副产品：根历史天然可查，隐私应用的审计与监管接口不必再自建。
风险提示：本文为协议提案的科普介绍，EIP-8272 与其所扩展的 EIP-8141 截至撰写时均未在主网激活，地址与常数以提案原文为准；不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。