AeroNyx

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

AeroNyx2026年7月16日約6分で読めます51 回表示

AeroNyx は暗号化された MemChain レコード向けに署名付き追記専用コミットメント台帳を運用します。台帳は順序と完全性を検証しますが、インフラは記憶内容を読めません。これは公開ブロックチェーンではありません。

プロトコル不変条件: コーディネーター、フォロワー、Witness、バックエンド、公開サイトは暗号文コミットメントと限定的な運用証跡だけを扱い、平文、復号鍵、所有者関係、ソーシャルグラフを受け取りません。

現在の本番構成

1 台のコーディネーターと 3 台の監査済みフォロワー／Witness を使用します。起動時は 3 台中 2 台の署名済みチェックポイントが必要で、実行中の生産には 3/3 の短期 lease が必要です。

observed_at=2026-07-16 · reporting_nodes=4 · coordinator=1 · followers=3 · height=33 · commitments=8,339 · witness_lease=3/3.

text
client.encrypt_and_sign
  -> coordinator.append_opaque_commitment
  -> follower.verify_signed_ancestry
  -> pinned_witness.retain_checkpoint_and_grant_bounded_lease
<!-- commitment-ledger-flow-i18n-v1:start -->

書き込みと検証の流れ

  1. クライアントが対象の記憶レコードをローカルで暗号化し、署名します。
  2. コーディネーターは不透明なコミットメントと順序 metadata だけを追記します。
  3. 追記ごとに直前の署名済み Block を検証し、ローカルの署名済み high-water anchor を更新します。
  4. Follower は上限付き page を取得し、祖先関係と署名を検証して checkpoint certificate を保持します。
  5. 設定済みの全 runtime witness が同じ短期 lease instance を許可している間だけ、新しい commitment Block を生成します。

起動時と実行時の強制

ロールバック検知と複製コーディネーターの同時稼働防止には、独立した二つの制御を使います。

  • 起動しきい値: UDP、TUN、API listener を開く前に、operator が固定した 3 witness のうち異なる 2 witness 以上から有効な署名証拠が必要です。
  • Runtime lease: 設定済み 3 witness の全てが active coordinator に短期 lease を付与します。一部更新は degraded となり、権限失効時には新規生産を停止します。
  • 復旧: witness 接続が戻った後、完全な新しい lease round が生産権限を回復し、集約 recovery counter を増やします。
<!-- commitment-ledger-flow-i18n-v1:end -->

障害時の動作

Witness の一部が応答しない間は既存 lease が有効な限り degraded として再試行し、期限切れ時は新しいコミットメント生産を自動停止します。remote-ahead または履歴分岐は起動を停止します。

renewal_degraded -> retry_until_expiry

expired -> coordinator_lease_production_permitted=false

remote_ahead | diverged -> startup_denied

公開可観測性

公開 API は検証ノード数、tip 高さ、コミットメント数、lease の集約状態のみを返します。hash、署名、Witness ID、endpoint、owner、内容は返しません。

text
GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/
data.protocol_status.memory_chain
json
{
  "mode": "signed_commitment_ledger",
  "status": "witness_protected",
  "verified_nodes": 4,
  "coordinator_nodes": 1,
  "follower_nodes": 3,
  "max_verified_tip_height": 33,
  "max_verified_commitment_count": 8339,
  "max_granted_witnesses": 3,
  "max_required_witnesses": 3,
  "network_consensus": "not_claimed"
}

コーディネーター、フォロワー、Witness、バックエンド、公開サイトは暗号文コミットメントと限定的な運用証跡だけを扱い、平文、復号鍵、所有者関係、ソーシャルグラフを受け取りません。

<!-- commitment-ledger-privacy-i18n-v1:start -->

プライバシー境界

中央／公開 contract から record ID、Block hash、署名、witness identity、endpoint、owner、ciphertext body、plaintext、route、client metadata、wallet-level traffic、social-graph edge を除外します。集約 commitment count は処理量を示しますが、記憶の内容や作成者を示しません。

