原作者：亀まどかIOBC Capital
実際、イーサリアム システムには 2 種類のアカウントがあります。
1 つは秘密キーによって制御されます外部アカウント(外部所有アカウント、EOA)、私たちが使用するウォレット内のアカウントなど、このタイプのアカウントには独自の残高があります。所有者は、トランザクションを作成して署名することで、外部アカウントからメッセージを送信できます。
もう 1 つは、ブロックチェーンにデプロイされたコードによって制御される契約アカウントであり、スマート コントラクト アカウント (スマート ウォレットとも呼ばれる) に保存されたイーサリアム仮想マシン コードによって制御されます。契約アカウントが情報を受け取ると、その内部コードがアクティブになり、内部ストレージの読み取りと書き込み、新しい契約の作成などが可能になります。
最初のレベルのタイトル
アカウントの抽象化とは何ですか?
アカウントの抽象化は、上記の 2 つのアカウントを改良したもので、2 つの間の境界を曖昧にし、複雑なロジックを備えた汎用アカウントにしようとしています。アカウントに契約アカウントと外部アカウントの機能を同時に持たせることができます。
最初のレベルのタイトル
アカウント抽象化のさまざまなスキーム
アカウントの抽象化を実現することは、常にイーサリアム開発者コミュニティのビジョンでした。コミュニティでは次のようなさまざまな提案も行われています。EIP-86，EIP-2938待って。
EIP-86 はアカウント抽象化のための技術的な準備であり、ユーザーがスマート コントラクトに基づいてアカウントを作成できるようにする新しいアカウント タイプを定義します。
Ethereum プロトコル自体は、ECDSA で保護された外部アカウント (EOA) から発生するトランザクションにすべてをパッケージ化する必要があり、すべてのユーザー アクションを EOA からのトランザクションでラップする必要があり、これには 21,000 ガスのコストがかかります。ユーザーはガス料金を支払うために別の EOA で ETH を所有する必要があります。
EIP-86 によって提案されたアカウント抽象化は、送信者として EOA が必要な従来のトランザクションと比較して、送信者を持たない新しいタイプのトランザクションをもたらします。このようなトランザクションは、トランザクション ハッシュの一意性を破壊します。 EIP-86 は当初、Metropolis フェーズでアップグレードされる予定でしたが、上記の問題により、開発者は Metropolis への導入を延期することを決定しました。
EIP-2938 はアカウント抽象化ソリューションを提供し、イーサリアム プロトコルの一部を変更することで、契約アカウントは外部アカウントと同じようにトランザクションを開始できます。ただし、このソリューションはコンセンサス層でイーサリアムプロトコルを変更する必要があるため、広く受け入れられていません。
新しいプロトコルERC-4337最初のレベルのタイトル
ERC-4337はどのように実装されていますか?
ERC-4337 はプロトコルのコンセンサスを変更しようとするものではなく、システム内のメモリプールの機能を複製します。
ユーザーは UserOperation (UserOperation) オブジェクトを送信します、ユーザーの意図、署名、その他のデータが含まれています。ユーザー アクション用に別のメモリプールがあり、このプールに接続されているノードは ERC-4337 固有の検証を実行してアクションをフィルタリングし、料金を支払うアクションのみを確実に受信できるようにします。
これらのユーザー アクションは、Flashbot サービスを使用してマイナーまたはパッケージャーによってバッチで収集され、パッケージ化されます。単一バンドルトランザクション、イーサリアムブロックに含まれています。パッカーはイーサリアムでのバンドル取引に対してガス料金を支払います、そして個々の UserOperation が支払う金額に対して補償されます。パッケージャは、コスト優先ロジックを使用して、含める UserOperation オブジェクトを選択します。
ユーザー オペレーション UserOperation はトランザクションのように見えますが、ABI でエンコードされた構造であり、次のフィールドが含まれます。
1. 送信者: 操作を実行するウォレット。
2. nonce と署名: ウォレットが操作を検証できるようにウォレット検証関数に渡されるパラメータ。
3. initCode: ウォレットがまだ存在しない場合、ウォレットの作成に使用される初期化コード。
4. callData: 実際の実行ステップでウォレットを呼び出すために使用されるデータ。
そして、各ウォレットはスマート コントラクトであり、これには次の 2 つの機能が含まれている必要があります。
1. validateUserOp。UserOperation を入力として受け入れます。この関数は、UserOperation で署名と nonce を検証し、検証が成功した場合は料金を支払って nonce を増やし、検証が失敗した場合は例外をスローする必要があります。
最初のレベルのタイトル
ERC-4337 によってもたらされる変更
この提案が一般的に採用されれば、署名検証はイーサリアム仮想マシン (EVM) に移行されました、 validateUserOp 関数は、任意の署名と乱数の検証ロジックを追加し、検証ロジックをより柔軟にします。
このようにして、トランザクションに署名するときに新しい暗号ツールを使用でき、ウォレットは次のような新しい機能も提供できます。
マルチシグネチャ。
社会的回復。
より効率的でシンプルな署名アルゴリズム (Schnorr、BLS など)。
ポスト量子安全署名アルゴリズム (Lamport、Winternitz など)。
アップグレード可能なウォレット。
このアプローチは、トランザクションがスマート コントラクトを通じてガス料金を支払うことを可能にするなど、他のさまざまなトランザクション許可管理も可能にします。
現時点では、イーサリアム上でやり取りするための外部ウォレットのガス料金は、ウォレット内の ETH によってのみ支払うことができます。ETH を持たずにウォレット内に ERC-20 トークンのみがある場合、これらのトークンを外部に転送する方法はありません。 ERC-4337が採用されると、ユーザーはアカウント内のERC-20トークンを使用して料金を支払うことができ、マイナーノードは仲介者として契約を使用してETHチェーンの支払いを行い、ユーザーのERC-20トークンを取得します。
抽象化が実現した後は、外部アカウントの所有者によってトランザクションに署名されブロードキャストされることは、トランザクションを開始する唯一の方法ではなくなります。これにより、イーサリアムがメタトランザクションの中継者として機能する可能性が開かれます。イーサリアム上の現在のアプリケーションの多くは、ブロックチェーン上でユーザートランザクションを公開し、中継者に料金を支払うために中継者に依存しています。より複雑なコントラクトをウォレットに組み込むことができれば、一部の中継者は不要になり、中継者に追加料金を支払う必要もなくなります。
新しいスキームには多くの利点がありますが、いくつかの問題にも直面しています。
最も顕著な点はガスコストが高く、ERC-4337の基本操作には約42,000ガスが必要であるのに対し、通常のトランザクションには21,000ガスが必要であり、その理由は次のとおりです。
1. ストレージの読み取り/書き込みコストを個別に支払う必要があります。EOA の場合、これらのコストは 21000 ガスの 1 回の支払いにまとめられます。
(1) pubkey+nonce (~5000) を含むストレージ スロットを編集します。
(2) ユーザー操作呼び出しデータコスト (約 4500、圧縮により約 2500 に削減可能)。
（3）ECRECOVER (~3000)；
(4) ウォレット自体への初回アクセス (~2600)
(5) 受取人口座への初回アクセス(~2600)
(6) ETHを受取人の口座に送金(~9000)
(7) 料金を支払うためにストレージを編集 (~5000)
(8) エージェントを含むストレージ スロット (~2100) にアクセスし、次にエージェント自体 (~2600) にアクセスします。
2. 上記のストレージ読み取り/書き込みコストに加えて、コントラクトでは「ビジネス ロジック」(UserOperation のアンパック、ハッシュ、変数のシャッフルなど) を実行する必要もあります。
3. ログ料金を支払うためにガスを消費する必要があります (EOA はログを公開しません)。
4. 1 回限りの契約作成コスト (約 32,000 ガス、プロキシ内のコード バイトごとに 200 ガス、およびプロキシ アドレスの設定に 20,000 ガス)
つまり、アカウントの抽象アドレスのすべてのステップを計算する必要があるため、より多くのリソースが消費され、追加のコストが追加されます。
幸いなことに、これは解決できないことではありません。
Rollup はデータ圧縮に優れているため、複雑なデータを含むアカウント抽象化スキームに自然に適合します。
ヴィタリック氏の最新の提案では、アカウント抽象化によって生成されたデータをレイヤー 2 を通じて処理することが提案されています。改良点は、ステップバイステップでしか実現できない機能をバッチトランザクションにパッケージ化し、SNARK技術を利用してトランザクションの正当性を確保することです。
エピローグ
エピローグ
イーサリアムのレイヤー 2 の開発に焦点を当てるパターンが確立された今、イーサリアムをアップグレードするための Vitalik のフォローアップ計画は、アカウントの抽象化に目を向け始めています。最新の提案を紹介しますロールアップ + アカウントの抽象化テクニカルパス。さまざまなロールアップ プロバイダーも、アカウントの抽象化と互換性のある新しいバージョンをリリースしました。
今年6月、zkSyncは「アカウント抽象化」機能の追加やイーサリアムEVMとの互換性向上などのV2アップデート情報を公開した。 10月にはBLS署名アルゴリズムを含む署名集約機能を追加した新バージョンERC-4337がリリースされた。署名の集約により、ビルダーとバッチ送信者は署名 (BLS、SNARK など) も集約できるため、チェーン上のデータが大幅に削減され、ロールアップのデータ コストが削減されます。
アカウントの抽象化によってもたらされる変化には、生態学的爆発の可能性も含まれていると信じる理由があります。 Rollup の開発に伴い、Rollup と組み合わせることができるアカウントの抽象化も、より優れた、より洗練されたソリューションを開発する必要があります。
