V神还是你家大神！另外，偶尔你不能只考虑技术，还得想想未来的人类未来的社会如何管理。
账户抽象化这个概念是在 2017 年2月 Vitalik Buterin 的 EIP-86 里首次提出的，其目的是实现 “交易来源和签名的抽象”。不过其动机和想法可以追溯到 2016 年年初 vitalik 提交的一个 issue， 文中建议 “与其将 ECDSA 签名算法和默认的 nonce 机制写死在协议内作为 ‘标准’ 的账户安全机制，不如初步建立一个（统一的）账户模型，在未来把所有的账户都变成合约，让合约可以支付 gas，让用户可以自由定义自己的安全模型。”
RationaleThe goal of these changes is to set the stage for abstraction of account security. Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only "standard" way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.
什么是天才？凭借直觉就能预判准未来，那他就是！
前面有关章节已经介绍以太坊有两种类型的账户：
外部账户（Externally Owned Account, EOA）
合约账户（Contract Account, CA）。
前者由用户私钥控制，而后者由存储在智能合约账户（有时也被称为智能钱包）内的合约代码控制。
外部账户的权限要大于合约账户，因为只有外部账户可以通过支付 gas 启动交易的执行过程（即与智能合约交互）。
随着实践经验与教训的积累，钱包用户开始对外部账户产生一些担忧。这些担忧包括：
严重依赖人工：由于账户访问完全依靠私钥，且所有交易均需动用私钥进行签名，即转账和实施智能合约操作的唯一方法是人工操作（使用私钥），在全天无休的区块链行业，这就实在太不方便。甚至完全可以说手段太落后了。
私钥管理问题：既然私钥决定一切，对于如何安全存储私钥以及谁有权访问它，就会给用户带来极困难和极具压力的挑战——如果有50亿地球人都得日常使用私钥，因私钥掌控Money，那么每天必定有大量私钥的遗失和泄露事件发生！如果不泄露就绑架就凶杀……
依赖椭圆曲线签名（ECDSA加密算法）：已经有专业团队发出外部账户采用的ECDSA加密算法会在不久的将来被破解的预警！抗量子的数字签名是对当前 ECDSA 的必要改进，并且可以说迫在眉睫！该提案可以让用户升级至更安全的加密算法。但能否顺利升级，能否赶在被破解前完成升级换代，目前看起来胜算都不大！……那咋办呢？
一对一的操作：一次不能执行多个操作。否则会产生不必要的成本和糟糕的用户体验。外部账户一点都不好玩！
值得思考的是，Vitalik 这个提案的核心思想，是在遥远的未来，已经没了外部账户而所有的账户均为合约账户，让合约账户可以支付gas，所有人都不用应对与私钥相关的安全问题。
改造链上交易类型的 EIP-86 给大家带来了巨大的启迪，类似它的方案此后又出现了EIP-101、EIP-208、EIP-859、EIP-2718。
2020年，Vitalik 等人提出了 EIP-2938 草案，该草案概述了一个更简单的实现。这个实现对协议/共识的改动最小，并且通过设置节点的内存池规则来满足所需的安全保证——开发小组的动机是将它“封装”到以太坊共识层（Consensus Layer），而非像通证标准ERC-20那样，仅仅只是提供一个在智能合约层面应用的技术标准。
EIP-2938 提出的账户抽象化（Account Abstraction, AA）是一个可以让合约账户成为和外部账户一样的 “顶层” 账户的提案。具体来说，这个方案要求对以太坊协议进行修改，并允许从合约（每个智能合约都有一个合约账户），而不仅仅是外部账户来发起以太坊交易。合约本身将具备验证和矿工需验证的gas费用支付逻辑。那么也就是说，实现了账户抽象化之后，合约账户也可以发起交互请求并支付交易费。
而实际的应用场景更复杂，考虑到遥远的未来可以说细思极恐：EIP-2938通过账户抽象化来为以太坊提供一个基础功能层，以确定何时支付，谁来支付以及怎样支付 gas——简单地说，这是一个以改造链上主体对象为核心的解决方案。如果你还没感觉，那就仔细看完（特别是ERC-4337）。
EIP-2938可以让更多通用型钱包或者其它应用的智能合约执行复杂的逻辑。譬如没有EIP-2938，你想把所有代币都放到一个新钱包里，然后你一不小心先把所有 ETH 都发送到这个新钱包里了。马上，你会尴尬地发现你的旧钱包因为没有 ETH 而无法发送任何交易，剩下的代币无法转移到新钱包。账户抽象化能让你使用其它合约地址（如智能合约钱包）里的 ETH 支付 gas 费用（这种情况叫代付交易，Sponsored Transactions），甚至还可以让你使用旧钱包里的其它代币支付 gas 费用。当然，这只是一个很容易理解的示例，实际的应用还可以复杂很多倍。
EIP-3074 主要的技术创新是向 以太坊虚拟机（EVM） 添加两个新的操作码：AUTH 和 AUTHCALL，它们旨在被称为“调用者”的智能合约使用。这些调用者获得了对授权他们的外部账户 EOA 的控制权，并可以代表他们进行调用。
这也就是说，用户可使用私钥对包含其意图的消息进行签名。然后，该消息被包含在调用程序的链上交易中。调用者使用签名消息和 AUTH 操作码来控制用户的外部帐户，并且使用 AUTHCALL 代表用户去执行操作。
要注意的是，包含用户签名消息的交易不一定必须从该用户的帐户发送，这使用户完全不必依赖 ETH 来发送交易。事实上，还可以通过其他方式支付费用，例如使用道易程创建的伟大的价格单位制里面的那个叫做uToken的 ERC-20 代币。
这种方法有几个问题，主要是认为赋予调用者如此大的权力会导致类似于 DAO 黑客攻击的灾难性事件。
之后的EIP-3607、EIP-5003基本沿袭了 EIP-3074 的内核思想。
ERC-4337 看上去与EIP-2938类似，但ERC-4337是无需更改任何共识层即可在协议上实现账户抽象的技术标准。它显然是更好的解决方案。EIP-4337最早于2021年提出，已经于2023年3月被部署到以太坊主网，可实现在单个合约账户中进行交易和创建合约。
ERC-4337 的核心技术创新是用一个被称为 UserOperation 的更高层伪交易对象，取代了 transaction ，而它本身则是一个描述一个 transaction 结构体。你可以理解为 ERC-4337 为以太坊在 transaction 基础上，新创了另一种交易形式。或者说比特币只有一种办法交易，而以太坊现在有了另一种更复杂也更高效的形式完成交易。以太坊对比特币的超越是全面的！并且，把这个场景放到智能合约的应用里去考虑就叫细思极恐。是的，我词穷了，你能理解就好！
validateUserOp：它接受一个 UserOperation 作为输入。这个函数应该验证UserOperation上的签名和nonce，如果验证成功则支付费用并增加nonce，如果验证失败则抛出异常。
op执行功能：将calldata解释为钱包采取行动的指令。这个函数如何解释calldata以及它的结果是完全开放的；但我们预计最常见的行为是将calldata解析为钱包的一个或多个调用。
捆绑者(Bundler)将这些对象打包成一笔交易，纳入到一个区块当中。捆绑者支付捆绑交易的燃料费，但收取单独执行UserOperation的费用。捆绑者与验证者的工作方式类似，即根据费用优先等级逻辑选择要纳入的对象。任意捆绑者均可参与到流程当中。
为了简化钱包的逻辑，确保安全所需的大部分复杂智能合约技巧不是在钱包本身中完成的，而是在称为入口点的全局合约中完成的。validateUserOp 和执行函数预计将使用 require(msg.sender == ENTRY_POINT) 进行门控，因此只有受信任的入口点才能使钱包执行任何操作或支付费用。入口点仅在 validateUserOp 之后对钱包进行任意调用，并且携带该调用数据的 UserOperation 已经成功，因此这足以保护钱包免受攻击。如果钱包不存在，入口点还负责使用提供的 initCode 创建钱包。
启用创新用例：包括聚合签名、每日交易限额设置、账户紧急冻结、白名单设置以及保护隐私的应用程序等。
钱包设置——无需写下助记词。只需轻点几下，即可快捷轻松地进行设置。
账户恢复——用户无需再担心丢失助记词，现已可以实现多重身份验证和账户恢复。
易于使用的钱包功能——用户可以享用非常丰富的定制服务，包括自动支付、预先批准交易和捆绑交易。至于还有什么功能，完全取决于你写的智能合约。
更高的安全性——降低人为出错的几率，钱包将能够更加安全。
更灵活的gas支付方式——由ERC-4337提供支持的钱包可用任意ERC-20代币、EIP-3712代币和未来其它币种支付gas。
最突出的一点就是因为其复杂性增加，需要更高的Gas成本：基本的ERC-4337操作约需要42000 gas，而常规交易需要 21000 gas，原因如下：
1、需要支付大量的单个存储读/写成本，在 EOA 的情况下，这些成本会捆绑到一笔 21000 gas 的付款中： （1）编辑包含 pubkey+nonce (~5000) 的存储 slot； （2）用户操作调用数据成本（约 4500，通过压缩可减少到约 2500）； （3）ECRECOVER (~3000)； （4）首次访问钱包本身 (~2600) （5）首次访问收款人账户 (~2600) （6）将 ETH 转入收款人账户 (~9000) （7）编辑存储以支付费用（~5000） （8）访问包含代理 (~2100) 的存储 slot，然后访问代理本身 (~2600)；
2、除了上述存储读/写成本之外，合约还需要执行 “业务逻辑”（解包 UserOperation、对其进行哈希、洗牌变量等）
3、需要消耗 gas 来支付日志费用（EOA 不发布日志）；
4、一次性合约创建成本（约 32000 gas，加上代理中每个 code byte 200 gas，再加上设置代理地址的 20000 gas） 简而言之，账户抽象地址的每一步都需要计算，需要消耗更多的资源，也增加了额外的费用。
还没完？
ERC-5189 显然是受 ERC-4337 的启发而创建的，但它卡顿了。如果你对技术感兴趣可以点击链接去看看。
Title为Native Account Abstraction，意味着和 EIP-2938 一样，它是一个“封装”到以太坊共识层的技术提案。
RIP-7560 简介里的第一句话为：
Combining the EIP-2938 and ERC-4337 into a comprehensive Native Account Abstraction proposal.
该提案的意图，是引入共识层协议变更的原生账户抽象（Native Account Abstraction），并将 EIP-2938 和 ERC-4337 合并为一个全面的账户抽象提案。
EIP-7701 有个小标题：A variant of RIP-7560 transactions relying on EOF Smart Contract Accounts
它是以EIP-3540为基础。
它有个令人惊讶的小标题：Add a new tx type that sets the code for an EOA during one transaction execution。
它的简介也令人惊讶：
Add a new transaction type that adds a contract_code field and a signature, and converts the signing account (not necessarily the same as the tx.origin) into a smart contract wallet for the duration of that transaction. Intended to offer similar functionality to EIP-3074.
看似简单，但一石惊起千层浪！
EIP-7702 提出了一种同时接受 contract_code 和签名字段的新交易类型，在开始执行交易时，它将签名者账户的合约代码设置为 contract_code。在交易结束时，它会将代码重新设置为空。
EIP-7702和 EIP-3074 一样，实现了 EOA 对智能合约的临时委托功能。然而 EIP-7702 并没有引入新的操作码（这需要硬分叉），而是定义了要调用的函数：
AUTH -> 调用“verify”（验证）
AUTHCALL -> 调用“execute”（执行）
具体来说，它：
由此可见，EIP-7702 能够达成与 EIP-3074 同样的核心功能，如批量交易和交易赞助，增强了交易类型的复杂性和控制策略的灵活性。这也就是说，EIP-7702 允许外部拥有账户（EOAs）在交易中临时扮演智能合约钱包的角色，使得 EOAs 可以执行以前只有智能合约才能进行的复杂操作，极大地增强了 EOAs 的功能性和灵活性。通过引入 contract_code 字段，EOAs 可以在交易中动态地引入智能合约代码，实现在单一交易中完成多种操作，如批量处理和复杂的交易指令，从而简化流程并降低交易成本，同时减少了操作复杂性。
其次，EIP-7702 还引入了一种新的权限管理机制，即权限降级。这使得账户持有者可以为其子密钥分配具体权限，从而增强了账户的安全性。通过细粒度的权限控制，用户可以限制子密钥的操作范围，防止未授权的交易和滥用行为，旨在保护用户资金安全，这对于防止未授权的交易和滥用具有重要意义。
EIP-7702 相比 EIP-3074 的优势是，它与EIP-4337 构建的所有账户抽象工作高度兼容，“用户需要签名的合约代码实际上可以是现有的 EIP-4337 钱包代码”。
一旦此项改动生效，用户现有的 EOA 就可以执行任何智能合约代码。通过额外的 EIP，EOA 还可以永久升级以运行特定的代码。
账户抽象化为包括新型钱包在内的区块链dApp的创新设计打开了新的思路。也许有助于下列技术方案的实施：
多签和账户的社交恢复
验证逻辑灵活性——更高效和更简洁的签名算法（如：Schnorr, BLS）
执行层量子安全与后量子安全签名算法（如：Lamport, Winternitz）
如果EIP-2938这样的提案得到普遍采用，则无需为量子安全在执行层做进一步的工作。用户可将钱包自行升级到量子安全的版本。甚至连封装交易（wrapper transaction）也是安全的。矿工可以为每个捆绑交易使用新创建的EOA，由于是新创建的，所以每个交易都受到哈希保护，更保证了安全性。并且，在矿工将交易添加到区块中之前不会发布该交易。 对于其它方案，则始终要考虑到外部账户的加密算法，能够被量子攻击所破解！
钱包可升级性及其执行逻辑灵活性
钱包验证逻辑可以是有状态的，因此钱包可以更改其公钥或（譬如如果使用DELEGATECALL发布）完全升级其代码。
钱包可以为执行步骤添加自定义逻辑，例如进行原子多操作（这是EIP 3074的一个关键目标）。
EIP-7702提议对以太坊协议进行一系列更改，以实现账户抽象。其关键思想是引入一种称为“用户操作”的新交易类型。与普通交易不同，用户操作不是通过签名进行身份验证的。相反，它们是由与账户关联的智能合约钱包进行身份验证的。
当用户操作提交到网络时，首先会发送到关联的智能合约钱包。然后，钱包根据自己的验证逻辑验证操作。如果验证成功，则钱包向用户操作的目标发送普通交易。
这一过程允许更灵活地验证交易。例如，智能合约钱包可以要求在执行交易之前进行多重签名，或者可以使用链下数据（如生物识别验证的证明）来验证交易。
EIP-7702还引入了“支付主合约”的概念。这些是可以为用户操作赞助gas费用的合约。这意味着只要有一个愿意支付其gas费用的支付主，用户就可以与以太坊进行交互，而无需持有任何ETH。
智能合约的应用升级 这句话需要你自己去想象……
账户抽象化背后的动机很简单，但会带来根本性的改变：当前，以太坊交易具备功能可编程性（通过调用智能合约实现），但是交易的验证方式却是固定的。只有持有有效的 ECDSA 签名、有效的 nonce 值以及足够的账户余额，一笔交易才算有效。账户抽象化引入了一种新的交易类型 —— 抽象账户交易（AA Transaction）。这种交易总是由一个特殊地址产生，协议不会检查其签名，nonce 和余额。通过引入这种交易，账户抽象化实现了从固定验证方式到可编程验证方式的转变。抽象账户交易的有效性由其 target 字段指定的智能合约验证，通过验证之后，合约可以自行为该交易支付手续费。
我们业已看到，随着技术探讨的深入，一个小小的突破口，带来了很大的一个未来世界！
这就叫创新！并且它对于区块链未来的发展极为重要！
EIP-86、EIP-101、EIP-859、EIP-2718、EIP-2938、EIP-3074、EIP-3607、EIP-4337、EIP-5003、EIP-5189，RIP-7560……其中EIP-86、EIP-2938、EIP-4337、RIP-7560都是 Vitalik 领衔制订，前后耗费七八年时间。创新不易！
以太坊封装 ERC-4337？ 对于开发者来说，这是值得重视和学习的！ 请仔细阅读以太坊是否应该封装更多功能？（注意“封装 ERC-4337”一节 ） ——原文：Should Ethereum be okay with enshrining more things in the protocol? 此后 RIP-7560 的出现，证实了封装势在必行。
提案即技术协议，它的不断变化，可能会给开发带来不良影响！这篇文章里面有提到一些细节：《RIP-7560 ：从共识层实现标准化的原生账户抽象》。
账户抽象化的出发点，是想要显著改善用户与dApp的交互体验。它客观上有个巨大的应用优点：减少外部账户也就是人类的缺陷和失误带来的不良影响——考虑到未来合约满天飞带来的超高效率的交互，我们甚至可以说它很可能让人类对dApp的影响降低到极小化。并且，未来肯定还会通过一次次创新持续降级外部账户（或者使之产生蜕变），而优化dApp的效率和安全性。
对使用 ERC-4337 达到社交恢复用户账户这样的应用，要特别小心！因为我们说到社交恢复，绝大多数俗人理解的就是几个人能够联合起来恢复某个用户的账户，或者赋予某个用户的一个新账户接收款项的权利——万一这几个人中有数人同时挂掉呢？万一他们联合起来作恶呢？ 如果你不但这样想还这样做，那意外就迟早会发生，而且大概率还是灾难级别越大发生的可能性越高——很遗憾我们有时候确实没法阻止它就这样发生。 而如果里面不是人，而是一个AI一个地址，这些AI能够飞到你的身边验明正身，由它们来掌握恢复人类账户的权限，你觉得如何？
May 14, 2024 • 7 min read
Ethereum's evolution never stops. With each Ethereum Improvement Proposal (EIP), the network takes a step towards greater scalability, security, and usability. One such proposal, EIP-7702, is set to revolutionize the way users interact with the Ethereum blockchain by introducing account abstraction.
Account abstraction is a concept that has been discussed in the Ethereum community for a while, but EIP-7702 brings it closer to reality. The proposal aims to provide a more flexible and user-friendly experience by allowing smart contracts to act as Ethereum accounts. This shift could potentially unlock a myriad of new use cases and greatly enhance the overall user experience on Ethereum.
In this blog post, we'll take a deep dive into EIP-7702, explaining what account abstraction is, how it works, and what benefits it brings to developers and users. We'll also explore how thirdweb's tools and services can help developers navigate this new terrain and take full advantage of the opportunities presented by EIP-7702.
Before we delve into the specifics of EIP-7702, let's first understand what account abstraction is. In the current Ethereum ecosystem, there are two types of accounts: externally owned accounts (EOAs) and contract accounts. EOAs are controlled by private keys and can initiate transactions, while contract accounts are controlled by their contract code and can only perform transactions in response to receiving a transaction.
Account abstraction aims to blur the distinction between these two types of accounts. With account abstraction, all accounts on Ethereum can be treated as contract accounts. This means that EOAs can be replaced by smart contract wallets, which can have arbitrary verification logic for validating transactions.
This shift brings several benefits. For one, it allows for more flexibility in how transactions are authorized. Instead of relying solely on private keys, smart contract wallets can define their own authentication methods, such as multi-signature schemes, social recovery, or biometric authentication.
Furthermore, account abstraction enables new features like gas sponsorship, where a third party can pay for the gas fees of a transaction, and account recovery mechanisms, which can help users regain access to their funds if they lose their private keys.
Now that we have a basic understanding of account abstraction, let's take a closer look at EIP-7702 itself. The full technical specification of the proposal can be found in the Official EIP-7702 Proposal.
EIP-7702 proposes a set of changes to the Ethereum protocol that would enable account abstraction. The key idea is to introduce a new type of transaction called a "user operation." Unlike regular transactions, user operations are not authenticated with a signature. Instead, they are authenticated by a smart contract wallet associated with the account.
When a user operation is submitted to the network, it is first sent to the associated smart contract wallet. The wallet then validates the operation based on its own verification logic. If the validation succeeds, the wallet sends a regular transaction to the target of the user operation.
This process allows for much more flexibility in how transactions are validated. For example, a smart contract wallet could require multiple signatures before a transaction is executed, or it could use off-chain data (like a proof of biometric authentication) to validate a transaction.
EIP-7702 also introduces the concept of "paymaster contracts." These are contracts that can sponsor the gas fees for user operations. This means that users can interact with Ethereum without needing to hold any ETH, as long as there is a paymaster willing to cover their gas fees.
The changes proposed by EIP-7702 have significant implications for both developers and users of Ethereum.
For developers, EIP-7702 brings a new level of flexibility in designing smart contract wallets. They can implement custom verification logic, enabling features like multi-factor authentication, spending limits, and emergency recovery mechanisms. This opens up a whole new design space for smart contract wallets.
Moreover, the ability to sponsor gas fees through paymaster contracts allows developers to create more user-friendly onboarding experiences. New users can interact with Ethereum applications without needing to acquire ETH first, reducing a significant barrier to entry.
For users, EIP-7702 promises a more seamless and secure Ethereum experience. Smart contract wallets can offer better safety features, like protection against phishing attacks and the ability to recover funds if private keys are lost. Gas sponsorship also makes it easier for users to get started with Ethereum, as they don't need to worry about purchasing ETH for gas fees.
However, these benefits come with some challenges. Implementing account abstraction adds complexity to Ethereum clients and wallets. There are also questions around how to optimize gas costs for user operations and how to ensure that paymaster contracts are not abused.
While EIP-7702 presents a plethora of benefits, it's not without its challenges. One of the main hurdles is the added complexity it brings to Ethereum clients and wallets. Implementing account abstraction requires significant changes to the existing infrastructure, which could lead to potential compatibility issues and increased development overhead.
Another challenge is optimizing gas costs for user operations. Since smart contract wallets will be performing additional computations to validate transactions, this could lead to higher gas costs compared to traditional EOA transactions. Developers will need to find ways to minimize these costs, possibly through gas optimization techniques or by utilizing gas sponsorship mechanisms.
There's also the question of how to prevent abuse of paymaster contracts. While gas sponsorship is a powerful feature, it could potentially be exploited by malicious actors. Safeguards will need to be put in place to ensure that paymaster contracts are used responsibly and don't enable spam or denial-of-service attacks.
Adoption of EIP-7702 will also require buy-in from the broader Ethereum community. Wallets, dapps, and other ecosystem participants will need to update their software to support the new transaction types and interactions introduced by account abstraction. This process will take time and require coordination across the community.
Despite these challenges, the benefits of account abstraction are compelling, and tools like thirdweb are making it easier for developers to take advantage of these features.
thirdweb provides a suite of developer tools and infrastructure that simplify the process of building and deploying smart contracts on Ethereum. With thirdweb, developers can easily create smart contract wallets that leverage the capabilities of EIP-7702.
For instance, thirdweb's Solidity SDKs include pre-built, audited smart contract templates for common use cases like multi-signature wallets, escrow contracts, and token vesting. These templates can be easily extended to incorporate custom verification logic and advanced features enabled by account abstraction.
thirdweb also offers gasless transactions, a feature that aligns perfectly with the gas sponsorship capabilities of EIP-7702. With gasless transactions, users can interact with smart contracts without needing to hold ETH for gas fees. This feature, combined with the flexibility of smart contract wallets, could greatly improve the onboarding experience for new Ethereum users.
Furthermore, thirdweb's infrastructure is designed to handle the increased computational requirements of account abstraction. Their serverless architecture can scale automatically to meet the demands of user operations and smart contract wallet interactions.
As EIP-7702 and the concept of account abstraction gain traction, it's exciting to consider how they might shape Ethereum's future.
One of the most promising implications is a vastly improved user experience. With smart contract wallets, users will have access to advanced security features, customizable transaction validation, and the ability to interact with Ethereum without needing to manage ETH for gas directly. This could make Ethereum much more approachable and user-friendly, lowering the barriers to entry for mainstream adoption.
Account abstraction also unlocks new possibilities for developers. The ability to define custom transaction validation logic opens up a whole new design space for smart contract interactions. We could see the emergence of new types of dapps and use cases that were previously not possible or practical with traditional EOA accounts.
For example, account abstraction could enable more sophisticated identity and reputation systems. Smart contract wallets could incorporate identity verification, credit scoring, or other off-chain data into their transaction validation process. This could pave the way for decentralized credit markets, self-sovereign identity, and more robust decentralized governance models.
Gas sponsorship also introduces new economic models and incentive structures. We could see the rise of "gas relayers" - entities that specialize in sponsoring transactions in exchange for other forms of value (e.g., token rewards, service fees, etc.). This could create new revenue streams and business models within the Ethereum ecosystem.
Of course, the full impact of account abstraction will depend on the rate and scale of adoption. But with proposals like EIP-7702 and the growing ecosystem of tools like thirdweb, the future looks bright. As more developers start experimenting with these new capabilities, we're likely to see a wave of innovation that could redefine what's possible on Ethereum.
As the Ethereum ecosystem continues to evolve, EIP-7702 and the concept of account abstraction represent a significant step forward in terms of usability, security, and flexibility. By blurring the lines between EOAs and contract accounts, account abstraction opens up a world of possibilities for developers and users alike.
For developers, EIP-7702 provides a new canvas to create innovative smart contract wallets with custom verification logic, advanced security features, and improved user onboarding. Tools like thirdweb are already making it easier for developers to integrate these features into their projects, providing pre-built templates, gasless transactions, and scalable infrastructure.
For users, account abstraction promises a more intuitive and secure Ethereum experience. Smart contract wallets can offer better protection against common vulnerabilities, more flexible authentication methods, and the ability to interact with Ethereum without the need to directly manage ETH for gas fees. This could significantly lower the barriers to entry for mainstream adoption.
As EIP-7702 moves closer to implementation, it's clear that account abstraction will play a central role in shaping Ethereum's future. While there are still challenges to overcome, such as increased complexity and potential gas optimization issues, the benefits are too compelling to ignore. With the right tools and community support, account abstraction could unlock a new era of innovation and growth for Ethereum.
What is EIP-7702? A Beginner's Guide
以太坊账户抽象研报：拆解 10 个相关 EIP 提案与冲击千万级日活用户的瓶颈问题
zkSync Era Account Abstraction
新增一种交易类型，添加一系列 [chain_id, address, nonce, y_parity, r, s] 授权元组。对于每个元组，向签名账户的代码写入一个委托设计器 (0xef0100 ++ address)。所有读取代码的操作必须加载设计器所指向的代码。
人们对为外部账户（EOAs）增加短期功能改进非常感兴趣，这可以提高应用的可用性，并在某些情况下提升安全性。特别的三个应用包括：
批处理：允许同一用户在一个原子交易中进行多个操作。一个常见的例子是 ERC-20 授权后跟随的支出，这在去中心化交易所（DEX）中是一个常见的工作流程，目前需要两个交易。批处理的高级用例偶尔涉及依赖关系：第一个操作的输出是第二个操作的输入的一部分。 赞助：账户 X 代表账户 Y 支付一个交易。账户 X 可以用其他 ERC-20 代币获得这项服务的报酬，或者可以是一个应用程序运营商为其用户免费处理交易。 权限降级：用户可以签署子密钥，并给予它们特定的权限，这些权限远低于对账户的全局访问权限。例如，可以想象一种权限，允许支出 ERC-20 代币但不允许支出 ETH，或者每天支出总余额的 1%，或者仅与特定应用程序进行交互。
| 参数 | 值 |
|---|---|
我们引入了一种新的EIP-2718交易，即“设置代码交易”，其中 TransactionType（交易类型）为SET_CODE_TX_TYPE，并且 TransactionPayload （交易装载）是以下内容的RLP序列化：
外部交易的字段 chain_id、nonce、max_priority_fee_per_gas、max_fee_per_gas、gas_limit、destination、value、data 和 access_list 遵循 EIP-4844 的相同语义。请注意，这意味着空的（null） destination 是无效的。
authorization_list 是一个元组列表，存储（即提供）签名者希望在其 EOA 的应用场景中执行的地址与代码。如果 authorization_list 的长度为零，交易将被视为无效。
当授权元组（authorization tuple）中的任何字段无法在以下范围内时，该交易也被视为无效：
此交易的 EIP-2718 ReceiptPayload为 rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])（分别对应：状态, 累计交易gas值, 日志_布隆, 日志）。
在执行交易开始时，在增加发送者的nonce后，对于每个[chain_id, address, nonce, y_parity, r, s]元组，执行以下操作：
验证链ID是0或当前链的ID。
authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
将authority添加到accessed_addresses（如EIP-2929中定义）。
验证authority的代码要么为空，要么已经被委托。
验证authority的 nonce 等于 nonce。
如果authority存在于trie（前缀树）中，则将PER_EMPTY_ACCOUNT_COST - PER_AUTH_BASE_COST的gas添加到全局退款计数器中。
将authority的代码设置为0xef0100 || address。这是一个委托标识。
将authority的nonce增加1。
如果上述任何步骤失败，立即停止处理该元组，并继续处理列表中的下一个元组。在多个元组对应同一authority的情况下，将使用最后一个有效出现的地址设置代码。
请注意，授权元组的签名者可能与交易的tx.origin不同。
代理（授权）指示
代理指示使用了EIP-3541中禁止的操作码0xef，以指定代码具有特殊用途。这个指示要求所有检索代码操作都遵循地址指针，以填充可观察的账户代码。受影响的指令包括：EXTCODESIZE、EXTCODECOPY、EXTCODEHASH、CALL、CALLCODE、STATICCALL和DELEGATECALL。
例如，EXTCODESIZE将返回由 address（地址）指向的代码的大小，而不是代表代理指示的 23。CALL 将类似地从 address加载代码，并在 authority（授权）的应用场景中执行它。
如果一个代理指示者指向另一个指示者，形成潜在的指示者链或循环，客户端必须只检索第一个代码，然后停止跟随指示者链。
新交易的内在成本继承自EIP-2930，具体为21000 + 16 * 非零calldata字节 + 4 * 零calldata字节 + 1900 * 访问列表存储键计数 + 2400 * 访问列表地址计数。此外，我们还增加了一个费用，费用为PER_EMPTY_ACCOUNT_COST * 授权列表长度。
交易发送者将为所有授权元组支付费用，无论其有效性或重复性。
如果代码读取指令在解析代表授权代码时访问一个冷账户，则在正常费用上增加2600 gas的EIP-2929 COLD_ACCOUNT_READ_COST费用，并将账户添加到accessed_addresses中。否则，评估100的WARM_STORAGE_READ_COST费用。
修改 EIP-3607 所施加的限制，以允许其代码是有效的代表授权设计（即0xef0100 || address）的外部拥有账户（EOAs）继续发起交易。任何其他代码值的账户均不得发起交易。
（注：Initdode是创建"存储在链上的字节码"的代码。 即通常指的是使用create2操作码时需要的字节码。此处翻译为“初始化代码”） 许多原因使得执行初始化代码并不理想。主要的担忧是它不自然。初始化代码的目的是初始化和部署合约。根据这个EIP，它将承担一个新的角色，以决定是否适合将代码部署到外部账户（EOA）。假设用户只希望在交易的普通调用数据中有相关操作时，代码被部署到他们的账户。这赋予了EOA独特的权力，控制代码在他们账户中何时以及执行什么。虽然EIP-7702如其所写仍在某种程度上允许这样做，但决策缺乏可编程性将迫使钱包不签署许多授权元组，而是专注于只签署指向可配置代理的元组。这使得EOA体验类似于智能合约钱包 。
此外，交易中的初始化代码倾向于在交易内部传播。这意味着它需要包含在授权元组中并进行签名。最小的初始化代码大约为15字节，仅仅是将合约代码从外部地址复制过来。总成本大约为 16 * 15 = 240 的调用数据成本，加上 EIP-3860 的成本 2 * 15 = 30，再加上大约150的运行时成本。因此，光是准备账户就将花费近500额外的 gas；如果没有从外部账户复制，可能成本更高，达到1200+的 gas。
不论是否有初始化代码（Initcode），用户如何指定他们打算在账户中运行的代码也是一个问题。两个主要选项是直接在交易中指定字节码或指定指向代码的指针。最简单的指针就是链上某段代码的地址。
成本分析使答案变得明晰。最小的代理大约为50字节，而地址为20字节。30字节的差距并未提供任何有用的附加功能，并且将在链上低效地复制数十亿次。
此外，直接指定代码的方式将再次使得EOA能够拥有新的独特能力，在交易调用数据中执行任意指定的代码。
从实现的角度和用户理解的角度来看，一致性都是以太坊虚拟机（EVM）的一个重要属性。虽然在外部账户（EOA）的应用场景中考虑过对几类指令的禁令，但作者认为没有足够的理由去这样做。这将迫使智能合约钱包和EOA智能合约钱包走上不同的合约开发道路。
可以建立禁令的主要指令家族是与存储相关的指令和与合约创建相关的指令。我们决定不禁止存储指令主要基于其对智能合约钱包的重要性。尽管可以有一个外部存储合约供智能合约钱包调用，但这效率不高。在未来，新的状态方案甚至可能允许以更低的成本访问某些存储槽。智能合约钱包非常希望利用这一点，而存储合约则无法支持。
创建指令在其他类似EIP的情况下曾被考虑禁止，但由于这个EIP允许EOA在交易内花费价值，因此在交易内增加nonce并使待处理交易失效的担忧并不大。一个有趣的附带效果是，通过结合EIP-7702和CREATE2，可以在不承诺任何费用市场参数的情况下，承诺将特定的字节码部署到一个地址。这解决了长期以来的跨链合约部署的普遍问题。
创建指令在其他类似的以太坊改进提案（EIP）中曾被考虑禁用，然而由于该EIP允许EOA在交易内花费价值，因此在交易内递增 nonce 并使得待处理交易失效的问题并不显著。一个有趣的附带效果是，通过结合 EIP-7702 和 CREATE2，可以在不提交任何费用市场参数的情况下，保证在特定地址部署特定的字节码。这解决了长期以来跨链合约部署的普遍问题。
这个EIP中的签名方案支持灵活的设计模式，可以实现地址 address 的全权委托和更受保护的地址 address委托。
在签署代码指针时需要考虑的一个因素是该地址在另一条链上可能指向什么代码。在某些情况下，验证部署是否是确定性的可能并不是很必要。在这种情况下，可以设置链 ID 以减少授权的范围。对于其他更倾向于普遍部署的情况，例如，委托给钱包代理。在这些情况下，可以将链 ID 设置为 0，以便在所有 EIP-7702 链上都具有效力。钱包维护者将能够将一个单一的 EIP-7702 授权消息硬编码到他们的钱包中，这样跨链代码可塑性就不会成为问题。
添加链 ID 的另一种选择是对地址指向的代码进行签名。这似乎在保留账户中实际运行的代码的特定性同时，最大限度地减少了链上认证元组的大小。然而，这种格式的一大缺点是它要求进行数据库查找，以确定每个认证元组的签名者。这种要求本身似乎在交易传播中产生了足够的复杂性，因此决定避免这种情况，直接对地址进行签名。
与该 EIP 之前的版本以及类似的 EIP 不同，委托指定可以随时通过签署并发送一条带有账户当前 nonce 的新目标的 EIP-7702 授权来撤销。如果不采取此类行动，委托将永久有效。
tx.origin 设置代码允许 tx.origin 设置代码可以简化交易批处理，外部交易的发送者将成为签署账户。目前，ERC-20 的批准后转账模式需要两笔单独的交易，而通过这一提案，可以在一笔交易中完成。
一旦代码存在于外部拥有账户（EOA）中，任何时候该 EOA 的代码发起调用时，自费的 EIP-7702 交易都可以使 msg.sender == tx.origin。在没有 EIP-7702 的情况下，这种情况只能出现在交易的最顶层执行层。因此，该 EIP 打破了这一不变性，因此会影响包含 require(msg.sender == tx.origin) 检查的智能合约。该检查主要用于至少三个目的：
确保 msg.sender 是一个 EOA（因为 tx.origin 总须是 EOA）。这个不变性不依赖于执行层的深度，因此不受影响。
防范像闪电贷这样的原子性三明治攻击，这种攻击依赖于在执行目标合约之前和之后修改状态的能力，作为同一原子交易的一部分。这个保护将被此 EIP 打破。然而，以这种方式依赖 tx.origin 被视为不好的实践，并且已经可以通过矿工有条件地将交易包含在区块中来规避。（译者：道易程的核心合约开发者Elon提交过一个防范闪电贷攻击的EIP。）
防止重入攻击。
(1) 和 (2) 的例子可以在以太坊主网部署的合约中找到，其中 (1) 更常见（且不受此提案影响）。另一方面，用例 (3) 受到此提案的更大影响，但该 EIP 的作者未发现任何这种形式的重入保护示例，尽管搜索并不全面。
这种情况——很多 (1)，一些 (2)，没有 (3)——正是该 EIP 的作者所预期的，因为：
在没有 tx.origin 的情况下确定 msg.sender 是否为 EOA 是困难的（如果不是不可能的话）。
唯一一个安全的原子性三明治攻击执行环境是最顶层的环境，而 tx.origin == msg.sender 是检测该环境的唯一方法。
相比之下，有许多直接且灵活的方法来防止重入（例如，使用瞬态存储变量）。由于 msg.sender == tx.origin 只有在最顶层环境中为真，因此和其他更常见的方法，它是防止重入的冷门的工具。
还有其他方法可以减轻这种限制而不破坏不变性：
在 EOA 的应用场景中使用 CALL* 指令时，将 tx.origin 设置为一个常量 ENTRY_POINT 地址。
将 tx.origin 设置为从发送者或签字者地址派生的特殊地址。
禁止 tx.origin 设置代码。这将使简单批处理的用例变得不可能，但将来可以放宽。
该 EIP 旨在使得最终的账户抽象技术方案高度向前兼容，而不过度依赖 ERC-4337 或 RIP-7560 的任何细节。
具体而言：
用户签名的地址address 可以直接指向现有的 ERC-4337 钱包代码。
所使用的“代码路径”在许多情况下（尽管可能并非全部）在纯智能合约钱包世界中“仍然有意义”。
因此，它避免了“创建两个独立代码生态系统”的问题，因为在很大程度上，它们将是同一个生态系统。在这个解决方案下，确实有一些工作流程需要采取权宜之计，而在“最终账户抽象”下做得会更好，但这相对是一小部分。
它不需要添加任何操作码，这些操作码在后 EOA 世界中会变得无用。
它允许 EOA 伪装成合约以便被包括在 ERC-4337 包中，这种方式与现有的 EntryPoint 兼容。
这个EIP打破了账户余额只能因来自该账户的交易而减少的规则。它还打破了在交易执行开始后EOA nonce不能增加的规则。这些破坏对内存池设计和其他EIP（如包含列表）都有影响。不过，由于账户在外部交易中是静态列出的，所以可以修改交易传播规则，以便不会转发冲突的交易。
以下是代理合约需要谨慎注意的检查或陷阱或条件的非详尽清单，并需要获取账户授权的签名：
重放保护——（例如一个nonce）应该由代理方实现并签名。如果没有，恶意行为者可以重复使用签名，重复其影响。
value—— 如果没有，恶意赞助商可能会导致被调用函数（callee）出现意想不到的效果。
gas——如果没有，恶意赞助商可能会导致被调用方（callee）耗尽 gas 而失败，从而给被赞助方带来麻烦。
target / calldata——如果没有，恶意行为者可能会在任意合约中调用任意函数。
实现不佳的委托代理可能让恶意行为者几乎完全控制签名者的EOA。
tx.origin允许EIP-7702的发送方也设置代码，可能会：
破坏依赖于 tx.origin 的原子三明治保护；
破坏类型为 require(tx.origin == msg.sender) 的重入保护。 该EIP的作者认为，出于理由部分所述的原因，允许这样做的风险是可以接受的。
授权账户可以使赞助交易中继者支付 gas，而无需通过无效化授权（即增加账户的 nonce）或将相关资产转出账户来获得补偿。中继者（relayers）的设计应考虑这些情况，可能需要存入保证金或实施声誉系统。
智能合约钱包开发者必须考虑在未执行的情况下设置账户代码的影响。合约通常是通过执行初始化代码来部署的，以确定要放入账户的确切代码。这使得开发者有机会同时初始化存储槽。账户的初始值不能被观察者替换，因为它们要么在创建交易的情况下由外部账户（EOA）签名，要么通过从初始化代码的哈希中确定合约地址来提交。
该 EIP 并未给开发者提供在委托代理期间运行初始化代码和设置存储槽的机会。为了防止观察者通过控制的账户前置运行委托的初始化，智能合约钱包开发者必须验证初始的 calldata 由 EOA 的密钥使用 ecrecover所做的签名。这确保账户只能用期望的值进行初始化。
允许 EOA 通过委托指定的方式表现得像智能合约，会给交易广播带来一些挑战。传统上，EOA 只能通过交易发送价值。这一不变性使节点能够静态地确定该账户交易的有效性。换句话说，单个交易只能使发送者账户的待处理交易失效。
通过这个 EIP，可能会导致其他账户的交易变得过时。这是因为一旦 EOA 委托给代码，该代码可以在交易的任何时刻被任何人调用。以静态方式判断账户的余额是否被转移变得不可能。
虽然有一些缓解措施，作者建议客户端对任何具有非零委托指定的 EOA 不接受超过一个待处理交易。这最小化了单个交易可能导致的交易失效的数量。另一种选择是扩展 EIP-7702 交易，附带调用者希望在交易过程中“激活”的账户列表。这些账户在包括它们的 EIP-7702 交易中仅表现为委托代码，从而使客户端能够静态分析和推理待处理交易。
一个相关的问题是，EOA 的 nonce 可能在每个交易中递增多次。由于客户端已经需要在更糟糕的情况下保持稳健（如上所述），这应该并非一个多大的安全注意事项。然而，客户端应意识到这种行为是可能的，并相应地设计他们的交易广播。
通过 CC0 放弃版权及相关权利。
请将此文献引用为： Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), Matt Garnett (@lightclient), "EIP-7702: Set EOA account code [DRAFT]," Ethereum Improvement Proposals, no. 7702, May 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7702.
作者
Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), Matt Garnett (@lightclient)
创建日期
2024-05-07
所需
SET_CODE_TX_TYPE
0x04
MAGIC
0x05
PER_AUTH_BASE_COST
2500
PER_EMPTY_ACCOUNT_COST
25000
