L2技術が「短期OP、長期ZK」をダイナミックに提示してから、Vitalik氏の心はアカウント抽象化（Account Abstraction）技術へと傾き始め、ボゴタで開催された今回のイーサリアム開発者カンファレンスでは、ウォレットであるソウルウォレットについての講演も行った。アカウント抽象化テクノロジーをサポートしています。

アカウントの抽象化により、ソースからのトランザクション データを削減でき、ロールアップ ソリューションと組み合わせることで、統合された「データ間引き」ソリューションとして使用でき、ガス料金の消費と使用量を大幅に削減でき、使いやすく安価です。イーサリアムネットワークが世界に登場します。

10 月 3 日、Vitalik は EIP-4337 アカウント抽象化提案の内容を補足し、BLS 署名アルゴリズムのデータ集約部分を追加しました。これにより、ビルダーとバッチ検証者が署名を集約してメイン ネットワークへのデータ ブロードキャストを削減できるようになります。

さらに、StarkNet は、新しいバージョンのアップデートでアカウント抽象化の詳細な設計も提案しています。アカウントの抽象化を悩ませていた DoS 危機も、Zk ベースのロールアップの使用が増えるにつれて解決されました。ZK スキームのセキュリティは、データ圧縮機能ほど注目されていません。これは、長い間無視されてきた機能です。抽象的なルートをめぐる論争が全面的に表示されました。

最初のレベルのタイトル

考え方の変化: 非コンセンサス層でのアカウントの抽象化

今回のアップデートでは、EIP提案に基づいてアカウント抽象モデルが設計されており、当初の構想ではイーサリアム自体のアカウントアドレス設計を変更し、EOAアカウントとスマートコントラクトアドレスを統一することが当初の構想であったが、これも当初の構想通りである。イーサリアムアカウントのアドレス設計スキーム。

EIP-86/208、EIP-859、EIP-2938 などの 4337 より前の提案の中で、これらの提案はいくつかの共通の特徴を持ち、基本的にイーサリアムのメインネットに基づいています。メインネットワーク上で「筋肉と骨を切断する」ような操作を軽率に実行するにはリスクが大きすぎるため、実際にはアカウントの抽象化の優先順位は L2 以降に置かれます。

これはエンジニアリングの観点から最適なソリューションではありませんが、「使用できないわけではない」という原則に従うため、アカウント抽象化の実際の実装は、L2 ソリューション、特に ZK ルートの実用化を待つ必要があります。

本質的に、アカウント抽象化が実現したい機能は現時点ではEOAアカウント+スマートコントラクトで実現可能であり、イーサリアムのメインネットワークには影響を与えず、コミュニティは打倒ではなく「改善」のみを望んでいる。

最初のレベルのタイトル

スマート コントラクト: ERC-4337 標準が世界を支配

前述したように、イーサリアムにはEOA外部アカウントアドレスとスマートコントラクトアドレスの2種類のアドレスがあり、このうちEOAは秘密鍵やニーモニック、ETH（ガス料金）や、「人間」とイーサリアムとのやり取りを制御します。他の前提条件; 一方、スマート コントラクト アドレスは、特定の条件下で特定のタスクを実行する事前に作成された関数です。

両者が協力して最も豊かなイーサリアムの生態を創り出し、ニーモニックワード、ウォレット、秘密鍵、スマートコントラクトなどの概念も人々の心に深く根付いていますが、実はこれはイーサリアムの最適解ではありません。イーサリアムを使用し、2 セットのアドレス タイプを維持すると、メイン ネットワークの運用効率が低下します。たとえば、アドレスがどのタイプのアドレスに属するかを決定するために追加のオーバーヘッドが必要になります。また、複雑な操作には高価なガス料金が必要になることは言うまでもありません。

したがって、2015 年以来、私たちは 2 つを結合することを常に模索してきました。現在の 4337 提案は、スキーム設計の成功に最も近いものです。コンセンサス層レベルでメイン ネットワークを変更する代わりに、2 つを統合する「インテリジェンス」セキュリティと効率のバランスをとるために。

ユーザーはユーザー オペレーションと呼ばれるオフチェーン情報を送信することが期待されており、その情報はブロック ビルダーによって収集され、バッチ化されます。ビルダーは、これらのアクションをフィルタリングして、料金を支払うアクションのみを確実に受け入れる責任があります。また、ユーザー操作用に別の Mempool があり、この Mempool に接続されているノードは ERC-4337 固有の検証を実行して、ユーザー操作が転送される前に料金の支払いが保証されていることを確認します。

これを行うことの利点は次のとおりです。

• より賢く。スマート コントラクトの論理的な性質により、より複雑な操作が可能になります。

• より安全です。ウォレットには、マルチシグネチャ機能とニーモニックワードを取り除くためのソーシャルリカバリ機能を組み込むことができます。

• より柔軟に。たとえば、他者によるスポンサーシップ取引を実現し、Gas に支払う ETH がないというジレンマを回避できます。

