アカウント抽象化の実装には時間がかかりますが、将来的には新規ユーザーの敷居を下げ、ユーザーエクスペリエンスを向上させる唯一の方法となるでしょう。

アカウント抽象化の実装には時間がかかりますが、将来的には新規ユーザーの敷居を下げ、ユーザーエクスペリエンスを向上させる唯一の方法となるでしょう。

セルフホストする必要があるウォレット アドレスは、チェーンの世界ではユーザーの「アカウント」ですが、これはユーザーが Web3 に参入するのを妨げる大きな障害でもあります。アカウント改善のため、7年以上続いた実験です。 2022 年 10 月まで、Vitalik はアカウント抽象化に関する EIP-4337 を紹介するスレッドをツイートしました。アカ​​ウント抽象化は、11 月にボゴタで開催された devcon 6 のさまざまな共有セッションに頻繁に登場し、アカウント抽象化に関する議論を引き起こしました。抽象化、コントラクト ウォレット、4337 についての広範な活発な議論。

アカウントの抽象化は、オンチェーンでユーザーをサポートするために非常に重要です。 「キーではなく、コインでもありません。」 セルフホスティングが仮想通貨のベテランによって何度強調されてきたかわかりませんが、それを実行できる人はまだ非常に少数です。アカウントの抽象化によってもたらされる非常に高い自由度により、一般ユーザーはより安全で使いやすい分散エクスペリエンスを真に得ることができ、セルフホスティングはもはや一部のマニアの偉業ではなくなります。 FTX の爆発は暗号化世界の将来に深い影を落としていますが、分散型アプリケーションとセルフホスティングの必要性が証明されたことは間違いありません。アカウント抽象化の実装により、暗号化業界は中央集権的な悪役や皇帝からより自由になり、より高い次元の分散化と自由に向けて進むことができるようになります。

現在、EIP-4337 はアカウント抽象化の方向性を示すものとして多くの人に考えられていますが、この提案はまだ理想的な草案にすぎません。たとえば、理想的にはトランザクションのパッケージングでガスを共有できますが、実際には検証プロセスによってガスの消費量が増加します。たとえば、理想的なコントラクトウォレットは統一された構造を適用していますが、実際には自主的な ERC 提案であり、その効果は非常に大きくなります。弱い; たとえば、EIP-4337 を使用する理想的なアカウントはより良いユーザー エクスペリエンスをもたらすことができますが、実際には、多くの dapp がコントラクト アドレスのやり取りを禁止しているという厄介な状況です...

最初のレベルのタイトル

文章

アカウント抽象化の具体的な意味を議論する前に、まずそれを分解して「アカウント」と「抽象」とは何かを理解することができます。

副題

アカウント アカウント

Ethereum には、外部所有アカウント (EOA) と契約アカウント (契約アカウント - CA) の 2 つの基本的なアカウント タイプがあります。

副題

抽象的な

抽象化とは、特定の問題から共通のパターンを抽出し、一般的な解決策を使用してそれらに対処することを指します。言い換えれば、抽象化は「一般化」のプロセスであり、特殊性を取り除き、共通性を見つける必要があります。

おもちゃの車やレゴ ブロックなど、より現実的で具体的な例を使って抽象化を理解しましょう。小型自動車玩具の構造は特殊で特殊であり、4 つの車輪と車体などの一連の特殊な部品で構成されています。小さなトラックのおもちゃや飛行機のおもちゃが欲しい場合は、新しいおもちゃを購入する必要があります。レゴ ビルディング ブロックはより抽象的でより一般的です。彼はおもちゃを立方体や球などの一般的なビルディング ブロック モジュールに抽象化します。プレイヤーはこれらのビルディング ブロックを使用して、あらゆるおもちゃの形を構築できます。

副題

アカウントの抽象化

