本文へスキップ
Anon Wallet

プライベートペイマスターリレー

Anon は Oblivious HTTP（OHTTP）でウォレットのネットワーク識別情報と要求を分離します。リレーはブラウザー接続を受けますが復号できず、ペイマスターはリレーから受けた要求を復号・処理します。

目標は、単一の運用者が利用者の IP とペイマスターへの取引要求を結び付けられないことです。最終的にオンチェーン公開される情報は隠しません。

Wallet                 Independent relay                 Paymaster
  |                           |                              |
  | HPKE-encrypted request    |                              |
  |-------------------------->| opaque request               |
  |                           |----------------------------->|
  |                           |                    decrypt, validate,
  |                           |                    sponsor, and submit
  |                           |<-----------------------------|
  | encrypted response        |                              |
  |<--------------------------|                              |

sees: request + own IP        sees: client IP + ciphertext  sees: request + relay IP

プライベート要求の内容

ウォレットは署名取引、ゼロ知識証明、手数料見積もり、トークンをローカルで準備します。内部要求にエンコードし、現在の HPKE 公開鍵で暗号化します。

リレーは OHTTP の暗号化エンベロープだけを受け取り、取引、証明、トークン、アドレス、応答を読めません。HPKE 秘密鍵を持つペイマスターが開きます。Railgun の証明は引き続きシールド送金の詳細を保護し、リレーは接続と提出を伝送層で関連付けにくくします。

要求フロー

  1. ウォレットはリレー URL と独立して固定した Ed25519 署名鍵を持ちます。本番値は検出文書にも公開しています。
  2. リレー経由で GET /ohttp-configs を取得し、固定鍵で HPKE KeyConfig を検証します。リレーによる鍵の差し替えを防ぎます。
  3. ガス見積もりや対応トークンなど、識別情報のない公開読み取りも経由します。許可リストに限定し、上流の Cache-Control に従って保存できます。
  4. 実行・状態要求を HPKE で封印し、POST /gateway に message/ohttp-req として送ります。
  5. リレーは固定先へ暗号文を転送します。ユーザー入力で送信先を選ばず、オープンプロキシではありません。
  6. ペイマスターが復号し、証明、署名見積もり、手数料、取引を検証して受理した処理をチェーンへ提出します。
  7. 応答を暗号化し、リレーは読めないまま message/ohttp-res として返します。

各主体が観察できる情報

主体 観察できるもの 設計上観察できないもの
ウォレット 自身の要求、鍵、応答、接続 他の利用者の活動
リレー IP、暗号文サイズ、時刻、許可した公開パスとクエリー OHTTP 平文、ペイマスター秘密鍵
ペイマスター 復号要求、結果、時刻、リレー IP リレーと入口が IP 転送を除去した場合のクライアント IP
チェーン観察者 結果の取引が公開したデータと時刻 伝送中の OHTTP 平文

セキュリティ保証

  • リレーでの内容の機密性。 HPKE が各非公開要求と応答を暗号化し、リレーに復号・署名鍵はありません。
  • ペイマスターでの識別情報の分離。 クライアント IP ヘッダーを転送しなければ、接続元はウォレットではなくリレーです。
  • 鍵の置換への耐性。 リレー経路外で固定した Ed25519 鍵で更新 HPKE 設定を検証します。検出機能は信頼の基点の代わりではありません。
  • 暗号文の完全性。 改変は認証検証に失敗します。ただし破棄、遅延、再送は可能なのでアプリは再試行に安全である必要があります。
  • 限定された転送。 固定先、公開パス、Go の 1 MiB 上限、厳密なメディアタイプで汎用プロキシ化を防ぎます。
  • ブラウザー認証情報なし。 公開応答はワイルドカード CORS を使い、Cookie、認証ヘッダー、ブラウザー認証情報を使いません。

限界と前提

信頼を分離する道具であり、完全な匿名ネットワークではありません。

  • リレーとペイマスターは別主体が共謀せず運用する必要があります。観測を合わせると IP と要求が結び付きます。
  • 全体を観察する相手はサイズと時刻を関連付けられます。ミックスネットのような分析耐性はありません。
  • リレーは IP やメタデータを記録できます。脅威モデルに合う独立性とデータ方針を選びます。
  • 直接呼び出すとアドレスが伝わるため、設定、見積もり、実行、状態のすべてを経由させます。
  • 公開チェーンのメタデータ、時刻、アドレス再利用、取引が明かす値は隠しません。
  • 可用性は保証せず、遮断、遅延、制限、選択的拒否が可能です。

公開リレーを使う

Anon はブラウザー対応の https://relay.anon.inc を提供します。URL と署名鍵は https://anon.inc/.well-known/anon-paymaster.json にあります。

別の公開リレーには次が必要です。

  • 意図するペイマスターが転送先であること；
  • 同じ /ohttp-configs、/gateway、ガス見積もり・対応トークン経路を実装すること；
  • 利用元を許可するか互換 CORS を提供すること；
  • ペイマスターから独立運用すること；
  • 可用性、ログ、保存方針が許容できること。

クライアントから任意のペイマスターに向けることはできません。固定先はオープンプロキシ化を防ぐ意図的な設計です。運用者が送信先ごとに互換インスタンスを配置します。

自前のリレーを動かす

Go、Docker、Cloudflare Worker の全実装は github.com/anondotinc/paymaster-relay に公開済みです。テスト、配置設定、健全性確認、ブラウザーのプリフライト検証を含みます。

Go と Docker

Go は新しい上流要求を作り、クライアントヘッダーを転送しないため、最も強い IP 分離を提供します。コンテナー、VM、Kubernetes で動作します。

git clone https://github.com/anondotinc/paymaster-relay.git
cd paymaster-relay
docker build -t anon-ohttp-relay .
docker run --rm -p 8080:8080 \
  -e OHTTP_GATEWAY_URL="https://paymaster.example.com" \
  anon-ohttp-relay

コンテナーの前で TLS を終端し、リレー経路だけを公開します。適切な本文・レート上限を設定し、本文ログを避けます。

Cloudflare Worker

自分が管理するゾーンとドメインの Cloudflare アカウントに配置できます。フォーク後、worker/wrangler.toml を編集します。

  • 固有の Worker name を選択；
  • ドメインの routes[].pattern を置換；
  • TARGET を対象の HTTPS OHTTP ゲートウェイに設定。

リポジトリルートから配置して確認します。

make cloudflare-login
make deploy RELAY_URL=https://relay.example.com

Cloudflare が配置中に DNS と証明書を管理します。

Cloudflare の IP に関する注意: Cloudflare 外のオリジンへの Worker サブリクエストでは、CF-Connecting-IP にクライアント IP が入り Worker から変更できません。ペイマスター入口でログ・アプリ処理より前に除去する必要があります。保証できなければ Go リレーを使ってください。HTTP ヘッダーの資料を参照。

運用者の確認項目

  • ペイマスター組織から独立して運用します。
  • 意図する HTTPS ゲートウェイだけに接続します。
  • Cookie、認証値、ユーザーエージェント、IP ヘッダーを転送しません。
  • 本文ログを無効化し、メタデータ保存を最小化します。
  • OHTTP の正確な要求・応答メディアタイプを維持します。
  • 公開読み取り許可を絞り、上流のキャッシュ期限を守ります。
  • 安定したユーザー識別子を作らないレート制限を設けます。
  • /health を監視し、配置後に /gateway のプリフライトを確認します。
  • URL、運用者、ログ方針、対応ペイマスターを公表します。

参考資料