本質的に、ERC-4337 によって設計されたアカウント抽象化は、スマート コントラクトを通常のアカウントに「委任」し、いくつかの複雑なロジックを機能させることです。ユーザーは、内部ロジックを深く理解することなく、フロントエンドでのみ便利だと感じます。

最初のレベルのタイトル

自然な一致: アカウントの抽象化とロールアップの接点

アカウントの抽象化を使用する前に、まず現在のアカウントの抽象化とロールアップの特性を要約し、この 2 つをどこで組み合わせることができるかを調べます。

• アカウントの抽象化: 機密性、インテリジェンス、および汎用性がありますが、多くの手順によって大量のデータが発生するため、ガス料金が高くなります。Zk-Rollup はデータの削減に優れています。

• 豊富な機能：ウォレットのマルチシグネチャによりセキュリティが確保され、権限分割が管理しやすくなりますが、ロジックが複雑になり、セキュリティホールが拡大します。

• まだ爆発していない: ロールアップはまだ ZK 以前の時代にあり、経常口座抽象化ソリューションは大規模な L2 の実用性を前提としており、まだ研究前の技術です。

• 将来の一貫性: L2 が段階的に形成された後は、コンセンサス層は変更されず、スマート コントラクトの用途が広がり、アカウント抽象化のセキュリティも保証されます。

アカウントの抽象化によりアドレスのインテリジェンスは向上しますが、現時点ではユーザーへの直接プロモーションには適していません。その複雑さはガス料金を直接押し上げ、セキュリティを低下させます。他の人のスポンサー付きトランザクションを例に挙げると、メインネットワークの運用危機。

ガス料金値上げの提案も提案書に詳しく記載されており、これが今回 Vitalik が ERC-4337 を補足する直接の動機でもありますが、理論的には、アカウント抽象アドレスをすべてのステップで計算する必要があり、より多くのコンピューティング リソースが必要になります。安全性を確保するために、トランザクションには、コントラクト アドレスの設定とプロキシ アドレスの設定にかかる次の 1 回限りのコストが含まれる必要があります。

従来の EOA 外部アカウント アドレスは、そのような「複雑な」トランザクション ロジックを必要としません。イーサリアムのメイン ネットワーク上で手動で検証および設定されており、直接使用できます。アカウント トランザクションのガス料金は、通常のアカウントの約 1/2 です。アカウントの抽象化。

したがって、より安価なソリューションが使用される前に、アカウント抽象化の複雑さによってイーサリアムの実行速度が低下します。これが、圧縮データを使用してグローバルな検証結果を表示することに優れている ZK-Rollup のチャンスとなります。

今回Vitalikが更新した提案内容は、実際にはアカウント抽象化とRollupのデータインターフェースをオープン化し、アカウント抽象化で生成されたデータをL2ソリューションでも処理できるようにするというもので、改善点は、アカウント抽象化でしか処理できない機能をパッケージ化することです。これはロールアップのアイデアに非常に近いものですが、トランザクションの正当性を保証するために依然として SNARK テクノロジーを使用しています。

ロールアップとアカウント抽象化を組み合わせた後、イーサリアムは、より洗練されたソリューションに依存するコンセンサス層を改善する必要なしに、共通データ、便利な検証、および高いセキュリティの特性を提示することが想像できます。

さまざまなロールアップ ソリューションと同様に、アカウントの抽象化にも生態学的爆発の可能性が生じる可能性があります。たとえば、EVM エコシステムで最大のスマート コントラクト マルチシグネチャ ウォレットである Gnosis-Safe には、技術的な堀がなくなり、新しいラウンドの物語モデルは、より新しいソリューションの出現を促進します。

レイヤ 2 ソリューションでは、StarkNet は、検証と実行の分離、ナンス フィールドの追加など、エントリ ポイント コントラクトで指定されたアカウント抽象化モジュールを含む、設計の最初からアカウント抽象化機能を組み込むことも試みています。プロトコルレベルまでトランザクションの一意性などを強制します。

エピローグ

エピローグ

2015 年に初めて実際のアカウント抽象化スキームが提案されてから 7 年以上が経過しました。ZK-Rollup の遅々たる進歩を背景に、アカウント抽象化機能の実現には依然として長い時間がかかりますが、ちょうど PoW の登場により、アカウント抽象化の変革が始まりました。 PoSは現在も実現しており、イーサリアムは既定路線に沿って発展しています。アカウント抽象化は、PoS、Layer 2、DankSharding などで長期的に計画されている主要な基本機能として、PoS および Zk-rollup バージョンの Layer 2 が実装された後、より広く使用されるようになります。

ロールアップ互換のアカウント抽象化ソリューションが増えれば、そう遠くない将来にニーモニック フレーズを廃止し、Web 2 レベルのユーザー エクスペリエンスと Web 3 のセキュリティとプライバシーのエクスペリエンスを真に実現できるようになるかもしれません。