MetaMask Snaps
MetaMask Snaps（https://metamask.io/snaps/） 是一個有很長遠理想的專案。不過，拋去它所披著的「理想」的外衣，筆者更願意稱它為Web3 世界的小程式。或給它取一個花俏點的名字：dApplet。
作為開發者，特別是中國國內的開發者，應該對它的概念並不陌生。我們近些年常會聽到「生態打造」、「超級App」之類的網路黑話，商業巨頭總是想要將網路打造的越來越封閉，以便讓自己從服務提供者的角色轉變為標準制定者的角色。
現在，這股風潮似乎也開始慢慢往Web3 領域飄蕩了。
到今天（2024 年6 月），雖然Snaps 已經出現了快要一年時間了，從概念提出更是至少4 年了，但是普通用戶對它的了解卻幾乎沒有。筆者身邊有一些非常關注加密貨幣市場的朋友，每天打開MetaMask 就像吃飯睡覺一般自然，卻仍然連MetaMask Snaps 是什麼都不知道。不過，筆者向他們解釋「就像小程式一樣」之後，臉上也總是會立刻出現一抹難以言喻的微笑（他們都是開發者，大部分是前端開發者）。
這場景莫名讓人聯想到微信小程式剛出來時的境況，由於功能入口不明顯，使用量很低微。後來入口改到首頁下拉出現小程式清單後，使用量才開始大幅成長。 MetaMask 既然想打造生態，那麼如何吸引用戶進入生態大門，恐怕會成為一個亟待解決的重要議題。
小程式從出現開始，在網路產業就爭議不斷。前端工程師普遍對它的出現嗤之以鼻，認為它就只是網路巨頭為了壟斷流量、封鎖生態的商業工具，對於科技發展並沒有太多貢獻。 Web3 的Snaps 不知又能對社群有多少貢獻呢？瀏覽MetaMask 提供的文檔，愈來愈覺得未來的Snap 開發者將會飽嘗帶著鐐銬跳舞的艱辛。
從MetaMask 開啟Snaps 的公開測試版到目前已有將近一年的時間，然而其官網列出的可用的Snaps 數量其實還不是很多，截止2024 年6 月，滿打滿算也只有68 個。要知道，在正式公測之前，早在2020 年左右，官方就已經提出了Snaps 的概念，Web3 公司與開發人員其實已經有相當長一段時間來對它進行充分的了解。
一些Snaps
筆者還沒見過專職開發Snaps 的開發人員，不過身邊Web2 中的小程式開發者還是有不少的，對小程式的普遍看法就是開發體驗比較差。小程式開發使用的依然是前端生態，但卻是閹割版的，廠商因為各種各樣的原因對開發者實際能做的事情進行限制。且各廠商的技術能力、提供的文件品質參差不齊，導致開發者要在各種平台踩過各種奇奇怪怪的坑之後，才能被人稱讚一句「有經驗」。
再回到Web3，出於安全性等因素考慮，Snaps 極有可能面臨著相似的狀況，它不得不在一個隔離的安全上下文中運行，所使用的是“安全ECMAScript”，實際上是對JavaScript API 做了一些限制，例如無法存取DOM、Node.js、瀏覽器插件API 等。
由於可理解的安全考量，一個最基本的Snaps 其實做不了太多事情。它的大部分功能都需要先有對應的權限，所以Snaps 在安裝時就需要向使用者申請相關的權限。可用的權限包括生命週期、交易、簽名、CRON 等： https://docs.metamask.io/snaps/reference/permissions/#eth_accounts
所以，比起繁榮的Web3 生態，目前可用的Snaps 少的可憐，MetaMask 將它們做了一些分類。
Snaps 類型
依照MetaMask 官網的分類，大致能分為4 種類型：
帳戶管理（Account Management）
這類Snaps 主要透過MPC（Multi-Party Computation，多方運算, https://blog.usecapsule.com/what-is-mpc/）技術，提升私鑰的安全性。
想想我們平常是怎麼保護私鑰的呢？大概很多人會將助記詞存在某個地方，筆者猜普遍是自己的電腦或手機上，哈哈。當然，如果你非常富有，錢包中的資金非常多，那麼你確實可能會使用保密性更強的方式，例如使用硬體錢包。但是大多數人，說真的，只是將他們的助記詞貼在某個自己很方便就能找到的地方，以避免自己完全忘記。
這種保存方式可能會造成一些問題：
-
如果你忘記把助記詞放在哪裡了，那麼你大機率是要和自己錢包中的資產說再見了。
-
如果你保存助記詞的設備遭遇木馬病毒，則很難防止駭客竊取你的助記詞。有些用戶可能為了提高安全性，將自己的助記詞拆分，然後分別存放。這也許能增加一些安全性，卻無疑也增加了自己的管理難度與遺忘的風險。
而MPC 技術，則可以自動將你的私鑰拆分為多份，分別放到不同的地方存儲，只在當需要使用私鑰進行交易簽名時，再將它們拼接起來生成完整的私鑰，同時這個過程中並不會產生完整的私鑰，最大限度地保護私鑰免於洩漏。
到目前（2024 年6 月）為止，還只有3 個帳戶管理類別的Snaps，分別是Capsule, Silent Shard 和Safeheron。
-
Capsule 使用了裝置的PassKey、復原密碼和2FA 共同維護同一份金鑰，同時如果遺失了某一個，則可以透過另外兩個來復原。
-
Silent Shard 和Safeheron 是透過使用多台裝置安裝它們的App 的方式來實現這一點。
很難說這類Snaps 能吸引多少Web3 用戶，從Snaps 網站上顯示的數據來看，這類型的Snaps 確實很少，安裝量也不高。
它們使用起來並不複雜，這裡不再贅述。安裝完成後，你的MetaMask 錢包多出一個位址：
互通性（Interoperability）
這類Snaps 主要提供了對非EVM 網路的相容，我們能看到許多熟悉的鏈，包括Solana、Cosmos、Near、Sui 等等。目前這類是最多的，它們佔據了整個Snaps 生態的一半以上。
豐富的多鏈Snaps
通知和聊天（Communication）
筆者個人更喜歡這類型的Snaps，不過在當下，可選的聊天應用那麼多，願意透過鏈來發送訊息的用戶顯然還是少數。那麼很遺憾也只能繼續「戰未來」了。
安全（Security）
這類的需求想來還是比較大的，特別是，MetaMask 本身在用戶遇到釣魚交易時的警告做的其實並不夠。交易作為加密貨幣和區塊鏈領域最常見的操作，本身俱有高風險和高敏感的特點，透過Snaps 提供的交易洞察相關功能，開發者可以對用戶展示更豐富的交易信息，提供對交易的分析和見解，最大限度地避免用戶的資產損失。
筆者身邊就有朋友曾遇到被釣魚網站轉走帳戶餘額，而MetaMask 從連接錢包到轉帳成功，全程毫無警告的情況，無奈之下只能換用其他錢包。而筆者當時對Snaps 也不了解，只是推薦了ZAN 的KYT（https://zan.top/home/know-your-transaction?chInfo=ch_WZ） 服務來保護他的交易。希望這類安全型Snaps 能彌補MetaMask 本身的不足。實際上，從Snaps 官網顯示的數據來看，安全性Snaps 也確實是除了多鏈支援外需求最大的，目前佔據了總數的兩成。
MetaMask Snaps 提供了「 endowment:transaction-insight 」和「 endowment:signature-insight 」權限來滿足相關需求，Snap 申請相關權限後，可以在用戶發起交易或簽名時，可以讀取到原始交易或簽名的有效負載。 Snap 可以對其進行分析，然後向使用者顯示更多更豐富的安全性說明。
想法
MetaMask 想要透過Snaps 將自己的領域擴展到其他鏈平台，但最終究竟能走到多遠，恐怕很難如其所願。拿Web2 領域的小程式來說，雖然很多App 提供了小程式版本，但是往往，簡陋的小程式所提供的服務遠無法與App 相比，對新功能的跟進也經常落後，甚至許多小程式會將使用者直接引導至自己的App 。而到小程式爆發式成長後，更多App 也都想來分一杯羹，又紛紛推出了自己的小程式平台，各家努力加固著自己的護城河，整個Web 世界越來越「中心化」。
Web3 領域的資本也不會比Web2 的更高明，如果後面Snaps 發展良好，那勢必會有更多錢包跟隨。如果真的到了這種地步，Web3 領域的開發者需要針對各個錢包的「Snaps」開發相應的版本，屆時恐怕會讓他們焦頭爛額一段時間。只是，倘若各廠商都來打造自己的「Snaps」生態，又幾乎等於全部沒有自己獨有的生態。咦，這似乎倒是也暗合它們「去中心化」的標籤了。
我們或許能稍微預測一下，未來可能會有各種「Snaps-like」出現，平台差異巨大，此時對各平台的兼容成了開發者們的日常工作，最終到了不可忍受的地步。於是Snaps Standard 在眾多開發者的期待中誕生了，同時會有各種「SIP」 供人們參與討論，社區一片繁榮景象…
抱歉筆者個人似乎有些對MetaMask Snaps 太沒有信心了點。無論怎麼說，它至少是由一群有熱情的開發者所建構的、想要解決實際問題的產品，而不是由一群金融專家發起的騙局。
只是，對於MetaMask 眼下的大部分用戶來說，Snaps 確實還不算是一個特別必須的功能，MetaMask 接下來恐怕需要在如何更有效的推廣方面做更多工作。
