アカウント構造の再定義：なぜ3鍵システムが理想的な解決策なのか？
TechFlow厳選深潮セレクト
アカウント構造の再定義：なぜ3鍵システムが理想的な解決策なのか？
入門時にユーザーにウォレットソフトウェアのインストールやリカバリーフレーズの保存を求めることは好ましくありません。私たちは、使いやすく、比較的安全で、一定の先見性を備えた方法が必要です。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Norswap
編集：TechFlow
私は0xFableのために、ウォレットとユーザーのオンボーディングについて多くのことを考えました。以下に私のいくつかの見解を示します。議論するトピックは：
-
私が理想とするアカウント構成；
-
セキュリティに関する考察；
-
現存するWeb3ログインプロバイダーの概要
明らかに、ユーザーにウォレットアプリのインストールやニモニックフレーズの保管を求めるようなオンボーディング手法は望ましくありません。私たちは、使いやすく、比較的安全で、ある程度先を見据えた方法が必要です。
構成
各ユーザーには、以下の3つの鍵を持つスマートアカウントが与えられます：
-
デバイス鍵――初期段階ではローカルに保存可能ですが、将来的にはパスキー／WebAuthnの利用を目指します。
-
補助鍵――プロバイダーが管理し、ソーシャルログインで解除可能な鍵。
-
バックアップ鍵――第三者が保管（単純にメールの添付ファイルやDropbox／Google Drive上に保存することも可）。
これが技術的に劣っている、あるいは安全ではないように思えるなら、おそらくあなたはプロバイダーの甘い言葉に騙されています。実際のところ、彼らの提供する仕組みはこれ以上安全ではありません（むしろ多くの場合、より脆弱です――例えば、上記の鍵(2)と(3)が同一の主体によって管理されているケースなど）。
この構成では、デバイス鍵を使ってユーザーの介入なしに操作を行うことができます。資産の送金や取引など重要な操作では、補助鍵の使用を要求できます。
シンプルなパターンとしては、ユーザーがGoogle／Apple／Facebookなどでログインし、確認プロンプトを追加する方法があります。これにより、オンボーディングが非常に簡単になります。一方で、ユーザーがより高いセキュリティを求める場合には、この鍵の代わりに従来のEOAを使用することも可能です。また、任意の鍵ペアを使ってバックアップ鍵を再生成でき、バックアップ鍵自体はクラウド上に保存されたファイルとして扱うだけでよいのです。
セキュリティ分析
これはどれほど安全でしょうか？ 多くの場合、十分に安全です。資金の損失が起こるのは、2つのデバイスまたはエンティティが同時に侵害された場合に限られます。
ただし、構成ミスによってセキュリティが低下するリスクがあります。例えば、Google Drive上にバックアップ鍵を保存しつつ、補助鍵を自分のGoogleアカウントに割り当ててしまうこと。あるいは、デバイス鍵と同じリスクを抱えるホットウォレットを補助鍵として使うこと。ユーザーがバックアップを紛失してしまう可能性もあります。定期的にデバイス鍵のローテーションを促すことで、ユーザーにバックアップ鍵の存在を思い出させるとよいでしょう。
バックアップ鍵が公開場所に保存されていれば、盗難のリスクも非常に高くなります。これは、ディスク上で鍵を暗号化し（メモリ内で復号にはパスワードが必要）、より安全なホットウォレットよりも悪い状況です。いずれにせよ、パスキーの導入（デバイス認証によるアプリへのログイン）によって、この問題は解決されます。
認識すべきは、ソーシャルログインはプロバイダーを信頼することに他なりません。プロバイダーは基本的に、自由に使える鍵を持っていますが、「あなたがソーシャルアカウントでログインした後だけ、あなたの指示通りに使う」と約束しているのです。最後に注意すべき点として、補助鍵がDApp開発者によって提供されている場合、あるいは確認プロンプトがない場合、DApp開発者は容易にユーザーを欺くことができます（フロントエンドはデバイス鍵を持っており、かつ補助鍵も所有または制御できるため）。
現存するプロバイダーの概要
現在、これを提供している企業はありますか？ 私の知る限り、いません。よくある問題は、バックアップ鍵がないか、同じ主体がそれを管理していることです（例：Coinbase Wallet）。
市場は主に二つのカテゴリに分けられます：
-
スマートアカウント、またはMPC（マルチパーティ計算、暗号技術）を用いて複数の鍵を1つのEOAに統合する、多鍵対応のソリューションを提供するプロバイダー。
-
ユーザーの鍵を保管し、ログイン後に署名を可能にする、より低レベルのプロバイダー。
全スタックプロバイダーには次のようなものがあります：Particle Network、Privy、Alembic Tech、Magic、Web3Auth、Turnkey、Dynamic、0xPass、Fireblocks、Portal、Capsule、ZeroDev、Keyp、Circle Developers。
鍵保管プロバイダーには：Lit Protocol、Amazon などがあります。
はい、これらは多数存在します。実質的に大きな違いはありません。ビジネスモデルが明確な場合、これらは通常、ユーザーあたり年間0.02〜0.05ドルの課金を行います。私にとっては、これはかなり妥当な価格に思えます。
興味深いことに、これらすべてが開発者ツールとして位置づけられています。これらの技術を活用して、ユーザーの主要ウォレットとなる企業は、今のところ存在しないようです。
もちろん、既存のDAppと連携するには、ウォレットアプリのインストールが必要です。そのため、システムの利点は「ニモニックフレーズの排除」に限定されます。しかし、DAppに対して「最も簡単なオンボーディング手段」として自社を宣伝することもできます（もしDApp側があなたを統合すれば、ウォレットアプリのインストールさえ不要になる）。こうすれば、あなたはユーザーを獲得でき、DApp側は無料で簡単にオンボーディングを実現できます。双方にとってメリットのある関係です。
プロバイダーに関する懸念
私が理想とする構成を実装していないという点に加え、これらのソリューションはしばしばREST APIや特定のMPC計算といった大きな中央集権的要素を導入しています。もしプロバイダーがサービスを停止すれば、それらの計算は自分で行うことができません（公開されているのか？監査されているのか？）。
また、プロバイダーとの提携をやめた場合にどうなるかも不明確です。彼らは（一部の）ユーザーの鍵を握っているのです！ これは私がRollups-as-a-service（RaaS）に対して抱く懸念と非常に似ています。
その後、あるRaaSの創業者から聞いたのですが、「簡単に脱却できるようにすること」と「創業者がユーザーをだまして利益を得る行動を抑止する」ことの間にはトレードオフがあるそうです（それはRaaS業界全体の評判を損なうことにもつながるため）。
以下のようにすれば、上記の構成でプロバイダーの切り替えが容易になります。ユーザーはチェーン上に自身のソーシャルアカウントのハッシュ（例：[email protected]）を提出します。各ソーシャルログインプロバイダーは独自の秘密鍵を持ちます（ユーザーごとに個別の鍵を持つ必要はなく、通常、それがより安全というわけでもありません）。スマートアカウントはシングルトンコントラクトを参照し、その中には現在のプロバイダーのアカウントが保存されています。プロバイダーの切り替えとは、このアカウントを変更するだけの簡単な作業です。
最後に
明らかに、我々は理想的なオンボーディングの方向に向かっています。理想は、このような簡単なオンボーディングを提供するウォレットがユーザーと直接関係を築くことです。そしてDAppはこの問題を無視し、単にウォレットとパートナーシップを結び、「どのウォレットをデフォルトのログイン手段とするか」を決めるだけで済むようになることです。
それができない場合、私の解決策は自前でシステムを立ち上げることです――上記の構成に基づき、独自のソーシャルログインプロバイダーを作るのは難しいことではありません。しかし、私は「できれば」外部のプロバイダーを利用したいと考えています。前述したように、DApp開発者が無料の鍵を制御している場合、システムは完全に非中央集権的とはいえなくなるからです。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@norswap
