アカウント抽象：Web3採用の推進者であり、ゲームチェンジャー
TechFlow厳選深潮セレクト
アカウント抽象：Web3採用の推進者であり、ゲームチェンジャー
「鍵なし、トークンなし！」これはブロックチェーンのスローガンです。しかし、「秘密鍵」とは一体何なのでしょうか？
Web3業界の深掘り報道に専念し潮流を洞察
著者：Gal Ron、Stanford Blockchain Review
翻訳：TechFlow
*注：本稿はスタンフォード・ブロックチェーン・レビューからの寄稿です。TechFlowは同誌のパートナーであり、翻訳および転載の独占的権限を有しています。
「鍵なし、トークンなし！」これはブロックチェーンのスローガンである。しかし、「秘密鍵」とは一体何なのか？
現実世界の鍵は、その用途に応じて異なる。自転車のロックの鍵とBrinksの装甲車両用の高セキュリティ鍵は、まったく別物である。
しかし、イーサリアム上ではすべての鍵が同じ構造を持っている。価値や目的に関わらず、イーサリアム上のあらゆる操作には、ニーモニックフレーズを使って取引に署名する必要がある。そしてこのニーモニックフレーズは、アカウント所有者のみが知っているべき情報である。これは大きなUXの障壁であり、暗号資産の主流化を妨げる要因となっている。
アカウント抽象は、このようなパラダイムからブロックチェーンアプリケーションを解放するものだ。アカウント抽象という概念は、もともとVitalikが2015年に発表した記事で紹介されたもので、現在ではStarknetやzkSyncのようなLayer-2ブロックチェーン、およびEIP-4337を通じてイーサリアム本体でも実現されつつある。アカウント抽象は、Web3の強力な機能とWeb2のシンプルさ・使いやすさを融合させたものであり、セルフカストディ（自己管理）の拡張に向けた重要なマイルストーンである。
イーサリアムにおけるEOAとその制約
まず、イーサリアム上の暗号アカウントの仕組みを振り返ってみよう。イーサリアムには2つの基本的なエンティティがある：スマートコントラクトとEOA（外部所有アカウント）だ。
EOAとは、以下の特徴を持つエンティティである：
（1）秘密鍵から派生されるアカウントアドレス、
（2）手数料の支払いまたは他者へのETH送金に使用されるETH残高、
（3）リプレイ攻撃防止のために、そのEOAから送信された取引のシーケンス番号を記録する「nonce」と呼ばれる識別子。
イーサリアム上では、EOAだけが取引を送信できる。取引を有効とするためには、アカウントアドレスから派生された秘密鍵を使って署名する必要がある。つまり、「EOAを所有する」ということは、アカウントアドレスを派生させるために使われる秘密鍵を所有することを意味する。
イーサリアムのスマートコントラクトは完全にプログラマブルであるにもかかわらず、取引の有効性を検証するロジックはプログラマブルではなく、EVM（イーサリアム仮想マシン）にハードコードされている。有効な取引は以下のような一連のルールを厳密に遵守しなければならない：
-
署名方式。取引はECDSA署名方式で、secp256k1楕円曲線上で署名されなければならない。
-
取引手数料。取引手数料の資金源は、取引を開始したEOAと同じものでなければならない。また、手数料はETHで支払われなければならない。
-
リプレイ保護。取引は「nonce」識別子の番号順に順次送信されなければならない。
-
秘密鍵は不変である。アカウントアドレスは秘密鍵から派生するため、取引に署名するために使用する「秘密情報」を変更することは不可能である。
これらのルールはイーサリアムプロトコルに埋め込まれており、変更できない。これらはプロトコルの安全性とノードの動作効率を最適化するための設計上の意思決定に由来している。しかし、これらはdApp開発者の多くのユースケースを制限している。たとえば、EOAを使用している場合、別のアカウントが自分の取引手数料を支払うことは不可能だ。これは、各プレイヤーの最初の数回の「アクション」を資金援助したい分散型ゲームにとって貴重な機能となる。
他の状況では、ブロックチェーンユーザーが他のユーザーに自身を代理して取引を送信する権限を与えたいかもしれないし、取引の価値や頻度に一定の制限を設けたいかもしれない。これもEOAでは実現できない。
さらに、Web2ではパスワードのローテーションが基本的なプリミティブだが、EOAの「パスワード」を変更することは不可能であり、また、他の主体に完全なアカウントアクセス権を与えることなく、パスワードの復旧を依頼することもできない。
アカウント抽象
アカウント抽象とは、上記のハードコードされたロジックをEOAから切り離し、すべてのアカウントを完全にプログラマブルなスマートコントラクトに変えるという考え方である。これにより、アカウント所有者、ウォレット、dAppは、取引の署名方法や承認方法、および手数料の出所について柔軟に設定できるようになる。言い換えれば、アカウント抽象はスマートコントラクトウォレットを実現する技術的基盤である。
アカウント抽象の概念は、現在のEOAが抱える主な制約3つに対応して、以下の3つのカテゴリーに分けられる：
(1) 署名者抽象。ECDSA方式と固定された秘密鍵を唯一の許容可能な署名として強制するのではなく、スマートコントラクトに柔軟性を持たせ、有効な署名付き取引を独自に定義できるようにする。これにより、スマートコントラクトは共有シークレットに適した他の署名方式を受け入れたり、異なる関数に対して異なる署名方式を要求したり、あるいは全く署名を不要とすることさえ可能になる。
(2) 手数料抽象。イーサリアムでは、ユーザーがまずETHをアカウントに入れて手数料を支払い、アカウントを使い始める必要がある。dAppがユーザーの取引手数料を支援したり、ユーザーが希望する任意のトークンで手数料を支払い（リアルタイムでETHに交換）したりできるようなブロックチェーンアーキテクチャを想像してほしい。これにより、イーサリアムが現在直面している大きなUX課題の多くが解決されるだろう。
(3) Nonce抽象。これはアカウント抽象の中であまり議論されないが、より繊細かつ興味深い領域である。EOAの「nonce」識別子はリプレイ攻撃防止の役割を果たすが、同時に取引モデルを本質的に逐次的（シーケンシャル）なものに強制している。もしスマートコントラクトが同一EOAからの2つの並列取引を受け入れたい場合、その順序はどうでもよい。こうしたことが可能になるのは、「nonce」メカニズムがスマートコントラクトによって制御され、汎用的な取引処理ロジックにハードコードされなくなるときである。
セルフカストディの拡張
ビットコインのホワイトペーパーが発表されてから15年が経った今、現在の暗号資産ウォレットは依然として高メンテナンスであり、私たちが求めるスムーズな製品とは言えない。昨年のCEX崩壊は、自己管理こそが正しい道である一方で、秘密鍵の管理は依然として大きな負担とセキュリティリスクであることを教えてくれた。たとえコアな暗号開発者であっても、時々秘密鍵を失ったり盗まれたりすることがある（ツイート参照）。アカウント抽象を活用するスマートコントラクトウォレットは、こうしたリスクを解消し、自己管理ウォレットの大規模採用を促進する触媒となる可能性がある。アカウント抽象は、よりスマートな取引署名と優れたリカバリプロセスという2つのメカニズムを通じて、アカウント管理を容易にする。
まず第一に、署名者抽象機能により、ウォレットはWeb2の利便性を製品に組み込むことができる。たとえば、BraavosウォレットはiOSおよびAndroidデバイスのセキュアエンクレーブ（安全隔離領域）を活用し、ユーザーがニーモニックフレーズを一切入力せず、指紋や顔認証だけで取引に署名できるようにしている。同様の署名者抽象機能により、開発者は個別のケースごとに単一取引の承認に必要なセキュリティレベルを柔軟に制御できる。これにより、Web3ウォレットにおける真の多要素認証（MFA）が可能になる。オンライン銀行口座と同様に、日常的な取引は単一デバイスでのみ実行可能だが、新しい受取人への送金や高額取引では複数のデバイスでの署名を求めることができる。
アカウント抽象は、アカウント復旧のUXも改善する。署名者抽象により、1つのアカウントに複数の署名者が存在でき、それぞれが異なる権限と特権を持つことができる。たとえば、アカウントの主要所有者は友人に低権限の鍵を共有することで、友人が主鍵の復旧を支援できるが、アカウント内の資産は一切移動できないような仕組みを構築できる。これは一般的に「ソーシャルリカバリー」と呼ばれ、ArgentXウォレットなどのスマートコントラクトベースのウォレットで既に実装されている。
暗号決済のチャンス
暗号資産による決済は、ブロックチェーンの主要なユースケースの一つとして広く議論されてきた。しかし、この約束はまだ実現していない。過去には高額な取引手数料が原因だったが、レイヤー2やスケーラビリティソリューションの登場により、その費用は低下しつつある。しかし、伝統的金融分野で成熟した決済ソリューションが成功している理由は、低い取引コストだけではない。クレジット付与、詐欺検知、紛争処理、定期支払いといった機能も必要なのである。
アカウント抽象は、こうした従来の決済概念を暗号資産の世界に持ち込むことを可能にする。たとえば、Visaは最近、アカウント抽象を用いて定期支払いシステムを設計するプロトタイプを提案した。毎回の取引でユーザーの署名を必要とすることなく、Visaが上限額まで自動的に資金を引き落とせるように承認できる、プログラマブルなセルフカストディウォレットを想像してほしい。
ゲームUXとWeb3の出会い
バッチ取引と手数料抽象化により、Web3ゲームはアカウント抽象の恩恵を大きく受けるもう一つの分野となる。
ゲームアクティビティをブロックチェーン上に導入する主な障壁は、すべてのオンチェーン活動に取引署名が必要であり、これが取引コストを超えてしまう可能性がある点にある。ユーザーにウォレット上で「署名」ボタンをクリックするよう促すことは、ゲームの流れを中断させ、Web3ゲーム体験を非常に面倒なものにしてしまう。
アカウント抽象により、ゲーム開発者は特定の期間内に限定されたゲーム取引の事前承認を可能にする「セッション鍵」を作成できる。これらの鍵はブラウザやスマートフォンのローカルストレージに保存され、必要に応じて取り消すこともできる。これにより、Web3ゲームの体験はWeb2ゲームに近づく。
さらに、手数料抽象化により、ゲーム開発者がユーザーの取引手数料を負担できるようになる。これは、暗号資産に不慣れな新規プレイヤーや、まずはゲーム体験を試してから後で手数料を支払いたいと考えるプレイヤーを惹きつけるのに特に効果的である。
今後の展望
アカウント抽象は、常にイーサリアムのロードマップの一部であった。EIP-86（2017）、EIP-2983（2020）、EIP-3074（2020）といったイーサリアム改善提案は、EIP-4337（2021）の道を paved した。EIP-4337は、スマートコントラクトウォレットを運用するための新たな分散型インフラを導入したものである。
EIPに加えて、GnosisのようなスマートウォレットdAppがイーサリアム上に登場している。しかし、これらすべてはイーサリアムのネイティブアカウントモデル（すなわちEOA）に比べると二級市民的な存在である。
イーサリアムの制約を克服し、スマートコントラクトウォレットを一般ユーザーに届ける機会は、おそらくLayer 2スケーリングネットワークを通じて実現されるだろう。StarknetやzkSyncのようなLayer2は、プロトコルレベルでアカウント抽象を組み込んでおり、開発者がネイティブツールやインフラを簡単に利用できるようになっている。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
Stanford Blockchain Club
