深度：vitalik的eip-2938会给以太坊带来哪些改变？

以太坊中有两种类型的账户。 外部自有账户 (EOA) 和合约账户 (CA)。

以太坊中有两种类型的账户。 外部自有账户 (EOA) 和合约账户 (CA)。 EOA 由私钥控制，CA 由其中包含的智能合约代码控制。 EOA总是比Ca更有特权，因为只有EOA才能通过支付gas发起交易执行。 账户抽象 (AA) 是一项允许合约成为“顶级”账户的提议，它与 EOA 一样，可以支付费用并开始执行交易。

账户抽象的动机是为了显着提高用户在钱包、dapps、DeFi 等各种场景下与以太坊交互时的体验。 账户抽象在以太坊中提供了一个基本的层函数，用于决定何时向谁支付 gas。

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

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

历史和动机

账户提取于 2017 年作为 eip-86 首次提出，以启用“交易来源和签名摘要”，但这个想法的起源可以追溯到 2016 年。当时有人建议“而不是采用 ECDSA 的协议内机制而默认的nonce scheme作为保证账户安全的唯一“标准”方式，还是先一步建立模型为好。 从长远来看，所有账户都是合约，合约可以支付 GAS FEE，用户可以自由定义自己的安全模型。”

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

动机

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

为什么这行得通？ 让我们以以太坊钱包为例来强调账户抽象的好处。

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

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

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

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

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

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

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

然而，基于转发器的架构具有三个主要缺点：（1）它们可能被视为中心化中介并可能审查交易； 企业需要在使用 GAS FEE 之外获利，它们在技术/经济上效率低下 (3) 使用 relay-only 协议迫使应用程序依赖非基础层以太坊基础设施，该基础设施具有较小的用户群和不确定的可用性保证。

提现将使智能合约钱包在不依赖中继层网络的情况下接受用户的无gas交易并支付GAS FEE。 因此，这种草根能力将极大地改善此类钱包的用户体验，而不会牺牲以太坊的去中心化保护。

Tornado cash：一个相关的激励应用是混币器，例如 Tornado Cash Tornado 通过使用智能合约断开地址之间的链接来提高交易隐私。 该合约接受以太坊存款，可以通过不同的地址提取。 用户在存款时需要提供该秘密的哈希值，然后提供证明他们对秘密的理解的 zksnark 证明，而无需透露秘密或先前的存款本身。 这样，取款和存款就脱钩了。

但是以太坊的两种账户，从用户的 gas 中提取现金以从新交易中提取现金存在问题。 这个 ETH 的来源（通常是交易所）会破坏龙卷风的隐私。 首选的替代方案是重用中继器网络，但它具有前面概述的缺点。

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

帐户抽象

eip-2938 中提出的账户抽象允许合约成为支付费用和发起交易的顶级账户。 这是通过引入协议更改来实现的。 新的账户抽象交易类需要两个新的操作码：nonce 和 paygas，这将改变 MemPool 的规则并支持高级使用的扩展。 仍然有两类账户（EOA 和合约账户），所有提议的更改都向后兼容当前的交易、智能合约和协议。

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

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

变更协议

引入了一个新的交易类和两个支持 nonce 和 paygas 的操作码。 这些是对协议的唯一更改。

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

账户抽象交易中的遗漏 gas-price 和 gas-limit 由目标账户抽象合约在执行时指定。 账户抽象交易中省略的ECDSA签名V,R,s被具体合约的数据校验校验代替。 Target Contract Address 替换为 Target Contract Address。 这个值被忽略是因为所有账户抽象交易的起始地址是一个特殊的入口，与ffffffff关联的地址，而不是PointF的值。

如果检查失败，则交易被视为无效； 否则，tx.target.noncesent.target.nonce 将递增，交易将继续。

账户汇总交易的基本 gas 成本建议为 15000 而不是 21000（以反映由于缺乏内部 ECDSA 签名而节省的成本）。 此外，账户抽象交易没有气体限制。 在执行开始时，gas limit 简单地设置为该组的剩余 gas。

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

Paygas 操作码：Paygas 操作码 (0x49) 从堆栈中获取两个参数：（顶部）版本号（顶部第二个）内存引导。 版本号允许未来的实现改变操作码的语义。 目前，操作码的语义如下。

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

提取 gas 价格 = bytes 虚拟内存[ram_start:ram_start+32])

提取气体限制=字节虚拟内存[ram_start+32:ram_start+64])

查看合约余额gt; = gas price * gas price limit（否则抛出异常）

勾选全局事务处理fee_upay==false（否则抛异常）

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

设置合约余额 -= gas price * gas price limit。

设置已支付的全球交易费用 = TRUE

设置 glob_price = gasprice 和 glob_limit = gas_limit

为当前执行上下文设置 remaining gas=gas 以限制消耗的 gas。