アカウントの抽象化とは、イーサリアム アカウントの一般化と特殊性の除去を指します。また、前の記事で、イーサリアムには EOA と CA という 2 種類のアカウントがあり、それぞれに独自の特徴があることについても述べました。そのうち EOA はより「トップレベル」のアカウントであり、トランザクションの開始と ETH の支払いは EOA にのみ依存できます。ガス、および EOA は、特定の Secp 256 k 1 楕円暗号化アルゴリズムによって実装される ECDSA 署名スキームのみを使用できます。ただし、EOA はコード ロジックを直接サポートしません。コード ロジックをサポートする CA を展開し、EOA によってトランザクションを開始する必要があります。

これらはすべて、イーサリアムの最下層の特別な必須設計です。アカウント抽象化の目的は、イーサリアムアカウントを一般化し、より自由度を高め、アカウントの可能性を広げることです。アカウントの特異性を一般化することにより、アカウントの次の抽象キーを抽出できます。

1. 暗号化の抽象化: つまり、アカウントの署名検証が特定の暗号化アルゴリズムに限定されなくなり、ユーザーはセキュリティ メカニズムとしてさまざまな暗号化アルゴリズムをカスタマイズして選択できるようになります。

2. アカウント関数の抽象化: コード ロジックをサポートし、カスタム関数を実現します。

3. トランザクションの抽象化: アカウントがトランザクションを開始できる、ガス支払いのカスタマイズ

最初のレベルのタイトル

アカウント抽象化の開発プロセス - 急進的から中程度、最終状態への移行まで

抽象化に関する議論は、2015 年のイーサリアム ネットワークの正式リリースから数か月後に始まり、今年 10 月まで新しい提案が提出され続けました。アカウント抽象化に関連する EIP を時系列で整理し、アカウント抽象化のさまざまなソリューションと発展を垣間見ることができます。

ここで、アカウント抽象化スキームの開発は 3 つの段階に分かれています。

2015年のイーサリアム発足以来、EIP-86は初めてアカウントの抽象化を提案し、理想主義に満ちた5年間にわたる抜本的な改革に着手した。イーサリアムの基盤となるコードを直接変更するこれらのアカウント抽象化提案は審査段階に進むことができませんでしたが、いくつかの補助提案は通過し、アカウント抽象化の一定の基盤を築きました。たとえば、EIP-1014 は、コントラクトを展開することなくコントラクトアドレスを事前に計算できることを実現し、EIP-1271 は、コントラクトアカウントを介して署名するスキームを実現します。

急進的な改革に挫折したアカウントの抽象化は、より控えめな妥協点を模索し始めました。現段階では、イーサリアムの基盤となるコードを直接変更する試みではなくなりましたが、主に開発者が自発的に採用する ERC 標準を立ち上げることが目的となっています。 EIP-4337 が誕生し、アカウント抽象化が穏やかに進む時代が始まりました。最近、EIP-5189 は 4337 のアイデアに基づいたさらなる最適化スキームを提案しました。

ERC 標準のアカウント抽象化スキームは、基礎となるコードの変更が遅く、影響が大きく、互換性が低いための妥協策です。このような穏やかなアプローチは、アカウント抽象化の概念の普及に役立ち、アカウント抽象化をまず理想的な議論から実践的な現実に実装し、段階的に実践し、既存のソリューションの欠点を継続的に改善していくことができます。

副題

過去 - 抜本的改革

関連提案が最初に提案されて以来、アカウントの抽象化に対する解決策は常にコンセンサス層を直接変更する暴力的な改革案であり、現段階の提案では継続的に改善されてきました。

EIP-101 

プログラムの紹介:

2015 年末、イーサリアムの創設者 Vitalik は EIP-101 で抽象化を初めて提案しました。この提案では、Vitalik 氏は Serenity のアカウント システムの抽象的な設計について議論し、アカウントを 4 つのフィールドからコードとストレージの 2 つのフィールドのみに簡素化し、ETH はトークン コントラクトに保存され、ユーザー残高をマッピングするアドレスは予約されています。 ; トランザクションは 8 フィールドから 4 フィールドに簡略化され、アカウントとトランザクションが大幅に抽象化されます。

