原文
ビットコインのジェネシスブロックから17年が経った今でも、暗号通貨の送金は開発者向けのタスクのように感じられます。受取人にウォレットアドレスを尋ね、42文字の16進数文字列をコピーし、正しいネットワークにいることを確認し、手数料を支払うためだけにガス代トークンを入手する必要があります。これらのステップのいずれかを間違えると、資金は永久に失われます。一方、誰かにメッセージを送るのは3秒で済みます。メールアドレスや電話番号を入力するだけです。
このUXギャップは些細な不便さではありません。これは、暗号通貨の大衆採用 (mass adoption) における最大の障壁です。明白な解決策は、これらの識別子をブロックチェーンアドレスに直接マッピングすることです。しかし、そうしようとする素朴な試みはすべて、ユーザーがますます重視する唯一のもの、すなわちプライバシーを犠牲にしてしまいます。あなたのメールアドレスを知っている人は誰でもあなたのアドレスを導き出し、そこからオンチェーンでのあなたの完全な金融履歴を再構築できてしまいます。
この記事では、このギャップをプライバシーのトレードオフなしに埋めるプロトコル、HFIPayについて議論します。
問題
暗号通貨を送金するには、送信者がウォレットアドレスを知っている必要があります。UXの改善があったとしても、そのフローは「アドレスを尋ねる → 16進数文字列をコピー → 正しいネットワークを選択 → ガス代トークンを入手 → 送金」です。
人間が使いやすい識別子、つまりメールアドレス、電話番号、ソーシャルハンドルは、すでに人々がオンラインでお互いを識別する方法です。自然な目標は次のとおりです。
alice@example.com にメッセージを送るのと同じ方法で、暗号通貨を送金する。
素朴なアプローチでは、識別子を決定論的にアドレスにマッピングします。例えば、keccak256(identifier) → address のようにです。これはシンプルですが、致命的なプライバシーの欠陥を導入します。アリスのメールアドレスを知っている人は誰でも、彼女のオンチェーンアドレスを導き出し、サポートされているすべてのチェーンで彼女の完全な取引履歴、トークン残高、取引相手との関係を調べることができます。
解決策：HFIPayとその機能
HFIPayはプロトコルであり、アプリケーションではありません。どんなウォレットや支払いアプリにも統合できます。プロトコルレベルで以下の特性を可能にします。
- 受取人のウォレット設定は不要 — 受取人が暗号通貨アプリを一度も開いたことがなくても、資金を送金できます。
- 列挙耐性 (Enumeration resistance) — オンチェーンデータは、既知のメール、電話、ソーシャルハンドルにどのインテントが属するかについて何も明らかにしません。
- クレーム前非リンク性 (Pre-claim unlinkability) — 同じ識別子への複数の支払いは、再利用可能なオンチェーンの受取人タグを残しません。
- 非カストディアルなクレーム (Non-custodial claim) — リレーはルーティングを行いますが、資金をリダイレクトすることはできません。受取人のみがZK証明を介して解放を承認できます。
- 識別子に依存しない (Identifier-agnostic) — メール、電話、Xハンドル、その他、検証可能なあらゆる識別子で機能します。
HFIPayプロトコルを使用すると、誰でも次のことができます。
- 誰にでも暗号通貨を送金 — 受取人のウォレットアドレスを知る必要はなく、ウォレットを持っているかどうかさえ知る必要はありません。
- 受取人は通知を受けて資金をクレーム — まだウォレットを持っていない場合、クレーム時にその場で作成できます。
- 初回使用後は自動クレーム — 受取人が一度クレームすると、それ以降の支払いは手動操作なしで自動的にクレームできます。
- 送信者は一定期間内にキャンセル可能 — 受取人がクレームしなかった場合、送信者はタイムアウト前に資金を取り戻すことができます。
- 未クレームの送金は自動的に返金 — 有効期限期間 (expiry window) 後、資金は手動介入なしで送信者に返還されます。
ENSとの比較
ENSはイーサリアムエコシステムで最も成熟したネーミングシステムであり、不透明な16進数アドレスを人間が読める名前に置き換えるという実際の問題を解決しています。HFIPayは異なる問題を解決しています。以下に中立的な機能比較を示します。
| ENS | HFIPay | |
|---|---|---|
| 識別子の種類 | .eth名（登録必須） | メール / 電話（既存、設定不要） |
| オンチェーンマッピング | 公開、列挙可能 | オンチェーンに保存されない |
| プライバシーモデル | アドレスは設計上公開 | チェーンはインテントごとの盲目化された値のみを認識 |
| 受取人設定 | 受信前に必須 | オプション（遅延オンボーディング可能） |
| 識別子の列挙 | 誰でも任意の名前をクエリ可能 | チェーンの状態は識別子を明らかにしない |
| 信頼の前提 | ENSコントラクト（分散型） | リレー（下記の信頼モードを参照） |
ENSとHFIPayは競合関係にありません。HFIPayリレーは、内部的に.eth名を他の識別子タイプの一つとして解決することができます。違いは、オンチェーンにコミットされる情報と、それに続くプライバシー保証にあります。
ERC-5564（ステルスアドレス）との比較
ERC-5564は、資金がオンチェーンの「どこに」着地するかを隠します。受取人のアドレスは一時的で、公開鍵にリンクできません。HFIPayは、より早い段階、つまり「人間が使いやすい識別子がオンチェーンの宛先にどのようにマッピングされるか」を隠します。
送信者は以下を知っている: alice@example.com
↓
[リレー: プライベート解決] ← HFIPayのスコープ
↓
オンチェーン: 盲目化されたインテント
↓
[受取人によるZKクレーム]
↓
宛先アドレス (ステルスアドレスの可能性あり) ← ERC-5564のスコープ
この2つのメカニズムは補完的です。HFIPayは、支払いごとに新しいステルスアドレスに資金をルーティングでき、識別子レベルとアドレスレベルのプライバシーを組み合わせることができます。
HFIPayのメカニズム（非公式）
このプロトコルは、3つの懸念事項を分離しています。
1. プライベートルーティング（オフチェーン）
送信者はalice@example.comを指定します。リレーはこれを登録済みの受取人レコードにプライベートに解決し、新しいintentIdをサンプリングします。ワンタイム入金アドレスを導出し、インテント固有の盲目化されたバインディング ρᵢと、提示された資産および金額のみをコミットします。チェーンは識別子も再利用可能な受取人タグも認識しません。
2. 送信者側での見積もり検証（オプション）
検証済み見積もり (verified-quote) デプロイメントでは、リレーは資金提供前に、ρᵢを意図された受取人の隠されたバインディングキーコミットメントにリンクするオフチェーンの証明 (attestation) を返します。送信者は資金提供前にこれを検証できます。これにより、リレーが密かに資金を別の受取人にリダイレクトすることを防ぎます。
3. オンチェーンクレーム承認
資金をクレームするために、受取人はゼロ知識（ZK-ACE経由）で、資金提供されたインテントの盲目化されたバインディングが、自身の決定論的IDから導出されたハンドルと一致することを証明し、選択した宛先への解放を承認します。リレーはルーティングと可用性に関与しますが、インテントに資金が提供された後で資金をリダイレクトすることはできません。
送信者 リレー チェーン
| | |
|-- alice@emailへ支払い --> | |
| | (プライベート検索) |
|<-- 見積もり (ρᵢ, τᵢ) --- | |
| | |
|-- インテントに資金提供 --------|---------------------> |
| | |
受取人
|
|-- ZKクレーム証明 ---> |
|<-- 資金解放 --- |
プライバシー特性
この論文では、2つの特性を定式化しています。
列挙耐性 (Enumeration resistance): 観察者が既知のメールアドレス、電話番号、またはソーシャルハンドルにどの資金提供されたインテントが属するかを、たとえその識別子を知っていてすべてのチェーンの状態を読み取ることができたとしても、オンチェーンデータから判断することはできません。
クレーム前非リンク性 (Pre-claim unlinkability): クレームが行われる前に同じ識別子に対して複数の支払いが行われても、再利用可能な公開の受取人タグは露出しません。各インテントは独立した盲目化されたバインディングを使用します。クレームが成功した後、宛先アドレスと資産額は（他のトランザクションと同様に）オンチェーンで可視になります。この論文では、クレーム後に何がリンク可能になるかを明示的に特徴付けています。
信頼モード
このプロトコルは、リレーに置かれる信頼の度合いを区別する2つのデプロイメントモードを定義しています。
ベースラインデプロイメント (Baseline deployment): リレーは、各インテントに正しい受取人をバインドすると信頼されます。リレーとアプリケーションが信頼境界を共有する統合ウォレットに適しています。
検証済み見積もりデプロイメント (Verified-quote deployment): リレーは資金提供前に、送信者検証可能な証明を発行します。別のバインディング層が識別子の所有権を（例えばメールOTPやOIDCを介して）独立して検証するため、リレーが異なる受取人に置き換えることは、送信者がそれを検出することなく行うことはできません。バインディングは、公開識別子レジストリなしで送信者が検証可能です。完全な形式的扱いは、論文のセクション2〜6に記載されています。
実装
私たちは**hfi.network**で、リレーインフラストラクチャとZKクレーム回路を含むオープンな実装を構築しています。リレーの分散化に関する初期の検討が進行中です。プロトコル設計と信頼モデルに関するフィードバックを歓迎します。
完全な論文：arXiv:2603.26970
正式なセキュリティ定義、バインディングエポックローテーションスキーム、または他の識別子ベースの支払い提案との関係について喜んで議論します。
3つの投稿 - 3人の参加者