原作者：Yuxing、SevenX Ventures

出典: フォーサイトニュース

まとめ：

将来のウォレット モデルは、B2B2C モデルに似たものになる可能性が高くなります。ウォレットは C エンド製品として存在しますが、他のアプリケーションをアプリ内ウォレットに統合して C エンド ユーザーを対象とする成熟した SDK ソリューションを提供することがより重要です。このうち、パッカーとアグリゲーターは初期は主に集中型で構築されますが、後からモジュール型のネットワークを形成することも可能ですが、この部分は価値獲得の核となるため、他の人が構築したパッカーネットワークを使用したウォレットを移行する必要があります。経済的利益のゲームを通じて。

Ethereum のアプリケーション シナリオが拡大および拡張し続けるにつれて、従来の Ethereum ウォレットの外部所有アカウント (EOA) ソリューションの欠点が徐々に明らかになってきています。機能はシンプルで、パフォーマンスも平均的です。同時トランザクションをサポートしておらず、キー管理の問題があります。スマート コントラクト ウォレットは、コントラクト アカウント (CA) をウォレット アドレスとして使用します。これは、EOA ウォレットの欠点を解決し、より強力な機能をもたらす、比較的新しい Ethereum ウォレット ソリューションです。将来的には、秘密鍵を慎重に保護しなくても、ほぼ同じレベルのセキュリティを享受できるようになります。分散型取引所では、中央集権型取引所の利便性を享受できますが、同時に、資金は常に自分の手元にあり、取引所が破産する可能性を心配する必要はありません...

少し前にリリースされたイーサリアム ロードマップの新バージョンでは、EOA ウォレットをスマート コントラクト ウォレットに移行するための重要な要素として、アカウント抽象化スマート コントラクト仕様 ERC-4337 が The Splurge に書き込まれました。では、スマート コントラクト ウォレットとは一体何でしょうか。アカウント抽象化とスマート コントラクト ウォレットの関係はどのようなものでしょうか。それらはどのように実装されるのでしょうか。将来の開発形態はどのようなものになるのでしょうか。また、どのような機会と課題が存在するのでしょうか。

イーサリアムアカウントの種類

Ethereum には、外部所有アカウント (EOA) とコントラクト アカウント (CA) の 2 種類のアカウントがあります。外部アカウントは、Ethereum でユーザーの残高をネイティブに記録するウォレット アカウント アドレスです。契約アカウントはもともと、ユーザーのウォレットアドレスの残高を記録するために設計されたものではありません。

外部アカウント

EOA は、Ethereum やその他の EVM 互換チェーン (または EVM のようなチェーン) に固有の概念です。厳密に言えば、BTC を含む主流の非 EVM チェーンにはこの設定はありません。 Metamask ウォレットは外部アカウントを使用します。このタイプのウォレットは「EOA ウォレット」とも呼ばれ、ユーザーの秘密鍵によって制御されます。生成ルールは次のとおりです。

秘密鍵 → 公開鍵 → Keccak256 ハッシュ → 最後の 20 バイト → 16 進文字列 (EOA アドレス)

この生成ルールは完全に数学的変換から導き出されたものであり、アドレスはどのスマート コントラクトにも対応していません。このタイプのアドレスをトランザクションに使用する場合のノード検証ルールは次のとおりです。

トランザクション署名 → ec_recover → 公開鍵 → (上記のルールを使用して生成) アドレス → 操作対象のアドレスと比較

検証が成功した場合、後続のプロセスが続行されます。失敗した場合、トランザクションは拒否されます。 Ethereum における EOA のコア設定は、トランザクションの開始者として機能し、ガスを支払うこと、つまりトランザクションのトリガーになることです。後で何回コントラクト呼び出しが行われても、トランザクションは最初に EOA によって開始され、実行される前に十分なガスが支払われる必要があります。 EOA アドレスのトランザクション フローを下図に示します。

簡素化されたEOA取引メカニズム 出典: Nethermind

外部アカウントの問題

