詳解EIP-3074對錢包與DApp的影響

作者：Nic @ imToken Labs

EIP-3074

更好、更安全的使用體驗

EIP-3074 讓EOA 能將控制權交給指定的合約，藉此獲得和合約一樣豐富的執行能力。

在EIP-3074 以前，EOA 每次送出交易就只能做一個操作，例如去approve ERC20 或是去Uniswap 兌換；在EIP-3074 以後，EOA 可以一次完成多個操作，或甚至出現以前無法想像的用途。

簡而言之，EIP-3074 讓使用體驗大幅提升，目前熟悉的授權方式也將被重塑，在維持使用體驗不變的前提下提升安全性。

而且透過EIP-3074，EOA 可以不必再自己送交易上鍊，也就不需要煩惱要先籌出ETH 來支付交易手續費的問題。

Invoker 合約

能夠獲得EOA 控制權的合約稱為Invoker 合約。當然不是任意的合約都能獲得EOA 的控制權：EOA 要用私鑰簽名，簽名內容會明確指定是哪個Invoker 合約，以及允許Invoker 執行的操作。

 EOA 簽章內容會明確指定哪一個Invoker 合約（invoker address）及授權該Invoker 合約的操作（commit）。

實際執行流程大概會長這樣：

• Alice 用她的EOA 私鑰簽名，然後將簽章內容及簽章交給Relayer。
• Relayer 帶上鍊到Invoker 合約執行。
• Invoker 驗證簽章，驗證通過後就能以EOA 的身份去執行操作，例如去approve USDC，然後去Uniswap 進行資產互換，最後再使用一些USDC 給Relayer 作為手續費。

註1：Relayer 為非必要，Alice 也可以自己帶簽名內容和簽名上鍊。

 Invoker 驗證完簽章並開始執行操作後，皆是以Alice EOA 的身份去執行，就像是取得該EOA （有限的）控制權。

不過要注意，執行完並不會增加該EOA 的nonce 值，所以同一個簽章有可能可以重複使用（只要EOA nonce 不變），因此Invoker 需要自己實作一套nonce 機制來避免重播。

如果Invoker 合約沒有防Replay，同一項授權就可以一直執行。

了解更多關於EIP-3074 實際的運作機制介紹可以參考：https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

用途

Batchcall

請使用者把原本該分為好幾筆交易的執行合併為一筆，省下多次授權簽名的過程以及一些Gas 成本。

註：這會需要DApp 也支援Batchcall 的功能，像是目前社群正在推的EIP-5792，否則DApp 把用戶當普通EOA 的話一樣只會每個操作都prompt 一次交易給用戶簽字。

了解EIP-5792，請複製連結到瀏覽器查閱：https://eips.ethereum.org/EIPS/eip-5792

Session Key

使用者也可以讓第三方在有條件限制下替他代為操作，如下圖中的delegate key 就是被授權的第三方；access policy 則是執行的限制條件，例如限制只能去操作Uniswap、每天最多轉走1 ETH、授權有效期限等等。

這些條件都是在Invoker 合約內設計並檢查，只要檢查能通過，第三方就能以使用者EOA 身分執行操作。

 Telegram Bot 可以給予特定權限，並以使用者EOA 為名執行操作。

Native ETH Permit

只要條件滿足（也就是Permit 簽章合法），就能以授權人EOA 身分去執行ETH 轉賬，達成原生ETH Permit 的效果。

Limit Order

使用者填好限價單條件，等到條件滿足就能以使用者EOA 身分去執行，包含approve 相關數位資產給DEX、去DEX 互換等等。和DEX 本身提供的Limit Order 相比，用戶不需事先送交易去approve 給DEX。

 Alice 成交訂單時會順便執行Approve，不再需要事先Approve。

把條件設計得更通用的話，就會變成像是Intent 合約：只要使用者指定的條件被滿足，任何人都能以他的EOA 身分去執行完成意圖。

只要Intent 條件被滿足，任何人都能以使用者EOA 名義去發起執行。

Social Recovery

讓使用者遺失EOA 私鑰時，能藉由當初她（Alice）簽好的EIP-3074 授權，搭配她授權的人（Husband 及Trust Agent）的簽名來將該EOA 的資產全部轉走。實際上Recover 的是（可轉移的）資產，而不是帳戶控制權。 EOA 私鑰遺失後該EOA 就無法再使用了。