アドバンテージ：

• ユーザー定義のセキュリティ モード。他の暗号化アルゴリズムを使用してアカウントのセキュリティを保護します。

• ETH と他の ERC 20 トークンは同等に扱うことができます

• マルチシグなどのカスタム アカウント機能の間接化が減少しました。

問題点と現状:

この案はアカウントシステムに大幅な変更が加えられており、互換性の問題やセキュリティ上のリスクがあるため、シャーディング後に一時保留となり、現在は停滞している状態です。

EIP-86 

プログラムの紹介:

2017 年に、Vitalik は EIP-86 を提案し、トランザクション ソースと署名を抽象化し、基礎となるコードに再び根本的な変更を加えました。この提案により、ユーザーは任意の署名およびノンス チェック メカニズムを使用できるアカウント コントラクトを作成できるようになります。このスキームには、エントリー ポイント コントラクトがあり、誰でもこのコントラクトを通じてトランザクションを送信できます。アカウント コントラクトは、エントリー ポイントからデータを受け取り、署名をチェックします。それが正しければ、マイナーにガス代を支払います。このソリューションはアカウント抽象化の準備であり、ユーザーが署名アルゴリズムをカスタマイズできるようになり、イーサリアムのハードコードされた ECDSA とデフォルトの nonce メカニズムの使用は必須ではなくなりました; 同時に、ガスは署名が検証された後に契約アカウントによって支払われます正しく。

アドバンテージ：

• マルチシグネチャ: すべてのマルチシグネチャの人が ETH を所有する必要はなく、マルチシグネチャ情報を含むトランザクションはマルチシグネチャ アカウントに直接送信でき、マルチシグネチャ アカウントはマルチシグネチャ アカウントによって直接支払われます。

• リング署名混合通貨：リング署名とは、署名がつながってリングを形成することを指し、開始点を判断することはできません。 n 人のユーザーが同じ数のトークンをコントラクトに送信し、リング署名方式を使用して同じ数のトークンを引き出します。ただし、トークンを引き出すためのガスを準備する必要があるため、この段階では暴露のリスクがあります。したがって、この提案を通じて、抽出されたトークンから直接ガスを支払うことができ、このシナリオでのプライバシーが確保されます。

• カスタム暗号化: ユーザーは、Lamport などの量子安全な署名方法を使用してアカウントのセキュリティを確保できます。

• トランザクションの有効期限の設定など、暗号化以外の機能をカスタマイズします。

問題点と現状:

• 新しいトランザクション タイプにはトランザクション送信者 (すべてのエントリ ポイント) がないため、ハッシュの一意性が失われます。ハッシュの一意性に基づくプロトコル操作と互換性がありません

• ガス無料化の必要性は不十分であり、現状では代理店契約でも実現可能だが、コストは若干高くなる

• マイナーのマイニング戦略は大きな影響を受ける

• 新しいトランザクション タイプは nonce、gasprice、value およびその他のフィールドを保持し、0 に設定されます。これにはコードの優雅さが欠けています。

• したがって、こうした問題点を踏まえまして、最終的には延期され、現在停滞しているという状況でございます。

EIP-859 

プログラムの紹介:

この提案では、新しいトランザクション タイプと新しいオペコードが導入されていますが、トランザクション ハッシュの一意性を維持するために、トランザクションでは nonce フィールドが依然として必須です。ガス支払い用の paygas 操作コードを導入し、トランザクションの一部の検証とトランザクションの一部の実行の間の論理境界として機能します。

アドバンテージ：

• カスタマイズされた署名スキーム カスタマイズされた署名スキーム

• トランザクションハッシュの一意性を維持します