現在、EOA アカウントは、ユーザーが使用する絶対的に主流のウォレット タイプです。 Ethereum コミュニティは、EOA に関して次のような懸念を表明しています。

  • キー管理: 資金を取得する唯一の方法は、秘密鍵を知ることです。最大の問題は単一障害点です。ユーザーにとって、秘密鍵は資産です。ユーザーにとって、秘密鍵を紛失したり盗難されたりすることは、資産の損失を意味します。

  • ECDSA 署名への依存: よりシンプルで量子耐性のある税金署名は、現在の ECDSA に比べて明らかに改善されています。

  • トランザクションは操作と 1 対 1 で行われます。一度に複数の操作を実行できないと、不必要なコストが発生し、ユーザー エクスペリエンスが低下します。

ブロックチェーンの応用シナリオが拡大し続けるにつれて、ユーザーはブロックチェーン上で自分のオンチェーン資産を管理するだけでなく、オンチェーン ID、ソーシャル関係、さらにはオンチェーン クレジットも管理するようになります。現在、これらのコンテンツのほとんどは、ウォレットを通じて疑似匿名の個人に単純にマッピングされています。ユーザーは、ニーモニックに基づく EOA ウォレットの秘密鍵管理ソリューションに苦労するだけでなく、EOA ウォレットの単純さのために、多くのアプリケーション シナリオでアプリケーションが制限されます。

これらの問題を解決しようとするウォレット ソリューションは数多くあります。

  • 単一障害点については、MPC ウォレットはしきい値署名スキーム (TSS) を使用してより優れた秘密鍵管理ソリューションを提供しますが、スマート コントラクト ウォレットはソーシャル リカバリ、マルチ署名、その他のソリューションを通じてこの問題を解決できます。

  • バッチトランザクションやカスタム検証ロジックなど、より優れたユーザーエクスペリエンス、より強力な機能とスケーラビリティは、主にスマート コントラクト ウォレットによってもたらされます。

MPC ウォレットとスマート コントラクト ウォレットは完全に独立したソリューションではありません。スマート コントラクト ウォレットでは、MPC + TSS テクノロジーを使用してスマート コントラクト ウォレットを管理することもできます。 Unipass は良い例です。

注: MPC ウォレットとは、マルチパーティの安全なコンピューティング テクノロジーを使用するウォレットを指します。これは、資産金庫に M 管理者を雇うのと同じです。各スチュワードは独立して金庫を開けることはできません。しきい値署名スキーム (TSS) を使用することは、開くために N 個のキーを必要とする金庫のロックを設定することと同じです。そうすると、MPC + TSS ウォレット ソリューションは、マルチロール ボールト管理ソリューションを提供することと同等になります。 M の管理者のうち N 人は、金庫を開けるために同時に管理している鍵を提供する必要があります。

契約アカウント

CA は内部ロジックを備えた Ethereum アカウントであり、ビジネス ロジック (トークン コントラクトは会計に使用され、質入れコントラクトは貸付と清算に使用されます) またはアカウント ロジック (gnosis safe のマルチ署名ロジックなど) を含めることができます。後者はスマート コントラクト ウォレット/アカウント (SCW) です。 Argent ウォレットは、ソーシャルリカバリーモデルの先駆者であるスマートコントラクトウォレットを使用します。契約は内部ロジック コードによって制御され、その生成ルールは CREATE と CREATE2 ですが、ここでは詳しく説明しません。

EOA とは異なり、CA と公開鍵の間には必要な対応関係はありません。たとえば、Gnostic Safe によって作成された CA に任意の数の公開鍵を設定して、そのアドレスに対応する資産のロックを解除することができます。もちろん、CA はキーを設定しないこともできますが、DeFi ローン契約など、他の CA のロジックでロック解除できるかどうかを決定し、お金が返済されれば担保資産を回収できます。

ETHを除くEthereum上のすべての資産はCAによって運ばれ、DeFiなどのビジネスロジックはすべてCAによって実装されています。しかし、CA が積極的に運営してガス代金を支払うことができないという事実も、その能力を制限しています。 2016年には、カリフォルニア州が自らガス代金を支払うことを許可するという提案がありました。

スマートコントラクトウォレット取引元: Nethermind

