Account Abstraction（アカウント抽象化）とは？

ブロックチェーン通信
2023/01/22 00:16

Part 1: AAが暗号の普及に向けたゲームチェンジャーとなる理由

TwitterでVitalikをフォローしている人なら、「Account Abstraction（以下AA）」について聞いたことがあるかもしれません。Vitalikは、AAの実装はEthereum開発者の長年の夢であったと述べており、同時にいくつかの提案を行っています。

また、代表的なL2ソリューションであるStarkNetとzkSyncが、ネイティブなAAのローンチを発表したことも聞いたことがあるかもしれません。

しかし、AAとは一体何なのでしょうか？

また、なぜそれが暗号の普及にとってのゲームチェンジャーとなり得るのでしょうか。

このブログ記事はシリーズ化する形で、これらの疑問にお答えしていきたいと思います。最初の投稿では、イーサリアムアカウントの制限について解説します。そして、AAがどのようにこの問題を解決するのかを説明します。

要約すると、AAは暗号を、小さなミスで全てを失う可能性のある現在の「ワンアカウント・フィット・オール」のアプローチから、アカウントをユーザーニーズに合わせてカスタマイズできる仕組みに移行させるものです。つまり、セルフカストディのためのセーフティネットを構築することができるものであり、より洗練されたUXの提供を可能にします。

これは、シードフレーズや中央集権取引所に頼る怖い世界に代わるものとして、セルフカストディを人々にとっての選択肢とするための画期的な取り組みです。

では、さっそく中身を見てみましょう：

イーサリアムアカウントはどのように機能するのか？
AAを理解するためには、まず現在のイーサリアムでアカウントがどのように動作しているかを理解する必要があります。

イーサリアムには2種類のアカウントが存在します：

外部所有アカウント(EOA)
Contract Accounts (CA)

この記事では、ユーザーにとって現状より重要なEOAに焦点を当てます。コントラクトアカウントについてより詳細を知りたい場合はこちらをご覧ください。

EOAはブロックチェーンの外部にあるもの、つまりユーザーが所有するアカウントであり、3つのプロパティが存在します：

アカウントで利用可能なETHの量を表す残高
全てのトランザクションが一意であることを保証するためのナンス
ネットワーク上でアカウントを一意に識別するためのアドレス

ブロックチェーンの状態＝アカウントの状態は、トランザクション（以下tx）の発生によってのみ変更できます。このトリガーは「ブロックチェーンの外部からもたらされる何か」であり、イーサリアムでは、全てのtxはEOAから開始される必要があります。つまり、イーサリアム仮想マシン（EVM）によってtxが実行されるとき、最初に触れられるアカウントはEOAでなければならず、対応するアカウントはtx全体の実行のためにマイナーに手数料を支払わなければなりません。

アカウントの所有権の証明方法は？

誰かがあなたのアカウントのETHを使うのを防ぐためには、何らかの認可が必要となります。

イーサリアムの全てのアカウントは、シグナーと呼ばれる暗号オブジェクトと関連付けられています。シグナーは秘密鍵と公開鍵の2つの鍵（キーペア）で構成されています。

秘密鍵はデジタルメッセージに署名するために使用され、公開鍵はある署名が対応する秘密鍵によって署名されたことを誰でも確認できるようにするものです。暗号技術の背後にある全ての数学は、私があなたに私の公開鍵を与えた場合にも、私の秘密鍵を導き出す方法がないことを保証し、私が秘密鍵で署名したメッセージを提供する場合は、私が署名することができた唯一の人であることを確認することを可能にします。

キーペアに基づく暗号署名を生成する方法は複数存在しており、イーサリアムでは、Secp256k1という特定の楕円曲線上でECDSAという特定の署名方式を使用しています。

では、アカウントはどのように署名者と関連付けられるのでしょうか？

EOAアドレスは署名者の公開鍵から導かれます。具体的には、公開鍵のKeccak-256ハッシュの最後の20バイトがアドレスとなるのです。

