作者：Nic @ imToken Labs
目標讀者：區塊鏈開發者
先備知識：
-
了解EOA 與合約的不同
-
了解EVM 與合約的執行過程
-
了解ERC-20 的approve 及permit 設計
-
詳情可參考：https://support.token.im/hc/zh-tw/articles/22181703417241
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/1783027808723435727
https://x.com/realScamSniffer/status/1784932506174967970
https://x.com/realScamSniffer/status/1786738218962223226
不過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 簽名內容上鍊的話會有兩個缺點：
-
用戶要簽兩次名：一次是EIP-3074 簽名，一次是上鍊交易的簽名。
-
因為上鍊交易會在交易開始執行前就先將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 模式，提供給使用者更安全的授權方式。