• より複雑な検証シナリオをサポートし、ガスを節約できます。たとえば、トークン ICO 中には、同時に 10,000 のトランザクションが参加しますが、トークンはオンラインでのみ最初の 5,000 トランザクションをサポートします。既存のロジックによれば、10,000 のトランザクションはすべてサポートされます。この提案では、最後の 5,000 件のトランザクションをブロックチェーンに含めないように契約で設定できるため、ガス消費量が節約され、無効なスパムトランザクションが削減されます。

問題点と現状:

• ERC-20 トークンによるガス支払いはサポートされていません

• Cannot use ERC 20 s to pay for gas

実際、この提案はまだ最終的な草案を形成しておらず、議論の段階にすぎません。この提案はいくつかのイーサリアム開発者会議でも議論されましたが、十分に成熟しておらず、当時のアップグレードには多くのコンテンツが含まれていたため、この提案も永久に棚上げされました。

EIP-1014 

プログラムの紹介:

この提案はアカウントの抽象化について直接言及していませんが、アカウントの抽象化の開発と密接に関連しています。本提案では、実際にコントラクトアドレスをデプロイする前にコントラクトアドレスを事前に計算し、コントラクトアドレスをデプロイする前にそのアドレスにアセットを送信し、最初のトランザクションでコントラクトアドレスを使用する場合はデプロイを進める方法を導入します。

アドバンテージ：

• コスト削減: ユーザーは、契約を展開するためにガスを支払う前に、事前に契約アドレスを計算できます。

• マルチチェーン コントラクト アドレスの一貫性: コントラクト アドレスは存在する前にデプロイする必要があるため、EOA とは異なり、マルチチェーンの一貫性を直接実現できます。オペコード内のソルト パラメータを通じて、コントラクト アドレスもマルチチェーンの一貫性を実現できます。

現状：

この提案は最終的に可決され、スマートコントラクトウォレットの開発に重要な基盤が築かれました。

EIP-1271 

プログラムの紹介:

この提案は、契約アカウントを表す署名が有効であることを検証するための一連の基準を提供します。これにより、契約アカウントは EOA のような署名検証を実行できるようになります。

アドバンテージ：

この提案は、開発者が自主的に採用できる確立された ERC 標準です。これにより、将来の契約アカウントの促進と普及のための良い基盤が築かれました。dapp が契約アドレスの署名をサポートする意思がある限り、EIP-1271 のコードを契約に追加するだけです。

現状：

この提案は最終的に可決され、opensea が署名ログイン用の authereum コントラクトウォレットをサポートするなど、すでに実用化されています。

EIP-2938 

プログラムの紹介:

2020 年、Vitalik は多くの人々と協力して、より完全なアカウント抽象化ソリューションを提案しました。アカウントの種類を 1 つの契約アカウントに統一する以前のアカウント抽象化の目標と比較して、EIP-2938 提案では既存の EOA と契約アカウントを引き続き維持しますが、トランザクション ガスと契約を支払うことができるように契約をトップレベルのアカウントとして受け入れます。トランザクション実行プロセスを開始します。

この提案は、新しいタイプのトランザクションであるアカウント抽象化トランザクションを定義し、2 つのオペコード (Nonce と PAYGAS) を導入します。この改善には、依然としてイーサリアムの基盤となるコードの変更が必要でした。

EIP-2938 では、このソリューションの実装も計画し、特定のアプリケーション シナリオについて説明します。アカウントの抽象化は 2 つのレベルに分かれています。1 つ目はシングルテナントのアカウントの抽象化を実装し、次にマルチテナントのアカウントの抽象化に拡張します。

利点とシナリオ:

シングルテナント シングルテナント

• ECDSA 以外の署名検証方法 (BLS、ポスト量子など) の使用をカスタマイズする

• マルチ署名検証やソーシャルリカバリなどのコントラクトウォレット機能を追加

• ERC-20 トークンでガソリン代を支払います。

マルチテナント マルチテナント

• プライバシー: トルネード キャッシュなどのプライバシー保護のシナリオでは、アカウントはプライバシーを公開するためにガス料金を準備する必要がなくなりました。

