原標題：《引介 | 對 EIP-3074 的批評以及一種簡單的替代》
對於開發者來說，AUTH/AUTHCALL 機制非常具有吸引力。它可以讓人們創建調用者來實現不同的批量處理策略（例如，支持多個 nonce 來實現更好的并行性）、gas 抽象模型和複雜的賬戶抽象方法等。
這種靈活性源於這一機制賦予了開發者極大的自由。AUTH/AUTHCALL 機制不要求開發者遵循特定的模式，而是要求用戶簽署一個 commit 哈希值（commit 內容將由調用者來解析），讓開發者基於 commit 自行設置限制。
然而，這種靈活性是以犧牲安全性為代價的。在本文中，我想要介紹一種更簡單的替代方案。這個方案具備 AUTH/AUTHCALL 機制的絕大多數優點，但是風險遠低於後者。
為什麼簽署一個 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。
- 一旦授權人數達到某個閾值，EveSwap 就會通過治理提案劫持 AliceSwap。
EveSwap 用戶不太可能注意到這個過程，因為交易總是成功的，但是最終會給 AliceSwap 帶來毀滅性的打擊。
跨鏈重放示例
EIP 3074 合理地建議 commit 應該包含 chainid。但是，這是由調用者，而非協議執行的。在另一條鏈上有着相同地址的調用者可能會跳過該檢查（或與此相關的檢查）。
- EveSwap 在兼容 EVM 的 BobSpongeChain 上運行，後者支持 EIP 3074。EveSwap 在 BobSpongeChain 上部署了一個誠實的調用者。
- 用戶使用該調用者在 BobSpongeChain 上交易，然後使用橋將資產轉移到以太坊上。
- EveSwap 使用同一個部署密鑰在以太坊上部署了另一個地址相同的調用者。這個在以太坊上的調用者不會檢查
commit，只會檢查ownerOnly，並充當其所有者的通用 AUTH/AUTHCALL 代理。 - 這樣一來，EveSwap 就可以劫持用戶在以太坊上的外部賬戶並捲走他們的資產了。
用戶從未在以太坊上交易過，運行在 BobSpongeChain 上的調用者程序又經過了嚴格的安全審查。儘管如此，用戶還是丟失了全部資產。
以太坊通過 EIP 155 的重放保護來防範這種情況。AUTHCALL 沒有重放保護。由於所有 commit 檢查都交給調用者完成，我們失去了以太坊提供的一切交易保護。攻擊是在所難免的，因為保護措施很隨意。如果要接受EIP 3074，AUTH 消息必須明確包含 chainid，而非將其作為 commit 的一部分。
我們還能採取什麼別的手段？
我的提議是實現一個更明確的機制，在協議層面強制規定 commit 的含義。commit 結構將是類型化的（如 EIP 712 所述），錢包會以用戶可讀的形式將 commit 呈現出來。用戶可以確切地知道事務是什麼樣子的，並確信這個事務不會在任何鏈上重放，無需依賴於調用者程序開發者的品行和能力。
一個可能的實現：
AUTH 將使用包含授權調用列表的類型化結構代替 commit 哈希值。每個調用都將指定 {nonce,to,gas,calldata,value,chainid}。簽名將被驗證，整個授權調用列表將保存為 authorized_transactions 而非 authorized 地址變量。
AUTHCALL 將得到一個新的參數 index，該參數指向最後一個 AUTH 創建的列表中的地址。
用戶地址的 nonce 將隨 AUTHCALL 遞增。nonce 並非由調用者存儲，而是實際的賬戶 nonce。
利：
- 用戶可以清楚地了解情況。
- 安全性由協議保障。
- 依然支持批處理和賬戶抽象。
弊：
- nonce 實現，不支持并行。
- 複雜調用者程序的事務處理起來很繁瑣，因為用戶必須查看並接受整個調用列表。
不同的實現可能支持不同的 nonce 方案。但是，無論我們使用什麼機制，該機制必須由協議而非調用者執行。
無論如何都應該避免讓複雜調用者執行大量用戶調用。複雜操作應該作為普通的智能合約實現，而非嘗試實現使用多個外部賬戶調用的算法。
替代方案：完全避免硬分叉
還有一個選擇是完全避免 AUTH 機制，並通過 vbuterin 建議的另一種交易池來解決賬戶抽象和批量處理問題。
利：
- 無需硬分叉，可由智能合約和可以感知這些智能合約的節點支持。
- 可用於一切支持 EIP 3074 的實現，而不會引入額外的風險。
弊：
- 不向後兼容已有的外部賬戶。用戶需要部署一個合約錢包並將資產轉移到該錢包內。
除非要求在不遷移的情況下支持已有的外部賬戶，否則這個選擇看起來更安全。
（完）
（文內有許多超鏈接，可點擊左下 ”閱讀原文“ 從 EthFans 網站上獲取）
原文鏈接:
https://blog.mycrypto.com/eip-3074/
作者: Maarten Zuidhoorn
翻譯&校對: 閔敏 & 阿劍
本文鏈接：https://www.8btc.com/article/6654707
轉載請註明文章出處
