深入解析 ERC-20 授權模型:Permit 與 Permit2 的原理、風險與比較

新手4/25/2025, 6:38:53 AM
ERC-20 代幣的授權機制正持續進化!從傳統的雙交易 approve 模式,到 Permit 引入的鏈下籤名授權,再到 Uniswap 開發的通用型 Permit2 合約。這些創新不僅簡化了用戶操作流程、節省了 Gas 成本,更通過批次處理、時效控制等功能增強了安全性。然而,新技術也帶來新的挑戰,特別是籤名釣魚攻擊的風險。本文全面剖析這些授權機制的原理、優劣與應用場景,並提供實用的安全建議,幫助用戶在便利與安全間取得平衡。

區塊鏈世界中,我們常需要授權(allowance)機制來讓智能合約代我們花費代幣。例如,在去中心化交易所(DEX)交易代幣時,用戶必須先授權交易合約可以從自己的錢包轉出特定數量的代幣。傳統的 ERC-20 授權流程需要用戶提交一筆 approve 交易,然後再提交實際的交換交易,流程繁瑣且耗費額外的 Gas。然而,爲了改善用戶體驗與安全性,以太坊社群提出了基於籤名的授權機制 ——Permit(例如 EIP-2612)與進一步的 Permit2 方案。這些新機制允許用戶透過鏈下籤名(off-chain signature)來授權代幣使用權,避免額外的鏈上交易。

在本篇文章中,我們將從基礎概念出發,介紹傳統 ERC-20 授權的原理與局限,再深入講解 Permit 與 Permit2 的工作方式、優缺點,以及它們如何增進效率與安全。同時,我們也會分析相關的安全風險(特別是籤名釣魚攻擊案例)並提供防護建議。希望使剛入門區塊鏈或加密投資的新手,也能理解這些重要的技術演進。

ERC-20 授權模型基礎

在開始討論 Permit 之前,先讓我們了解傳統 ERC-20 代幣的授權模型是如何運作的,以及其中存在的問題。

傳統 ERC-20 Approve 的運作方式

ERC-20 是以太坊代幣的標準,其中定義的 approve 和 transferFrom 函式提供了代幣授權機制。所謂授權,是指代幣持有人(owner)允許另一個帳戶(通常是智能合約,稱爲spender)從自己的餘額中代爲轉出一定數量的代幣。基本流程如下:

  1. 授權(approve):代幣持有人呼叫代幣合約的 approve(spender, amount) 函式,在代幣合約的內部 allowance 對映中記錄授權額度。例如 A 授權 Uniswap 合約可花費自己最多100枚代幣,則 allowance[A][Uniswap] = 100。這步驟需要一筆鏈上交易,由 A 支付 Gas 費。
  2. 代付(transferFrom):之後,當 Uniswap 等需要代替 A 花費其代幣時,就由 Uniswap 合約呼叫 transferFrom(A, B, amount)。代幣合約會檢查 allowance[A][Uniswap] 是否足夠,若足夠則從 A 帳戶轉出 amount 給 B,並減少相應的授權額度。

Approve 模式的局限與挑戰

透過上述雙步驟模型,用戶不需將私鑰交給他人,就能讓合約代操作資金。然而,這種傳統模型也帶來一些實際問題:

需要兩次交易,體驗不佳
當用戶第一次在某應用使用某代幣時,都得先進行一次獨立的授權交易,然後才能進行真正的操作(例如交易、質押等)。這意味着用戶在使用新 DApp 時,錢包會跳出兩次確認,而且要支付額外的 Gas。對新手而言,這額外的一步驟容易造成困惑與不便。

授權管理分散
如果用戶在多個 DApp 中使用同一代幣(例如先在 Uniswap 交易,又到另一個 DeFi 協議存款),即使都是自己的代幣,每個 DApp 仍要求分別的授權交易,導致重復授權浪費時間與費用。

且每個協議各自爲政地要求授權,用戶錢包很難統一管理。目前有一些工具(如 Revoke.cashDeBank)能顯示所有授權,但普通用戶未必知曉;加上每次撤銷也需要一筆鏈上交易完成,成本不低,因此很多舊的授權往往被遺忘。

無限額授權的風險
爲了避免頻繁授權交易,不少應用建議用戶直接「無限額」授權,即授權 spender 可以支配錢包中該代幣的全部餘額,且不限時間。雖然這樣用戶後續無需再授權,但安全風險很高:一旦該 DApp 或合約被攻擊,攻擊者就能利用無限授權轉走用戶所有該代幣。

上述問題促使開發者尋找更佳方案。理想情況是:用戶只需一次籤署意願(最好不額外花 Gas),就能完成授權與操作,同時授權範圍與時間應盡量受控,降低不必要的風險。在這背景下,ERC-20 Permit 應運而生。

Permit:以籤章授權的 ERC-20 擴充 (EIP-2612)

Permit 這個構想最初由 快點 穩定幣合約引入,後來標準化爲 EIP-2612。簡而言之,Permit 允許用戶透過鏈下籤名來授權代幣轉移,省去單獨發送 approve 交易的麻煩。以下我們深入介紹其機制與特色。

Permit 的運作原理

Permit 是一種利用數位籤章進行授權的機制。以 EIP-2612 的標準實現爲例,每個支持 Permit 的 ERC-20 代幣合約內部增加了一個 permit() 函式,大致如下:

功能許可(
地址所有者、地址花費者、
uint256 值,uint256 截止日期,
uint8 v、bytes32 r、bytes32 s
) 外部的;

其中 owner、spender、value 分別是授權的持有人、被授權者、額度數量,deadline 是籤名期限,後面的 v, r, s 是籤名數據(即 電子CDSA 籤章的組成部分)。透過 Permit 機制,用戶跳過了獨立的 on-chain 授權步驟,只需籤名(不用付 Gas)並在隨後操作時附帶該籤名即完成授權,達到了「一次操作,雙重效果」的目的。


Permit 使用流程(來源: Gate Learn 創作者 John)

相較傳統 approve,Permit 省去一次鏈上交易,用戶不再需要提前發出 approve 交易,節省了時間和 Gas 成本。並且提供更細粒度的授權控制,例如用戶可籤一個只允許花費 50 USDC、5 分鍾內有效的 Permit,用於一次性操作。過期後即使籤名未被用,攻擊者也無法濫用,減少授權風險。目前許多 DeFi 協議(如去中心化交易所、借貸平台等)均已逐步支援 Permit 流程。知名例子包括 Uniswap V2/V3 流動性憑證代幣、DAIUSDC 等均實裝了 EIP-2612 標準,使其在各種操作中都可透過籤名授權一步完成。

然而,Permit 最大的限制是必須由代幣合約本身實現。如果一個 ERC-20 代幣的開發者沒有在合約中加入 permit () 方法(即不支持 EIP-2612),那該代幣就無法使用籤名授權。由於 EIP-2612 是在 2020 年提出,許多較早發行的代幣並不具備這功能,而即便是之後的新代幣也不見得都實裝了它。這導致 Permit 的適用性受到限制:不支援的代幣仍得沿用傳統 approve 模式。

