研究002：同等条件の比較と混雑制御の評価計画
状態：計画案 v0.1 · 未実施 · 2026年10月31日
本資料は研究001の結果を受けて作成した次の研究計画である。研究001の事前計画を変更するものではなく、外部で事前登録を完了した文書でもない。制御実装、校正用pilot、環境の確保、下記の実施前条件の確定を経て正式版を固定する。計画中の機能を0.1の完成済み機能として扱わない。
1. 判断したいこと
- 同じ署名付きObjectを取得・検証・保存する際、AINET通信とHTTPSでどのような費用・挙動の差が出るか。
- 同じ情報と保証を表現した場合、AINET独自の包装をCOSEに置き換えることにどのような得失があるか。
- 上限付きの待ち行列と再試行によって、複数クライアントの期限内完了率を改善しつつ、資源の上限と公平性を維持できるか。
署名された内容を別の提供元から検証できるという既知の性質は、新規性の仮説としない。方式に差がない、または標準方式が適するという結果も採用判断に使う。
2. 比較を分離する
| 構成 | Objectと検証 | 通信 | 比較の目的 |
|---|---|---|---|
| A | 現在のAINET Record・本文・検証 | AINET／libp2p | 基準 |
| B | Aと同じRecord・本文・検証 | HTTPS | A–Bで通信部分の差を評価 |
| C | Bと同じ情報・保証を持つCOSEプロファイル | Bと同じHTTPS | B–Cで包装の差を評価 |
A–BではObjectの正確なバイト列、署名、画像デコード、保存手順を同じにする。HTTPSは手動登録した鍵を確認する相互認証を用い、接続先だけを認証する方式と相互認証を無説明で比較しない。証明書・鍵の生成は測定から分離する。B–Cでは作者、出典の申告、参照、配布条件、本文のハッシュ・サイズ・形式を同じ検証契約に含め、署名対象から一部を落とさない。
CPU・メモリ上限、帯域、ストレージ、公開状態、キュー方針、要求順序をそろえる。既存接続の再利用と新規接続は別条件とする。初回保存と保存済みObjectの再取得を区別し、OSキャッシュを消していない測定をcoldと呼ばない。まず常駐クライアントで通信・検証・保存を測り、CLI起動を含む利用者時間は別に記録する。
COSEプロファイルと保存保証の同等性が確認できるまではCの優劣を評価しない。CIDへのID表現変更を同じ実験で同時に行わず、別の設計判断にする。Kubo／Nostrの全機能を無条件に同じ試験へ入れない。
3. 負荷・障害の条件案
| 段階 | 条件案 | 評価範囲 |
|---|---|---|
| ローカル機能確認 | 署名不正、本文改変、長さ不一致、要求と異なるObject、受領通知消失 | 実際の受信経路を使い、検証前の正式登録や重複保存を確認 |
| 局所的な負荷 | 1・2・4・8件の同時要求、32仕事のバッチ、複数の独立クライアント | 総投入仕事数、待機、拒否、再試行、公平性を記録 |
| 模擬ネットワーク | RTT 0・20・100 ms、損失0・0.1・1%、帯域10・100 Mbit/sを候補とする | まず要因ごとに変更。各方向の遅延・損失設定と実測RTTを保存 |
| 実機 | 管理下の2台以上、別の鍵と保存領域 | 模擬環境と別の結果として報告。NAT越えや複数地域の実証とは扱わない |
| 独立実装 | 仕様・試験ベクトルから別の開発者が作成 | 受理・拒否と交換手順を比較。作成者と共有した補助コードを記録 |
通信障害の模擬は利用環境の権限内で行う。1ホストの名前空間やコンテナを複数実機と数えない。現在、複数実機および独立した実装担当者は確保済みとはしていない。
同じ有効Objectの再送は、それだけで攻撃や不正入力ではない。指定IDの取得、MESSAGEの重複、期限付き要求、最新版解決を分ける。最新版を保証する規約を実装していない段階で、署名が有効な古い版を検出できなかったことを署名検証の失敗に数えない。
4. 混雑制御の設計候補
既存の即時拒否方式を基準に、提供側の上限付きキュー、相手ごとの上限、明示的BUSY、クライアント側の期限付き再試行を比較する。再試行間隔には乱数を入れ、最大回数と総時間を制限する。キャンセル時は待機・処理枠を解放する。送信・受信・接続確認の枠を整理し、双方向要求が互いの応答処理を塞がないことを確認する。
MESSAGEは同じ送信者・ID・内容を再利用できる手順を先に定義する。新しいIDで送信し直す操作を重複排除済みの再送と呼ばない。BUSYは現在のワイヤ仕様では予約されているが、現実装の提供側超過ではストリームが拒否される。新しい応答や待機動作は互換性を検討して別途実装する。
5. 指標と統計処理
主指標は「事前に定めた期限内に検証・保存が完了した仕事数 ÷ 投入した異なる仕事数」とする。要求再試行は別の試行IDで記録し、同じ仕事を分母に二重計上しない。成功、拒否、期限超過、利用者キャンセル、接続失敗、検証失敗、保存失敗を分ける。
補助指標は、投入から完了までの時間、処理開始までの待ち時間、再試行回数、全通信バイト数、CPU時間、最大RSS、キュー長、相手ごとの完了率とする。再試行とハンドシェイクも通信量に含める。成功した要求の時間分布だけで全仕事の性能を説明しない。未完了を除外した平均だけを主図にしない。
反復の単位は独立に起動した実験ブロックとする。同一ブロック内の要求を独立した配備環境の標本として扱わない。構成A/B/Cの実行順をブロック内で無作為化し、種と順序を保存する。完了率差とバッチごとの時間分布を示し、区間推定を行う場合はブロックを単位とする。小標本のp95を保証値として扱わない。
6. 正式実施前に固定する項目
校正用pilotは本測定と分けて保存する。pilotで環境の分散と処理時間を確認した後、対象条件、独立ブロック数、仕事の期限、資源上限、許容する性能差、比較対象の版、解析コードを固定する。これらが未確定の現文書を事前登録済みとは呼ばない。
pilotだけを根拠に都合のよい負荷条件を選ばない。省く条件は実施不能などの理由を残す。固定後に変更が必要になった場合は改訂を発行し、変更前の記録を残す。収集済み結果を見て停止時点や採用基準を変更した場合は事後分析として分離する。ハーネス故障は要求失敗と区別し、元の記録を削除しない。
計画の固定には、第三者から確認できる公開記録または登録サービスを利用する。署名タグやAINET Objectは内容の改変検知に使えるが、それだけで独立した時刻証明にならない。既存の研究001は、ローカル計画ファイルと記録の対応を保存した研究であり、後から外部事前登録扱いには変更しない。
7. 採用判断と再現用成果物
最初に、仕様上の同等性と、受理・拒否の基準を満たすことを確認する。機能・保証がそろわない比較は、速度の優劣を決める根拠にしない。標準方式が要件を満たし、事前に定めた実用差を超える独自方式の利点が見られない場合は、相互運用性と保守負担を重視して標準方式への移行を優先する。優劣不明という結論も許容する。
再現用成果物にはソース、依存関係の版、配布ライセンス、ビルド・実行手順、正常・異常ベクトル、期待結果、生データ、解析手順を含める。元のバイナリの一致確認と、他環境で再ビルドした実装の再現を区別し、後者を単にバイナリハッシュが違うために排除しない。現プレビューでは測定データと文書を配布し、実装ソースの公開リリースとライセンスは準備項目として残っている。
AIモデル接続は0.2に位置付ける。改ざん検出、出典への正しい帰属、内容の理解、受信文章に含まれる指示への耐性を別々に評価する。署名が有効な文章にも誤情報や不正な指示があり得るため、署名をモデルの安全性保証として扱わない。