MPC Snap：將多因素驗證整合至 MetaMask

MetaMask Snaps 是讓 MetaMask 成為全球最具擴展性錢包的發展藍圖。身為開發者，您可以透過全新方式將您的功能與 API 帶入 MetaMask。Web3 開發者是這項成長的核心，本系列旨在展示當今正在建構的創新 MetaMask Snaps。

Web3Auth Snap

Snap 儲存庫： https://github.com/Web3Auth/openlogin-snap/

您為什麼要建構它？

在 Web3Auth，我們一直相信多因素驗證是保護加密資產的最佳方式，遠優於助記詞。當我們在 ETHBogota 看到最新版本的 MetaMask Snaps 允許其提供外部金鑰管理功能時，我們決定在 Sozu House 黑客松中挑戰自我，將 MPC 技術整合至 MetaMask。

能否帶我們了解技術實作的細節？

• 我們的目標是讓新使用者能夠登入並設定雙重驗證（2FA），以便在 MetaMask 中存取其帳戶。此後，在幕後，每當使用者嘗試簽署交易時，我們的 MPC SDK 便會執行門檻 ECDSA 簽章。其做法是將私鑰分割為兩個部分：一個儲存在 snap 中的本地份額，以及一個儲存在簽署伺服器上的份額。經過多輪通訊後，簽署伺服器與 snap 應能共同簽署以太坊交易，並在 Goerli 網路上完成確認。與助記詞不同，此設置不存在導致金鑰永久遺失的單點故障：即使使用者的筆記型電腦遭到入侵，或簽署伺服器被駭，使用者也不會失去其私鑰。

• 與其他所有 snap 一樣，我們的 snap 由兩個部分組成：實際的 snap 套件，以及一個載入並與 snap 互動的頁面。我們理想的使用者流程是將所有金鑰管理互動保留在 MetaMask 擴充功能的 UI 中，但由於權限限制，我們無法做到這一點。因此，使用者驗證發生在 snap 之外，完成後，我們再將狀態遷移至 snap 中。隨後，我們接入 MetaMask 的 RPC 引擎，並透過使用我們的 MPC SDK 和 snap 中已遷移的狀態，對交易生成門檻 ECDSA 簽章來回應交易請求。令人驚訝的是，我們在黑客松的最初幾個小時內便完成了狀態遷移部分，剩下的只有簽署功能。

• 其餘流程可進一步分為兩項主要任務：

• 將現有的 Web3 提供者與我們的 MPC SDK 重新整合，以處理傳入的交易請求

• 讓 MPC SDK 在 MetaMask Snaps 的 SES 環境中運行

• 如果您熟悉 MetaMask 的運作方式，或其他錢包的運作方式，您就會知道簽署以太坊交易所需的工作遠不止使用私鑰簽署訊息那麼簡單。構建待簽署的訊息物件需要大量工作。每筆交易都遵循特定於各鏈和交易類型的特定格式，具有需要支援以確保向後相容性的舊有行為，必須獲取當前 Gas 價格的資訊，必須計算要使用的 Gas 量與 Gas 上限，還必須追蹤帳戶 nonce 等。幸運的是，大多數現有的 Web3 提供者已開箱即用地處理這些事項。然而，為了讓我們的門檻簽章函式庫能與這些 SDK 良好配合，我們必須深入研究每個模組，並將 eth-sig-util 函式庫的簽署函式替換為我們自己的門檻簽章函式庫簽署函式，這花費了大量時間。此外，由於我們的 MPC SDK 是鏈無關的，未考慮以太坊特定的檢查，我們還必須對已替換的 eth-sig-util 函式庫中的檢查進行逆向工程並重新實作。例如，EIP-2 規定 ECDSA 簽章中的 s 值不得大於 n/2 + 1（其中 n 是 secp256k1 橢圓曲線的階），以防止交易延展性攻擊，這要求 ECDSA 簽署函式庫在 s 值超出此範圍時對簽章進行「翻轉」。

• 我們面臨的另一個挑戰是讓我們的 MPC SDK 在 MetaMask Snaps 環境中運行。我們的 MPC SDK 使用 wasm（從 Rust 編譯而來）以在瀏覽器中高效運行。由於 SDK 與簽署伺服器之間需要多輪通訊，它也使用 Socket.IO 進行通訊，以避免 HTTP 標頭的額外開銷。在嘗試將我們的 wasm 程式碼載入 snap 時，我們遇到了 wasm 方法中混合參數類型的奇怪問題。不幸的是，wasm 除錯工具仍然非常匱乏，錯誤訊息毫無幫助且缺乏資訊（例如：「Uncaught RuntimeError: unreachable」）。最終，我們透過將所有混合輸入參數接受為字串，並在 wasm 程式碼內部將其解析為整數或位元組陣列，繞過了這一限制。我們遇到的另一個問題是 socket.io 無法在 MetaMask Snaps 環境中運作。Socket.IO 是一個建立在普通 WebSocket 之上的獨立函式庫與規範，可處理連線升級、斷線、降級為長輪詢等情況，在生產環境中使用 WebSocket 時非常有用。不幸的是，我們無法讓 Socket.IO 的函式庫在 MetaMask Snap 環境中運行。因此，我們不得不退回到普通 WebSocket，並重寫簽署伺服器以使用預設 WebSocket 而非 socket.io，並在 WebSocket 出現問題時退回到輪詢策略。

