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

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

帐户抽象背后的动机是在钱包、DApps 和 DeFi 等各种场景中显着改善与以太坊交互时的用户体验。 账户抽象在以太坊中提供了一个基础层功能来决定何时可以支付 gas 以及向谁支付 gas。

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

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

历史与动机

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

由于需要进行许多协议更改并且需要保证安全性，因此最初的提议被认为具有挑战性。 最近，Vitalik 等人。 提出了 EIP-2938 草案，其中概述了一种更可实现的方法：通过最小化协议/共识更改并通过节点内存池规则强制执行所需的安全保证。 Vitalik 的 Ethereum Engineering Group Meetup 演示和 Sam Wilson 和 Ansgar Dietrichs（另外两位 EIP 作者）的 ETH Online 演示（以及相关文章 1 和 2）提供了对此主题的更详细介绍。 本文重点介绍了所有这些来源的要点。

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

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

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

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

虽然智能合约钱包面临易受攻击的智能合约的安全风险，但可以通过钱包提供商执行的安全测试和审计来减轻这种风险。 EOA 钱包的风险完全由钱包用户承担，他们被委托种子短语的安全性，而没有智能合约中的任何程序来确保安全性。

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

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

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

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

然而，基于中继器的架构有三大缺点：（1）它们可能被认为是中心化中介，可能会审查交易（2）由于中继器而产生的交易需要额外的 21,000 基础燃料费，并且它们的业务需要在燃料费之外赚取利润，因此在技术/经济上效率低下 (3) 使用 relayer-only 协议迫使应用程序依赖非基础层以太坊基础设施，其用户群较小，无法保证可用性。

账户抽象将使智能合约钱包能够在不依赖中继层网络的情况下接受用户的无气体交易并为他们支付气体费用。 因此，这种草根功能将大大改善此类钱包的入门用户体验，而不会牺牲以太坊的去中心化保证。

Tornado Cash：一个相关的激励应用程序是混币器，例如 tornado.cash，其中 Tornado 通过使用接受 ETH 存款的智能合约打破地址之间的链上关系来提高交易隐私，随后可以由不同的地址提取。 用户在存款时需要提供秘密的哈希值，然后在提款时提供 zkSnark 证明以表明知道秘密，而不会泄露秘密或先前的存款本身。 这使提款与存款脱钩。

但是提款有问题。 要从新生成的地址执行取款交易，用户需要在其中有一些 ETH 来支付 gas。 这个 ETH 的来源（通常是交易所）会损害 Tornado 的隐私。 首选的替代方案同样是使用中继器网络，但它具有前面概述的缺点。

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

帐户抽象

EIP-2938 提出的账户抽象允许合约成为支付费用并开始执行交易的最高级别账户。 这是通过引入协议更改、需要两个新操作码的新帐户抽象交易类型来实现的：NONCE 和 PAYGAS、内存池规则的更改以及支持高级使用的扩展。 仍然有两种账户类型（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 成本建议为 15,000，而不是目前的 21,000（以反映由于缺乏内在 ECDSA 签名而节省的成本）。 此外，账户抽象交易没有内在的 gas 限制。 在执行开始时，只需将气体限制设置为该组的剩余气体。

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

PAYGAS 操作码：PAYGAS 操作码 (0x49) 从堆栈中获取两个参数：version_number、memory_start。 version_number 允许未来的实现改变操作码的语义。 目前，该操作码的语义如下。

