Vitalik 提出的EIP-2938将给以太坊带来哪些改变？

作者 | Rajeev Gopalakrishna     

以太坊有两种类型的账户。外部自有账户（EOA）和合约账户（CA）。EOAs由私钥控制，而CA由其中包含的智能合约代码控制。EOAs一直比CA更有特权，因为只有EOAs可以通过支付gas开始交易执行。账户抽象(AA)是一个提案，它允许合约像EOA一样成为一个 "顶层 "账户，其可以支付费用并开始交易执行。

账户抽象的动机是显著改善用户在钱包、DApps和DeFi等各种场景下与以太坊进行交互时的用户体验。账户抽象在以太坊中提供了一个基础层的功能，来决定什么时候可以支付gas，以及对谁支付gas等问题。

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

在本文中，我们提出了智能合约钱包背景下对账户抽象的需求。然后，我们通过描述协议变化和对节点的影响深入探讨账户抽象的关键方面。最后，我们讨论了一些扩展的提议，并通过合理化与以太坊接口的Status项目的计划路线图来结束，这些项目可能都会受到账户抽象的影响。

历史&动机

账户抽象最初是在2017年以EIP-86的形式提出的，目的是实现 "交易来源和签名的摘要"，但这一想法的起源可以追溯到更早的2016年。当时有人建议："与其有一个协议内机制，将ECDSA和默认的nonce方案作为唯一的 「标准 」方式来保证账户的安全，不如采取初步措施，建立一个模型，从长远来看，所有的账户都是合约，并且合约可以支付gas，用户可以自由定义自己的安全模型。"

最初的建议被认为是具有挑战性的，因为需要改变许多协议并且需要保证安全性。最近，Vitalik等人提出了EIP-2938的草案，该草案概述了一个更容易实现的方法：通过将协议/共识的变化最小化，并通过节点mempool规则强制执行所需的安全保证。由Sam Wilson和Ansgar Dietrichs(另外两位EIP作者)撰写的Vitalik的以太坊 Engineering Group Meetup presentation和ETH Online presentation(以及相关文章1和2)为这个主题提供了更详细的介绍。本文重点介绍了所有这些来源的关键内容。

动机：账户抽象背后的动机原理非常简单，但却是根本性的：今天的以太坊交易具有可编程的效果（通过调用智能合约实现），但它们只具有固定的有效性，即只有当它们具有有效的ECDSA签名与有效的nonce，并且具有足够的账户余额时，交易才是有效的。账户抽象通过引入一种新的账户抽象交易类型，将交易从固定有效性升级为可编程有效性。这种账户抽象交易类型总是来自一个特殊的地址并且协议不需要对其进行签名、Nonce或余额检查。这种账户抽象交易的有效性由目标智能合约决定，目标智能合约可以执行自己的有效性规则，之后它可以决定为这类交易付款。

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

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

智能合约钱包是通过智能合约在链上实现的。这种钱包通过实现多签名安全、社交或基于时间的恢复、交易或金额的速率限制、允许/拒绝地址列表、无gas交易和批量交易等功能，提供可编程的功能缓解风险以及用户友好体验。

虽然智能合约钱包暴露在易受攻击的智能合约的安全风险之下，但钱包提供商执行的安全测试和审查可以减轻这种风险。EOA钱包的风险完全在于钱包用户，他们被委托负责种子短语的安全，而在智能合约中没有任何可保障安全的程序。

智能合约钱包的例子有Argent、Authereum、Dapper、Dharma、Gnosis Safe、Monolith和MYKEY。如下图所示，这类钱包的采用率似乎在增加。

Argent通过他们的Guardians概念实现了无密钥社交恢复功能，其中Guardians是用户信任的人或设备，可以帮助找回用户的钱包。Argent还旨在实现类似银行的安全性（通过每日交易限额、账户锁定和可信联系人等功能）以及类似Venmo的可用性（通过使用ENS名称而非地址和支持元交易）相结合。

Gnosis Safe是一个多签名的智能合约钱包，专注于团队管理资金，需要团队成员的最低数量（m-of-n）批准交易才能发生。它还可以通过元交易实现无gas签名。

所有这些先进的钱包功能都需要使用完善的智能合约。钱包用户要么需要与EOA进行交互，要么依赖钱包提供商通过提供商的中继器或第三方中继器网络（如 Gas Station Network）来支持元交易。前者依赖于在KYC后的中心化交易所购买ETH，而后者旨在通过将用户的负担转移到中继器上，以减少这种上链用户体验摩擦，其成本由钱包提供商链上/链下和/或用户链下补偿。

