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时要格外谨慎。