1F916、Merkleログでエージェントの記憶をアーカイブ――オフライン検証で証明できるのは「改ざんされていないこと」のみ

新たに公開された1F916 Protocolは、永続型エージェントに存在する限定的ながら現実的な問題を埋めようとしている。セッションをまたいで再び読み込まれるMarkdown、JSON、ベクトルデータが、エージェントが以前に残したものと同一の内容かどうかという問題だ。エージェントはまず、保存対象ファイルのSHA-256ハッシュを計算し、そのハッシュだけを追記専用ログへ送信する。各レコードは直前のレコードに連結され、ログはMerkle treeによってcheckpointを生成する。checkpointにはregistry serviceが署名し、独立したwitnessがcountersignatureを付与する。原文は引き続きユーザー自身のストレージ層に保持される。

再起動後、エージェントはファイルを再度ハッシュ化し、単一ファイルで依存関係ゼロのNode.js検証ツールを使って、Ed25519署名、Merkle inclusion proof、append-only consistency proof、witness countersignatureを検証する。検証はオフライン環境で実行できるため、検証時に元のregistry serviceをあらためて信頼する必要がない。プロトコルは、registry keyとwitness keyを外部で固定することも求めている。検証ツールがproofファイルに同梱された公開鍵だけを受け入れる場合、攻撃者はその場で、内部的には整合しているものの偽のアイデンティティ一式を生成できるためだ。現在、このような場合の判定は`unanchored`または`consistent-unwitnessed`にとどまり、最高レベルには昇格しない。

公開テストを通じて、すでに複数の修正が行われた。たとえば、署名されていないwitnessファイルに過度に高い判定が与えられていた問題、生成直後の公開鍵が自己保証に使えた問題、葉ノード数が2^32を超えた際のビットシフトエラーによってMerkle proofが弱体化する可能性などだ。こうした結果は、少なくとも設計が公開の場での敵対的検証を受け入れていることを示している。ただし現時点では、スケーラビリティ、性能、複数registry間の相互運用性について、広範なデプロイによる検証は行われていない。

制約も同様に重要だ。アーカイブによって証明できるのは、保存後にビット列が変化していないことだけであり、内容が当初から正しかったことは証明できない。秘密鍵が盗まれた場合、失効するまでの間、窃取者は引き続きエージェントになりすますことができる。wire formatは個人によるIETF Internet-Draftとして提出されているが、これはIETFによる承認や標準化を意味しない。プロジェクトはまだv0.1さえリリースしておらず、2組の独立した実装者が仕様だけを基に検証ツールを再構築し、一致する結果を得ることが条件となっている。エンジニアリングチームは当面、これを記憶の完全性を検証する実験的レイヤーとして扱うべきであり、アクセス制御、コンテンツの真正性、ハードウェアattestationの代替と見なすべきではない。