したがって、アカウントの所有者は、対応する秘密鍵でtxのパラメータに署名することで、そのアカウントからのtxを承認することができます。txと署名を受け取ると、EVMは署名が対象アカウントで有効であることを検証し、txナンスがアカウントナンスと一致することを検証し、txを実行し、アカウント残高からtx手数料を差し引く仕組みです。

ここまでに学んだことを振り返ってみましょう。

イーサリアム上のアカウントは3つの要素で構成されています：

残高とnonce を含むステート
アカウントからのtxを検証・実行するためにEVMにハードコードされたロジック
アドレス

また、署名者の公開鍵から得られるアドレスと、署名者からの有効な署名を正確に指定するハードコードされたロジックを介して、アカウントは署名者（キーペア）と緊密に結合していることがわかります。

アカウントの概念（あなたのトークンを保持するオブジェクト）と署名者の概念（トークンの移動権限を持つオブジェクト）は基本的に同じものです。秘密鍵を持っていれば、自動的に関連アドレスにアカウントを持っていることになり、あるアドレスにアカウントの保有には、対応する秘密鍵を持っている必要があります。このロジックは、EVMのコア部分にハードコーディングされています。

この方法は、理解しやすく、実装が簡単という利点があります。また、コンピュータ上でキーペアを生成するだけで、簡単に始められます。

さらに重要なのは、「あなたの鍵ではなく、あなたのコインでもない」という最近よく耳にするキャッチーなフレーズを体現する仕組みであるということです

しかし、このアカウントと署名者のカップリングには、多くの問題もあります。

秘密鍵を盗難・紛失してしまった場合は？

秘密鍵はあなたのアカウントそのものなので、鍵を失うことはあなたのアカウントを失うことを意味します。

つまり、もし他の誰かがあなたの秘密鍵を手に入れたら、あなたのアカウントの主権が共有されることになり、そこに含まれる全てのトークンも奪われることになります。あなたもウォレットの開発者もそれに対しては何もすることができません。

実際に、秘密鍵の盗難や紛失が原因で、何億ドル、何十億ドルというお金がすでに失われたり、盗まれたりしています。

もちろん、ハードウェアウォレットを使って、秘密鍵を金属片に書き込み、金庫に保管することはできます。この技術のアーリーアダプターたちは、ある意味オタク気質があるのでこの仕組みを許容していたのですが、この仕組みのままで何十億人ものユーザーに対してスケールアップできるとは誰も思っていないでしょう。

ECDSAとは異なる署名方式を使いたい、または異なる楕円曲線を使いたい場合はどうすればいいのでしょうか。機能する量子コンピュータが登場したらECDSAが破られることができることは分かっています。

私たちはより良いものを作ることができるのでしょうか？

予想外かもしれませんが、それは比較的簡単な仕組みで可能になります。

トークンを保持するオブジェクト（アカウント）とトークンを移動する権限を持つオブジェクト（署名者）を切り離すのです。

具体的には、アカウントを、有効なtxを定義する独自のロジックを持つスマートコントラクトに変えるのです。唯一の要件は、txを検証して実行するためのメソッドを持つ特定のインターフェースに準拠することです。

AAの応用によって、各ユーザーは自分のニーズに合ったアカウントを持つことができます：

DECDSAとは異なる署名方式を使いたい場合には、そのためのアカウントを作成することができます。
トランザクションの認証に複数の鍵を使用したい場合には、そのためのアカウントを作成することができます。
毎週、署名者を変更したい場合にも、そのためのアカウントを作成することができます。

可能性は無限大であり、StarkNetやzkSync 2.0のようなAAをサポートするチェーンで、どのような新しいユースケースが現れるのかが今から楽しみでなりません。

本シリーズの第2回では、AAが独自に実現する機能の具体例をいくつか紹介し、ブロックチェーン技術の導入に向けたゲームチェンジャーになると考える理由を紹介していきます。

