Summary

  • 一份个人提交的 IETF 草案让委托人用通行密钥签署代理采购额度，再用签名收据核对实际记录。草案例子给出总额 200 英镑，单本日志记到 230 英镑时，离线核验器确实报出超额。
  • 同一份许可若流向两本日志，草案只在各自账本内计算总额。两边都显示合规，委托人的合计账单却可能越过签过字的上限。

两本绿账，一张红账单

草案里的办公室代理负责采购纸张和碳粉。委托人给它 200 英镑总额度，单笔最多 100 英镑；供应方每笔都要副署，超过 60 英镑还得让委托人批准具体订单。作者列出的同一本日志依次记下 45、80、25、80 英镑的采购，最后达到 230 英镑。核验器指出总额越界，也指出批准记录缺失。这个演示之所以干净，是因为许可、订单和加总都在同一本账里。

换成两个记录方，额度纸条不变。每本账各有 125 英镑的订单，审批与副署也都齐全。两个核验器各自看到低于 200 的数字，都会给自己的日志盖上通过章；委托人收到的是 250 英镑的合计费用。这是依据草案规则构造的算术场景，不是现实事故。草案的安全章节直接承认：总额、次数、时间窗口和重复标识只在一本日志内检查；同一许可分散到两本日志，核验器不会自动相加。

这里连造假都不需要。委托人的通行密钥可以真实地签下 200 英镑，代理每张收据可以真实地签名，供应方也可以副署。问题藏在“总额”的计量范围：谁掌握唯一余额，谁有权在另一条执行链也同时下单时拦住后来的那笔？如果答案只是“事后把各自日志交给审计员”，那 200 英镑是事后比对的愿望，不是采购时生效的闸门。

草案把什么交给核验器

Pavel Izmaylov 10 月 24 日的第 01 版属于个人 Internet-Draft。IETF Datatracker没有给它列出已采纳的标准流程或负责的领域主管。提案的记录设计却很具体：委托人用通行密钥签许可，许可中写总额、单笔金额、次数、滚动时段以及附加条件；代理签每次动作的收据；记录方把收据写进带签名树根和时间戳的日志。拿到材料的第三方可以离线核验。

第 01 版还收紧了解析。第 00 版会接受的一些密钥编码、签名长度和字段值，现在会被拒绝。附录 C 说记录本身的字节没有改，变的是核验器如何判断。更严格的单本账审计值得肯定，却不会让两本账自动共享余额。

提案自己把核验定位在动作之后，没有规定一个执行器在供应方接受订单之前拒绝超额行为。示例中的 230 英镑已经写进订单轨迹，报告才指出越界。报告能帮助追责、结算争议和改变流程；要守住采购上限，执行方必须在出手前获得同一个余额的预留结果，并在重试、超时和并发时仍认同它。

副署和批准也不能混成一个按钮。供应方副署表明许可所指定的密钥签了该收据；草案提醒，密钥持有者的现实身份需要另外核实。委托人对超过阈值的某一笔订单签批准，签的不是对无限后续订单的空白支票。日志树根封住已提交的记录序列，却不替外部供应方完成交货，也不替另一名记录方扣减余额。每一种证据都很精确，合计问题仍无人负责。

完美的树根也照不见隔壁那本账

提案采用 RFC 9162 的 Merkle 树结构。被外部持有的签名树根能让后来篡改或截短已覆盖的历史留下冲突；一致性证明说明一棵树如何在不重写旧叶子的情况下继续生长。它回答的是“这棵树的过去有没有被改写”。两棵各自正确的树，并不会因为都通过一致性核验，就自动生成一份跨树账单。

草案还指出，最后一个树根若只有记录方保管，删除它可能不留下外部反证；同一记录方也能向不同人展示分叉视图，而文本尚未定义两种视图之间的一致性证明。这些是历史可见性的缺口。200 英镑额度被拆成两个 125 英镑局部总额则更直接：即使两个记录方诚实保留全部收据，核验器仍只在各自范围内计算。缺的不是更亮的加密封印，而是共同分母。

实施状态也写得明白。草案列出同一作者制作的 JavaScript 与 Python 库；Python 版尚不能核验树根的一种 SLH-DSA 签名，时间戳属性处理也有已知问题。文中没有列出独立实现。要改变对跨日志额度的判断，公开的并发测试至少要展示同一许可在两个记录方同时使用时，系统怎样拒绝超额，并让第三方重算统一结果。

Sources