使用過 Uniswap 就有資安風險？鏈下簽名將如何導致資產遭竊取
近期不斷發生用戶使用鏈下簽名導致資產被盜的事件，其中的原理是什麼？又該怎麼預防？為何相關鏈上數據跟 Unisw
這篇文章 使用過 Uniswap 就有資安風險？鏈下簽名將如何導致資產遭竊取 最早出現於 鏈新聞 ABMedia。
近期不斷發生用戶使用鏈下簽名導致資產被盜的事件，其中的原理是什麼？又該怎麼預防？為何相關鏈上數據跟 Uniswap 有關係？本文將會清楚說明 Permit 函數背後的運作模式，以及用戶該如何自保的知識。
鏈下簽名
要理解 Permit 函數的簽名如何挪取用戶資產，需要先知道鏈下簽名的原理。
鏈下簽名是什麼
鏈下簽署是區塊鏈產業常見的用戶互動方式，常用於錢包連線、網站會員登入、確保用戶閱讀完畢免責聲明等，是一種使用 Web3 錢包獨特的互動方式。可以在虛擬世界帶入用戶的權力。
以 OpenSea 登入流程舉例，其使用了鏈下簽名方式，除了確保用戶是錢包持有者之外，也要確認用戶同意使用服務條款與隱私權政策
登入 OpenSea 的鏈下簽名畫面
鏈下簽名優點：使用者體驗好
鏈下簽名的有許多的優勢：
最明顯就是可以減少燃料費消耗
快速完成
整體來說比起鏈上交易，鏈下簽名的使用者體驗更好。
鏈下簽名缺點：容易被忽視的資安風險
鏈下簽名最大問題是可能讓用戶面臨資產遭竊的風險。
雖然鏈下簽名的當下並沒有將資料上傳區塊鏈，但是某些鏈上合約的函數可以將用戶的簽名資訊作為參數使用，代表取得特定簽名內容的任何人 (或是智能合約) 都可以因此調用鏈上的函數 (例如 Permit 函數)，並牽動用戶的資產。
不同的簽名有不同的風險，特別是某些簽名內容看不懂的時候，就需要更加特別注意，一律建議當不理解簽名內容時，不要隨意同意簽署以確保安全。
此問題將在文末繼續延伸討論。
Permit 函數
可以將用戶簽名作為參數調用的鏈上函數，最常見的函數是 Permit，提供的功能與 approvals 相似，不過前者藉由鏈下簽名，並不需要用戶付出燃料費即可以讓用戶完成授權。
想解決問題：鏈上授權體驗差
相信使用過鏈上服務的用戶都熟悉這個畫面，當使用代幣進行鏈上合約操作時，需要使用 approvals 函數進行鏈上授權，這樣才能讓合約存取錢包中的代幣，以進行服務。
Metamask 進行代幣授權 (approvals) 的畫面
不過由於代幣總類繁多，不同的合約也都需要重新授權，更不要說合約也會隨時間更新。最終造成用戶需要頻繁地進行代幣授權，除了花費的時間，且每次行動也都需要燃料費用，因此使用者體驗受到嚴重影響。
Permit 函數提升使用者體驗
因此出現了 EIP-2612，作為延伸 ERC-20 的代幣標準，提出 Permit 函數，藉由將鏈下簽名作為參數輸入的方式完成代幣授權，讓用戶不需要為了授權而付出燃料費用。
Permit 提供另一種代幣授權方法，不過參數是鏈下簽名資訊。
而其中的符合 Permit 函數的簽名內容需要包含：
授權者地址
被授權者地址
代幣合約地址
授權時間
授權數量
理想情況下，就像是現實生活的簽約模式，用戶可以依照自身需求調整參數後再進行簽署，確保權益。比起 approvals 也擁有更多的調整空間。
Permit 函數不適用早期代幣
不過由於許多代幣早已推出，許多代幣合約都是不可更改的，因此 Permit 函數僅適用在較新的代幣上，導致此功能使用場景受到滿大的限制。
因此後來 Uniswap 團隊為解決這個問題，打造了一個全新的智能合約 — Permit2。
Permit2 合約
Uniswap 推出 Permit2 合約
Uniswap 團隊在推出 Universal Router 功能時，一併整合了 Permit2 合約，並同時上線包含 Ethereum、Optimism、Arbitrum、Polygon、Celo 等網路。讓所有代幣都可以擁有 Permit 功能。
Permit2 合約：讓所有代幣都支援 Permit 函數
Permit2 原理
既然舊的代幣合約內沒有 Permit 函數可以使用，那麼就將就繼續使用 approvals 函數。
在 Dapp 合約與代幣合約之間插入 Permit2 合約，Permit2 合約接收 Dapp 傳送過來的鏈下簽名資料驗證後，代替 Dapp 與代幣合約互動，每種代幣僅需要經過一次 approvals 函數，藉此節省不同 Dapp 或是不同用戶的但幣授權次數。
傳統授權與 Permit 合約運作方式差異 (資料來源)
Uniswap 藉由其影響力，促使其他 Dapp 整合 Permit2，將會使得未來幾乎所有代幣與服務都僅需要 Permit2 合約獲得授權就可以了。
鏈下簽名竊款的原理
基於以上的背景知識，終於可以來理解為何使用過 Uniswap 後的用戶，就更有遭到簽名竊款的風險。
鏈下簽名 Permit 函數風險增
由於鏈下簽名並不需要燃料費用，是用戶經常忽略的安全性的環節，若其中遭到惡意網站誘導用戶簽下符合調用 Permit 函數的內容，那麼用戶的代幣就會遭到第三方竊取。
符合 Permit 函數需求的鏈下簽名
上述範例即為符合 Permit 函數格式的簽名，其中授權的代幣數量大多數智能合約預設都是無限顆 (10^31顆)，而授權時間換算下來也有 54 年，整體來說就是一個長期的無限授權。若此內容來自惡意第三方，用戶的資產將面臨極大危險。
當然，代幣需要擁有 Permit 函數才可能發生，只不過現在有了 Permit2 合約就不同了。隨著越來越多的協議背後整合 Permit2 合約，當用戶使用過 Uniswap 或是其他整合 Permit2 的合約，就讓其他代幣也同樣面臨相同的風險。(也才會發生牽扯到 Uniswap 合約的釣魚事件)
鏈下簽名難追蹤
鏈下簽名不會在鏈上有紀錄，大多是儲存在某個私人或是專案的資料庫中，體供隨時調用。因此比起鏈上教抑或是鏈上授權，並不是那麼容易追蹤與取消，才會說大多 Permit 授權容易有安全風險。
用戶該如何自保
身為用戶，如果對於鏈下簽名的內容不熟悉，也有許多方式可以降低這類代幣設計的風險。
第一原則就是不要隨意簽署不熟悉的內容。
當出現 approvals 確認畫面時，將授權數量調整為本次交易所需數量 (雖然這樣多次交易會需要重複授權)
雖然簽署內容難追蹤，仍然可以嘗試使用工具盡量查詢 (revoke.cash)
使用保存小額資產的錢包進行鏈下簽名
一連串本末倒置的設計
不論是 Permit 函數或是 Permit2 合約，出發點都是為了改善使用者體驗，不過最終卻讓更多的一般用戶深陷風險之中，反而要做出更多煩麻的流程 (創多錢包、多次 approvals) 才能確保資產安全，整體的使用體驗不但沒有提升反而更加糟糕。
不過確實也有許多人注意到此問題，也已經提出潛在的解決方案，相信未來的產業會更加成熟，只是仍需要給時間發展。身為產業早期參與者，注意自身資產安全確實自己是不可忽視的責任。
請務必讓身邊朋友知悉，由於現今鏈上環境變化，千萬不可忽視鏈下簽名帶來的安全風險。
這篇文章 使用過 Uniswap 就有資安風險？鏈下簽名將如何導致資產遭竊取 最早出現於 鏈新聞 ABMedia。