當使用者遺失EOA 私鑰時，其他當初被授權的人可以簽署授權轉走EOA 的資產。

EIP-3074 的影響

改善資產授權的方式，甚至取代approve/permit？

DApp 目前都是以使用者是EOA 的假設去設計的：使用者必須「事先approve」且要「approve 足夠大的資產數量」給DApp 合約，如此使用者才不需要隨時保持在線、等待DApp 執行，以及不需要不斷重複approve，這對使用體驗有很大的提升。

例如條件觸發的應用程式像是限價單或DCA，使用者不一定會在條件符合時在在線，所以要事前先approve 夠大的資產數量讓DApp 合約去執行，而且可能是重複執行。

使用者必須事先approve DApp 足夠大的資產數量，才能方便DApp 使用他的錢去操作。 

但也因此必須相信DApp 或避免approve 給fake DApp，以及能即時移除approval。

或是後來出現的permit 模式，例如，EIP-2612或是非原生的Permit2，都是為了改善approve 模式的使用體驗及安全性：用戶不需再approve 很大的資產數量給各個DApp 合約（而且每個資產都要approve 一次），而是只需「簽一個名」就可以授權DApp 合約在「指定時間」內「提取指定數量資產」，如此不僅大大限縮了攻擊面，也大大提升了使用體驗。

了解更多EIP-2612 詳情，請複製下方連結至瀏覽器查詢：https://eips.ethereum.org/EIPS/eip-2612

Permit2 詳情，請複製下方連結至瀏覽器查詢：https://medium.com/taipei-ethereum-meetup/uniswap-permit2-introduction-858ae3dddf18

用戶只需鏈下簽名，並且能指定資產數量及有效期間，提供比approve 更好的使用體驗及安全性。

但事實上，不只是approve，permit 模式被利用作為詐騙攻擊手段的事件仍然層出不窮，：受害者誤簽了以為是要給DApp 用的permit 但實際上是給了攻擊者。

用戶在簽permit 時，只能看到要授權給誰，但不知道這會搭配什麼操作一起執行。

附註：另外目前的permit 設計並不相容重複性操作的DApp，例如DCA 或其他定期支付應用程式。這是因為permit 有防重播機制，所以轉帳完一次之後就無法再用同一個permit，等於是用戶要先為未來每一次重複性操作都預先簽好permit。

了解更多了解permit 模式被利用作為詐騙攻擊手段的事件，請複製下方連結到瀏覽器查詢：

https://x.com/realScamSniffer/status/1783027808723435727https://x.com/realScamSniffer/status/1784932506174967970https://x.com/realScamSniffer/status/174967970https://x.com/realScamSniffer/status/17867218962238962238962

不過EIP-3074 帶來了改變的契機：當DApp 開發者知道EOA 可以透過Invoker 做到各種複雜的操作之後，DApp 互動上的設計便不再需要為了提升使用體驗而犧牲安全性，例如“用戶事前approve 大筆資產數量」、「用戶簽個permit 訊息授權提款」。

取而代之的是使用者將DApp 操作與approve 綁在一起，透過Invoker 去進行原子化（Atomic）的執行：要不approve 和DApp 操作一起成功執行，要不一起失敗，沒有approve 單獨成功的可能，所以使用者可以很確信這次approve 就是給這次的操作。

而且使用者是使用鏈下簽名的授權方式，所以使用體驗和permit 是一樣的！這表示DApp 將不再需要permit 模式！未來錢包可以直接對permit 簽名請求進行封鎖或更嚴格的審查，不必再擔心是否會造成用戶用不了某些DApp（但反而因此被詐騙利用）。

使用者不再只單純授權某個地址，而是授權某個地址以及做哪些事，甚至可以看到模擬的執行結果。

註：這不表示可以完全阻絕詐騙！用戶一樣有可能被騙進詐騙網站，詐騙網站一樣可以組approve 或轉帳操作讓用戶簽名，但此時用戶至少可以看到這次簽名是要做什麼操作，錢包甚至可以透過仿真顯示執行結果並呈現給使用者，讓使用者可以明確知道誰會少了多少錢、誰會多了多少錢。相較於沒辦法知道要做什麼操作或甚至執行結果的permit， 使用者有了更多資訊去決定要不要授權。雖然不是完美的防治，但仍將是對現狀的大幅改善。

