BTC
ETH
HTX
SOL
BNB
查看行情
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

對EIP-3074 的批評以及一種簡單的替代

以太坊爱好者
特邀专栏作者
本文約2726字,閱讀全文需要約4分鐘
為什麼簽署一個AUTH commit 所帶來的風險高於簽署一個與存在漏洞/惡意合約相關的事務?
AI總結
展開
為什麼簽署一個AUTH commit 所帶來的風險高於簽署一個與存在漏洞/惡意合約相關的事務?

對於開發者來說,AUTH/AUTHCALL 機制非常具有吸引力。它可以讓人們創建調用者來實現不同的批量處理策略(例如,支持多個nonce 來實現更好的並行性)、gas 抽像模型和復雜的賬戶抽象方法等。

這種靈活性源於這一機制賦予了開發者極大的自由。 AUTH/AUTHCALL 機制不要求開發者遵循特定的模式,而是要求用戶簽署一個commit 哈希值(commit 內容將由調用者來解析),讓開發者基於commit 自行設置限制。

為什麼簽署一個AUTH commit 所帶來的風險高於簽署一個與存在漏洞/惡意合約相關的事務?

為什麼簽署一個AUTH commit 所帶來的風險高於簽署一個與存在漏洞/惡意合約相關的事務?

用戶在簽署與合約相關的事務時,所承擔的風險是已知的,即,可能會損失在該合約控制範圍內的資產。比方說,用戶給一個ERC 20 合約簽署了批准事務,授權惡意的DEX 合約。這個惡意DEX 合約就可以提走用戶在ERC 20 合約中的全部餘額。但是,它無法從該用戶的其它ERC 20 合約中提走代幣,除非得到該用戶的批准。它也不能代表用戶進行其它操作,因為這也需要專門獲得用戶的批准。

相較之下,EIP 3074 不僅要求用戶簽署“空白支票”,而且假設調用者是誠實且沒有漏洞的。一個惡意/存在漏洞的調用者可以代表用戶執行任何操作—— 訪問用戶持有的資產,代表用戶進行投票,控制用戶所有的合約等。

更糟糕的是,調用者隨時都可以作惡,因為nonce 實現是由調用者控制的。存在漏洞/惡意的nonce 邏輯實現可以重放用戶過去的事務。如果commit 驗證的其它部分的邏輯也存在漏洞,調用者就可以利用這個nonce 邏輯實現來代表用戶執行任何操作。即使漏洞被發現,用戶也無法撤回空白支票。這個外部賬戶(EOA)已經被永久入侵了。

編寫一個正確的調用者程序很難,而且我們幾乎可以肯定,調用者會不定期出現錯誤,從EIP 3074 最後列出的調用者應該警惕的檢查/漏洞/情況非詳盡清單中可見一斑。這份清單勢必會變得越來越長,很可能伴隨著痛苦的發現過程。

治理劫持示例

二級標題

治理劫持示例

  • 惡意去中心化交易所EveSwap 為其用戶編寫了一個調用者程序。這個調用者程序通過空投EVE 代幣來為用戶提供gas 資助,並批量處理用戶的批准和轉賬事務。

  • EveSwap 的調用者程序看似無害,而且永遠不會竊取用戶的代幣,因為這樣馬上就會露餡。

  • 用戶很開心。交易都成功了,交易費也很便宜。幾個月來平安無事。

  • 然而,每當有人使用EveSwap 交易AliceSwap 的治理代幣ALI 時,會自動將用戶的AliceSwap 投票權委託給EveSwap。

  • 二級標題

  • 二級標題

跨鏈重放示例

EIP 3074 合理地建議commit 應該包含chainid。但是,這是由調用者,而非協議執行的。在另一條鏈上有著相同地址的調用者可能會跳過該檢查(或與此相關的檢查)。

  • EveSwap 在兼容EVM 的BobSpongeChain 上運行,後者支持EIP 3074。 EveSwap 在BobSpongeChain 上部署了一個誠實的調用者。

  • 用戶使用該調用者在BobSpongeChain 上交易,然後使用橋將資產轉移到以太坊上。

  • EveSwap 使用同一個部署密鑰在以太坊上部署了另一個地址相同的調用者。這個在以太坊上的調用者不會檢查commit,只會檢查ownerOnly,並充當其所有者的通用AUTH/AUTHCALL 代理。

  • 這樣一來,EveSwap 就可以劫持用戶在以太坊上的外部賬戶並捲走他們的資產了。

  • 二級標題

    二級標題

我們還能採取什麼別的手段?

我的提議是實現一個更明確的機制,在協議層面強制規定commit 的含義。 commit 結構將是類型化的(如EIP 712 所述),錢包會以用戶可讀的形式將commit 呈現出來。用戶可以確切地知道事務是什麼樣子的,並確信這個事務不會在任何鏈上重放,無需依賴於調用者程序開發者的品行和能力。

一個可能的實現:

AUTH 將使用包含授權調用列表的類型化結構代替commit 哈希值。每個調用都將指定{nonce,to,gas,calldata,value,chainid}。簽名將被驗證,整個授權調用列表將保存為authorized_transactions 而非authorized 地址變量。

AUTHCALL 將得到一個新的參數index,該參數指向最後一個AUTH 創建的列表中的地址。

利:

利:

  • 用戶可以清楚地了解情況。

  • 安全性由協議保障。

  • 弊:

  • 弊:

  • nonce 實現,不支持並行。

  • 複雜調用者程序的事務處理起來很繁瑣,因為用戶必須查看並接受整個調用列表。

  • 替代方案:完全避免硬分叉

    二級標題

替代方案:完全避免硬分叉

利:

利:

  • 無需硬分叉,可由智能合約和可以感知這些智能合約的節點支持。

  • 弊:

  • 弊:

  • 翻譯&校對: 閔敏& 阿劍

  • 原文鏈接:

原文鏈接:

https://blog.mycrypto.com/eip-3074/

翻譯&校對: 閔敏& 阿劍

翻譯&校對: 閔敏& 阿劍

ETH
開發者
歡迎加入Odaily官方社群