然而，基于中继器的架构有三个主要缺点：(1)它们可能会被认为是中心化的中介机构，有可能会对交易进行审查(2)由于中继者的交易需要额外的21000基础gas fee，而且它们的业务需要在gas fee之外获得利润，因此在技术/经济上效率低下(3)使用中继者专用协议迫使应用依赖非基底层的以太坊基础设施，其用户群较小，可用性保证不确定。

账户抽象将使智能合约钱包能够接受用户的无gas交易，并在不依赖中继层网络的情况下为其支付gas 费。因此，这种基层能力将极大地改善这类钱包的入驻用户体验，而不会牺牲以太坊的去中心化保障。

Tornado Cash：一个相关的动机应用是混币器，如tornado.cash，其中Tornado通过使用智能合约打破地址之间的链上联系来改善交易隐私，该合约接受ETH存款，随后可由不同的地址提取。用户在存款时需要提供秘密的哈希值，之后在提现时提供zkSnark证明，以显示对秘密的了解，而不泄露秘密或之前的存款本身。这样就把提现和存款脱钩了。

但提现存在一个问题，要从新生成的地址中执行提现交易，用户需要在里面有一些ETH来支付gas。这个ETH的来源（一般是交易所）会破坏Tornado的隐私。首选的替代方案是再次使用中继器网络，但是它有前面概述的缺点。

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

账户抽象

EIP-2938号文件提出的账户抽象，允许合约成为支付费用和开始执行交易的最高级账户。这是通过引入协议变化实现的，新的账户抽象交易类型需要两个新的操作码：NONCE和PAYGAS，对mempool的规则进行改变以及支持高级用法的扩展。账户类型仍然有两种类型（EOA和合约账户），所有拟议的变化都与当前的交易、智能合约和协议向后兼容。

账户抽象的应用分为两个方面考虑：1）单租户应用，如智能合约钱包，为每个用户创建一个新的合约 2）多租户应用，如tornado.cash或Uniswap，多个用户与同一套智能合约交互。

账户抽象对多租户应用的支持需要更多的研究，建议作为未来的工作。所以我们将在本文中重点讨论单租户账户抽象的支持。

协议变化

引入了一种新的交易类型，以及两个支持NONCE和PAYGAS的操作码。这些是唯一的协议变化。

账户抽象交易：引入了一种新的账户抽象交易类型AA_TX_TYPE。它的有效类型被解释为RLP([nonce, target, data])，而不是现有的交易类型。后者的有效类型是RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s])。

账户抽象交易中省略的gas_price和gas_limit在执行过程中由目标账户抽象合约指定。账户抽象交易中省略的 ECDSA 签名 v、r、s 由特定合约对数据进行验证检查代替。to 地址由目标合约地址代替。之所以省略该值，是因为所有账户抽象交易的始发地址是一个特殊的ENTRY_POINT地址(0xFFFF...FFF)，而不是与之相关联的EOA值。

如果检查失败，则交易被认为是无效的，否则，tx.target.nonce将被递增，交易继续进行。

账户抽象交易的基本gas成本建议为15000，而不是目前的21000（以反映缺乏内在ECDSA签名所节省的成本）。此外，账户抽象交易没有内在gas限额。在开始执行时，gas限值只需设定为该组的剩余gas。

NONCE操作码：NONCE操作码(0x48)将被调用者的NONCE(即账户抽象目标契约)压入EVM堆栈。因此，Nonce暴露给EVM，以允许对所有交易字段（包括nonce）进行签名验证，作为账户抽象合约中验证的一部分。

PAYGAS操作码：PAYGAS操作码(0x49)从堆栈中取出两个参数: (顶部)version_number, (顶部第二个)memory_start. version_number允许未来的实现改变opcode的语义。目前，该操作码的语义如下。

检查 version_number == 0 (否则抛出异常)

提取 gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])

提取 gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])

检查contract.balance >= gas_price * gas_limit (否则抛出异常)

检查 globals.transaction_fee_paid == False (否则抛出异常)

检查AA执行框架==顶层框架，即如果当前EVM执行退出或还原，则整个事务的EVM执行终止（否则抛出异常）。

