帐户抽象 (EIP-2938)：原因和内容

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

AA的动机在于显著改善用户与以太坊区块链的互动体验，涵盖了各种场景，如钱包、混币服务、去中心化应用（ÐApps）和 DeFi。AA为以太坊提供了一个基础层功能，用于决定何时可以支付 gas 费用，这也对谁支付 gas 以及如何支付 gas 产生了影响。

Status Messenger 应用捆绑了一个以隐私为中心的即时通讯应用，以太坊钱包和 Web3 ÐApp 浏览器。Status 钱包目前是一个外部拥有账户（EOA）钱包，这限制了我们提供的富有用户体验，只有智能合约钱包才能提供，如多重签名安全、社交恢复、速率限制、地址允许/拒绝列表和无 gas 的元交易。然而，智能合约钱包的用户体验今天受到波动的 gas 价格严重影响，这个问题并没有被第三方中继有效解决。AA旨在解决这个问题。

在本文中，我们阐述了在智能合约钱包背景下需要账户抽象的原因。然后，我们深入探讨了AA的主要方面，描述了协议的更改以及对节点的影响。最后，我们讨论了一些提议的扩展，并对与以太坊进行接口的 Status 项目的计划路线进行了合理化。因此，这些项目可能会受到AA的影响。

历史与动机

抽象账户最初是在2017年作为EIP-86提出的，旨在实现“交易发起方和签名的抽象化”，但这一激发思想的起源可以追溯到更早的2016年，当时有人建议：“与其在协议中设立一个机制，将ECDSA和默认nonce方案确立为唯一的“标准”保护账户的方式，不如采取初步步骤朝着一个模型迈进，在长期内所有账户都是合约，合约可以支付 gas，用户可以自由定义自己的安全模型。” 最初的提案被认为难以实现，因为需要进行许多协议更改，并满足安全保证。 最近，Vitalik等人提出了EIP-2938的草案，概述了一种更简单的实现方式，通过尽量保持协议/共识更改的最小化，并通过节点内存池规则强制执行所需的安全保证。Vitalik的以太坊工程团队见面会演示和ETHOnline演示（与其他EIP作者之一的Sam Wilson和Ansgar Dietrichs（附带的文章1和2一起）一起）为主题提供了很好的介绍。 本文从所有这些来源中着重介绍了最关键方面。

动机：AA背后的激发原理非常简单但是基本的：以太坊交易今天具有可编程效果（通过调用智能合约实现），但它们具有固定的有效性，即仅当交易具有有效的ECDSA签名、有效的nonce和足够的账户余额时才有效。AA通过引入一种新的AA交易类型，将交易从固定的有效性升级为可编程的有效性，该类型始终源自一个特殊地址，协议不需要对其进行签名、nonce或余额检查。 这种AA交易的有效性由目标智能合约确定，在此之后，它可以决定支付此类交易，并施加自己的有效性规则。

那么，为什么这有用呢？我们以以太坊钱包为例来着重介绍 AA 的好处。

智能合约钱包： 如今大多数以太坊钱包都是 EOA 钱包，它们受到种子短语生成的私钥的保护。（BIP-39 种子短语或助记词是从2048个单词的列表中随机选择的12-24个单词的有序列表。这提供了获得使用 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签名。

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

然而，基于中继器的架构存在三个主要缺点：（1）它们可能被视为具有潜在审查交易能力的中心化中介；（2）它们在技术上/经济上效率低下，因为中继器交易需要额外的基本Gas费用并且他们需要在Gas费用之上获取利润；（3）使用中继器特定协议迫使应用程序依赖于具有较小用户基础和不确定可用性保证的非基础层以太坊基础设施。

账户抽象将使智能合约钱包能够接受用户的无gas元交易并为其支付Gas费，而无需依赖中继器网络。因此，这种基础层功能将显著改善此类钱包的入门用户体验，而不会牺牲以太坊的去中心化保证。

Tornado Cash：一个相关的激励应用是tornado.cash等混币服务，@tornado.cash/introducing-private-transactions-on-ethereum-now-42ee915babe0">Tornado通过接受ETH存款并允许稍后由不同地址提取来改善交易隐私，从而打破了地址之间的链上关联。用户在存款时需要提供一个秘密的哈希，并在提取时提供zkSnark证明以显示对秘密的了解，而不会透露秘密或早期存款本身。这样就从提取中断开了存款。

但是提取存在一个鸡生蛋的问题。要从新生成的地址执行提现交易，用户需要在其中存放一些ETH以支付Gas费。这些ETH的来源（通常是交易所）可能会破坏Tornado的隐私。首选的替代方案是再次使用中继器网络，但这具有前面提到的缺点。

账户抽象将通过允许Tornado合约接受用户的提取AA交易、验证zkSnark、从早期存款金额中扣除一些gas费用，然后将剩余的存款金额转移到提取地址来解决此问题。

账户抽象

