みんなが口にするのは、アカウント抽象化（AA）とそのブロックチェーン空間でユーザーエクスペリエンスを革新する可能性です。 しかし、AAに関する主な誤解は、ガス料金を抽象化したり、バッチトランザクションを可能にしたりするだけでなく、どのようにプログラマブルなキーマネジメントシステムを通じて、それ以上のことを成し遂げるという点です。

これらのシステムは、日常のデバイスにハードウェアレベルのセキュリティを提供し、Web2の認証方法をWeb3の環境に統合することができ、従来の12語のシードフレーズを超えることができます。今日は、開発者が利用できるさまざまなキー管理システムと、それらが最も役立つ具体的なユースケースについて説明します。

12語を超えて移動する

私たちの産業はブームワードを愛し、そして「seedless」は最近注目を集めています。ユーザーにプライベートキーを安全に保存することを期待することは現実的ではなく、何百万ドルもの損失につながっていますが、問題は残っています：ユーザーにシードフレーズを表示しない場合、キーをどこに保存するのですか？

アカウント抽象化（AA）がない場合、ほとんどの既存のソリューションはマルチパーティ計算（MPC）に依存してキーを複数の部分に分散させ、取引のためのしきい値を作成します。これらのソリューションはしばしば自己保管を主張していますが、これは完全に正確ではありません。たとえば、バイナンスはキーの1つのシェアを保管し、ユーザーがデバイスを失った場合の保管人として機能します。このセットアップにより、主張にもかかわらず、ユーザーは自分のキーを真に制御していないだけでなく、キーの回復には依然として中央集権的なエンティティへの依存があります。

さらに、キーシェアが漏洩した場合、メインアカウントからキーを取り消す方法はありません。キーの取り消しは不可能です。なぜなら、Externally Owned Accounts（EOAs）ではキーのローテーションをサポートしていないため、漏洩したキーは常にアカウントの一部となります。これは重大なセキュリティリスクを示しており、侵害されたキーは置換または削除することができないため、アカウントは無期限に脆弱な状態になります。

AAがプログラマブルアカウントやキーローテーションの道を開く方法について詳しく知りたい場合は、私の記事をチェックしてください.

1. 完全にプログラム可能なアカウント：アカウント抽象化

Account Abstractionを使用すると、開発者は異なるキーマネジメントシステムを構築することができます。アカウントは複数のキーと異なる認証方法で制御することができ、すべてのキーはキーのローテーションをサポートしています。さらに、キーの権限を区別することができます。これは、ユーザーが同じアカウントに対して異なるキーを使用し、それぞれのキーを異なるユースケースに合わせることができることを意味します。後ほど、これらのユースケースについて詳しく説明します。

AAでは、資金はスマートコントラクトに保存され、アカウントの所有権はこれらのスマートコントラクトによって定義されます。EIP-4337に対応したアカウントは、取引に2つの部分を持っています。

1. 最初の部分は、アカウント所有権がチェーン上で確認される検証です。
2. 第二部は実行です。メッセージを実行します。

2つのパートは完全にプログラム可能です。例えば、2つのキー（i、ii）を定義することができ、最初のキー（i）は即時トランザクションを実行でき、2番目のキー（ii）はタイムロック後にのみトランザクションを実行できます。これにより、キーの権限やタイムロックの追加、または他の条件を設定してトランザクションを実行できます。

従来のアカウント（EOA）について話すとき、認証は認可と同等です。AAでは、認可がプログラム可能であり、開発者は役割ベースのアクセス制御スキームを定義し、最小特権原則を強制できます。

暗号空間には、役割ベースのアクセス制御スキームを可能にする多くの認証方式（すなわち、キー管理システム）があり、1つのキーだけではキー管理に関連するすべての問題を解決することはできません。キー管理システムの最も重要な側面は、キーの保存場所と認証者です。

さまざまなキー管理システムの長所と短所

まず、パスキー（Consumer Secure Enclaves）、MPC ベースのソリューション、クラウドベースの TEE ソリューション、カストディアルソリューション、従来の12単語やセッションキーの要点を簡単にまとめます。その後、最適な組み合わせについて説明します。

1. 伝統的な12語 - (secp256k1) -

BitcoinとEthereumはサポートしていますsecp256k1ユーザーのデバイス上に秘密鍵を作成し、保存するために楕円曲線暗号（ECC）アルゴリズムを使用します。この方法はEOAで広く使用され、適用することもできます。スマートアカウント。 それを使用するには、ウォレットアプリケーションがランダムなキー生成アルゴリズムを使用してプライベートキーを生成し、その後、プライベートキーを共有ストレージに保存します。

secp256k1を使用すると、さまざまな利点があります：追加のガスコストがかからず、安価であり、ecrecoverの事前準備を介してオンチェーンで簡単に検証できます。また、ユーザーだけがキーにアクセスできるため、自己保管型でもあります。

