原作者：Yuxing、SevenX Ventures
この記事は学習とコミュニケーションのみを目的としており、投資の参考となるものではありません。
イーサリアム アプリケーション シナリオの継続的な拡張と拡張により、従来のイーサリアム ウォレットの外部所有アカウント (EOA) ソリューションの欠点が徐々に明らかになり、その機能はシンプルでパフォーマンスは平均的であり、同時トランザクションはサポートされておらず、重要な点がいくつかあります。経営上の問題、問題。スマート コントラクト ウォレットは、ウォレット アドレスとしてコントラクト アカウント (CA) を使用し、EOA ウォレットの欠点を解決し、より強力な機能を提供できる比較的新しいイーサリアム ウォレット ソリューションです。将来的には、秘密鍵を慎重に保護しないことを選択して、ほぼ同じレベルのセキュリティを享受できるようになり、現在の集中型取引所の利便性を分散型取引所でも享受できるようになりますが、同時に資金は常に取引所で雷雨が起こる可能性を心配する必要はありません...
少し前にリリースされたイーサリアムロードマップの新バージョンでは、アカウント抽象化スマートコントラクト仕様ERC-4337が、EOAウォレットがスマートコントラクトウォレットに切り替えるための重要な要素としてThe Splurgeに書き込まれました。では、スマートコントラクトウォレットとは一体何なのか、アカウントの抽象化とスマートコントラクトウォレットの関係は何なのか、どのように実装されているのか、今後の開発形態はどうなっているのか、そしてチャンスと課題は何なのか？
イーサリアムアカウントの種類
イーサリアムには、外部所有アカウント (EOA) と契約アカウント (CA) の 2 種類のアカウントがあります。外部アカウントは、ユーザー残高を記録するイーサリアムのネイティブ ウォレット アカウント アドレスです。契約アカウントは当初、ユーザーのウォレット アドレス残高を記録するように設計されていませんでした。
外部アカウント
EOA はイーサリアムなどの EVM 互換チェーン (または EVM 類似チェーン) に特有の概念であり、BTC を含む主流の非 EVM チェーンには厳密にはこの設定はありません。メタマスク ウォレットは外部アカウントを使用します。このタイプのウォレットは「EOA ウォレット」とも呼ばれ、ユーザーの秘密鍵によって制御されます。その生成ルールは次のとおりです。
秘密鍵 → 公開鍵 → Keccak 256 ハッシュ → 最後の 20 バイト → 16 進文字列 (EOA アドレス)
この生成ルールは完全に数学的変換から導出されており、このアドレスはどのスマート コントラクトにも対応しません。このタイプのアドレスをトランザクションに使用する場合、ノード検証ルールは次のとおりです。
トランザクション署名 → ec_recover → 公開鍵 → (上記ルールで生成) アドレス → 操作対象のアドレスを比較
検証に合格した場合は、以降のプロセスを続行します。そうでない場合、トランザクションは拒否されます。イーサリアムにおける EOA の中心的な設定は、トランザクションのイニシエーターとして機能し、ガスを支払うこと、つまりトランザクションのトリガーです。トランザクションに続くコントラクト呼び出しの数に関係なく、最初と最後に EOA によって開始される必要があります。十分なガソリンを支払う必要があります。 EOA アドレスのトランザクション プロセスを次の図に示します。
簡素化された EOA 取引メカニズム 出典: Nethermind
外部アカウントの問題
現在、EOA アカウントはユーザーが使用する最も主流のウォレット タイプです。イーサリアム コミュニティは、EOA に関して次のような多くの懸念を表明しています。
• 鍵管理: 資金を入手する唯一の方法は秘密鍵を知ることです。最大の問題は単一障害点です。ユーザーにとって秘密鍵は資産です。ユーザーにとって、秘密キーが紛失または盗難されると、それは資産の損失を意味します。
• ECDSA 署名への依存: よりシンプルで量子耐性のあるデジタル署名は、現在の ECDSA に比べて明らかに改善されています。
• トランザクションは操作と 1 対 1 で行われます。複数の操作を同時に実行できないと、不必要なコストが発生し、ユーザー エクスペリエンスが低下します。
ブロックチェーンのアプリケーションシナリオが継続的に拡大するにつれ、ユーザーはブロックチェーン上の自分のオンチェーン資産だけでなく、オンチェーンのアイデンティティ、社会的関係、さらにはオンチェーンのクレジットなども管理するようになりました。現時点では、これらのコンテンツのほとんどはウォレットを介して擬似匿名の個人にマッピングされているだけであり、ユーザーはニーモニックベースの EOA ウォレット秘密鍵管理ソリューションに苦労しているだけでなく、EOA ウォレットのシンプルさにより多くのアプリケーションに使用されています。シーンが限られてしまいます。
これらの問題を解決しようとするウォレット ソリューションは数多くあります。
• 単一障害点に関しては、MPC ウォレットはしきい値署名スキーム (TSS) を使用することで、より優れた秘密鍵管理ソリューションを提供しますが、スマート コントラクト ウォレットは、ソーシャル リカバリ、マルチ署名、その他のソリューションを通じてこの問題を解決できます。
• より優れたユーザーエクスペリエンス、バッチトランザクション、カスタム検証ロジックなどのより強力な機能とスケーラビリティは、主にスマートコントラクトウォレットによってもたらされます。
MPC ウォレットとスマート コントラクト ウォレットは完全に独立したソリューションではありません。スマート コントラクト ウォレットは、MPC+TSS テクノロジーを使用してスマート コントラクト ウォレットを管理することもできます。Unipass がその良い例です。
注: MPC ウォレットとは、マルチパーティのセキュア コンピューティング テクノロジーを使用するウォレットを指します。これは、資産保管庫に M 人のスチュワードを雇うことと同じです。各スチュワードは独立して保管庫を開くことができず、しきい値署名スキーム (TSS) を使用することは、保管庫には、開くのに N 個のキーが必要なロックが設定されています。この場合、MPC + TSS ウォレット ソリューションは、複数の役割の保管庫管理ソリューションを提供することと同じです。M 人のスチュワードのうち N 人のスチュワードが、管理するキーを同時に提供する必要があります。金庫を開ける能力。
契約口座
CA は内部ロジックを備えた Ethereum アカウントであり、ビジネス ロジック (トークン契約は会計に使用され、質権契約は融資と清算に使用されます) またはアカウント ロジック (gnosis セーフのマルチシグネチャ ロジックなど) のいずれかになります。それはスマート コントラクト ウォレット/アカウント (SCW) です。 Argent ウォレットは、ソーシャル リカバリ モデルの先駆けであるスマート コントラクト ウォレットを使用しており、コントラクトは内部ロジック コードによって制御され、その生成ルールには CREATE と CREATE 2 が含まれますが、ここでは説明しません。
EOA とは異なり、CA と公開鍵の間には必要な対応関係はありません。たとえば、gnosis セーフによって作成された CA は、そのアドレスに対応する資産のロックを解除するために任意の数の公開鍵を設定できます。もちろん、CA は鍵を設定できないこともありますが、ロックを解除できるかどうかは他の CA のロジックによって決まります。 DeFiなどの融資契約では、お金を返済すれば担保に入れている資産を取り戻すことができます。
ETH を除くイーサリアム上のすべての資産は CA によって運ばれ、DeFi などのビジネス ロジックはすべて CA によって実装されます。ただし、CA が積極的に運営してガスを支払うことができないという設定により、その機能も制限されます。提案うまくいけば、CA がガソリン代を自分で支払えるようになります。
スマートコントラクトウォレットのトランザクションソース: Nethermind
トランザクションは EOA からのみ開始できるため、ユーザーエクスペリエンスを向上させるために、スマートコントラクトウォレットは通常、ユーザーから署名されたメッセージを取得し、サービスプロバイダーからチェーンに EOA を送信するためのリレーサービスを提供します。 EOAウォレットはガス代無料を実現します。
現在、スマート コントラクト ウォレットの運用標準は存在しません (EIP-4337 が標準になる予定です)。そのため、すべてのプロジェクトはイーサリアム ガソリン ステーション ネットワーク (GSN) のようなメタトランザクション ソリューションを使用するか、ウォレットの作成と管理に取り組む必要があります。独自のリレーサービスのほか、料金メカニズムを管理し、複雑なスマートコントラクトを監査します。
スマートコントラクトウォレット
スマートコントラクトウォレット/アカウント(SCW)は、その名のとおり、CAをアドレスとするウォレットソリューションであり、内部ロジックが特徴で、ガス決済やバッチトランザクションなど、EOAでは実現できない多くの機能を実装できます。 、複数の署名、権利管理、オフライン認証、ソーシャルリカバリなど。
契約アカウントは署名者 (承認者) とは別のスマート コントラクトであり、独自の署名および回復ロジックを持つことができます。これは、署名者へのアクセスを失っても、必ずしもアカウントへのアクセスを失うわけではないことを意味します。繰り返しになりますが、これがアカウント抽象化という名前の由来です。アカウントは署名者から抽象化されます。
アカウントの抽象化
イーサリアムの現状は、大多数の人が EOA ウォレットを使用しているということです。現在、イーサリアムでのすべてのトランザクションは EOA で開始する必要があり、EOA はガス代を支払うためにある程度の ETH を持っている必要があるため、新規ユーザーがすぐに参入することは不可能です。ユーザーが任意の検証ロジックを含むスマート コントラクト ウォレットを使用できるようにするソリューションが必要であり、このソリューションはアカウント アブストラクト (AA) と呼ばれます。
簡単に言うと、アカウント抽象化の結果は次のようになります。
以前は、イーサリアム EOA ウォレット アドレスにお金を保存していましたが、さまざまな EOA アドレスによる制限を受けながらも、秘密キーを使用して資産を所有するシンプルさと利便性も享受していました。
イーサリアム スマート コントラクト アドレスにお金を保存することで、秘密キーを管理せずにウォレット資産を管理できるようになりました。署名者とアカウント自体を分離することで、より低いセキュリティ レベルでトランザクション操作を実行できるようになります。アカウント自体は次の場所に配置されます。より高いセキュリティレベル。
「アカウントの抽象化」の目標は、アカウントの種類の数を 2 (EOA および契約) から 1 (契約のみ) に減らし、署名検証、ガス支払い、リプレイ攻撃保護などの機能をコア プロトコルからプロトコルに移動することです。 EVM 。 EIP の歴史から分かるように、アカウント抽象化の実装は常に多くのイーサリアム開発者の努力でした。
EIPの歴史
アカウント抽象化の概念は、2016 年に Vitalik によって初めて提案され、2017 年に最初の提案を開始しました。長年にわたり、アカウントの抽象化に関連する多くの提案が行われてきましたが、その中で最も重要なものは EIP-3074 と EIP-4337 です。 EIP-3074 は EIP-4337 より 1 年前に提案されましたが、EIP-4337 はイーサリアムのロードマップの新バージョンに含まれています。主な理由は、EIP-4337 の実装はより軽量である必要があり、変更する必要がないためです。イーサリアムの中核プロトコルであり、EIP-3074 のようなセキュリティ リスクはありません。ユーザー移行の問題、過剰なガスの問題、EIP-4337 の潜在的なスマート コントラクトのセキュリティ問題は、スマート コントラクト ウォレットの一般的な問題です。Vitalik 氏は、抽象化を考慮するための最良の現実的な方法は、短期的に ERC-4337 の精力的なサポートを開始することであると考えています。そして、時間の経過とともに、その弱点を補うために EIP が追加されました。
アカウントの抽象的な EIP 履歴
EIP-86: 2017 年、Vitalik は、「転送コントラクト」とみなせるスマート コントラクト ウォレットを導入する試みとして EIP-86 を提案しました。これらの転送契約は、特定の形式に従っている限り、誰でもトランザクションを送信できる「エントリ ポイント」アドレスからのトランザクションのみを受け入れます。
EIP-1014: これらの転送コントラクトは、コードに基づいて特定のアドレスに展開され、後に CREATE 2 オペコードを提案する EIP-1014 に発展するアイデアが導入されました。 EIP-86 はプロトコルに大幅な変更を必要としたため、最終的にはマージされませんでしたが、EIP-1014 は 2018 年にマージされました。
EIP-2938: 2020 年 9 月に、Vitalik Buterin、Ansgar Dietrichs、Matt Garnett が EIP-2938 を提案し、スマート コントラクト ウォレットとして識別される特別なスマート コントラクトがアカウント抽象トランザクションのみを受け入れることを要求します。この新しいタイプのトランザクションは EIP- 2718導入。彼らは、トランザクションの最大ガスをプログラムで設定し、任意の検証方法を実装します。 EIP-2938 トランザクションを実行可能にするには、2 つの新しいオペコードを EVM に追加する必要があります。これらのオペコードはコア プロトコルを大幅に変更するため、そのような変更を組み込むプロセスは長くなる可能性があります。
EIP-3074: 2020 年 10 月に、Ansgar Dietrichs 氏、Matt Garnett 氏らが EIP-3074 を提案し、AUTH と AUTHCALL という 2 つの新しいオペコードを導入しました。一緒に使用すると、スマート コントラクトが EOA に代わってトランザクションを送信できるようになり、たとえば、マルチ署名、バッチ化されたスポンサー付きトランザクション、キーの回復、CeFi 取引所でのよりアクセスしやすいデポジットが可能になります。しかし、この EIP にはセキュリティ上のリスクがあり、いくつかの批判を受けました。新しいオペレーション コードではコア プロトコルも変更されるため、研究者はより良い解決策を検討し始め、最終的に EIP-4337 として提案されました。
EIP-3074 トランザクション プロセスのソース: Nethermind
レイヤ 2: その後、L2 にはイーサリアム L1 の技術的負債がないため、すぐにアカウント抽象化を導入できます。Optimism と Starknet の両方に独自のアカウント抽象化実装があります。ArgentX は Starknet 上の Argent のウォレット バージョンであり、影響を受けるバージョンを使用していますby EIP-4337 インスピレーションを得たカスタム アカウント抽象化の実装。最新の例は、StarkNet の Visa Crypto Auto Payments です。Visa の Ethereum 自動支払いソリューションは、アカウント抽象化の概念を活用し、新しいタイプのアカウント契約、つまり委任アカウントを作成します。主なアイデアは、トランザクションのプログラム可能な有効性ルールを拡張して、事前のトランザクションを含む-承認された許可リスト。簡単に言うと、アカウント抽象化により、ユーザー アカウントによって開始された自動支払い操作を、事前承認された自動支払いスマート コントラクトに委任できます。 StarkNet のアカウント モデルは、現在 Visa がアカウント抽象化と呼んでいるもので、その実装は ERC-4337 に触発されており、抽象アカウントはトランザクションが指定されたアドレスからのものであるかどうかをチェックします。
Visa、StarkNet にアカウント抽象化を実装
EIP-4337: 2021 年 9 月、OpenGSN および Nethermind の Vitalik Buterin 氏と 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 月に、ムーディー セイラムは、ユーザー ウォレットから複数の関数呼び出しを送信し、そのステータスを確認するための JSON-RPC メソッドを追加する EIP-5792 を提案しました。新しいアプローチは、基礎となるトランザクションの点で、既存のトランザクション送信 API よりも抽象的であり、EIP-4337 を使用するスマート コントラクト ウォレットや、EIP-3074 を介してバンドルされたトランザクションをサポートする EOA ウォレットなど、ウォレット実装間の差異を考慮します。 Dapps は、このより抽象的なインターフェイスを使用して、追加の作業なしでさまざまなタイプのウォレットをサポートし、関数呼び出しパッケージ (例: EIP-20 #approve とそれに続くコントラクト呼び出し) を送信するためのより良いユーザー エクスペリエンスを提供できます。
EIP-4337の詳細説明
EIP-4337 には、EntryPoint コントラクト、Paymaster コントラクト、UserOperation、Bundler、Sender Contract、および Aggregator (アグリゲーター) の合計 6 つのコンポーネントがあります。
EntryPoint: エントリ ポイント コントラクトは、渡されたトランザクション操作の実行と検証を処理します。グローバル エントリ ポイント コントラクトは、さまざまなバンドラーからパッケージ化されたトランザクションを受け取り、各 UserOperations を通じて検証および実行ループを実行します。
Paymaster: これは、ユーザーに代わってトランザクションのガソリンを支払うことができるオプションの契約です。ユーザーは自分の財布に頼る代わりに、窓口担当者から後援される取引手数料を受け取ります。
UserOperations: これらは、ユーザーに代わってトランザクションを実行するために作成されたトランザクション オブジェクトです。送信者契約の確認後に実行されます。これらの操作は Dapp によって生成されます。
バンドラー: バンドラーは、メモリー プールから UserOperations を取得し、それらをパッケージ化して、実行のために EntryPoint コントラクトに送信します。
送信者契約: これらは、スマート コントラクトの形式のユーザー ウォレット アカウントです。
アグリゲーター: アグリゲーターは、ウォレットによって信頼される補助コントラクトであり、集約署名を検証するために使用されます。
ERC-4337 標準動作ロジック全体には、検証ループと実行ループという 2 つのループが含まれており、これらを組み合わせてアカウント抽象化ロジックを完成させます。
検証ループ:エントリ ポイント コントラクトは、各 UserOperation を通過し、送信者コントラクトの「チェック関数」を呼び出します。 Sender Contract は、UserOperation の署名を確認し、これらのトランザクションをパッケージ化した Bunder を補償するためにこの関数を実行します。
実行ループ:各 UserOperation の通話データを送信者コントラクトに送信します。ウォレットは実行オペレーションを実行して、オペレーションで指定されたトランザクションを実行します。送信者コントラクトは、操作の実行後に残りのガスを返します。
検証ループと実行ループ ソース: EIP-4337
導入されたキャッシャーの役割により、アプリケーション開発者はユーザーの料金を補助できるようになります。ペイマスターがゼロ アドレスと等しくない場合、エントリ ポイントは別のプロセスを実行します。
窓口担当者の検証ループと実行ループの導入 出典: EIP-4337
検証ループでは、「チェック関数」を呼び出すことに加えて、エントリーポイントコントラクトは、ペイマスターがステークされているかどうか、および操作手数料をカバーするのに十分なETHがエントリーポイントコントラクトにデポジットされているかどうかもチェックし、その後「チェック関数」を呼び出す必要があります。支払主に「機能」を使用して、支払主が支払う意思があるかどうかを確認します。
実行ループでは、エントリ ポイント コントラクトは、メイン実行呼び出しの後にペイマスターのポストオペレーションを呼び出す必要があります。内部呼び出し環境でメイン実行を行うことでポストオペレーションの実行を保証する必要があり、内部呼び出し環境がロールバックした場合は、外部呼び出し環境で再度ポストオペレーションの呼び出しを試みます (たとえガスが支払われる必要があります)ユーザー操作によりコストがロールバックされます)。
Vitalik 氏は、ERC-4337 は純粋に自主的な ERC として多くのことができると結論付けました。ただし、いくつかの重要な領域では、真のプロトコル内ソリューションよりも弱いです。
ユーザー移行の問題。既存のユーザーは、すべてのアセットとアクティビティを新しいアカウントに移動しないとアップグレードできません。
追加のガス オーバーヘッド (基本的な UserOperation ユーザー操作は約 42 K、基本トランザクションは約 21 K)。
スマート コントラクトのセキュリティ問題。トランザクションをターゲットにしてユーザー操作を無視する、プロトコル内の検閲耐性技術 (crList など) による恩恵が少ない
最良の結果を達成するための現実的な方法は、ERC-4337 の強力なサポートを短期的に開始し、その後、時間をかけて EIP を追加してその弱点を補うことです。これには、ERC-4337 に準拠するための特別な取り組みが必ずしも必要ではありません。代わりに、プロトコル内サポートはより一般的で、ERC-4337 とその代替案および改良点をサポートするように設計できます。現在の ERC-4337 実装ソリューションには Biconomy、Soul Wallet、eth-infinitim が含まれており、これらはすべて独自のエントリ ポイント コントラクト実装ソリューションを作成しており、エントリ ポイント コントラクトはこの標準におけるスマート コントラクト セキュリティの中核となります。
Vitalik氏はアカウント抽象化の可能性を提案した路線図 。
短期
ERC-4337 を本格的に稼働させます。理想的には、署名集約機能を使用してこれを拡張し、ロールアップの利便性を実現できます。
ERC-4337と連携する使いやすいブラウザウォレットが必要です。
ERC-4337 を L2 フレンドリーにするために、署名の集約と圧縮の実装を検討してください。
ガスコストの問題が少なくなる L2 プロトコルで ERC-4337 エコシステムをガイドします。
中期
Verkle ツリーを実装し、EIP を追加してガスコストを削減します。
オプションの EOA から ERC-4337 への変換を追加します。
crList ロジックを、提案者/構築者の分離 (PBS) ロールアウトと同時に、またはその直後に追加します。
長さ
キャスト、不規則な状態遷移の実行、EOA となる可能性のあるすべてのアカウントへのバイトコードのデプロイを検討してください。ただし、このアプローチの欠点は、コア プロトコルを変更する必要があることと、マイナー/バリデーターのコストが高いことです。
プロジェクトスキャン
SevenX Ventures は、市場のスマート コントラクト ウォレットの簡単なスキャンを実施し、市場で主流のスマート コントラクト ウォレット プロジェクトのいくつかを収集しました。
導入事例
事例紹介として 2 つのプロジェクトを選択し、その機能と対応する実装原理を分析しました。中でも従来のスマートコントラクトウォレットの代表格としてUnipass、ERC-4337規格を採用したウォレットの代表格としてCandide Walletがあり、製品の機能実装について詳しく説明した豊富な公開ドキュメントを持っています。
Unipass
UniPass Wallet は、電子メールのソーシャル リカバリをサポートするスマート コントラクト ウォレット ソリューションです。 UniPass Wallet を通じて、開発者は製品内で秘密キーやガスを使用しないスムーズなユーザー エクスペリエンスを提供できるため、すぐに多数の Web2 ユーザーを引き付けることができます。その特徴は、秘密キーフリー、検閲耐性、ガスフリー、電子メール回復、プライバシー保護、マルチプラットフォームおよびマルチチェーンのサポートです。
秘密キー不要、検閲耐性、電子メール回復、プライバシー保護といった機能は、主に Unipass のキー管理ソリューションによってもたらされます。 UniPass Wallet の契約アカウントは、ユーザーが複数の種類のキーを設定できるようにします。すでにサポートされているキー タイプには次のものがあります。
私たちがよく使用する外部アドレスは、EIP-1271 プロトコル (契約の標準署名検証方法) をサポートする契約アカウントです。
UniPass ユーザーは、自分の電子メール アドレスをキーとして使用することもできます。チェーン上に展開するスマート コントラクトは、DKIM (Domain Name Key Identified Mail) を通じてインターネット メールボックスのユーザーの所有権を暗号的に検証できます。
UniPass は検証プロセス中にゼロ知識証明技術を使用して、ユーザーの電子メール情報のプライバシーとセキュリティを確保します。
将来的には、UniPass Wallet は、secp 256 k 1 (Schnorr、BLS など) よりも効率的でシンプルな署名アルゴリズム、ポスト量子安全署名アルゴリズム (Lamport、Winternitz など) などのサポートも検討する予定です。
秘密キーには 3 つの主な役割があります。
所有者はアカウントの所有者です。所有者は、アカウントの展開、アップグレード、破棄、およびその他のコア機能を制御し、アカウントの最高権限の管理者です。
オペレーターはアカウント資産の執行者です。オペレーターは、アカウントの資産移管、契約の発動、認可などの機能を担当し、ユーザーが毎日使用するキーです。
Guardian はアカウントの保護者です。アカウントのキーが破損または紛失し、ユーザーがアカウントの制御を失った場合、ガーディアンを使用してアカウントを復元できます。 UniPass が提供する主な機能は、オンチェーン電子メールのソーシャル リカバリです。
UniPass Wallet のスマート コントラクトでは、ユーザーは役割の重みを備えた一連のキーを通じてアカウントを管理します。安全なマルチパーティ計算 (MPC) スキームで実装されたマスター キーに加えて、ユーザーは他の多くの種類のキーを設定することもできます。各キーには対応する役割と重みがあります。ユーザーは、ロールの重みの合計しきい値が要件を超えるキーを収集した後にのみ、このロールの承認を取得できます。
キーには 1 つまたは複数の役割を割り当てることができます。キーに役割を割り当てると、対応する重みも同時に設定されます。ユーザーが特定の ID に関連する操作の実行を開始したい場合、役割の合計の重みが 100 以上に達する 1 つまたは複数のキーで署名する必要があります。たとえば、最初にアカウントを登録するときに、ユーザーは保護者の設定をスキップできます。関連するパラメータは次のように設定できます。
ガスフリー機能はサードパーティのリレーラーを通じて実装されており、ユーザーがトランザクションを開始する場合、ユーザーがトランザクションを開始するのを支援するためにリレーラーが必要です。このプロセスでは、リレーラーはユーザーがガスの支払いに任意のトークンを使用できるようにサポートすることができ、ユーザーが代わりにガスを支払うのを完全に支援して、ガスのないエクスペリエンスを実現することもできます。 Relayer はオープン ソースのサーバー プログラムで、UniPass がデフォルトの Relayer を実行しますが、パートナーやサードパーティも Relayer を実行できます。
Candide
CANDIDE は、開発を管理する単一の組織や企業が存在せず、貢献者のグループによって共同かつオープンに構築された公開製品です。 Candide Wallet Beta は、セルフホスト型のモバイル スマート コントラクト ウォレットです。現在、Goerli テストネットにデプロイされています。 Android Test と IOS Testflight で利用できるようになりました。
Candide Beta の技術的基盤は、Stackup フォークの ERC-4337 実装と Gnosis Safe のオープンソース フレームワークであり、その機能には、言葉のない言葉、ソーシャル リカバリ、バッチ トランザクション、ガス料金の無料などが含まれます。
このうち、ノーノートワード、バッチトランザクション、ガス手数料無料などの機能の実装ロジックはERC-4337と同様で、eth-infinitimが開発したエントリーポイントコントラクトを利用して完成します。 Candide は独自のパッケージャーを実行し、UserOperation を独自のウォレットのサービスとしてパッケージ化します。このソリューションでは、セキュリティのほとんどはウォレット自体の構築ではなく、エントリ ポイントのコントラクトにあります。
さらに、ソーシャル リカバリ機能は、Candide が基本ウォレット契約に Safe を使用していることから生まれています。これにより、Candide は最も信頼できる DAO コントラクトを活用してデジタル トークンを管理できるようになります。 Candide は、Gnosis Safe モジュラー設計を使用して、ソーシャル リカバリなどのコア機能に加え、タイム ロックや引き出し制限などの将来の機能も提供します。このソーシャル リカバリ モジュールは Unipass と同じロジックを持っていますが、Unipass が主に電子メールのリカバリを目的としている点が異なりますが、Candide の保護者は家族の友人、機関、ハードウェア ウォレットなど、パブリック アドレスを持つ任意の署名者になれる点が異なります。
コントラクトウォレットについての考え
初期のスマート コントラクト ウォレットは、Gnosis Safe のマルチシグネチャや Argent のソーシャル リカバリ機能など、非常に特殊な問題に基づいて開発されました。これらの初期の製品は設計が複雑で、オープンでも透明でもないことが多く、統一された標準を形成していないため、ミドルウェアとして他のアプリケーションに挿入することが困難でした。この種の製品では、より利用シーンやユーザーのコアニーズを捉えているかどうかを判断基準とする必要があり、例えばSafeのマルチシグネチャ機能はユーザーのコアニーズの1つを捉えています。
ERC-4337 の誕生により、文字なし、バッチトランザクション、ガス手数料なしでウォレットを素早く構築することが非常に便利になりました。統一規格により、この規格に基づいて構築された開発キットもコンポーザブルになり、中間的な役割を果たすことができます。ソフトウェアはさまざまなアプリケーションにプラグインされ、相互運用性を維持します。
したがって、初期のスマート ウォレット ソリューションを検討する場合、ERC-4337 と互換性があることが非常に重要です。 ERC-4337 に基づくソリューションの場合、ほとんどのテクノロジーがオープンソースであるため、次の点に焦点を当てて検討することをお勧めします。
テクノロジー: エントリー ポイント コントラクト、パッカー、アグリゲーター (存在する場合) を構築する方法、およびソーシャル リカバリ機能など、ERC-4337 がもたらす機能を超える機能を構築する方法
運用: コミュニティを構築し、市場に参入し、ユーザーを獲得する方法
エクスペリエンス: スムーズさ、安定性など、ウォレットを使用するユーザー エクスペリエンスが十分であるかどうか。
その他の C 製品の主要な検査ロジック
将来のウォレット モデルは B2B2C モデルに似たものになる可能性が高くなります。ウォレットは C エンド製品として存在しますが、他のアプリケーションをアプリ内ウォレットに統合して C エンド ユーザーを対象とする成熟した SDK ソリューションを提供することがより重要です。このうちパッカーとアグリゲーターは初期は主に集中的に構築され、後からモジュール型のネットワークを形成することも可能ですが、この部分は価値獲得の中核となるため、他社が構築したパッカーネットワークを利用したウォレットは移行する必要があります。経済的利益を得るゲームを通じて。