Part 2: イーサリアムにAccount Abstractionを導入する際の課題

L2は、安価で迅速な取引の提供を約束します。ここでの問題は、暗号を大規模な普及を実現させるために、UXとセキュリティをどのように向上させるかにあります。

Argentでは、Account Abstraction（AA）がその答になると考えています。
この投稿は、「WTF is AA？」というシリーズの2つ目として、イーサリアムのL1にAAを導入しようとした過去の試みについて取り上げていきます。

なぜ実装に苦戦したのか、その弱点は何なのか。そして、L2が、私たちが当初から夢見ていたUXを実現するための絶好の機会となる理由について説明して、このブログを締めくくります。

AAとは何なのか、そしてなぜそれが重要なのかについて掘り下げていきましょう。

前回の記事に記したように、イーサリアムには外部所有アカウント（EOA）とコントラクトアカウントという2種類のアカウントがあり、このモデルには厳しい制限が存在しています。

現在のセルフカストディに関する多くの問題は、Ethereum Virtual Machine（EVM）のコアにあるハードコードされた認証ロジックに起因しするものです。ユーザーのトークンを保持するアカウントと、トークンの移動を許可された署名者の間には緊密な結合が存在しています。例えば、イーサリアムでは、署名方式はECDSAで、楕円曲線はsecp256k1です。そして、それを回避する方法は存在しません。

では、AAはこの問題をどのように解決するのでしょうか。

AAは、全てのアカウントをスマートコントラクトにすることで、アカウントの結合を解除し、トランザクション（以下tx）の認可をプログラマブルにします。つまり、AAを使うことで、全てのユーザーが自分のニーズに合わせたカスタム認可ロジックを持つアカウントをデプロイして、使用することができるのです。

なぜこれが重要なのかについて、いくつかの理由を挙げます：

複数の署名者によって詐欺の監視をサポート：全てのtxを検査して、定義されたセキュリティルールに準拠していることを確認し、ユーザーが詐欺のアドレスや不正なコントラクトへの資産の送信を防ぎます。
異なる楕円曲線による異なる署名スキーム：署名方式をよりシンプルでガス効率の良いもの、量子耐性のあるものに変更する。または、iOSやAndroid端末のセキュアエンクレーブを利用して、全ての携帯電話をハードウェアウォレットにすることも可能です。
ソーシャルリカバリー：ユーザーの秘密鍵が失われたり、危険にさらされたりした場合に備えて、ウォレットがアカウントを制御する鍵を安全に交換する仕組みを追加できるため、シードフレーズに悩まされることはもうありません。

もちろん、これはAAが可能にすることのほんの一部でしかなく、ユースケースの可能性は無限大です。

しかし、もしAAが本当にスケールアップに対して強力な力を持っていることがわかっているにも関わらず、イーサリアムがまだそれをサポートしていない理由を掘り下げる必要があります。

さて、なぜイーサリアムはまだAAをサポートしていないのでしょうか？

イーサリアムへの完全なAAの実装は、プロトコルのコア部分に複数の変更を加える必要があるため、簡単なことではないのです。しかも、イーサリアムによって保護される価値の高まりにつれて、調整と実装がますます難しくなってしまうのです。

2016年に議論され、2017年に提案されたEthereum Improvement Proposal（EIP）であるにもかかわらず、現在もまだAAがイーサリアムに実装されていません。提案以降、プロトコルに許容できる変更によってAAの機能の一部をもたらすアプローチが複数提案されています。ここで言う許容できる変更とは、プロトコルの次のフォークで受け入れられるような小さな変更であるという意味です。

この小さな変更で得られる弱い形式の AA にはそれぞれ制限があり、まだ広く採用されているものはありません。こうした遅々として進まない経緯があることが、私たちがL2にAAの採用を働きかけている理由の 1 つです。