• ガスの節約: たとえば、裁定取引の機会が発生すると、多数の裁定取引者が同時に裁定取引を開始し、最初の裁定取引が成功した後、他の裁定取引は失敗しますが、依然としてブロックにパッケージ化されます。アカウントが抽象化された後、裁定取引者は、失敗した分の料金を支払う必要がなくなりました。アービトラージのためにガスを支払うと、チェーン上のスパムトランザクションの数が減ります。

問題点と現状：

計画はより詳細になりましたが、マルチテナント段階の技術計画はまだ策定されていません。そして、この解決策は技術的にも経済的にも十分に効率的であるとは考えられなかったため、最終段階には入りませんでした。

副題

今 - 穏やかな変化

イーサリアム開発者らはイーサリアムの統合とシャーディングに注力しており、基礎となるプロトコルを直接変更する計画を進めるのは難しく、ヴィタリック氏が代表を務める開発者らは妥協して、比較的穏やかで間接的な代替案を提案するしかない。

EIP 4337 

プログラムの紹介:

この提案は、イーサリアムの基礎となるコードの変更を必要としない最初のアカウント抽象化提案です。 ERC-4337 では、UserOperation オブジェクトが導入されています。ユーザーは UserOperation オブジェクトを別のメモリ プールに送信します。 Bundler はこれらのオブジェクトをトランザクションにパッケージ化し、Entry Point コントラクトを呼び出し、トランザクションはブロックに組み込まれます。

アドバンテージ：

• カスタム署名アルゴリズム: ECDSA 以外の署名アルゴリズムをサポート

• 機能のカスタマイズ：契約コードによりガス決済やソーシャルリカバリーなどの機能を実現可能

問題点と現状：

• アップグレード不可: 標準をサポートするには、ユーザーは資産とアクティビティを新しいアドレスに転送する必要があります。

• ガスのオーバーヘッドが高くなります。導入されたユーザー操作によりガス消費量が増加します。

• 互換性の問題: 一部の既存の DAPP またはプロトコルでは、契約アカウントとのやり取りが禁止されている場合があります。

実際には多くの問題がありますが、Vitalik は短期的には ERC-4337 を強力にサポートし、実践の過程でより良い解決策を研究し、改善を継続したいと考えています。大規模なプロモーションを達成した後、合意形成とスケール効果は、既存のアプリケーションの変更を促進し、契約アカウントの相互作用をサポートし、ERC-1271 の契約署名標準をサポートするのに役立ちます。現在、EIP 4337 はまだドラフト状態にあり、次の段階に進むのを待っています。

EIP-5189 

プログラムの紹介:

この提案は、トランザクションのパッケージ化プロセスを変革するための ERC 提案であり、基礎となるコードの変更も必要ありません。この提案では、エンドーサーの役割が導入されており、コントラクトウォレットの開発者は、送信されたメタトランザクションの品質を確認し、トランザクションをメモリプールに残す必要があるかどうかをバンドラーが決定できるように、エンドーサーコントラクトを定義します。この提案では、アカウントをバンドラーに抽象化するリスクをウォレット開発者に移し、開発者がエンドーサー契約のコーディングとデプロイを担当することを期待しています。

アドバンテージ：

バンドラーがメタトランザクションをスクリーニングするためのしきい値とリスクを軽減しました。

問題点と現状：

この提案は現在草案段階にあり、まだ初期段階にあります。

副題

将来 - 必須

Vitalik氏は、ERC-4337の実装過程において、契約アドレスへのEOAのアップグレードやガスコストの最適化など、ERC-4337の欠点を改善するための新しい提案を継続的に導入していきたいと述べた。考えられる道筋は、自主的な採用から広く普及し、その後、イーサリアムのアカウントタイプを 1 つに統一するという最終目標を達成するための強制的な変換の最終実装に至ることになるでしょう。

