この記事は SevenX 調査チームによるオリジナルであり、コミュニケーションと学習のみを目的としており、投資の参考となるものではありません。引用する必要がある場合は出典を明記してください。
元のリンク: https://mirror.xyz/sevenxventures.eth/3sYkMimEKqzQbme8-KszvSrKGj4uPxBLyJM9ncXxgcU
著者: Rui、@Ruisnakes
目次
暗号化のユーザー エクスペリエンスは悪いですか?キー管理が最悪です!
鍵管理: 責任、保管およびアクセス
既存製品の分析: MetaMask、Trust Wallet、Privy、Particle
新しいソリューション:
- 主要なレイヤー: WebAuthn、Secure Enclave (Secure Enclave)、および Passkey (Passkey)
- アカウント層: スマートコントラクトアカウント (SCA)、外部アカウント (EOA)
- 署名層: プロトコル r 1 プリコンパイル、サードパーティ サービス、Solidity およびゼロ知識バリデーター
ケーススタディ: (キー) + (アカウント)
- Clave ウォレット: (Secure EnclaveWebAuthn) + (SCA)
- ソウルウォレット：（パスキー）+（4337 SCA）
- OKX ウォレット: (MPC-TSS + パスキー) + (4337 SCA)
- Web3 Auth：（MPC-TSS + Passkey）+（EOA/SCA）
- Lit プロトコル: (MPC-TSS + 分散ノード + パスキー) + (EOA/SCA)
※上記の事例は急遽変更・改善される可能性がございますので予めご了承ください。
見通し
TL;DR
秘密キーはイーサリアムでトランザクションに署名するための鍵ですが、ニーモニック フレーズ (「シード フレーズ」とも呼ばれる) のような人間が判読できる形式で管理されている場合でも、ユーザーの秘密キーの管理は悪夢になる可能性があります。そして、ブロックチェーンを複雑なゲームに変えることは私たちの意図ではなかったことを私たちは知っています。
トランザクションのセキュリティを確保するには、許可されたユーザーを認証する必要があります。インターネットのセキュリティとユーザー エクスペリエンスが進化するにつれて、パスワード認証から顔認識や指紋などの生体認証へと進化してきました。 WebAuthn は、この進歩における重要なマイルストーンです。この記事では、次の 3 つの用語に焦点を当てます。
WebAuthn：これは、公開キーベースの資格情報を使用する Web 認証標準であり、通常は外部認証システムによって作成されます。パスワード不要で安全なユーザー認証も可能です。
Secure Enclave：機密データを保護するために設計されたコンピューティング デバイス内のハードウェア ベースのセキュリティ エンクレーブ。 iOS、Android、および Windows デバイスでは、さまざまなバージョンの Secure Enclave を利用できます。 WebAuthn を使用すると、外部認証システムとして機能し、ハードウェア レベルのセキュリティを実現できますが、秘密キーはローカルにバインドされているため、クロスデバイスの操作が困難になる可能性があります。
Passkey：WebAuthn はオペレーティング システム レベルで適用され、さまざまなデバイスおよびシステム プロバイダーが独自のカスタム ルールを持っています。例えば、Apple パスキーiCloud キーチェーンに保存されているキーを使用してデバイス間で同期します。ただし、この方法は通常、特定のプラットフォームまたはシステムにのみ適用され、システム間 (Apple-Android) に実装することはできません。
上で述べたように、WebAuthn の導入は、高度なフィッシング対策セキュリティとユーザー フレンドリーなエクスペリエンスを実現するという、日常のブロックチェーン ユーザーに対する私たちの目標と一致しています。以下は、WebAuthn 実装をブロックチェーンに統合するための提案です。
キーレイヤー:ユーザーは、顔認識や指紋などの滑らかな方法を使用して認証できます。内部では、キー管理を処理するハードウェア ベースのセキュリティ プロセッサ (Secure Enclave など) またはクラウド サービス (iCloud や Google Cloud など) です。クロスデバイスおよびクロスプラットフォームの問題については、後ほど詳しく説明します。
アカウントレベル:スマート コントラクト アカウント (SCA) は、任意の署名者 (SE やパスキーなど) としきい値メカニズムを割り当てることができます。さらに、モジュール設計により、柔軟性とアップグレード可能性が向上します。たとえば、スマート コントラクト アカウントは、トランザクション量、時間、IP アドレスなどの要素に基づいて署名要件を動的に調整できます。一方、従来の外部アカウント (EOA) は、マルチパーティ コンピューティング (MPC) サービスで拡張できます。この組み合わせにより、スマート コントラクト アカウントと比較して相互運用性とコスト効率が向上しますが、スマート コントラクト アカウントの利点はありません。提供される高度な機能、特にキーのローテーションは、より困難になる可能性があります。
署名レイヤー:Ethereum は k 1 曲線をネイティブにサポートしていますが、WebAuthn の署名検証では r 1 曲線を使用してキーを生成するため、より高いコストが発生します。したがって、zkSync などのレイヤー 2 ソリューションはネイティブを使用する予定です。EIP-7212 r 1 カーブのプリコンパイル。さらに、よりコスト効率の高い方法で r1 カーブ署名を促進できるサードパーティ サービス、Solidity バリデーター、ゼロ知識 (ZK) バリデーター、および分散キー管理システムがあります。
*免責事項:
技術の進歩は市場での成功を保証するものではありません。すべてのデバイスやプラットフォームが Passkey を採用しているわけではありません。スマート コントラクト アカウントの使用は外部アカウントよりも高価になる可能性があります。提案されるソリューションは技術の進歩とともに進化し続けます。
暗号化のユーザー エクスペリエンスは悪いですか?キー管理が最悪です!
ブロックチェーンの分野では、ブロックチェーン資産の実際の管理はユーザーやウォレットプロバイダーの手にあるのではなく、秘密鍵にあります。このキーは、イーサリアムでのトランザクション実行の成功または失敗を決定します。これをよりよく理解するために、外部アカウントを例に挙げてみましょう。
鍵生成: 秘密鍵として secp 256 k 1 楕円曲線から選択された乱数。次に、この秘密キーに曲線上の事前定義された点を乗算して、公開キーを生成します。イーサリアム アドレスは、公開キーのハッシュの最後の 20 バイトから派生します。通常、最終的に秘密キーと公開キーを生成するためのバックアップとして、ニーモニック フレーズを使用して秘密キーを人間が読める単語に変換します。
トランザクションに署名する: 秘密キーを使用して、ノンス (シリアル番号)、金額、ガス価格、受信アドレスなどの詳細を含むトランザクションに署名します。このプロセスには、楕円曲線デジタル署名アルゴリズム (ECDSA) が含まれます。これは、楕円曲線暗号化を使用し、secp 256 k 1 曲線を採用して (r, s, v) 値で構成される署名を生成し、その署名と元のトランザクションを結合します。ネットワークにブロードキャストされます。
トランザクションの検証: トランザクションが Ethereum ノードに到達すると、ノードのメモリプールで検証されます。署名者を検証するために、ノードは署名およびハッシュされたトランザクションを使用して送信者の公開キーを取得し、抽出されたアドレスを送信者のアドレスと照合することによってトランザクションの信頼性を確認します。
前述したように、秘密キーはチェーン上の重要なエンティティです。当初、イーサリアムアカウント、つまり外部アカウントは単一の秘密鍵に完全に依存していましたが、秘密鍵を失うとアカウントにアクセスできなくなるため、重大なリスクが生じていました。
多くの人は、アカウント抽象化 (AA) がユーザー エクスペリエンスの問題に対する究極の解決策であると考えているかもしれませんが、必ずしもそうではないと私は言います。アカウントの抽象化により、イーサリアム上の有効性ルールがプログラム可能なルールに変わり、スマート コントラクト アカウントによってそれらのルールを実装できるようになります。アカウントの抽象化は非常に強力です。複数のトランザクションを並行して送信できます (抽象ノンス)、ガススポンサーシップ、ガスの支払いに ERC 20 の使用をサポートします (抽象ガス)。この記事のトピックに関連した機能もあります -アカウントの抽象化により、固定署名の検証が壊れる可能性があります (抽象 ECDSA 署名)。外部アカウントとは異なり、スマート コントラクト アカウントには、マルチシグやスコープ付きキー (セッション キー) などの任意の署名者と署名メカニズムを割り当てることができます。ただし、アカウント抽象化の柔軟性と拡張性が向上したにもかかわらず、トランザクション署名には依然としてキーが必要です。
秘密キーが 12 単語のニーモニック フレーズに変換されたとしても、秘密キーの管理は依然として課題となる可能性があり、秘密キーを紛失したりフィッシング攻撃にさらされるリスクがあります。ユーザーは、複雑な分散ソリューションと集中サービスのどちらかを選択する必要がありますが、どちらも理想的ではありません。
暗号化エクスペリエンスがひどいのはなぜですか?この問題の多くは、鍵の管理が不十分であることが原因です。ユーザーはキーを管理する際に、エクスペリエンス、セキュリティ、分散化の間で常にトレードオフを行う必要があります。この記事では、キーを管理するための潜在的な最適なソリューションを検討します。
キー管理
すべてに適合する万能のソリューションは決してありません。鍵を保管する最適な方法は、特定のユーザー シナリオに合わせてカスタマイズする必要があり、ユーザーのタイプ (組織または個人)、資本額、頻度などの多くの要因の影響を受けます。トランザクション、インタラクションの種類など。
前もって明確にしておきますが、現在流行している「セルフホスト、セミマネージド、フルマネージド」という一般的な用語は使用しません。私の意見では、真の自己管理とは、たとえ一部のソリューションが従来の意味でホスティングとみなされず (分散ノードの信頼できる実行環境に保存されるなど)、非集中とみなされなかったとしても、他の当事者に依存せず、独立してトランザクションに署名することを意味します。拘置所。ホスティングの種類のみに基づいてソリューションの良し悪しを判断するのは単純すぎ、これらのソリューションの適合性の違いを考慮していません。鍵管理アプローチをより詳細に評価するには、3 つの異なる側面に沿って分析することをお勧めします。
責任
キー管理の責任をさまざまな責任者間で分担するかどうか。
個々のユーザーがキーを管理する際に直面することが多い課題のため、キー管理の責任を割り当てることは自然なリスク軽減戦略です。このような方法には、マルチシグ システムの場合のように、共同署名に複数のキーを使用することや、秘密共有スキーム (SSS) またはマルチパーティ計算 (MPC) を介して秘密キーを複数の部分に分割することが含まれます。
マルチ署名: トランザクション署名を生成するには、複数の完全な秘密キーが必要です。このアプローチでは、異なる署名者間のオンチェーン通信が必要となり、トランザクション手数料が高くなります。また、署名者の数がオンチェーンで表示されるため、プライバシーに影響します。
秘密共有スキーム (SSS): 単一の場所で秘密キーを生成し、このキーを複数の部分に分割してさまざまな当事者に配布します。各当事者は、トランザクションに署名するために完全な秘密キーを再構築する必要があります。ただし、このアドホックな再構築により脆弱性が生じる可能性があります。
MPC-TSS (しきい値署名スキーム): マルチパーティ計算の実装として、この暗号化方式を使用すると、複数のパーティが入力を共同でプライベートに保ちながら計算を実行できるようになります。各当事者は個別にキーシャードを作成し、物理的に会うことなくトランザクションに署名できます。オフチェーンで運用されるため、この方法のコストは低く、秘密共有スキームのような単一障害点のリスクはありません。
ストレージ
キーまたはキーのフラグメントの保存は、セキュリティ、アクセシビリティ、コスト、および分散化要因の影響を受けます。
AWS、iCloud、その他のサーバーなどの一元的なクラウド サービス。このアプローチは頻繁な取引を容易にしますが、監視の影響を受けやすくなります。
ローカル コンピュータ/モバイル デバイス: キーはブラウザの安全なストレージに保存されます。
ペーパーウォレット: 秘密キーまたは QR コードを印刷します。
信頼できる実行環境 (TEE): 信頼できる実行環境は、メイン プロセッサ内に、メイン オペレーティング システムとは独立して機密データを実行または保存する安全な領域を提供します。
Secure Enclave: 最新のデバイスの Secure Enclave はメイン プロセッサから分離されており、アプリケーション プロセッサ コアが侵害された場合でも機密性の高いユーザー データを安全に保つための追加のセキュリティ層を提供します。
ハードウェアウォレット: 例:LedgerそしてTrezorおよび秘密鍵を安全に保管するように設計されたその他の物理デバイス。
ハードウェア セキュリティ モジュール (HSM): ハードウェア セキュリティ モジュールは、安全なキー管理と暗号化操作に特に使用されるハードウェア デバイスであり、通常はエンタープライズ環境で使用され、高レベルのセキュリティ機能を提供します。
アクセス
保存されたキーにアクセスするユーザーを認証する方法
保存されたキーにアクセスするには認証が必要です。これには、アクセスを試みている個人が実際にキーへのアクセスを許可されていることを確認する必要があります。振り返ってみると、アクセス方法は次のように分類できます。
知っていること: パスワード、PIN、セキュリティの質問への答え、または特定のグラフィック。
所有するもの: スマート カード、ハードウェア トークン (時間ベースのワンタイム パスワード)、またはソーシャル アカウント検証や携帯電話に送信されるテキスト メッセージ コードなどのデジタル要素が含まれます。
あなたは誰ですか: 指紋、顔認識 (Apple の Face ID や Windows Hello など)、音声認識、虹彩/網膜スキャンなどのユーザー固有の身体的特徴。
これらの基盤に基づいて、2 要素認証 (2FA) と多要素認証 (MFA) は、テキスト メッセージとプッシュ通知など、少なくとも 2 つの要素を組み合わせて、ユーザー アカウントのセキュリティを強化します。
既存製品の分析
MetaMaskユーザーがパスワードを使用して、ローカル ブラウザ ストレージに保存されているキーにアクセスできるようにします。
Trust Walletユーザーは、クラウド サービスを使用して秘密キーをバックアップするオプションとともに、パスワードまたは faceID を使用してユーザーのローカル ブラウザ ストレージに保存されているキーにアクセスできるようになります。
Privyキーを 3 つの部分に分割する秘密共有スキームを使用して、ユーザーが電子メールなどの複数のソーシャル ログイン方法を使用できるようにします。
デバイスの断片化: ブラウザ - iFrame、モバイル - Secure Enclave。
Auth 認証シャード: Privy によって保存され、Privy ID にリンクされます。
リカバリ リカバリ フラグメント: ユーザー パスワード、または Privy によって暗号化されて保存されるハードウェア セキュリティ モジュール (HSM)真ん中。
ParticleMPC-TSS を使用してキーを 2 つの部分に分割し、ユーザーがソーシャル ログインを採用できるようにします。
デバイス シャーディング: ブラウザ - iFrame
サーバー キー セクション: Particle のサーバー
新しいソリューション
主要なレイヤー: WebAuthn、Secure Enclave、および Passkey
上記の既存のソリューションは、ユーザーを Web3 に引き付ける上で重要な役割を果たしています。ただし、それには課題も伴います。パスワードは忘れてしまったり、フィッシング攻撃の標的になったりする可能性があり、2FA は安全性が高くなりますが、複数の手順が必要なため依然として使いにくい場合があります。さらに、誰もが鍵管理をサードパーティに委託することを望んでいるわけではなく、一部のサービスによってユーザーが鍵にアクセスできない場合でも、ユーザーは依然としてシステムの可用性と有効性に依存する必要があります。
このため、私たちは、トラストレスに近い状態、高いセキュリティ、シームレスなユーザー エクスペリエンスを提供する、より効果的なソリューションはないかと考えました。このソリューションを追求することで、最適な Web2 アプローチを見つけることができます。この記事の冒頭で述べたように、このトピックに密接に関連する用語がいくつかあります。WebAuthn は認証標準であり、Secure Enclave と Passkey は標準に関連する展開またはコンポーネントです。
WebAuthn
WebAuthn は、Web ベースのアプリケーションのユーザー認証用のインターフェイスを指定します。ユーザーは、パスワードの代わりに外部認証システムを使用してインターネット アカウントにログインできます。認証システムには、ローミング認証システム (Yubikey、Titan キーなど) やプラットフォーム認証システム (Apple デバイスの組み込みキーチェーンなど) などを使用できます。
WebAuthn の背後にあるテクノロジーは、もともと FIDO (Fast IDentity Online) アライアンスによって開発されました。 2019 年 3 月に W3C が WebAuthn を Web 標準として正式に発表し、その標準化の進展に伴い、Google Chrome、Mozilla Firefox、Microsoft Edge、Apple Safari などの主要なブラウザが WebAuthn を採用し、WebAuthn の適用範囲と可用性が大幅に拡大しました。現在利用可能です多くの高度なデバイスのサポート。
WebAuthn の利点:
セキュリティの向上:パスワードに依存する必要がなくなり、フィッシング、ブルート フォース、リプレイ攻撃のリスクが軽減されます。
ユーザーエクスペリエンスの向上:多くの場合、ワンクリックまたは生体認証による認証で、よりシンプルかつ高速なログインが可能になります。
プライバシー保護：認証プロセス中に共有秘密が送信されることはなく、個々の Web サイトが個人を特定できる情報を受信することもありません。
スケーラビリティと標準化:Web 標準として、WebAuthn は、さまざまなブラウザーやプラットフォーム間での一貫性と相互運用性を保証します。
Secure Enclave などのデバイスベースの WebAuthn
現在、Apple デバイス用の Secure Enclave、Android デバイス用の Trustzone、Google Pixel 用の Strongbox など、ハードウェア プロセッサを認証システムとして使用できます。
キーの生成: 使用公開鍵暗号化、通常は P-256 r 1 曲線を使用して、WebAuthn 標準に従ってキー ペアを生成します。公開キーはサーバーに送信されますが、秘密キーが Secure Enclave から出ることはありません。ユーザーは平文キーを決して扱わないため、秘密キーのセキュリティが確保されます。
キーの保管: 秘密キーはデバイスに安全に保管されます。Secure Enclave内部的には、この強化されたサブシステムはメイン プロセッサから分離されています。機密データを保護するため、メイン システムが侵害された場合でも、元のキー マテリアルにアクセスできなくなります。 Secure Enclave をクラックする障壁は非常に高いため、Apple Pay や FaceID データなどの最も機密性の高いデータ タイプがここに保存されます。ここでは、Secure Enclave仕組みについての詳細な説明。
認証: ユーザーは顔認識または指紋を使用してアクセスを取得し、Secure Enclave は秘密キーを使用してサーバー側のチャレンジに署名し、サーバーは検証に公開キーを使用します。
デバイスベースの WebAuthn の利点:
ハードウェアのようなセキュリティ:Secure Enclave は、スタンドアロンのハードウェアベースのキー マネージャーであり、セキュリティを強化します。
フィッシング攻撃と戦う:侵害された可能性のあるデバイスや Web サイトには情報を入力しないでください。
便利な体験:よりユーザーフレンドリーなエクスペリエンスを提供します。ユーザーは、Web サイトごとに複雑なパスワードを覚える必要がなくなりました。
デバイスベースの WebAuthn の欠点:
デバイスの制限: デバイスを紛失または破損した場合、秘密キーをエクスポートまたは取得することはできず、デバイスをまたがる操作はできません。
クラウドベースの WebAuthn、パスキー
クロスデバイス機能の課題を解決するために、テクノロジー大手はクラウドベースの WebAuthn 導入を導入し、Passkey は Apple によって有名になりました。
Apple のパスキーを例に挙げます。
キーの生成: ユーザーの macOS、iOS、または iPadOS デバイスは認証システムとして機能し、ユーザーがアカウントを作成するときに公開キーと秘密キーを生成します。公開キーはサーバーに送信され、秘密キーはデバイスの iCloud キーチェーンに保存されます。 iCloud キーチェーン データは、ハードウェアにバインドされたキー ペアで暗号化され、ハードウェア セキュリティ モジュールに保存されます。 Apple はキーペアにアクセスできません。
デバイス間で同期: このプロセスは iCloud にアクセスするのと同じです。 iCloud アカウントを認証し、SMS 認証コードを受信し、いずれかのデバイスのパスワードを入力します。
クラウドベースの WebAuthn の利点:
デバイス間で:Passkey は、ユーザーが使いやすく、定期的に使用するすべてのデバイスからアクセスできるように設計されています。ただし、現時点では Apple デバイスに限定されています。 Android デバイスでは、Android のバージョンとハードウェアが多種多様であるため、このアプローチはより困難です。
フィッシング攻撃を防止します。同上。
便利な体験:同上。
クラウドベースのパスキーの欠点:
クラウド サービスに依存する場合:デバイスベースの WebAuthn と比較して、クラウドベースの Passkey はセキュリティ層を Secure Enclave のハードウェアから iCloud キーチェーンに移動します。iCloud キーチェーンはクラウド サービスでホストされていると考える人もいるかもしれません。考慮すべき重要な点には、ユーザーの iCloud AppleID アカウントが侵害されていないかどうかが含まれます。iCloud キーチェーンはエンドツーエンドの暗号化を使用してデータを保護しますが、操作上のエラーや脆弱性がリスクをもたらします。
プラットフォームの制限:たとえば、Android デバイスで iCloud ベースのパスワードを使用するのは非常に困難です。さらに、従来のアプローチとは異なり、Apple と Google はデバイス固有のアサーションを送信しません。これは、現時点ではキーを生成したデバイスの種類を検証する方法がなく、キーとそれに関連するメタデータの信頼性について疑問が生じていることを意味します。
アカウント層: スマート コントラクト アカウントと外部アカウント
これまでのところ、クロスデバイスおよびクロスプラットフォームの互換性に対処しながらハードウェアの安全性を維持することが大きな課題であることがわかります。セキュリティを強化するために複数の保護者を追加するなど、社会的回復のオプションも同様に重要です。この場合、ブロックチェーンが解決策を示してくれます。
注: Web2 の WebAuthn を Web3 に導入しようとする場合、明らかな違いの 1 つは、Web2 は所有権を証明する必要があるだけであるのに対し、Web3 はトランザクションの承認も必要であることです。パスキーのみを所有している場合、開発者は署名付きメッセージ (通常は「サインイン」などの一般的なもの) を制御できません。これにより、ユーザーがメッセージに「盲目的に」署名するという、フロントエンド操作の問題が発生する可能性があります。これは、一見些細なことのように見えますが、重大な問題です。
スマート コントラクト アカウント自体はスマート コントラクトであり、チェーン上のエンティティとして任意の署名者を指定できます。この柔軟性により、ユーザーは署名者として Android 携帯電話、Macbook、iPhone などのさまざまなデバイスやプラットフォームの設定を構成できます。さらに、モジュール式スマート コントラクト アカウントはアップグレードをサポートし、新しい署名者を交換でき、署名のしきい値を 2/3 からより複雑な構成に変更できます。
状況に応じてセキュリティのニーズを柔軟に調整できるウォレットを想像してください: このウォレットは、ユーザーが使い慣れたローカル IP アドレスを使用している場合には単一署名者の認証をサポートしますが、未知の IP アドレスまたは特定の値以上からのトランザクションには複数の署名者の認証を必要とします。による。モジュール性とプログラマビリティでは、私たちが想像できない、実現できないイノベーションしかありません。多くのスマート コントラクト アカウント サービス プロバイダーがこの分野で積極的に構築を行っています。Zerodev、Biconomy、Etherspots、ラインストーンら。などの方々にも感謝したいと思いますStackup、Plimico、Alchemy のようなインフラストラクチャがこれを可能にします。
私をチェックしてください以前の研究、スマート コントラクト アカウントに関するより包括的な背景情報を取得します。
スマート コントラクト アカウントは、マルチパーティ コンピューティング サービスを通じて、ソーシャル リカバリとクロスデバイス/プラットフォームの互換性を可能にします。スマート コントラクト アカウントの署名者は固定ですが、マルチパーティの計算プロバイダーはセキュリティと柔軟性を強化するためにキーを複数の部分に分割できます。このアプローチには、タイムロックの回復やキーの簡単な非アクティブ化など、スマート コントラクト アカウントのプログラム可能およびアップグレード可能な機能はありません。ただし、MPC は特定のブロックチェーンに制限されないため、優れたクロスチェーン機能を備え、スマート コントラクト アカウントよりもコスト効率が高くなります。有名なマルチパーティ コンピューティング プロバイダーには、Particle Network、Privy、web3 Auth、OKX Wallet、Binance Wallet待って。
署名層: R1 サポート
理解するために一歩下がってみましょう。イーサリアムでは、秘密鍵は k 1 曲線から選択された乱数であり、署名プロセスでもこの曲線が利用されます。
ただし、WebAuthn 標準に従って生成されたキー ペアは、r 1 曲線を使用します。したがって、イーサリアム上で r 1 署名を検証するコストは、k 1 署名の検証コストの約 3 倍になります。この問題の解決策は次のとおりです。
Dogan の貢献に感謝し、より深い知識については彼の研究をチェックしてください。
プロトコルソリューション:
解決：EIP 7212 、によって提供される、secp 256 r 1 曲線のサポートでプリコンパイルされています。Claveチーム提案。
評価: この提案は、メッセージ ハッシュ、署名の r と s、および公開鍵の x、y 座標パラメータを指定して、「secp 256 r 1」楕円曲線で署名検証を実行するプリコンパイルされたコントラクトを作成します。したがって、任意の EVM チェーン (主にイーサリアムのロールアップ) は、このプリコンパイルされたコントラクトを簡単に統合できます。プロトコルのプリコンパイルは、おそらくこれまでのところ最もガス効率の高いソリューションです。
応用：zkSync
サードパーティのサービス:
ソリューション: ターンキー
評価: ターンキー TEE は、ユーザーがパスキーを介してのみ秘密キーにアクセスできることを保証し、ターンキーが秘密キーにアクセスすることはありませんが、サービスが有効であるためにはこれが必要です。
実装: ゴールドフィンチ
Solidity Verifier ソリューション:
ソリューション: FCL の Solidity Verifier、FCL with Precomputed Solidity Verifier、Daimo の P 256 Verifier
成し遂げる：Clave，Obvious Wallet
ゼロ知識 (ZK) バリデータ:
評価: このアプローチでは、ゼロ知識証明を使用してイーサリアム仮想マシン (EVM) の外部で計算を検証し、オンチェーン コンピューティングのコストを削減します。
成し遂げる：Bonfire Wallet (Risc Zero)，Know Nothing Labs (Axiom)
これらのソリューションはすべて、イーサリアム エコシステムにおけるより安価で実現可能な r 1 署名検証を可能にします。Doganの評価。
WebAuthn の新しいケーススタディ
*2023 年 12 月の時点で、これらのソリューションのほとんどは初期段階にあり、いつでも変更または改善される可能性があることに注意してください。これらの例は学習のみを目的としており、正確な情報については常に公式 Web サイトを参照してください。
Clave ウォレット: (Secure Enclave WebAuthn) + (スマート コントラクト アカウント)
基本情報：
デモ: https://getclave.io/
アカウント: スマートコントラクトアカウント
チェーン: ZkSync
取引プロセス:
キーの作成: ユーザーは指紋や顔認識などの生体認証を受け、決して侵害されることのないキー ペアが Secure Enclave 内で生成されます。
キー署名: アプリケーションは必要なトランザクション メッセージを受信し、署名リクエストを Secure Enclave に転送します。ユーザーは生体認証検証を実行して署名を承認します。Secure Enclave はキーを使用してメッセージに署名し、それをブロックチェーン ノードにブロードキャストします。
追加機能: スマート コントラクト アカウントは、多くの強力な機能をサポートします。 1つ目はガススポンサーです。 Paymaster を使用すると、dApps または広告主はユーザーのガス料金を支払うことができるため、トランザクション プロセスがよりスムーズになり、ユーザーはイーサリアムまたはネイティブ トークンだけでなく ERC 20 トークンを使用してガス料金を支払うこともできます。さらに、ユーザーはセッション キーを使用して、一定期間にわたって署名なしのトランザクションを実行できます。
回復メカニズム:
回復プロセスは、zkSync 上の Clave のスマート コントラクトによって実行され、ユーザーは 48 時間のロック期間内に回復をキャンセルして、不正な悪意のあるアクティビティを防ぐことができます。
クラウド バックアップ: ユーザーがクラウド バックアップを選択すると、外部アカウントが作成されます。外部アカウントの秘密キーは iCloud または Google Drive に保存されます。ユーザーはクラウドに保存された秘密キーを使用して、さまざまなデバイスから自分のアカウントにアクセスできます。 、いつでも削除または削除することができます。このバックアップ セクションを上書きします。
ソーシャルリカバリ: ユーザーは家族や友人の Clave アドレスをバックアップとして指定でき、N 人中 M 人の保護者がリカバリを確認しキャンセルしなかった場合、48 時間のロック期間後に実行が再開されます。
ソウルウォレット: (パスキー) + (4337 SCA)
基本情報：
デモ: https://alpha.soulwallet.io/wallet
アカウント: ERC 4337 スマート コントラクト アカウント
チェーン: イーサリアム、オプティミズム、アービトラムは間もなくイーサリアム仮想マシン レイヤ 2 を完全にサポートします
取引プロセス:
キーの作成: ユーザーが指紋や顔認識などの生体認証を行うと、オペレーティング システムがパスキーを生成し、クラウド サービスを使用してバックアップされます。ユーザーは、デバイスやプラットフォーム全体に複数のパスキーを追加できます。
ガーディアンの追加 (オプション): ユーザーは、異なる Ethereum 仮想マシンの外部アカウント アドレスをガーディアンとして指定し、アカウント回復のしきい値を設定できます。
アカウントの生成: 反事実的な展開により、ユーザーは最初の取引を行うまで何も支払う必要がありません。
回復メカニズム:
パスキー: 定義されたパスキーを使用して、任意のデバイスでウォレットにログインします。
ガーディアンの回復: 指定されたガーディアンは、しきい値に基づいてウォレットをローテーションし、後でタイムロックを設定して悪意のある動作を防ぐことができます。
OKX ウォレット: (MPC-TSS + パスキー) + (4337 スマート コントラクト外部アカウント)
基本情報：
デモ: https://www.okx.com/help/what-is-an-aa-smart-contract-wallet
チェーン: 30+チェーン
キー：MPC-TSS、2/3
アカウント: 4337 スマートコントラクトアカウント
取引プロセス:
キーの作成: ウォレットを作成することにより、OKX は 1 つの秘密キーを 3 つの別々の部分に分割します。 1 つの部分は OKX サーバーに保存され、1 つの部分はユーザーのデバイスのローカル ストレージに保存され、もう 1 つの部分はデバイスによって生成されて暗号化され、Google Cloud、iCloud、デバイスの優先クラウド サービスにバックアップできます。そしてファーウェイクラウド。
キー署名: OKX は MPC-TSS テクノロジーを使用します。これにより、ユーザーはトランザクションに署名するときに 3 つの秘密キー部分のうち 2 つを使用して完全な署名を取得できます。その間、秘密キーのフラグメントは互いに接触しません。
回復メカニズム:
2/3 メカニズム: ユーザーがログアウトした場合、デバイスが使用不可になった場合、またはデバイス上のキーの 1 つが漏洩した場合、ユーザーは新しいデバイスを使用して OKX ウォレットにログインできます (サーバーに保存されているキーを取得します)。クラウド サービスによって保存されているキー部分を取得し、これら 2 つの部分キーを使用してウォレットを復元すると、OKX ウォレットが新しいキー部分を生成します。
Web3 認証: (MPC-TSS + パスキー) + (外部アカウント/スマート コントラクト アカウント)
基本情報：
デモ: https://w3a.link/passkeysDemo
チェーン: すべての EVM および Solana
キー: MPC-TSS、通常 2/3
アカウント: 外部アカウント、4337 スマート コントラクト アカウント、または一般的なスマート コントラクト アカウントなどの任意のアカウント
取引プロセス:
キーの作成: ウォレットを作成すると、3 つのキー部分が生成されます。 1 つのセクションはソーシャル ログイン用で、ユーザーは電子メールを入力でき、分散ネットワーク ノードが各ユーザーのキーを保存します。1 つのセクションはユーザーのデバイスのローカル ストレージに保存されたキー用で、もう 1 つのセクションはローカル コンピューターによって提供されます。ユーザーの好みのクラウド サービスによってアップされます。
キー署名: Web3 認証 MPC-TSS アーキテクチャにより、ユーザーのキーが常に利用可能になり、しきい値署名を使用してもキーが再構築されたり、単一の場所に保存されたりすることはありません。
回復メカニズム:
しきい値の回復: ユーザーがログアウトした場合、デバイスが使用できなくなった場合、またはデバイス上のキーが漏洩した場合、ユーザーはソーシャル ログイン方法を使用して WebAuthn アカウントにログインし、クラウド ストレージのキー部分を取得し、使用することができます。これら 2 つの部分のキーを使用してウォレットを復元します。
Lit プロトコル (MPC-TSS + 分散ノード + パスキー) + (外部アカウント/スマート コントラクト アカウント)
基本情報：
デモ: https://lit-pkp-auth-demo.vercel.app/
チェーン: ほとんどの EVM、Cosmos、Solana。
アカウント: MPC-TSS、2/3 メカニズムは、スマート コントラクト アカウントと外部アカウントの両方に適用できます。
取引プロセス:
キーの作成: ユーザーがウォレットを作成する場合、最初に認証方法 (パスキー、oAuth ソーシャル ログインをサポート) を選択し、次にキー ペアを作成するリクエストをリレーラーに送信し、認証ロジックをスマート コントラクトに保存します。各キー ペアは、分散キー生成 (DKG) プロセスを通じて Lit ノードによって共同で生成されます。分散型ネットワークとして、TEE は内部で 30 個の Lit ノードを実行し、各ノードがキーの一部を保持しますが、秘密キーが TEE に完全に存在することはありません。
キー署名: リクエストを受信した後、Lit ノードは指定された認証方法に基づいてリクエストを個別に検証または拒否し、MPC-TSS テクノロジーを使用します。 1. コレクションがしきい値を超えた場合に署名を生成します (30 ノード中 20 件の確認)。ご要望に応じてクライアントが作成したものです。
回復メカニズム:
2/3 メカニズム: スマート コントラクトに保存されている認証方法を使用してアカウントにアクセスし、Lit ノードがリクエストを検証し、ノードの 2/3 以上が確認した場合、リクエストは続行されます。
見通し
レイヤ 2、レイヤ 3、およびデータ可用性 (DA) ソリューションを活用して、ブロックチェーンのパフォーマンスの向上に努めています。同時に、ゼロ知識証明プライバシーと透明性を組み合わせて、真のセキュリティを追求します。すべての取り組みは、ユーザーの日常生活ですぐに使用できる暗号化という同じ目標に向けられています。
理想的なテクノロジーの夢に囚われてしまいがちですが、私たちは自問しなければなりません。「私たちはどのような経験を追い求めているのか?」私たちは、暗号通貨が威圧的な専門用語ではなく直感的で理解しやすい世界、ユーザーがためらうことなく汗をかかずにウサギの穴に飛び降りることができる世界を思い描いています。
Rui という名前のユーザーがいると想像してください。彼女は、顔認識や指紋を使用して簡単に登録し、バックアップや保護者を設定できる素晴らしい dApp を発見しました。彼女は dApp を使用して簡単にトランザクションを実行できます。おそらく少額の ERC 20 手数料がかかるか、場合によっては手数料がまったくかからない場合もあります。その後、自動トランザクションのタイムロックの有効化、バックアップ署名者としての別のデバイスの追加、保護者のリストの変更など、ウォレットの設定をカスタマイズできます。
起業家たちはこれを実現するために懸命に取り組んでいます。 WebAuthn と Passkey を組み合わせることで、秘密キーの管理が強化され、安全かつ便利になりました。これに基づいて、エンティティとしてのスマート コントラクト アカウントは、パーソナライズされたセキュリティと機能の分野を開きます。ガスは？ Paymaster を使用すると、プロバイダーはスワップ取引用の「保管庫」を作成でき、広告主がユーザーに料金を支払うこともできるため、ガスの負担がなくなります。この進化、特にイーサリアム メインネットとそのレイヤー 2 相当物にとって中心となるのは、ERC 4337 です。 ERC 4337 では、プロトコルに大きな変更を加えることなく、スマート コントラクト アカウントのトランザクションを外部アカウントから分離する代替メモリプールが導入されています。一方、一部のレイヤー 2 ネットワークでは、スマート コントラクト アカウントをネイティブに採用し、それらをシステムにシームレスに統合しています。
すべてをシンプルにするには多大な努力が必要です。また、スマートコントラクトアカウントの展開、検証、実行コストの削減、アカウントの相互運用性を高めるためのインターフェースの標準化、チェーン間でのアカウントステータスの同期など、多くの課題にも直面しています。ビルダーの皆様のおかげで、私たちは日々成功に近づいています。私たちの会社 SevenX は、他の仮想通貨スタートアップ企業とともに、偉大な企業に力を与え、ビジョンの実現を支援する準備ができています。
この記事に興味がある場合は、より包括的な背景情報については、私の他の記事を参照してください。
04/アカウント:モジュール式スマートコントラクトアカウントのアーキテクチャと課題
03/ キー (この記事): WebAuthn と Passkey、日常暗号化ユーザーのためのキー管理
02/インフラストラクチャ:ERC 4337がもたらしたイーサリアムアカウントの進化