トランザクションは EOA からのみ開始できるため、ユーザー エクスペリエンスを向上させるために、スマート コントラクト ウォレットは通常、ユーザーから署名されたメッセージを取得し、サービス プロバイダーの EOA からチェーンに送信するリレー サービスを提供します。カスタム料金メカニズムにより、ETH をユーザーの EOA ウォレットに返却して、ガス料金の免除を実現できます。

現在、スマート コントラクト ウォレットを運用するための標準は存在しません (EIP-4337 が標準になることが期待されます)。そのため、各プロジェクトは、Ethereum Gas Station Network (GSN) などのメタトランザクション ソリューションを使用するか、独自のリレー サービスを作成して管理し、料金メカニズムを管理して複雑なスマート コントラクトを監査する必要があります。

スマートコントラクトウォレット

名前が示すように、スマート コントラクト ウォレット/アカウント (SCW) は、CA をアドレスとして使用するウォレット ソリューションです。内部ロジックの特性を持っています。スマート コントラクト ウォレットは、ガス支払い、バッチ トランザクション、マルチ署名、権限管理、オフライン認証、ソーシャル リカバリなど、EOA では実現できない多くの機能を実現できます。

コントラクト アカウントは、署名者 (承認者) とは別のスマート コントラクトであり、独自の署名および回復ロジックを持つことができます。つまり、Signer へのアクセスを失っても、必ずしもアカウントへのアクセスも失われるわけではありません。繰り返しますが、これが Account Abstraction という名前の由来です。アカウントは署名者から抽出されます。

アカウントの抽象化

イーサリアムの現状では、大多数の人が EOA ウォレットを使用しています。これは、現在イーサリアム内のすべてのトランザクションは EOA から開始する必要があり、EOA にはガス代を支払うための ETH がいくらか必要であるため、新しいユーザーがすぐに参加することが困難になっているためです。私たちには、アカウントアブストラクト (AA) と呼ばれる任意の検証ロジックを含むスマート コントラクト ウォレットをユーザーが使用できるようにするソリューションが必要です。簡単に言えば、アカウント抽象化の結果は次のようになります。

  • これまでは、資金を Ethereum EOA ウォレット アドレスに保管していましたが、これは、秘密鍵で資産を所有するシンプルさと利便性を享受しながらも、さまざまな EOA アドレス制限の対象となっていました。

  • これで、資金が Ethereum スマート コントラクト アドレスに保管されたので、秘密鍵を管理せずにウォレットの資産を制御できます。署名者とアカウント自体を分離することで、アカウント自体のセキュリティ レベルを高くしながら、トランザクションを低いセキュリティ レベルで実行できます。

「アカウント抽象化」の目標は、アカウントの種類の数を 2 (EOA と契約) から 1 (契約のみ) に減らし、署名検証、ガス支払い、リプレイ保護などの機能をコア プロトコルから EVM に移動することです。 EIP の歴史からわかるように、アカウントの抽象化を実現することは常に多くの Ethereum 開発者の焦点でした。

EIPの歴史

アカウント抽象化の概念は、2016年にVitalikによって初めて提案され、彼は2017年に最初の提案を開始しました。長年にわたり、アカウント抽象化に関連する多くの提案があり、最も重要なソリューションはEIP-3074とEIP-4337です。 EIP-3074 は EIP-4337 より 1 年前に提案されましたが、EIP-4337 は Ethereum のロードマップの新しいバージョンに含まれていました。主な理由は、EIP-4337 の実装が軽量であり、Ethereum のコア プロトコルを変更する必要がないことです。また、EIP-3074 のようなセキュリティ リスクもありません。ユーザーの移行問題、高ガス問題、および EIP-4337 の潜在的なスマート コントラクト セキュリティ問題は、スマート コントラクト ウォレットに共通する問題です。 Vitalik 氏は、アカウントの抽象化に対する最も現実的なアプローチは、短期的には ERC-4337 を強力にサポートし、その後徐々に EIP を追加してその弱点を補うことだと考えています。

アカウント抽象化EIP履歴