EIP-3074 

プログラムの紹介:

EIP 3074 の提案は、実際には EIP 4337 よりも前のものです。新しいトランザクション タイプは導入されませんでしたが、AUTH と AUTHCALL という 2 つのオペレーション コードが導入されました。これにより、EOA 制御をスマート コントラクトに委任できるようになり、すべての EOA がスマート コントラクトを持つことが可能になります。ウォレット機能。

アドバンテージ：

• ガスの支払い: ガス料金は別のアカウントで支払うことができ、ETH を保持していないアドレスでもトークンを送信できます。

• バッチトランザクション: 1 回の呼び出しで複数のトランザクションを送信し、トランザクション手数料を削減します。

問題点と現状：

この提案ではイーサリアムコードの変更が必要であり、上海のアップグレードフェーズで実装される予定だが、セキュリティ上のさまざまな不確実性のため、まだ検討段階で検討中である。

EIP-5003 

プログラムの紹介:

この提案は、ＥＩＰ ３０７４の拡張提案であり、契約アカウントへのＥＯＡのアップグレードを実現するために、認可されたアドレスが認可されたアドレスのコードを設定できるようにする新しいオペレーションコードＡＵＴＨＵＳＵＲＰを導入する。

アドバンテージ：

EOAから契約アカウントへのアップグレードを実現

現状：

副題

Layer 2 ？

上記の EIP 開発の歴史から、アカウントの抽象化は、イーサリアムのデュアルアカウント システムのレガシー問題を解決するためのものであることがわかりますが、性別はまだ高度ではないため、多くの障害に遭遇しました。比較すると、コードを直接変更するソリューションは、エコロジーが始まったばかりの新しいレイヤー 2 パブリック チェーンにより適している可能性があります。たとえば、Starknet はアカウントの抽象化をネイティブにサポートするチェーンであり、統一されたアカウント タイプが 1 つだけあり、プログラム可能で、トランザクションの送信、資産の送受信などが可能です。 10 月には、zksync 2.0 メインネットが開始され、アカウント抽象化の新機能も導入され、アカウントはトランザクションを開始し、アカウントにデプロイされたコード ロジックを実行できます。

さらに、イーサリアムのメインネットと比較して、レイヤー 2 のガス料金は低いことが多く、展開にガスを支払う必要があるスマート コントラクト アカウントの場合、ユーザー エクスペリエンスが向上し、コストも低くなります。

最初のレベルのタイトル

アカウントの抽象的なトラック マップ

アカウントの抽象化とは、将来のアカウントが契約アカウントと同様の機能を持つことを意味します。アカウントの抽象化がコンセンサスと基礎となるコードで完全に実現される前に、すでにいくつかのスマート コントラクト ウォレット製品 (スマート コントラクト ウォレット-SCW) が存在し、コントラクト アカウントの利点を認識し、EOA アカウント システム以外のオプションをユーザーに提供しています。

画像の説明

アカウントの抽象概念プロジェクトの比較

副題

アカウントの抽象化は必要ですか?

MetaMask のような従来の EOA ウォレットは、ユーザーエクスペリエンスが劣悪であると批判されており、ユーザーは秘密鍵やニーモニックワードを適切に管理する必要があり、秘密鍵漏洩のリスクを負う必要があります。このため、Web3 の世界への最初の一歩は非常に敷居が高くなります。

最近では、多くのユーザーとトラフィックを抱える多くの Web2 企業が Web3 への拡張を試みており、例えば Reddit がユーザーに Reddit NFT を発行すると、既存の Opensea のユーザー数をはるかに超える新規ユーザーを容易に獲得することができました。 NFTキャスティングプロセスを指導する際、redditはユーザーが理解できる敷居を下げるために最善を尽くし、アドレス、秘密キー、NFTなどの複雑な概念を曖昧にしました。