錢包如何處理EOA nonce

目前的EIP-3074 設計會把EOA nonce 值包含在簽名內容中，所以只要EOA 送了一筆交易上鍊執行，改變了nonce 值，原本的EIP-3074 授權就會直接全部失效。

如果使用者是去授權其他人來代為操作EOA，例如上面提到的Session Key 或是Social Recovery 方式，那EOA 的nonce 就要避免被改變，否則就要再重新簽一次所有授權並交給受託人，這對使用體驗及機制的穩健程度都有不小影響。

如果使用者是由自己授權操作的話，那就不用特別避免EOA nonce 被改變，因為EIP-3074 簽名還是和交易一樣預期要在某個期限之前去執行。只是錢包要多管理該EOA 的EIP-3074 交易：如果有EIP-3074 簽名正在等待上鍊，那EOA 自己上鍊的交易就要等待。

註：Invoker 合約自己會（也應該要）維護一套nonce 機制，所以簽名用過之後一樣得再簽一次，不管EOA nonce 是否改變。

Session Key 和Social Recovery 非常可能要等到EIP-3074 修改規則把EOA nonce 從簽章內容移除，才有可能被大模規採用。因此錢包只需專注在「使用者自己授權操作」的使用情境下，並把EIP-3074 簽名也當作交易一樣來處理，就不需要擔心要避免EOA 送交易、改變EOA nonce。

不過要注意，如果是使用者自己要帶自己的EIP-3074 簽名內容上鍊的話會有兩個缺點：

1. 用戶要簽兩次名：一次是EIP-3074 簽名，一次是上鍊交易的簽名。
2. 因為上鍊交易會在交易開始執行前就先將EOA nonce +1，所以用戶的EIP-3074 簽署的EOA nonce 要是預先+1 才能對得上因為自己上鍊而造成的EOA nonce +1。

因為自己上鍊會先把EOA nonce +1，所以開始驗證EIP-3074 簽章時就會因為EOA nonce 對不上而失敗。 

用戶自己上鍊前有提先把EIP-3074 簽名裡的EOA nonce +1，就能順利通過驗證。

總結與重點

• EIP-3074 讓EOA 獲得和合約一樣豐富的執行能力，開啟了許多新的應用場景。
• 這不僅讓使用體驗大幅提升，也將會改變現行的授權方式，讓它在使用體驗不變的前提下變得更安全。
• 而且EIP-3074 是單純簽名，使用者不一定要自己將簽名帶上鏈執行，也就不需要煩惱要先湊到ETH 來支付手續費。
• EIP-3074 的用途包含Batch Call、Session Key、Native ETH Permit、Limit Order、Social Recovery。這些許多原本都是EOA 不可能做到的，有些像是Limit Order 則是需要預先授權等較不安全的方式才能使用。
• EIP-3074 也將改變現行的授權方式。 approve 直接授權指定地址有無限期提領數位資產的權力，而且需要用戶EOA 先送出一筆交易執行approve，因此使用體驗及安全性都不佳；permit 只需要用戶簽名，且每次簽名都會指定資產數量及有效期限，在使用體驗及安全性上都比approve 提升不少。
• 但permit 依然被頻繁利用於詐騙，簽名時使用者只能知道要授權給哪個地址、多少資產數量及有效期，但不會知道這個授權是要「用來做什麼」的。 「用來做什麼」會是另一筆簽名（或交易），正常DApp 會讓用戶簽permit 及「用來做什麼」，但它們仍然會是兩筆不同簽名，因此被請求permit 簽名時，用戶及錢包都沒辦法知道這筆permit 會「用來做什麼」。
• 有了EIP-3074，用戶(1) 不需要事先approve 很大的資產數量給DApp，而是有操作時才approve，效果和permit 一樣；(2) 只是單純簽名且不需要煩惱湊ETH 付手續費，和permit 一樣；（3）每次approve 都是和指定的操作所綁定、一起簽名，用戶可以清楚知道這次approve 是“用來做什麼”，這會比permit 更為安全！
• 期望EIP-3074 能成功取代現行的approve 及permit 模式，提供給使用者更安全的授權方式。