# 账户抽象的基础认知（What、Why、How？） By [加密卷心菜.eth](https://paragraph.com/@eth-18) · 2022-07-18 --- 怎样理解账户抽象？ ========= 账户抽象（Account Abstraction，简称AA）是以太坊上的一种待实现的技术方案。也可以简单理解为建立合约账户，让账户像具有像合约一样的，具备可编译、可升级的能力，能不仅执行交易，还能拓展各种用户自定义的计算逻辑。之所以赋予“抽象”一词，就在于能为账户创造巨大的自定义空间。 > _账户一词，类比于传统互联网中，最基础的就是具备交易功能和存储有账户余额Balance信息。web 3.0中也是一样，账户简单来说就是能执行交易和存储状态信息（State）的。_ > > _在以太坊中，现行有两种类型的账户，一类是外部账户（EOAs，Externally Owned Accounts），一类是合约账户（Contracts Accounts）。一般常说的账户更多的是指EOA。EOA存储的是账户Balance，合约存储的是合约中内容和Balance。_ 当前，在以太坊生态中，这种账户“抽象”的能力，是相较于以太坊现行账户“具象”规则而言的。 一是，以太坊合约账户虽然也可以接收和发送Ether，但合约账户只能被EOA调用激活、执行、或在执行过程中调用其他合约的公共函数。因为，过程中所消耗的Gas是需要通过 EOA 中的eth进行支付。二是，账户要完成交易执行，核心是包含授权签名和验证签名两大部分。当前，以太坊的签名机制是依赖于ECDSA 算法签名。三是，每个外部账户（私钥控制的账户）都有一个Nonce值，每一个账户从同一个节点发起交易时从0开始连续累加，每累加一次，代表完成一笔交易。当前面的Nonce处理完成之后才会处理后面的Nonce。 > _ECDSA 算法签名，通俗理解：账户所有人凭借私钥G，经魔法数学公式可得数字签名，包含两部分R和S；验签者，可以凭借公开的公钥（hash后即以太坊0x账户地址）和签名的一部分S，经魔法数学公式得到签名的另一部分E；如果两边E一致，则说明这个签名真的是账户所有人发出的，且签名数据没有被篡改，即验签通过。仅仅知道公钥是无法知道私钥或者创建出数字签名。_ [https://zhuanlan.zhihu.com/p/97953640](https://zhuanlan.zhihu.com/p/97953640) 由上可以看到，目前以太坊账户现行的“具象”在于固定的规则，如一笔交易只能由EOA发起，以及只有一个特定的原生验签方式：ECDSA算法。而账户抽象就是要突破这个局限性。有多样、自定义的交易授权逻辑。 为什么账户抽象一直被开发者心心念念，具有很大想象空间？ =========================== 作为以太坊乃至整个加密生态的入口，和账户最紧密相关的Dapp，就是钱包产品。而钱包产品，也是加密世界的最重要的基础设施，账户交易、转账、质押等都需要持有钱包。钱包的作用是保管私钥，帮助钱包所有者，进行签名授权交易并广播到区块链上。目前，最广泛使用的web3.0钱包如Metamask，就是以太坊EOA账户钱包。 对于EOA钱包使用者或账户所有人，必须牢牢掌握记住助记词/私钥，因为私钥遗失账户就永远无法找回。此外，关于钱包费用方面，用户还需要理解较为复杂的费用逻辑，如gas price、gas limit、自定义 Nounce、原生代币支付gas等，诸如此类，这些都是现有钱包给到普通用户进入的天然门槛。因此，区块链钱包应用一直是在不断地试图通过产品优化提高用户体验。 > _Nonce自定义下的加速操作：当有一笔处于pending状态的交易，新的一笔交易与其拥有相同的Nonce值，如果新交易的gas price太小，则无法覆盖pending状态的交易，如果新交易的gas price高于原交易的110%，则原交易会被覆盖掉。也就是说，如果发起一笔交易，但是因为gwei比较低或者网络比较忙的时候，该交易还没上链，那么想要加速，可以通过设置相同的Nonce和较高的gas费用，从而“覆盖”这一笔交易。_ 账户抽象和智能合约钱包 ----------- 伴随着钱包产品创新突破的，在传统EOA钱包另一面的，是智能合约钱包的应用崛起。智能合约钱包，如多重签名钱包（Gnosis）、社交恢复钱包（Argent），隐私支付钱包（BlockWallet）等，基于不同的用户需求角度，衍生出了多种功能特征。 * **账户恢复** 相较传统助记词钱包，该类钱包电子邮件或生物信息验证用户身份后协助用户恢复帐户，或者是“守护者Guardians”（通常为钱包持有人其他设备、家人或朋友等，合作更改签名密钥）。而这种基于社会关系的钱包恢复，和当下的DeSoc和灵魂绑定概念也是不谋而合的，某种程度上具有灵魂/身份钱包的意义。因为如果一个钱包一旦遗失永远无法找回，则永远无法承载Soul或个人身份了。每个人身份应该是固定的，不应该丢了私钥或私钥泄露就要换个钱包，换个身份。此外，账户恢复之上，还应包括有守护者更换，或是遭受遗失时候实现资产冻结保护功能。 * **多重签名** 签名意味着资产授权，实现多对一的管理。相较于单签（一个私钥控制一个钱包），多签功能在于需要凭借多个私钥控制一个钱包，如2/3多签，3个中有2个同意签名，资金才可使用。这种多签往往更适用于企业、机构等资产的联合授权管理上，资金使用是进行多数投票表决，避免资金的滥用。对于个人，也可以添加多个私钥来提高账户的安全性。 * **灵活支付** 在传统EOA钱包中，最僵化的支付场景提现在，如果有人转了一笔钱给你，而你想再交易，这个是必须有原生代币ETH作为Gas支付的，如果钱包已有资产非原生，则要通过其他迂回方式去想办法先获取原生代币，继而再交易。而费用灵活支付，就在于能突破这一限制，实现No Gas。但需要注意的，这里本质不是No Pay, 而是可以让用户选择费用支付途径、支付币种、第三方代付、会员制阶梯支付等，从而拓展设计灵活的费用模型。 * **隐私支付** 链上加密货币交易的透明性对于传统世界来说是一个优势，但也有一个问题就是，缺乏隐私。而资产安全的另一面，就是隐私保护。一些钱包尝试叠加混币器的中转功能，在链上很难实现资产交易记录的追踪，无法得知资金的流入流出配对关系，从而实现了钱包资产的隐私保护。 * **权限/白名单等管理** 借鉴传统互联网金融/银行账户的账户特征，或者是一些中心化交易所账户特征，会发展有转账额度管理、转账对象及有限白名单管理等附加功能，提供更多元、更像传统世界的账户服务。 * **交易策略级管理** 集成DeFi，不关局限于简单的信息聚合，还包括针对不同的DeFi产品进行主动监听，设置不同的预定触发和交易执行逻辑。例如监听外部Vault的抵押率，做好安全预警。在MEV方面，也可以尝试与套利交易平台的深度结合，提高套利操作效率。 不同智能钱包功能的衍生，都是在探索和事件在“ 寻求更强的安全及隐私保护、更便捷的交易体验、更多元的交易策略 ”三方面的潜在用户需求。这种打造类似web2.0级各种各样的多功能策略和极致管理体验的钱包产品，则必须以合约钱包的形式。 然而，当前各种智能合约钱包产品，受限于已有的以太坊账户体系，更像是带着镣铐跳舞。由于交易需要EOA发起，一般会采用“元交易”（Meta-Transaction）的方式，用户签名完成之后，交由钱包的 Relayer 发交易信息上链，并由其代为支付矿工费，包括一些隐私支付功能的钱包或混币器，也需要提款时候由中继器角色进行Gas的支付。这带来了中心化的节点运营安全问题。另外，智能合约钱包账户的创建，需要部署合约，会存在一定开户费用（代理代付费用），转账或其他调用合约的策略操作都会产生较传统EOA账户更高的事务费用，这都影响了智能合约钱包用户的当前使用体验。 正是因为诸如此类的“安全”“费用”相关的bug，关于从协议层底层突破发展账户抽象，提升合约账户的权限及地位的声音，一直存在。更有观点认为，类比于web2.0的互联网的发展轨迹，web3.0时代的操作系统极大可能从智能合约账户中演变而来（如微信账户及微信&小程序生态），有核心的通用协议标准，有生态工具&模块，有抽象即无限想象空间的下一代windows系统。 V神“The road to account abstraction” =================================== 围绕账户抽象相关的以太坊协议标准方案近几年一直不断被提议倡导，但又不断被搁置，如已停滞的2020年的EIP-2938。2022年，在上海以太坊峰会上V神，在The merge和Dank Sharding之外又一次提及到了账户抽象，并倡导运用最新的ERC 4337来尽快实践落地。 > _ERC-4337(2022年)：目前最新的帐户抽象标准方案。非 EIP，它是 ERC，完全避免共识层协议更改，因此被认为当前短期内落地性最强的账户抽象标准方案，可直接用于Dapp开发。该提案没有添加新的协议特性和更改底层事务类型，而是引入了一个更高层的伪事务对象，称为“UserOperation”。用户将“UserOperation”对象发送到单独的内存池中。称为Bounder的参与者（矿工或通过Flashbots之类的捆绑市场向矿工发送交易的用户）将一组这些对象打包成一个交易，并对一个特殊的合约进行“handleOps”调用，然后该交易进一步打包出块。_ > > _EIP-2938（2020年）：目标是将允许合约成为能支付费用且能自行执行交易的顶级账户。将账户划分为单租户AA和多租户AA，以此支持多签钱包、智能钱包、Tornado等业务场景。_ [https://notes.ethereum.org/@vbuterin/account\_abstraction\_roadmap#The-road-to-account-abstraction](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#The-road-to-account-abstraction) [https://eips.ethereum.org/EIPS/eip-2938](https://eips.ethereum.org/EIPS/eip-2938) [https://github.com/ethereum/EIPs/pull/4337](https://github.com/ethereum/EIPs/pull/4337) [https://github.com/ethereum/EIPs/pull/4337/files#diff-a28c1bf623090bfefa32545f2feacbfce1002c34298f89602439fb77ca73529c](https://github.com/ethereum/EIPs/pull/4337/files#diff-a28c1bf623090bfefa32545f2feacbfce1002c34298f89602439fb77ca73529c) 在The road to account abstraction一文中，V神给出了关于账户抽象实施的短期-中期-长期的路线图。总体来说，即短期以尽快推动实践为首要目标，以最小的改造以太坊网络生态成本为先，同时可尝试从对Gas问题敏感性较弱的二层Rollups入手。中期乃至长期，才是攻克太坊共识层面相关的棘手性问题，如额外Gas优化及CrList问题、全部EOA账户强制转化等。 另外，值得注意的是，在“历史包袱”较少的以太坊二层网络，目前已开始在探索内置账户抽象这一路线。最新的zksync 2.0 测试网，是将支持部署账户抽象，创建了一个aa-signature-checker，尽管目前仅支持ECDSA算法签名，但未来会添加对EIP-1271 的支持。 最新的StarkNet主网，从一开始上线就没有像以太坊的外部账户EOA，原生设计的每个账户地址都是合约账户，以此可以定义账户逻辑。StarkNet并没有内置特定的签名方案，目前仍是可以借助ECDSA算法签名来实现。ArgentX和Braavos作为其二层浏览器扩展钱包，现阶段的方式都仍然是通过私钥-公钥签名机制和助记词进行钱包恢复的。尽管目前二层智能合约钱包发展处于早期，但伴随着二层网络生态和账户抽象的进一步迭代，后来居上的二层钱包开发也会有更多的功能尝试。 > _EIP1271：是一种针对contract所发签名的标准签名验证方案。由于EOA账户可以使用关联的私钥-公钥验签方式，而contract账户没有私钥，不可能进行常规签名，因此特有了此提案。主要运用函数isValidSignature（hash，signature），可以调用任意方法来验证contract签名，如ECDSA、multisig、BLS等。_ --- *Originally published on [加密卷心菜.eth](https://paragraph.com/@eth-18/what-why-how)*