ただし、いくつかの欠点があります:

1. デバイスを紛失した場合に、ユーザーがキーを安全に保存する方法を教育することは困難です。
2. トロイの木馬やマルウェアは、ユーザーのデバイスからプライベートキーを盗む可能性があります。なぜなら、それは共有ストレージに保存されているからです。

NISTはsecp256k1曲線をサポートしていません。つまり、一般的なフレームワークやほとんどのハードウェアで一般的にサポートされていません。

2. パスキー（コンシューマーセキュアエンクレーブ）

ほとんどすべての現代のデバイスには、2つの主要なコンポーネントがあります：オペレーティングシステム（関連する共有ストレージを備えたもの）とセキュアエンクレーブです。オペレーティングシステムは、生体認証データ、暗号キー、暗号化、およびデバイスのロック解除などの機密タスクを除いて、ほとんどの操作を処理します。

開発者たちは、Secure Enclaveという専用のマイクロチップを作成し、これらの機密操作を別々に管理します。Secure Enclaveは、ハードウェアウォレットに似た方法で機能し、独立して動作し、機密データを安全に処理し、デバイスの所有者でもその内容にアクセスできません。幸いなことに、Secure Enclaveはプライベートキーの作成やそれらでメッセージに署名するなどの暗号化操作をサポートしています。ただし、Secure EnclaveはEthereumがサポートする曲線（secp256k1）をサポートしておらず、代わりにp256曲線をサポートしています。ネイティブP256検証を有効にするには、私たちが（@getclave"">@getclave チーム) 提案されましたRIP-7212そしてほぼすべての大規模なロールアップは今それをサポートしています。

Secure Enclavesの最大の利点は、生体認証だけでSecure Enclaves内にプライベートキーを作成できることです。これにより、最新のデバイスで利用可能な最高のセキュリティを備えたワンクリックのオンボーディング体験が可能になります。しかし、いくつかの欠点もあります:

• RIP-7212なしでのP256検証は高価であり、バグリスクを増加させます。
• 鍵を取り出せないため、ここでは回復性が欠落しています（パスキーは限られた回復性を可能にしますが、それだけでは不十分です）
• パスキーのWebドメインまたはSecure Enclave（SE）アプリケーションが機能しなくなった場合、ユーザーはプライベートキーにアクセスできません。Secure Enclaveは隔離され独立して設計されているため、関連するアプリケーションやWebドメインがないと、プライベートキーを取得または操作する方法はありません。これにより、ユーザーは必要な暗号操作を実行できなくなります。- この問題の解決方法について説明します。

3. SSSベースのキーマネジメントソリューション

SSS（Shamirの秘密分散）ソリューションは、従来の鍵管理システムのシングルポイントオブフェイルヤーを排除する方法を作成します。基本的に、鍵を異なる部分に分割し、鍵にアクセスするための閾値を確立します。これらの部分を分散することにより、SSSは誰もが完全な鍵を保持しないため、セキュリティを強化します。

彼らが鍵を保存している場所と、秘密鍵にアクセスするためのクォーラムにどのように到達するかを検討しましょう。ほとんどの既存のプロトコルは3つの鍵共有を使用しています: 1つはユーザーのデバイスに保存され、1つは彼らのサーバー(またはMPCネットワーク内)に保管され、もう1つはバックアップとして予約されています。Googleドライブなどの一部のアプリケーションでは、これらの鍵共有を保存するためにクラウドストレージソリューションを利用しています。

したがって、ユーザーはクォーラムを持ってウォレットの制御を他の当事者に委任します。MPC（Multi-Party Computation）は、異なる当事者に鍵管理の責任を委任するために強力ですが、いくつかの欠点もあります。

ほとんどのMPCソリューションには中央集権的なパーティーが必要であり、時には、彼らが分散型と呼ぶものが本当に分散型ではありません。AAを使用したMPCはキーのローテーションが可能なため強力ですが、多くのMPCソリューションにはゲートキーピングの機能が含まれることがあります。また、以前のキーが回転後も使用される場合があるため、キーが実際に廃棄されたことを信頼する必要があります。一部のMPCソリューションはユーザーを検閲することができるため、単にMPCに依存することは常に実現可能ではありません。

SSSのもう1つの主な欠点は、通常ブラウザ上で秘密鍵を再構築するということです。クライアント側で平文の鍵が利用可能であることは、重大なセキュリティリスクです。TSSは鍵を再構築せず、MPCを使用して署名をキーシェア全体で連携させます。

4. クラウドベースのTEEソリューション