执行抽象交易（global gas limit - remaining gas）*global gas price 在账户结束时给矿工，账户的抽象合约返回剩余gas *global gas price

Paygas 充当 EVM 执行的检查点。 之后的任何修复只会在这里恢复，合同上不接受退款，并且 GAS 限制*矿工的 GAS 价格。

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

内存池规则

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

目前，通过固定的交易有效性规则，矿工和其他节点可以以最小的努力验证其 MemPool 中的交易，避免 DoS 攻击。 例如，如果矿工拥有有效的 ECDSA 签名、有效的 nonce 和足够的账户余额，则可以确定交易会实际支付。 矿工 MemPool 中的其他交易只有在源自同一地址并且增加随机数或充分减少帐户余额的情况下才能使待处理交易无效。 这些条件在计算上是最小的，因此矿工和节点对他们的内存池有足够的信心分别等待或重播块。

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

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

操作码限制

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

节点需要放弃MemPool中针对account Abstract合约的account Abstract交易，打破此opcode限制规则。 这确保只要帐户抽象合约的状态不变，MemPool 中活跃的帐户抽象交易将保持有效。

字节码前缀限制

如果非账户抽象交易能够影响账户抽象合约的状态，就会影响MemPool中账户抽象交易的有效性。 为了防止这种情况发生，账户抽象交易应该只允许那些在合约开头有 AA 的用户使用字节码前缀，其中 AA 前缀实现消息发送者是账户抽象交易的特殊入口，即检查点地址。 这有效地防止了非账户抽象交易与账户抽象合约之间的交互。

节点应在其字节码入口点将帐户抽象事务作为前缀抛给 AA。

抽象账户合约的两个限制性保证： (1) 账户抽象交易的有效性逻辑唯一可访问的状态是账户抽象合约的内部状态； (2) 该状态只能被其他账户抽象为该特定账户抽象合约交易修改。

因此，只有在同一账户抽象合约存在另一笔未决交易的情况下，一笔未完成的账户抽象交易才无效。 然而，鉴于这些不是协议/共识的变化，矿工可以自由地将违反这些规则的交易包含到区块中。

延长

上述协议变更和 MemPool 规则使得基础账户抽象合约能够全面安全地实现智能合约钱包等单租户应用。 对于其他需要放宽上述规则或实现多租户应用程序高级使用的人，帐户抽象需要以扩展的形式提供更多支持，例如。

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

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

当从非账户抽象交易调用 RESERVE_Ugas 操作码时，它会建立一个 gas floor 供账户抽象合约消耗，该合约将写入合约状态。 这样做的目的是迫使攻击者不花费最少的 gas 来阻止使 MemPool 中的任何帐户抽象交易无效的尝试。

还有一些其他交易，如多个待处理交易、验证缓存结果、验证动态 gas 限制和支持多租户应用程序和 ZK 证明（如龙卷风现金）所需的赞助交易。 有关它们的详细信息超出了本文的范围。

下一步

帐户摘要 eip-2938 目前处于草案模式，正在以太坊研究论坛上进行讨论。 EIP 的下一步是考虑将其包含在即将到来的“硬分叉”中。 EIP 作者显然瞄准了柏林之后的硬分叉（柏林暂定在 2021 年初的某个时间），具体时间表尚不清楚。 所以对于 eip-2938 来说还为时过早。

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

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

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

Status 还在评估 L2 解决方案以支持钱包中的多个链，并为各种用例提供​​必要的扩展，如我们在之前的帖子中所述。 例如，keycard 正在探索一种支付网络以太坊的两种账户，其对信用卡级可扩展性和近乎即时终结性的设计要求超越了当前的以太坊网络。 此外，还有许多其他场景，例如推荐器、distribution to talk 和 ENS 名称，所有这些都将受益于 L2 可扩展性，以实现可行的部署和合理的用户体验。 如果一个可行的二级解决方案实现了账户抽象，那么建立在二级之上的项目将能够在不依赖 L1 的情况下利用账户抽象。

总结

aogas（a601s）执行账户只有一侧用于支付外部交易费用。 合同账户 (CA) 不能这样做。 账户抽象 (AA) 是一项改变这种区别的提议，允许专门构建的 CA 以编程方式检查新账户抽象交易的有效性并决定代表他们支付 GAS 费，在没有 EOA 的情况下有效地支付开始执行。

账户抽象可以显着改善钱包、混币器、dapps 和 DeFi 等各种场景的用户体验，而无需依赖中心化和低效的基于中继的架构。 通过引入一个新的交易类、两个新的操作码和两个 MemPool 规则，可以安全地支持智能合约钱包等基本的单租户场景。 高级多租户应用程序，例如 Tornado Cash，需要扩展这些协议更改和节点规则。

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

在 Web3 中减少摩擦并改善用户体验是该生态系统中所有项目的首要任务。 在某种形式下，账户抽象一定会在以后的工作中发挥重要作用。