作者：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時要格外謹慎。