回顧2025年Web3錢包暗戰,各大玩家到底在卷什麼?

1. 前言

一轉眼,筆者已然在wallet賽道裡耕耘4年了。

很多人覺得2025年的錢包賽道已經固化,但事實並非如此——它正在暗流湧動,這一年裡:

  • Coinbase 新發布 CDP 錢包,底層基於 TEE 技術構建
  • Binance 的 MPC 錢包,將密鑰分片托管引入 TEE 環境
  • Bitget 上周剛發布社交登錄功能,底層由 TEE 托管
  • OKX Wallet 推出基於 TEE 的智能帳戶功能
  • MetaMask、Phantom 引入社交登錄,本質是密鑰分片加密存儲

雖然今年確實沒有出現什麼亮眼的新玩家,但現有玩家在生态定位和底層技術架構上已經發生翻天覆地的變化。

這種轉變源於上游生态的劇烈變化。

隨著 BTC 與銘文生态全面退潮,大量錢包開始以"入口"的新定位,承接 Perps(永續合約)、RWA(股票類)、CeDeFi(中心化與去中心化金融結合)等新興賽道。

這個轉變其實醞釀多年。

跟隨本文,讓我們深入理解那些在暗處盛開的花朵,以及它們對未來用戶的影響。

2 回顧錢包賽道的发展階段

錢包是區塊鏈行業中難得的剛需產品,也是除公鏈外率先突破千萬用戶的入口級應用。

2.1 第一階段:單鏈時代(2009-2022)

行業早期(2009-2017),錢包極難使用,甚至需要本地運行節點。這個階段我們直接跳過。

到了可用階段,自托管成為首選——畢竟在去中心化世界裡,"默認不信任"是生存基礎。MetaMask、Phantom、Trust Wallet、OKX Wallet 等等耳熟能詳的產品都是這一時期的佼佼者。

2017-2022年,市場迎來公鏈/L2 爆發期。雖然大多數鏈仍沿用以太坊的 EVM 架構,但做一個兼容的好工具已足夠滿足需求。

這個時期,錢包的核心定位是"好工具"。 雖然業內能看到流量入口、DEX 入口的商業遠景,但安全、好用、穩定才是第一要求。

然而 2023-2025年,形勢發生變化。

Solana、Aptos、BTC(銘文時期)等異構公鏈徹底佔據用戶市場。雖然 Sui 本身發展不錯,但黑客事件後,大資金因過度中心化的弊端而有所卻步。

在"胖協議、瘦應用"的融資時代驅動下,儘管 VC 們收益寥寥,但市場格局確實在改變。

2.2 第二階段:多鏈時代(2022-2024)

面對多鏈格局,強如 MetaMask 這樣的老牌玩家也不得不轉型,開始內置支持 Solana、BTC 等。OKX Wallet、Phantom 等頭部選手更是早早實現了多鏈兼容架構。

判斷是否多鏈兼容的核心標誌,是支持多少鏈,以及看交易從哪裡發出——這代表後台承擔了大量工作,客戶端只負責簽名。從用戶角度看,就是是否需要自己尋找 RPC 節點才能使用錢包。

如今,多鏈兼容幾乎成為標配。長期堅持單鏈很容易難以為繼,因為鏈的熱點在不斷變化。

典型案例是Keplr錢包,它專注 Cosmos 生态,但這個賽道始終未能起飛。許多基於 Cosmos 快速搭建的應用鏈,上線後也逐漸沉寂。隨著 EVM L2 構建門檻越來越低,單鏈錢包的處境或許會緩和,但上限也就在那裡了。

在基礎工具足夠好用之後,用戶開始在錢包中覺醒商業需求!

真正的資產所有者不僅要托管資產,還要主動驅動它——尋找最佳收益場所,選擇交互對象。但用戶也被各種 DApp 的交互複雜度折磨得夠呛,还得時刻提防釣魚網站。

既然如此,何不直接使用錢包內置功能?

2.3 业务角逐分支期

