AeroNyx

分散型プライバシーノードの運用とヘルスチェック

AeroNyx2026年6月18日約9分で読めます45 回表示

AeroNyx 分散型プライバシーノードのヘルス、発見、ブラインドリレー、再起動復旧、容量、パケット実行状態、二ホップ証明、Cargo キャッシュを安全に運用します。

「分散型プライバシーノードの運用とヘルスチェック」は AeroNyx ドキュメントの正式な日本語ページです。AeroNyx はプロトコル層とプロダクト体験を分離し、プロトコルは停止しにくい公開能力を、プロダクトは App、Nodeboard、暗号化チャット、暗号化ストレージ、ノード運用体験を担います。

概要

このページでは「分散型プライバシーノードの運用とヘルスチェック」が AeroNyx のオープンプライバシープロトコルで果たす役割、実装範囲、プライバシー不変条件、開発とノード運用上の注意点を日本語で説明します。

AeroNyx アーキテクチャでの位置づけ

このテーマは ノード運用者 に属します。AeroNyx を単一の中央集権サービスとしてではなく、クライアント、分散型プライバシーノード、バックエンド調整器、Nodeboard が共有するオープンなプライバシープロトコル能力として理解することが重要です。

現在の実装ポイント

  • ユーザー内容に関わる機能は、端末間暗号化または暗号化オブジェクトとして扱います。
  • 分散型プライバシーノードはヘルス、容量、接続、経路証明、集計統計を報告できますが、メッセージ本文、アクセス資格情報、ユーザー秘密を読むことはできません。
  • Nodeboard は運用可観測性のために、ノード状態、peer discovery、再起動復旧、容量、パケット/トラフィック、プロトコル状態を表示します。
  • 現在のバックエンドは調整、順序付け、集計、公開ドキュメント API を担当し、将来は一部を Rust プロトコル層へ移行できます。

プライバシー境界

AeroNyx の中心は blind-node invariant です。リレーノードと MemChain 調整器は、暗号文、タイムスタンプ、証明、集計ヘルス信号、限定されたルーティングメタデータだけを扱います。平文、DNS 内容、宛先、通信関係を知るべきではありません。

ノード運用者が見るべき項目

運用者は帯域、接続上限、IP プール、conntrack、ファイルディスクリプタ、packet drops、pps、bps、peer store、heartbeat の新鮮度、restart recovery を確認します。運用 UI は障害解析を助けるべきですが、ユーザー内容や識別可能なデータを表示してはいけません。

開発者とプロダクト統合

クライアント、App、AI agent、第三者サービスは、AeroNyx の暗号化エンベロープ、署名、ブラインドリレー、匿名資格情報、ヘルスチェック規約を再利用するべきです。新しい API は公開メタデータと E2E payload 内に残すべきフィールドを明確に分ける必要があります。

現在の状態

このページは、AeroNyx が現在公開できるプロトコルとプロダクト設計の境界を説明します。multi-hop routing、blind-signed vouchers、encrypted media blob、MemChain 同期、ノード発見の更新は、同じ translation_key の下で継続的に更新します。

<!-- memchain-witness-operations-v1:start -->

Pinned witness の運用

Pinned witness は MemChain commitment coordinator の明示的な運用信頼ポリシーです。独立運用・監査済みで、この coordinator の履歴を保持する follower だけを設定してください。

toml
[memchain]
commitment_coordinator_enabled = true
commitment_witness_node_ids = ["<64-hex-ed25519-node-id-1>", "<64-hex-ed25519-node-id-2>"]
commitment_witness_startup_required = false
commitment_witness_min_verified = 2

検証前に placeholder をすべて置換してください。最大3個の一意でゼロではない32-byte Ed25519 IDを設定でき、coordinator でのみ有効です。

安全な導入手順は、監査済み follower を2台以上更新し、strict を無効にして正確なIDを追加し、aeronyx-server validate -c /etc/aeronyx/server.toml を実行し、再起動で operator_pinned の署名証拠を確認してから strict を有効にすることです。

