はじめにAAウォレットは、ユーザーの参入障壁を大幅に下げ、ガス支払いとWeb2アカウントログインを実現しましたが、機密ログイン、機密トランザクション、オムニチェーンAA、インテントフュージョンプロトコルなどの大量採用に関連する側面は、AAを基盤としてさらに開発する必要があります。

ZenGoのMPCウォレットやArgentのようなスマートコントラクトウォレットのような様々なUX最適化ソリューションが、ユーザーの障壁を効果的に軽減しているのがわかりますが、それらは前述の問題の一部に対処しているだけで、製品全体のユーザビリティの懸念を完全にカバーしているわけではありません。

明らかに、ほとんどのAAウォレットや類似製品は、Web3の普及にまだ対応できていません。 一方、エコシステムの観点からは、開発者側は重要な側面です。 開発者側に十分な影響を与えずに、通常のユーザーへの魅力だけでは、スケーラビリティを実現できる可能性は低いです。 開発者エクスペリエンス最適化ソリューションの出現は、製品エコシステムにおける開発者側の重要性が高まっていることを示しています。

Particle Networkを例にとり、Web3製品が直面している現在のUXの課題を詳しく説明し、ターゲットを絞った包括的な技術ソリューションを設計する方法について議論します。 この種の統合ソリューションは、大量採用の必要条件である可能性があります。 さらに、ParticleのBtoBtoCビジネス戦略は、多くのプロジェクトチームが有益であると感じる注目すべきアプローチとして機能します。

粒子生成物構造の内訳

Particle Networkは、使用障壁を下げることに重点を置いており、B2B2C製品の構築と生態学的開発アプローチを採用し、Web3の普及のための包括的なソリューションを提供しています。 そのコアモジュールは、次の3つの主要コンポーネントで構成されています。

zkWaaSとは、ゼロ知識ウォレット・アズ・ア・サービス(zero-knowledge wallet-as-a-service)のことです。 開発者は、ParticleのSDKを使用して、スマートウォレットモジュールをdAppsにすばやく統合できます。 このウォレットは、アカウントの抽象化に基づくキーレスのスマートコントラクトウォレットであり、ガス支払いを可能にし、Web2スタイルのOAuth機密ログインと機密トランザクションを提供します。

Particle Chain - Particle用に設計された専用のOmnichain Account Abstractionスキームは、スマートコントラクトウォレットのクロスチェーン展開、メンテナンス、および呼び出しの課題に対処することを目的としています。 また、Unified Gas Tokenも含まれており、マルチチェーントランザクションでのさまざまなガストークンの使用を簡素化します。

Intent Fusion Protocol - 簡潔なドメイン固有言語(DSL)、インテントフレームワーク、インテントソルバーネットワークなどが含まれており、インテントに基づいてWeb3インタラクションフレームワークを構築します。 ユーザーは、特定の操作をそれぞれ実行するのではなく、トランザクションの意図を直接宣言するため、複雑なパスの考慮事項から解放され、複雑な基盤となるインフラストラクチャを理解する必要性が軽減されます。

zkWaaS - ゼロ知識ウォレット・アズ・ア・サービス

ウォレット側では、Particleは主にWallet-as-a-Service(WaaS)の形でdApp開発者向けのSDKを提供しています。 その目的は、開発者が包括的なWeb3マスアダプションフレームワークに統合できるようにすることです。 このBtoBtoCアプローチには、ビジネスとエコシステムの両面からいくつかの利点があります。

消費者向けウォレット市場は競争が激しく、機能の類似性が高まっています。 消費者のウォレットは、もはや最適なエントリーポイントではありません。 一方、dApp開発者は、ユーザーエクスペリエンスを向上させ、よりカスタマイズ可能な機能を提供するために、アプリケーション内にウォレットを統合することを好みます。

