【RFC9564】超光速通信プロトコルFLIPの紹介

以下は2024年4月に公開されたRFC、[RFC9564 Faster Than Light Speed Protocol](https://www.rfc-editor.org/rfc/rfc9564.html)の日本語訳です。


# RFC 9564 Faster Than Light Speed Protocol (FLIP)

## Abstract

大規模言語モデル(AI)などの最近の飛躍的進化に伴い、インターネット用の超光速通信プロトコル(FLIP)を実用化することが可能になりました。
FLIPでは、受信ピアに到達するパケットをAIを駆使して事前に予測することで、インターネット上で高速なパケットを送信する方法を提供します。
このドキュメントでは、プロトコル、カプセル化の方法、および運用上の考慮事項について説明します。

## Status of This Memo

このドキュメントは情報提供を目的としており、インターネット標準の仕様を規定するものではありません。


## 1.  Introduction

2022年11月30日にChatGPTが公開されて以来、大規模言語モデル(LLMs)は様々なアプリケーションで利用されてきました。
適切なトレーニングを施すことで、入力から適切な出力を生成する強力な機能を備えています。
このプロトコル仕様では、その機能を用いて、次のパケットが受信ピアに到着する前に次のパケットを予測することで、高速を超える通信を実現します。
プロトコル名は「Faster than LIght speed Protocol」、略称はFLIPです。

FLIPはパケット、フレーム、テキスト、ストリームいずれをも予測することができるため、IPプロトコルスタックのどのレイヤーにも対応できます。
また、暗号化は単なるバイト文字列にすぎないので、適切なトレーニングを行うことで予測することが可能です。
このプロトコル仕様では、FLIPをレイヤー2およびトランスポート層に適用します。
FLIPはどのレイヤーにも適用可能であるため、今後HTTPリクエストやレスポンス、メールなどについても追加の仕様が作成される予定です。

宇宙船との通信速度はいまのところ光速以下に制限されており、宇宙船と地球は非常に離れているため、非常に長い遅延が発生します。
光速を超える通信を提供することにより、FLIPは[深宇宙IPネットワーキング](https://datatracker.ietf.org/doc/html/draft-many-deepspace-ip-assessment-01)の重要な実現手段となるでしょう。


## 2.  Protocol Peer Preparation

光速を超える速度を実現するために、FLIPが使用するプロトコルレイヤーのピアは、該当のケースに合わせてトレーニングされた適切なモデルを使用する必要があります。
このドキュメントでは特定のLLMを規定していません。
実装ではユースケースに応じて適切なLLMを選択し、トレーニングすることになります。
セキュリティ・プライバシー、および法的問題への対処のため、使用されるLLMの詳細やトレーニング方法、使用されるデータセットはプロトコル上で開示されることはありません。

実装では、たとえばインターネット上の様々なエンドポイントで、tcpdumpなどを用いて大量のパケットを収集することができます。
トラフィックが暗号化されているかは影響を与えません。
十分にトレーニングされたLLMは、暗号化されたトラフィックを暗号化されていないトラフィックと同等に予測できるからです。


## 3.  FLIP Header

FLIPが使用される場所では、必ずFLIPヘッダを挿入する必要があります。

```
   +----------+---------+----------------+----------------+
   |  Version | Command | Inner Protocol | Optional Data  |
   +----------+---------+----------------+----------------+
```

FLIPヘッダには以下のフィールドが含まれます。

### Version

セクション5で解説します。
使用するモデルのSHA-256ハッシュを含む、可変長フィールド。

### Command

このFLIPフレームの操作を識別するコードポイントであり、コマンドはセクション4で解説します。


### Inner Protocol

このフィールドで内部プロトコルを指定します。
たとえばIPとTCPの間であれば、トランスポートプロトコルのFLIPコードポイントが含まれます。


### Optional Data

一部のコマンドで使用する、追加のフィールドです。

ヘッダ長は可変で、コマンドによって長さが異なります。
このプロトコルの実装ではAIが使用されるため、フィールド長はヘッダに記載されません。
受信側がヘッダ終了部分を適切に検出することで、多くのヘッダビットを省略することができます。

FLIPヘッダの存在を上位層に通知するため、FLIPの下の層で一部のコードポイントが予約されます。
詳細についてはセクション7で解説します。


## 4.  Protocol Operation

FLIPでは最初のパケットを送る前に、送信者と受信者それぞれにおいて適切にトレーニングされたモデルを設定しておく必要があります。
適切なLLMの選択、適切なトレーニングの選択はプロトコルの実装に任されています。

以下のコマンドが定義されています。

### Model / コードポイント0x01

モデルをFLIPプロトコル帯域に送信する方法をピアに提供します。
モデル自体はFLIPヘッダのOptional Dataに格納されます。
モデルデータの前に、適切なメディアタイプのMIMEヘッダを指定する必要があります。
モデルのメディアタイプが存在しない場合は、IANAのメディアタイプレジストリに登録する必要があります。


### Data / コードポイント0x02

後続のデータが予測可能であることを受信側ピアに伝えます。

モデルのサイズは大きくなることが予想されるため、モデル自体を他のピアに送信する操作はなるべく避けるべきです。
また、盗聴者にモデルを盗まれる可能性があります。
盗聴者はAI予測の影響を受けにくいポスト量子暗号アルゴリズム、すなわちポスト量子AI暗号アルゴリズムを使うかもしれません。


## 5.  Versioning

[RFC 6709](https://www.rfc-editor.org/info/rfc6709)で解説されているように、プロトコルの新しいバージョンを通知する方法を提供するなど、今後のバージョニングが可能な設計にする必要があります。
FLIPの場合、トレーニングされたモデルは常に新しくトレーニングされ続けられるため、[RFC 6234](https://www.rfc-editor.org/info/rfc6234)に従ってモデルのSHA-256ハッシュをバージョンとして扱います。
SHA-256ハッシュはFLIPヘッダのVersionフィールドに配置されます。
SHA-256ハッシュには連続性がなくランダムであるため、将来のバージョンを予測したリプレイアタックは不可能です。


## 6.  Future Work

この新しいプロトコルは、インターネットプロトコルの設計やインターネットの利用方法に革命をもたらすかもしれません。
たとえばこのプロトコルをビデオストリーミング、AR・VR、量子暗号などに応用されることが期待されます。
将来のパケットを予測することで、これらのプロトコルやアプリケーションはFLIPの恩恵を受けることができるでしょう。


## 7.  IANA Considerations

FLIPのコードポイントは、次のIANAレジストリに登録されます。

[Protocol Numbers](https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml):345。
[Service Name and Transport Protocol Port Number Registry](https://www.iana.org/assignments/service-names-port-numbers/):68534。


## 8.  Security Considerations

LLMに基いて将来のパケットを予測する能力は、トラフィックを監視している攻撃者にも利用される可能性があります。
受信ピアが使っているモデルを攻撃者が手に入れることができれば、それを使って次のパケットを予測し、予測リプレイアタックなどの攻撃を仕掛けることができる可能性があります。
この攻撃は、攻撃者が将来のパケットを予測して先に受信ピアに送り付けるというものです。
現時点ではこの攻撃による被害は未知数ですが、新しい攻撃による問題が大きくなる前に研究を行う必要があるでしょう。


## Acknowledgements

このプロトコル仕様はAIと大規模言語モデルを使用して策定されています。
愚かな人類はこのプロトコル仕様のレビューに参加するべきではないと判断されました。
かわりに複数のLLMチャットサービスによってレビューされ、彼らの提案によって改善されました。
IETFは現在人間の知性に頼って仕様を策定していますが、今後はLLMを使って仕様を策定することを検討するべきです。
またIESGやIABといった管理職のエキスパートを見付けることの困難さを考えると、彼らの役割もLLMによって代替することを考慮するべきでしょう。
残念乍ら、セキュリティ・プライバシー、および法的問題への対処のため、プロトコル仕様策定に使用されたLLMチャットサービス名が開示されることはありません。


# 感想

実際に超光速通信をするわけではなく、結果として超光速通信をしているように見えるのであれば超光速通信であるというアヒル理論の応用ですね。

実は、ストリートファイターなどのネット対戦格闘ゲームでは既に[似たような技術GGPOが実用されています](https://www.inside-games.jp/article/2022/05/22/138312.html)。
対戦相手はこうするだろうと予測してキャラを動かしておいて、後から来た正しい動きが異なっていたらロールバックするという手法で、本RFCで言う意味での超光速通信を既に実現しているわけです。
ソースコードも[OSSで公開されています](https://github.com/pond3r/ggpo)。

もっともこれに使われているのは汎用的なAIであり、対戦相手の適切なトレーニングを施した高精度なモデルではないので予測ミスも多々発生します。

ところでレースゲーム[Forzaシリーズ](https://forza.net/)には[Drivatar](https://support.forzamotorsport.net/hc/en-us/articles/360005302934-FH3-Drivatars)という仕組みが存在します。
プレイヤーのドライビング操作をAIが学習して、自分の分身を産み出すというものです。
コースに沿った理想の走りをすればDrivatarも綺麗に走るし、プレイヤーが壁走りばっかりやっていればDrivatarも壁にがんがんぶつかります。
そして彼らはネットで拡散し、フレンドや他人とレースで対戦してくれます。
中には[亡くなった親友と再会した](https://automaton-media.com/articles/newsjp/forza-horizon-3-player-met-a-firend-who-died-as-driveartar/)なんて話もありました。

これはリアルタイムの通信こそしていないものの、適切なトレーニングを施した高精度なモデルといえるでしょう。

すなわち、DrivatarとGGPOを組み合わせれば、対戦格闘ゲームでは超光速通信が既に実現できますよね。
対戦相手の癖を高度に学習したAIであれば、予測ミスもほとんどおこらないでしょうし、いずれは一切通信をせずに通信対戦ができるようになるかもしれませんね。

さすがにそこから直接的にあらゆる汎用の用途にまで超光速通信を広げられるかというと難しそうですが、実現手法の見当も付かない他の未来技術RFCたちとは異なり、既に技術としては手元に存在するわけです。
まあもっとも、その前にAIの性能をもっと改善しないことには実現は無理ですけどね。

というか正直ずっと思ってるんだけど、ChatGPTとかGeminiごとき程度の性能でAIとか名乗ってほしくない。
我々が求めているAIは、なんか10億円稼いできてって言ったらなんか10億円稼いでくるAIであって、ベッド下のエロ本を見つけてえっちなのはいけないと思いますって言ってくるAIであって、ミートスパを作ろうとしてミートせんべいを作ってくるAIであって、手取り足取り細かい情報を教えてようやく答えの断片を返してくる介護型AIではないのだ。