技術解讀：Particle Network 構建的 Access Layer of Open Web

以Particle Network為例，詳解目前Web3產品在體驗上的問題，以及如何針對性地設計一套綜合的技術解決方案。

撰文：霧月，極客 Web3

導語：雖然 AA 錢包在很大程度上降低了用戶使用門檻，初步實現了 gas 代付與 web2 賬戶登錄，但隱私登錄 – 隱私交易、全鏈統一 AA 賬戶、Intent 專用架構等與 mass adoption 相關的設計，仍然要在 AA 的基礎上添磚加瓦。

我們雖然能見到很多 UX 優化方案，如 ZenGo 等 MPC 錢包或 Argent 這種智慧合約 wallet，有效的降低了用戶門檻，但他們只解決了上述問題中的一部分，而沒有全方位覆蓋產品易用性問題。

顯然，目前大多數 AA 錢包或者類似產品，還無法支持 Web3 大規模採用。另一方面，從生態角度考量，開發者側是非常重要的層面，僅僅在產品上對普通用戶有吸引力，但在開發者側影響力不夠，很難形成規模。越來越多開發體驗優化方案的湧現，已經說明開發者端對於產品生態的重要意義。

我們將以 Particle Network 為例，詳解目前 Web3 產品在體驗上的問題，以及如何針對性地設計一套綜合的技術解決方案，而這種綜合解決方案可能正是 mass adoption 的必要條件。同時，Particle 的 BtoBtoC 商業策略，恰好也是許多專案方需要學習借鑑的思路。

Particle 產品結構全解

Particle Network 以解決使用門檻為核心，用 B2B2C 的產品構建與生態發展思路，針對 Web3 大規模採用提出了一整套解決方案。其核心模塊為三個：

zkWaaS，基於零知識證明的 WaaS(Wallet-as-a-service) 服務。開發者可以基於 Particle 提供的 SDK，快速將智慧錢包模塊集成至自己的 dApp 內。該錢包是基於賬戶抽象的 keyless 智慧合約錢包，不但可以實現 gas 代付等 AA 基本場景，還可以提供 Web2 式的 OAuth 隱私登錄方式以及隱私交易等功能。

Particle Chain——專門用於 Particle 的全鏈賬戶抽象（Omnichain Account Abstraction）方案，致力於解決智慧合約錢包的跨鏈部署、維護和調用問題。配套的還有通用 gas 代幣（Unified Gas Token），用以解決多鏈交易時需要用到不同 gas 幣種的麻煩。

Intent Fusion Protocol，包含了簡潔的 DSL（Domain Specific Language）語言，Intent 框架，Intent Solver Network 等，用以構建一套基於意圖 (Intent) 的 Web3 交互框架，用戶直接聲明自己的交易意圖而非去執行每一條具體的操作，使用戶擺脫繁瑣的路徑思考，並減少對複雜底層基礎設施的理解。

zkWaaS——結合 ZK 的智慧錢包即服務

在錢包側，Particle 主要以 WaaS（智慧合約錢包即服務）的形式來為 dApp 開發者提供 SDK，以期讓開發者接入其完整的 Web3 mass adoption 框架。這種 BtoBtoC 方案從商業和生態角度看有幾個優點：

單純的 C 端錢包競爭已經白熱化，功能也較為雷同，C 端錢包不再是一個好的切入點。另一方面，dApp 開發者也開始越來越傾向於在 dApp 內內置錢包，以避免用戶連接錢包、交易時需要到切換錢包等步驟的體驗損耗，並提供更多可自定義的功能。

C 端的獲客成本高昂，但 B 端卻不同。WaaS 的用戶增長主要源於集成了 SDK 的 dApp。只要做好 BD 與開發者關係，就能「城市包圍農村」式的擴展整個生態。

目前 C 端錢包主要專注於金融與資產，我們很難說這就是未來 Web3 的主要場景。真正要實現 Web3 的大規模採用，必須有專案將更基礎的特性——用戶身分（賬戶）和用戶操作（發送事務 / 交易），抽象出來作為一個底層服務，將上層更豐富的場景交由 dApp。

從以往的 dApp 連接入口，大家可以觀察到錢包和 dApp 之間較為緊密的綁定關係。在 dApp 端盡可能提高錢包的市佔率，是非常關鍵的。這一點對 B2B2C 模式而言是近水樓臺先得月的。

構建一套能滿足用戶需求，降低使用門檻，易於開發者接入的 WaaS 則是方案成功的另一個支柱。Particle 的 zkWaaS 有三個核心：

1.隱私登錄。在合約錢包上利用傳統 Web2 的登錄方式，如 Twitter、Google、微信登錄等 OAuth 驗證方式，讓用戶完全擺脫私鑰管理的桎梏，以最熟悉和簡單的方式進入 Web3。同時利用零知識證明將用戶身分隱藏。