另外,用戶錢包軟體需要正確識別並顯示 Permit 籤名資訊(EIP-712 格式)。大多數主流錢包現在已支持,但仍有部分錢包或不夠友善,可能僅顯示原始資料而非人類可讀訊息。這可能導致用戶看不懂自己籤了什麼。如果錢包沒有針對 EIP-2612 提供清晰界面,會降低用戶對籤名授權的理解。同時如果在平行部署(如不同鏈上同地址合約)情況下,籤名可能在其它環境被重新使用。因此用戶還需要確保籤名中鏈 ID、合約地址都是當前環境,以免籤給 A 鏈代幣的許可被 B 鏈上相同地址合約濫用。

基本上,Permit 大幅改善了 ERC-20 授權的效率和靈活性,被視爲 Gasless Approve 的重要裏程碑。但它並非萬能:需要代幣支持,以及新的風險也隨之而來。接着我們將看看 Uniswap 發布的 Permit2,如何在 Permit 基礎上更進一步。

Permit2:通用授權管理合約

隨着 Permit 機制的普及,一個新的問題出現:如何讓不支援 Permit 的代幣也享受籤名授權的便利?爲了解決這個問題,同時優化多種情境下的授權體驗,Uniswap 團隊在 2022 年推出了 Permit2。 Permit2 不是單一代幣的功能,而是一個獨立的授權管理智能合約。它的目的是成爲各種代幣授權的中介,提供統一、強化的授權功能。下面我們來剖析 Permit2 的原理與特色。

Permit2 的運作原理

Permit2 可以理解爲一個授權中繼服務。核心思想是:用戶對 Permit2 合約進行一次授權,之後由 Permit2 合約替用戶管理對各應用的子授權。具體流程如下:

  1. 一次性授權 Permit2:用戶針對每個代幣,使用傳統方式調用其 approve (Permit2, max_amount)。通常建議無限額或較大額度,因爲這是主授權。一旦完成,Permit2 合約在該代幣上就擁有了可以代表用戶調用 transferFrom 的權限。這步需要鏈上交易,但只需做一次。
  2. 用戶鏈下籤名子授權:當用戶希望與某 DApp 進行特定操作時(例如用 Uniswap Universal Router 進行多代幣交換),用戶針對此次操作透過 Permit2 的規範籤署一份離線授權消息。籤名內容包括允許的代幣、金額、授權給的目標(spender,例如特定 DApp 合約)以及有效期限等資訊。
  3. DApp 使用籤名請求轉帳:DApp 接收到用戶籤名後,在需要動用代幣時,不直接呼叫代幣合約,而是呼叫 Permit2 合約提供的函式(例如 permitTransferFrom)。該函式會驗證用戶籤名資料,確認此次操作在用戶授予的權限之內(代幣、金額、截止時間皆未超限)。驗證通過後,Permit2 合約遂利用自己之前獲得的主授權,去調用代幣的 transferFrom,將代幣從用戶轉給指定接收方。重點:Permit2 合約本身就是 spender,它用自己的權限完成對代幣的轉移,只是在轉移前增加了一道對籤名的核驗。
  4. 完成操作:一旦 Permit2 執行 transferFrom 成功,資金便順利從用戶轉出至 DApp 或指定地址。對前端用戶而言,他只是在交易中提供了一個籤名,後續動作均由合約代理完成。