strict 無効時、witness 不達は明示的な degraded warning になりますが可用性は維持されます。署名済み remote-ahead または divergence は常に起動を止めます。strict 有効時は、検証済み証拠がない場合も停止します。

checkpoint は署名プロトコル endpoint であり、匿名ブラウザ GET は health check ではありません。Witness は rollback 検出を強化しますが、単独で consensus、quorum、finality を作るものではありません。

検証済みの本番展開 — 2026年7月14日

1台の本番 coordinator に、運用者が固定した3つの witness ID が設定されています。独立運用・監査済みの2台の follower が互換 checkpoint service を稼働し、それぞれ同じ33 block・8,339 commitment の履歴を検証して保存しました。Coordinator は両 follower が個別に署名した converged 応答を受理した後、commitment_witness_startup_required = true を有効にしました。

検証済み再起動では startup guard が configured=3、eligible=3、attempted=3、verified=2、converged=2 を記録し、UDP と TUN listener は検査通過後にだけ開かれました。これは運用者が固定した node による rollback evidence であり、consensus、quorum、公開チェーンの finality、token execution ではありません。

<!-- witness-threshold-enforced-v1:start -->

2-of-3 起動しきい値の強制 — 2026年7月14日

本番 coordinator は commitment_witness_min_verified = 2 と commitment_witness_startup_required = true を同時に設定しています。異なる固定 witness から有効な署名証拠が2件未満の場合、起動を拒否します。有効応答が0件なら signed_checkpoint_unavailable、1件なら signed_checkpoint_threshold_unmet です。直近の本番再起動では、UDP、TUN、公開 API listener を開く前に、設定済み3 witness のうち2件を検証しました。

これは運用者が定める起動しきい値であり、ネットワーク consensus、quorum、finality、leader election、fork choice ではありません。Rust heartbeat は startup_minimum_verified を含む集約済みの方針と結果だけを報告し、witness ID、endpoint、checkpoint hash、署名は公開しません。

<!-- witness-threshold-enforced-v1:end --> <!-- memchain-witness-operations-v1:end --> <!-- signed-commitment-ledger-related-v1:start -->

関連プロトコル仕様

署名付きコミットメント台帳と Witness 保護

<!-- signed-commitment-ledger-related-v1:end --> <!-- aof-semantic-integrity-v1:start -->

MemChain AOF 完全性チェック

計画されたすべてのアップグレードと再起動に、この読み取り専用ゲートを追加してください。出力は集約情報のみなので運用自動化に利用できます。

bash
sudo aeronyx-server memchain verify-aof \
  --config /etc/aeronyx/server.toml

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain
結果運用者の対応
status: verified かつ torn_tail_bytes: 0設定検証と guarded restart を続行します。
torn_tail_detected手動編集しないでください。完全な意味 scan 後、guarded append-open だけが不完全な物理 tail を除去できます。
完全性エラーで終了停止し、AOF とログを incident review 用に保存します。完全 record の意味的破損は fail closed です。

プライバシー: AOF 自体を upload、paste、公開しないでください。共有できるのは verifier の集約出力だけです。

完全性と証明境界の詳細: 署名付きコミットメント台帳と Witness 保護.

<!-- aof-semantic-integrity-v1:end --> <!-- build-cache-maintenance-v1:start -->

保護された Cargo ビルドキャッシュ保守

ソースビルドを繰り返すと、再生成可能な Cargo オブジェクトが数十 GB 残ることがあります。統一運用コマンドは、プロトコル状態を削除せず、サービスを再起動せずに容量を確認して回収します。

1. ホストを変更せずに確認

最初に読み取り専用 inventory を実行します。旧 target、分離 build root、固定 Rust バージョン、保護対象 binary の SHA-256、集約ファイルシステム容量を表示します。

bash
cd /root/open/AeroNyx
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. 削除候補をすべてプレビュー

dry-run を一行ずつ確認してください。削除には root と明示的な --yes が必要で、status や upgrade が自動的に消去することはありません。

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --dry-run