秘密キーのないコントラクトウォレットを使用すると、しきい値を根本的に取り除くことができ、多数の Web2 ユーザーが Web3 に参入するためのより良いチャネルが提供されます。

ただし、セキュリティと秘密キーのないエクスペリエンスは、アカウントの抽象化またはコントラクト アドレスを通じて実現する必要がありますか?

ない。

最初のタイプのオプションは、現在ほとんどの取引所で使用されている保管ウォレットです。つまり、秘密鍵はユーザーの手にはありませんが、取引所がユーザーに代わって資産を保持および管理し、ユーザーは完全に管理することはできません。自分たちの資金。このような管理されたウォレットはユーザーの敷居を大幅に下げることができますが、それに対応する信頼リスクもあります。最近のFTXの突然の爆発により、ユーザーは、保管されている資産が悪用される可能性があり、一見強力な機関も崩壊する可能性があることに気づきました。最も安全なオプションは、資産を自分の手で完全に管理することです。鍵でもコインでもありません。

別のタイプのウォレットは、マルチパーティ コンピューテーション (MPC) と呼ばれるテクノロジーを適用しており、一部のコントラクト ウォレットが実現したいセキュリティと秘密キーのないユーザー エクスペリエンスも実現できます。

一般に、MPC は主にしきい値署名 (TSS-しきい値署名スキーム) 方式を使用します。これは、秘密キーを断片化し、その断片を計算と暗号化のために分散型ネットワークに送信することを意味します。秘密キーの署名が必要な場合、フラグメントが結合されて完全な秘密キーが形成され、制御権限を分散することで単一障害点によるセキュリティ問題が回避されます。この方法はセルフカストディとカストディの中間に位置し、セミカストディウォレットと呼ぶことができます。

このロジックはマルチシグネチャ ウォレットと似ていますが、異なる点は、マルチシグネチャ ウォレットの各マルチ署名者が契約アカウントを制御するための完全な秘密キー署名を提供するのに対し、TSS の検証プロセスには秘密キーのみが含まれることです。以下はスマートコントラクトとは直接関係ありません。

To BのSafeheronやTo CのBitizenなど、優れたMPCウォレット製品も多数あります。

MPC は秘密鍵なしなどの機能も実装でき、MPC は EOA をベースにすることができるため、安価に使用でき、互換性も優れていると思われます。 MPC テクノロジーは、EVM チェーンだけでなく、他の非 EVM アカウントにも適用できます。それでは、コントラクトウォレットは秘密キーを持たないという目的に基づいているのでしょうか、それともアカウントの抽象化は本当に必要なのでしょうか?

今年5月、Coinbaseは、コントラクトウォレットの高価なガソリンや、ユーザーがMPCウォレットのプロモーションTwitterで十分な信頼できるガーディアンを見つけることができない可能性があるという事実などの問題に疑問を呈した。

そしてヴィタリックもこのツイッターで自身の態度を表明した。

Vitalik は、アカウント署名アルゴリズムをカスタマイズできるという目標を達成するために、プロトコル レベルでアカウントを抽象化したいと考えていることがわかります。現在イーサリアムによって強制されている ECDSA 署名アルゴリズムは最適な選択ではなく、MPC は ECDSA に基づく部分的なセキュリティ スキームにすぎません。アカウント抽象化が実現した後は、技術の発展に応じて、より高度で安全な署名アルゴリズム（量子耐性など）をそのまま利用できるようになります。

副題

アカウント抽象ウォレットの究極の形

アカウントの抽象化が普及し、合意に達すると、契約アカウントの互換性と経済性が向上します。ここでは、このタイプの製品の最終状態、提供できる機能、および適用可能なシナリオについても楽観的に予測または期待していますが、それには次の機能と適用シナリオが含まれる可能性があると考えられます。

1. 秘密キーが不要: ユーザーはニーモニックワードや秘密キーを保持する必要がなくなり、生体認証やデバイス認証などの複数の認証方法に合格できます。

