Recoverian Network
非カストディ・ウォレットの鍵リカバリを支える、独立機関によるネットワーク構想。UPBONDはユーザーの鍵を復元できない——復元を支えるのは、独立した「リカバリアン」。
非カストディ・ウォレットの理想は、ユーザーだけが自分の鍵を管理できること。しかしその裏返しとして、鍵を失えば資産も失われます。UPBOND は設計上、ユーザーの鍵を復元できません。
だからこそ、復元を支えるのは UPBOND ではなく、独立した「リカバリアン」です。複数の独立機関が連なる Recoverian Network が、非カストディ性を保ったまま、鍵の復旧可能性をユーザーに届けます。
非カストディの、最大の課題
セルフカストディの最大の課題は鍵の紛失です。しかしウォレット事業者自身が復旧手段を握れば、それは「預かり」——カストディに近づきます。この二律背反を、構造で解くのが Recoverian です。
鍵を失えば、資産も失われる
セルフカストディでは、シードフレーズや端末を失った瞬間に資産へアクセスできなくなります。復旧手段がないことは、ユーザーにとって大きな参入障壁です。
事業者が復旧を握ると、預かりになる
ならばと事業者自身が復旧手段を保持すれば、ユーザーの資産を実質的に管理できてしまい、非カストディという前提が崩れます。
復旧を、独立機関に委ねる
復旧を支える鍵を、事業者でも UPBOND でもない独立した第三者機関が保持する。構造そのもので、非カストディ性と復旧可能性を両立します。
鍵ではなく、役割を分ける
国際公開済みの特許出願技術に基づき、鍵の復旧に関わる情報を3者に分離します。どの1者も、単独ではユーザーの鍵を復元できません。
| 当事者 | 保持するもの | 保持しないもの |
|---|---|---|
| ユーザー端末 | Device Share（端末上のシェア） | — |
| UPBOND | 暗号化されたリカバリ情報（暗号文）のみ | 復号鍵は持たない |
| リカバリアン | 復号鍵のみ | 暗号文・ユーザーの秘密鍵は持たない |
復号機能は、ウォレット提供者のサーバーに備わりません。 UPBOND は暗号文を預かるだけで復号鍵を持たず、リカバリアンは復号鍵を持つだけで暗号文を持たない。この分離こそが、非カストディ性の核です。
リカバリアンがユーザーの秘密鍵や資産を預かることは、一切ありません。 リカバリアンが保持するのは、自社の管理下で生成した復号鍵のみ。ウォレットの復元は、ユーザー自身の端末上で完結します。
単独機関ではなく、ネットワークにする理由
ユーザーのリカバリ情報は、複数受信者向け暗号化（envelope encryption、HPKE / RFC 9180 ベース）によって、各参加機関の公開鍵に個別にラップされます。1機関に依存しない構造が、ユーザーの復旧可能性を守ります。
どの1機関でも支援できる（any-of-N）
リカバリ情報は各参加機関の公開鍵へ個別にラップされ、いずれか1機関だけでも復旧を支援できます。
1機関の脱退・障害に強い
ある機関が脱退・障害に陥っても、他機関がカバーするため、ユーザーのリカバリ可能性は損なわれません。
後発参加機関も既存ユーザーをカバー
後から参加した機関も、統制された再ラップ手続きにより、既存ユーザーのリカバリに加われます。
将来は k-of-n へ発展可能
複数機関の協調を要する k-of-n 方式への発展も、設計上あらかじめ想定されています。
ネットワークを貫く、4つの設計原則
参加機関が増えても、ユーザーの非カストディ性と復旧可能性を一貫して守るための原則です。
秘密鍵は機関間を移動しない
各機関は鍵ペアを自社の HSM 内で生成・保持し、秘密鍵はネットワーク上を一切移動しません。
UPBOND は復号に関与できない
ウォレット提供者が復号操作に一切関与できない構造を、恒久的に維持します。
参加・脱退で再暗号化しない
機関の参加・脱退は暗号文の再暗号化を伴わず、ラップの追記・削除のみで完結します。
すべての復号は監査可能
あらゆる復号操作は、統制され監査可能なプロセスとして記録・運用されます。
リカバリアンに求める役割
大規模なインフラ投資は不要です。独立性と事業継続性のある機関——信託銀行・金融機関・監査法人・法律事務所等を想定しています。
鍵ペアの安全な保持
復号鍵ペアを自社の管理下で安全に保持します（HSM の利用を推奨）。
復号依頼への統制された応答
ユーザーからの復号依頼に対し、統制されたプロセスに沿って応答します。
監査への協力
復号操作の記録を残し、監査可能なプロセスの運用に協力します。
参加リスクは、構造で抑えられている
参加を検討する機関が抱く懸念に、正面から答えます。多くのリスクは運用努力ではなく、ネットワークの設計そのものによって抑えられています。
ユーザーの秘密鍵・資産を預かることになるのでは
預かりません。保持するのは自社の管理下で生成した復号鍵のみで、ユーザーの秘密鍵・資産・暗号文はいずれも保持しません。復元処理はユーザー端末上で完結します。
単独でユーザー資産にアクセスできてしまう立場になるのでは
構造上、不可能です。復号鍵だけでは何も復号できません（暗号文は UPBOND 側に保管され、リカバリアンは保持しない）。どの1者も、単独ではユーザーの鍵に到達できない設計です。
自社の鍵が漏洩したら重大事故になるのでは
影響は限定的で、即時に失効できます。漏洩した復号鍵単独では暗号文がなければ復号できず、当該機関向けのラップ（暗号化データ鍵）を削除すれば即時失効。鍵のローテーションも、暗号文全体の再暗号化なしに完了します。
自社の障害・撤退がユーザーの資産喪失に直結するのでは
any-of-N の冗長構造です。複数の独立機関がそれぞれ復旧を支援できるため、1機関の障害・脱退がネットワーク全体の単一障害点になりません。脱退もラップ削除のみで完結します。
大規模なシステム投資・専任組織が必要になるのでは
不要です。求められるのは、鍵ペアの安全な保持（HSM 推奨）、統制された復号依頼への応答、監査への協力のみです。
不正な復号依頼に応じてしまうリスクは
すべての復号はユーザー本人の依頼に基づき、統制・記録された監査可能なプロセスとして運用されます。