设置contract.balance -= gas_price * gas_limit(限制)。

设置 globals.transaction_fee_paid = True

设置 globals.gas_price = gas_price 和 globals.gas_limit = gas_limit。

设置当前执行上下文的剩余gas=gas_limit-已经消耗的gas。

在账户抽象交易执行结束时，（globals.gas_limit - remaining_gas）*globals.gas_price转移给矿工，账户抽象合约退还 remaining_gas * globals.gas_price。

PAYGAS作为EVM执行检查点。在此点之后的任何还原都只会还原到这里，然后合约不接受退款，globals.gas_limit * globals.gas_price转移到矿机。

新的交易类型和两个新的操作码构成了协议/共识层面的变化，它们的语义是比较容易理解。

Mempool规则

"Mempool "指的是以太坊节点内部的一组内存数据结构，它在挖矿前存储候选交易。Geth称其为 "交易池"；Parity称其为 "交易队列"。无论名称如何，它都是一个坐在内存中等待被纳入区块的交易池。把它看成是一个 "等待区"，等待交易被接受到一个区块中。"

目前，通过固定的交易有效性规则，矿工和其他节点只需要最小的努力就可以验证其mempool中的交易，从而避免DoS攻击。例如，如果一个矿工拥有有效的ECDSA签名、有效的nonce，并且有足够的账户余额，就可以确定某笔交易将真正支付费用。该矿工的mempool中的其他交易只有在来自同一地址，并且，增加nonce或充分减少账户余额的情况下，才可能使这个待处理的交易无效。这些条件在计算上是最小的，以使矿工和节点对其mempools有足够的信心，分别进行区块等待或重播。

账户抽象交易以其可编程的有效性引入了更多的复杂性。账户抽象交易不支付任何前期gas，并依靠其目标账户抽象合约来支付gas（通过PAYGAS）。从概念上讲，账户抽象交易处理分为两个阶段：较短的验证阶段（PAYGAS之前）和较长的执行阶段（PAYGAS之后）。如果验证阶段失败（或抛出异常），交易无效（就像今天无效签名的非账户抽象交易一样），不会被包含在一个区块中，矿工也得不到任何费用。

因此，矿工和节点需要一个可预测的机制来避免一个待处理的账户抽象交易的有效性对mempool中其他待处理交易的依赖性。否则，一个交易的执行可能会使mempool中的许多/所有账户抽象交易无效，导致DoS攻击。为了避免这种情况，有两个建议的规则要在mempools中的账户抽象交易上执行（由矿工和节点执行，但不是在协议本身）。

Opcode Restriction

为了防止账户抽象交易的有效性取决于账户抽象合约本身以外的任何因素，以下操作码在核查阶段(即在PAYGAS之前)被视为无效：PAYGAS之前）：环境操作码（BLOCKHASH、COINBASE、TIMESTAMP、NUMBER、DIFFICULTY、GASLIMIT）、BALANCE（任何账户，包括目标本身）、对目标以外的任何事物的外部调用/创建或预编译（CALL, CALLCODE、STATICCALL、CREATE、CREATE2）和读取代码的外部状态访问（EXTCODESIZE、EXTCODEHASH、EXTCODECOPY、DELEGATECALL），除非地址是目标。

节点要放弃mempool中以账户抽象合约为目标的账户抽象事务，打破这个操作码限制规则。这确保了只要账户抽象合约状态不发生变化，mempool中的有效账户抽象事务将保持有效。

字节码前缀限制

如果非账户抽象事务可以影响账户抽象合约的状态，那么就会影响mempool中账户抽象事务的有效性。为了防止这种情况的发生，账户抽象事务应该只允许针对那些在其字节码开头有AA_PREFIX的合约，其中AA_PREFIX实现了对msg.sender是账户抽象事务的特殊ENTRY_POINT地址的检查。这有效地防止了非账户抽象交易与账户抽象合约的交互。

节点要把账户抽象事务丢给在其字节码入口点没有这个AA_PREFIX的账户抽象合约。

对账户抽象合约实施的这两个限制共同确保了：(1)账户抽象交易的有效性逻辑所能访问的唯一状态是账户抽象合约内部的状态，(2)这个状态只能被其他针对这个特定账户抽象合约的账户抽象交易修改。