EIP-86: 2017 年に Vitalik は EIP-86 を提案し、「転送契約」と見なすことができるスマート コントラクト ウォレットの導入を試みました。これらの転送契約は、「エントリ ポイント」アドレスからのトランザクションのみを受け入れます。トランザクションが特定の形式に従っている限り、誰でもそのアドレスからトランザクションを送信できます。

EIP-1014: これらの転送契約は、コードに基づいて特定のアドレスに展開され、後に EIP-1014 に進化し、CREATE2 オペコードを提案するアイデアが導入されました。 EIP-86 はプロトコルに大幅な変更を必要としたため、最終的には統合されませんでしたが、EIP-1014 は 2018 年に統合されました。

EIP-2938: 2020 年 9 月、Vitalik Buterin、Ansgar Dietrichs、Matt Garnett は、スマート コントラクト ウォレットとして識別される特別なスマート コントラクトが、EIP-2718 で導入された新しいタイプのトランザクションであるアカウント抽象化トランザクションのみを受け入れることを要求する EIP-2938 を提案しました。トランザクションの最大ガスをプログラムで設定し、任意の検証方法を実装します。 EIP-2938 では、トランザクションを実行可能にするために、EVM に 2 つの新しいオペコードを追加する必要があります。これらのオペコードはコアプロトコルを大幅に変更するため、このような変更を組み込むプロセスは長くなる可能性があります。

EIP-3074: 2020 年 10 月、Ansgar Dietrichs、Matt Garnett らが EIP-3074 を提案し、AUTH と AUTHCALL という 2 つの新しいオペコードを導入しました。これらを一緒に使用すると、スマート コントラクトが EOA に代わってトランザクションを送信できるようになり、たとえば、マルチ署名、バッチおよびスポンサー トランザクション、キー回復、CeFi 取引所でのよりアクセスしやすい入金などが可能になります。しかし、この EIP にはセキュリティ上のリスクがあり、批判も受けています。新しいオペコードにより、コア プロトコルも変更されます。研究者たちはより良い解決策について考え始め、最終的に EIP-4337 として提案されました。

EIP-3074 トランザクションプロセスソース: Nethermind

レイヤー2: その後、L2 には Ethereum L1 のような技術的負債がないため、アカウントの抽象化をすぐに導入できます。 Optimism と Starknet はどちらも独自のアカウント抽象化実装を持っています。 ArgentX は、EIP-4337 にヒントを得たカスタム アカウント抽象化実装を使用した、Starknet 上の Argent のウォレット バージョンです。最近の例としては、StarkNet 上の Visa Crypto Auto Payments が挙げられます。これは、Visa の Ethereum 自動支払いソリューションで、アカウント抽象化の概念を活用して、新しいタイプのアカウント コントラクトである委任可能アカウントを作成します。その主なアイデアは、トランザクションのプログラム可能な有効性ルールを拡張して、事前承認済みの許可リストを含めることです。簡単に言えば、アカウント抽象化により、ユーザー アカウントによって開始された自動支払い操作を、事前に承認された自動支払いスマート コントラクトに委任できます。 StarkNet のアカウント モデルは、Visa が現在アカウント抽象化と呼んでいるもので、その実装は ERC-4337 にヒントを得ています。抽象アカウントは、トランザクションが特定のアドレスから送信されたかどうかを確認します。

VisaがStarkNetにアカウント抽象化を実装

EIP-4337: 2021 年 9 月、Vitalik Buterin 氏と OpenGSN および Nethermind の Ethereum 研究者は、以前の取り組みから得た教訓を活かして EIP-4337 を提案しました。 EIP-4337 は、現在のトランザクション メモリ プールを完全に置き換えてアカウントの抽象化を実現する新しい UserOperation メモリ プールを追加します。ユーザーは UserOperation オブジェクトを Ethereum ノードに送信し、トランザクションの代わりに、これらのオブジェクトのグループを Ethereum チェーンに含まれるトランザクションにパッケージ化します。このパッケージ化されたトランザクションは「エントリ ポイント」スマート コントラクトと呼ばれ、UserOperation オブジェクトを処理し、そのためのスマート コントラクト ウォレットをデプロイします。

