StarkNetとアカウントの抽象化(Account Abstraction)について
先日、StarkNetがMainnetでローンチしました。その内容は後日まとめようと思いますが、Twitterで次の発言をしている方がいました。
ここで、「アカウントの抽象化」というキーワードが気になり、StarkWareのMainnetローンチとどのような因果関係があるのか理解ができなかったので調べてみました。
１ アカウントの抽象化(Account Abstraction)とは
・2020年の9月にEIP-2938でAccountAbstraction（以下、AA）が提案されました。（もう少し遡ると、2016年にVitalikが提案しているところから始まり、歴史は古いようです。）
※AAの概要については、GBECの中城元臣さんのこちらの動画で勉強させていただきました。
（１）現行のAccount
・現在、Ethereumは主にExternally Owned Accounts(EOA)とスマートコントラクトにより成り立っています。
・EOAとは、シードフレーズから生成された秘密鍵によって保護されているアドレスで、私たちがよく使っている「0x・・・」などの外部所有アドレスのことです。
・もう少し言うと、EOAはユーザーによりコントロールされるアカウントであり、ユーザーによる任意のタイミングで、EOAがトランザクションを発生させ、他のアカウントへのEtherの送金、コントラクト・コードの実行などを行うなど、トランザクションを行ううえで核となるものです。
・AAとは、EOAを削除して一つのコントラクトにまとめ、コントラクトが EOA と同様に料金の支払いやトランザクションの実行ができるようにするものです。
（２）EOAの課題
EOAによる課題は次のようなものだと言われています。
①トランザクションを行うための制約
・現在、トランザクションの有効性は、プロトコル（ECDSAによる署名、単純なナンス、および口座残高）によって厳密に定義されており、これを満たさない場合は拒否されます。
署名でガス代がかかる、トランザクション途中にガス代が高騰して口座残高が足りずトランザクションが拒否されるなど、枚挙にいとまがありません・・・
②セキュリティ面の脆弱性
・前述のとおり、EOAは秘密鍵により保護されており、秘密鍵の盗難やシードフレーズの損失があるとユーザーの資金が失われる可能性があります。
この点はもはや日々Cryptoを触るうえでは当たり前のことのように感じてしまっていますが、外から見ると「セキュリティの脆弱性」と見なされ、様々な活用のハードルになっていると思われます。
③プライバシーが保護されづらい
・「0x0・・・」などのEOAを保持していると、それを知っている人物であればトランザクションの中身を閲覧することができます。
上記の制限により、イノベーションが阻害されており、EOAを削除したAAを導入すべきであると、これまでEIPで再三提案がなされてきました。
（３）AAによる効果
EOAを削除したAAでは次のような効果が期待されます。
①トランザクションの複雑性の解消
・EOAを削除することで、トランザクションを通す際に必要な情報が、nonce、target、dateの３要素のみとなるようです。その結果、トランザクションの効率性が向上します。
・例を挙げると、トランザクションに署名が不要となり、呼び出し先のスマートコントラクトで定義されたり、無効なトランザクションをブロックに含めなくすることが可能となります。
②セキュリティの向上
・秘密鍵やシードフレーズによる管理が不要となります。
・また、これまで実現できなかったマルチシグが導入可能となり、セキュリティが向上します。
③プライバシーの向上
・Tornedo.cashのようなMixingが可能となります。
④トランザクションの手数料をETH以外で払うことが可能となる
・これまでトランザクションの手数料として、EOA側でETHを支払っていましたが、AAではコントラクトが保有しているETHから支払われます
・そのため、ユーザーはわざわざETHで支払う必要はななく、任意のERC20で手数料を代替し、呼び出し先のコントラクトに支払うことが可能となります。
２ StarkNet × AA
・StarkNetでは、AAに対応したアプリケーションのデプロイが可能となるようです。この件はあまり情報がなく、こちらの記事を参考にしました。
・新しいアカウントを作成するには、L1からL2にオンボーディングする必要があり、次の要素を組み合わせたアカウントを体験できるようです。
- L1ウォレットからトランザクションの支払い。
- ウォレットを使用してStarkNetキーの生成（たとえば、特定のECDSA曲線、StarkNet固有の階層的決定論的パスなど）
- 必要なアカウントの種類の選択（単純な単一所有者アカウントなど）
- 選択したアカウントに必要な情報の選択（たとえば、L2が強制的に閉鎖された場合に資金を受け入れるL1アドレスの指定など）
・まだこの辺り詳細は明らかになっておらず、もうすこし今後の情報を追っていく必要がありそうです。
・また、L2対応のWalletとして期待されているArgentもStarkNetとの提携を発表していますので、この辺りの要素も取り入れた形になるかもしれません。