AAに関連するEIPについて説明する前に、スマートコントラクトウォレットについて説明しておきます。これらはAAの正式な提案ではありませんが、プロトコルの変更を必要とせずにAAの利点を模倣できる方法です。

スマートコントラクトウォレットとAA

イーサリアムのウォレットのほとんどは、EOA（外部所有アカウント）であり、MetaMaskもその一例です。これらはシードフレーズに依存しており、UXやセキュリティの改善をプログラムすることはできません。一方、スマートコントラクトウォレットは、カスタムコードでプログラムすることができ、txを承認し、EOAでは不可能なUXを解放できます。

例えば、Argentでは、ソーシャルリカバリー、マルチコール、オンチェーン詐欺監視など、AAとともによく挙げられる機能を開拓してきました。これらは、初心者から上級者まで、ユーザーに大きな利便性と安全性のアップグレードを提供しています。

問題は、スマートコントラクトのウォレットが、ネイティブアカウントがEOAであるチェーン上でまだ生きていることです。これは主に2つの結果をもたらします：

L1上のスマートコントラクトウォレットは、AAを適切にエミュレートするために、複数のトリックを使用し、カスタムインフラストラクチャを構築する必要があります。例えば、スマートコントラクトウォレットでtxを実行するために必要な手数料を補助するために、リレイヤーと呼ばれるオフチェーンサーバーを使用する必要があります。

イーサリアムのエコシステム全体がEOAを中心に構築されているため、スマートコントラクトウォレットは普及していないため、多くのDappsはスマートコントラクトウォレットとの互換性を持っていません。

この互換性の問題を解決しようとする試みは複数ありますが、それぞれトレードオフの関係にあります。

EIP2938
EIP2938は、2020年に提案されたAAの制限版で、スマートコントラクトがトップレベルのアカウント（txを開始したりガス料金を支払ったりできるアカウント）として機能することを目的としています。

これは、新しいAAトランザクションタイプと2つの新しいオペコード（および複数のマイナー変更）を導入することによって行われます。これは、将来、より強力な新機能を開発できるようにしながらも、実装が非常に簡単になるように設計されています。

新しいAAトランザクションタイプには 3 つのフィールド { nonce, target, data } が含まれるのみで、targetはトランザクションを検証するロジックを含む AA スマートコントラクト、data はAAコントラクトが検証・実行する必要のあるtxの全パラメータ（コールコントラクト、ペイロード、最大tx手数料、署名など）がカプセル化されています。

EIP2938は大幅にシンプル化されており、nonceの抽象化、プロキシコントラクトの使用、メタトランザクションのサポートなど、AAに期待される機能の多くをサポートしていません。また、より重要なこととして、EIP2938 はEOAを置き換えたり取り除いたりするものではありません。

EIP3074
EIP3074は、EIP2938の直後に導入され、本質的に逆のアプローチをとっています。スマートコントラクトをトップレベルのアカウントとして機能させる代わりに、ユーザーが自分のEOAの制御をコントラクトに委任できるようにすることで、既存のEOAアカウントをよりスマートコントラクトらしく動作させようとする仕組みです。

この委任は、ユーザーに自分のEOAでメッセージに署名するよう求めることで実現されます。そして、署名されたメッセージと2つの新しいオペコード（AUTHとAUTHCAL）を使用して、インボーカーと呼ばれるターゲットのスマートコントラクトは、EOAと同様にtxを送信することが可能です。

EIP3074の主な狙いは、EOAウォレットの既存ユーザーが、新しく（スマートコントラクト）アカウントを作成したり資産を転送したりすることなく、AAの機能の一部を享受できるようにすることです。特に、ユーザーのためのtxをスポンサーしたり、マルチコールを実行したりする機能に主眼が置かれています。

このアプローチは柔軟性を提供する一方で、セキュリティのトレードオフを伴うため、エコシステムメンバーからは懸念の声も少なからず上がっています。例えば、EIP3074では、ユーザに対して引き続きシードフレーズのバックアップが要求されていますが、これはセキュリティ上のバッドケースであり、大衆を暗号に引き込む方法ではないことは明確です。

