vitalik的eip-2938会给以太坊带来什么变化？

作者拉杰里亚夫；

a6021和以太坊中有两种类的帐户。外部自有账户（EOA）和合同账户（CA）。EOA由私钥控制，CA由其中包含的智能合约代码控制。EOA总是比Ca更有特权，因为只有EOA可以通过支付gas来启动事务执行。账户抽象（accountabstraction，AA）是一个提议，允许合同成为一个像EOA一样的“**”账户，它可以支付费用并启动交易执行。

账户抽象的动机是在各种场景（如wallet、dapps和DeFi）中与以太坊交互时显著改善用户体验。Account abstraction在以太坊中提供了一个基本的层函数来决定何时支付天然气以及向谁支付天然气。

status messenger应用程序将以隐私为中心的信息系统与以太坊钱包和Web3 DAPP浏览器集成在一起。Status wallet目前是一个EOA钱包，它限制了我们提供只有智能合约钱包才能提供的丰富用户体验，如多重签名安全、社交恢复、利率限制、允许/拒绝地址列表和无气元交易。目前，智能合约钱包用户体验到GAS FEE波动的影响，而第三方中继器无法有效解决这一问题。帐户抽象就是为了解决这个问题而设计的。

本文提出了智能合约钱包环境下账户提取的需求。然后，我们通过描述协议更改及其对节点的影响来探讨帐户抽象的关键方面。**，我们讨论了一些扩展建议，并对与以太坊接口的状态项目的计划路线图进行了合理化，这可能会受到帐户抽象的影响。

历史与动机

账户提取最初是在2017年以eip-86的形式提出的，目的是实现“交易来源和签名汇总”，但这一想法的起源可以追溯到2016年。当时有人建议，“与其采用协议内机制，将ECDSA和默认nonce方案作为确保账户安全的唯一“标准”方式，不如采取初步措施建立模。从长远来看，所有账户都是合同，合同可以支付GAS FEE用，用户可以自由定义自己的安全模。”

最初的提议被认为具有挑战性，因为许多协议需要更改，安全性需要得到保证。最近，vitalik等人。提出了一个eip-2938的草案，该草案概述了一种更简单的实现方法：通过最小化协议/一致性更改和通过节点MemPool规则强制执行所需的安全保证。Vitalik的以太坊工程组会议报告和由Sam Wilson和Ansgar Dietrich（其他两位EIP作者）撰写的ETH在线演示文稿（以及相关文章1和2）对该主题进行了更详细的介绍。本文重点介绍了所有这些来源的关键元素。

动机：账户抽象背后的动机原理非常简单，但它很重要：今天的以太坊事务具有可编程的效果（通过调用智能合约实现），但它们只有固定的有效性，即只有当事务具有有效的ECDSA签名和有效的nonce时，它们才有效，账户余额充足。通过引入一种新的账户抽象交易，账户抽象将交易从固定有效性提升到可编程有效性。这种类的帐户抽象事务总是来自一个特殊的地址，协议不需要签名、一次性或余额检查。账户抽象交易的有效性由目标智能合约决定，智能合约可以实现自己的有效性规则，然后决定为此类交易支付费用。

为什么这个有用呢？以以太坊钱包为例，强调账户抽象的好处。

智能合约钱包：目前大多数以太坊钱包都是EOA钱包，由种子短语生成的私钥保护。（bip-39子短语是从2048个单词中随机抽取的12-24个单词的有序列表。这提供了获取二进制种子所需的熵，该种子是使用pbkdf2函数生成的。然后，使用二进制种子生成bip-32钱包的非对称密钥对。)用户应该把种子短语写在一个安全的地方，因为以后可能需要它来恢复另一个钱包上的密钥。然而，这种钱包很容易受到私钥被盗或种子短语丢失的影响，从而导致用户资金的损失。

智能合约钱包是通过智能合约在链上实现的。该钱包提供了可编程功能，通过实现多重签名安全、社交或基于时间的恢复、交易或金额的费率限制、允许/拒绝地址列表、禁止气体交易和批量交易来降低风险和用户友好体验。

尽管智能合约钱包面临易受攻击的智能合约的安全风险，但钱包提供商进行的安全测试和审计可以减轻这种风险。EOA钱包的风险完全在于钱包用户，他们被赋予种子短语的安全性，智能合约中没有安全程序。

智能合约钱包的例子有argent、authoreum、dapper、Dharma、Gnosis safe、monolith和MyKey。如下图所示，这些钱包的使用率似乎在增加。