Permit2 授權流程示意。用戶僅需針對每種代幣執行一次最大額度的主授權給 Permit2,之後與各應用(Uniswap Universal Router 或其他協議)互動時,只需在交易中附帶 Permit2 籤名即可完成授權與轉帳,無需額外的鏈上 approve。 Permit2 合約會驗證籤名並利用其持有的主授權執行轉帳。 (來源:Introducing Permit2 & Universal Router

透過上述模式,Permit2 將 EIP-2612 的籤名授權概念推廣到所有 ERC-20 代幣,無論該代幣本身是否實裝 permit() 方法。只要用戶願意事先授權 Permit2 合約管理,就能用籤名進行後續操作。值得一提的是,Uniswap 將 Permit2 設計爲無主、不可升級的合約,已部署在以太坊主網及多條二層上,地址都相同。這意味着所有應用使用的其實是同一個 Permit2 實例,實現真正的「一次授權,多處通用」。

Permit2 的特色功能

作爲新一代授權系統,Permit2 不僅達成所有代幣的籤名授權,還提供了額外的功能來增進安全與易用性。主要特色包括:

授權自動過期
Permit2 的所有授權記錄都可以設定時間戳過期。用戶在籤名時即可指定此子授權有效至何時。一旦超過期限,Permit2 將拒絕該籤名,即便主授權還在。這有效解決了傳統無限授權掛着不管的隱患。

一次性籤名轉移
Permit2 提供直接籤名轉帳模式,用戶可以用籤名授權直接完成某次代幣轉移給特定接收者,而無需事先設置 allowance。這適用於一次性的支付場景:用戶籤一個消息授權轉 100 個代幣給好友地址,好友或中介即可拿此籤名從用戶處扣款。一旦執行,籤名作廢,不留長期許可。

批次授權與轉帳
Permit2 考慮了效率,允許批量處理多筆授權或多筆轉帳。例如用戶可一份籤名授權多種代幣不同額度給同一協議;或在一次交易裏執行多個代幣的轉帳操作。對高級用戶而言,這可節省更多 Gas 和步驟。

批量撤銷
除了批量授權,也可以在一次交易裏批量撤銷多個代幣/多個應用的許可。這對於清理歷史授權非常便利。

額外資料見證
Permit2 還提供 permitWitnessTransferFrom 等介面,允許在籤名中攜帶其他見證資料進行校驗。這可用於更復雜的場景,例如訂單籤章中夾帶特定交易細節,避免籤名被移花接木在不同情境下使用。

透過這些功能,Permit2 不僅重現了 Permit 的所有好處,還加強了靈活性與安全控制。尤其自動過期與一次性籤名轉帳,使最小必要授權成爲常態,降低長期風險。

總結而言,Permit2 可視爲對傳統 Permit 機制的擴充與補強,兩者的主要差異包括:

Permit2 的應用生態與採用情況

自 Uniswap 推出 Permit2 以來,已有多個項目開始整合這一機制,加速了行業標準化的趨勢 。根據 Dune Analytics 的最新數據,截至 2025 年 4 月,已有​超過 310 萬個以太坊主網地址對 Permit2 合約授予過授權。​這反映出該合約的使用範圍相當廣。


Permit2 的應用生態與採用情況(來源:Dune Analytics

例如,Uniswap 自己就將 Permit2 集成到其 Universal Router 中,實現單筆交易完成多代幣及 NFT 交換。透過 Universal Router,用戶能在一次交易中串聯多步操作,像是用三種代幣交換兩種目標代幣並購買 NFT,而中途所有授權需求都由 Permit2 籤名滿足。這極大簡化了操作流程,也降低總 Gas 成本,是 Permit2 提升 UX 的直接體現。

另外,隨着 Permit2 開源並在各鏈部署,越來越多錢包與 DApp 工具開始支援 Permit2。Revoke.cash 等安全工具已更新服務,讓用戶能檢視和撤銷 Permit2 的授權紀錄。 Matcha 也引入了 Permit2 的 SignatureTransfer 模組,實現了「一次性授權」機制。

盡管有上述進展,Permit2 的普及仍面臨挑戰。一方面,開發者需要額外時間整合:相較直接用 ERC-20 的 approve,對接 Permit2 需處理籤名邏輯,增加了開發負擔。小型團隊可能因此卻步。另一方面,用戶教育也很重要:許多使用 Permit2 的 DApp 需要教導用戶籤名意義。目前看來,Permit2 的一體化優勢足以抵消這些摩擦,但全面滲透仍需時間推動。

Permit2 與 Session Key、ERC-4337 等新方案的比較

回顧過去 8 年,ERC‑20 授權機制從「多筆交易」走向「無感籤名」、再到「智能帳戶」,每一次迭代,都試圖在「用戶體驗(交易/籤名次數)」與「Gas 成本」之間取得更佳平衡。以下是各技術對比:


目前除了 Permit2,比較值得關注的新興授權方案是 Session Key(會話金鑰)及 ERC-4337 帳戶抽象,都提供了不同的解決思路。

Session Key 比較特別,他其實不算授權模型,而是屬於「錢包/帳戶層」的暫時金鑰機制——它並不改動代幣合約,而是讓錢包產生一組短期、限額的臨時私鑰,只能執行特定操作。適用於遊戲道具支付、單次授權的微額支付等場景。它的重點在於降低單次授權風險,是爲了用戶臨時交互而量身打造,不同於直接改合約的 Permit/Permit2。

ERC-4337 則將授權邏輯直接內建在智能帳戶中,允許使用者自行設定授權條件,甚至省略傳統的授權步驟,透過更靈活的 UserOperation 與 Paymaster 機制,達到更佳的安全性與使用體驗。

從未來發展趨勢來看,這些不同方案可能會並存,短期內 Permit2 將持續成爲各類新興 DApp 的標準方案,透過一次性授權提高使用流暢度,並隨之推動安全教育與工具支援,降低釣魚風險。中期而言,隨着 ERC-4337 等帳戶抽象的普及與更多 Layer 和主網支援,使用者可望擺脫傳統 ERC-20 approve 限制,更精細且智能化地管理授權條件,使 Permit2 的需求逐漸降低。

長期願景是達到如 Web2 般直覺且無感的授權體驗,用戶點擊按鈕即可自動完成背後所需的授權操作,僅在風險較高時才收到明確提示。爲達成此目標,底層協議、錢包和 DApp 需要持續協作創新與整合。 Permit2 是這個過渡過程中的重要一步,但要達到理想狀態仍有漫長的路要走。在這過程中,社群和開發者應保持務實的態度,充分理解各方案的優缺點,協同推動更安全、便利的授權環境。

整體而言,Permit2 提供了當前可即刻運用的解決方案,而 Session Key 和 ERC-4337 則代表了更長期且本質上的授權機制改進方向。

籤名授權的安全風險

任何新技術都伴隨新的風險。 Permit 和 Permit2 雖提升了效率,卻也引入了籤名授權被攻擊的潛在風險。

在 Permit2(以及 EIP‑2612 Permit)等籤名授權方案中,爲了降低籤名濫用與重放攻擊風險,核心合約設計了多層防護機制:

1. Nonce 防重放

Permit2 爲每組 (owner, token, spender) 維護獨立的 nonce 計數器,用戶每次籤名後,對應的 nonce 就遞增。攻擊者手中持有舊籤名時,只要合約端 nonce 已更新,該籤名即失效,無法再被重放執行。

2. Deadline 失效機制

籤名資料中必須包含 deadline 欄位,合約在驗證籤名時會檢查當前區塊時間是否 ≤ deadline。一旦過期,即使籤名與 nonce 正確,也會被拒絕執行,避免長期授權造成的潛在損失。

3. 允許範圍(Allowance)細化

Permit2 籤名可指定「最大授權額度」,合約在轉帳前會比較實際操作數量是否 ≤ 籤名中允許的上限。單次操作後,不會自動消耗所有額度,用戶可分批使用,降低一次性全額授權風險。

4. 批次與一次性模式

除了持續授權(allowance)模式,Permit2 同時支援「一次性籤名轉帳」(SignatureTransfer),該籤名在執行後即失效,不留後續授權。在一次性支付場景下,籤名只對本次轉帳生效,再也不會被重放或濫用。

透過上述多重機制,籤名授權在提高 UX 與節省 Gas 的同時,也在合約層面大幅降低了「重放」、「過度授權」與「長期失效」等典型風險。

不過,即便合約端具備嚴密設計,社交工程(又稱「釣魚」)仍是最難防的環節。接下來,我們將用常見釣魚手法,說明攻擊者如何誘導用戶在毫無察覺的情況下,提交惡意籤名,濫用 Permit2 授權,並提出防範建議。

籤名釣魚攻擊都是怎麼發生的?

籤名釣魚是指攻擊者誘騙受害者籤署特定訊息,以取得對方資產控制權。在傳統模式下,攻擊者可能引誘你執行惡意合約或提交惡意交易;而在 Permit 時代,籤一個惡意授權就足以讓幣被轉走。以下說明可能的攻擊過程:

  1. 受害者誤點擊了一個仿冒的知名 DEX 網站(釣魚網站)。該假網站在用戶嘗試操作時,彈出了一個錢包籤名請求,宣稱是「確認登入」或其他看似正常的用途。但實際上,這請求是一份 Permit2 授權籤名:內容是授權攻擊者的合約可不限額度提取受害者的 USDC,期限較長。

  2. 受害者因缺乏警覺直接點擊籤名。此時,他並未花費任何 Gas,鏈上也尚未有動作,因此毫無異常跡象。

  3. 攻擊者拿到籤名後,立刻呼叫了 Permit2 合約的 permit () 函式,提交該籤名。 Permit2 合約驗證通過後,在受害者地址下記錄了對攻擊者合約的授權許可(相當於受害者對攻擊者合約執行了一次 approve,但這步是攻擊者替他完成的)。這步操作依然可能不被受害者察覺,因爲從受害者觀點,他的錢包沒發生任何支出,只是區塊鏈上自己的代幣 Allowance 映射被更新了。

  4. 隨後,攻擊者立即由自己的地址發起 transferFrom (受害者,攻擊者地址,若幹金額) 的交易,透過剛才 Permit2 的許可,成功將受害者錢包裏的 USDC 轉走。受害者此時才驚覺資產被盜,但爲時已晚。

在上述攻擊中,用戶完全沒有執行任何明顯的「轉帳」或「授權」交易,但資產卻莫名其妙地轉出。關鍵就在於籤名本身成了授權。攻擊者精心僞裝籤名請求,使其看似與一般的操作無異,讓人放下戒心。然而,一旦籤署,後果就如同把資產的門鎖鑰匙交給了對方。

更惡劣的是,一些攻擊者會使用技術手段來提高隱蔽性。例如,攻擊者會利用了以太坊的 CREATE2 機制,每次釣魚爲每個受害者生成獨一無二的惡意合約地址。這使傳統黑名單難以及時辨識,因爲每次攻擊地址都不同。

大部分近年來的釣魚盜幣事件都與籤名授權有關。例如,Scam Sniffer 2024 年初統計,一個月內就有超過 5500 萬美元的資產因這類籤名釣魚被盜。 Permit2 啓用後,攻擊者更加積極誘導用戶籤署 Permit/Permit2 許可,導致短時間內許多用戶中招。可見,籤名授權一旦被濫用,殺傷力巨大且不易被察覺。

爲何籤名授權的釣魚風險會高於傳統模式?

傳統的惡意授權需要誘導用戶執行一筆鏈上交易,在錢包中往往明顯提示「你正在給 XXX 授權使用你的代幣」並需支付 Gas,稍有經驗的用戶可能警覺。而籤名請求在錢包介面中可能被描述爲「資料籤名要求」而非金錢行爲,用戶往往降低戒心。此外籤名不耗 Gas,使得攻擊嘗試成本低,攻擊者可以大規模發起釣魚而不擔心費用損失,只要有少數成功就賺到了。

另外,不同錢包對 EIP-712 訊息的顯示差異很大。一些現代錢包(如 MetaMask 新版)會解析出字段,例如提示「授權某合約花費你多少某代幣」,但也有不少錢包僅顯示十六進制資料或簡單描述,使一般用戶難以判斷真僞。攻擊者會利用這點,在訊息中塞入欺騙性的說明(例如假裝是 NFT Mint 籤名),讓人誤籤。

由於籤名授權不會立即體現在用戶資產變化上,受害者往往不立即察覺。而攻擊者可以選擇最佳時機下手。例如,一些攻擊者拿到籤名後並不立刻執行,而是等待受害者錢包有更多資產或在特定時機再用,使追查更困難。另外,如果籤名有較長的有效期,攻擊者甚至可以等待價格波動後再執行,以獲取更大利益(這在金融上稱爲給攻擊者一個免費期權,因此 Permit 籤名多半要求帶上短 deadline 以降低此風險。

特別針對 Permit2,因其允許一份籤名授權多個代幣,這對用戶閱讀理解增加了困難。假設一個釣魚網站請你籤一個 Permit2 消息,介面上可能只強調其中一兩種代幣用途,卻在同一籤名中暗藏對其他代幣的大額授權。如果錢包沒有列出全部細節,用戶很容易忽略。此外,有些惡意籤名甚至授權的是所謂「WalletGuard」之類看似正當的合約名稱,實則是攻擊者部署的合約,專門用來騙取許可。

用戶如何保護自己免受籤名攻擊?

牢記籤名 = 蓋章同意的原則,不要因爲籤名不花 Gas 就掉以輕心。每次錢包彈出籤名要求時,都應仔細閱讀錢包提供的訊息明細。確認發起籤名的網站或 DApp 是否可信,訊息內容是否與自己預期操作一致。例如,如果你只是要登入網站,那籤名內容應該是人類可讀的登入訊息(許多 DApp 登入會用特定字串),而不是一堆代幣地址和數字。

此外,確保使用的錢包軟體能支援 EIP-712 資料顯示。目前主流的 MetaMask、TrustWalletLedger Live 等都在改進顯示籤名內容的體驗。例如 MetaMask 已能將常見許可訊息解析成人話。如果你的錢包在籤名時只秀出一長串16進位數據,建議更換或更新。硬體錢包用戶也要注意固件更新,以支援新格式,否則螢幕上可能無法正確顯示資訊。

不論是 Permit 籤名或 Permit2,多數情況下你可以自行調整授權參數。不要籤無限額(value = 2^256-1)除非非常必要,改爲僅授權實際所需數量再稍留餘裕即可。也不要將 deadline 設得過長。這樣即使籤名意外落入他人之手,能造成的損失也有限,過期後籤名失效。

養成習慣,定期使用工具(如 Revoke.cash、Etherscan Token Approval、各錢包內建功能)查看自己地址對外授權情況,包括傳統 approve 和 Permit2 許可。如果發現異常或不再需要的授權,及時撤銷。對於 Permit2,撤銷需注意兩層:一是主授權(你對 Permit2 合約本身的 approve,可考慮在不用時將其設 0);二是子授權(Permit2 代你給各 DApp 的許可,多數有自動過期,但如有效期很長,也可以透過工具提前終止)。尤其如果你懷疑曾籤署可疑 Permit,最安全的做法是立刻調整 nonce:可以對同一 spender 籤發一個新的 permit(哪怕給 0 額度),以佔用掉攻擊者手中的舊籤名的 nonce,使其作廢。

對於不熟悉的網站或應用,一定提高警覺。不隨意點擊來路不明的連結,尤其是社群平台上的廣告或私訊提供的「福利」、「mint 活動」等連結。許多釣魚就是透過冒充官方帳號發布虛假活動連結,一旦連入就誘導籤名。養成習慣直接輸入常用 DApp 官方網址,或使用書籤,避免被假網站魚目混珠。

總而言之,權衡方便與安全很重要。 Permit 類技術固然便利,但用戶端的風險防範不能松懈。隨着環境成熟,錢包產品和瀏覽器插件也在開發針對籤名釣魚的防護,例如有的會在你籤名包含巨大金額時警示。未來希望在技術與教育雙方面共同降低此類攻擊的發生。

結語

從傳統 ERC-20 授權模型的不足,到 Permit 的誕生,再到 Uniswap Permit2 的創新,我們見證了以太坊生態爲改善用戶體驗和安全性所做的努力。 Permit2 通過鏈下籤名大幅簡化了代幣授權流程,減少重復授權和無限許可的風險,同時引入了過期機制和批次操作等實用功能。然而,新機制也伴隨着新的責任——用戶需要提升安全意識,錢包與 DApp 需要協同保護用戶免受籤名攻擊。未來,隨着帳戶抽象等更進一步的技術發展,代幣授權管理有望變得更加無感且安全。

Autor: John
Tradutor(a): Sonia
Revisor(es): Pow、KOWEI、Elisa
Revisor(es) de tradução: Ashley、Joyce
* As informações não se destinam a ser e não constituem aconselhamento financeiro ou qualquer outra recomendação de qualquer tipo oferecido ou endossado pela Gate.io.
* Este artigo não pode ser reproduzido, transmitido ou copiado sem fazer referência à Gate.io. A violação é uma violação da Lei de Direitos de Autor e pode estar sujeita a ações legais.

深入解析 ERC-20 授權模型:Permit 與 Permit2 的原理、風險與比較

新手4/25/2025, 6:38:53 AM
ERC-20 代幣的授權機制正持續進化!從傳統的雙交易 approve 模式,到 Permit 引入的鏈下籤名授權,再到 Uniswap 開發的通用型 Permit2 合約。這些創新不僅簡化了用戶操作流程、節省了 Gas 成本,更通過批次處理、時效控制等功能增強了安全性。然而,新技術也帶來新的挑戰,特別是籤名釣魚攻擊的風險。本文全面剖析這些授權機制的原理、優劣與應用場景,並提供實用的安全建議,幫助用戶在便利與安全間取得平衡。

區塊鏈世界中,我們常需要授權(allowance)機制來讓智能合約代我們花費代幣。例如,在去中心化交易所(DEX)交易代幣時,用戶必須先授權交易合約可以從自己的錢包轉出特定數量的代幣。傳統的 ERC-20 授權流程需要用戶提交一筆 approve 交易,然後再提交實際的交換交易,流程繁瑣且耗費額外的 Gas。然而,爲了改善用戶體驗與安全性,以太坊社群提出了基於籤名的授權機制 ——Permit(例如 EIP-2612)與進一步的 Permit2 方案。這些新機制允許用戶透過鏈下籤名(off-chain signature)來授權代幣使用權,避免額外的鏈上交易。

在本篇文章中,我們將從基礎概念出發,介紹傳統 ERC-20 授權的原理與局限,再深入講解 Permit 與 Permit2 的工作方式、優缺點,以及它們如何增進效率與安全。同時,我們也會分析相關的安全風險(特別是籤名釣魚攻擊案例)並提供防護建議。希望使剛入門區塊鏈或加密投資的新手,也能理解這些重要的技術演進。

ERC-20 授權模型基礎

在開始討論 Permit 之前,先讓我們了解傳統 ERC-20 代幣的授權模型是如何運作的,以及其中存在的問題。

傳統 ERC-20 Approve 的運作方式

ERC-20 是以太坊代幣的標準,其中定義的 approve 和 transferFrom 函式提供了代幣授權機制。所謂授權,是指代幣持有人(owner)允許另一個帳戶(通常是智能合約,稱爲spender)從自己的餘額中代爲轉出一定數量的代幣。基本流程如下:

  1. 授權(approve):代幣持有人呼叫代幣合約的 approve(spender, amount) 函式,在代幣合約的內部 allowance 對映中記錄授權額度。例如 A 授權 Uniswap 合約可花費自己最多100枚代幣,則 allowance[A][Uniswap] = 100。這步驟需要一筆鏈上交易,由 A 支付 Gas 費。
  2. 代付(transferFrom):之後,當 Uniswap 等需要代替 A 花費其代幣時,就由 Uniswap 合約呼叫 transferFrom(A, B, amount)。代幣合約會檢查 allowance[A][Uniswap] 是否足夠,若足夠則從 A 帳戶轉出 amount 給 B,並減少相應的授權額度。

Approve 模式的局限與挑戰

透過上述雙步驟模型,用戶不需將私鑰交給他人,就能讓合約代操作資金。然而,這種傳統模型也帶來一些實際問題:

需要兩次交易,體驗不佳
當用戶第一次在某應用使用某代幣時,都得先進行一次獨立的授權交易,然後才能進行真正的操作(例如交易、質押等)。這意味着用戶在使用新 DApp 時,錢包會跳出兩次確認,而且要支付額外的 Gas。對新手而言,這額外的一步驟容易造成困惑與不便。

授權管理分散
如果用戶在多個 DApp 中使用同一代幣(例如先在 Uniswap 交易,又到另一個 DeFi 協議存款),即使都是自己的代幣,每個 DApp 仍要求分別的授權交易,導致重復授權浪費時間與費用。

且每個協議各自爲政地要求授權,用戶錢包很難統一管理。目前有一些工具(如 Revoke.cashDeBank)能顯示所有授權,但普通用戶未必知曉;加上每次撤銷也需要一筆鏈上交易完成,成本不低,因此很多舊的授權往往被遺忘。

無限額授權的風險
爲了避免頻繁授權交易,不少應用建議用戶直接「無限額」授權,即授權 spender 可以支配錢包中該代幣的全部餘額,且不限時間。雖然這樣用戶後續無需再授權,但安全風險很高:一旦該 DApp 或合約被攻擊,攻擊者就能利用無限授權轉走用戶所有該代幣。

上述問題促使開發者尋找更佳方案。理想情況是:用戶只需一次籤署意願(最好不額外花 Gas),就能完成授權與操作,同時授權範圍與時間應盡量受控,降低不必要的風險。在這背景下,ERC-20 Permit 應運而生。

Permit:以籤章授權的 ERC-20 擴充 (EIP-2612)

Permit 這個構想最初由 快點 穩定幣合約引入,後來標準化爲 EIP-2612。簡而言之,Permit 允許用戶透過鏈下籤名來授權代幣轉移,省去單獨發送 approve 交易的麻煩。以下我們深入介紹其機制與特色。

Permit 的運作原理

Permit 是一種利用數位籤章進行授權的機制。以 EIP-2612 的標準實現爲例,每個支持 Permit 的 ERC-20 代幣合約內部增加了一個 permit() 函式,大致如下:

功能許可(
地址所有者、地址花費者、
uint256 值,uint256 截止日期,
uint8 v、bytes32 r、bytes32 s
) 外部的;

其中 owner、spender、value 分別是授權的持有人、被授權者、額度數量,deadline 是籤名期限,後面的 v, r, s 是籤名數據(即 電子CDSA 籤章的組成部分)。透過 Permit 機制,用戶跳過了獨立的 on-chain 授權步驟,只需籤名(不用付 Gas)並在隨後操作時附帶該籤名即完成授權,達到了「一次操作,雙重效果」的目的。


Permit 使用流程(來源: Gate Learn 創作者 John)

相較傳統 approve,Permit 省去一次鏈上交易,用戶不再需要提前發出 approve 交易,節省了時間和 Gas 成本。並且提供更細粒度的授權控制,例如用戶可籤一個只允許花費 50 USDC、5 分鍾內有效的 Permit,用於一次性操作。過期後即使籤名未被用,攻擊者也無法濫用,減少授權風險。目前許多 DeFi 協議(如去中心化交易所、借貸平台等)均已逐步支援 Permit 流程。知名例子包括 Uniswap V2/V3 流動性憑證代幣、DAIUSDC 等均實裝了 EIP-2612 標準,使其在各種操作中都可透過籤名授權一步完成。

然而,Permit 最大的限制是必須由代幣合約本身實現。如果一個 ERC-20 代幣的開發者沒有在合約中加入 permit () 方法(即不支持 EIP-2612),那該代幣就無法使用籤名授權。由於 EIP-2612 是在 2020 年提出,許多較早發行的代幣並不具備這功能,而即便是之後的新代幣也不見得都實裝了它。這導致 Permit 的適用性受到限制:不支援的代幣仍得沿用傳統 approve 模式。

另外,用戶錢包軟體需要正確識別並顯示 Permit 籤名資訊(EIP-712 格式)。大多數主流錢包現在已支持,但仍有部分錢包或不夠友善,可能僅顯示原始資料而非人類可讀訊息。這可能導致用戶看不懂自己籤了什麼。如果錢包沒有針對 EIP-2612 提供清晰界面,會降低用戶對籤名授權的理解。同時如果在平行部署(如不同鏈上同地址合約)情況下,籤名可能在其它環境被重新使用。因此用戶還需要確保籤名中鏈 ID、合約地址都是當前環境,以免籤給 A 鏈代幣的許可被 B 鏈上相同地址合約濫用。

基本上,Permit 大幅改善了 ERC-20 授權的效率和靈活性,被視爲 Gasless Approve 的重要裏程碑。但它並非萬能:需要代幣支持,以及新的風險也隨之而來。接着我們將看看 Uniswap 發布的 Permit2,如何在 Permit 基礎上更進一步。

Permit2:通用授權管理合約

隨着 Permit 機制的普及,一個新的問題出現:如何讓不支援 Permit 的代幣也享受籤名授權的便利?爲了解決這個問題,同時優化多種情境下的授權體驗,Uniswap 團隊在 2022 年推出了 Permit2。 Permit2 不是單一代幣的功能,而是一個獨立的授權管理智能合約。它的目的是成爲各種代幣授權的中介,提供統一、強化的授權功能。下面我們來剖析 Permit2 的原理與特色。

Permit2 的運作原理

Permit2 可以理解爲一個授權中繼服務。核心思想是:用戶對 Permit2 合約進行一次授權,之後由 Permit2 合約替用戶管理對各應用的子授權。具體流程如下:

  1. 一次性授權 Permit2:用戶針對每個代幣,使用傳統方式調用其 approve (Permit2, max_amount)。通常建議無限額或較大額度,因爲這是主授權。一旦完成,Permit2 合約在該代幣上就擁有了可以代表用戶調用 transferFrom 的權限。這步需要鏈上交易,但只需做一次。
  2. 用戶鏈下籤名子授權:當用戶希望與某 DApp 進行特定操作時(例如用 Uniswap Universal Router 進行多代幣交換),用戶針對此次操作透過 Permit2 的規範籤署一份離線授權消息。籤名內容包括允許的代幣、金額、授權給的目標(spender,例如特定 DApp 合約)以及有效期限等資訊。
  3. DApp 使用籤名請求轉帳:DApp 接收到用戶籤名後,在需要動用代幣時,不直接呼叫代幣合約,而是呼叫 Permit2 合約提供的函式(例如 permitTransferFrom)。該函式會驗證用戶籤名資料,確認此次操作在用戶授予的權限之內(代幣、金額、截止時間皆未超限)。驗證通過後,Permit2 合約遂利用自己之前獲得的主授權,去調用代幣的 transferFrom,將代幣從用戶轉給指定接收方。重點:Permit2 合約本身就是 spender,它用自己的權限完成對代幣的轉移,只是在轉移前增加了一道對籤名的核驗。
  4. 完成操作:一旦 Permit2 執行 transferFrom 成功,資金便順利從用戶轉出至 DApp 或指定地址。對前端用戶而言,他只是在交易中提供了一個籤名,後續動作均由合約代理完成。


Permit2 授權流程示意。用戶僅需針對每種代幣執行一次最大額度的主授權給 Permit2,之後與各應用(Uniswap Universal Router 或其他協議)互動時,只需在交易中附帶 Permit2 籤名即可完成授權與轉帳,無需額外的鏈上 approve。 Permit2 合約會驗證籤名並利用其持有的主授權執行轉帳。 (來源:Introducing Permit2 & Universal Router

透過上述模式,Permit2 將 EIP-2612 的籤名授權概念推廣到所有 ERC-20 代幣,無論該代幣本身是否實裝 permit() 方法。只要用戶願意事先授權 Permit2 合約管理,就能用籤名進行後續操作。值得一提的是,Uniswap 將 Permit2 設計爲無主、不可升級的合約,已部署在以太坊主網及多條二層上,地址都相同。這意味着所有應用使用的其實是同一個 Permit2 實例,實現真正的「一次授權,多處通用」。

Permit2 的特色功能

作爲新一代授權系統,Permit2 不僅達成所有代幣的籤名授權,還提供了額外的功能來增進安全與易用性。主要特色包括:

授權自動過期
Permit2 的所有授權記錄都可以設定時間戳過期。用戶在籤名時即可指定此子授權有效至何時。一旦超過期限,Permit2 將拒絕該籤名,即便主授權還在。這有效解決了傳統無限授權掛着不管的隱患。

一次性籤名轉移
Permit2 提供直接籤名轉帳模式,用戶可以用籤名授權直接完成某次代幣轉移給特定接收者,而無需事先設置 allowance。這適用於一次性的支付場景:用戶籤一個消息授權轉 100 個代幣給好友地址,好友或中介即可拿此籤名從用戶處扣款。一旦執行,籤名作廢,不留長期許可。

批次授權與轉帳
Permit2 考慮了效率,允許批量處理多筆授權或多筆轉帳。例如用戶可一份籤名授權多種代幣不同額度給同一協議;或在一次交易裏執行多個代幣的轉帳操作。對高級用戶而言,這可節省更多 Gas 和步驟。

批量撤銷
除了批量授權,也可以在一次交易裏批量撤銷多個代幣/多個應用的許可。這對於清理歷史授權非常便利。

額外資料見證
Permit2 還提供 permitWitnessTransferFrom 等介面,允許在籤名中攜帶其他見證資料進行校驗。這可用於更復雜的場景,例如訂單籤章中夾帶特定交易細節,避免籤名被移花接木在不同情境下使用。

透過這些功能,Permit2 不僅重現了 Permit 的所有好處,還加強了靈活性與安全控制。尤其自動過期與一次性籤名轉帳,使最小必要授權成爲常態,降低長期風險。

總結而言,Permit2 可視爲對傳統 Permit 機制的擴充與補強,兩者的主要差異包括:

Permit2 的應用生態與採用情況

自 Uniswap 推出 Permit2 以來,已有多個項目開始整合這一機制,加速了行業標準化的趨勢 。根據 Dune Analytics 的最新數據,截至 2025 年 4 月,已有​超過 310 萬個以太坊主網地址對 Permit2 合約授予過授權。​這反映出該合約的使用範圍相當廣。


Permit2 的應用生態與採用情況(來源:Dune Analytics

例如,Uniswap 自己就將 Permit2 集成到其 Universal Router 中,實現單筆交易完成多代幣及 NFT 交換。透過 Universal Router,用戶能在一次交易中串聯多步操作,像是用三種代幣交換兩種目標代幣並購買 NFT,而中途所有授權需求都由 Permit2 籤名滿足。這極大簡化了操作流程,也降低總 Gas 成本,是 Permit2 提升 UX 的直接體現。

另外,隨着 Permit2 開源並在各鏈部署,越來越多錢包與 DApp 工具開始支援 Permit2。Revoke.cash 等安全工具已更新服務,讓用戶能檢視和撤銷 Permit2 的授權紀錄。 Matcha 也引入了 Permit2 的 SignatureTransfer 模組,實現了「一次性授權」機制。

盡管有上述進展,Permit2 的普及仍面臨挑戰。一方面,開發者需要額外時間整合:相較直接用 ERC-20 的 approve,對接 Permit2 需處理籤名邏輯,增加了開發負擔。小型團隊可能因此卻步。另一方面,用戶教育也很重要:許多使用 Permit2 的 DApp 需要教導用戶籤名意義。目前看來,Permit2 的一體化優勢足以抵消這些摩擦,但全面滲透仍需時間推動。

Permit2 與 Session Key、ERC-4337 等新方案的比較

回顧過去 8 年,ERC‑20 授權機制從「多筆交易」走向「無感籤名」、再到「智能帳戶」,每一次迭代,都試圖在「用戶體驗(交易/籤名次數)」與「Gas 成本」之間取得更佳平衡。以下是各技術對比:


目前除了 Permit2,比較值得關注的新興授權方案是 Session Key(會話金鑰)及 ERC-4337 帳戶抽象,都提供了不同的解決思路。

Session Key 比較特別,他其實不算授權模型,而是屬於「錢包/帳戶層」的暫時金鑰機制——它並不改動代幣合約,而是讓錢包產生一組短期、限額的臨時私鑰,只能執行特定操作。適用於遊戲道具支付、單次授權的微額支付等場景。它的重點在於降低單次授權風險,是爲了用戶臨時交互而量身打造,不同於直接改合約的 Permit/Permit2。

ERC-4337 則將授權邏輯直接內建在智能帳戶中,允許使用者自行設定授權條件,甚至省略傳統的授權步驟,透過更靈活的 UserOperation 與 Paymaster 機制,達到更佳的安全性與使用體驗。

從未來發展趨勢來看,這些不同方案可能會並存,短期內 Permit2 將持續成爲各類新興 DApp 的標準方案,透過一次性授權提高使用流暢度,並隨之推動安全教育與工具支援,降低釣魚風險。中期而言,隨着 ERC-4337 等帳戶抽象的普及與更多 Layer 和主網支援,使用者可望擺脫傳統 ERC-20 approve 限制,更精細且智能化地管理授權條件,使 Permit2 的需求逐漸降低。

長期願景是達到如 Web2 般直覺且無感的授權體驗,用戶點擊按鈕即可自動完成背後所需的授權操作,僅在風險較高時才收到明確提示。爲達成此目標,底層協議、錢包和 DApp 需要持續協作創新與整合。 Permit2 是這個過渡過程中的重要一步,但要達到理想狀態仍有漫長的路要走。在這過程中,社群和開發者應保持務實的態度,充分理解各方案的優缺點,協同推動更安全、便利的授權環境。

整體而言,Permit2 提供了當前可即刻運用的解決方案,而 Session Key 和 ERC-4337 則代表了更長期且本質上的授權機制改進方向。

籤名授權的安全風險

任何新技術都伴隨新的風險。 Permit 和 Permit2 雖提升了效率,卻也引入了籤名授權被攻擊的潛在風險。

在 Permit2(以及 EIP‑2612 Permit)等籤名授權方案中,爲了降低籤名濫用與重放攻擊風險,核心合約設計了多層防護機制:

1. Nonce 防重放

Permit2 爲每組 (owner, token, spender) 維護獨立的 nonce 計數器,用戶每次籤名後,對應的 nonce 就遞增。攻擊者手中持有舊籤名時,只要合約端 nonce 已更新,該籤名即失效,無法再被重放執行。

2. Deadline 失效機制

籤名資料中必須包含 deadline 欄位,合約在驗證籤名時會檢查當前區塊時間是否 ≤ deadline。一旦過期,即使籤名與 nonce 正確,也會被拒絕執行,避免長期授權造成的潛在損失。

3. 允許範圍(Allowance)細化

Permit2 籤名可指定「最大授權額度」,合約在轉帳前會比較實際操作數量是否 ≤ 籤名中允許的上限。單次操作後,不會自動消耗所有額度,用戶可分批使用,降低一次性全額授權風險。

4. 批次與一次性模式

除了持續授權(allowance)模式,Permit2 同時支援「一次性籤名轉帳」(SignatureTransfer),該籤名在執行後即失效,不留後續授權。在一次性支付場景下,籤名只對本次轉帳生效,再也不會被重放或濫用。

透過上述多重機制,籤名授權在提高 UX 與節省 Gas 的同時,也在合約層面大幅降低了「重放」、「過度授權」與「長期失效」等典型風險。

不過,即便合約端具備嚴密設計,社交工程(又稱「釣魚」)仍是最難防的環節。接下來,我們將用常見釣魚手法,說明攻擊者如何誘導用戶在毫無察覺的情況下,提交惡意籤名,濫用 Permit2 授權,並提出防範建議。

籤名釣魚攻擊都是怎麼發生的?

籤名釣魚是指攻擊者誘騙受害者籤署特定訊息,以取得對方資產控制權。在傳統模式下,攻擊者可能引誘你執行惡意合約或提交惡意交易;而在 Permit 時代,籤一個惡意授權就足以讓幣被轉走。以下說明可能的攻擊過程:

  1. 受害者誤點擊了一個仿冒的知名 DEX 網站(釣魚網站)。該假網站在用戶嘗試操作時,彈出了一個錢包籤名請求,宣稱是「確認登入」或其他看似正常的用途。但實際上,這請求是一份 Permit2 授權籤名:內容是授權攻擊者的合約可不限額度提取受害者的 USDC,期限較長。

  2. 受害者因缺乏警覺直接點擊籤名。此時,他並未花費任何 Gas,鏈上也尚未有動作,因此毫無異常跡象。

  3. 攻擊者拿到籤名後,立刻呼叫了 Permit2 合約的 permit () 函式,提交該籤名。 Permit2 合約驗證通過後,在受害者地址下記錄了對攻擊者合約的授權許可(相當於受害者對攻擊者合約執行了一次 approve,但這步是攻擊者替他完成的)。這步操作依然可能不被受害者察覺,因爲從受害者觀點,他的錢包沒發生任何支出,只是區塊鏈上自己的代幣 Allowance 映射被更新了。

  4. 隨後,攻擊者立即由自己的地址發起 transferFrom (受害者,攻擊者地址,若幹金額) 的交易,透過剛才 Permit2 的許可,成功將受害者錢包裏的 USDC 轉走。受害者此時才驚覺資產被盜,但爲時已晚。

在上述攻擊中,用戶完全沒有執行任何明顯的「轉帳」或「授權」交易,但資產卻莫名其妙地轉出。關鍵就在於籤名本身成了授權。攻擊者精心僞裝籤名請求,使其看似與一般的操作無異,讓人放下戒心。然而,一旦籤署,後果就如同把資產的門鎖鑰匙交給了對方。

更惡劣的是,一些攻擊者會使用技術手段來提高隱蔽性。例如,攻擊者會利用了以太坊的 CREATE2 機制,每次釣魚爲每個受害者生成獨一無二的惡意合約地址。這使傳統黑名單難以及時辨識,因爲每次攻擊地址都不同。

大部分近年來的釣魚盜幣事件都與籤名授權有關。例如,Scam Sniffer 2024 年初統計,一個月內就有超過 5500 萬美元的資產因這類籤名釣魚被盜。 Permit2 啓用後,攻擊者更加積極誘導用戶籤署 Permit/Permit2 許可,導致短時間內許多用戶中招。可見,籤名授權一旦被濫用,殺傷力巨大且不易被察覺。

爲何籤名授權的釣魚風險會高於傳統模式?

傳統的惡意授權需要誘導用戶執行一筆鏈上交易,在錢包中往往明顯提示「你正在給 XXX 授權使用你的代幣」並需支付 Gas,稍有經驗的用戶可能警覺。而籤名請求在錢包介面中可能被描述爲「資料籤名要求」而非金錢行爲,用戶往往降低戒心。此外籤名不耗 Gas,使得攻擊嘗試成本低,攻擊者可以大規模發起釣魚而不擔心費用損失,只要有少數成功就賺到了。

另外,不同錢包對 EIP-712 訊息的顯示差異很大。一些現代錢包(如 MetaMask 新版)會解析出字段,例如提示「授權某合約花費你多少某代幣」,但也有不少錢包僅顯示十六進制資料或簡單描述,使一般用戶難以判斷真僞。攻擊者會利用這點,在訊息中塞入欺騙性的說明(例如假裝是 NFT Mint 籤名),讓人誤籤。

由於籤名授權不會立即體現在用戶資產變化上,受害者往往不立即察覺。而攻擊者可以選擇最佳時機下手。例如,一些攻擊者拿到籤名後並不立刻執行,而是等待受害者錢包有更多資產或在特定時機再用,使追查更困難。另外,如果籤名有較長的有效期,攻擊者甚至可以等待價格波動後再執行,以獲取更大利益(這在金融上稱爲給攻擊者一個免費期權,因此 Permit 籤名多半要求帶上短 deadline 以降低此風險。

特別針對 Permit2,因其允許一份籤名授權多個代幣,這對用戶閱讀理解增加了困難。假設一個釣魚網站請你籤一個 Permit2 消息,介面上可能只強調其中一兩種代幣用途,卻在同一籤名中暗藏對其他代幣的大額授權。如果錢包沒有列出全部細節,用戶很容易忽略。此外,有些惡意籤名甚至授權的是所謂「WalletGuard」之類看似正當的合約名稱,實則是攻擊者部署的合約,專門用來騙取許可。

用戶如何保護自己免受籤名攻擊?

牢記籤名 = 蓋章同意的原則,不要因爲籤名不花 Gas 就掉以輕心。每次錢包彈出籤名要求時,都應仔細閱讀錢包提供的訊息明細。確認發起籤名的網站或 DApp 是否可信,訊息內容是否與自己預期操作一致。例如,如果你只是要登入網站,那籤名內容應該是人類可讀的登入訊息(許多 DApp 登入會用特定字串),而不是一堆代幣地址和數字。

此外,確保使用的錢包軟體能支援 EIP-712 資料顯示。目前主流的 MetaMask、TrustWalletLedger Live 等都在改進顯示籤名內容的體驗。例如 MetaMask 已能將常見許可訊息解析成人話。如果你的錢包在籤名時只秀出一長串16進位數據,建議更換或更新。硬體錢包用戶也要注意固件更新,以支援新格式,否則螢幕上可能無法正確顯示資訊。

不論是 Permit 籤名或 Permit2,多數情況下你可以自行調整授權參數。不要籤無限額(value = 2^256-1)除非非常必要,改爲僅授權實際所需數量再稍留餘裕即可。也不要將 deadline 設得過長。這樣即使籤名意外落入他人之手,能造成的損失也有限,過期後籤名失效。

養成習慣,定期使用工具(如 Revoke.cash、Etherscan Token Approval、各錢包內建功能)查看自己地址對外授權情況,包括傳統 approve 和 Permit2 許可。如果發現異常或不再需要的授權,及時撤銷。對於 Permit2,撤銷需注意兩層:一是主授權(你對 Permit2 合約本身的 approve,可考慮在不用時將其設 0);二是子授權(Permit2 代你給各 DApp 的許可,多數有自動過期,但如有效期很長,也可以透過工具提前終止)。尤其如果你懷疑曾籤署可疑 Permit,最安全的做法是立刻調整 nonce:可以對同一 spender 籤發一個新的 permit(哪怕給 0 額度),以佔用掉攻擊者手中的舊籤名的 nonce,使其作廢。

對於不熟悉的網站或應用,一定提高警覺。不隨意點擊來路不明的連結,尤其是社群平台上的廣告或私訊提供的「福利」、「mint 活動」等連結。許多釣魚就是透過冒充官方帳號發布虛假活動連結,一旦連入就誘導籤名。養成習慣直接輸入常用 DApp 官方網址,或使用書籤,避免被假網站魚目混珠。

總而言之,權衡方便與安全很重要。 Permit 類技術固然便利,但用戶端的風險防範不能松懈。隨着環境成熟,錢包產品和瀏覽器插件也在開發針對籤名釣魚的防護,例如有的會在你籤名包含巨大金額時警示。未來希望在技術與教育雙方面共同降低此類攻擊的發生。

結語

從傳統 ERC-20 授權模型的不足,到 Permit 的誕生,再到 Uniswap Permit2 的創新,我們見證了以太坊生態爲改善用戶體驗和安全性所做的努力。 Permit2 通過鏈下籤名大幅簡化了代幣授權流程,減少重復授權和無限許可的風險,同時引入了過期機制和批次操作等實用功能。然而,新機制也伴隨着新的責任——用戶需要提升安全意識,錢包與 DApp 需要協同保護用戶免受籤名攻擊。未來,隨着帳戶抽象等更進一步的技術發展,代幣授權管理有望變得更加無感且安全。

Autor: John
Tradutor(a): Sonia
Revisor(es): Pow、KOWEI、Elisa
Revisor(es) de tradução: Ashley、Joyce
* As informações não se destinam a ser e não constituem aconselhamento financeiro ou qualquer outra recomendação de qualquer tipo oferecido ou endossado pela Gate.io.
* Este artigo não pode ser reproduzido, transmitido ou copiado sem fazer referência à Gate.io. A violação é uma violação da Lei de Direitos de Autor e pode estar sujeita a ações legais.
Comece agora
Registe-se e ganhe um cupão de
100 USD
!