EIP-2938 中提出的账户抽象允许合约成为支付费用并开始交易执行的顶级账户。这是通过引入协议更改以及新的 AA 事务类型来实现的，该事务类型需要两个新的操作码：nonce和PAYGA、内存池规则和扩展的更改以支持高级用法。账户类型仍然是两种（EOA 和合约账户），所有提议的更改都向后兼容当前交易、智能合约和协议。

AA 的应用程序分为两类：1) 单租户应用程序，例如智能合约钱包，它为每个用户创建一个新合约；2) 多租户应用程序，例如tornado.cash 或 Uniswap，其中多个用户与 AA 进行交互同一套智能合约。

多租户应用程序的AA支持需要更多的研究，并将在未来进行。因此，在本文中，我们将专注于单租户AA支持。

协议变更

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

AA 交易：引入了一种新的 AA 交易类型 AA_TX_TYPE。其有效载荷被解释为 RLP([nonce, target, data])，而不是现有交易类型的有效载荷 RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s])。

AA 交易中省略的 gas_price 和 gas_limit 由目标 AA 合约在执行过程中指定。AA 交易中省略的 ECDSA 签名 v、r、s 被替换为对数据的特定合约验证检查。to 地址被目标合约地址替换。由于所有 AA 交易的发起地址都是一个特殊的 ENTRY_POINT 地址（0xFFFF…FFFF），而不是具有与之关联的值的 EOA，因此省略了值。

与现有交易类似，通过检查 tx.nonce == tx.target.nonce 来处理非重复 nonce 的 AA 交易。如果此检查失败，则将视交易为无效，否则会增加 tx.target.nonce 并继续执行交易。

建议将 AA 交易的基本 gas 成本设定为 15000，而不是当前的 21000（以反映缺乏内在 ECDSA 签名的成本节约）。此外，AA 交易没有固定的 gas 限制。在开始执行时，gas 限制被简单地设置为区块中剩余的 gas。

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

PAYGAS 操作码：PAYGAS 操作码（0x49）从栈中取出两个参数：（顶部）version_number、（次顶部）memory_start。version_number 允许将来的实现更改操作码的语义。当前，操作码具有以下语义：

1. 检查 version_number == 0（否则抛出异常）
2. 读取 gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. 读取 gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. 检查 contract.balance >= gas_price * gas_limit（否则抛出异常）
5. 检查 globals.transaction_fee_paid == False（否则抛出异常）
6. 检查 AA 执行帧 == 顶级帧，即如果当前的 EVM 执行退出或回滚，则整个交易的 EVM 执行终止（否则抛出异常）
7. 设置 contract.balance -= gas_price * gas_limit
8. 设置 globals.transaction_fee_paid = True
9. 设置 globals.gas_price = gas_price 和 globals.gas_limit = gas_limit
10. 设置当前执行上下文的 remaining_gas = gas_limit - 已经消耗的 gas

在 AA 交易执行结束时，将 (globals.gas_limit - remaining_gas) globals.gas_price 转移给矿工，而 AA 合约将被退还 remaining_gas globals.gas_price。

PAYGAS 充当 EVM 执行检查点。在此点之后的任何回滚都只会回滚到此处，然后合约将不会收到退款，而 globals.gas_limit * globals.gas_price 将转移到矿工处。

新的交易类型和两个新的操作码构成了协议/共识级别的更改，它们的语义相对简单，易于理解。

内存池规则

“内存池是指以太坊节点内部的一组内存数据结构，它在交易被挖掘之前存储候选交易。Geth 称之为“交易池”; Parity 称之为“交易队列”。不管名称如何，它都是一个存储在内存中等待被包含在区块中的交易的池子。可以将其想象成交易等待被接受到区块中的“等待区”。

目前，由于固定的交易有效性规则，矿工和其他节点在验证其内存池中的交易时需要的工作量很小，因此可以避免 DoS 攻击。例如，如果一个交易具有有效的 ECDSA 签名、有效的 nonce 并且具有足够的账户余额，矿工就可以确信该交易实际上会支付费用。该矿工内存池中的其他交易可能会使得待处理交易无效，只有当它们来自相同的地址时，并且要么增加 nonce，要么足够减少账户余额。这些条件在计算上是最小的，以便给矿工和节点足够的信心来考虑区块或重新广播。

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

因此，矿工和节点需要一个可预测的机制，以避免待处理的 AA 交易的有效性依赖于内存池中的其他待处理交易。如果没有，一笔交易的执行可能会使得内存池中的许多/全部 AA 交易无效，从而导致 DoS 攻击。为了避免这种情况，有两个建议在 AA 交易内存池中执行的规则（由矿工和节点执行，但不包括在协议本身中）：

操作码限制

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

预计节点会丢弃针对违反此操作码限制规则的 AA 合约的 AA 交易。这确保了内存池中的有效 AA 交易在 AA 合约状态不发生变化的情况下将保持有效。

字节码前缀限制

如果非-AA 交易可以影响 AA 合约的状态，则会影响内存池中 AA 交易的有效性。为了防止这种情况发生，AA 交易只能针对在其字节码开头具有 AA_PREFIX 的合约，其中 AA_PREFIX 实现了检查 msg.sender 是否为 AA 交易的特殊 ENTRY_POINT 地址的检查。这有效地防止了非-AA 交易与 AA 合约进行交互。

