Web3アカウントの概念整理：ウォレットの使い方で迷わない
TechFlow厳選深潮セレクト
Web3アカウントの概念整理：ウォレットの使い方で迷わない
先ほど終了したDevconで登場したいくつかの用語や概念は何を意味するのか？
Web3業界の深掘り報道に専念し潮流を洞察
執筆：知県、UniPass創業者
先日終了したDevconでは、アカウント抽象（Account Abstraction）は最もホットな話題の一つであり、ここ最近、AA / EOA / SCW / 4337といった略語やコードネームがさまざまなトーク、パネル、情報フィードに頻繁に登場している。
さらに「次なる10億ユーザーのオンボーディング」へ向けてのストーリー展開が始まっていることもあり、製品の前にseedless / gasless / social recovery / non-custodialといった新しい形容詞も登場し始めている。
この二文を読んですでに頭が痛くなってきたことだろう。そこでここからは、これらの用語が一体何を意味するのか、できる限り分かりやすく整理していきたい。
閲覧前の注意：本稿は厳密な技術文書ではなく、正確ではないかもしれないが理解しやすい表現や比喩を用いる場合があります。これらを出発点として、読者の皆さんが個別の技術の詳細を深く探求されることを期待しています。
EOA - Externally Owned Accounts
EOAは中国語で外部アカウントと呼ばれる。MetaMaskが生成するアドレスはEOAそのものである。その特徴はシンプルな原理に基づいており、たとえば生成ルールは次の通り：
このルールが非常に直接的であることがわかる。すべて数学的な変換によって計算され、生成されたアドレス自体には内部構造やロジックが一切含まれていない。ノードが取引がアドレス所有者によって承認されたかを検証する際のルールも固定されている：
比較結果が一致すれば署名検証成功となり、以降の処理へ進む。一致しなければ拒否され、取引は広くブロードキャストされない。
EOAのもう一つの仕様は、取引の発信元としてgasを支払う役割を持つことである。これに対して、CA（コントラクトアカウント）は他のCAまたはEOAからのみ呼び出される。つまり、EOAは取引のトリガーであり、後続にいくつコントラクト呼び出しがあろうとも、最初に必ずEOAが取引を開始し、十分なgasを支払わなければならない。
なお、EOAという概念はイーサリアムおよびEVM互換チェーン（あるいは類似EVMチェーン）に特有のものであり、厳密にはBTCを含む主要な非EVMチェーンにはこの設定はない。
CA - Contract Accounts
CAは中国語でコントラクトアカウント（かつては内部アカウントとも呼ばれた）。よく見かけるERC-20トークンコントラクト、DeFi業務コントラクトなども、EOAに酷似したアドレスを持っているが、これがまさにCAである。
設計上、CAはイーサリアム世界の原住民であり、EOAとETHはCAのビジネスロジックを動かすためのトリガーや燃料に過ぎない。実際の運用では、イーサリアム上のETH以外のすべての資産はCAによって保持されており、DeFiなどの業務ロジックもすべてCAによって実現されている。しかし、CAが自ら操作を実行したりgasを支払ったりできないという制限もあり、能力に制約がある。すでに2016年に提案があり、CA自身がgasを支払えるようにすることを目指していた。
簡単に言えば、CAとは内部ロジックを持つイーサリアムアカウントであり、その中には会計用のトークンコントラクトや貸付・決済のステーキングコントラクトといった業務ロジックもあれば、gnosis safeのようなマルチシグロジックといったアカウント管理ロジックも含めることができる。後者がまさにこれから触れる「SCW - スマートコントラクトウォレット」という概念になる。
CAのアドレス生成ルールは計算によって決定され、CREATEとCREATE2の二つの方式がある（ここでは詳述しない）。重要なのは、CAと公開鍵の間に必然的な対応関係がないことだ。たとえばgnosis safeで作成されたCAでは、任意の複数の公開鍵を設定してアドレスに対応する資産をアンロックできる。また、CAは鍵を一切設定せず、他のCAのロジックによってアンロック可否を決めることも可能だ。例えばDeFiのローンコントラクトでは、返済さえすれば担保資産を取り戻せる。
SCW/A - Smart Contract Wallet/Account
スマートコントラクトウォレットは、言葉の通り理解しやすい。つまり、アドレスとしてCAを利用するウォレット方式であり、一般的に使われるEOAウォレットは前述の公開鍵変換結果をアドレスとする。
内部ロジックを持つため、スマートコントラクトウォレットはEOAでは実現できない多くの機能を提供できる。たとえばgas代行支払い、一括取引、権限管理、オフライン承認、ソーシャルリカバリーなどがある。
以下にスマートコントラクトウォレットの拡張可能性を示す具体例をいくつか挙げる：
-
Gnosis Safeはスマートコントラクトウォレットのアーキテクチャを活用してマルチシグロジックを実現；
-
ユーザーは一度のオンチェーン取引で複数のアドレスに異なるトークンを送信でき、Uniswapを使う際にapproveとswapを同一取引内で完結させることも可能。これにより必要な範囲でのみ承認を行い、過剰承認によるセキュリティリスクを回避できる。
-
ユーザーは資産ごとに異なる操作権限を設定できる。たとえばPFPに対して通常のERC-20トークンより高い操作ハードル（ハードウェアウォレットで管理されたadmin keyが必要など）を設けることで、日常使用環境での鍵漏洩があっても高価値資産を転送されず、安全性と利便性のバランスを取れる。
-
ユーザーは「100ETHを渡せば私のBAYCを譲渡できる」というオフライン承認を署名できる。これにより第三者コントラクトへの承認なしに、他ユーザーとP2Pでアトミック取引を完結できる。
AA - Account Abstraction
アカウント抽象はまったく新しい概念ではない。2015年の議論まで遡ることができ、当時Vitalikは少なくともイーサリアムの取引検証に使う暗号アルゴリズムを交換可能にするべきだと主張していた（性能の優れたed25519などへの置換、詳細はこちら）。7年間、VitalikとEFはアカウント抽象の議論と探索を続けてきた。歴史を振り返るための整理済みlink treeもある。
それではアカウント抽象とはどう理解すべきか？ここではERC-4337における目標説明を引用する：
アカウント抽象の主要な目標を達成する：ユーザーがプライマリアカウントとしてEOAの代わりに任意の検証ロジックを持つスマートコントラクトウォレットを使用できるようにする。ユーザーがEOAを持つ必要性を完全に排除する（現状のSCウォレットやEIP-3074ではまだ必要）。
イーサリアムがアカウント抽象に期待するのは、現在大多数がEOAを使っている現状を変え、ユーザーがSCWに移行し、エコシステムのEOA依存を完全に解消することである。ここで言及されたEIP-3074以外にも、より急進的かつ長期的なEIP-5003がある。以下に原文の一部を引用する（省略あり）：
EOAは…プロトコルによってさまざまな重要な面で制限されている。これらのアカウントは、セキュリティのための鍵ローテーション、ガス節約のための一括処理、ETHを自分で保有する必要を減らすスポンサード取引などをサポートしていない。コントラクトアカウントやアカウント抽象化から得られる無数のメリットがある。たとえば、独自の認証アルゴリズムの選択、支出限度額の設定、ソーシャルリカバリー、鍵のローテーション、能力の任意かつ推移的な委任、そして私たちが想像できるほぼすべてのこと。
…このEIPは、EOAを永続化させるのではなく、一度きりの移行経路を提供する。
EIP-5003の目標は、EOAをCAに一括変換し、すべてのユーザーがSCWを使えるようにして、前方互換性の問題を根本的に解決することである。（ここまで用語の説明を読んで、これらの略語も読みやすくなったのではないだろうか？）
以上でAAの来歴と将来像についてある程度理解できたと思う。ただし、AAという概念はイーサリアムやEVM専属ではない。多くのチェーンはもともと不同程度のAA特性を備えている。
たとえばEOS / Polkadot / Near / Solana / Flow / Aptos… さらにはBTC（単一署名／マルチシグ／Taproot）まで、これらのチェーンは設計段階でアカウントに内部構造を持たせたり、権限管理機能を備えていたりする。StarkNet / CKBなどはさらに高度なアカウント抽象能力を持つ。
ここまで読めばわかるように、イーサリアムのAAは、EOAが予期せず普及したことによる歴史的負債を解決し、アカウント層をより進化させ柔軟にする取り組みなのである。
4337 - ERC 4337
上記のAAに関する議論から明らかなように、ERC-4337はその方向性の一つに過ぎないが、なぜAAやSCWと言えばすぐにこれが話題になるのか？そのドキュメントの副題を見てみよう：
コンセンサス層のプロトコル変更を完全に回避するアカウント抽象提案。代わりに上位レイヤーのインフラに依存する。
つまり、ERC-4337はAAのアプローチを「暴力革命」から「平和的進化」へと転換した最初の事例であり、コンセンサス層の変更を追求せず、代わりにユーザー層のSCW方式を採用した。さらに相互運用性を高めるため、ERC-4337はSCWが実装すべきインターフェースや、メタトランザクションのパッケージング、gas代行支払いなどのインフラフレームワークを定義している。
これにより、現在大きく異なるさまざまなSCW方式が統一されたユーザーエクスペリエンスを持ち、エコシステムが構築した共通インフラを共有できるようになり、さまざまなシナリオでのSCW導入が迅速に進められる。
一方で、ERC-4337の推進は、EIP-1271のような署名検証や、一部DeFiプロトコルがCAとのインタラクションを禁止するルールなど、エコシステムの他の参加者がSCWとの互換性を高める動きを促進する効果もある。
Seedless
ここで言うseedとはseed phrase（シードフレーズ）のことで、ウォレット作成時にバックアップを求められるあの「助記詞」を指す。「seedless」つまり「助記詞不要」、あるいは「秘密鍵不要」を意味する。ただし「不要」とは、実際に鍵がないという意味ではなく、ユーザーが助記詞／秘密鍵をバックアップする必要がなく、存在を意識する必要もないことを指す。
よくある疑問は、「もしユーザーが助記詞をバックアップしなければ、本当にアカウントを制御できるのか？新しい端末に切り替えたときにアクセスできなくなるのではないか？」ということだ。
確かに、ただユーザーの助記詞バックアップ機能を削るだけなら製品設計の失敗だが、seedlessが目指すのは、ユーザーが助記詞の存在を「知る必要がなく」、それでも完全にアカウントを制御できる状態である。
つまり、ユーザー（本人のみ）が新しい端末でアカウントの制御を自主的に回復できる能力を持つが、もはやUXが悪く、極めてgeek的な助記詞方式に頼らないのだ。以下で述べるソーシャルリカバリーなどがその好例である。
Gasless
ここで言うgasとはgas fee（手数料）のこと。よってgaslessとは「手数料無料」を意味する。もちろん、gaslessだからといって本当に手数料が発生しないわけではない。ユーザーがgasの概念を強制的に理解する必要がなく、あらかじめさまざまなネイティブトークンを購入して支払う必要もない、ということだ。
では、誰がgasを支払うのか？二通りの場合がある：
-
ユーザーのアカウントにすでに暗号資産がある場合。Play-to-Earnで得たトークン、エアドロップ、他人からの送金など。これらのトークンに一定の価値と流動性があれば、リレーヤーがそれを受け取り、ユーザーの代わりにgasを支払い、利益を得ようとする。
-
ユーザーのアカウントに価値のあるトークンがない場合（新規作成直後など）。このときオンチェーン操作が必要であれば、アプリ側がユーザーに特定用途の「限定的」gasを支援することで初期体験を助け、ユーザー離脱を防ぐことができる。この場合、gas補助のコストを含めても、全体の獲得コストが逆に低くなる可能性がある。あるいは、ユーザーが広告視聴などの行動を通じてgasを獲得する仕組みも考えられる。
これらの戦略はgasコストが低いL2上で特に効果的である。
Social Recovery
ソーシャルリカバリーとは、鍵を紛失した際に、ソーシャルな関係性を利用してユーザーが再びアカウントにアクセスできるようにする仕組みである。WeChatで新端末にログインしたとき、「二人の友人にxxxをあなたのアカウント宛に送信してもらい、ログインしてください」という経験があるだろう。ソーシャルリカバリーが目指すのはまさにこの体験であり、検証主体がWeChatからスマートコントラクトに変わるだけである。
よくある誤解は、ソーシャルメディアアカウントを使ってウォレットを作成・ログインする仕組みをソーシャルリカバリーと呼ぶことだ。これは「ソーシャルな関係性」と「ソーシャルプラットフォームのアカウント」を混同している。老舗のスマートコントラクトウォレットArgentは内蔵のソーシャルリカバリー機能を持ち、ガーディアンにイーサリアムアドレスを提供してもらい、新端末ログイン時に署名を要求する。しかし、この方式の潜在的課題は、ガーディアンがあなたよりもイーサリアムアカウントを適切に管理できている必要がある点にある。もし彼らが自分のアカウントにアクセスできなくなれば、あなたのアカウントも巻き添えを食らってしまう。そのため、より現実的な方法として、emailの暗号学的証明（DKIM署名）や電子パスポートなど、日常生活でよく使われる暗号ツールを活用してソーシャルリカバリーの実用性を高めるべきである。
Non-custodial
ノンカストディアル（非預託）は、crypto業界で最も政治的に正しく、同時に最も乱用されている概念の一つかもしれない。なぜなら多くの企業がそれぞれ独自の定義を持っているからだ。ここでは私たちの定義を共有したい。主に二点ある：
-
ウォレット開発者が勝手にユーザーのアカウントを操作できない
-
ウォレット開発者がユーザーの操作を阻止できない
もしこの二点に同意するなら、あるウォレットがカストディアル（預託）、半預託、ノンカストディアルのいずれに該当するかは、この二つの基準で検証できる：
では、どれがどのタイプかを知ることが何か意味があるのか？ユーザーは背後の原理なんて気にせず、使いやすければいいだけではないか！確かに、この意見の一部には賛同する。少なくとも今の段階では、業界はユーザーの認知モデルが変わるほど成熟していない。実は、これら三種類の方式はそれぞれ異なるシーンに適していると考えている：
-
カストディアル方式：取引所、大規模機関向け金融サービス、厳格なコンプライアンス要件のあるシーンに適している。Coinbase / Fireblocksなどが提供するサービスが例。特徴はユーザー数が少なく、高頻度のインタラクションを必要とせず、単価が高く、サービスプロバイダーが高コストの防御システムを維持できる。
-
半預託方式：比較的上級な個人ユーザー層に適している。サービス提供者が取引を審査できることを理解しており、事前にバックアップ策（秘密鍵のエクスポートなど）を準備できる。サービス提供者が主動または受動的にサービスを停止しても、資産の安全を守れる。日常的には安全性と利便性を享受でき、緊急時には資産を保護できる。ただし、この方式はサービスプロバイダーの運用能力も非常に高いことが求められる。個人ユーザーが多く、アプリとの日常的なやり取りも多いため、データ可用性も重要。サーバー側のデータを失えば、バックアップのないすべてのユーザーが永久にアカウントにアクセスできなくなる可能性がある。
-
ノンカストディアル方式：マスアダプションを狙うシーンに適している。一見反直感的かもしれないが、コスト面では、低単価のシーンで十分な安全性と可用性を保てる唯一の方式である。大規模ユーザーを対象とするアプリが上記二つの方式を選択する場合は、そのプロバイダーが自社のユーザー層に十分安全で可用性の高いサービスを提供できるか慎重に検討すべきだ。そうでなければ、内部不正、ハッカー攻撃、不可抗力によるサービス停止が発生した場合、すべてのユーザーが被害を受け、事業も致命的な打撃を受ける可能性がある。歴史の数えきれない事例が一つの教訓を教えてくれる：セキュリティは些細なことではない。ユーザーを守ることは、自分自身を守ることなのだ。
MPC - Multi-Party Computation
マルチパーティ計算（MPC）はゼロ知識証明（ZKP）とともに、現在のWeb3における二大「魔法」と称されることがある。これらに関わると、以前は不可能だったことが突如可能になるように感じられる。実際、ある意味ではそうなのだが、特にZKPは確率を使って実現可能性を高める。MPCは制御権を分散させることでリスク管理や災害対策能力を実現する。
MPCは一種のパラダイムであり、多くの技術方式を包含するが、現在のWeb3の文脈では多くがtssを指している。
TSS - Threshold Signature Scheme
閾値署名方式（TSS）は、分散型のマルチパーティ署名プロトコルであり、分散鍵生成、署名、および公開鍵を変えずに秘密鍵の断片を再分配（re-sharing）するアルゴリズムなどを含む。
m-nのTSSとは、一つの公開鍵に対してn個の秘密鍵断片があり、そのうちm個の断片による共同署名が公開鍵で検証できるという方式である。このロジックはマルチシグに似ているが、主な違いは公開鍵の数にある。
たとえば、2-2のマルチシグはドアに2つの鍵がかかっており、両方の鍵で開錠する必要がある。2-2のTSSはドアに1つの鍵がかかっているが、その鍵は2つのピースからなり、合体させて初めて開錠できる。わかりやすさのために多少不正確だが、2つの鍵を1つに合成するイメージはむしろShamir Secret Sharingに近い。TSSの鍵断片は物理的に出会わず、それぞれが署名した後、特定のアルゴリズムで対応する公開鍵で検証が通る。
ではTSSは必ずカストディアルまたはノンカストディアルなのか？実は必然的な関係はない。最終的な設計と選択に依存する。ノンカストディアル方式ではユーザーがアカウントを独立して操作できる必要があるため、ユーザーは閾値以上の鍵断片を保持していなければならない。たとえば2-3であればユーザーは2つの断片を握る必要がある。2-2の方式ではノンカストディアルは不可能で、せいぜい半預託（ZenGoなど）にとどまる。しかし、ユーザーが最も多くの秘密鍵断片を管理すればするほど、その能力要求は上がり、マスアダプションは難しくなる。
最後に
ここまでで、よく使われるWeb3アカウント関連の用語はほぼ網羅できたはずだ。文字数も約5,000字に達した。これほどの内容では間違いや漏れが避けられないが、ぜひ忌憚なくご指摘いただきたい。問題点や異なる見解があればTwitterで私に連絡してくれ（@frank_lay2）。今後内容に追加や修正があれば、Twitterで随時共有していく。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