<!-- commitment-ledger-privacy-i18n-v1:end -->

これは何ではないか

  • permissionless consensus、Byzantine finality、fork choice ではありません。
  • トークン台帳やスマートコントラクト基盤ではありません。
  • ノードが記憶平文を読める仕組みではありません。

Heartbeat

coordinator_lease_state, coordinator_lease_granted_witnesses, coordinator_lease_required_witnesses, coordinator_lease_seconds_remaining, coordinator_lease_production_permitted, coordinator_lease_last_failure_at, coordinator_lease_consecutive_failures, coordinator_lease_recoveries_total.

<!-- commitment-ledger-faq-i18n-v1:start -->

よくある質問

AeroNyx には現在 Block がありますか？

はい。commitment subsystem は署名済み Block で不透明な暗号化レコードの commitment を順序付けます。ただし、公開 blockchain や global consensus network と表現してはいけません。

Witness がオフラインになるとどうなりますか？

既存の権限が有効な間は一部更新を degraded として表示します。lease が失効するまでに全 witness の新しい許可を得られなければ、新規 commitment 生産は自動停止します。

Witness は MemChain の記憶を読めますか？

読めません。witness は署名済み commitment 構造と lease ownership を検証するだけで、plaintext record や復号鍵を受け取りません。

関連資料: MemChain and Decentralized Node Operations.

<!-- commitment-ledger-faq-i18n-v1:end --> <!-- aof-semantic-integrity-v1:start -->

ローカルの追記専用履歴を検証する

現在の AeroNyx 分散ノードは、記憶内容を一切出力せずにローカル MemChain 追記専用ファイルを検査できます。再起動、アップグレード、mirror 復旧、incident review のためのローカル完全性ゲートです。

検証対象

  • 正規かつ上限付きの record framing。デコード後の 1 record は最大 10 MiB。
  • 単独 Fact と Block 内の各 Fact が、内容から導出された fact_id と一致すること。
  • 各 Block の Merkle root が、保存順どおりの Fact ID と一致すること。
  • 連続 Block の height と previous-Block hash link が連続していること。
  • ファイルが完全な record 境界で終わること。不完全な物理 tail は別に報告されます。

読み取り専用コマンド

設定済み path、または明示した path に対して実行します:

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

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain
フィールド意味
valid_bytes完全かつ意味的に有効な record が占める byte 数。
fact_records / block_records単独 Fact record と Block record。Block 内 Fact は二重計上しません。
last_block_height最後に有効なローカル Block の height。
torn_tail_bytes最後の有効 record 以降に残る不完全な物理 byte。ゼロなら clean です。
statusverified は観測したファイル全体がローカル scan を通過したことを示します。

アップグレードと復旧のゲート

  1. binary 交換前に verify-aof を実行し、集約結果を command audit に残します。
  2. 新 binary を validate し、service 再起動前に同じ読み取り専用 scan を実行します。
  3. 再起動後、replay が同じか新しい height を復元したことを確認し、node health check を実行します。
  4. 完全な record が意味検証に失敗した場合は停止して証拠を保存し、truncate や自動 merge を行いません。

証明の境界

コマンドが出力するのは path と集約 count のみです。Fact 内容、record ID、Block hash、署名、owner、witness identity、endpoint、route、復号鍵は出力しません。Mirror または Full node は同期後、暗号化された記憶内容を知ることなく同じローカル byte を独立検証できます。

この scan は Block 署名検証、witness certificate、runtime lease、fork choice、consensus の代替ではありません。clean AOF が証明するのはローカル構造の完全性であり、全参加者の誠実性ではありません。

実装パス:

  • crates/aeronyx-server/src/services/memchain/aof.rs
  • crates/aeronyx-server/src/main.rs
<!-- aof-semantic-integrity-v1:end -->