作者：Vitalik，以太坊創辦人；譯：xiaozou@金財經
1、概述
新增一個新的交易類型（transaction type），該交易類型會新增一個contract_code欄位和一個簽名，並在該交易期間將簽名帳戶（不一定與txt .origin相同）轉換為智慧合約錢包，目標是提供與EIP -3074類似的功能。
2、動機
為EOA添加短期功能改進，增加應用的可用性，並在某些情況下支援安全性改進，許多人對此非常感興趣。三個特定應用如下：
-
批次：允許同一用戶在一個原子交易中執行多個操作。一個常見的例子是ERC-20獲批准之後被再次花費，這在如今要求兩筆交易的去中心化交易所中是一個常見的workflow（工作流程）。批次的高階用例偶爾也會涉及依賴關係：第一個操作的輸出是第二個操作的輸入的一部分。
-
贊助：帳戶X代表帳戶Y支付交易費。帳戶X可以透過其他ERC-20支付此項服務，或者它還可以是一個應用程式運營商，免費包含其用戶的交易。
-
特權降級：使用者可以簽署子金鑰，並賦予它們特定權限，這些特定權限要比帳戶全域存取權限弱得多。例如，你可以設想這個權限是使用ERC-20代幣支付而非ETH，或每天支出總餘額1%，再或僅與特定應用程式互動。
EIP-3074解決了所有這些用例挑戰，但是存在者未來相容性的顧慮：
-
它引入了AUTH和AUTHCALL兩個操作碼，這在最終所有用戶都使用智能合約錢包的“帳戶抽象終局”的世界裡毫無用處（似乎最終必將是這樣一個世界，最起碼因為最終量子計算機將終止EOA使用的ECDSA）。
-
它將導致「invoker contract（呼叫者合約）」生態系統的發展，該生態系統將獨立於「智慧合約錢包」生態系統，從而導致付出的努力處於分散狀態，形不成合力。
該EIP的目標是在不存在這兩個問題的情況下啟用EIP-3074的所有用例。
3、規範
本文檔中的關鍵字「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」和「OPTIONAL」的解釋與RFC 2119中所述的一致。
參數：
-
FORK_BLKNUM = TBD
-
TX_TYPE = TBD
-
MAGIC = TBD
-
PER_CONTRACT_CODE_BASE_COST = 5000
自FORK_BLOCK_NUMBER開始，引進了一個新的EIP-2718交易，TransactionType = TX_TYPE(TBD)。
該交易的EIP-2718 TransactionPayload為：
rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s]…], signature_y_parity, signature_r, signature_s])
新交易的固有成本繼承自EIP-2930，具體為：21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count
此外，我們在每個contract_code上新增了16 * non-zero calldata bytes + 4 * zero calldata bytes，再加上PER_CONTRACT_CODE_BASE_COST乘以contract_code陣列的長度。
在交易執行一開始時，對於各[contract_code, y_parity, r, s]元組：
-
設定signer = ecrecover(keccak(MAGIC + contract_code)， y_parity, r, s]
-
驗證signer的合約代碼為空
-
設定signer的合約代碼為contract_code
在交易結束時，將每個signer的contract_code重設為空。
注意，任何contract_code簽署的singer和交易的txt .origin都可以不相同。
4.基本原理
（1）EIP-3074用例的轉換
在該設計中，無需做大量工作即可轉換現有的EIP-3074工作流程。具體來說，AUTH和AUTHCALL將被該EOA的調用所取代。一種方法是，contract_code將是一個用戶錢包（為了節省gas，可以是一個DELEGATECALL轉發器），並將暴露兩個函數，verify和execute。
-
AUTH將被verify代碼取代，該代碼將使用TSTORE在本地設定authorized[msg.sender, …] = True
-
AUTHCALL將被一個execute呼叫所取代，該呼叫將使用TLOAD來驗證authorized[msg.sender, …]，然後從那裡開始執行。
因此，從「現有的EIP-3074工作流程」轉換為這個新方案下的工作流程非常簡單。
（2）向前相容未來的帳戶抽象
此EIP被設計為具有非常高度的對帳戶抽象化未來的向前相容性，不會過度保存任何ERC-4337或RIP-7560的詳細資訊。
具體如下：
-
用戶需要簽署的合約代碼可以是現有的ERC-4337錢包代碼。
-
所使用的「code pathways」是在許多情況下（儘管可能並非全部）在純智慧合約錢包領域裡繼續「行得通」的程式碼路徑。
-
因此，它避免了「創建兩個獨立的代碼生態」的問題，因為在很大程度上它們將是同一個生態系統。在這個解決方案下，可能會有一些需要組合的工作流程，在「帳戶抽象終局」下的各種「更原生的」環境中可能會做得更好，但這只是相對較小的一部分。
-
它不需要添加任何操作碼，將在後EOA世界變得無用。
-
它允許EOA以一種與現有EntryPoint相容的方式，將自己暫時轉換為合約，以包含在ERC-4337交易包中。
-
一旦部署完成，EIP-5003將「只有一行程式碼」：只需新增一個flag，在交易結束時不將程式碼設為空。
5.向後相容性
此EIP打破了帳戶餘額只能因源自該帳戶的交易而減少的定式。這對記憶體池設計和其他EIP（如包含清單）都有影響。然而，這些問題對於任何提供類似功能的提案都是常見的，包括EIP-3074。
6.安全顧慮
關於EIP-3074的許多安全疑慮都是共通的。尤其是，用戶錢包在簽署contract_code時要格外謹慎。