以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題



我們將以Particle Network為例,詳解目前Web3產品在體驗上的問題,以及如何針對性地設計一套綜合的技術解決方案,而這種綜合解決方案可能正是mass adoption的必要條件。

作者:霧月,極客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大規模採用提出了一整套解決方案。其核心模組為三個:

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图1

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模式而言是近水樓台先得月的。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图3

建構一套能滿足使用者需求,降低使用門檻,易於開發者存取的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或用戶對智慧錢包的功能需求。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图5

基於web2帳號的鏈上錢包隱私登入

Particle的隱私登入方案利用了JWT(Json Web Token),可以在合約內進行Web2身份認證和操作錢包。

JWT是一種廣泛運用於傳統互聯網中的,由服務端向客戶端發放的身份證明,客戶端在每次與服務端交互時憑藉此證明來進行身份認證。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图7

在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的隱私登入方案流程如下圖所示:

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图9

其中具體的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

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图11

上面的流程描述其實簡化了很多複雜的數學運算,整個情報交換過程,就好比兩個特務在公用的公告板上,寫下一些只有彼此才能破解的暗語,暗語的生成與解密方法雖然是公開的,但只有兩個特務知道中間必需的重要數據,所以外界就算知道暗語的生成與解密方法,還是無法順利解密。

這個交換流程與著名的Diffie–Hellman秘鑰交換方法大致相同,在不透露各自的秘密(Bob的根消費私鑰m和Alice的臨時私鑰r)的情況下,雙方都可以計算出共享秘密— —上文中的匿蹤地址A。如果對DH交換不了解可以用下面的染色圖進行比喻式的理解。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图13

相比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網路代勞前置完成)。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图15

我們可以把上述的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。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图17

除了上述用途外,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賦能,使用場景非常豐富。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图19

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檢查約束,若無誤則將輸出回饋給使用者。

以未向財經rticle Network為例,技術解讀目前Web3產品在體驗上的問題插图21

我們可以把這個過程想像為你將需求講給ChatGPT聽,不論多複雜的需求,他都可以給你產生一個最終的結果,只要你對結果滿意就可以直接使用,而無需關心其中的過程。

總結

Particle Network提出了一個全方位解決方案:透過zkWaaS、Particle Chain、Intent Fusion Protocol三位一體式的綜合形態,實現了Web2 OAuth隱私登錄,隱私交易,全鍊帳戶抽象化和意圖交易範式。每個feature都將涵蓋Web3使用的一部分痛點,這些進步與優化將成為日後Web3大規模採用的產品和技術基礎。在生態與商業模式上,採用B2B2C範式,以WaaS為入口帶動整個產品鏈條規模化標準化,與dApp開發者共建生態,共同為用戶打造一個低門檻高體驗的Web3世界。

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

聯系郵箱:0xniumao@gmail.com