為了更好地閱讀本文，你需要先了解授權等基本概念。
閱讀這篇文章「一文了解代幣授權」進行了解。
Permit2 授權簡介
Permit2 是 Uniswap 去年發布的授權標準，用於改善傳統的 ERC20 代幣授權體驗，相比 ERC20 授權，更節省 Gas、更安全、更方便管理。本文我們將通過對比傳統授權、Permit 授權和 Permit2 授權，探索更詳細的 Permit2 的優勢和風險所在。
傳統授權 VS Permit2 授權
傳統授權模式
1. Approve 模式
傳統授權通常使用 Approve 方法，要求用戶分別進行兩步操作：授權和執行。基於 ERC20 標準，Approve 方法使用戶能夠設定代幣的最大轉移額度。這樣，第三方應用在獲得用戶授權後，可以轉移不超過該設定額度的代幣。其中，用戶授權和代幣轉移均為鏈上交互，需要消耗 Gas 費。
但是，用戶在使用新 DApp 進行 Approve 授權時，通常會面臨以下痛點：
- 用戶體驗差：每個 DApp 和 Token 都需要獨立授權，意味著用戶要將授權交易發送到區塊鏈，步驟繁瑣又耗費 Gas 費。
- 最大授權引發安全隱患：為避免反覆授權，DApp 通常要求用戶授予最大轉移權限。但這可能帶來若協議被漏洞利用，授權的代幣可能被全數取走的風險。
2. Permit 授權模式
為解決上述痛點，開發者推出了 Permit 簽名。該方式需進行鏈下簽名和執行兩步操作，無需消耗 Gas，節約費用且高效。更重要的是，用戶可以一次性設定授權額度和期限，有效應對了原有問題。
最常見的是 Dex 裡的掛單功能，如 1inch 有一個 Fusion 功能，讓用戶對一個消息進行簽名，這個消息包含了按某個價格出售多少代幣資訊，用戶就可以在不支付 Gas 的情況下將代幣委託給 1inch 處理，然後 1inch 會給用戶想購買的幣。
但是，Permit 簽名需要代幣合約實現 Permit 函數，而市場主流的代幣已經相當古老，其智能合約是不可升級的設計，無法支持 Permit，因此該設計只能解決新的 ERC20 代幣的授權問題，而對於絕大多數我們常用的代幣並不可行。
為了解決這個問題，Uniswap 提出了 Permit2 的標準。
Permit2 授權模式
Permit2 簽名有授權、鏈下簽名和執行三步。
- 授權給 Permit2 合約：用戶為 Permit2 合約授權（僅需首次使用時），後續便由其進行直接管理代幣
- 鏈下簽名授權：用戶在鏈下簽名，並傳給智能合約
- 執行：智能合約驗簽後，Permit2 觸發 transferFrom 完成轉賬
值得注意的是，用戶只需為 Permit2 合約授權一次，後續與其他已集成 Permit2 的智能合約交互時，無需重複授權，只需要後續兩步操作。同時，之前的沒有實現 Permit 的代幣現在通過 Permit2 也能通過簽名進行授權。
該模式具有以下優點和風險：
優點
- 兼容任意 ERC20 代幣，無論代幣本身是否支持
- 在 Permit2 合約中實現統一的代幣授權管理
- 授權時間和額度可控，且允許用戶撤銷待處理的簽名許可
- 無需為每次交互重複授權
缺點
- 簽名風險：與傳統授權（Approve）相比，Permit2 使授權更依賴簽名，對簽名警覺性較低的用戶可能會忽視其內容，增加釣魚風險
- 簽名展示問題：部分錢包可能不支持或不完整展示簽名資訊，進一步加大了用戶誤操作風險
- 舊代幣釣魚風險：先前不支持 Permit 的代幣通過 Permit2 得以授權，雖方便但增加了釣魚風險
- 授權時限變數：Permit2 允許設置授權有效期，但因其可自定義，所以實際安全性取決於使用 Permit2 的 DApp 設定
面對新風險，對於錢包來說，不僅需要可以解析 Permit 簽名資訊，為了避免釣魚網站，也需要清晰展示來源網站，通過 Logo 和 URL，幫助用戶判斷是否經過社區認證，是不是未知風險的網站。imToken 2.13.0 版本已支持該功能，可以更新體驗。
對於用戶，切記不要隨意打開來源不明的網站進行操作；確保在官方 DApp 進行交互；謹慎設定授權數量；定期檢測授權情況。