用户可以通过“守护者”或“守护者”的概念来检索用户的密钥，这可以帮助用户恢复他们信任的设备。Argent还被设计为结合了类似银行的安全性（通过日常交易限额、账户锁定和可信联系人）和类似venmo的可用性（通过使用ENS名称而不是地址并支持元交易）。

Gnosis safe是一个多签名智能合约钱包，专注于团队资金管理，需要最少的团队成员（M-of-N）来批准交易。它还可以通过元事务实现无气签名。

所有这些先进的钱包功能都需要智能钱包。钱包用户要么需要与EOA交互，要么依赖钱包提供商通过提供商的中继器或第三方中继器网络（如加油站网络）支持元交易。前者则是通过用户的网银/**服务商中心化支付用户的网银/网银，以减少网银/网银用户的**负担。

然而，基于中继器的体系结构有三个主要缺点：（1）它们可能被视为中心化的中介，并且可能审查事务；（2）由于基于中继的事务需要额外的21000基本gas费用，并且它们的业务需要在gas中（3）使用特定于中继的协议迫使应用程序依赖于非基础层以太坊基础设施，用户基数小，可用性保证不确定。

账户提取将使智能合约钱包能够接受用户的无油交易并为其支付GAS FEE用，而无需依赖中继层网络。因此，这种草根能力将大大改善此类钱包的用户体验，而不会牺牲以太坊的去中心化保障。

Tornado cash：一个相关的动机应用程序是money mixer，例如龙卷风现金Tornado通过使用智能合约断开地址之间的链接来提高事务隐私性。合同接受以太坊押金，可按不同地址提取。用户在存款时需要提供该秘密的散列值，然后提供zksnark证明，以表明他们对该秘密的理解，而不泄露该秘密或之前的存款本身。这样，取款和存款就脱钩了。

不过，撤军有问题。要从新生成的地址执行取款事务，用户需要在其中包含一些ETH来支付煤气费。这种ETH的来源（通常是交易所）会破坏龙卷风的隐私。**的替代方案是重用中继器网络，但它有前面概述的缺点。

账户提取将解决这个问题，允许tornado合同接受用户的取款账户抽象交易，然后验证zksnark并扣除一些煤气费（从之前的存款金额中扣除），然后将剩余的存款金额转移到取款地址。

账户抽象

eip-2938号文件中提出的账户抽象允许合同成为支付费用和启动交易的**账户。这是通过引入协议更改来实现的。新的account Abstract事务类需要两个新的操作码：nonce和paygas，这将更改MemPool的规则并支持**用法的扩展。仍然有两种类的帐户类（EOA和合同帐户），所有提议的更改都向后兼容当前事务、智能合约和协议。

账户抽象的应用分为两个方面：1）单租户应用，如智能合约钱包，为每个用户创建新的合约；2）多租户应用，如龙卷风现金或者Uniswap，多个用户使用同一组智能合约进行交互。

多租户应用对帐户抽象的支持还需要进一步的研究，这是今后工作的方向。因此，在本文中，我们将重点关注对单租户帐户抽象的支持。

协议变更

介绍了一种新的事务类和支持nonce和paygas的两个操作码。这些是协议的唯一改动。

抽象账户交易：本文引入了一种新的账户抽象交易AA_x_uType，其有效类被解释为RLP（[nonce，target，data]），而不是现有的交易类。后者的有效类是RLP（[nonce，gas）price，gas_ulimit，to，value，data，v，r，s]）

账户抽象交易中的遗漏气体－价格和气体－限额由目标账户抽象合约在执行过程中规定。账户抽象交易中省略的ECDSA签名V、R、s被具体合同的数据验证检查所代替。目标合同地址替换为目标合同地址。由于所有帐户抽象事务的起始地址是一个特殊的入口点地址（0xFFFF。。。而不是与之相关的EOA值。

如果检查失败，则认为事务无效；否则，tx.target.nonce发送.target.nonce将递增，事务将继续。

账户摘要交易的基本天然气成本建议为15000而不是21000（以反映由于缺乏内部ECDSA签名而节省的成本）。此外，账户抽象交易没有天然气限额。在执行开始时，气体限制只需设置为组的剩余气体。

Nonce操作码：Nonce操作码（0x48）将调用方的Nonce（即account Abstract target contract）推入EVM堆栈。因此，nonce向EVM公开，以允许对所有事务字段进行签名验证，包括nonce，作为帐户抽象契约中验证的一部分。

Paygas操作码：Paygas操作码（0x49）从堆栈中获取两个参数：（顶部）版本号（位于顶部的第二个）内存启动。版本号允许将来的实现更改操作码的语义。目前，操作码的语义如下。

检查版本号==0（否则引发异常）

提取气体价格=字节数虚拟内存[内存启动：内存启动+32]）

提取气体极限=字节数虚拟内存[内存启动+32：内存启动+64]）

检查合同余额gt；=汽油价格*汽油价格限制（否则抛出异常）

检查全局事务处理fee_upay==false（否则抛出异常）

Check AA execution framework==top-level framework，即如果当前的EVM execution退出或恢复，则终止整个事务的EVM执行（否则抛出异常）。

设置合同余额-天然气价格。

设置全局事务处理费用已付=真

设置全球煤气公司价格=天然气价格和全球煤气公司极限=气体极限

gas的剩余执行上下文=gas_ulimit gas consumped。

在账户结束时执行抽象交易（全球煤气公司限制-剩余气体）*全球煤气公司价格转移给矿工，账户的抽象合同返回给剩余的天然气*全球煤气公司价格

执行Paygas检查点。在此之后的任何修复只会在这里恢复，合同不接受退款，全球煤气公司限制*全球煤气公司价格转给矿工。

新的事务类和两个新的操作码构成了协议/共识级别的变化，它们的语义更容易理解。

内存池规则

“MemPool”是指以太坊节点中的一组内存数据结构，它在挖矿之前存储候选事务。GETH称之为“交易池”；parity称之为“交易队列”。不管名称是什么，它都是一个存储在内存中的交易池，等待被包含在块中。把它想象成一个“等待区”，等待交易被接受成一个区块。”

目前，通过固定的事务有效性规则，矿工和其他节点可以以最小的努力验证其MemPool中的事务，从而避免DoS攻击。例如，如果一个矿工有一个有效的ECDSA签名、一个有效的nonce和足够的帐户余额，则可以确定一个事务将实际支付。miner MemPool中的其他事务只能在来自同一地址并增加nonce或充分减少帐户余额的情况下使挂起的事务无效。这些条件在计算上是最小的，因此矿工和节点对它们的内存池有足够的信心来分别等待或重放块。

抽象账户交易由于其可编程的有效性而引入了更多的复杂性。Account Abstract transaction不支付任何先前的gas，并依赖其目标帐户抽象合同（通过paygas）支付gas。从概念上讲，帐户抽象事务处理分为两个阶段：短验证阶段（paygas之前）和长执行阶段（paygas之后）。如果验证阶段失败（或抛出异常），则该事务无效（就像今天具有无效签名的非帐户抽象事务），它将不会包含在块中，并且矿工将不会收到任何费用。

因此，矿工和节点需要一个可预测的机制，以避免一个挂起帐户抽象事务的有效性依赖于MemPool中的其他未决事务。否则，执行一个事务可能会使MemPool中的许多/所有帐户抽象事务失效，从而导致DOS攻击。为了避免这种情况，有两个建议的规则要在memopools中的帐户抽象事务上实现（由矿工和节点实现，而不是在协议本身上）。

操作码限制

为了防止账户抽象交易的有效性不依赖于账户抽象合约本身之外的任何因素，在验证阶段（即在paygas之前），以下操作码被视为无效：环境操作码（blockhash、CoinBase、时间戳、数字、差异、gaslimit）、余额（任意帐户，包括目标本身）、除目标外部调用/创建或预编译（callcode、staticcall、create、create2）和外部读取代码状态访问（extcodesize、extcodehash、extcodecocopy、delegatecall）之外的任何其他类的代码。

节点需要放弃MemPool中以account Abstract contract为目标的account Abstract事务，打破了这个操作码限制规则。这确保只要帐户抽象契约的状态不变，MemPool中活动的帐户抽象事务将保持有效。

字节码前缀限制

如果非账户抽象交易能够影响账户抽象契约的状态，则会影响账户抽象交易在MemPool中的有效性。为了防止这种情况发生，帐户抽象事务应该只允许那些在字节码前缀契约开始时具有AA的用户，其中AA前缀实现消息发送者是帐户抽象交易的一个特殊条目，检查点地址。这有效地防止了非账户抽象交易与账户抽象契约之间的相互作用。

节点应该在其字节码入口点向AA抛出account Abstract事务作为前缀。

对抽象帐户契约的两个限制保证：（1）帐户抽象事务的有效性逻辑唯一可以访问的状态是帐户抽象契约的内部状态；（2）此状态只能由该特定帐户抽象契约的其他帐户抽象事务修改。

因此，只有在另一个等待交易的同一账户抽象契约中，未完成的账户抽象交易才是无效的。然而，鉴于这些不是协议/共识的变更，矿业公司可以自由地将违反这些规则的交易纳入区块。

延伸

上述协议更改和MemPool规则允许基本帐户抽象契约全面、安全地实现单个租户应用程序，例如智能合约钱包。对于其他需要放宽上述规则或实现多租户应用程序**用法的用户，帐户抽象需要以扩展的形式提供更多的支持，例如。

SET_It允许帐户抽象契约在验证阶段安全地调用delegatecall库。

是静态操作码。如果当前上下文是静态的，则返回true，允许非帐户抽象事务调用方重写以前的字节码前缀限制，并安全地从帐户抽象协定中读取值。

当从非账户抽象交易中调用RESERVE_Ugas操作码时，它为账户抽象合约的消费建立了一个Gas下限，该下限旨在写入合约状态。这样做的目的是迫使攻击者不要消耗最少的气体来阻止试图使MemPool中的任何帐户抽象事务失效的行为。

还有一些其他事务，如多个挂起的事务、经过验证的缓存结果、经过验证的动态气体限制和赞助的事务，这些都需要支持多租户应用程序和ZK证明，如tornado cash。关于它们的细节超出了本文的范围。

下一步

账户摘要eip-2938目前处于草稿模式，正在以太坊研究论坛上讨论。EIP的下一步是考虑将其纳入即将到来的“硬分叉”中。EIP作者的目标显然是柏林之后的硬分岔（柏林暂定在2021年初的一段时间），其时间表仍然不清楚。所以现在对eip-2938还为时过早。

此外，还不清楚是否需要将EIP-29 38添加到以太坊的基础层1（L1）中。由于L1（L2）相对灵活，我们可以像L2中描述的那样升级整个解决方案。然而，即使某些L2实现了自己版本的帐户抽象，在L1上统一支持帐户抽象也是有益的。因此，在何处以及如何实现帐户抽象还有待观察。

“账户抽象不那么重要，因为不管L1是否支持它，它都可以在二级语言上实现。”——维塔利克在他关于以聚合为中心的以太坊路线图的文章中谈到了在基础层将继续工作的内容。

状态：状态钱包当前为EOA钱包。不同之处在于，它与一个以隐私为中心的短信系统捆绑在一起，并集成了聊天中的支付功能或增强的密钥卡安全性。考虑到智能合约钱包的多点签名和社交恢复等功能，账户摘要eip-2938的支持将有助于消除上述对中心化式和低效中继式架构的依赖。

Status还在评估L2解决方案，以支持钱包中的多个链，并为各种用例提供必要的扩展，如我们在上一篇文章中所述。例如，keycard正在探索一种支付网络，其对信用卡级别的可扩展性和近乎即时终结性的设计要求超出了目前的以太坊网络。此外，还有许多其他方案，如推荐程序、distribute to talk和ENS name，所有这些都将受益于L2可伸缩性，以实现可行的部署和合理的用户体验。如果不依赖L2的抽象就可以考虑到项目的可行抽象。

总结

以太坊协议的一个基本方面是，只有外部自有账户（EOA）才能支付GAS FEE用并开始执行交易。合同帐户（CA）无法执行此操作。Account abstraction（AA）是一种改变这种区别的建议，它允许专门构建的CA以编程方式检查新帐户摘要交易的有效性，并决定代表它们支付GAS FEE用，从而有效地在没有EOA的情况下启动其执行。

帐户抽象可以显著改善用户在各种场景中的体验，如钱包、硬币混合器、dapp和DeFi，而不依赖于中心化式和低效的基于中继的架构。通过引入新的交易类、两个新的操作码和两个MemPool规则，可以安全地支持基本的单租户场景，如智能合约钱包。**多租户应用程序，如tornado cash，需要扩展这些协议更改和节点规则。

在本文中，我们提到了在智能合约钱包的上下文中进行帐户抽象的必要性。我们通过描述协议更改及其对节点的影响来突出帐户抽象的关键方面。我们讨论了一些建议的**应用扩展，**，我们在以太坊的当前路线图和状态优先级中定位了帐户抽象。

减少摩擦和改善Web3中的用户体验是这个生态系统中所有项目的首要任务。帐户抽象，在某种形式上，肯定会在未来的努力中发挥重要作用。