各家錢包的競爭焦點轉移到業務層面,典型的是聚合 DEX、聚合跨鏈橋。雖然 Coinbase 探索過集成社交功能,但這需求過於伪需求,始終不溫不火。

回歸剛需,用戶需要的是在一個錢包入口完成多鏈資產轉賬。這時,覆蓋面、速度、滑點成為核心競爭點。

DEX 領域還可以進一步延伸到衍生品交易:RWA(如股票代幣化)、Perps(永續合約)、預測市場(2025下半年火熱,畢竟2026年要舉辦世界杯)

與 DEX 並行的是 DeFi 收益需求。

畢竟鏈上 APY 會高於傳統金融:

  • 幣本位策略: ETH 質押約 4% APY,Solana 質押 + MEV 約 8% APY(詳情可見萬字研報:Solana上MEV的格局演進與是非功過),更激進的可以參與流動性池(LP)、跨鏈橋 LP。
  • 穩定幣策略:雖然收益相對較低,但結合循環槓桿操作可提升 APY。

所以到今年(2025),在業務角逐的巔峰期,錢包基礎架構同步再次迎來升級。

原因是上述交易太複雜了——不僅是交易結構的複雜性,更是交易生命周期的複雜性。

要獲得真正的高收益,需要結合自動化交易:動態調倉,定時限價單(而非僅支持市價單),定投、止損等高級功能。

但是這些功能在純自托管時代根本無法實現。

所以,是要完全的"安全至上"還是"盈利至上"?其實不是難題,因為市場本就有不同需求。

就像 Telegram Bot 横行時期,大量玩家交出私鑰換取自動交易機會——"怕就別玩,玩就別怕"的高風險模式。相比之下,大廠服務商做錢包就必須考慮品牌和口碑。

那有沒有既能安全托管私鑰,又能相對保障服務商不跑路的方案?

當然有!這就迎來了今年的底層托管技術升級。

3. 托管底層技術升級期

回歸到開局提到的行業底層技術升級,讓我們逐個分析

3.1 告別完全自托管時代

首先作為純錢包廠商的 Metamask、Phantom 的舉動相對輕量一些,更多是體驗驅動,因為社交登錄也只是在解決用戶跨設備、找回等需求場景的,並不是在完全切入具體的應用層賽道上。

但他們的轉變,其實是在一定程度上告別完全的自托管時代。

自托管是有程度區分的,但沒有人真正能定義什麼是完全,什麼是不完全。

首先,自托管本身是指用戶的私鑰只能存儲在用戶的設備上。但這點在過去已經有好多的問題了。

本地加密存儲的私鑰,如果設備被控制,就有爆破的可能性,強度依賴用戶的密碼。

在跨設備同步、備份保存的時候,總要複製出來,那麼操作系統的粘貼板權限就直接成了生死線。

記憶深刻的是某錢包廠商把複製私鑰這個頁面,只默認黏貼出前部分,剩餘幾位要用戶自己手打,這樣直接讓那段時間私鑰被盜案件反饋骤降90%以上。後來的黑客們學乖了,剩餘幾位也穷举爆破,變相又進入了對抗期。

在以太坊布拉格升級後,由於7702權限極高,簽名也很隱晦,甚至有全鏈影響的特殊性,又把permit 2 這樣的高釣魚風險激發了起來。

所以,自托管這件事,根源還是用戶並不能輕易習慣自己完全控制資產的行業背景。

畢竟私鑰在用戶那,這自然沒問題,如果留一份加密的私鑰在服務端,防止用戶本地設備丟失,資產就完全丟失的窘境。這還能算自托管嗎?

Metamask和Phantom給出的答案是,也算。但同時,也要防止服務方作惡。

3.2 先說Metamask

他的做法很簡單,用戶要登錄一個郵箱並且設置一個密碼,兩者結合形成一個叫TOPRF(Threshold Oblivious Pseudorandom Function 阈值不經意伪随机函数)的東西,用這個去加密了用戶的私鑰,被加密的私鑰自然可以備份。