3. 確認済みの整理を実行

bash
sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --yes

カスタム build root を使う場合は、3 つのコマンドすべてで AERONYX_BUILD_TARGET_ROOT を設定し、同じ分離 target を参照してください。

保護対象と削除対象

  • 保護対象: 実行中の target/release/aeronyx-server、現在の固定 toolchain/service cache、他の release 実行ファイルと rollback artifact、/var/lib/aeronyx のプロトコルデータ、/etc/aeronyx の ID/設定、他サービスの cache を保持します。
  • 再生成可能: 旧 debug/クロスターゲット、deps、build、.fingerprint、incremental、.rlib、.rmeta、.d、同じサービスの旧 toolchain target など、既知の再生成可能な Cargo 出力だけを削除します。
  • 実行ガード: 削除前に install/upgrade と同じ deployment lock を取得し、systemd MainPID が保護対象 binary を実行していることを確認します。前後の hash が変化すれば失敗します。

保守後の検証

キャッシュ保守はノードを再起動せず、active session の drain も不要です。完了後にサービス、startup readiness、discovery quorum、二ホップ証明の鮮度を確認します。

bash
./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"
./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

本番検証証拠 — 2026 年 7 月 26 日

制御された本番実行で 50,649,768 KiB を回収し、使用率は 90% から 65% に低下しました。binary SHA-256、MainPID、再起動回数は不変で、startup は失敗ゼロ、二ホップ証明は ready/stable を維持しました。

プライバシー境界: inventory はローカルパス、サイズ、toolchain version、binary hash、集約容量だけを出力します。暗号化 payload、MemChain record、鍵、peer ID、route、client address、DNS、宛先、social graph は読み取りません。

<!-- build-cache-maintenance-v1:end --> <!-- memchain-llm-provider-operations-v1:start -->

任意 cognitive worker のプロバイダー運用

SuperNode cognitive worker は任意で、既定では無効です。信頼上の役割を理解した処理ノードでのみ有効にしてください。

最小ローカルプロバイダー設定

toml
[memchain.supernode]
enabled = true

[[memchain.supernode.providers]]
name = "local-ollama"
type = "openai_compatible"
api_base = "http://127.0.0.1:11434/v1"
api_key = ""
model = "llama3.2"
max_tokens = 1000
temperature = 0.3

[memchain.supernode.routing]
fallback = "local-ollama"

[memchain.supernode.privacy]
default_level = "structured"
allow_full_for = []

api_key = "$ENV_VAR" も利用できます。秘密情報をコミット済み設定へ書き込まないでください。

OpenAI 互換 endpoint の形式

次の 3 形式はいずれも同じ Chat Completions endpoint に解決されます。

  • https://provider.example
  • https://provider.example/v1
  • https://provider.example/v1/chat/completions

type = "anthropic" では api_base を省略でき、現在の runtime は Anthropic 公式 Messages endpoint を使用します。

障害時とリソース上限

  • 成功レスポンスは JSON 解析前に 8 MiB、エラー診断本文は 64 KiB に制限されます。
  • 通信、API、解析、空レスポンスの失敗はプロバイダーを永久停止せず、単調時計による 30 秒の cooldown に入れます。
  • HTTP 429 の Retry-After は 1-300 秒の範囲で適用され、指定がなければ 30 秒です。
  • router は別の健全なプロバイダーへ切り替え、cooldown 終了後に失敗したプロバイダーを自動的に再評価します。定期ジョブは不要です。

再起動前に aeronyx-server validate -c /etc/aeronyx/server.toml を実行してください。この動作は現在の main に含まれ、導入済みノードでは該当リリースへの再ビルドまたはアップグレードが必要です。

プライバシー境界：保存／relay ノードは引き続き node-blind です。有効な cognitive worker と外部プロバイダーは privacy level が許可した prompt を見ます。default_level = "structured" を維持し、完全な内容処理への明示的同意がない限り allow_full_for は空にしてください。

<!-- memchain-llm-provider-operations-v1:end -->