一文读懂 Vitalik 的 EIP-7702 新提案：账户抽象的终极药方？
Vitalik Buterin提出了EIP-7702提案，旨在解决以太坊普通账户的安全和功能限制问题。该提案允许用户使用智能合约作为账户，通过修改现有提案实现更好的账户抽象。此外，EIP-5003添加了操作码「AUTHUSURP」，使得EOA能够执行任何智能合约代码。这可能会彻底改变我们与Web3应用的交互方式。
原文作者：Jarrod Watts
原文来源：twitter
Vitalik Buterin 最新提出了 EIP-7702 提案，这可能是以太坊历史上影响最大的变化之一，本文就将介绍该新提案的有关工作原理以及实现其所需要了解的一切。
首先，EIP-7702 新提案出奇地简短，这让部分人感到困惑，不知道它到底如何运作，为了理解 7702，我们首先要了解其中提到的另外三个提案：
- EIP-4337
- EIP-3074
- EIP-5003
让我们从所有这些提案的共同目标「账户抽象」说起——以太坊上的 EOA（「普通」账户）很糟糕，它们风险很大，功能非常有限，而账户抽象则允许用户使用智能合约作为账户，以添加更多功能和安全性来解决这个问题。
EIP-4337
EIP-4337 于 2023 年 3 月在主网上线，它允许用像账户一样编写智能合约，以便它们可以验证和执行交易，这改进了许多用户体验（UX）。
自发布以来，EIP-4337 得到了广泛的采用，主要由 Polygon 主导，而 Base 在过去几个月中的相关活动也在增多。
EIP-4337 相关的最新创新来自 Coinbase 生态及 Coinbase 智能钱包，它基于生物识别技术，用户体验非常棒，我曾在上周末于 ETH Global Sydney 制作了另一个小型演示来展示这一点。
那么 EIP-4337 存在什么问题？为什么今天又有另一个帐户抽象提案？因为 EOA 仍然是迄今为止使用最广泛的账户类型。
除此之外，大多数 EIP-4337 的智能合约账户都由单个 EOA 签署者控制，下面是示例代码：
因为无法将用户的 EOA「转换」为智能合约账户，所以有这个奇怪的中间步骤解决方案——主要是由于 Web3 应用缺乏对连接智能合约账户的原生支持，如今大多数人仍通过 MetaMask 等插件钱包使用 EOA。
EIP-3074
这引出了我们的下一个提案：EIP-3074。
实际上，这个提案是在 EIP-4337 之前提出的，但是它尚未合并到主网，EIP-3074 试图赋予 EOA 更多权力，允许他们将其 EOA 的控制权委托给智能合约。
该提案概述了以下内容，添加两个新的操作码：
- AUTH：EOA 可以调用 AUTH 来授权给定的智能合约代表其 EOA 执行操作；
- AUTHCALL：获得授权的智能合约可以使用 AUTHCALL 为 EOA 执行交易；
这实现了与 EIP-4337 许多相同的用例，而无需每个用户部署新的智能合约。一个关键的区别在于交易来自用户的 EOA，而不是一个没有用户任何帐户历史记录、ETH、NFT、代币等的新合约。
对 EIP-3074 的一个常见反应是「如果有人制定恶意合约并且用户委托给他们怎么办？」，毕竟委托给恶意合约可能会导致用户的钱包里的所有加密资产都被抽走。
解决这个问题的方法是钱包服务提供商甚至不允许用户对任何合约进行授权，他们可能会保留一份用户可以委托授权的智能合约白名单列表，并且此列表之外的任何合约都不会显示给用户。
关于【一文读懂 Vitalik 的 EIP-7702 新提案：账户抽象的终极药方？】的延伸阅读
EIP-4337的最后一块拼图：全链账户抽象
【GPT】EIP-4337是以太坊生态的账户抽象框架，Biconomy、Safe Core和Particle Network等项目探讨如何在EIP-4337框架下进一步推动账号抽象领域的发展。Particle Network提出了一套简洁的抽象化的Intent-Centric实现方案，支持跨链交互，并使用统一的手续费支付方式，为开发者提供更灵活和便捷的方式来构建多链应用程序，促进账号抽象的广泛采用。
以太坊核心开发者最新会议摘要：同意移除EIP 3074，包含EIP 7702
以太坊开发者讨论了新增执行API功能、Geth的最低优先小费要求、Pectra开发网络和分叉范围等议题。他们同意从Pectra Devnet 0中移除EIP 3074，并在下一个测试网Pectra Devnet 1中包含EIP 7702。开发者们还讨论了Pectra升级的时间表和范围，建议将其分成两个分叉。最后，开发者们将继续在GitHub上讨论并尝试解决这些问题。
EIP-3074 委托的一个关键点是委托并非永久性的，「EOA 的单个交易会导致 nonce 增加，从而使未完成的授权失效」。
实质上，在用户进行新交易后，委托将不再有效。
EIP-5003
我们也确实不想赋予 EOA 更多权力。毕竟，这些提案的目标是将用户从 EOA 转移到智能合约账户，那么我们为什么要向 EOA 添加功能呢？
这很好地引出了我们的下一个提案：EIP-5003。EIP-5003 添加了另一个操作码「AUTHUSURP」，它将代码部署在 EIP-3074 授权地址。
EIP-3074 和 EIP-5003 两者的区别在于：
- EIP-3074 是对智能合约的临时委托，可撤销；
- EIP-5003 是从 EOA 永久迁移并从 EOA 「转换」 到智能合约账户；
EIP-3074 + EIP-5003 的一个大问题是它与通过 EIP-4337 的当前账户抽象方案不太兼容，所以以太坊社区的一些人担心我们会通过这两种类型的账户抽象「创建两个独立的代码生态系统」。
EIP-7702
这就到了 Vitalik Buterin 今天的提议：EIP-7702——他提议修改 EIP-3074，使其更精简并与 EIP-4337 更兼容，这样我们就不会最终得到两个独立的账户抽象生态系统，还将 EIP-5003 视为永久迁移的下一步。
EIP-7702 提出了一种同时接受 contract_code 和签名字段的新交易类型，在开始执行交易时，它将签名者账户的合约代码设置为 contract_code。在交易结束时，它会将代码重新设置为空。
这和 EIP-3074 一样，实现了 EOA 对智能合约的临时委托功能。然而 EIP-7702 并没有引入新的操作码（这需要硬分叉），而是定义了要调用的函数：
- AUTH -> 调用「verify」（验证）
- AUTHCALL -> 调用「execute」（执行）
具体来说，它：
- 检查你的账户合约代码是否为空；
- 如果为空，则设置为提供的合约代码；
- 根据提供的智能合约处理交易的方式执行交易；
- 将账户合约代码设置恢复为空；
「合约代码」 就是字面意思，智能合约的代码就存储在「合约代码」中。由于 EOA 本身不是合约，所以这个字段通常是空的。然而 EIP-7702 的巧妙之处在于，它会在交易执行期间临时将一些智能合约代码填充到该字段中。
这是一种为您的 EOA 提供新行为（代码形式）的方式，用于执行此特定交易，下一步是使之成为永久性的行为改变，只需选择「在交易结束后不将代码设置为空」。
该提案最棒的一点之一是，它与迄今为止为 EIP-4337 构建的所有账户抽象工作高度兼容，「用户需要签名的合约代码实际上可以是现有的 EIP-4337 钱包代码」。
一旦此项改动生效，用户现有的 EOA 就可以执行任何智能合约代码。通过额外的 EIP，EOA 还可以永久升级以运行特定的代码。
假以时日，这可能会彻底改变我们所有人与 Web3 应用的交互方式。
免责声明：本文仅代表作者个人观点，不代表链观CHAINLOOK立场，不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险，以及遵守所在国家和地区的相关法律法规。
图文来源：Jarrod Watts，如有侵权请联系删除。转载或引用请注明文章出处！