2. アカウントの回復: アカウントの回復は、生体認証、社会的認証などを通じて実行できます。

3. ガスフリーインタラクション: ユーザーは、ガスとして ETH を事前に準備することなく、またはトランザクションが失敗した場合にガス料金を支払うことなく、トランザクションに含まれる ERC-20 トークンをガス支払いに使用したり、支払い用の固定口座を直接指定したりすることができます。

4. カスタム セキュリティ メカニズム: 暗号化の発展により、より優れたセキュリティ メカニズムを選択できるようになりました。

5. プライバシー: リング署名やその他の方法に基づいた、より効果的なオンチェーン プライバシー

6. アカウントの一時保管：ユーザーは管理者、時間、やり取りなどの要件を設定し、アカウントの管理を他人に委託し、時間や要件に達すると自動的に退会することができます。

7. アカウントの抵当/取引: アカウントにはチェーン上の資産と蓄積された信用履歴が含まれており、アカウント自体を直接抵当に入れてチェーン市場で取引することができます。

8. アカウント権限の制限と分割: アカウント内で NFT のみを使用し、トークンは使用しないなど、一部のアカウント権限を他のユーザーにライセンスできます。

9. カスタム ワークフロー: 自動化されたトリガーとプロセスを設定します。たとえば、アカウント A の残高が 1 ETH より 0.5 ETH 多い場合、超過した 0.5 ETH が自動的にアカウント B に送金され、特定のトークンが特定の価格に達すると、アカウント B は自動的に ETH を特定のトークンにスワップします。 。

10. トランザクション制限: トランザクション時間とクォータを設定でき、時間を超過したり、クォータを超過したトランザクションは成功しません。

11. ホワイトリスト/ブラックリスト: ブラックリストに登録されたアドレスとのやり取りを制限します。たとえば、以前にトルネード キャッシュが認可され、アドレスが他のプロトコル フロントエンドによってブロックされた後、ブラックリストに登録されたアドレスによって送信された資産は、他のアドレスへの「汚染」を避けるために自動的に返されます。虚偽の禁止。

12. アカウント分類管理システム: ユーザーはさまざまなシナリオで専用アカウントを使用し、より合理的なアカウント管理システムを備えています。たとえば、特定のアカウントは ETH のみをガスアカウントとして保存し、他のすべてのアカウントのインタラクションはガスアカウントによって支払われます、特定のアカウントは簡単に使用されないブルーチップ NFT のみを保存します、特定のアカウントは使用されますゲーム専用アカウントとして

13. 最初のレベルのタイトル

結論：

アカウントの抽象化の実現は誰もが期待する価値があります。これにより、チェーン上のユーザー数が大幅に増加するだけでなく、アカウントの抽象化が開発者にもたらす高い自由度が現在のアカウント システムの問題点を解決し、新しいアプリケーション、ゲームプレイ、想像力を生み出すことになるからです。

コードレベルでのアカウント抽象化の実装は障害と不確実性でいっぱいです。EIP-4337 のような妥協ソリューションには、高ガスや互換性の低さなどの実用的な問題がまだありますが、EIP-4337 を積極的に推進することは、コンセプトを促進し、機能を強化するための選択でもあります。コンセンサスです。概念の普及に伴い、アカウントの抽象化とコントラクトウォレットはニッチからメインストリームに移行し、ユーザーのニーズに基づいてプロトコルの互換性を促進し、新しいアカウントパラダイムを形成します。結局のところ、広範な合意の下で、イーサリアムには、アカウントの抽象化を達成するために基礎となるコードを直接変更する条件が備わっています。

最終的なアカウント抽象化が実装された後は、現在のアカウント システムの敷居が高く複雑なユーザー エクスペリエンスは、もは​​や当たり前のものとは考えられなくなります。この新しいアカウント システムは、Web3 の新しいユーザーとトラフィックを引き付けるのにさらに役立ち、エコロジーの活発な発展を刺激し、好循環を形成します。