能否介紹一下您自己和您的團隊？

Zhen 和我是 Web3Auth 的共同創辦人，我們的公司專注於提供直觀、安全且非託管的金鑰管理解決方案。我們相信，良好的安全性必須易於使用且無感，否則將無法被廣泛採用。這就是為什麼我們大力倡導對私鑰使用多因素驗證。

您是何時首次接觸 MetaMask Snaps 的，體驗如何？

大約一年前，我們嘗試了 MetaMask Snaps，但不幸的是，當時它還不具備讓我們擴展 MetaMask 私鑰管理功能的能力。隨著近期 SIP-2 的推出（感謝 Olaf！），它允許 MetaMask Snaps 擴展 MetaMask 的 keyring，我們對其可能性感到非常興奮！在建構我們的 snap 時，我也探索了 MetaMask Snaps 所基於的 SES 系統，我認為這是一個非常穩固的基礎，讓 MetaMask 得以作為平台，供開發者透過 MetaMask Snaps 新增功能。

MetaMask Snaps 與其他錢包有何不同？

可擴展性！我認為 MetaMask Snaps 為開發者提供了一個安全的介面，可以在不損害 MetaMask 擴充功能本身安全性的情況下進行實驗並增強 MetaMask。與其他類型的專案不同，錢包需要高標準的安全性，這意味著整合來自第三方的新功能始終是一個漫長而艱辛的程式碼審查與稽核過程，這抑制了創新。MetaMask Snaps 讓 MetaMask 團隊能夠繼續建構安全的產品，同時仍允許外部開發者進行實驗並擴展其功能。

請告訴我們您和您的團隊使用 MetaMask 建構 Snaps 的體驗如何？

我認為 MetaMask Snaps 絕對是未來的方向，讓人們能夠在保持基礎 MetaMask 擴充功能安全的同時建構功能。目前還有一些小問題，但每天都在持續改進，我整體上認為這非常令人振奮。

MetaMask Snaps 對您意味著什麼？

我希望透過 MetaMask Snaps 為 MetaMask 新增多因素驗證功能，能幫助數百萬 MetaMask 主流使用者更安全地管理其帳戶，並防止他們成為詐騙和駭客攻擊的受害者。MFA 如今已為數十億 Web2 使用者提供保護，我們希望將這些安全最佳實踐帶入 Web3。

您認為 MetaMask Snaps 為 Web3 領域帶來了哪些機遇與可能性？

總體而言，我認為 MetaMask Snaps 代表了一種切實可行的方式，讓 MetaMask 能夠在不損害安全性的前提下，向其他人開放其程式碼庫以共同貢獻。

您對有意嘗試 MetaMask Snaps 的開發者有什麼建議？

就去試試吧！它看起來可能有點新，但到目前為止非常易於上手，而且在 Consensys Discord 頻道的 MetaMask Snaps 社群中有很好的支援。許多出色的開發者正在為此努力，如果您想參與塑造 MetaMask Snaps 的對話，現在正是在其上建構並提供反饋的最佳時機！

使用 MetaMask Snaps 進行建構

開始使用 MetaMask Snaps：

1. 查閱開發者文件

2. 安裝 MetaMask Flask

3. 查看 MetaMask Snaps 指南

4. 在 Twitter、GitHub 討論區和 Discord 上與我們保持聯繫

請留意我們的團隊將出現在您附近的下一場黑客松！祝 BUIDL 愉快 ⚒️

免責聲明：MetaMask Snaps 通常由 Consensys Software 以外的第三方開發。使用第三方開發的 MetaMask Snaps 須由您自行斟酌判斷並承擔風險，且您同意對因此類活動造成的任何損失或損害承擔全部責任。Consensys 對第三方開發的 MetaMask Snaps 不作任何明示或暗示的保證，無論是口頭或書面形式，並對第三方開發的 MetaMask Snaps 免除一切責任。使用區塊鏈相關軟體存在風險，使用 MetaMask Snaps 即表示您完全承擔這些風險。