クラウドベースの信頼性のある実行環境（TEE）とSSSベースのソリューションはそれほど異なるとは思いませんが、それらの動作方法を説明したかったので説明します。信頼性のある実行環境は、コードどおりに機能します。それらは変更不可です（少なくともそう主張されています）。TEEの所有者でさえ、中身を見ることはありません。それらは完全性とともに動作するように設計されています。つまり、誰も見ていない場合でも正しいことを行います。したがって、TEEが正常に動作している限り、キーはクライアントに公開されることはありません。

TEEを利用することで、開発者が異なる認証方法を使用できるキーマネジメントレイヤーを構築し、TEEがそれらを検証できます。検証後、TEEはユーザーに関連付けられた秘密鍵でメッセージに署名し、チェーン上で検証します。

ユーザーの資金を制御する主要な秘密鍵はTEE内に格納され、抽出することはできません。このため、サービスがシャットダウンまたはユーザーを検閲することを決定した場合、dAppビルダーができることは何もありません。これは分散化を脅かします。

理論上、クラウドベースのTEEは有望ですが、過去には脆弱性が見られましたsgx.failクラウドTEEに関しては、利点がありますが、バックドアや脆弱性があっても、攻撃者はTEEに物理的にアクセスする必要があるため、消費者向けハードウェア（セキュアエンクレーブ - パスキー）が非常に強力であるため、ユーザーのセキュアエンクレーブ内に鍵を格納し、所有者以外は鍵にアクセスできないため、クラウドTEEはキーをクラウド内に格納しているため攻撃に対して脆弱になります。

あなたのセキュアエンクレーブではなく、あなたのコインではありません。

私が言及したように、TEEは暗号的なブロッカーなしでほぼすべての認証方法を使用するといういくつかの利点があります。しかし、彼らはまたいくつかの欠点も持っています:

サービスプロバイダーがサーバーをシャットダウンすると、ユーザーの資金は凍結され、誰もアクセスできません。キーはCloud TEE内に格納されているため、ユーザーを検閲することができます。キー管理においてTEEsにのみ頼ることは、単一障害点を作り出します。

セッションキー：限られた権限のための新しい方法

私たちは永続的なキーについて話しました。ユーザーが決めた時間の間、資産に制限付きでアクセスでき、その後消える一時的なキーを生成できたらどうでしょうか？セッションキーを使用することで、それが可能になります:

web2の世界では、セッションキーは、2つのデバイス（コンピュータとサーバーなど）間の会話中に使用される一時的なパスワードのようなものです。会話の開始時に作成され、共有される情報を安全に保持し、会話が終了した後に破棄されます。したがって、ハッカーがこのパスワードをどうやって見つけても、新しい異なるパスワード（またはセッションキー）が毎回作成されるため、将来の会話を傍受するために使用することはできません。

Web3の世界では、セッションキーをユーザーがdAppsとやり取りする方法を変える可能性があるフレームワークとして定義しています。セッションキーの目的は、ユーザーがさまざまなシナリオで特定の時間の事前承認を設定し、署名せずに取引を行うことを可能にすることです。しかし、それはどのように機能するのでしょうか？

ユーザーは、ユーザーが指定した資産のみを限られた期間だけ使用でき、いつでも取り消すことができるセッションキーのような限られた権限を作成します。その後、バックエンドサービスがユーザーの代わりにそれらに署名することで取引を行うことを許可します。この設定により、dAppとユーザーの間に一時的な信頼ウィンドウが作成されます。承認は特定の資産および一定期間に対してのみであるため、無制限の承認よりもはるかに優れています。たとえdAppがハッキングされたとしても、ユーザーは数ヶ月前に作成されたセッションキーを心配する必要はありません 🙂。

異なるユースケースに対して最適な認証＆キー管理の組み合わせ

私はさまざまなキー管理システムとその利点と欠点について説明しました。AAの力を借りて、これらのキー管理システムを組み合わせ、最小のトレードオフで強力な構造を作成することができます。C.1）パスキー+タイムロックを備えた回復-Clave-貴重な資金を保管するためのフィンテックアプリケーションです。

セキュアエンクレーブ（パスキー）ベースの認証方法はハードウェアレベルのセキュリティを提供しますが、回復性は多くのユーザーにとって不十分です。幸いなことに、AAは開発者に異なる署名方法を組み合わせて1つのアカウントで使用することを可能にします。スマートアカウントにリカバリーサインを追加することで、パスキーが持つ回復性の問題を解決することができます。

ソーシャルリカバリー、ユニバーサルリカバリー（ZK-Email Based Recovery）、MPCベースのリカバリーなど、いくつかのリカバリーオプションがあります。しかし、私の意見では、完全に自己保管型に設計されたフィンテックアプリケーションにおいては、ソーシャルリカバリーがほとんどの問題を解決します。Claveでは、ソーシャルリカバリーモジュールを構築し、ユニバーサルリカバリーに取り組んでいます。

