原文标题：引介|账户抽象化：为什么&做了什么
以太坊有两种类型的账户：外部账户和合约账户。前者由用户私钥控制，而后者由存储在智能合约账户内的合约代码控制。外部账户的权限要大于合约账户，因为只有外部账户可以通过支付gas启动交易的执行过程。账户抽象化则是一个可以让合约账户成为和外部账户一样的“顶层”账户的提案，实现了账户抽象化之后，合约账户也可以支付交易费和执行交易。
之所以提出账户抽象化，是想要在钱包、交易混淆器、DApp和DeFi等各种应用场景下，显著改善用户与以太坊链的交互体验。账户抽象化方案要为以太坊提供一个基础功能层，来确定何时支付，谁来支付以及怎样支付gas。
以StatusMessenger应用为例，其将隐私信使服务与以太坊钱包和Web3浏览器集成在一起。目前，Status钱包仍然是外部账户钱包，因此其不能像智能合约钱包那样支持丰富的用户体验，比如多签安全、基于社交的钱包恢复、支付限额、地址黑/白名单以及无需gas费用的元交易。智能合约钱包的用户体验受累于gas价格波动，即使通过第三方的中继者也无法有效解决这个问题。账户抽象化旨在解决这个问题。
在本文中，我们先探讨智能合约钱包对账户抽象化的需求。然后描述协议的变更及其对节点的影响，借此深入到账户抽象化的关键部分。最后，我们讨论一些关于扩展功能的提案，并以阐释Status项目的计划路线图作为本文的总结，因为该项目要与以太坊配合因而势必受到账户抽象化的影响。
历史与动机
账户抽象化这个概念是在撰写于2017年的EIP-86里首次提出的，其目的是实现“交易来源和签名的抽象”。不过其动机和想法可以追溯到2016年年初vitalik提交的一个issue，文中建议“与其将ECDSA签名算法和默认的nonce机制写死在协议内作为‘标准’的账户安全机制，不如初步建立一个账户模型，在未来把所有的账户都变成合约，让合约可以支付gas，让用户可以自由定义自己的安全模型。”
要实现最初的提议非常有挑战，因为不仅要大幅修改协议，还要满足系统的安全保证。最近，Vitalik等人提出了EIP-2938草案，该草案概述了一个更简单的实现。这个实现对协议/共识的改动最小，并且通过设置节点的内存池规则来满足所需的安全保证。Vitalik的以太坊工程组Meetup演讲和SamWilson与AnsgarDietrichs的ETH线上演讲都对这个主题做了非常棒的介绍。本文会着重介绍这些资料的关键内容。
Argent推出利用账户抽象的自托管智能钱包Web Wallet:8月4日消息，智能合约钱包Argent宣布推出利用账户抽象的自托管智能钱包Web Wallet，允许用户使用电子邮件地址创建网络钱包，无需下载，也无需助记词。[2023/8/4 16:18:40]
动机：账户抽象化背后的动机很简单，但会带来根本性的改变：当前，以太坊交易具备?功能可编程性，但是?交易的验证方式?却是固定的。只有持有有效的ECDSA签名、有效的nonce值以及足够的账户余额，一笔交易才算有效。账户抽象化引入了一种新的交易类型——抽象账户交易。这种交易总是由一个特殊地址产生，协议不会检查其签名，nonce和余额。通过引入这种交易，账户抽象化实现了从固定验证方式到可编程验证方式的转变。抽象账户交易的有效性由其target字段指定的智能合约验证，通过验证之后，合约可以自行为该交易支付手续费。
那么，为什么账户抽象化这么有用呢？我们将用以太坊钱包为例，阐述它会带来哪些好处。
智能合约钱包：如今大多数以太坊钱包都是外部账户钱包，它们的安全性由助记词生成的私钥保护。为了以后能在其他钱包里恢复密钥，用户应当安全妥善地保管助记词。然而，这种钱包很容易因为私钥被盗或者助记词丢失导致用户的资产遭受损失。
智能合约钱包是通过智能合约在链上实现的。这种钱包能够提供可编程的风险迁移和友好的用户体验，比如多签安全、基于社交或时间的钱包恢复、转账金额限制、地址黑白名单、无需gas费用的元交易和批量交易。
虽然智能合约面临因代码质量差而带来的安全风险，但是这种风险可以通过钱包提供方的安全审计来减轻。而外部账户钱包的风险完全由用户自己承担，用户无法获得智能合约那样的可编程的安全保障，用户必须自己保管好助记词。
当前可用的智能合约钱包有Argent、Authereum、Dapper、Dharma、GnosisSafe、Monolith和MYKEY。从下图可以看到，这类钱包的使用率看起来在增加。
Argent通过守护者的概念实现了无需种子的基于社交的钱包恢复。守护者是用户信任的人或设备，可以帮助用户恢复钱包。Argent还要实现类似银行的安全性与类似Venmo的可用性取代地址，支持元交易）。
GnosisSafe是一款多签智能合约钱包，专注于团队资金管理，任何一笔交易都要得到团队中最低人数的批准才能发生。它还可以通过元交易实现无需gas的签名。
Arbitrum已激活One和Nova上的账户抽象端点支持:8月2日消息，Offchain Labs已正式在Arbitrum One与Arbitrum Nova上激活对账户抽象端点的支持。
此前报道，7月17日，Arbitrum提案AIP-2已获得投票通过，将在 One 和 Nova 主网上激活对账户抽象端点的支持。该提案旨在解决ERC-4337打包交易的问题，新RPC端点eth_sendRawTransactionConditional 将允许用户在提交交易时指定有效的区块高度和时间戳范围，从而解决了在验证和执行阶段之间可能发生的智能合约账户存储变化的问题。[2023/8/2 16:13:47]
所有这些高级钱包功能都要用到灵活的智能合约。钱包用户要么通过外部账户发送交易，支付gas费以调用钱包合约，要么依赖钱包提供方支持元交易功能，借由钱包提供方的中继器或者第三方中继网络如GasStationNetwork来使用钱包。前者通常是通过了KYC认证的用户依靠中心化交易所购买ETH；后者将用户的负担转移到中继器上，由钱包提供方或用户在链上或链下补偿中继器，从而提高用户体验。
然而，基于中继器的架构有三个主要缺点：他们可能会面临中心化的诟病，引起交易审查的担忧；由于中继器发出的交易需要支付额外21000单位的基础gas费，为了获得利润其必须收取更高的费用以覆盖这部分成本，这就导致了技术和经济上的低效；对中继专用协议的使用，迫使应用不得不依赖非以太坊的基础设施，而较小的用户群无法支撑这些设施提供稳定可靠的服务。
账户抽象化将使智能合约能够接受用户的无需gas的元交易，并且无需依赖中继网络就能为其支付gas费。因此，这种底层能力在不牺牲去中心化的情况下，能够极大改善这些智能合约钱包的用户体验。
TornodoCash：另一个相关应用是交易混淆器，例如tornado.cash。Tornado使用智能合约切断地址之间的链上关联以提升交易的隐私性，该合约允许用户存入ETH后通过另一个地址提款。用户在存款时提供一个秘密值的哈希，随后在提款时提供zkSnark证明。该证明可以在不泄露秘密值和存款信息的情况下，证明其知道这个秘密值。这样就把存款和提款脱钩了。
但是在提款时有一个鸡生蛋蛋生鸡的问题。为了在新生成的地址上执行提款交易，用户需要给该地址存入一些ETH以支付gas费。但这些ETH的来源本身又会破坏使用Tornado所带来的隐私性。首选的替代方案是再次使用中继网络，而这样做有上述的那些缺点。
Vitalik Buterin：账户抽象升级可以吸引数十亿人使用以太坊:7月20日消息，以太坊创始人Vitalik Buterin最近在以太坊社区会议（EthCC）演讲中详细介绍账户抽象升级“paymasters”如何让用户用用于交易的代币支付Gas费，从而吸引数十亿人使用以太坊。账户抽象使用户能够从外部拥有的钱包（EOA）切换到基于智能合约的钱包。如果此次升级成功，钱包管理将比现在更加高效和轻松。Vitalik Buterin和社区相信，这可以使加密货币得到广泛采用。
此外，加密货币领域充斥着丢失助记词或助记词被盗的用户。通过账户抽象，用户可以创建充当可编程智能合约的非托管钱包。钱包恢复只是此次新升级带来的众多功能之一。[2023/7/20 11:06:21]
账户抽象化就可以解决这个问题，Tornado合约可以接受用户的提款抽象账户交易，验证zkSnark，扣除gas费，然后把剩余的资金转给提款地址。
账户抽象化
在EIP-2938中提出的账户抽象化，接纳合约作为顶层账户，使之可以支付交易费以及启动交易的执行过程。实现账户抽象化需要变更协议以增加新的抽象账户交易类型、修改内存池规则以及引入扩展功能以支持高级用法。抽象账户交易需要增加两个新的操作码：NONCE?和?PAYGAS。账户类型仍然保持现有的两种，所有的变更都向后兼容以支持当前的交易、智能合约和协议。
账户抽象化应用可以分成两类：1)单租户应用，如智能合约钱包，其会为每个用户创建一个新合约；2)多租户应用，例如tornado.cash或Uniswap，多个用户与同一组智能合约交互。
目前还不能支持多租户应用，这需要更多的研究工作，以期未来早日实现。所以本文将重点介绍单租户的账户抽象化。
协议变更
对协议唯一的变更就是引入了一种新的交易类型，以及相关的两个操作码?NONCE?和?PAYGAS。
抽象账户交易：协议引入了一种新的交易类型：AA_TX_TYPE。它的二进制数据(payload)会被解析为?RLP()?，而不是现有交易的?
RLP()?。
Nonce检查和现有交易类似，需满足
?tx.nonce==tx.target.nonce。
Harmony将在第二季度实现账户抽象功能:2月19日消息，Harmony宣布将在2023年第二季度实现账户抽象，为用户和开发者提供更大的灵活性和功能。帐户抽象是一种允许创建多种类型帐户的功能，每种帐户都具有独特的功能和特性。[2023/2/19 12:15:35]
如果检查失败，则交易无效，如果通过检查，则?tx.target.nonce?将会递增，交易继续进行。
抽象账户交易的基础gas消耗量将从21000降到15000。此外，抽象账户交易没有内置的gas限额。当交易执行时，gas限额只需设定为当前block还剩余的gas限额即可。
NONCEopcode：NONCE?操作码(0x48)推送被调用者——即抽象账户交易的target字段所指定的合约——的nonce值到EVM的栈上。借此，nonce值被暴露给了EVM，因而抽象账户合约可以将交易的任何字段作为验签逻辑的一部分。
PAYGASopcode：PAYGAS?操作码(0x49)从栈上弹出2个参数：version_number，memory_start。
Version_number?允许未来通过新的实现变更操作码的语义。目前，操作码的语义如下：
检查?version_number==0
读取?gas_price=bytes_to_int(vm.memory)
读取?gas_limit=bytes_to_int(vm.memory)
检查?contract.balance>=gas_price*gas_limit
检查?globals.transaction_fee_paid==False
检查?AAexecutionframe==top-levelframe，也就是若当前EVM执行退出或回退，整个交易的EVM执行就暂停了
设置?contract.balance-=gas_price*gas_limit
设置?globals.transaction_fee_paid=True
设置?globals.gas_price=gas_price，globals.gas_limit=gas_limit
VitalikButerin等人发布Ethereum“账户抽象”提案ERC4337:9月29日，Ethereum创始人Vitalik Buterin联合KristofGazso、yoav.eth、DrorTirosh、NamraPatel、TomaszK.Stanczak等人发布账户抽象提案ERC4337，可在不改变以太坊共识层协议的情况下实现验证逻辑，该提案的开发者内测版本将于近期上线。
注：“账户抽象”是以太坊社区中讨论的改进提案之一，以实现交易不需要从私钥控制的EOA账户发起，而是可以直接从智能合约发起，具体的用例包括智能合约钱包、Tornado.Cash这类隐私保护工具等。[2021/9/29 17:15:22]
设置当前的执行上下文的?remaining_gas=gas_limit-已经消耗的gas
在执行抽象账户交易的最后，(globals.limit-remaining_gas)*globals.gas_price?的费用将转给矿工，remaining_gas*globals.gas_price?的金额则退还给抽象账户合约。
PAYGAS?操作码充当EVM执行过程中的检查点。任何回退都只退回到上一个检查点，此时合约收不到退款，globals.gas_limit*globals.gas_price?的金额全都转给矿工。
这个新的交易类型和这两种新的操作码构成了协议/共识级别的全部变更，它们的语义相对直观，易于理解。
内存池规则
“内存池是指以太坊节点内部的，存储在内存里的数据结构，其中存储了用于挖矿的候选交易。Geth称之为‘交易池’；Parity称之为‘交易队列’。不管叫什么，它都是一个存储将被区块包含的交易的数据池。我们可以把它看做是待打包区块的“候车厅”。
抽象账户交易的可编程验证方式引入了更多的复杂性。抽象账户交易并不预付gas费，而是依靠?target?字段指定的抽象账户合约来支付gas费。理论上，抽象账户交易的处理分两个阶段：较短的验证阶段和较长的执行阶段。如果验证阶段失败，会导致交易无效，该交易便不会被区块包含，因而矿工也就拿不到交易费了
因此，矿工和节点需要一个可预测的机制，以避免待处理的抽象账户交易的有效性依赖内存池中的其他待处理交易。否则，一笔交易执行失败可能会导致许多甚至全部的抽象账户交易无效，以此可以构造出拒绝服务攻击。为了避免这种情况发生，我们建议内存池对抽象账户交易执行两条规则。
操作码限制
为了防止抽象账户交易的有效性取决于抽象账户合约以外的任何状态，在验证阶段以下操作码被视为无效：执行环境操作码
、
BALANCE、除了对?target?合约或预编译合约之外的任何外部调用/创建操作码
、
对除了?target?合约之外的任何外部状态的读取操作码
。
如果有抽象账户交易的target字段所指向的抽象账户合约违反了这个操作码限制规则，节点就要丢弃这个交易。如此，只要抽象合约的状态不发生变化，内存池中有效的抽象账户交易就将继续有效。
字节码前缀限制
如果非抽象账户交易可以影响抽象账户合约的状态，那么其就可以影响内存池中的抽象账户交易的有效性。为了防止这种情况发生，抽象账户交易应当只接受字节码前缀为?AA_PREFIX?的target合约。AA_PREFIX?实现了对?msg.sender?的检查，确保其是特殊的?ENTRY_POINT?地址。这有效地防止了非抽象账户交易与抽象账户交易发生交互。
节点如果检查到抽象账户交易指定的合约没有这个?AA_PREFIX?作为字节码前缀，就应该删除这笔交易。
这两条对抽象账户合约的限制确保了：只有抽象账户合约的内部状态可以影响抽象账户交易的验证逻辑；只有以同一个抽象账户合约为target的抽象账户交易可以修改该合约的状态。
因此，只有区块包含了以同一个抽象账户合约为target的另一笔抽象账户交易，才有可能使一个待处理的抽象账户交易无效。不过，鉴于这不是协议/共识层的变更，矿工在打包交易时可以随意违反这些规则。
扩展
上述协议变更和内存池规则足以安全地实现诸如智能合约钱包这样的单租户应用。其他高级用法则需要放宽上述规则或者需要实现多租户应用，这就要账户抽象化支持以下形式的扩展：
SET_INDESTRUCTIBLE?操作码，它会禁用?SELFDESTRUCT，并允许抽象账户合约在验证阶段通过?DELEGATECALL?安全地调用库函数。
S_STATIC?操作码，如果当前的上下文是静态的则返回true，并允许非抽象账户交易的调用者绕过之前的字节码前缀限制，安全地从抽象账户合约里读取数据。
RESERVE_GAS?操作码，当一笔非抽象账户交易试图对一个抽象账户合约写入状态时，设置一个gas消耗的下限。这样做是为了强制攻击者在试图让内存池的抽象账户交易无效时至少要消耗一定的gas，以此抑制其攻击动机。
还有一些其他的扩展，例如存储多笔待处理交易、缓存验证结果、验证过程的动态gas限制和担保交易等，这些都是为了支持多租户应用和零知识证明。这些内容不在本文的讨论范围内。
下一步
目前，关于账户抽象化的EIP-2938还只是一个草案，正在以太坊研究论坛中讨论。下一步是考虑将这个EIP纳入即将到来的硬分叉中。EIP的作者显然瞄着Berlin之后的硬分叉，具体的时间表还不确定。所以，对于EIP-2938来说，现在还处于早期阶段。
此外，也不清楚是否有必要在以太坊的Layer1(L1)加入EIP-2938。鉴于Layer2(L2)方案的灵活性，我们也可以在特定的L2上实现账户抽象化，这样就不需要升级整个L1了。不过，在L1上统一支持账户抽象化要比在不同的L2上各自实现账户抽象化好。因此，在哪里实现，怎样实现账户抽象化还有待观察。
“账户抽象化在某种程度上不那么重要，因为无论L1是否支持，它都可以在L2上实现。”——Vitalik在谈及基础层的升级需求时表达了这个观点。
Status：Status钱包目前是一个外部账户钱包，它的独门绝技是将聊天支付和Keycard集成到一个隐私信使服务中。目前其正在考虑加入一些智能合约钱包的特性，如多签和基于社交的钱包恢复。如前所述，支持EIP-2938有助于消除对中心化和低效的中继架构的依赖。
Status也在评估L2解决方案，正如我们之前的文章里说的，这样做既可以在钱包里支持多链，也可以为多种用例提供所需要的扩展。例如，Keycard正在探索一种支付网络，其所需的信用卡级别的可扩展性和近乎即时的终局性是目前以太坊网络无法满足的。此外，还有许多其他计划，如推荐计划、SNTreaction、Tribute-to-Talk和ENS域名。所有这些计划都适合在L2上实现，因为这在部署上可行，而且能够提供还不错的用户体验。如果一个可行的L2方案实现了账户抽象化，那么在该L2上的项目都能享受账户抽象化的好处，而不必依赖L1。
总结
以太坊协议的一个根本问题是，只有外部账户（EOS（可以支付gas费和启动交易执行过程，而合约账户（CA（做不到。账户抽象化（AA（是一个旨在改变这种区别的提案，允许具有特定构造的合约账户可以检查新增的一类交易——抽象账户交易的有效性，并代为支付gas费，从而在不需要外部账户的前提下有效地启动交易的执行过程。
账户抽象化能够在不依赖中心化和低效的中继架构的情况下，显著改善钱包、交易混淆器、DApps和DeFi的用户体验。通过引入一种新的交易类型，两种操作码以及两条内存池规则，账户抽象化能够安全地支持基本的单租户场景，如智能合约钱包。如果要支持更高级的多租户应用，如TornodoCash，则需要对协议和节点规则做更多的扩展。
本文阐述了智能合约钱包对账户抽象化的需求。通过描述协议的变更和对节点的影响来强调账户抽象化的关键部分。我们还谈到了一些针对高级用法的扩展提案，最后通过介绍Status项目在以太坊上的路线图和优先级让读者对账户抽象化有一个比较清楚的定位。
减少Web3的摩擦及改善用户体验是这个生态里所有项目的首要任务。账户抽象化，最终一定会以某种形式在未来发挥重要的作用。
感谢HesterBruikman审阅本文草稿并提供有益的反馈。感谢AlexHowell提供贴心的插图。
原文链接:
https://our.status.im/account-abstraction-eip-2938/
作者:?RajeevGopalakrishna
翻译&校对:?戡乱&阿剑
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。