ERC-4337 著者との対話: イーサリアム アカウントの抽象化とその進化
インタビュー: Huobi Incubator シニアリサーチマネージャー兼シニアオペレーションマネージャー、Lucas、Jenny 氏
編集：aididiaojp.eth、フォーサイトニュース
編集：aididiaojp.eth、フォーサイトニュース
司会者：まずは自己紹介をお願いできますか？
Kristof：私は2021年5月にNethermindに入社しましたが、昨年の11月頃、この分野で次に何をしようかと考えていましたが、この分野が直面している最大のボトルネックは何でしょうか？現時点での最大の問題は、技術的な背景のない一般の人がイーサリアム アプリケーションを使用することがいかに難しいかということです。したがって、私にとって最も効果的なことは、イーサリアムアカウントとウォレットの使用の難しさを解決し、イーサリアムアプリケーションのユーザーエクスペリエンスを向上させることです。
アカウントには、プライベート アカウント (EOA) とスマート コントラクト アカウントの 2 種類があります。現在イーサリアムでは、ユーザーは主に EOA アカウント (メタマスクやレインボーなど) を使用していますが、いくつかの制限があります。
しばらく解決策を探していたところ、アカウントの抽象化の概念を見つけました。以前のすべての提案が複雑すぎるか、提案に必要な作業が多すぎるため、まだメインネットにデプロイされる機会があった提案はありません。そこで、私たちは Vitalik および OpenGSN と協力して、メイン ネットワークがコンセンサス レベルのプロトコル変更を行う必要がないアカウント抽象化のソリューションを模索しています。これが ERC-4337 の主要な革新ポイントです。
これまでにいくつかのアプリケーションが構築されていることがわかります。現在、私たちはERC-4337の生態系を開発し、普及への道を切り開いています。
Praneeth：私は Ethereal Ventures の投資パートナーです。Ethereal Ventures は、ConsenSys の元 VC チームによって設立された新しい仮想通貨投資会社です。
より多くの人を Web3 に参加させるには、認証やソーシャル復元など、人々が基本的に慣れ親しんでいる典型的な慣習である、参入障壁を低くし、スムーズなエクスペリエンスをユーザーに提供する必要があります。
アカウントの抽象化を通じて、これらの問題に対する効率的な解決策を提供できます。私は ERC-4337 の進化を観察し、エコシステム内の人々や関係者と協力してその誕生に立ち会うことに非常に興味があります。
モデレータ: アカウント抽象化の実装に関する ERC 4337 が今年提案され、Devcon 中にアカウント抽象化について何度か議論しました。 ERC 4337 は実際にバズワードになっており、現在の市場は非常に悪いですが、アカウント関連では良い勢いが見られます。それではまず、アカウントの抽象化とは何なのか説明していただけますか?
Kristof：まずは分かりやすく説明させていただきます。イーサリアムでは、ほとんどの人が使用するアカウントは秘密鍵アカウントであり、これらのアカウントを外部所有アカウント EOA と呼びます。
ただし、イーサリアムにはスマート コントラクト アカウントという別の種類のアカウントがあります。 EOA アカウントは秘密キーによって制御され、スマート コントラクト アカウントはコードによって制御されます。
問題は、イーサリアムでは、EOA アカウントにはスマート コントラクト アカウントにはない多くの特別な権限があることです。たとえば、EOA アカウントのみがトランザクションを開始できますが、スマート コントラクト アカウントはトランザクションを開始できません。
また、EOA アカウントはその仕組みが非常に手続き的であるため、EOA アカウントの場合、Gas の支払いの仕組みは、トランザクションで使用されたすべての Gas をイーサリアム スマート コントラクトに入れ、残っている場合は返金されるというものです。アカウントに。
EOA では、ECDSA 署名などの署名検証も非常に手順的です。それ自体には何も問題はありませんが、このスキームには今日使用できる多くの革新性があります。
したがって、アカウントの抽象化は、1 種類のアカウントのみという概念を取り除き、スマート コントラクト アカウントにより多くの権限を提供し、トランザクションを開始する権限を与えようとしているだけです。
Praneeth：アカウントの抽象化により、Web3 のセキュリティと使いやすさが向上します。これが、ユーザーが初めてブロックチェーンと対話し始めるときに感じてほしいことです。トークンやサービスを購入するために特定のスマート コントラクトへのアクセスを許可せずに、秘密キーをどのように保存して記憶する必要があるかを考えるのは、悪い経験です。
アカウントの抽象化により、非常に直感的な方法で対話できるようになります。ユーザーはこれを使用して、主要なアクセス許可をきめ細かく制御できます。これは、現在 Web2 アカウントで使用されているものです。
また、特定のウォレットの機能を制限しているものは何かについて根本的に考え、トランザクションベースのモデルからできればコンセンサスベースのモデルに移行できるかどうかを確認する必要があります。
Kristof：スマート コントラクト ウォレットに適切に移行した場合に、ユーザーが現在の機能に加えて得られるパワーの例をいくつか示します。
例としては、ガスの支払い方法があります。 Dapps は、ユーザーのトランザクションを奨励する能力を非常に簡単に獲得できるようになります。ユーザーは、オフチェーンのさまざまなトークンやクレジット カードで支払うこともできるため、取引に ETH は必要ありません。あらゆるタイプのシステムまたは個別のガス支払い方法が可能になりました。
署名スキームを使用すると、ユーザーはソーシャル リカバリ スキームとマルチ署名スキームを使用でき、アカウントの動作方法とサブアカウントの権限の種類を完全にカスタマイズできます。
ユーザーのマスター アカウントはマルチ署名によって制御され、秘密キーを介してクイック アクセスを許可されますが、これはオンチェーン ゲーム コントラクトと対話する場合に限ります。この設定により、ユーザーウォレットとオンチェーンゲームはユーザーに代わって取引できるようになりますが、権限は非常に制限されています。言い換えれば、ユーザーはEVM/Solidityコードを使用して個人アカウントがどのように見えるべきかを完全に定義でき、時間ベースの権限、支出制限などのカスタム権限を提供できます。
最後に、非常に一般的な UX の問題は、バッチ トランザクションが欠落していることです。 Uniswap で承認してからスワップする (現在 2 つのトランザクション) のではなく、ユーザーは任意の数の個別の操作を同じトランザクションに入れることができるようになりました。
これらの改善により、次世代の暗号通貨ユーザーに真に強力なユーザー エクスペリエンスが提供されます。ユーザーは基本的にNEO Banksを利用するのと同じ体験をすることができます。
モデレーター: イーサリアムコミュニティでは、EIP-86、EIP-2938などに続いて開始されたEIP-4337の実装が進められています。新しいアカウント抽象化プロトコル レベルの標準があるのはなぜですか?イーサリアム開発コミュニティとユーザーにはどのような影響がありますか?
Kristof：最も関連性の高い以前の提案は、友人の Ansgar によって作成された EIP-2938 でした。 EIP-2938 は、イーサリアムに基づいたアカウント抽象化メカニズムを定義します。これは、実際にはイーサリアムの動作方法を変更するプロトコルです。では、なぜ今それを維持しないのでしょうか？問題は、どのような種類のプロトコル レベルの変更も非常に困難なプロセスであることです。過去 1 年半にわたるコア開発者の取り組みのほとんどすべてがマージに費やされたため、コア開発者にはアカウント抽象化の提案を試して実装する時間がありませんでした。
アカウントの抽象化は UX の観点からは非常に便利ですが、スケーラビリティやセキュリティほど優先度は高くありません。現在、リソースは主に合併、撤退、EIP-4844 プロトダンクシャーディングや EVM など、およびコア開発者コミュニティに割り当てられています。ユーザー エクスペリエンスの向上に焦点を移すには、少なくとも 2 ～ 4 年かかります。そのため、私たちは、プロトコル レベルでの展開を必要とせず、イーサリアムで展開されたスマート コントラクトを通じて実装できる、新しい ERC-4337 提案を考え出すことにしました。
コミュニティが 2938 のようなものを採用しなかった最終的な理由は、アカウントの抽象化が本質的にサービス拒否の潜在的なリスクを引き起こすためだと思います。アカウントの抽象化を使用すると、トランザクションが有効かどうかをウォレットに定義させることができます。基本的に、カスタム EVM コードを実行して、トランザクションが実際にマイナーまたはバリデータに支払うかを判断する必要があります。したがって、そのようなものをコンセンサスに直接導入するのは非常に大きなリスクであり、実際にノード サービスを変更するよりも、まず ERC を使用してみる方が良いでしょう。
Praneeth：これは、4337 エコシステムを同様の EVM 互換環境で開始するための非常に良い方法だと思います。これは、将来のプロトコルに完全に適合し、他の発明のブートストラップとして機能する可能性があります。
司会：抽象化を基準に考えると、Gnosis SafeやArgentなどのコントラクトウォレットが第一候補になりますが、現在どのような機能が人気で、どのような機能が近い将来登場すると予想されますか？
Kristof：まず注意すべきことは、Gnosis Safe と Argent はまだ ERC-4337 に準拠していないということです。したがって、ERC-4337 は、アカウント抽象化ウォレットと支払者、およびエコシステムの他の部分がどうあるべきかを定義する標準にすぎません。
もう 1 つの質問に関しては、どのような機能が確認されており、どのような機能が将来期待されていますか? Argent では、ERC-20 トークンを使用した支払いなどが行われています。あまり一般的なガス料金の支払い方法はまだ見たことがありません。これは間違いなく Gnosis Safe と Argent の未来です。ソーシャル リカバリやマルチ同期などのシナリオには多くの差異が見られましたが、サブアカウントの生成やサブアカウントへの非常にカスタムな権限の付与については実際には確認されていません。
Argent を使用すると、指定された条件に基づいてユーザーに代わって取引できる署名者キーを生成できる機能があったことを覚えています。そのため、ソーシャル リカバリの署名者に会いに行き、1 日取引できる特別なキーの承認を求めることができます。つまり、署名者に毎回返信する必要がなく、多くのトランザクションを順番に実行できます。したがって、これはすでに将来何が起こるかについての基本的な例です。
私の知る限り、支出制限のようなものはまだ導入されていません。これは今後のユーザー エクスペリエンスにとって非常に重要だと思います。 Argent や Gnosis Safe などのウォレットはまだ準拠していませんが、準拠すると、多くの非常に優れた機能が利用できるようになります。
Praneeth：ERC-4337 では、既存のユーザーがアセットとアクティビティを新しいアカウントに転送することで、ERC-4337 に準拠する必要があるコンソールをアップグレードする必要があります。それ以外にも、特にバックグラウンドでのアクティビティがあまりないアカウントの場合、移行プロセスがスムーズに進み、過度の摩擦が生じるのを避けるために、他にもいくつか考慮する必要があることがあります。
しかしそれを超えて、EOA が常に最初の選択肢になるという考えがまだあると思います。特に人々が L2 の 4337 からインスピレーションを受けるにつれて、アカウント抽象化関連の機能がさらに登場することになるでしょう。 EOA 移行アカウントへの道を手に入れることも非常に興味深いものとなるでしょうし、そう遠くない将来に画期的な進歩が得られることを願っています。
Kristof：プラニースさん、あなたは、将来 EOA をスマート コントラクト ウォレットに正確にどのように移行するかについて、非常に興味深いトピックを提起しました。これは非常に重要な質問であり、スマートコントラクトウォレットについて私が話した多くの人からの共通の反応は、すべてを新しいウォレットに移動するのは面倒だというものでした、特にソウルバウンドトークン。
したがって、EOAウォレットをスマートコントラクトにする方法を見つける必要があります。主な選択肢は 2 つあります。 1 つは、新しいトランザクション タイプを導入できる弱いバージョンです。このトランザクション タイプにより可能になるのは、トランザクションを送信すると、たとえばデータ フィールドで指定したコードに従って、EOA がスマート コントラクト アカウントに単純に変換されるということです。非常に完全にカスタムな方法でスマート コントラクト コードを使用してアカウントの外観を定義するには、1 つのトランザクションを呼び出すだけです。これは、以前に所有していたすべてのトークン、すべての NFT などと同じアドレスになります。
もう 1 つのオプションは、ユーザーに EOA をスマート コントラクトに変えるオプションを与える代わりに、ハード フォークが発生すると、各 EOA を非常に単純なスマート コントラクト アカウントに即座に変えることができる、より強力なバージョンです。したがって、このスマート コントラクト アカウントは今と同じスキームです。基本的に EOA を一気に取り除く ECDSA に依存します。
これは私たちが今検討する必要がある重要なトレードオフであり、より強力なバージョンを取得しようとすると、2 番目のオプションに傾く可能性があります。なぜなら、より弱いバージョンを使用して、人々が EOA をスマート コントラクト アカウントに変えることを許可すると、実際には EOA をさらに使用することになるからです。したがって、EOA をスマート コントラクト アカウントに変換することを唯一の目的とするトランザクション タイプが作成されます。しかし、将来的に EOA を完全に排除したい場合はどうなるか、それは私たちが解決しようとしている将来のトピックです。
しかし、前に述べたように、イーサリアムに何らかのコンセンサス変更を導入しようとすると、実装までに長い時間がかかります (たとえば 1 ～ 3 年)。したがって、すぐに EOA を取り除くことに絶対に賭けないでください。
Praneeth：私もこれに全く同感です。また、基本的にその署名が EOA アカウントに関連しているかどうかを示す署名スキームに関する特定の仮定に通常依存する契約に関連するため、アプリケーション開発者に対するこれらの仮定も変更されます。
しかし、これにはさらなる疑問が生じると思います。なぜなら、古い可能性のあるアカウントをキャスティングすることになる可能性があり、ある意味、ユーザーが何年も活動していないアカウントを実際には検出できない可能性があるからです。しかし、EOAを使用している人にとっては、受け入れられる点でいくつかの変化があるかもしれないと思います。
モデレーター: アカウントの抽象化がゲームチェンジャーであり、将来の暗号体験にとって不可欠なデフォルトである場合、それを機能させるには他の多くの Dapps やインフラストラクチャを構築する必要があります。開発者にとって、どのようなウォレットのサポートが必要ですか?また、Dapps はスマート コントラクト ウォレットに基づいて機能を設計するために、どのように事前に計画を立てることができますか?
Kristof：非常に簡単な答えは 2 つあります。Dapps は導入が約束されており、それはそれほど難しいことではありません。 1つは、トランザクションソースの使用を停止するなど、スマートコントラクトアカウントに対する差別をやめることです。アカウントの抽象化を実現すると、現在の 457 であっても、将来的には非常に誤解を招くものになるでしょう。トランザクション ソースを使用する場合は、ユーザー アクションをまとめてバンドルするエコシステム プレーヤーであるバンドルも参照できます。したがって、トランザクション ソースの使用を停止し、スマート コントラクトが Dapps と対話するのを無効にしないでください。
2つ目はEIP-1271への対応です。この EIP は、スマート コントラクト ウォレットで承認に署名する方法を定義します。したがって、スマート コントラクト ウォレットが「有効な署名の場合」関数を実装し、「true」を返した場合、ウォレットがメッセージに署名したかのように扱います。しかし、多くの Dapps は依然としてこれに準拠しておらず、EOA アカウントが署名されているかどうかを判断するための単純な ECDSA 署名があると想定しています。したがって、それは2つあると思います。 1 つはスマート コントラクト アカウントを差別しないこと、2 つは EIP-1271 に準拠することです。
Praneeth：はい、それはかなり正確だと思います。留意すべき点が 1 つありますが、EVM オブジェクト形式に関するすべての変更は、上海のアップグレードに反映される可能性があります。
米国専用部品など、今後起こると予想される作業の多くは、建設業者の分離に関するより広範な提案や長期ロードマップを検討し、中核から検討される能力を確実に備えていることを確認する上で、基本的に非常に重要になるだろう。同意します。プレイの提案やビルダーの分離計画など、新しい仕組みやモデルを検討しているからです。
ただし、プロトコルにおける検証と強制の概念をよりよく理解できるように、EOF と EIP には細心の注意を払うようにしてください。
モデレーター: レイヤー 2 とレイヤー 3 で構成されるイーサリアム エコシステムにおけるアカウントの抽象化についてのみ話しているのでしょうか、それともより広範なマルチチェーン エコシステムにおけるアカウントの抽象化について話しているのでしょうか?アカウント抽象化の発祥の地がイーサリアムではなくレイヤー 2 なのはなぜですか? StarkNet は現在、アカウント抽象化の開発にどのような取り組みを行っていますか?
Kristof：最初の質問に答えることができます。だからこそ、レイヤー 2 でのアカウント抽象化の発展を 2 つの言葉、つまりガス料金で見ているのです。アカウントの抽象化を使用すると、スマート コントラクト コードを利用してトランザクションが有効であることを確認できます。しかし、EOA では、これはノード自体によって検証されます。
レイヤ 1 メイン ネットワークのガス コストはレイヤ 2 のガス コストよりもはるかに高いため、レイヤ 1 で追加されるガス コストのペナルティははるかに大きくなります。レイヤー 1 では、EOA トランザクションの費用は 10 ドルですが、スマート コントラクト ウォレットのトランザクションの費用は 20 ドルですが、レイヤー 2 ではわずか 1 ～ 2 ペニーの費用がかかる場合があります。そのため、レイヤー 2 のガス料金の差はごくわずかであり、そのため、特定のレイヤー 1 が採用される前にレイヤー 2 が登場すると予想されます。
私の知る限り、StarkNet には ERC-4337 からインスピレーションを得た多くのメカニズムがあります。私はそれらにあまり詳しくありませんが、スマート コントラクトをデプロイし、そのコントラクトを直接使用してトランザクションを開始することはすでに許可されています。そのため、彼らは 4337 と同様の方法で関連するコントラクトを実装し、プロトコルでそれを試みました。彼らは大きな一歩を踏み出しており、とても刺激的です。
Praneeth：Dan Finlay の委任フレームワークには、本質的にあらゆるソリッド コントラクトとアカウントに反事実的な委任を追加する機能があり、検証やトランザクションのバッチ処理機能など、スマート コントラクト ベースのウォレットに関連する多くの機能が含まれています。このフレームワークを基礎として使用すると、EOA は、オフチェーンでメッセージを公開することにより、コントラクトをデプロイすることなく、スマート コントラクト ウォレットとして機能することができます。これは基本的に EIP-3074 と EIP-5003 の主要な作業です。
ただし、署名キーは、ユーザーが引き続きバックアップする必要があるキーに関連付けられています。任意のスマート コントラクトにアクセス許可を委任できますが、それでもアクセス許可の取り消しと取り消し、およびノード管理に関連する問題が発生します。アカウントの抽象化に関しては、プロトコルの変更を回避する非常に興味深い概念がいくつかあると思います。これらの実験のいくつかを使用して、これがほとんどの EOA アカウントのデータ移行に使用できる方法であるかどうかを確認してください。
私たちは、しばらく時間をかけて、これまで存在してきた委任可能なフレームワークを検討することをお勧めします。
聴衆の質問 (Eric Siu): 4337 と 3074 や 5003 などの他の EIP のアカウント抽象化についてどう思いますか?
Kristof：3074 は、どのアカウント EIP よりも前から存在します。その役割は、EOA アカウントにより多くの権限を与えることです。したがって、呼び出し元の概念が導入され、基本的に呼び出し元は、定義できるいくつかの制約に従って EOA に代わってトランザクションを実行できるようになります。
これには 2 つの問題があり、それがおそらくメインネットに反映されない理由です。最初の問題は、それが EOA に役立ち、EOA を強化してしまうことです。スマートコントラクトウォレット機能を使用したい場合は残高を移動する必要がなくなるのでこれは良いことですが、将来的にアカウントの抽象化を導入したい場合は技術的な問題がたくさんあるため悪い点もあります。
2 番目の問題は、Invoker にセキュリティ上の問題があることです。呼び出し元にフルアクセスを許可すると、奇妙な副作用が発生する可能性があります。 Yoav Weiss は 4337 の共著者であり、3074 のセキュリティ問題の多くを公開しています。セキュリティ問題について概説した彼の投稿をチェックすることをお勧めします。それが、この EIP がメインネットに登場する可能性が低い理由だと思います。
聴衆の質問 (リック・バートン): このすべてが展開し始めている中で、ステージ上の人々が将来何が起こるかもしれないと考えているのか、本当に興味があります。現在、私たちは実装の詳細と、Dapps 開発者にこれらすべてのことを認識させる方法に焦点を当てていると思います。 5年後にこれがすべて叶うとしたら、あなたの将来の夢は何ですか？マッチングアプリや商品、ツール、サービスはありますか？
Kristof：私にとって、私のビジョンは、実際に優れたアカウント抽象化エコシステムを構築すれば、イーサリアムでの報酬の運用は、現在ある種類の NEO Bank を使用するのと同じくらい簡単か、よりシンプルになるということです。あらゆる資産を友人に簡単に譲渡できます。内蔵アプリの多くは節約や予算管理に使用できますが、クレジット カードのブロックやそれらの操作の実行など、非常に限られた権限しかありません。私たちのウォレットがアカウント抽象化の多くの機能を活用すれば、オフチェーン エコシステムで銀行とやり取りするのと同じくらい簡単にオンチェーン エコシステムとやり取りできるようになると本当に思います。
Praneeth：これについては以前にも簡単に触れましたが、ユーザーが自分の意図を表現し、それを自動的に、またはアプリケーションとプロトコル間の自動会話で実行できる機能であるという意味で、この結合されたコンセンサスを抽象化します。固有のトランザクションは抽象アカウントと呼ばれます。これらのプロトコルを操作する場合、実際的な方法でこれを行う方法の実装の詳細に深く立ち入らずに、それを実行できるテクノロジまたはツールを使用する必要があります。したがって、物事を一緒に構成する機能、複数のアンストールされたアクションを割り当てる機能、後でブロックチェーンに簡単にコミットできるコミットメントに署名する機能、検証と実行の間で本質的に中核となる分離機能などがあると思います。について。
元のリンク