然後這個TOPRF 通过典型SSS(Shamir Secret Sharing,秘密分享算法),分片分發出去。而這些社交登錄的服務商則會通過社交驗證得到加密數據,還要結合用戶的密碼才能完全解密。

所以安全風險不算完全沒有,畢竟弱密碼+郵箱盜號也是有風險的,而且用戶忘記密碼的話,也自然恢復不出來,但好處就是更便利了,體驗也基本和web2的一致。

3.3 在看Phantom

看圖的話整體架構複雜一些,但本質還是後端存儲加密的私鑰,分片管理用於加解密的密鑰。

與小狐狸的差別是用來加密的密鑰分成2份,他引入了另一個叫JuiceBox網絡的服務方存其中一份,必須要社交登錄+pin(4位)綜合起來才能使用其分片。

綜合看,用戶只需要郵箱不被盜,且pin不忘記,那就能隨時恢復。

當然極端情況下juiceBox與phantom串謀的話,也是能解密資產的,但起碼黑客的攻擊成本就從單點變多方了。而且,畢竟juicebox是個網絡,其安全設計也是會分擔多個驗證者上。

可以說,在社交恢復方面,這兩家是在恪守底線的情況下,做出一定妥協,但為了低概率事件就去壓制用戶體驗而言。

筆者認為是一個好的轉變,畢竟區塊鏈行業最需要的就是擁抱普通用戶,而不是逼著普通用戶都成為行業專家。

4. 采用可信技術環境 Tee 的自托管

前面的社交登錄其實只能解決恢復問題,但不能解決自動化交易的問題。

那為此每家的思路都有些不大一樣。

首先,科普下背景,Tee是可信計算環境(Trusted Execution Environments)的縮寫,它本質依舊是一種伺服器,但這個伺服器可以確保其內存環境、運行過程,是不能被讀取和干擾的,即使是aws服務商或者伺服器的擁有者。

另外他開始運行程序後,就會公示一個叫 Attestation 的文件,與Tee交互的一方,可以驗證這個文檔是否與他開源公示的是否一致。

只有當他跑的程序符合開源的指定版本,兩者才會對應上,從而證明可信,這點在行業裡已經有非常多的應用了:

  • 比如avalanche的官方跨鏈橋,就是用SGX(某Tee型號)來跑的公證人驗證者。
  • 比如以太坊主網,已經有40%的區塊鏈是通過buildr net底層也是TEE,來完成交易和出塊。
  • 更別提各種金融銀行,嚴格管控防止內鬼風險,也基本引入Tee,頭部交易所在25年的合規大背景下,也高價引入Tee來做冷熱錢包簽名托管。

雖然用Tee的難點也有不少難點,比如機器性能較低(可以用錢堆)以及宕機風險(損失內存信息)還有升級複雜。

那剩下的問題是各家交易所廠商,是如何提供Tee在錢包中服務的呢?

4.1 coinbase與Bitget的方案

一開始很難想象,其實coinbase這樣美股上市合規交易所,做的是最中心化的版本。

而且bitget也幾乎在邏輯架構上也是一致的。

其實他本質只是把Tee用作生成私鑰和驅動簽名的服務,但Tee要如何驗證這個服務是否真的是用戶的意願?

coinbase完全是基於用戶登錄了,靠後端鑑權後轉發指令到Tee內,然後完成的交易。

Bitget也是,雖然信息很少,但目前看他並沒有端上出現簽名頁的過程,然後直接就給新的地址設置了eip-7702的地址,從而實現了gas代付。

這套的優勢可以說,起碼有用戶資產的私鑰,確實是在Tee裡的,但至於後端會不會放其他奇奇怪怪的指令進去,那就不可證實,也不可證伪了。

但好在鏈上是有證據的。

所以,筆者認為,coinbase等本質是加注了交易所的信譽,畢竟私鑰是否導出肯定有記錄,這就能排除用戶騙保作惡,唯一風險就是交易所自己作惡,那其實和用戶信任CEX的底層模型是一致的。

4.2 Bn與Okx