ERC-4337トランザクションプロセスソース: Nethermind

EIP-5003: 2022 年 3 月、Dan Finlay と Sam Wilson は、外部アカウントの代わりにコードを展開することで ECDSA からの移行を可能にすることを期待して、EIP-5003 を提案しました。この EIP は、EIP-3074 認証アドレス AUTHUSURP にコードを展開する新しいオペコードを導入します。外部所有アカウント (EOA) の場合、EIP-3607 とともに、これにより元の署名キーの権限が事実上取り消されます。これは、追加の参加者権限を付与することしかできず、取り消すことができない EIP-3074 に追加されるものです。

EIP-5792: 2022 年 10 月、Moody Salem は、ユーザー ウォレットから複数の関数呼び出しを送信し、そのステータスを確認するための JSON-RPC メソッドを追加する EIP-5792 を提案しました。新しいアプローチは、既存のトランザクション送信 API よりも基礎となるトランザクションに関してより抽象的であり、EIP-4337 を使用するスマート コントラクト ウォレットや、EIP-3074 を介してバンドルされたトランザクションをサポートする EOA ウォレットなど、ウォレット実装間の違いを考慮できます。 Dapps は、このより抽象的なインターフェースを使用することで、追加のワークロードなしでさまざまな種類のウォレットをサポートし、関数呼び出しパケット (EIP-20#approveに続くコントラクト呼び出しなど) を送信するための優れたユーザー エクスペリエンスを提供できます。

EIP-4337 詳細説明

EIP-4337 には、EntryPoint コントラクト、Paymaster コントラクト、UserOperation、Bundler、Sender コントラクト、Aggregator の合計 6 つのコンポーネントがあります。

  • EntryPoint: エントリ ポイント コントラクトは、渡されたトランザクション操作の実行と検証を処理します。グローバル エントリ ポイント コントラクトは、さまざまなバンドラーからバンドルされたトランザクションを受け取り、各 UserOperations を通じて検証および実行ループを実行します。

  • Paymaster: これは、ユーザーに代わってトランザクションのガスを支払うことができるオプションの契約です。ユーザーはウォレットに頼る代わりに、出納係がスポンサーとなる取引手数料を獲得できます。

  • UserOperations: ユーザーに代わってトランザクションを実行するために作成されたトランザクション オブジェクトです。送信者契約が確認された後に実行されます。これらのアクションは Dapps によって生成されます。

  • バンドラー: バンドラーはメモリ プールから UserOperations を取得し、それらをまとめてパッケージ化して、実行のために EntryPoint コントラクトに送信します。

  • 送信者契約: スマート コントラクト形式のユーザー ウォレット アカウントです。

  • アグリゲータ: アグリゲータは、ウォレットが集約署名を検証するために信頼する補助契約です。

ERC-4337 標準全体の動作ロジックは、検証ループと実行ループの 2 つのループで構成され、これらが組み合わさってアカウント抽象化のロジックが完成します。

検証ループ: エントリ ポイント コントラクトは各 UserOperation を通過し、Sender コントラクトの「チェック関数」を呼び出します。 Sender Contract はこの関数を実行して、UserOperation の署名を確認し、これらのトランザクションをパッケージ化した Bunder を補償します。

ループを実行: 各 UserOperation の呼び出しデータを Sender Contract に送信します。ウォレットは実行操作を実行して、操作で指定されたトランザクションを実行します。送信者コントラクトは、操作が実行された後に残りのガスを返金します。

検証ループと実行ループ 出典: EIP-4337

テラーロールの導入により、アプリ開発者はユーザーに対して手数料を補助できるようになります。 paymaster がゼロ アドレスと等しくない場合、エントリ ポイントは別のフローを実行します。

出納係の検証ループと実行ループの紹介 出典: EIP-4337

検証ループでは、「チェック関数」を呼び出すことに加えて、エントリ ポイント コントラクトは、paymaster がステークされているかどうか、および操作の支払いに十分な ETH がエントリ ポイント コントラクトに預け入れられているかどうかも確認し、paymaster の「チェック関数」を呼び出して、paymaster が支払う意思があるかどうかを確認する必要があります。

実行ループでは、エントリポイント コントラクトは、メイン実行呼び出しの後に paymaster の Post-op を呼び出す必要があります。内部呼び出し環境でメイン実行を行うことで Post-op の実行を保証し、内部呼び出し環境がロールバックされた場合は、外部呼び出し環境で再度 Post-op の呼び出しを試みる必要があります (ユーザー操作がロールバックされた場合でも、ガス料金を支払う必要があります)。

Vitalik 氏は、ERC-4337 は完全に自発的な ERC として、多くのことを実現できると結論付けました。ただし、いくつかの重要な領域では、真のプロトコル準拠ソリューションよりも劣ります。

  1. 既存のユーザーがすべての資産とアクティビティを新しいアカウントに移動しないとアップグレードできないユーザー移行の問題。

  2. 追加のガス コスト (基本的なユーザー操作の場合は ~42k、基本的なトランザクションの場合は ~21k)。

  3. スマートコントラクトのセキュリティ問題。トランザクションをターゲットにしてユーザー操作を無視するプロトコル内検閲耐性技術（crListsなど）の恩恵が少ない。

最良の結果を達成するための現実的な方法は、短期的には ERC-4337 を強力にサポートすることから始め、その後、時間をかけて EIP を追加してその弱点に対処することです。これには、ERC-4337 に準拠するための具体的なコミットメントが必ずしも必要というわけではありません。代わりに、プロトコル内のサポートをより一般的なものに設計し、ERC-4337 とその代替および改良点をサポートすることができます。現在、ERC-4337 の実装には、Biconomy、Soul Wallet、eth-infinitism が含まれます。これらはすべて独自のエントリ ポイント コントラクト実装を記述しており、エントリ ポイント コントラクトはこの標準に基づくスマート コントラクト セキュリティの中核となります。

Vitalik 氏は、アカウント抽象化のための可能なロードマップを提案しました。

考えられるロードマップ

短期

  1. ERC-4337 を本格的に生産開始します。理想的には、これを署名集約機能で拡張して、ロールアップ対応にすることができます。

  2. ERC-4337 にアクセスできる、使いやすいブラウザ ウォレットが必要です。

  3. ERC-4337 をより L2 フレンドリーにするために、署名の集約と圧縮を実装することを検討してください。

  4. ガスコストがあまり問題にならないL2プロトコルでERC-4337エコシステムをブートストラップする。

中期

  1. ガスコストを削減するために Verkle ツリーを実装し、EIP を追加しました。

  2. オプションのEOAからERC-4337への変換を追加しました。

  3. Proposer/Builder Separation (PBS) の導入と同時または直後に crList ロジックを追加します。

長さ

遷移を強制し、不規則な状態遷移を実行し、EOA になる可能性のあるすべてのアカウントにバイトコードを展開することを検討してください。ただし、このアプローチには、コア プロトコルの変更が必要になり、マイナー/バリデーターにとってコストがかかるという欠点があります。

プロジェクトスキャン

SevenX は、市場にあるスマート コントラクト ウォレットを簡単にスキャンし、市場で最も主流のスマート コントラクト ウォレット プロジェクトをいくつか収集して分類しました。全体的な状況は次のとおりです。

事例紹介のために 2 つのプロジェクトを選択し、その機能と対応する実装原則を分析しました。その中で、Unipass は従来のスマート コントラクト ウォレットの代表的なものであり、Candide Wallet は ERC-4337 標準を使用するウォレットの代表的なものです。公開ドキュメントが豊富で、製品機能の実装について詳細な説明が提供されています。

導入事​​例 - Unipass

UniPass Wallet は、電子メールのソーシャル リカバリをサポートするスマート コントラクト ウォレット ソリューションです。 UniPass Wallet を使用すると、開発者は自社製品内でスムーズなキーフリー、ガスフリーのユーザー エクスペリエンスを提供できるため、すぐに多数の Web2 ユーザーを獲得できます。その特徴は、秘密鍵なし、検閲防止、ガスフリー、電子メール回復、プライバシー保護、マルチプラットフォームおよびマルチチェーンのサポートです。

秘密鍵不要、検閲防止、電子メール回復、プライバシー保護などの機能は、主に Unipass のキー管理ソリューションによって実現されます。 UniPass Wallet の契約アカウントでは、ユーザーが複数の種類のキーを設定することをサポートしています。サポートされているキーの種類は次のとおりです。

  1. 私たちがよく使用する外部アドレスは、EIP-1271 プロトコル (契約の標準的な署名検証方法) をサポートする契約アカウントです。

  2. UniPass ユーザーは、電子メール アドレスをキーとして使用することもできます。チェーン上に展開するスマート コントラクトは、DKIM (DomainKeys Identified Mail) を通じてユーザーのインターネット メールボックスの所有権を暗号的に検証できます。検証プロセス中、UniPass はゼロ知識証明テクノロジーを使用して、ユーザーの電子メール情報のプライバシーとセキュリティを確保します。

  3. 今後、UniPass Wallet では、secp256k1 よりも効率的で簡潔な署名アルゴリズム (Schnorr、BLS など) や、量子耐性セキュリティ署名アルゴリズム (Lamport、Winternitz など) などのサポートも検討する予定です。

秘密鍵には主に 3 つの役割があります。

  1. 所有者はアカウントの所有者です。所有者は、展開、アップグレード、破棄などのアカウントのコア機能を制御し、アカウントの最高権限の管理者となります。

  2. オペレーターはアカウント資産の実行者です。オペレーターは、アカウントの資産移転、契約の呼び出し、承認などの機能を担当し、ユーザーが日常生活で使用するキーです。

  3. 保護者はアカウントの管理者です。アカウント内のキーが破損または紛失し、ユーザーがアカウントの制御を失った場合、ガーディアンを通じてアカウントを復元できます。 UniPass が提供する主要な機能の 1 つは、オンチェーン電子メール ソーシャル リカバリです。

UniPass Wallet のスマート コントラクトでは、ユーザーはロールの重み付けがされた一連のキーを通じてアカウントを管理します。セキュアなマルチパーティ計算 (MPC) スキームで実装されたマスター キーに加えて、ユーザーは他のさまざまなタイプのキーを設定することもできます。各キーには対応する役割と重みがあります。ユーザーは、ロールの重みの合計しきい値が要件を超えるキーを収集した後にのみ、ロールの承認を取得できます。

キーは単一のロールまたは複数のロールに割り当てることができます。キーがロールに割り当てられると、対応する重みも同時に設定されます。ユーザーが特定の ID に関連する操作の実行を開始する場合、そのロールに対して合計重みが 100 以上の 1 つ以上のキーで署名する必要があります。たとえば、最初にアカウントを登録するときに、ユーザーは Guardian のセットアップをスキップできます。関連するパラメータは次のように設定できます。

ガスフリー機能はサードパーティのリレーを通じて実現されます。ユーザーがトランザクションを開始する場合、ユーザーがトランザクションを開始するのを支援するためにリレー機能が必要になります。このプロセス中、リレーヤーはユーザーが任意のトークンでガス代金を支払うことをサポートできるだけでなく、ユーザーがガス代金を支払うのを完全にサポートしてガスフリーの体験を実現することもできます。 Relayer はオープンソースのサーバー プログラムです。 UniPass はデフォルトのリレー機能を実行しますが、パートナーやサードパーティもリレー機能を実行できます。

実装事例 - Candide

CANDIDE は、開発を管理する単一の組織や企業がなく、オープンな貢献者グループによって構築されたパブリック製品です。 Candide Wallet Beta は、自己管理型のモバイル スマート コントラクト ウォレットです。現在、Goerli テストネットに展開されています。 Android Test および IOS Testflight で利用できるようになりました。

Candide Beta の技術的基盤は、Stackup フォークの ERC-4337 実装と Gnosis Safe のオープン ソース フレームワークです。その特徴としては、ニーモニックが不要、ソーシャルリカバリ、バッチトランザクション、ガス料金が不要などがあります。

このうち、ニーモニック不要、バッチトランザクション、ガス料金不要といった機能の実装ロジックはERC-4337と同一であり、eth-infinitismが開発したエントリポイントコントラクトを利用して完成されています。 Candide は独自のパッケージャーを実行し、UserOperation を独自のウォレット用のサービスにパッケージ化します。このソリューションでは、セキュリティの大部分はウォレット自体の構築ではなく、エントリポイント コントラクトに依存します。

さらに、ソーシャルリカバリ機能は、Candide が基本ウォレット コントラクトに Safe を使用していることから生まれます。これにより、Candide はデジタル トークンの管理に最も信頼できる DAO 契約を活用できるようになります。 Candide は、ソーシャルリカバリーなどのコア機能のほか、時間ロックや引き出し制限などの将来の機能を提供するために、Gnosis Safe のモジュール設計を使用します。ソーシャルリカバリモジュールは Unipass と同じロジックを持っていますが、Unipass は主に電子メールのリカバリですが、Candide の保護者は、家族の友人、機関、ハードウェアウォレットなど、パブリックアドレスを持つ任意の署名者になることができるという違いがあります。

コントラクトウォレットについての考察

初期のスマート コントラクト ウォレットは、Gnosis Safe のマルチ署名や Argent のソーシャル リカバリー機能など、非常に特殊な問題に基づいて開発されました。これらの初期の製品は設計が複雑で、オープンで透明性に欠けることが多く、統一された標準がなかったため、ミドルウェアとして他のアプリケーションに挿入することが困難でした。このタイプの製品の場合、判断基準は使用シナリオとユーザーのコアニーズを捉えているかどうかに基づく必要があります。たとえば、Safe のマルチ署名機能は、ユーザーの中心的なニーズの 1 つを捉えています。

ERC-4337の誕生により、ニーモニックやバッチトランザクション、ガス料金なしでウォレットを素早く構築することが非常に便利になりました。統一された標準により、この標準に基づいて構築された開発キットも構成可能になり、相互運用性を維持しながらミドルウェアとしてさまざまなアプリケーションに挿入できるようになります。

したがって、初期のスマートウォレットソリューションを検討する場合、ERC-4337 との互換性は非常に重要です。 ERC-4337 ベースのソリューションに関しては、テクノロジのほとんどがオープンソースであるため、次の考慮事項が推奨されます。

  1. テクノロジー: エントリーポイント コントラクト、パッケージャー、アグリゲータ (存在する場合) を構築する計画、およびソーシャル リカバリ機能など、ERC-4337 で提供される機能を超える機能を構築する計画。

  2. 運用: コミュニティを構築し、マーケティングしてユーザーを獲得する方法。

  3. エクスペリエンス: スムーズさや安定性など、ウォレットを使用する際のユーザー エクスペリエンスは十分ですか?

  4. そして、他のいくつかの C 製品の主な評価ロジック。

将来のウォレット モデルは、B2B2C モデルに似たものになる可能性が高くなります。ウォレットは C エンド製品として存在しますが、他のアプリケーションがアプリ内ウォレットに統合され、C エンドユーザーをターゲットにするための成熟した SDK ソリューションを提供することがより重要です。このうちパッケージャーやアグリゲータは初期段階では主に中央集権的に構築されており、後からモジュール型のネットワークを形成することも可能である。しかし、この部分は価値獲得の中核となるため、ウォレットは他者が構築したパッケージャー ネットワークを採用するために経済的利益のゲームを経る必要があります。

（上記コンテンツは、パートナーであるMarsBitの許可を得て抜粋・転載したものです。原文リンク｜出典：Foresight News）

声明：この記事は著者の個人的な見解と意見を述べたものであり、ブロックの客観的な論点や立場を表明するものではありません。すべてのコンテンツおよび意見は参考目的のみであり、投資アドバイスを構成するものではありません。投資家は自らの判断と取引を行う必要があります。著者およびブロック利用者は、投資家の取引によって生じた直接的または間接的な損失について一切の責任を負いません。

この記事「Ethereum ウォレットの変革: アカウント抽象化と ERC-4337 の機会と課題」は、Blockchain に初めて掲載されました。