スマートコントラクトウォレットは、EOAから大幅にアップグレードされたものです。EOAを改善して使うということは、より速い馬を生産することで近代化を図るようなものです。世界が実際に必要としているのは馬ではなく車なのです。

EIP4337
EIP4337は、AAに向けた旅における最も新しい提案であり、スマートコントラクトウォレットの進化版と見なすことができます。高度なレベルでは、必要なオンチェーンおよびオフチェーンのインフラの一部を相互化することによって、イーサリアム上のスマートコントラクトウォレットの作成と運用をよりシンプルなものにするものです。

EIP4337では、ユーザーはもはやtxを行わず、その代わりにUserOperationをより高いレベルのmempoolに送ります。マイナーやバンドラーはUserOperationのセットをバンドルトランザクションにパッケージ化して、EntryPointコントラクトに送信して実行させることができます。EntryPointコントラクトは、操作の正しい実行を指揮して、マイナー/バンドラーがtx手数料の適切な補償を確認します。

EIP4337を使えうことで、どんな開発者でも数行のコードでカスタムスマートコントラクトウォレットを書くことができ、手数料の補助方法について気にする必要もありません。

スマートコントラクトウォレットと同様に、EIP4337はプロトコルに変更を加えることなくAAをエミュレートするように設計されています。しかし、これもまたEOAを取り除くことはできず、EIP4337の上に構築されたウォレットはイーサリアム上で二流市民のままとなります。

イーサリアムにAAが実装される可能性は？

イーサリアムの初期の開発者は、UXとセキュリティの強化に向けて、完全なAAを実装するつもりでしたが、より他の変更を優先することで、繰り返し延期されてきたことがわかります。

では、マージが完了した今、AAは実装されるのでしょうか？

私自身は、それがセルフカストディで必要とされるUXを拡大する唯一の方法であると確信しているので、そうなることを望んでいます。

エコシステムが徐々にL2に移行していく中で、AAもL2をより強固するための基盤になりつつあります。例えば、StarkNetとzkSyncは共にネイティブなAAを既にローンチしています。

最終的な目標は、セルフカストディの主流採用に向けての最大の脅威であるEOAを排除することにあります。一般ユーザーに鍵の管理を要求するべきではありませんし、もしイーサリアムがEOAからの移行を決断しないのであれば、少数の人々によってセルフカストディが利用され、残りの多くの人々が中央集権的な取引所を利用する世界になってしまうでしょう。これは、私たちが望んでいる未来ではないし、私がArgentを共同設立した理由でもあります。物事は常にシンプルである必要があり、EIP4337が、その実現に近づけてくれる希望の光となるでしょう。

より多くのL2がAAをサポートして、より多くのユーザーがAAによる大幅な改善を体験できるようになればと最高です。そうなって初めて、より広範なイーサリアムコミュニティがプロトコルレベルでの変化を望むようになり、Ethereum上でのAAが現実のものとなるでしょう。

このシリーズの最終回では、私たちがStarkNetとzkSyncで構築しているユニークなAA機能の具体例について説明します。

Part 3:UXとセキュリティを10倍に拡張する

Vitalik氏は、Account Abstraction（以下AA）は「常に望んでいたもの」であり、「イーサリアム開発者コミュニティの長年の夢」と語っています。

今回は、AAがもたらす実用性について見ていきます。まず、Argentが取り組んでいる5つの重要な機能について触れていきましょう。

AAが存在しなければ、暗号分野はマイナーな普及から抜け出せなくなると考えられます。DappsはWeb2のようなUXを実現できず、ウォレットは使いにくく複雑で、安全性が低いものとして存在し続けます。そうなれば、コントロールできない中央集権的なソリューションに依存することになり、ユースケースも限定され他ものとなってしまいます。