このアプローチは、金融アプリケーションにとって非常に優れたセキュリティを実現します。しかし、重要な欠点もあります。それは、ユーザーが行いたい各トランザクションに対して生体認証が必要な点です。例えば、ソーシャルメディアアプリケーションでコンテンツを共有したい場合、アプリが生体認証画面を表示するかもしれません... ひどいですよね？

Non-financial applications like social-Fi apps and decentralized games need an easier way to conduct transactions, ideally without requiring users to sign each transaction. How? Here is the answer:

1. パスキー+タイムロック+セッションキーによるリカバリー-モバイルソーシャルアプリ

セッションキーを使用すると、ユーザーはサイン画面なしでトランザクションを行うことができます。NFTベースのゲームやソーシャルアプリは、セッションキーを継承して、ユーザーのアセットに一時的かつ制限的にアクセスすることができます。これにより、信頼の前提がさらに増えると思われる場合は、今日のフロントエンドがどのように機能するかを説明しましょう。

今日では、ほとんどのユーザーはゲームをプレイしたり、dAppとやり取りする際に、自分が何に署名しているのかさえチェックしません。これは危険です。なぜなら、悪意のあるフロントエンドによって、ユーザーがすべてのアセットを失う可能性があるからです。

セッションキーはこれのより良い代替手段です。ユーザーはセッションの有効期間やセッションがアクセスできる資産を確認できるため、dApp への信頼の必要性が減ります。セッションの時間が切れると、ユーザーは承認の必要がなくなります = もう心配する必要はありませんrevoke.cashlike applications :)

2. MPCまたはクラウドTEEベースのサイン者+自己保管サイン者での脱出

MPC や Cloud TEE ベースのサードパーティの鍵管理レイヤの欠点は、ほとんどがセルフカストディアルではなく、重要な集中型コンポーネントを備えていることです。ただし、一部のdAppでは、余分なガスオーバーヘッドのない埋め込みウォレットが必要であり、MPCまたはCloud TEEベースのソリューションが必要です。「rage quit」の署名者を追加することで、これらの鍵管理システムが抱える検閲の問題を解決し、これらのdAppsが直面する可能性のある潜在的な法的問題を軽減することができます。EOAではキーローテーションができないため、これを構築するにはスマートウォレットが必要です。

このキー管理アーキテクチャを使用しているアプリケーションはすでにいくつか存在しています。

3. セキュリティを最大限に高めるための12ワード+ハードウェアサイナー — DeFiブラウザ拡張機能体験

DeFiユーザーはブラウザ拡張機能の体験が大好きで、ユーザーの行動を変えることは現代世界で最も難しいことの一つです。なので、なぜより良い代替案を構築しないのでしょうか？ハードウェア署名者（セキュアエンクレーブまたはパスキーサイン）と12語のシードフレーズを組み合わせて、拡張機能を介してアクセス可能にすることで、リークした秘密鍵の問題も解決できます。この手法により、セキュリティが向上し、ユーザーの行動を変える必要もありません。AA業界の複数のチームがこれを可能にするために取り組んでいます。（例 @myBraavos)

スマートアカウントは十分にスマートではありません

最初にEOAを生成したユーザーとして想像してください@MetaMaskそしてZerionのような代替案を見つけました。あなたは使うことを決めました @zerion, そしてやるべきことはシードフレーズをインポートするだけです。簡単ですね。さて、同じことをStarknet上で試してみてください。そこではすべてのウォレットがスマートアカウントであるため、できません。なぜなら、BraavosとArgentは互換性がないからです。この問題はEIP-4337のエコシステムでも存在します。 @zkSyncのネイティブAA。

私たちは、ゲートキーパーではなく、少なくとも新しいウォレットを資金提供するためのより良い方法が必要です。そうでないと、スマートウォレットの普及は決して実現されず、既存のプレイヤーが決定権を持ち、業界の慣行を決め続けることになりますが、それが正しいとは限りません。

さらに、「レイジクイット」は、ほとんどのキーマネジメントシステムの中心的な役割を果たすアクターが停止できるため、デフォルトの機能であるべきです。ユーザーが署名者を変更したり、スマートコントラクトを切り替えたりすることが容易になるべきであり、ユーザーにとってはセルフホスティングがデフォルトのオプションとなるべきです。2つのモジュラースマートアカウントの標準規格があります: ERC-6900とERC-7579。両者は同様の目標を達成しようとしています-スマートアカウントをよりスマートにすることです。

特別な感謝Derek ,コンラッド、そしてNoamフィードバックやコメントについて!

免責事項:

1. この記事は[から転載されましたX]. すべての著作権は元の著者に帰属します [2077研究]. If there are objections to this reprint, please contact the ゲートラーンチームにお任せください。迅速に対応いたします。
2. 免責事項：この記事で表現されている見解や意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. gate Learnチームは、その記事を他の言語に翻訳しました。転載、配布、または翻訳された記事の盗用は、特記がない限り禁止されています。