因此，只有在另一宗针对同一份账户抽象合约的等待交易中，未完成的账户抽象交易才会失效。然而，鉴于这些不是协议/共识的改变，矿工可以自由地在区块中包含打破这些规则的交易。

扩展

上述协议变更和mempool规则允许基本的账户抽象合约充分而安全地实现单租户应用，如智能合约钱包。其他需要放宽上述规则或需要实现多租户应用的高级用法，则需要账户抽象以扩展的形式提供更多的支持，比如。

SET_INDESTRUCTIBLE opcode，禁用SELFESTRUCT，允许账户抽象合约在验证阶段安全地调用DELEGATECALL的库。

IS_STATIC opcode，如果当前上下文是静态的，则返回true，允许非账户抽象事务调用者覆盖之前的字节码前缀限制，安全地从账户抽象合约中读出值。

RESERVE_GAS opcode，当从一个非账户抽象事务调用时，它建立了一个账户抽象合约消耗的gas下限，该下限是寻求写入合约状态的。这样做的作用是迫使攻击者不消耗最低数量的gas，以抑制试图使mempool中任何账户抽象事务无效的行为。

还有其他的如多个待处理的交易、验证的缓存结果、验证的动态gas限制和赞助交易，这些都是支持多租户应用和zk证明所需要的，如Tornado Cash。关于它们的详细内容不在本文的讨论范围内。

下一步工作

账户抽象EIP-2938目前处于草案模式，正在以太坊研究论坛中进行讨论。EIP的下一步是被考虑纳入即将到来的硬分叉之一。EIP作者的目标显然是Berlin之后的硬分叉（Berlin暂定于2021年初的某个时间），其时间表目前还不是很明确。所以对于EIP-2938来说，现在还为时过早。

此外，也不清楚是否有必要在以太坊基础第1层（L1）加入EIP-2938。鉴于第2层（L2）解决方案的相对灵活性（如我们之前的文章所述），账户抽象可以在特定的L2上实现，而不需要升级整个L1。然而，即使一些L2实现了自己的账户抽象版本，在L1上统一支持账户抽象也有好处。因此，账户抽象在哪里实现，如何实现，还有待观察。

“账户抽象不太重要是因为不管L1是否支持，都可以在L2上实现。”--- Vitalik在他关于以汇总为中心的以太坊路线图的文章中谈到了在基础层将继续起作用的事情）。

Status：Status钱包目前是一个EOA钱包，它的区别在于捆绑了一个以隐私为中心的短信系统，并实现了聊天中的支付或Keycard的增强安全性等集成。正在考虑智能合约钱包的功能，如多签和社交恢复，账户抽象 EIP-2938的支持将有助于消除对集中式和低效的基于relayer的架构的依赖，如前所述。

Status也在评估L2解决方案，既要支持其钱包中的多链，又要为各种用例提供所需的扩展，如我们在前面的文章中所述。例如，Keycard正在探索一个支付网络，其信用卡级别的可扩展性和近乎即时的终局性的设计要求是目前以太坊网络无法满足的。此外，还有许多其他的计划，如推荐计划、Tribute-to-Talk和ENS名称，所有这些计划都将受益于L2扩展性，以实现可行的部署和合理的用户体验。如果一个可行的L2解决方案实现了账户抽象，那么建立在该L2基础上的项目将能够利用账户抽象的优势，而不必依赖L1。

总结

以太坊协议的一个基本方面是，只有外部自有账户(EOAs)可以支付gas费并开始执行交易。合约账户（CA）不能这样做。账户抽象（AA）是一个提案，旨在改变这种区别，允许专门构建的CA以编程方式检查新型账户抽象交易的有效性，决定代为支付gas费，从而有效地启动其执行，而不需要EOA。

账户抽象对于显著改善钱包、混币器、DApps和DeFi等各种场景下的用户体验具有意义，而无需依赖中心化和低效的基于relayer的架构。基本的单租户场景，如智能合约钱包，通过引入一种新的交易类型、两种新的操作码和两种mempool规则，账户抽象可以安全地支持。高级多租户应用，如Tornado Cash，需要对这些协议变化和节点规则进行扩展。

在这篇文章中，我们提到了智能合约钱包背景下对账户抽象的需求。我们通过描述协议变化和对节点的影响来强调账户抽象的关键方面。我们触及了一些针对高级用途的拟议扩展，最后，我们在以太坊当前的路线图和Status的优先事项中对账户抽象进行了定位。

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