一方、AAを使えば、暗号分野を世界的普及させるための潜在能力を引き出すことができるのです。

さて、AAの実用性を見ていきましょう：

1. Multicall — ワンタップの利便性

イーサリアム上のDappを使用する場合、オンチェーンでのやり取りのたびに新たなtxを作成する必要があります。これでは時間もかかるし、ガスコストも高くつきます。

AAを使えば、複数のトランザクションを1つに束ねて、一連の操作を1つのアトミックトランザクションで実行することができます。この機能はMulticallと呼ばれます。

例として、Uniswapに流動性提供をするには、通常、2つのトークンをそれぞれ承認し、預ける、という3つのtxが必要になります。Multicallを使えば、それを1つのアトミックトランザクションで実行できるのです。

このようにAAは、ワンタップ取引のように、複雑なプロセスを簡素化することを可能にします。これは、Hasuが語っていた「理想的なDeFiインタラクション」を実現するものです。

2. Session keys — シンプルさと安全性

Session keysは、UX、特にゲーム分野において画期的なものとなるでしょう。Dappとのインタラクションルールを事前承認することで、いちいちtxに署名しなくても、ルールの範囲内で好きなだけDappを利用できます。

つまり、Dappができること、できないことを制限することで、資産を守りながら利用を楽しむことができるのです。つまり、リスクを最小限に抑えながら、利便性を最大限に高めることができる方法となります。

Session keysは、「適用期間、ガスの最大量、トークンの最大取引量、特定のコントラクト上の機能」など様々な範囲と方法を定義することが可能です。Influence、Loot Realms、Briq、Topology、Cartridge、MatchboxDAO、Ledgerなど多くのチームがこの要素を使って構築を進めています。

3. ソーシャルリカバリー — シードフレーズとの訣別

Vitalikはソーシャルリカバリーを「ウォレットの安全性向上に推奨すべき方法」であると言っています。

ソーシャルリカバリーの目的は、アカウントの紛失や侵害からユーザーを保護することにあります。具体的には、MetaMaskなどの既存ウォレットのリカバリー方法であるシードフレーズを使うことなく、その目的を実現するものです。シードフレーズは言うまでもなく面倒で安全性に欠け、大量導入の大きな障壁となっているため、無くしていく必要があります。

ソーシャルリカバリーを活用すると、秘密鍵を紛失した場合、正当なウォレットの所有者として新しい鍵を認証するだけでよくなります。これは様々な仕組みを活用することができます。例えば、信頼できる人、ハードウェアウォレット、サードパーティのサービスに依存するリカバリ方法を選択することもできますし、それらを組み合わせることで安全性を上げることもできます。

ここで重要になるのは、ソーシャルリカバリーがセルフカストディを犠牲にしないことです。便利な仕組みによって、自分の資産のコントロール権がなくなるのであれば本末転倒です。そして、リカバリープロセスをキャンセルできるよう、実行までの時間的な猶予を持たせる設定や通知機能も必要になるでしょう。

ソーシャルリカバリーが普及することで、安心でシンプルな相続の実現など、さらなるイノベーションが期待できます。「昔はシードフレーズというものを紙に書いていた」という笑い話ができるようになるといいですね。

4. 多要素認証とセキュリティ強化

現代の銀行では、大口の送金には2ファクタ認証の活用が主流となりつつあります。暗号分野でもこれと同様の、またはもっとスマート仕組みを導入することは可能です。

AAによって、複数の鍵の署名を必要とするアカウントを作成して、特定の条件が満たされた場合にだけ取引を実行できるようにすることが可能になります。

Gnosis Safeのようなマルチシグネチャーのウォレットとの違いは、AAを活用したウォレットでは、より高いカスタマイズ性、セキュリティ、ユーザビリティを享受できるということです。

AAを活用することで、アカウントのセキュリティレベルをニーズに合わせて調整し、様々なデバイスを使用して取引を承認することが可能になります。具体的な例をあげてみましょう：