预计节点会丢弃针对没有在其字节码入口点具有 AA_PREFIX 的 AA 合约的 AA 交易。

对 AA 合约强制执行的这两个限制确保：（1）AA 交易的有效性逻辑所访问的唯一状态是 AA 合约内部的状态，（2）此状态只能由其他针对特定 AA 合约的 AA 交易修改。

因此，对 AA 合约的未执行 AA 交易可能仅通过包含针对同一 AA 合约的另一个 AA 交易的区块而无效。然而，鉴于这些不是协议/共识更改，矿工可以自由地在区块中包含违反这些规则的交易。

扩展

上述协议更改和内存池规则允许基本 AA 合约充分且安全地实现智能合约钱包等单租户应用。其他需要放宽上述规则或需要实现多租户应用程序的高级用法需要 AA 以扩展的形式提供更多支持，例如：

1. SET_INDESTRUCTIBLE 操作码，它禁用了 SELFDESTRUCT，并允许 AA 合约在验证阶段安全地调用带有 DELEGATECALL 的库。
2. IS_STATIC 操作码，如果当前上下文是静态的，则返回 true，并允许非-AA 交易调用者覆盖之前的字节码前缀限制，并安全地从 AA 合约中读取值。
3. RESERVE_GAS 操作码，当从寻求写入合约状态的非-AA 交易中调用 AA 合约时，它为 AA 合约消耗的 gas 设定了一个下限。这有助于迫使攻击者消耗最少的 gas 以阻止尝试使内存池中的任何 AA 交易失效。

还有其他一些，例如多个待处理的交易、缓存验证结果、验证的动态 Gas 限制和赞助交易，这些都是支持多租户应用程序和 zk 证明（如Tornado Cash）所必需的。本文将不做讨论。

下一步

账户抽象EIP-2938目前处于草案模式，并正在以太坊研究论坛中进行讨论。该EIP的下一步是考虑将其纳入即将到来的硬分叉之一。EIP的作者显然正在瞄准柏林之后的硬分叉（柏林的时间表目前尚不清楚，初步计划于2021年初）。因此，对于EIP-2938来说，该过程仍处于早期阶段。

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

“账户抽象的重要性略有下降，因为无论L1是否支持，都可以在L2上实现。” —— Vitalik 在他关于以太坊路线图的文章中提到的关于基础层仍然重要的事情。

状态：Status钱包目前是一个EOA钱包，通过捆绑隐私中心的消息传递程序以及启用集成，如在聊天中进行支付或使用Keycard提供增强安全性，它因此与众不同。智能合约钱包功能，如多重签名和社交恢复，正在考虑之中，EIP-2938支持将有助于通过消除对中心化和效率低下的基于中继的架构的依赖，如前文所述。

Status还在评估L2解决方案，旨在支持其钱包中的多个链，并为早期文章中描述的各种用例提供所需的扩展。例如，Keycard正在探索一个支付网络，其设计要求包括信用卡级别的可扩展性和几乎即时的终局性，这些要求目前以太坊网络无法满足。此外，还有许多其他计划，例如推荐计划、SNT反应、Tribute-to-Talk和ENS名称等，所有这些都将受益于L2可扩展性，以实现可行的部署和合理的用户体验。如果一个可行的L2解决方案实现了AA，那么在该L2上构建的项目将能够利用AA的好处，而无需依赖于L1。

结语

以太坊协议的一个基本方面是，只有外部拥有的账户（EOAs）可以支付Gas费用并开始交易执行。合约账户（CAs）不能做到这一点。账户抽象（AA）是一个提案，旨在改变这种区别，并允许特殊构建的CAs以编程方式检查新类型的AA交易的有效性，决定代表它们支付Gas费用，从而在不需要EOA的情况下有效地开始它们的执行。

AA对于大大改善用户体验具有重要意义，涵盖了各种情景，例如钱包、混合器、ÐApps和DeFi，而无需依赖于中心化和效率低下的基于中继的架构。通过引入新的交易类型、两个新的操作码和两个内存池规则，基本的单租户场景，例如智能合约钱包，可以安全地得到AA的支持。对于高级的多租户应用程序，例如Tornado Cash，需要对这些协议更改和节点规则进行扩展。

在本文中，我们从智能合约钱包的背景出发，激发了对AA的需求。我们通过描述协议更改和对节点的影响来突出AA的关键方面。我们提及了一些用于高级用途的拟议扩展，并最终通过将AA置于当前以太坊路线图和Status的优先事项的背景中加以定位。

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

声明：

1. 本文转载自【status】。原文标题为“Account Abstraction (EIP-2938): Why & What”。所有版权归原作者【Rajeev Gopalakrishna】所有。若对本次转载有异议，请联系【Gate Learn】团队，他们会及时处理。
2. 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
3. Gate Learn 团队将文章翻译成其他语言。除非另有说明，否则禁止复制、分发或抄袭本译文。