技術層面解讀 EIP-3074 將如何提升以太坊用戶體驗

原文標題：《科普 | EIP-3074：提升以太坊用戶體驗》

如果你是以太坊上的活躍用戶，那麼你大概率會持有一些 （ERC 20）代幣，用來與以太坊生態中的各種 DeFi 項目進行交互。但是，這麼做的前提是你必須持有 ETH，因為 ERC 20 代幣無法用來支付以太坊的手續費。另外，在向智能合約發送代幣時，你通常需要執行兩個事務：一個用來_許可_目標合約使用你的代幣，另一個用來將代幣_轉移_到目標合約中。

EIP-3074 可以讓智能合約_代表_外部賬戶（就是普通的以太坊地址）發送事務，從而解決了上述乃至更多問題。

EIP 3074 引入了 AUTH 和 AUTHCALL 這兩個 EVM 指令。第一個指令基於 ECDSA 簽名設置環境變數 authorized，第二個指令則作為 authorized 發送調用。這本質上就是向智能合約授予外部賬戶的控制權。

通過 AUTH 和 AUTHCALL EVM 指令（又稱操作碼），智能合約可以基於已簽署消息獲得一個外部賬戶的授權，並代替該外部賬戶發送事務。這帶來了很多可能性，如：

*贊助事務**（又稱元事務）：支付來自另一個賬戶的交易的 gas。這樣一來，不持有 ETH 的地址也能發送代幣。

*批量事務**：通過單個調用發送多個事務。這樣可以確保兩個或以上的事務在同一個區塊中執行，還可以降低交易費。

*提升用戶體驗**：例如，你可以在單個事務中調用 approve 和 transferFrom。

不同於現有的解決方案，EIP 3074 不需要智能合約錢包。你可以直接將事務發送給負責執行事務的調用者（invoker）。調用者是無狀態的免信任型智能合約，而且不需要你事先將餘額發送到智能合約。EIP 3074 也沒有引入新的事務類型。從技術層面上來看，由於只引入了兩種新的 EVM 指令，EIP 3074 實現起來理應更容易。

只可惜 EIP 3074 依然在審查中，而且由於種種（安全方面的）擔憂，目前還不知道將於何時啟用。如果你現在想要體驗一把，可以使用 Puxi 測試網。在本文中，我將詳細介紹 EIP 3074 的工作原理。

如果你想看一下 EIP 3074 的實際運行效果，我編寫了一個（批量）事務調用者合約作為示例。點擊下方鏈接，即可訪問：

https://github.com/Mrtenz/transaction-invoker

請注意，這個合約沒有經過審計，而且只是概念證明。請勿在生產環境中使用。

AUTH 和 AUTHCALL 操作碼

EIP 3074 定義了兩個新的操作碼，可由智能合約調用：

• AUTH（0xf6）—— 基於簽名和 commit （提交）提出授權的外部賬戶。共有 4 個輸入參數：commit 以及簽名的 yParity、r 和 s。
• AUTHCALL（0xf7） —— 代替已授權的外部賬戶發送調用（事務） 。共有 8 個輸入參數：gas、addr、value、valueExt、argsOffset、argsLength、retOffset 和 retLength。與現有的 CALL 操作碼相似。

確認外部賬戶的授權需要來自該外部賬戶的簽名消息。調用 AUTH 的智能合約可以通過消息簽名復原出簽名者，然後將其設置成 authorized EVM 環境變數。這樣一來，該智能合約每次調用 AUTHCALL 時，調用者都會被設置成 authorized 地址。當被調用的智能合約調用 CALLER（例如，通過 Solidity 的 msg.sender）時，將由已授權的外部賬戶的地址而非調用者地址（智能合約）執行調用。

發送一個或多個事務的基本流程如下圖所示：

– 上圖顯示了 EIP 3074 的基本流程，其中調用者合約發送多個事務 –

1. 外部賬戶簽署授權消息；
2. 外部賬戶或其他 gas 支付方將事務數據和授權消息發送給調用者合約；
3. 調用者合約使用 AUTH 操作碼執行授權，並使用 AUTHCALL 操作碼發送事務。

將事務發送到合約的是誰並不重要，只要外部賬戶的簽名是有效的即可。因此，其他人（或賬戶）也可以發送事務。

請注意，目前無法使用 EIP 3074 通過外部賬戶發送 ETH。這樣做會極大地改變當前的一些重要假設，例如，檢查事務是否有效。調用者需要使用自己的 ETH 餘額來發送 ETH。但是，你可以將 ETH 發送給調用者，並由調用者代為發送。目前，AUTHCALL 操作碼所包含的 valueExt 欄位必須被硬編碼成 0。將來，如果找到適當的解決方案，我們可以更改這個欄位，允許調用者外部賬戶發送 ETH。

