要約

  • RFC 9564は2024年4月1日付のIndependent StreamによるInformational文書であり、IETF Standards Track仕様でも実装・展開の証拠でもない。
  • FLIPが想定する未来パケットの予測は受信側の局所計算であり、送信、到着、送信元、鮮度、権限、アプリケーション結果を示さない。
  • SHA-256はモデルのバイト同一性を示せるが、訓練来歴、適合性、同一推論環境、予測品質を保証しない。

モデルファイルのSHA-256が一致した。ここから言えるのは、比較したバイト列が同一だということだけである。どのデータで訓練したか、目的に適するか、受信側と送信側が同じ前処理を使うか、未来のパケットを当てられるかは別の問いだ。

RFC 9564は、その飛躍を意図的に巨大化する。Faster Than Light Speed Protocolでは、両端のLLMが暗号化済みトラフィックを含む未来のバイトを予測する。ヘッダー長さえ受信側ニューラルネットが見つける。将来を予測した攻撃者が先回りする「futureplay attack」も登場する。

提案値にも境界越えが埋め込まれている。IPプロトコル番号345は8ビットに収まらず、ポート68534は16ビット上限を超える。これは実装案ではなく、形式的な仕様記述が因果的な真実と同じではないことを示す仕掛けだ。

RFC番号の前にstreamを読む

ステータス文はInformational、Independent Stream、非Standards Trackと明記する。Internet Standardの候補ではなく、RFC Editorは実装または展開の価値を表明しない。

RFC 7841はstreamごとのboilerplateを定め、RFC 8729は複数streamから成るRFC Seriesを説明し、RFC 9280は編集モデルを記す。番号は固定された出版物の識別子として権威がある。しかし、その文書がIETF合意を経たという意味を自動では持たない。

製品説明や調達要件でRFC番号だけを残すと、category、stream、status、更新、errataが消える。「出版された」と「標準化された」、「引用した」と「相互運用した」を同じ欄に置いてはならない。

バージョン同一性と運用品質を分ける

FLIPはモデルハッシュをVersionに使う。一意な識別は変更検出や再現作業の入口になる。一方、モデルと訓練データを法務・安全・プライバシー上の理由で非公開にするという設定は、検証可能な識別子の背後に検証不能な能力を残す。

実システムでも、署名済みコンテナや承認済みモデル登録は供給経路を支える。しかし品質には、データ来歴、前処理、ランタイム、設定、評価集合、誤差、適用期間が必要である。ハッシュ照合を「AI検証済み」と呼べば、狭い完全性証明が能力保証へ化ける。

一致しても到着履歴にはならない

受信側が生成した予測はネットワークを通っていない。後から同じバイトが届いても、比較結果以外は自動で増えない。攻撃者は期待される列を送れる。リプレイも一致する。欠けた文脈の中で部分だけ一致することもある。アプリケーションは同じペイロードを拒否できる。

必要な受領書は別々である。文書の出版来歴、モデルと訓練来歴、推論入力と時刻、予測出力、実パケットの送受信、相手認証、鮮度と権限、アプリケーション処理結果を結ぶ。

Heng Luの現実レイヤーを使えば、RFC記録、ハッシュ、計算、観測はいずれも現実だが、異なる権限を持つ。風刺の教訓は、現実らしい形式よりも権限境界を読むことにある。