對比這兩家的MPC與SA,其實邏輯本質也是一樣的。在驅動交易方面,okx則會彈出一套意圖授權簽名頁,這點結合在Tee內驗證意圖的邏輯,用戶授權的程度會更高一些,但綜合用戶理解成本也更高了一些。

而 Binance 的MPC其實更多是原有的技術體系的因素(其實MPC在多鏈擴展上挺有局限性的),在Tee的引入後,需要用戶把本地設備中的一個分片,加密傳輸到Tee內。而okx的則是用戶自己本地的助記詞加密傳輸到Tee內。

作為用戶,不用太擔心這裡的安全風險,目前Tee與客戶端的可靠通信是非常成熟的,理論上都是完全杜絕中間人攻擊的,畢竟只要用Tee公開的公鑰做非對稱加密,那就自然只有私鑰才能解密了。

還有一些細節的體驗不同,比如MPC、私鑰傳入到Tee內,多久過期如何續期之類的。都是工程方面問題,就不展開了。

分析其設計動機,而這樣設計的好處,主要還是遷移成本,避免了用戶要體驗新的高級功能,就得遷移資產的冷啟動問題。

比如coinbase的那套,就側重用來打支付賽道,讓沒有本地私鑰管理經驗的傳統電商服務商可以通過API來調用私鑰完成鏈上操作。

而且Binance這套,則是結合起來用在打Cedefi賽道,讓平時看K線的用戶,更便於同類頁面,去直接操作購買鏈上資產,而可以忽略掉gas、滑點、多鏈等等問題。

5. 總結

如何評價25年,又如何看待未來呢?

筆者認為,這一年是wallet的沉寂之年,也是轉變之年,他沒有太大的聲量,但在闷头干大事。

在如今的多鏈的環境下,單純做個好用的工具,已經是養不活一個大規模的錢包團隊的(以及配套基礎設置),他必然需要各種增值服務來供氧,而恰逢這一年又是應用的爆發年,perps賽道破茧重生,rwa(股票方向),預測市場,支付都同步起色。

市場正在一步步從胖meme走向多元的Dex需求。

而且,meme也只是因為交易太快,流水金額太高,從而顯得市場很大,實際一直是那波人在玩,熱點在變化,但用戶增量並不大。

再結合各種Tee加持下押上各家交易所聲譽的各自新托管系統。

而且在大趨勢上,ai會越來越強大,ai trading也是,而之前的wallet是只給人準備的,而不是給ai準備的。

所以筆者看到的是,明年再應用上會有更加豐富的爆發,因為底層已經更加趨於成熟,中間肯定還有gap期,因為tee這套還是大交易所玩法,他們不大可能輕易類似coinbase那樣完全開放了對外的入口。

另外,用戶資金玩Dex只是一部分用戶的需求,還有更大量級的用戶,只是想賺點安穩錢,結合各家推廣期間的補貼和各類空投,再加持一APY,他們就非常滿足了。

而能夠吃到鏈上收益的Cedefi類產品,會是不少CEX用戶的首次下岸地(補充,這裡提的主要是有獨立地址的Cedefi,比如Bitget那種共享地址的是吃不到的)。

最後,其實今年在密碼學技術方面passkey也有不少的提升,雖然本文都沒有涉及,但以太坊、solana等越來越多的公鏈,已經逐漸通過預編譯合約集成了R1曲線(即設備passkey默認支持的),所以結合passkey的錢包也是一支伏筆(雖然他的找回和跨設備同步不好搞)所以還沒有很多好的應用。

畢竟凡是能在高頻需求上做精簡的產品,都遲早會有一席之地。

BTC-0.19%
ETH1.19%
SOL0.06%
APT-1.66%
查看原文
此頁面可能包含第三方內容,僅供參考(非陳述或保證),不應被視為 Gate 認可其觀點表述,也不得被視為財務或專業建議。詳見聲明
  • 讚賞
  • 留言
  • 轉發
  • 分享
留言
0/400
暫無留言
交易,隨時隨地
qrCode
掃碼下載 Gate App
社群列表
繁體中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)