授權消息和 commit

為了執行授權，外部賬戶必須簽署特定格式的消息：

“` *

 0x03 || ||

（註：||用作位元組連接運算符。）

這個消息包含三個部分：一個魔術位元組（`0x03`）、填充成 32 位元組的調用者地址（執行 authorize 的智能合約的地址）以及一個 32 位元組的 commit。 _- 授權消息格式，包含一個 commit 示例 -_ 該 commit 描述了外部賬戶提交的數據，並且可以根據調用的某些屬性計算得出，例如，地址、值和 nonce 的哈希值。調用者合約可以根據屬性重新計算出 commit，如果這些欄位都正確的話，就會執行授權。 假設我們想要發送以下事務（JSON 格式）： [ { “to”: “0x6b175474e89094c44da98b954eedeac495271d0f”, “value”: 123, “nonce”: 0 }, { “to”: “0x4bbeEB066eD09B7AEd07bF39EEe0460DFa261520”, “value: 123, “nonce”: 1 }]

我們可以對這些欄位進行哈希計算（例如，用確定性的方式將它們連接起來，或使用 EIP 712 之類的規範），並將得到的哈希值用作 commit。

我們可以在智能合約中提供要發送的事務和授權消息的簽名，如 JSON 數據所示。合約函數就如下面這個例子所示：“` *function sendTransactions(Transaction[] calldata transactions, Signature calldata signature) external;

智能合約根據 transactions 重新計算 commit，並將這個 commit （連同簽名一起）提供給 AUTH 調用。此舉的目的是找回簽名者的地址，如果計算得到的 commit 無效，根據簽名找回的地址將是錯誤的，也就是說事務將失敗。

調用者對 commit 的安全性負全責。你可以將 0x0 作為 commit 來簽署消息，並授予智能合約對外部賬戶的完整訪問權。前幾版 EIP-3074 對 commit 的格式要求更為嚴格，包括重放保護等，但是後面為了提高靈活性已經將其移除。這就要求你在與調用者進行交互時必須信任對方。

局限性和安全隱患

由於能夠根據簽名更改 CALLER，EIP 3074 極大地改變了 EVM 的運作方式。這會為新合約和現有合約引入潛在漏洞。因此，EIP 3074 已經經過正式審計。

下文解釋了一些安全隱患。由於種種原因，EIP 3074 建議只與可信調用者交互。MyCrypto 等錢包界面提供可信調用者白名單功能。使用該功能的用戶只能為白名單內的調用者簽署授權消息。

弱 commit 和重放攻擊

正如上文解釋的那樣，EIP 3074 沒有為 commit 定義標準格式。調用者可以通過任意方式生成 commit。這意味著，調用者有責任確保 commit 的安全性，例如，抵禦重放攻擊。

如果 commit 不包含某種隨機數，攻擊者就可以輕鬆獲取已簽署的消息，再一次發送給調用者。惡意調用者完全不需要驗證 commit，就可以獲得外部賬戶的控制權。每次簽署消息時，請你務必謹慎。

EIP 3074 通過將調用者的地址包含在授權消息內，提供了最基礎的重放攻擊保護。這樣一來，惡意調用者就無法重放其他調用者的授權消息。

可升級調用者

EIP 3074 明確聲明調用者程序不可升級。如果調用者程序是可以升級的，攻擊者就可以部署另一個版本的調用者，在不驗證 commit 的情況下授予合約對外部賬戶的控制權。

重入攻擊

目前，智能合約可以使用 require(tx.origin == msg.sender) 來驗證事務是否來自外部賬戶（而非另一個合約）。這樣可以在一定程度上防止重入攻擊，因為它可以防止合約調用該函數。

EIP 3074 也允許 tx.origin 成為授權消息的簽名者。調用者執行的任何 AUTHCALL 都會導致 tx.origin == msg.sender 成真，即使這個調用是由智能合約執行的，因此很有可能遭到重入攻擊。EIP 3074 指出：「……本 EIP 的作者並未找到任何有關這種重入攻擊的例子，儘管沒有進行詳盡的搜索。」

結論

EIP 3074 為以太坊帶來了很多新的可能。AUTH 和 AUTHCALL 使得外部賬戶能夠將賬戶的控制權授予智能合約調用者，從而實現批量事務和贊助事務等新的事務類型。然而，該 EIP 也極大地改變了事務在以太坊上的運作方式，因此在主網上激活該 EIP 之前，我們需要更深入地思考其安全性。