コンシューマ側でユーザーを獲得するにはコストがかかりますが、ビジネス側では違います。 WaaSのユーザー数の増加は、主にSDKと統合されたdAppsに起因しています。 効果的なビジネス開発と開発者との関係により、エコシステムは有機的に拡大することができます。

現在の消費者ウォレットは、主に金融と資産に焦点を当てており、Web3の将来の主なシナリオを表していない可能性があります。 Web3を広く普及させるには、ユーザーID(アカウント)やユーザー操作(トランザクション開始)などの基本機能を基本的なサービスとして抽象化し、より豊かなシナリオをdAppsで処理する必要があります。

歴史的に、dAppsの入り口は、ウォレットとdAppsの間に密接な関係を示してきました。 dApp側でウォレットの市場シェアを拡大することは非常に重要です。 これは、B2B2Cモデルにとって特に有利です。

ユーザーのニーズを満たし、参入障壁を下げ、開発者の統合を容易にするソリューションを構築するために、ParticleのzkWaaSは、3つのコア機能を備えた重要なコンポーネントとして機能します。

1. コンフィデンシャルログイン:スマートコントラクトウォレットで、Twitter、Google、WeChatなどのプラットフォームからのOAuth検証など、従来のWeb2ログイン方法を活用します。 これにより、ユーザーは秘密鍵管理の制約から完全に解放され、最も身近でわかりやすい方法でWeb3に参入することができます。 同時に、ゼロ知識証明を使用してユーザーIDが隠されます。

2. 機密取引:スマートステルスアドレスメカニズムを通じてポイントツーポイントのプライバシー転送を実装し、取引における普遍的なプライバシーを確保します。 さらに、ERC-4337のPaymasterを利用することで、スマートステルスアドレス(ガススポンサーシップ)のための資産をガスレスで使用することができます。

3. 包括的なAAウォレット機能:Particleのウォレットモジュールは、ERC-4337の基本要件に完全に準拠しています。 Bundler、EntryPoint、Paymaster、Smart Wallet Accountなどの重要なコンポーネントが含まれており、ERC-4337ワークフローのすべての重要な側面をカバーしています。 このワンストップソリューションは、DAppsやユーザーのスマートウォレットに対する機能的な要求を効果的に満たします。

Web2アカウントに基づくオンチェーンウォレットの機密ログイン

Particleのコンフィデンシャルログインソリューションは、JSON Web Tokens(JWT)を利用して、スマートコントラクト内でWeb2 ID認証とウォレット操作を可能にします。

JWTは、従来のインターネットアプリケーションで広く使用されているID証明の形式であり、サーバーからクライアントに発行されます。 クライアントは、サーバーとの各対話で ID 認証にこの証明を使用します。

(出典:FlutterFlow Docs)

JWTには、コントラクトによる本人確認の基礎となるいくつかの重要なフィールドがあります。

·"iss" (Issuer) は、JWT の発行者、つまり Google、Twitter などのサーバーを示します。

·"aud" (Audience): JWT が対象とするサービスまたはアプリケーションを指定します。 たとえば、Twitterを使用してMediumにログインする場合、Twitterが発行するJWTには、Mediumへの適用性を示すこのフィールドが含まれます。

·"sub" (サブジェクト): JWT を受信するユーザー ID を指し、通常は UID で識別されます。

実際には、"iss" と "sub" は、内部システムと外部参照の間の実質的な混乱を避けるために、通常一定に保たれます。 したがって、これらのパラメータをコントラクトで使用してユーザー ID を特定できるため、ユーザーが秘密キーを生成して保護する必要がなくなります。

JWTに対応するのは、サーバー上のキーペアのセットであるJSON Web Key(JWK)の概念です。 JWTを発行すると、サーバーはJWKの秘密鍵で署名し、対応する公開鍵は他のサービスが署名を検証するために公開されます。

たとえば、MediumがログインにTwitterを使用する場合、MediumはGoogleの公開JWKを使用してJWTを検証し、その信頼性(実際にGoogleが発行したもの)を確認します。 契約によるJWTの検証には、JWKの使用も含まれます。