检查 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(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 转移给矿工。

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

内存池规则

“内存池”是指以太坊节点内的一组内存数据结构，用于存储挖掘前的候选交易。 Geth 称之为“交易池”； Parity 称之为“交易队列”。 无论名称如何，它都是一个位于内存中等待包含在一个块中的交易池。 将其视为等待交易被接受到区块中的“等待区”。 “

目前，通过固定的交易有效性规则，矿工和其他节点可以以最小的努力验证其内存池中的交易，从而避免 DoS 攻击。 例如，如果一个矿工有一个有效的 ECDSA 签名，一个有效的随机数，并且有足够的账户余额，就可以确定一笔交易实际上会支付费用。 矿工内存池中的其他交易可能会使此待处理交易无效，前提是它们来自同一地址并且增加随机数或充分减少帐户余额。 这些条件在计算上是最小的，以允许矿工和节点对他们的内存池有足够的信心来分别执行块等待或重放。

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

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

操作码限制

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

节点应放弃针对内存池中账户抽象合约的账户抽象交易，并打破该操作码限制规则。 这确保了只要帐户抽象合约状态不变，内存池中有效的帐户抽象交易将保持有效。

字节码前缀限制

如果非账户抽象交易能够影响账户抽象合约的状态，就会影响内存池中账户抽象交易的有效性。 为了防止这种情况发生，账户抽象交易只允许在其字节码开头有 AA_PREFIX 的合约进行，其中 AA_PREFIX 实现了检查 msg.sender 是否是账户抽象交易的特殊 ENTRY_POINT 地址。 这有效地防止了非账户抽象交易与账户抽象合约的交互。

节点应将账户抽象​​交易抛给其字节码入口点中没有此 AA_PREFIX 的账户抽象合约。

加在账户抽象合约上的这两个限制共同确保了（1）账户抽象交易的有效性逻辑唯一可访问的状态是账户抽象合约内部的状态，以及（2）这个状态只能被其他人访问账户抽象合约的账户抽象交易修改。

因此，只有当同一个账户抽象合约有另一笔未决交易时，一个未完成的账户抽象交易才会失效。 然而，鉴于这些不是协议/共识的变化以太坊的两种账户，矿工可以自由地将违反这些规则的交易包含在区块中。

扩张

上述协议变更和内存池规则允许基本账户抽象合约完全安全地实现单租户应用程序，例如智能合约钱包。 其他需要放宽上述规则或需要实现多租户应用程序的高级用途需要帐户抽象以扩展的形式提供更多支持，例如。

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

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

RESERVE_GAS 操作码，当从非账户抽象交易中调用时，它会为寻求写入合约状态的账户抽象合约消耗的气体建立一个下限。 这样做是为了迫使攻击者不消耗最低数量的气体，以阻止试图使 mempool 中的任何帐户抽象交易无效的尝试。

还有其他一些，例如多个待处理交易、用于验证的缓存结果、用于验证的动态 gas 限制和赞助交易，这些都是支持多租户应用程序和 zk 证明所必需的，例如 Tornado Cash。 有关它们的详细信息超出了本文的范围。

工作的下一步

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

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

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

Status：Status 钱包目前是一个 EOA 钱包，它的不同之处在于捆绑了一个注重隐私的 SMS 系统，并支持聊天支付或增强 Keycard 安全性等集成。 正在考虑诸如多重签名和社交恢复等智能合约钱包功能，并且支持帐户抽象 EIP-2938 将有助于消除对中心化和低效的基于中继器的架构的依赖，如前所述。

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

总结

以太坊协议的一个基本方面是只有外部拥有的账户 (EOA) 才能支付汽油费并开始执行交易。 合同账户 (CA) 不能这样做。 账户抽象 (AA) 是一项改变这种区别的提议，允许专门构建的 CA 以编程方式检查新账户抽象交易的有效性，决定代表他们支付 gas 费用，从而有效地启动它们的执行而无需 EOA .

帐户抽象对于显着改善钱包、混合器、DApp 和 DeFi 等各种场景中的用户体验具有重要意义，而无需依赖集中且低效的基于中继器的架构。 通过引入新的交易类型、两个新的操作码和两个内存池规则，帐户抽象可以安全地支持基本的单租户场景，例如智能合约钱包。 高级多租户应用程序，例如 Tornado Cash以太坊的两种账户，需要对这些协议更改和节点规则进行扩展。

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

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