2.隱私交易。通過智慧匿蹤地址 (Smart Stealth Address) 機制實現點對點的通用性隱私轉賬，並使用 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 時此欄位會寫明該 JWT 適用於 Medium。

• 「sub」 (Subject) ，指的就是接受該 JWT 的用戶身分，一般用 UID 標示。

在實踐中，iss 和 sub 在絕大多數情況下都不會變，否則會帶來內部系統和外部引用的巨大混亂。因此，上述這些參數可用於合約確定用戶身分，這樣用戶完全無需生成和保管私鑰。

與 JWT 相對應的概念是 JWK(JSON Web Key)，它是服務端的一組密鑰對。服務端在發放 JWT 的時候會用 JWK 的私鑰簽名，而對應的公鑰是公開的，用於給其他服務驗證其簽名。

比如，在 Medium 使用 Twitter 登錄，Medium 會對 JWT 用 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，並將其發送至臨時公鑰記錄合約（或者是任何雙方認可的位置，不管什麼渠道只要 Bob 可以獲取即可）。

5.Bob 需要定期掃描臨時公鑰記錄合約，記錄下更新的每一條臨時公鑰。由於臨時公鑰合約是公開的，包含了其他人發送的隱私交易相關密鑰，Bob 還不知道哪一條是 Alice 發給自己看的。

6.Bob 掃描每一條更新的記錄，執行generate_address(R,m)來計算匿蹤地址。如果該地址裡有資產，那就是 Alice 生成並授權給 Bob 去控制的，否則就和 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 設為該合約的 Owner 等），計算一個 Counterfactual 地址。這是一個計算出的合約地址，但尚未部署合約，暫時還是 EOA。

Alice 會直接向該 Counterfactual 地址轉賬。Bob 想使用時，就直接在該地址上進行合約錢包創建，這樣就可以調用 gas 代付服務（這一步也可以由 Alice 或 Particle 網路代勞前置完成）。

我們可以把上述的 Counterfactual 地址稱為智慧匿蹤地址。Bob 通過下列流程來匿名地使用該智慧匿蹤地址下的資產：

通過自己的任意地址向 Paymaster 儲值，Paymaster 會返還一個資金證明（ZK 化）。

憑藉 AA 機制，用其他任意地址（可以沒有餘額）向 Bundler 節點發送 UserOperation，調用上述匿蹤地址下的資產。Bob 只要用一個新地址向 Paymaster 提供資金證明，Paymaster 支付 Bundler 打包交易的費用。

這其實是類似 Tornado Cash 的工作原理，通過資金證明（ZK 化）既可以證明梅克爾樹上的葉子節點集合中曾經有一筆儲值，花費時任何人卻無法得知具體消耗了哪個葉子節點上的資金，以此切斷消費者和儲值者之間的聯繫。

綜上，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，質押，借貸，得到的 Token 再 swap，質押，借貸……

上述內容只是我們在目前的 DeFi 世界的冰山一角，而在 dApp 越來越多樣化的 Web3 大規模採用時代，交互複雜度可能遠超想像。

所以，用意圖 Intent 代替具體的操作步驟，對用戶而言體驗是天差地別的。意圖較之操作，就像聲明式編程之於函數式編程。聲明式的語句往往給人簡單明瞭的感覺，只需要聲明我要做什麼即可而不關心其後細節，而這需要底層有層層封裝的各種函數式編程語句。

那麼使用 Intent 也不例外，也需要有一系列設施的支持。我們可以從整個流程來看一下：

1.用戶提交將自己的意圖用某種方式描述，如自然語言等以 RFS(Request For Solver) 形式提交給 Solver 網路。Solver 是意圖的解釋器，目前常見的 Solver 有 1inch 等聚合器，可以為用戶尋找最優的 dex，但相比我們的願景而言它們並不夠通用和強大。

2.多個 Solver 給出回應，他們之間是競爭關係。這些回應由 Intent DSL 語言編寫，再由客戶端解析為易於用戶理解的形式。這些回應包含 Input Constraints 和 Output Constraints，界定了輸入和輸出的界限。用戶也可以自行指定約束。一個簡單的例子來理解：在使用 Swap 的時候會提示用戶 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 隱私登錄，隱私交易，全鏈賬戶抽象和意圖交易範式。每一個 feature 都將覆蓋 Web3 使用的一部分痛點，這些進步與優化將成為日後 Web3 大規模採用的產品和技術基礎。在生態和商業模式上，採用 B2B2C 範式，以 WaaS 為入口帶動整個產品鏈條規模化標準化，與 dApp 開發者共建生態，共同為用戶打造一個低門檻高體驗的 Web3 世界。

當然，不同的專案對 Web3 mass adoption 的實現路徑理解是不一樣的。除了對具體專案的審視，我們希望通過不同的方案引出對 Web3 目前面臨的 onboard friction 的理解，對用戶需求和痛點的思考，以及對整個生態共同串聯和發展的考量。