Particle の機密ログイン ソリューションのプロセスを以下の図に示します。

ここでは特定のZK回路をスキップし、プロセスのいくつかの重要なポイントを強調します。

ログイン情報を検証するVerifierコントラクトは、ユーザーのID、JWT、およびeph_pkに関連するZKプルーフのみを認識します。 対応するウォレットの公開鍵やJWT情報を直接取得することはできず、ユーザーのプライバシーを確保し、外部エンティティがオンチェーンデータからログインユーザーを特定するのを防ぎます。

eph_pk(エフェメラルキーペア)は、1つのセッションで使用されるキーペアであり、ウォレットの公開鍵と秘密鍵のペアではありません。 ユーザーはそれを気にする必要はありません。

このシステムはオフチェーン検証をサポートしており、MPC(Multiparty Computation)などのロジックを採用したコントラクトウォレットに使用できます。

これは、従来のログイン方法に真摯に基づいた契約検証ソリューションであるため、ユーザーは、Web2アカウントが無効になるなど、極端な場合に他のソーシャルコンタクトを保護者として指定することもできます。

DH鍵交換に基づく機密取引

Particleの機密トランザクションについて説明する前に、既存のEVMシステム内で受信者の機密トランザクションを実現する方法、特に受信者のアドレスを非表示にする方法を検討しましょう。

Alice が送信者で Bob が受信者であると仮定すると、両者はいくつかの共通の知識を共有します。

1. ボブはルート支出キー(m)とステルスメタアドレス(M)を生成します。 M は m で生成でき、それらの関係は M = G * m で表され、暗号操作における数学的関係を示します。

2. アリスはボブのステルスメタアドレスMをあらゆる手段で入手する。

3. Alice はエフェメラル秘密鍵 (r) を生成し、アルゴリズム generate_address(r, M) を使用してステルス アドレス (A) を作成します。 このアドレスは、ボブのために用意された専用のステルスアドレスとして機能し、資産を受け取るとボブが制御権を獲得します。

4. Alice は、エフェメラル秘密鍵 r に基づいてエフェメラル公開鍵 (R) を生成し、エフェメラル公開鍵記録コントラクト (または Bob がアクセスできる相互に合意した場所) に送信します。

5. Bob は、エフェメラル pubkey レコーディング コントラクトを定期的にスキャンし、更新されたすべてのエフェメラル pubkey を記録します。 エフェメラル pubkey コントラクトは公開されており、他のユーザーから送信されたプライバシー トランザクションに関連するキーが含まれているため、Bob は Alice がどのキーを送信して表示したかを知りません。

6. ボブは更新された各レコードをスキャンし、generate_address(R, m) を実行してステルスアドレスを計算します。 そのアドレスにアセットがある場合は、アリスがボブの管理のためにアセットを生成し、承認したことを意味します。そうでなければ、ボブには関係ありません。

7. ボブはgenerate_spending_key(R, m)を実行して、そのステルスアドレスの支出キー、つまりp = m + hash(A)を生成します。 その後、Bob は Alice が生成したアドレス A を制御できます。

説明されているプロセスは、多くの複雑な数学演算を単純化します。 情報交換のプロセス全体は、2人の秘密諜報員が公共の掲示板に謎めいたメッセージを書くようなもので、メッセージはお互いにしか解読できない。 これらのメッセージの生成方法と復号化方法は公開されていますが、両方のエージェントに必要な重要なデータは、エージェントだけが知っています。 その結果、部外者がその方法を理解したとしても、復号化の成功はとらえどころのないままです。

この交換プロセスは、よく知られた Diffie–Hellman 鍵交換方法にいくらか似ています。 秘密(ボブのルート支出キー(m)とアリスのエフェメラルプライベートキー(r))を明かすことなく、両者は共有シークレット(前述のステルスアドレス(A))を計算できます。 DH交換に慣れていない場合は、以下の図を使用して比喩的な理解を容易にすることができます。

