长期以来，账户抽象(见文末附录）一直是以太坊开发者社区的梦想。 EVM 代码不仅用于实现应用程序的逻辑，还用于实现个人用户钱包的验证逻辑（随机数、签名……）。这将为钱包设计的创造力打开大门，可以提供一些重要的功能：
多重签名和社会恢复
更高效、更简单的签名算法（例如 Schnorr、BLS）
后量子安全签名算法（例如，Lamport、Winternitz）
可升级性 今天可以使用智能合约钱包完成所有这些事情，但以太坊协议本身要求将所有内容打包在源自 ECDSA 安全外部账户 (EOA) 的交易中，这一事实使得这变得非常困难。每个用户操作都需要由来自 EOA 的事务包装，从而增加了 21000 gas 的开销。用户需要在单独的 EOA 中拥有 ETH 来支付 gas，并管理两个账户中的余额，或者依赖中继系统，这些系统通常是中心化的。
EIP 2938 是解决此问题的一种途径，通过引入一些以太坊协议更改，允许顶级以太坊交易从合约而不是 EOA 开始。合约本身将具有矿工将检查的验证和费用支付逻辑。然而，当协议开发人员非常关注合并和可扩展性时，这需要对协议进行重大更改。在我们的新提案 (ERC 4337) 中，我们提供了一种无需更改共识层协议即可获得相同收益的方法。
这个提议如何运作？ 我们没有修改共识层本身的逻辑，而是在更高级别的系统中复制交易内存池的功能。用户发送 UserOperation 对象，这些对象将用户的意图与签名和其他数据打包在一起以进行验证。使用 Flashbots 等服务的矿工或捆绑商都可以将一组 UserOperation 对象打包成单个「捆绑交易」，然后将其包含到以太坊区块中。
捆绑者以 ETH 支付捆绑交易的费用，并通过作为所有单独 UserOperation 执行的一部分支付的费用获得补偿。捆绑商将根据与矿工在现有交易内存池中的操作方式类似的费用优先级逻辑来选择要包含哪些 UserOperation 对象。 UserOperation 看起来像一个事务；它是一个 ABI 编码的结构，其中包括以下字段：
sender：进行操作的钱包。
Nonce 和 signature：传递给钱包验证函数的参数，以便钱包可以验证操作。
InitCode：如果钱包尚不存在，则用于创建钱包的初始化代码。
CallData：用于实际执行步骤调用钱包的数据。 钱包是一个智能合约，需要具备两个功能：
1.ValidateUserOp，它接受一个 UserOperation 作为输入。这个函数应该验证UserOperation上的签名和nonce，如果验证成功则支付费用并增加nonce，如果验证失败则抛出异常。
2.Op 执行函数，将 calldata 解释为钱包采取行动的指令。这个函数如何解释 calldata 以及它的作用是完全开放的；但我们预计最常见的行为是将 calldata 解析为钱包进行一次或多次指令。 为了简化钱包的逻辑，确保安全所需的大部分复杂智能合约技巧不是在钱包本身中完成的，而是在称为入口点的全局合约中完成的。 ValidateUserOp 和执行函数预计将使用 require(msg.sender == ENTRY_POINT) 进行门控，因此只有受信任的入口点才能使钱包执行任何操作或支付费用。入口点仅在 validateUserOp 之后对钱包进行任意调用，并且携带该调用数据的 UserOperation 已经成功，因此这足以保护钱包免受攻击。如果钱包不存在，入口点还负责使用提供的 initCode 创建钱包。 
运行 handleOps 时的入口点控制流。
Mempool 节点和捆绑器需要强制执行 validateUserOp 可以做什么的一些限制：特别是，validateUserOp 执行不能读取或写入其他合约的存储，它不能使用诸如 TIMESTAMP 的环境操作码，并且它不能调用其他合约，除非这些合约可证明不能自毁。这需要确保模拟执行 validateUserOp ，由捆绑器和 UserOperation 内存池节点用来验证给定的 UserOperation 是否可以包含或转发，如果它实际包含在未来的块中将具有相同的效果。 如果成功模拟了 UserOperation 的验证，则保证 UserOperation 是可包含的，直到发件人帐户发生其他一些内部状态更改（因为具有相同发件人的另一个 UserOperation 或调用发件人的另一个合约；在任何一种情况下，都会触发此条件一个账户需要在链上花费 7500+gas）。此外，UserOperation 为 validateUserOp 步骤指定了 gas 限制，除非此 gas 限制非常小（例如低于 200000），否则内存池节点和捆绑器将拒绝它。这些限制复制了现有以太坊交易的关键属性，使内存池免受 DoS 攻击。捆绑器和内存池节点可以使用类似于当今以太坊事务处理逻辑的逻辑来确定是否包含或转发 UserOperation。 与常规的以太坊交易内存池相比，这种设计增加、维护和牺牲了哪些属性？ 维护属性：
1.没有中心化的参与者；一切都通过点对点内存池完成。
2.DoS 安全（通过模拟检查的 UserOperation 保证是可包含的，直到发送方有另一个状态更改，这将要求攻击者为每个发送方支付 7500+gas）。
3.没有用户端钱包设置的复杂性：用户不必关心他们的钱包合约是否「已经发布」；钱包存在于确定性的 CREATE2 地址，如果钱包尚不存在，第一个 UserOperation 会自动创建它。
4.完整的 EIP 1559 支持，包括费用设置的简单性（用户可以设置固定的费用溢价和最高总费用，并期望快速纳入并公平收费）。
5.能够按费用替换，发送一个新的 UserOperation，其溢价明显高于旧的 UserOperation 以替换操作或更快地将其包含在内。 新福利：
1.验证逻辑灵活性：validateUserOp函数可以添加任意签名和nonce验证逻辑（新的签名方案，多重签名……）
2.足以使执行层量子安全：如果该提议被普遍采用，则不需要在执行层上做进一步的工作来保证量子安全。用户可以单独将他们的钱包升级到量子安全的钱包。即使是包装交易也是安全的，因为矿工可以为每个捆绑交易使用新创建的、因此受哈希保护的 EOA，并且在将交易添加到区块之前不会发布交易。
3.钱包可升级性：钱包验证逻辑可以是有状态的，因此钱包可以更改其公钥或（如果使用 DELEGATECALL 发布）完全升级其代码。
4.执行逻辑灵活性：钱包可以为执行步骤添加自定义逻辑，例如。进行原子多操作（EIP 3074 的一个关键目标）。 弱项：
1.尽管协议尽了最大努力，DoS 漏洞仍略有增加，这仅仅是因为验证逻辑被允许比单个 ECDSA 验证的现状更复杂。
2.Gas 开销：比常规事务更多的 gas 开销（尽管在某些用例中通过多操作支持弥补了这一点）。
3.一次一笔交易：账户不能排队并将多笔交易发送到内存池中。但是，执行原子多操作的能力使此功能的必要性大大降低。 与付款人的赞助 赞助交易有许多关键用例。最常引用的期望用例是： 1.允许应用程序开发人员代表他们的用户支付费用。 2.允许用户以 ERC20 代币支付费用，合约作为中介收取 ERC20 并以 ETH 支付。 该提案可以通过内置的付款管理员机制支持此功能。 UserOperation 可以设置另一个地址作为其付款人。如果设置了付款管理员（即非零），则在验证步骤期间，入口点还调用付款管理员以验证付款管理员是否愿意为 UserOperation 付费。如果是，那么费用将从支付者在入口点内的 ETH 中提取（为了安全起见，提款延迟）而不是钱包。在执行步骤中，钱包会像往常一样使用 UserOperation 中的 calldata 调用，但之后会使用 postOp 调用 paymaster。 上述两个用例的示例工作流程是：
1.Paymaster 验证 paymasterData 包含来自赞助商的签名，验证赞助商愿意为 UserOperation 付费。如果签名有效，则付款主管接受并且 UserOperation 的费用从赞助商的股份中支付。
2.付款管理员验证发件人钱包是否有足够的 ERC20 余额来支付 UserOperation。如果是，paymaster 接受并支付 ETH 费用，然后在 postOp 中索取 ERC20 代币作为补偿（如果 postOp 由于 UserOperation 耗尽了 ERC20 余额而失败，则执行将恢复并且 postOp 将再次被调用，因此Paymaster 总是得到报酬）。请注意，目前，这只能在 ERC20 是由付款管理员本身管理的包装代币时才能完成。 特别要注意的是，在第二种情况下，付款主管可能是完全被动的，可能偶尔会重新平衡和重新设置参数。这是对现有赞助尝试的巨大改进，现有赞助尝试要求付款人始终在线以积极处理个人交易。 这个提议还有多远？ 早期的开发者 alpha 版本预计将很快推出，之后下一步将是确定最终细节并进行审计以确认该计划的安全性。开发人员应该能够很快开始试验帐户抽象钱包！ 附录：什么是账户抽象？ 计算机科学中的数据抽象是信息隐藏的实践。这提高了计算机系统在更高级别上使用的能力，而对底层进行的过程知之甚少。
考虑软件开发人员。高级编程语言用于创建对象之间的虚拟交互。程序员不需要知道如何编写组成在内存和处理器中物理运行的机器代码的 1 和 0。这是数据抽象的一个例子。
在以太坊网络上，目前有两种类型的账户。外部帐户是在 EVM（以太坊虚拟机）之外存在的发送和接收功能中进行加密货币交易的钱包。合约账户是存在于 EVM 中的「智能合约」。
EVM 是存在于以太坊区块链上的虚拟计算机。一系列 OPCODES 已被硬编程到以太坊区块链中，以便能够充当虚拟机；智能合约执行过程中的内存、存储和处理。
以太坊账户抽象的目标是将两种账户类型减少到一种，即合约账户。单一账户类型将具有交易代币和合约的功能。开发者和用户将不再需要区分帐户类型，因为交易将完全移入 EVM 并脱离区块链协议。
账户抽象将成为以太坊 2.0 的实现，关于这样做的方法仍然存在激烈的争论。 根据央行等部门发布“关于进一步防范和处置虚拟货币交易炒作风险的通知”，请读者严格遵守所在地区法律法规，不参与任何违法违规的投资行为。本文内容仅用于信息分享，不对任何经营与投资活动推广进行背书，请读者提高风险防范意识。币乎洁SIR刊载内容未经许可，禁止进行转载、复制等，违者将追究法律责任。 原文作者：Vitalik Buterin 原文链接：https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a
—-
编译者/作者：洁sir
玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。
|
