技術解説：Particle Networkが構築するOpen Webのアクセスレイヤー
TechFlow厳選深潮セレクト
技術解説：Particle Networkが構築するOpen Webのアクセスレイヤー
Particle Networkを例に、現在のWeb3製品が抱えるユーザーエクスペリエンス上の課題を詳細に分析し、それに対する包括的な技術的ソリューションの設計方法について解説する。
Web3業界の深掘り報道に専念し潮流を洞察執筆：霧月、Geek Web3
導入：アカウント抽象（AA）ウォレットはユーザーの利用ハードルを大幅に下げ、gas手数料の代行支払いとWeb2アカウントでのログインという初期目標をある程度達成している。しかし、プライベートログイン・プライベート取引、全チェーン統一AAアカウント、Intent専用アーキテクチャなど、mass adoption に直結する設計は、依然としてAAの上に追加的な構築が必要である。
ZenGoのようなMPCウォレットやArgentのようなスマートコントラクト型ウォレットなど、UX最適化のソリューションは多数存在し、確かにユーザーの参入障壁を下げているが、これらは前述の課題の一部しか解決しておらず、製品の使いやすさに関する問題を包括的にカバーできていない。
明らかに、現時点のほとんどのAAウォレットまたは類似製品は、Web3の大規模採用をサポートできる段階には至っていない。また、エコシステムの観点から見ると、開発者側の支援は極めて重要であり、一般ユーザーにとって魅力的でも、開発者側に影響力がなければスケールは難しい。最近では開発体験の最適化ソリューションが増加しており、開発者サイドが製品エコシステムに与える重要性が示されている。
本稿ではParticle Networkを例に取り、現在のWeb3製品が抱える体験上の課題と、それに対応する包括的な技術的ソリューションの設計方法について詳しく解説する。こうした包括的ソリューションこそが、mass adoption 実現のための必要条件かもしれない。同時に、ParticleのBtoBtoCビジネス戦略は、多くのプロジェクトが学ぶべきモデルでもある。
Particle 製品構造の全貌
Particle Networkは、利用ハードルの低減を核とし、B2B2Cの製品構築とエコシステム発展の視点から、Web3の大規模採用に向けた包括的ソリューションを提示している。その中核モジュールは以下の3つである：
zkWaaS：ゼロナレッジ証明を活用したWaaS（Wallet-as-a-Service）サービス。開発者はParticleが提供するSDKを利用して、スマートウォレット機能を自らのdAppに迅速に統合できる。このウォレットはアカウント抽象に基づくキーレスなスマートコントラクトウォレットであり、gas手数料の代行支払いといった基本的なAA機能に加え、Web2方式のOAuthによるプライベートログインやプライベート取引も可能にする。
Particle Chain——Particle専用の全チェーンアカウント抽象（Omnichain Account Abstraction）ソリューション。スマートコントラクトウォレットのクロスチェーン展開、維持管理、呼び出しの問題を解決する。これに付随する「ユニファイドガストークン（Unified Gas Token）」は、複数チェーンで異なるgas通貨を使う煩雑さを解消する。
Intent Fusion Protocol：簡潔なDSL（ドメイン固有言語）、Intentフレームワーク、Intent Solver Networkなどを含み、ユーザーの「意図（Intent）」に基づくWeb3インタラクションフレームワークを構築する。ユーザーは個々の操作ではなく、自分の取引意図を直接宣言することで、煩雑な経路選定から解放され、複雑なインフラ知識の理解負担を軽減できる。
zkWaaS——ZKを組み合わせたスマートウォレット即サービス
ウォレット側において、Particleは主にWaaS（スマートコントラクトウォレット即サービス）の形でdApp開発者にSDKを提供し、開発者がその包括的なWeb3 mass adoption フレームワークに接続できるようにしている。このようなBtoBtoCモデルは、ビジネスおよびエコシステムの観点から以下のような利点を持つ：
C向けウォレット市場の競争はすでに激化しており、機能も類似化しているため、C向けウォレットはもはや良い入り口ではない。一方で、dApp開発者は自らのアプリ内にウォレットを内蔵することを好む傾向にある。これは、ユーザーが外部ウォレットに接続したり、取引時に切り替えたりする手間を避け、カスタマイズ性を高めるためである。
C向けの顧客獲得コストは非常に高くつくが、B向けは異なる。WaaSのユーザーグロースは、SDKを統合したdAppの普及に依存する。BD（ビジネスデベロップメント）と開発者関係をしっかり構築すれば、「都市から農村を包囲する」ようなエコシステム拡大が可能になる。
現状のC向けウォレットは主に金融・資産管理に集中しており、これが将来のWeb3の主要シナリオとは言い難い。真にWeb3の大規模採用を実現するには、ユーザーのアイデンティティ（アカウント）や操作（トランザクション送信）といった基盤的機能を抽象化し、下層サービスとして提供し、上層の豊かなシナリオをdApp側に委ねる必要がある。
従来のdApp接続インターフェースを見ると、ウォレットとdAppの間に強いバインド関係があることがわかる。dApp側でウォレットのシェアを高めることは極めて重要であり、B2B2Cモデルにとっては近水楼台の利点がある。
ユーザーのニーズに応え、利用ハードルを下げ、開発者が容易に統合可能なWaaSを構築することが、成功のもう一つの柱となる。ParticleのzkWaaSには3つの核心がある：
1. プライベートログイン。スマートコントラクトウォレット上でTwitter、Google、WeChatなどのWeb2ログイン方式（OAuth）を利用し、ユーザーが秘密鍵管理から完全に解放され、最も親しみやすい方法でWeb3に入る。さらに、ゼロナレッジ証明によりユーザーの身元を隠蔽する。
2. プライベート取引。スマートステルスアドレス（Smart Stealth Address）メカニズムにより、P2P形式の汎用的なプライベート送金を実現。ERC4337のPaymasterを用いて、ステルスアドレスがgasなしで資産を使用できるようにする（gasスポンサー）。
3. 充実したAAウォレット機能。ParticleのウォレットモジュールはERC-4337の基本要件を完全に満たしており、Bundler、EntryPoint、Paymaster、Smart Wallet Accountなど、ERC-4337ワークフローの重要なコンポーネントを備え、dAppやユーザーのスマートウォレットニーズをワンストップで満たす。
Web2アカウントに基づくオンチェーンウォレットのプライベートログイン
ParticleのプライベートログインソリューションはJWT（Json Web Token）を活用し、コントラクト内でWeb2の身元認証とウォレット操作を可能にする。
JWTは従来のインターネットで広く使われる、サーバーがクライアントに発行する身分証明書である。クライアントはサーバーとのやり取りのたびにこの証明書を使って身元を確認する。
（画像出典：FlutterFlow Docs）
JWTには、コントラクトが身元を検証する基礎となる重要なフィールドがある：
-
「iss」（Issuer）：JWTの発行者、つまりサーバー（Google、Twitterなど）を示す。
-
「aud」（Audience）：そのJWTが使用されるサービスやアプリを示す。例えば、MediumにTwitterでログインする場合、Twitterが発行するJWTのこのフィールドには「Medium」と記載される。
-
「sub」（Subject）：JWTを受け取るユーザーの身元（通常はUIDで表される）。
実際には、issとsubはほとんど変更されず、そうでなければ内部システムや外部参照に大きな混乱をきたす。そのため、これらのパラメータを用いてコントラクトがユーザーの身元を特定できる。これにより、ユーザーは秘密鍵を生成・保管する必要が全くなくなる。
JWTに対応する概念がJWK（JSON Web Key）であり、これはサーバーの鍵ペアのセットである。サーバーはJWTを発行する際にJWKの秘密鍵で署名し、対応する公開鍵は公開され、他のサービスが署名を検証するために使う。
例えば、MediumがTwitterでログインする際、MediumはGoogleが公開するJWKの公開鍵を使ってJWTの署名を検証し、それが実際にGoogleが発行したものであることを確認する。コントラクトでのJWT検証も同様にJWKを利用する。
Particleのプライベートログインの流れは以下の通りである：
ここでは具体的なZK回路の詳細は割愛し、プロセスの要点を列挙する：
-
ログイン情報を検証するVerifierコントラクトは、ユーザー身元（JWT）に関連するZK Proofと無害なeph_pkしか認識せず、対応するウォレット公開鍵やJWT情報そのものを知ることができない。これによりユーザーのプライバシーが保護され、オンチェーンデータからログイン者の身元を特定できない。
-
eph_pk（一時鍵ペア）は単一セッションで使用されるもので、ウォレットの鍵ペアではないため、ユーザーは気にする必要がない。
-
このシステムはオフチェーン検証にも対応でき、MPCなどのロジックを持つコントラクトウォレットにも適用可能。
これは本当に従来のログイン方式に基づくコントラクト検証であり、ユーザーは他のソーシャルアカウントを「ガーディアン」として指定でき、Web2アカウントが停止されるような極端なケースにも備えられる。
DH鍵交換方式に基づくプライベート取引
Particleのプライベート取引ソリューションを議論する前に、既存のEVM体系内で受取人のプライバシーを守る方法、つまり受取人のアドレスを隠す方法をまず考察しよう。
Aliceを送信者、Bobを受取人とし、双方はある共通知識を持っているとする：
1. Bobはルート消費秘密鍵（root spending key）mとステルスメタアドレス（stealth meta-address）Mを生成する。Mはmから生成され、M = G * mという暗号学的演算関係を持つ。
2. Aliceは任意の手段でBobのステルスメタアドレスMを取得する。
3. Aliceは一時秘密鍵rを生成し、アルゴリズムgenerate_address(r,M)を用いてステルスアドレスAを生成する。このアドレスはBob専用のステルスアドレスであり、Bobは資産受領後にその支配権を持つ。
4. Aliceは一時秘密鍵rから一時公開鍵Rを生成し、それを一時公開鍵記録コントラクト（または双方が認める任意の場所）に送信する。
5. Bobは定期的に一時公開鍵記録コントラクトをスキャンし、更新された一時公開鍵を記録する。このコントラクトは公開されているため、他人のプライベート取引に関連する鍵も含まれており、BobはどれがAliceからのものかまだわからない。
6. Bobは各更新レコードをスキャンし、generate_address(R,m)を実行してステルスアドレスを計算する。もしアドレスに資産があれば、それはAliceが生成しBobに制御を許可したものであり、なければ無関係である。
7. Bobはgenerate_spending_key(R,m)を実行し、ステルスアドレスの消費秘密鍵p = m + hash(A)を生成し、その後Aliceが生成したアドレスAを制御できるようになる。
上記のプロセスは複雑な数学的演算を大幅に簡略化している。この情報交換プロセスは、まるで二人のスパイが公共の掲示板に、自分たちにしか解読できない暗号文を書き込むようなものである。暗号の生成・解読方法は公開されていても、二人にしか分からない重要なデータがあるため、第三者が方法を知っても解読できない。
この交換プロセスは有名なDiffie-Hellman鍵交換法とほぼ同じであり、お互いの秘密（Bobのルート消費鍵mとAliceの一時鍵r）を明かさずに、双方が共有秘密——上記のステルスアドレスAを計算できる。 DH交換を知らない場合は、以下の色分け図で比喩的に理解できる。
DHとの違いは、共有秘密（ステルスアドレスA）をそのまま秘密鍵として使えない点である。なぜならAliceもAを知っているため。そこで消費秘密鍵p = m + hash(A)を構成し、Aを公開鍵として扱う。前述の通りルート消費鍵mはBobだけが知っているため、Bobがそのステルスアドレスの唯一の支配者となる。
この方式によるプライベート送金では、受取人が新しい取引ごとに資金が流入する新たなEOAアドレスを得ることになる。受取人は保持するルート消費鍵で、各アドレスの消費鍵を計算し、どれが自分に関係するかを「運試し」で確かめる。
しかし、まだ問題がある。新しく生成されたステルスアドレスは最初EOAアカウントであり、ETHなどのgas通貨を持っていない可能性があり、Bobは直接トランザクションを送れない。これを解決するには、スマートコントラクトウォレットのPaymaster機能によるgas代行支払いが必要となり、プライベート取引が可能になる。したがって、受取アドレスに対して以下の修正が必要である：
CREATE2によるコントラクト展開時のアドレス計算方法を用い、必要なパラメータ（ステルスアドレスAを所有者とするなど）を付けてCounterfactualアドレスを計算する。これは計算されたコントラクトアドレスだが、まだ展開されていないため、一時的にはEOAとして存在する。
AliceはこのCounterfactualアドレスに直接送金する。Bobが使用する際は、このアドレス上でコントラクトウォレットを作成すれば、gas代行サービスを呼び出せる（このステップはAliceまたはParticleネットワークが事前に行うことも可能）。
上記のCounterfactualアドレスを「スマートステルスアドレス」と呼べる。Bobは以下の手順で、スマートステルスアドレス内の資産を匿名で利用できる：
任意のアドレスからPaymasterに充電し、Paymasterは資金証明（ZK化）を返却する。
AAメカニズムにより、残高ゼロの任意アドレスからBundlerノードにUserOperationを送信し、上記ステルスアドレスの資産を呼び出す。Bobは新しいアドレスでPaymasterに資金証明を提供すれば、PaymasterがBundlerの取引手数料を支払う。
これはTornado Cashと類似した動作原理であり、資金証明（ZK化）により、Merkleツリーの葉ノード集合にかつて充電があったことを証明できるが、支出時にどの葉ノードの資金を使ったかは誰にもわからない。これにより支出者と充電者の関係が断ち切られる。
以上のように、ParticleはAAとステルスアドレスを巧みに組み合わせ、スマートステルスウォレットを通じてプライベート送金を実現している。
Particle Chain & 全チェーンアカウント抽象
Particle Chainは、全チェーンアカウント抽象（Omnichain Account Abstraction）を目的としたPoSチェーンである。現状および将来を見据えると、単一チェーンが支配する世界ではなく、マルチチェーン環境でのユーザー体験向上が極めて重要である。
現状、ERC4337アカウント抽象システムはマルチチェーン環境で以下のような問題を引き起こす：
-
同じユーザーが異なるチェーンで持つアドレスが統一されない可能性がある（コントラクト設計による）。
-
ユーザーが複数チェーンのコントラクトウォレットを管理するには、各チェーンで手動で管理操作（管理者変更など）を行う必要がある。最悪の場合、あるチェーンで管理者権限を更新し古い認証方法を破棄すると、他のチェーンでは変更も使用もできなくなる。
-
異なるチェーンを使用するには、それぞれのgas通貨が必要、または各チェーンのPaymasterに前払い資金が必要。開発者にとっても面倒で、ユーザーに無償利用させたい場合、各チェーンに独自のPaymasterを展開し、資金を前払いしなければならない。
Particle Chainの全チェーンアカウント抽象は、これらの痛点に直接対処する：
-
Particle Chain上でAAウォレットを構築する。
-
LayerZeroなどのAMB（Arbitrary Message Bridge）クロスチェーンプロトコルを用い、新規作成・アップグレード・権限変更などの操作を他のチェーンに同期する。他のチェーンのウォレットはすべて本体の参照と見なせ、本体を変更すればすべてのウォレットに反映される。
-
一貫したパラメータのDeployer Contractにより、各チェーンのウォレットアドレスを同一に保つ。
-
各チェーンのウォレットはAMBを通じて相互に呼び出し可能で、必ずしもParticle Chainから開始する必要はない。
-
ユニファイドガストークン（Unified Gas Token）を発行し、全チェーン共通のgas通貨とする。Paymasterメカニズムにより、ERC20トークンでgas手数料を支払える。特定のチェーンにgasやPaymasterの前払い資金がなくても、条件を満たすチェーンでクロスチェーン取引を行い、Unified Gas Tokenを消費できる。
上記以外にも、Particle Chainは将来的に以下のような用途にも使えるかもしれない：
-
zkWaaSのProofおよびSalt生成のための分散ネットワーク。
-
各チェーンのBundlerに対するインセンティブ層として、より分散化されたBundlerを支援。
-
Intent Fusion ProtocolのSolverネットワークとして機能。
Particle Chainの物語の中で、Unified Gas Tokenはエコシステム全体の価値の中心となる：
-
gas手数料の支払いは、cryptoで繰り返し検証された強力な需要と価値捕捉ロジックである。
-
Unified Gas Tokenは既存のパブリックチェーンエコシステムからgas層という概念をさらに抽象化する。この抽象化は、Particle Chainとウォレットなしには実現できず、Unified Gas TokenはParticleエコシステム全体の価値の体現である。gas層ができることで、各チェーンのユーザーインタラクション・成長および自社トークンの価値は、Unified Gas Tokenと相互に利益を補完する関係になる。
-
統一gasはChainlessの推進要因の一つでもある。ユーザーにとって、単一通貨での支払いは利用フローと理解コストを大幅に簡素化する。将来マルチチェーン環境でもユーザーは無自覚になり、インフラの動作状況を気にする必要がなくなる。ちょうど現在のWeb2で、サーバーと通信する際にデータセンターの位置や構成、使用言語・データベースなどを気にしないのと同じである。
-
dAppが導入するユーザーが直接Unified Gas Tokenに価値を与えるため、使用シーンが非常に豊富。
Intent Fusion Protocol
通常、さまざまなdAppを使う際、ユーザーは常に使用経路を考えなければならない：
-
DEXに流動性がない場合、別のDEXを調べる必要がある。
-
同種のdAppのうち、どのサービスが取引をより良く実行できるかわからない。
-
多くの機能を使うにはApproveが必要だが、Approveとは何か？
-
ウォレットのダスト掃除、複数の少量トークンを一種類に変換するプロセスは煩雑。
-
最終目標を達成するには複数のアプリを経由。例えば高レバレッジ貸借：swap→担保預け入れ→借り入れ→得たトークンを再びswap→担保預け入れ→借り入れ……
上記は現在のDeFi世界のごく一部にすぎず、dAppがますます多様化するWeb3大規模採用時代には、インタラクションの複雑さは想像を絶するだろう。
したがって、具体的な操作手順ではなく「意図（Intent）」を使うことで、ユーザー体験は雲泥の差となる。意図と操作の違いは、宣言型プログラミングと関数型プログラミングの違いに似る。宣言型は簡潔で明瞭で、「何をするか」を宣言するだけで細部を気にせず済むが、その裏には関数型の命令群が多重にカプセル化されている。
Intentの使用も同様に、一連のインフラ支援が必要である。以下に全体の流れを見てみよう：
1. ユーザーは自然言語などで自分の意図を表現し、RFS（Request For Solver）としてSolverネットワークに提出する。Solverは意図の解釈器であり、現在の代表例は1inchなどのアグリゲーターだが、理想に比べれば汎用性・強力さに欠ける。
2. 複数のSolverが応答し、互いに競争関係にある。これらの応答はIntent DSLで記述され、クライアントがユーザーに理解しやすい形に解析する。応答にはInput ConstraintsとOutput Constraintsが含まれ、入出力の範囲を定義する。ユーザー自身も制約を指定可能。簡単な例：Swap時に「最低取得数量」を表示するのは一種の制約である。ユーザーは複数のSolverの応答から選択する。
3. Intentに署名する。
4. Solverは特定の実行コントラクトExecutorを指定し、Intentを応答コントラクトReactorに提出する。
5. Reactorはユーザーのアカウントから必要な入力（ある資産など）を収集し、ExecutorにIntentを渡す。Executorは関連ロジックコントラクトを呼び出した後、取引結果をReactorに返す。Reactorは制約をチェックし、問題なければ出力をユーザーに返す。
このプロセスは、複雑な要望をChatGPTに話すのに似ている。どんなに複雑な要求でも、最終的な結果を生成してくれ、結果に満足すれば過程を気にせず使える。
まとめ
Particle Networkは、zkWaaS、Particle Chain、Intent Fusion Protocolという三位一体の包括的ソリューションにより、Web2 OAuthによるプライベートログイン、プライベート取引、全チェーンアカウント抽象、意図型取引という新しいパラダイムを実現した。各機能はWeb3利用における部分的な課題を解決し、これらの進歩と最適化は今後のWeb3大規模採用の製品・技術的基盤となる。エコシステムおよびビジネスモデルではB2B2Cを採用し、WaaSを入口として製品チェーンの規模化・標準化を推進し、dApp開発者と協働してエコシステムを構築、ユーザーに低ハードルかつ高体験のWeb3世界を提供する。
もちろん、異なるプロジェクトがWeb3 mass adoption を実現する道筋への理解はさまざまである。特定のプロジェクトを評価するだけでなく、さまざまなソリューションを通じて、Web3が現在直面するonboard friction、ユーザーのニーズと痛点、そしてエコシステム全体の連携発展についての考察を深めてほしい。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@godrealmx