DHと比較して追加されたステップは、共有シークレット(ステルスアドレス(A)を計算した後、アリスもAを知っているため、秘密鍵として直接使用できないことです。Aを公開鍵として扱う支出鍵(p = m + hash(A))を構築する必要があります。 前述したように、ボブだけがルート支出キー(m)を知っているため、ボブはこのステルスアドレスの唯一のコントローラーになります。

明らかに、このプライバシー転送方法では、新しいトランザクションを受信するたびに、資金はまったく新しいEOAアドレスに流れ込みます。 受信者は、ルート支出キーを使用して、各アドレスの使用キーを繰り返し計算し、それらに純粋に関連付けられているキーを見つけるために実験することができます。

ただし、まだ問題があります。 当初、この新しく生成されたステルスアドレスはまだEOAアカウントであり、ETHやその他のガストークンが不足している可能性があります。 ボブは直接取引を開始することができず、秘密の取引を実現するために、スマートコントラクトウォレットのPaymasterをガスの支払いに使用する必要があります。 そのため、受信者のアドレスにはいくつかの変更が必要です。

コントラクト展開時のCREATE2機能からのアドレス計算方法と、対応するパラメータ(ステルスアドレスAをコントラクトの所有者として設定するなど)を使用して、反事実アドレスを計算します。 これは、まだ展開されていない計算されたコントラクト アドレスで、現在は EOA です。

アリスは、この反事実アドレスに直接資金を送金します。 ボブがそれを使いたいときは、このアドレスに直接コントラクトウォレットを作成し、ガス支払いサービスの呼び出しを可能にします(このステップは、事前にアリスまたはパーティクルネットワークで処理することもできます)。

前述の反事実アドレスは、スマートステルスアドレスと呼ぶことができます。 ボブは、次のプロセスを通じて、このスマートステルスアドレスのアセットを匿名で使用します。

·Paymasterの住所から入金すると、Paymasterは資金証明(ZKベース)を返します。

·AA メカニズムでは、残高がない可能性のある他のアドレスを使用して UserOperation を Bundler ノードに送信し、前述のステルス アドレスのアセットを呼び出します。 ボブは新しいアドレスを使用してPaymasterに資金証明を提供するだけでよく、Paymasterはトランザクションパッケージの代金をバンドラーに支払います。

このプロセスは、Tornado Cash の動作方法と似ています。 ファンドプルーフ(ZKベース)は、マークルツリーのリーフノードのセットで再充電が発生したことを証明できます。 しかし、支出の際、どの特定のリーフノードの資金が消費されたかを誰も判断できないため、消費者と充電器の間の接続が切断されます。

要約すると、ParticleはAAとステルスアドレスを巧みに組み合わせ、インテリジェントなステルスウォレットの形で機密転送を実現します。

パーティクルチェーンとオムニチェーンアカウントの抽象化

Particle Chainは、Omnichain Account Abstraction用に設計されたPOSチェーンです。 現在と未来の両方を考慮すると、単一チェーンが優位に立つ可能性は低いです。 マルチチェーンのシナリオでは、ユーザーエクスペリエンスを向上させることが重要です。

現在、ERC4337アカウント抽象化システムは、マルチチェーンの状況で特定の問題に遭遇する可能性があります。

• 異なるチェーン上の同じユーザーのアドレスは、コントラクトの設計によっては統一されていない場合があります。
• 異なるチェーンコントラクトウォレットを管理するには、管理者の変更など、複数のチェーンにわたる手動操作が必要です。 最悪のシナリオでは、1つのチェーンで管理者権限が更新され、その後古い管理者検証メソッドを破棄すると、他のチェーンで変更を加えることができなくなり、ウォレットが使用できなくなります。
• 異なるチェーンを使用するには、チェーンごとにガストークンを持っているか、各チェーンのPaymasterに事前に保管されている資金が必要です。 開発者にとって、これは厄介なことです。 ユーザーが特定の条件をゼロコストで使用したり、他の機能を実装したりする場合は、各チェーンにカスタムPaymastersをデプロイし、事前に資金を調達する必要があります。

Particle ChainのOmnichain Account Abstractionは、上記の問題点に対処します。

• Particle ChainにAAウォレットを確立します。
• LayerZeroおよびその他のArbitrary Message Bridge(AMB)クロスチェーンプロトコルを使用して、権限の作成、アップグレード、変更などのさまざまな操作を他のチェーンに同期します。 これは、他のチェーンのウォレットがそのチェーンのウォレットを参照し、本体への変更がすべてのウォレットに同期していると理解できます。
• 一貫性のあるパラメータDeployer Contractを通じて、各チェーン上のウォレットの統一されたアドレスを確保します。
• 異なるチェーン上のウォレットは、必ずしもParticle Chainから開始されるとは限りませんが、AMBを介して相互に呼び出すこともできます。
• Unified Gas Tokenを発行します。 Paymasterメカニズムは、ERC20をガス料金として実装します。 Paymasterにガスや事前に保管された資金がないチェーンでも、統一されたガストークンを消費するクロスチェーントランザクションは、準拠したチェーンで開始できます。

上記のユースケースに加えて、Particle Chainは次の用途にも利用される可能性があります。

• zkWaaSプルーフとソルト生成のための分散型ネットワーク。
• 異なるチェーンにまたがるバンドラーのインセンティブレイヤーは、バンドラーの分散化の促進を支援します。
• Intent Fusion Protocolのソルバーネットワークとして機能します。

Particle Chainの物語では、統一されたガストークンは、エコシステム全体のコアバリュープロポジションとして機能します。

• ガス料金の支払い機能は、暗号空間で繰り返し検証された強力な需要と価値の獲得ロジックです。
• Unified Gas Tokenは、既存のパブリックチェーンエコシステムからガス層の概念を抽象化します。 この抽象化は、Particle Chainとウォレットなしでは実現できません。 したがって、統一されたガストークンは、パーティクルエコシステム全体の価値の実現を表しています。 ガス層では、異なるチェーン間でのユーザーインタラクション、成長、およびネイティブトークンの価値は、統一されたガストークンと相互に有益な関係にあります。
• また、ユニファイドガスもチェーンレス化の推進要因の1つです。 ユーザーにとっては、単一通貨を使用することで、使用プロセスとコストの理解が大幅に簡素化されます。 将来的には、マルチチェーンのシナリオでも、ユーザーは気付かず、基盤となるインフラストラクチャの運用を気にする必要がなくなる可能性があります。 現在Web2で行われているように、データセンターの場所や構成、使用する言語やデータベースを気にすることなく、サーバーとやり取りしています。
• dAppsによってインポートされたユーザーは、統一されたガストークンに直接力を与え、幅広いユースケースを提供します。

Intent Fusionプロトコル

通常、さまざまなdAppsを使用する場合、ユーザーは常に使用パスを考慮する必要があります。

• 1つのDEXに流動性がない場合は、別のDEXを確認する必要があります。
• トランザクションやタスクに対して、同じカテゴリ内で最適なdAppを選択する。
• 多くの機能を使用する前に「承認」の概念を理解します。
• ウォレットの埃を払い、複数の少額のトークンを特定のトークンに変換する - 面倒なプロセス。
• 最終目標を達成するために、さまざまなアプリケーション間で複数の手順を完了する。 例えば、ハイレバレッジレンディングでは、スワップ、ステーキング、借入、トークンの取得、そして再びスワップ、ステーキング、借入を行います。

上記のコンテンツは、現在のDeFiの状況を垣間見たに過ぎず、Web3で多様なdAppsが広く採用される時代に移行するにつれて、インタラクションの複雑さは私たちの想像をはるかに超えるものになるかもしれません。

したがって、特定の運用手順をインテントに置き換えると、ユーザーのエクスペリエンスが大幅に異なります。 インテントは、操作と比較すると、宣言型プログラミングと関数型プログラミングに似ています。 宣言文は、多くの場合、後の詳細を気にすることなく、何をする必要があるかを宣言するだけで、率直な感覚を与えます。 このため、基盤となるレイヤーにさまざまなレベルのカプセル化された関数型プログラミング ステートメントが必要になります。

同様に、インテントを使用するには、一連のファシリティからのサポートが必要です。 プロセス全体を調べてみましょう。

1. ユーザーはインテントを送信し、自然言語などの何らかの方法で記述し、RFS(Request For Solver)の形式でソルバーネットワークに送信します。 ソルバーはインテントのインタープリターであり、アグリゲーターである1inchなどの一般的なソルバーであり、ユーザーにとって最適なDEXを探し求めます。 ただし、これらのソルバーは、私たちのビジョンと比較すると、汎用性が高く、十分に強力ではない可能性があります。

2. 複数のソルバーが応答し、互いに競合します。 これらのレスポンスは Intent DSL 言語で記述され、後でクライアントによって解析され、ユーザーが理解しやすい形式になります。 これらの応答には、入力と出力の境界を定義する入力制約と出力制約が含まれます。 また、ユーザー自身で制約を指定することもできます。 理解のための簡単な例:スワップを使用すると、ユーザーはスワップ後に受け取ることができる最小金額を尋ねられますが、これは一種の制約です。 ユーザーは、複数のソルバーから提供される応答から選択します。

3. インテントに署名します。

4. ソルバーは、特定の実行コントラクト Executor を指定し、応答コントラクト Reactor にインテントを送信します。

5. リアクタは、ユーザのアカウントから必要な入力(特定のアセットなど)を収集し、インテントをエグゼキュータに送信し、関連するロジック コントラクトを呼び出した後、トランザクションの出力をリアクタに返します。 リアクタは制約をチェックし、正しければ出力をユーザに返します。

このプロセスは、ChatGPT に要件を説明しているかのように想定できます。 要件がどれほど複雑であっても、最終結果を生成できます。 結果に満足している限り、基礎となるプロセスを気にすることなく、直接使用できます。

結論

Particle Networkは、zkWaaS、Particle Chain、Intent Fusion Protocolの統合形式を通じて、Web2 OAuthプライバシーログイン、プライバシートランザクション、オムニチェーンアカウントの抽象化、およびインテントベースのトランザクションパラダイムを実現する包括的なソリューションを提案しています。 各機能は、Web3 の使用における問題点の一部に対処します。 これらの進歩と最適化は、Web3製品とテクノロジーが将来広く採用されるための基盤となります。 エコシステムとビジネスモデルの面では、B2B2Cパラダイムを採用し、WaaSをエントリーポイントとして使用して製品チェーン全体のスケーラビリティと標準化を推進し、dApp開発者とエコシステムを共同で構築し、ユーザーのために敷居の低い、高体験のWeb3の世界を共同で作成します。

もちろん、Web3の大量導入の実装パスについては、プロジェクトによって解釈が異なります。 特定のプロジェクトを精査するだけでなく、さまざまなソリューションを使用して、Web3が現在直面しているオンボーディングの摩擦の理解、ユーザーのニーズと問題点の熟考、エコシステム全体の集合的な接続と開発への考慮事項を強調したいと考えています。

免責事項：

1. この記事は【极客Web3】からの転載ですが、すべての著作権は原作者【雾月,极客Web3】に帰属します。 この転載に異議がある場合は、 Gate Learn チームに連絡していただければ、迅速に対応いたします。
2. 免責事項:この記事で表明された見解や意見は、著者のものであり、投資アドバイスを構成するものではありません。
3. 記事の他言語への翻訳は、Gate Learnチームによって行われます。 特に明記されていない限り、翻訳された記事を複製、配布、盗用することは禁止されています。