ボブは、ルート支出キーmとステルスメタアドレスMを生成します。 M は m で生成でき、両者の関係は M = G * m であり、暗号演算における数学的関係を表します。
アリスは、ボブのステルスメタアドレスMをいずれかの方法で取得します。
Alice は一時的な秘密鍵 r を生成し、アルゴリズム generate_address (r,M) を使用して隠しアドレス A を生成します。 **このアドレスはボブの排他的な****ステルスアドレスであり、ボブは資産を受け取った後、アドレスを制御します。 **
次に、アリスは、一時秘密鍵 r に基づいて一時公開鍵 R を生成し、それを一時公開鍵レコード コントラクト (または、Bob が取得できる限り、チャネルが何であれ、相互に合意した任意の場所) に送信します。
Bob は、一時的な公開キー レコード コントラクトを定期的にスキャンし、更新された各一時公開キーを記録する必要があります。 エフェメラル公開キー コントラクトは公開であり、他のユーザーから送信されたプライベート トランザクションに関連するキーが含まれているため、Bob は Alice が送信したキーを知りません。
Bob は更新された各レコードをスキャンし、generate_address (R,m) を実行して編集されたアドレスを計算します。 アドレスに資産がある場合、それはアリスによって生成され、ボブによって制御されることが承認され、それ以外の場合はボブとは何の関係もありません。
Bob は generate_spending_key(R,m) を実行して、ステルスアドレスのコンシューマ秘密鍵 (p = m + hash(A) ) を生成し、Alice が生成したアドレス A を制御できます。
この交換プロセスは、よく知られた Diffie–Hellman 鍵交換方法とほぼ同じで、両者は、それぞれの秘密 (Bob のルート コンシューマ秘密鍵 m と Alice の一時秘密鍵 r) を明かさずに、共有秘密 (上記の隠しアドレス A) を計算できます。 **DH交換についてご存じない方は、以下の染色図を用いて比喩的に理解することができます。
DH と比較した場合の追加ステップは、Alice も A を知っているため、それぞれが共有シークレット編集されたアドレス A を把握した後、それを秘密キーとして使用できないことです。 コンシューマの秘密鍵 p = m + hash(A) を構築し、A を公開鍵として扱う必要があります。 前述したように、ルートコンシューマの秘密鍵 m は Bob だけが知っているため、Bob はステルスアドレスの唯一のコントローラになります。 **
**フルチェーンのガスコインであるUnified Gas Tokenの発行。 **ERC20は、Paymasterメカニズムによってガス料金として実装されています。 特定のチェーンにガスやPaymasterが事前に入金した資金がない場合でも、適格なチェーンでクロスチェーン取引を開始して、Unified Gas Tokenを消費することができます。
**Particle Chainの物語では、Unified Gas Tokenはエコシステム全体のコアバリューを把握しています。
ガス料金を支払う機能は、暗号で繰り返し検証されている強力な需要と価値のキャプチャロジックです。
Unified Gas Tokenは、既存のパブリックチェーンの生態学からガス層の概念を抽象化しており、この抽象化はParticle Chainとウォレットなしでは達成できないため、Unified Gas TokenはParticleの生態学全体の価値の引き出しです。 ガス層では、各チェーンのユーザーインタラクションと成長、および現地通貨の価値が相互に有益であり、Unified Gas Tokenと共生しています。
**1. ユーザーは、自然言語などのRFS(Request For Solver)の形式でソルバーネットワークに送信します。 **ソルバーはインテントのインタープリターであり、1inchのようにユーザーに最適なデックスを見つけることができるアグリゲーターもありますが、私たちのビジョンと比較すると、汎用的で強力ではありません。
Particle Networkを例にとると、このテクノロジーは現在のWeb3製品のエクスペリエンスの問題を解釈します
著者: Wuyue, Geek Web3
はじめに:AAウォレットはユーザーの敷居を大幅に下げ、当初はガス決済とweb2アカウントログインを実現しましたが、プライバシーログイン-プライベートトランザクション、フルチェーン統合AAアカウント、インテント専用アーキテクチャなどの大量採用に関連する設計は、AAに基づいて追加する必要があります。
ZenGoなどのMPCウォレットやArgentなどのスマートコントラクトウォレットなど、ユーザーの敷居を効果的に下げるUX最適化ソリューションは数多く見られますが、上記の問題の一部しか解決しておらず、製品の使いやすさを完全にカバーしているわけではありません。
明らかに、ほとんどのAAウォレットや類似製品は、Web3の大量採用をまだサポートできていません。 一方、エコロジカルな観点から見ると、現像側は非常に重要なレベルであり、製品的には一般ユーザーにとってのみ魅力的であるが、現像者側への影響が不十分であるため、スケールを形成することは困難である。 **開発エクスペリエンス最適化ソリューションの出現により、製品エコシステムにおける開発者側の重要性が実証されています。
Particle Networkを例にとり、Web3プロダクトの現状における経験上の問題点や、マスアダプションの必要条件となりうる包括的な技術ソリューションの設計方法について詳しく解説します。 同時に、ParticleのBtoBtoCビジネス戦略は、多くのプロジェクト関係者が見習うべきアイデアでもあります。 **
粒子生成物構造フルソリューション
Particle Networkは、使用の閾値を解決することを中核として、B2B2C製品の構築と生態学的開発のアイデアで、Web3の大規模な採用のための完全なソリューションセットを提案します。 そのコアモジュールは3つです。
**zkWaaSは、ゼロ知識証明に基づくWallet-as-a-Service(WaaS)サービスです。 **開発者は、Particleが提供するSDKに基づいて、スマートウォレットモジュールを独自のdAppにすばやく統合できます。 ウォレットは、アカウント抽象化に基づくキーレススマートコントラクトウォレットであり、ガス支払いなどのAA基本シナリオを実現できるだけでなく、Web2スタイルのOAuthプライバシーログイン方法やプライベートトランザクションなどの機能も提供できます。
Particle Chain - Article専用のOmnichain Account Abstractionソリューションで、スマートコントラクトウォレットのクロスチェーン展開、メンテナンス、および呼び出しの解決に特化しています。 また、マルチチェーン取引に異なるガスコインを使用する手間を解決するために、Unified Gas Token(Unified Gas Token)もあります。
**Intent Fusion Protocolは、簡潔なDSL(ドメイン固有言語)言語、インテントフレームワーク、インテントソルバーネットワークなどを含み、インテントベースのWeb3インタラクションフレームワークの構築に使用されます。 ユーザーは、特定のアクションをそれぞれ実行する代わりに、トランザクションの意図を直接宣言するため、ユーザーは面倒なパス思考から解放され、複雑な基盤となるインフラストラクチャの理解が減ります。
zkWaaS – ZKと組み合わせたSmart Wallet-as-a-Service
ウォレット側では、Particleは主にdApp開発者向けにWaaS(Smart Contract Wallet-as-a-Service)の形でSDKを提供し、開発者が完全なWeb3マスオプションフレームワークにアクセスできるようにしています。 このBtoBtoCソリューションには、ビジネスと環境の観点からいくつかの利点があります。
**純粋なCエンドウォレットの競争は白熱しており、機能は比較的似ており、Cエンドウォレットはもはや良いエントリーポイントではありません。 一方、dApp開発者は、ユーザーがウォレットとトランザクションを接続するときにウォレットを切り替える必要があるときにエクスペリエンスの損失を回避し、よりカスタマイズ可能な機能を提供するために、dAppsにウォレットを組み込む傾向が強まっています。
**顧客獲得コストはC面では高いが、B面では異なる。 **WaaSユーザーの増加は、主にSDKと統合されたdAppsによって推進されています。 BDと開発者の関係が良好であれば、「都市が田舎を囲む」というスタイルでエコシステム全体を拡張できます。
**現在、Cエンドウォレットは主に金融と資産に焦点を当てており、これが将来のWeb3のメインシナリオであるとは言い難いです。 Web3のマスアダプションを真に実現するためには、より基本的な機能であるユーザーID(アカウント)とユーザー操作(トランザクション/トランザクションの送信)を低レベルのサービスとして抽象化し、上位レイヤーのより豊かなシナリオをdAppに引き渡すプロジェクトが必要です。
前のdApp接続の入り口から、ウォレットとdAppの間の緊密な結合関係を観察することができます。 **dApp側でウォレットの市場シェアをできるだけ増やすことは非常に重要です。 これは、B2B2C モデルの最優先事項です。 **
ユーザーのニーズを満たし、参入障壁を低くし、開発者が簡単にアクセスできるWaaSを構築することも、このソリューションの成功のもう一つの柱です。 Particle の zkWaaS には 3 つのコアがあります。
**1. プライバシーログイン。 **Twitter、Google、WeChatログイン、その他のOAuth認証方法など、コントラクトウォレットで従来のWeb2ログイン方法を使用することで、ユーザーは秘密鍵管理の束縛を完全に取り除き、最も身近で簡単な方法でWeb3に参入することができます。 同時に、ゼロ知識証明は、ユーザーの身元を隠すために使用されます。
**3.完全なAAウォレット機能。 **Particleのウォレットモジュールは、Bundler、EntryPoint、Paymaster、Smart Wallet Account、およびERC-4337ワークフローのその他の重要な部分を含むERC-4337の基本要件に完全に準拠しており、DAPPまたはスマートウォレットのユーザーの機能要件をワンストップで満たします。
web2アカウントに基づくオンチェーンウォレットのプライバシーログイン
Particleのプライベートログインソリューションは、コントラクト内でWeb2のID認証やウォレットの運用に利用できるJWT(Json Web Token)を活用しています。
JWTは、従来のインターネットで広く使用されている、サーバーからクライアントに発行される一種のID証明書であり、クライアントはサーバーと対話するたびにこの証明に依存して認証を行います。
JWT には、コントラクトが ID を検証するための基礎となるいくつかの重要なフィールドがあります。
·" iss" (発行者) は、JWT の発行元、つまり Google、Twitter などのサーバーを示します。
·" aud" (Audience) は JWT が使用するサービスまたはアプリケーションを示し、Twitter で Medium にログインした場合、このフィールドは Twitter が JWT を発行したときに JWT が Medium に適用されることを示します。
·" sub" (サブジェクト) は、JWT を受け入れるユーザーの ID を指し、通常は UID でマークされます。
実際には、ISSと潜水艦はほとんどの場合変更されませんが、そうでなければ、内部システムと外部参照の大きな混乱をもたらすことになります。 したがって、これらのパラメータをコントラクトで使用してユーザーの ID を特定できるため、ユーザーは秘密キーを生成して保持する必要はまったくありません。 **
JWTに対応する概念は、サーバー側のキーペアのセットであるJWK(JSON Web Key)です。 サーバーがJWTを発行すると、JWKの秘密鍵で署名し、対応する公開鍵は公開され、他のサービスの署名を検証するために使用されます。
たとえば、MediumでTwitterにログインすると、MediumはGoogleが公開しているJWK公開鍵を使用してJWTを検証し、JWTが本物であること、つまり実際にGoogleが発行したことを確認します。 JWK は、JWT のコントラクト検証にも使用されます。
Particle のプライベートログインソリューションのフローを次の図に示します。
その中で、ここでは特定のZK回路をスキップします。 プロセスの重要なポイントをいくつか挙げてください。
**ログイン情報を検証するVerifierコントラクトは、ユーザーのIDに関連するZKプルーフ(JWT)と無害なeph_pkのみを認識し、ユーザーのプライバシーを保護するために、対応するウォレット公開鍵またはJWT情報を直接取得することはできず、外部はオンチェーンデータからログイン者の身元を知ることはできません。 **
Eph_pk(エフェメラルキーペア)は、ウォレットの公開鍵や秘密鍵ではなく、単一のセッションで使用されるキーペアであり、ユーザーは気にする必要はありません。
このシステムはオフチェーン検証にも使用でき、MPCなどのロジックを使用するコントラクトウォレットに使用できます。
これは従来のログインに基づく真の契約検証スキームであるため、ユーザーはWeb2アカウントのキャンセルなどの非常に極端な状況の場合に、他のソーシャル連絡先を保護者として指定することもできます。
DH鍵交換方式によるプライベートトランザクション
Particleのプライベート・トランザクション・ソリューションについて説明する前に、まず、既存のEVMシステム内で受信者へのプライベート・トランザクションを実現する方法、つまり受信者のアドレスを隠す方法を検討してみましょう。
アリスが送信者でボブが受信者であり、いくつかの共通の知識があると仮定しましょう。
ボブは、ルート支出キーmとステルスメタアドレスMを生成します。 M は m で生成でき、両者の関係は M = G * m であり、暗号演算における数学的関係を表します。
アリスは、ボブのステルスメタアドレスMをいずれかの方法で取得します。
Alice は一時的な秘密鍵 r を生成し、アルゴリズム generate_address (r,M) を使用して隠しアドレス A を生成します。 **このアドレスはボブの排他的な****ステルスアドレスであり、ボブは資産を受け取った後、アドレスを制御します。 **
次に、アリスは、一時秘密鍵 r に基づいて一時公開鍵 R を生成し、それを一時公開鍵レコード コントラクト (または、Bob が取得できる限り、チャネルが何であれ、相互に合意した任意の場所) に送信します。
Bob は、一時的な公開キー レコード コントラクトを定期的にスキャンし、更新された各一時公開キーを記録する必要があります。 エフェメラル公開キー コントラクトは公開であり、他のユーザーから送信されたプライベート トランザクションに関連するキーが含まれているため、Bob は Alice が送信したキーを知りません。
Bob は更新された各レコードをスキャンし、generate_address (R,m) を実行して編集されたアドレスを計算します。 アドレスに資産がある場合、それはアリスによって生成され、ボブによって制御されることが承認され、それ以外の場合はボブとは何の関係もありません。
Bob は generate_spending_key(R,m) を実行して、ステルスアドレスのコンシューマ秘密鍵 (p = m + hash(A) ) を生成し、Alice が生成したアドレス A を制御できます。
上記のプロセスの説明は、実際には多くの複雑な数学的操作を単純化しています、**情報交換プロセス全体は、2人のスパイが公開掲示板でお互いにしか解読できないいくつかのコードワードを書き留めるようなものです、**コードワードの生成と解読方法は公開されていますが、途中で必要な重要なデータを知っているのは2人のスパイだけなので、外の世界がコードワードの生成と復号の方法を知っていても、スムーズに復号することはできません。
この交換プロセスは、よく知られた Diffie–Hellman 鍵交換方法とほぼ同じで、両者は、それぞれの秘密 (Bob のルート コンシューマ秘密鍵 m と Alice の一時秘密鍵 r) を明かさずに、共有秘密 (上記の隠しアドレス A) を計算できます。 **DH交換についてご存じない方は、以下の染色図を用いて比喩的に理解することができます。
DH と比較した場合の追加ステップは、Alice も A を知っているため、それぞれが共有シークレット編集されたアドレス A を把握した後、それを秘密キーとして使用できないことです。 コンシューマの秘密鍵 p = m + hash(A) を構築し、A を公開鍵として扱う必要があります。 前述したように、ルートコンシューマの秘密鍵 m は Bob だけが知っているため、Bob はステルスアドレスの唯一のコントローラになります。 **
明らかに、このプライベート送金方法では、受取人が新しいトランザクションを受け取るたびに、そのトランザクションの資金が新しいEOAアドレスに流れ込みます。 受信者は、ルート消費秘密鍵を使用して、各アドレスの消費秘密鍵を個別に計算し、どのアドレスが実際に自分に関連しているかを確認できます。
しかし、この新しく生成されたステルスアドレスは、最初はまだEOAアカウントであり、ETHなどのガストークンがない可能性があり、ボブは直接取引を開始する方法がなく、**プライベートトランザクションを実現するために、ガス支払いにスマートコントラクトウォレットのPaymaster機能を使用する必要があります。 **したがって、受信アドレスにいくつかの変更を加える必要があります。
コントラクト展開時のCREATE2方式のアドレス計算方法と、対応するパラメータ(ステルスアドレスAをコントラクトの所有者として設定するなど)を用いて、反事実アドレスを算出します。 これは計算されたコントラクトアドレスですが、コントラクトはまだデプロイされておらず、当面はEOAのままです。
**アリスは反事実関係の住所に直接送金します。 **ボブがそれを使用したいときは、このアドレスに直接コントラクトウォレットを作成して、ガス支払いサービスを呼び出すことができます(このステップは、彼に代わってアリスまたはパーティクルネットワークが実行することもできます)。
上記の反事実アドレスは、スマートステルスアドレスと呼ぶことができます。 Bob は、次のプロセスを使用して、Smart Cloak アドレスのアセットを匿名で使用します。
自分のアドレスのいずれかでPaymasterにチャージすると、Paymasterは資金の証明(ZK)を返します。
AA メカニズムを使用して、他のアドレス (残高がなくても可) を使用して UserOperation を Bundler ノードに送信し、上記の非表示アドレスの下にあるアセットを呼び出します。 ボブは新しい住所でPaymasterに資金の証明を提供するだけで、PaymasterはBundlerパッケージトランザクションの代金を支払います。
これは、実際にはトルネードキャッシュの仕組みと似ており、マークルツリーのリーフノードのセットにトップアップがあったことを証明できるプルーフ・オブ・ファンズ(ZK)を介して、消費者と預金者の間の接続を断ち切るために、どのリーフノードが消費されたかを誰も知ることができません。
要約すると、ParticleはAAアドレスと隠しアドレスを組み合わせ、スマートな隠しウォレットの形でプライベート転送を巧みに実現します。
パーティクルチェーンとフルチェーンアカウントの抽象化
Particle Chainは、Omnichain Account Abstraction用に設計されたPOSチェーンです。 現在の状況と将来に焦点を当てると、シングルチェーンの世界になることは不可能であり、マルチチェーンの作業環境でのユーザーエクスペリエンスを向上させることが重要です。
**現在ERC4337アカウント抽象化システムは、マルチチェーンの場合、特定の問題を抱えています。
異なるチェーン内の同じユーザーのアドレスは、コントラクトの設計によっては統一されない場合があります。
ユーザーは、管理者の変更など、異なるチェーン上のコントラクトウォレットを管理するために、複数のチェーン間で管理操作を手動で繰り返す必要があります。 さらに悪いことに、1つのチェーンで管理者権限が更新され、古い管理者認証方法が破棄された場合、ウォレットは他のチェーンで変更できません。
異なるチェーンを使用するには、各チェーンにガスコインを持っているか、各チェーンのPaymasterに資金を事前に入金する必要があります。 また、開発者にとってもある程度のトラブルがあり、ユーザーが特定の条件下で他の機能をゼロコストで使用または実装したい場合は、各チェーンに独自のカスタムPaymasterをデプロイし、そこに資金を入金する必要があります。
**Particle Chainのフルチェーンアカウントの抽象化は、上記の問題点に対処します。
Particle ChainでAAウォレットを構築します。
LayerZeroなどのAMB(Arbitrary Message Bridge)クロスチェーンプロトコルを介して、新規作成、アップグレード、権限の変更などのさまざまな操作が他のチェーンに同期されます。 **チェーン上の他のウォレットはチェーン上のウォレットへの参照であり、すべてのウォレットに同期するには本体のみを変更する必要があることを理解できます。
**Deployer コントラクトは、各チェーンのウォレットアドレスが同じであることを保証するために、一貫したパラメーターを使用します。 **
チェーン間のウォレットは、AMBを介して相互に呼び出すこともできますが、そのすべてがパーティクルチェーンから開始されるわけではありません。
**フルチェーンのガスコインであるUnified Gas Tokenの発行。 **ERC20は、Paymasterメカニズムによってガス料金として実装されています。 特定のチェーンにガスやPaymasterが事前に入金した資金がない場合でも、適格なチェーンでクロスチェーン取引を開始して、Unified Gas Tokenを消費することができます。
上記の用途に加えて、Particle Chain は将来的にも使用される可能性があります。
zkWaaSのProof and Saltによって生成された分散型ネットワーク。
各チェーンBundlerのインセンティブレイヤーは、Bundlerがより良い分散化を実現するのに役立ちます。
インテント フュージョン プロトコルとしてのソルバー ネットワーク。
**Particle Chainの物語では、Unified Gas Tokenはエコシステム全体のコアバリューを把握しています。
ガス料金を支払う機能は、暗号で繰り返し検証されている強力な需要と価値のキャプチャロジックです。
Unified Gas Tokenは、既存のパブリックチェーンの生態学からガス層の概念を抽象化しており、この抽象化はParticle Chainとウォレットなしでは達成できないため、Unified Gas TokenはParticleの生態学全体の価値の引き出しです。 ガス層では、各チェーンのユーザーインタラクションと成長、および現地通貨の価値が相互に有益であり、Unified Gas Tokenと共生しています。
ユニファイドガスもチェーンレス実現の原動力の1つです。 ユーザーにとっては、単一通貨で支払うことで、プロセスが大幅に簡素化され、コストが理解されます。 将来的には、マルチチェーンのシナリオでも、ユーザーは鈍感になる可能性が高く、基盤となるインフラストラクチャの運用を気にする必要がなくなります。 現在のWeb2のように、コンピュータールームがどの地域にあるか、どのような構成であるか、どの言語が使用されているか、どのデータベースが機能しているかは気にしません。
dAppによってインポートされたユーザーは、Unified Gas Tokenに直接権限を与え、使用シナリオは非常に豊富です。
インテントフュージョンプロトコル
**通常、さまざまなdAppsを使用する際には、使用経路について常に考える必要があります。
1つのDEXに流動性がない場合は、別のDEXを検討する必要があります。
トランザクションまたはトランザクションをより適切に完了するために、同じカテゴリのどのdAppを選択すべきかわかりません。
· 承認には多くの機能があり、承認とは何ですか?
ウォレットのほこりを払ったり、複数の小さなトークンを特定の通貨にしたり、プロセスは面倒です。
最終目標を達成するには、複数のアプリケーションが必要です。 ハイレバレッジレンディングなど:スワップ、質入れ、借り入れ、トークンの取得、スワップ、質入れ、借入…
上記は現在のDeFiの世界では氷山の一角に過ぎず、dAppsが多様化するWeb3の大量導入の時代には、インタラクションは想像以上に複雑になる可能性があります。
したがって、特定の操作ステップをインテントインテントに置き換えると、ユーザーエクスペリエンスが大きく異なる可能性があります。 インテントは、関数型プログラミングに対する宣言型プログラミングと同様に、操作以上のものです。 宣言文は単純明快に感じられがちで、何をするかを宣言するだけで、詳細は気にせず、そのためには、下部にカプセル化されたさまざまな関数型プログラミング ステートメントが必要です。
インテントの使用も例外ではなく、さまざまなファシリティでサポートする必要があります。 プロセス全体を見てみましょう。
**1. ユーザーは、自然言語などのRFS(Request For Solver)の形式でソルバーネットワークに送信します。 **ソルバーはインテントのインタープリターであり、1inchのようにユーザーに最適なデックスを見つけることができるアグリゲーターもありますが、私たちのビジョンと比較すると、汎用的で強力ではありません。
**2. 複数のソルバーが互いに応答し、競合しています。 これらのレスポンスは Intent DSL 言語で記述され、クライアントによって解析されて、ユーザーが理解しやすい形式になります。 これらの応答は、入力と出力の境界を定義する入力制約と出力制約で構成されます。 ユーザーは、独自の制約を指定することもできます。 理解するための簡単な例:スワップを使用すると、ユーザーはスワップ後に取得できる最小量を求められますが、これは制約です。 ユーザーは、複数のソルバーの応答の中から自分で選択します。
**4.ソルバーは、特定の実行コントラクトを指定し、そのインテントをレスポンスコントラクトReactorに提出します。 **
このプロセスは、ChatGPTに要件を伝えると、要件がどんなに複雑であっても、ChatGPTは最終結果を生成でき、結果に満足している限り、プロセスを気にせずに直接使用できます。
まとめ
Particle Networkは、zkWaaS、Particle Chain、Intent Fusion Protocolの三位一体により、Web2 OAuthプライバシーログイン、プライベートトランザクション、フルチェーンアカウント抽象化、インテントトランザクションパラダイムを実現する包括的なソリューションを提案します。 各機能は、Web3の使用におけるいくつかの問題点をカバーし、これらの進歩と最適化は、将来的にWeb3を大量に採用するための製品と技術の基盤となるでしょう。 エコロジーとビジネスモデルの面では、B2B2Cパラダイムを採用し、WaaSを入り口としてプロダクトチェーン全体の大規模な標準化を推進し、dApp開発者とエコシステムを構築して、ユーザーにとって敷居が低く、エクスペリエンスの高いWeb3の世界を共同で作り上げます。
もちろん、Web3の大量導入の実装パスに対する理解は、プロジェクトによって異なります。 具体的なプロジェクトの振り返りに加え、Web3が現在直面している船上での摩擦の理解や、ユーザーのニーズやペインポイントの反省、エコシステム全体の共同接続や発展への配慮につなげていきたいと考えています。