以太坊有两种类型的账户。外部自有账户（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 Buterin 等人提出了 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 中减少摩擦和改善用户体验是这个生态系统中所有项目的首要任务。以某种形式，账户抽象可能肯定会在未来的努力中发挥重要作用。
转自：加密谷
