长文深度解读“账户抽象”：7年路线演化及赛道图谱

账户抽象并不仅限于 EIP-4337 ，也不仅限于无私钥和社交恢复功能。本文从 EIP 提案梳理账户抽象发展历史和未来方向，从赛道图谱畅想账户抽象的无限可能……

账户抽象的真正落地仍需要一定的时间，但这将是为未来新用户降低门槛、提高使用体验的必经之路。

需要自我托管的钱包地址是用户在链上世界的 ” 账户 ” ，但同时也是阻碍用户进入 Web3 的一大障碍。对于账户的改进，是一场已经持续了 7 年多的试验。直到 2022 年十月， Vitalik 在推特发布了介绍 EIP-4337 有关账户抽象的 thread ；十一月在波哥大举办的 devcon 6 的各个分享会中，也频繁出现了 Account Abstraction 的身影，引发了关于账户抽象、合约钱包、 4337 的广泛热烈讨论。

账户抽象对支持用户上链的意义重大。 “Not your keys, not your coins.” 自我托管不知道被加密老炮们强调了多少次，但能做到的人却还是占极少数。账户抽象带来的极高的自由度，才能真正赋予了普通用户一个更安全好用的去中心化体验，自我托管将不再是少数极客才能做到。虽然 FTX 的爆雷对加密世界的未来蒙上了层深深的阴影，但也无疑验证了去中心化应用与自我托管的必要性。随着账户抽象的落地，加密行业将更有实力从中心化的坏蛋和皇帝们中解脱，走向更高维度的去中心化和自由。

目前， EIP-4337 被很多人视为账户抽象的方向标，但该提案仍然只是过于理想的草案。比如理想中交易打包能分摊 gas ，实际上却是验证过程额外增加了 gas 消耗；比如理想中合约钱包适用统一架构，实际是作为一种自愿采用的 ERC 提案，它的效应很弱；比如理想中使用 EIP-4337 的账户可以带来更优秀的使用体验，实际是许多 dapp 禁止合约地址交互的尴尬现状 ......

EIP-4337 这样的温和方案是账户抽象演进路程中的一次转变，是对开发资源紧张、直接进行代码改动影响过大等种种现实的妥协。这种妥协的方案有助于提前将账户抽象的理念发散推广，为未来的抽象化打下共识基础，但并不是账户抽象的终点。最终，以太坊仍然需要在代码层真正实现账户抽象，抵达那片我们所向往的乌托邦。

什么是账户抽象 —— 从算盘到智能计算器

在讨论账户抽象的具体意义之前，我们可以先拆解开来，分别理解什么是“账户”和“抽象”。

简单来说，以太坊的基础建立在两种账户类型上，一种承载用户的钱包，另一种承载智能合约的逻辑。他们的功能大多不兼容：用户的钱包无法进行逻辑判断，而承载智能合约的账户无法做任何逻辑之外的事情。可想而知，这样的账户系统并不优化。账户抽象的目标就是消除这种不兼容，把他们的区别 ” 一般化 ” —— 去掉特殊性，寻找共性。

账户 Accounts

以太坊有两种基本的账户类型：外部账户（ Externally Owned Accounts - EOA ）以及合约账户 （ Contract Account – CA ）。

EOA 即普通用户最经常接触的一类账户，如 MetaMask 钱包中的地址，它由用户通过私钥控制；而 CA 则是被部署在以太坊网络中的智能合约，由其代码进行控制，没有私钥。两类账户的异同之处如下所示：

抽象

抽象指从具体问题中，提取出具有共性的模式，再使用通用的解决方法加以处理。换言之，抽象是一个“一般化”的过程，需要去掉特殊性，寻找共性。

以一个更现实具体的例子来理解抽象化：小汽车玩具和乐高积木。一个小汽车玩具的结构是特殊的、具体的，由四个轮子和车身等一系列特殊的零部件组成。若你想有一个小卡车玩具甚至是飞机玩具，则需要重新购买新的玩具。而乐高积木则是更抽象的，更一般化的，他将玩具高度抽象化为了立方体、球形等一般的积木模块，玩家可以用这些积木搭建任何玩具形态。

在区块链的发展中，从比特币到以太坊实际上也是抽象化的过程。比特币网络最初的目的是想实现点对点的支付系统，带有特殊的明确目的；而以太坊把区块链变成了更加一般化的系统，去掉了专为点对点支付的特殊性，提取了区块链技术的共性搭建出了新的网络，有了以太坊虚拟机，使区块链上可以自由地构造各种不同的协议与应用，拓展了区块链生态。

账户抽象

账户抽象则是指要将以太坊的账户进行一般化，去除特殊性。在前文中我们也提到，以太坊拥有两种账户类型， EOA 和 CA 各有自身的特性，其中 EOA 是更 ” 顶层 ” 的账户，任何交易都只能依赖 EOA 发起并支付 ETH 作为 gas ，且 EOA 仅能使用 ECDSA 签名方案，由特定的 Secp 256 k 1 椭圆加密算法实现。但 EOA 不直接支持代码逻辑。支持代码逻辑的 CA 需要由 EOA 进行部署和发起交易。

这一切都是以太坊底层的特殊的强制设计。而账户抽象的目的就是希望使以太坊的账户一般化，使其拥有更高的自由度，拓展账户的可能性。针对账户的特殊性进行一般化就可以提取出以下几个账户抽象的关键：

1. 密码学抽象：即账户的签名验证不再仅限于特定的加密算法，用户可以自定义选择不同的加密算法作为安全机制

2. 账户功能抽象：支持代码逻辑，实现自定义功能

3. 交易抽象：账户都可以发起交易； gas 支付自定义

总而言之，对开发者来说，账户抽象意味着更高的自由度和更多的可能性；对用户来说，账户抽象则能从多个维度带来更好的使用体验，比如安全性、易用性、功能性。可以说账户抽象前，用户的钱包地址只是一个可以计算加减的算盘。而账户抽象实现后，这个算盘有了逻辑判断的功能，成为了一个有芯片的智能计算器。

账户抽象的发展历程 —— 从激进到温和直至过渡到终态

关于抽象化的探讨，早在 2015 年以太坊网络正式发布后的几个月就已经开始，直到今年 10 月仍有新提案提出。我们按时间顺序梳理账户抽象相关的 EIP ，以一窥账户抽象的不同解决方案及发展。

在此，将账户抽象方案的发展分为 3 个阶段：

从 2015 年以太坊上线起的 EIP-86 初次提出账户抽象，开始了长达 5 年的充满理想主义的激进改革。虽然这些直接更改以太坊底层代码的账户抽象提案都未能推进至审核阶段，但一些附属的提案通过，为账户抽象打下了一定的基础。如 EIP-1014 实现无需部署合约即可提前计算出合约地址，以及 EIP-1271 实现通过合约账户进行签名的方案。

从激进的改革中挫败后，账户抽象开始寻找一条更加温和的折中的方案。该阶段不再试图直接更改以太坊底层代码，而是以推出 ERC 标准为主，由开发者自愿采用。 EIP-4337 出世，开启了账户抽象的温和推进时代。近期， EIP-5189 基于 4337 的思路，提出了进一步的优化方案。

ERC 标准的账户抽象方案是对底层代码更改慢、影响大、兼容性差的妥协。这样温和的方式有助于账户抽象的概念传播，让账户抽象先从理想的讨论中先落实到可实践的现实中，并在实践中循序渐进，不断改进完善与改进现有方案的缺憾。

未来，经过温和的演变并达成一定的共识后，将可能适用 EIP-3074 、 5003 等提案的方式，将 EOA 升级为合约账户。以太坊将最终实现最初的理想，在底层协议中进行彻底的变更，将账户统一为一种可编程、可自定义的账户。

过去 - 激进改革

从相关提案首次提出开始，对于账户抽象的解决方案一直都是对共识层进行直接变更的暴力改革方案，并在该阶段的一次次提案中不断完善。

EIP-101

方案简介：

2015 年底，以太坊创始人 Vitalik 在 EIP-101 中首次提出了抽象化。该提案中 Vitalik 讨论了对 Serenity 中的账户体系的抽象化设计，将账户从 4 个字段简化为仅 code 和 storage 两个字段， ETH 都被存储在一个代币合约中，保留映射用户余额的地址列表；交易从 8 个字段简化为了 4 个字段，极大程度地进行了账户和交易的抽象化。

优势：

• 用户自定义安全模式，使用其他加密算法保护账户安全

• ETH 和其他 ERC 20 代币可以被平等地对待

• 降低了自定义账户功能（比如多签）的间接性。

问题与现状：

该提案对账户体系进行了大刀阔斧的改动，存在兼容问题以及安全隐患，因此在当时暂时被搁置至分片后，目前已是 stagnant 状态。

EIP-86

方案简介：

2017 年， Vitalik 提出 EIP-86 ，对交易来源以及签名进行抽象，再次对底层代码进行激进的变更。该提案中允许用户创建能够使用任何签名和 nonce 检查机制的账户合约。在该方案中有一个 entry point 合约，任何人都可以通过这个合约发送交易，账户合约接收来自 entry point 的数据并对签名进行检查，正确则向矿工进行 gas 支付。该方案是对账户抽象的准备，使用户可以自定义签名算法，不再强制使用以太坊硬编码的 ECDSA 和默认的 nonce 机制；同时 gas 是在验证签名正确后才由合约账户支付。

优势：

• 多签：每一位多签人不需要都拥有 ETH ，包含多签信息的交易可以直接发送到多签账户，由多签账户直接支付

• 环签名混币：环签名指签名首尾衔接形成一个环形，因此无法判断起始点。 n 名用户向合约发送相通数量的代币，再使用环签名的方式取出相同数量的代币。但由于提取代币需要准备 gas ，在该阶段存在暴露风险。因此通过该提案， gas 可以从提取的代币中直接支付，保障了该场景下的隐私性。

• 自定义密码学：用户可以使用 Lamport 等量子安全的签名方式保障账户安全

• 自定义非密码学功能：例如设置交易过期时间等

问题与现状：

• 新的交易类型没有交易发送方（都是 entry point ），破坏了哈希唯一性。对基于哈希唯一性的协议操作不可兼容

• 无 gas 支付的必要性不足，目前通过代理合约也可以实现，只是成本会稍高一些

• 矿工挖矿策略会受到极大程度影响

• 新的交易类型保留了 nonce 、 gasprice 、 value 等字段且被设置为 0 ，缺乏代码优雅性

• 因此，基于这些问题，该提案最终被暂缓引入，目前也是 stagnant 状态。

EIP-859

方案简介：

该提案引入了新的交易类型和新的操作码，在交易中仍然强制保留了 nonce 字段，维持了交易哈希唯一性。引入 paygas 操作码进行 gas 支付，并作为验证部分交易和执行部分交易的逻辑分界。

优势：

• 自定义签名机制 Customized signature scheme

• 延续了交易哈希唯一性 Maintains transaction hash uniqueness

• 可以支持更复杂的验证情景并节省 gas ，比如在代币 ICO 时，有 1 万笔交易同时参与，但代币上线仅至支持前 5000 笔，按照现有逻辑所有一万笔交易都会被打包上链，而在该提案下，合约可以设置后 5000 笔不被包含进区块上链，从而节省 gas 消耗名，减少无效的垃圾交易。

问题与现状：

• 不能支持使用 ERC-20 代币支付 gas

• Cannot use ERC 20 s to pay for gas

实际上该提案一直并未形成确定性的草案，仅仅停留在讨论阶段。此提案也在多次以太坊开发者会议上进行了讨论，但由于不够成熟，且当时升级所包含的内容已经很多了，因此该提案也被永久搁置。

EIP-1014

方案简介：

该提案并未直接提及账户抽象，但却与账户抽象发展息息相关。该提案介绍了一种在实际部署合约地址之前，可以预先计算合约地址的方法，并在部署合约地址之前可以先向该地址发送资产，在使用该合约地址进行第一笔交易的时候，再进行部署。

优势：

• 节省了成本：用户可以在支付 gas 部署合约之前，提前计算合约地址

• 多链合约地址一致：合约地址需要部署后才存在，因此不像 EOA 可以直接实现多链一致；通过该操作码中的 salt 参数，合约地址也可以实现多链一致

现状：

该提案最终通过，为智能合约钱包的发展奠定了重要基础。

EIP-1271

方案简介：

该提案提供了一套验证代表合约账户的签名是否有效的标准。这使得合约账户能够像 EOA 一样进行签名验证。

优势：

该提案作为已经确定的 ERC 标准，开发者们可以自愿采用。这为未来合约账户的推广和普及打下了良好的基础，只要 dapp 愿意支持合约地址签名，简单在协议中增加 EIP-1271 的代码即可。

现状：

该提案已经最终通过，已经有实际应用，如 opensea 支持 authereum 合约钱包进行签名登陆。

EIP-2938

方案简介：

2020 年， Vitalik 联合多人提出了更完善的账户抽象解决方案。相较于之前的账户抽象目标将账户类型统一为 1 种合约账户， EIP-2938 提案中仍然保持现有的 EOA 和合约账户两种，但接纳合约作为顶层账户，使其可以支付交易 gas 以及发起交易执行过程。

该提案中定义了一种新的类型的 transaction ： Account Abstraction transactions ，并引入了两个 opcode ： Nonce 和 PAYGAS 。这一改进仍然需要对以太坊的底层代码进行变更。

EIP-2938 还对该解决方案实施进行了规划并阐述了具体的应用场景。账户抽象被分为了两个层级：首先是实现单租户账户抽象，然后再拓展至多租户账户抽象。

优势及场景：

单租户 Single-tenant

• 自定义使用除 ECDSA 以外的签名验证方式（比如 BLS ， post-quantum ）

• 增加多签验证、社交恢复等合约钱包功能

• 使用 ERC-20 代币支付 gas 。

多租户 Multi-tenant

• 隐私：比如 tornado cash 这样的保留隐私的场景下，账户不再需要准备 gas 费用而暴露隐私。

• 省 gas ：比如套利机会出现时，大量的套利者同时发起套利交易，而首笔成功后，其他套利交易失败但仍然被打包在区块中，在账户抽象后，套利者则无需再为失败的套利行为付 gas ，减少了链上的垃圾交易的数量。

问题及现状：

虽然该方案更加详尽，但对多租户阶段的技术方案仍未成型。且该方案被认为在技术及经济上都不够高效，因此也没有进入最终阶段。

至此，账户抽象的第一阶段，激进暴力地对以太坊底层协议进行变更的方案几乎都被搁置。账户抽象的优先度、必要性、经济性、兼容性都仍然有待进一步优化。

当下 - 温和变更

以太坊开发者们专注于以太坊的合并与分片，直接进行底层协议变更的方案难以推进，以 Vitalik 为代表的开发者们，不得不妥协，提出了相对更温和的、间接的替代方案。

EIP 4337

方案简介：

该提案是首个不需要对以太坊底层代码进行变更的账户抽象提案。在 ERC-4337 中，引入了一个 UserOperation 对象。用户将 UserOperation 对象发送到单独的内存池中。 Bundler 将这些对象打包成一个交易，对一个 Entry Point 合约进行调用，然后该交易就被纳入一个区块中。

优势：

• 自定义签名算法：支持 ECDSA 之外的签名算法

• 功能自定义：通过合约代码可以实现 gas 代付、社交恢复等功能

问题及现状：

• 不可升级：用户需要将资产和活动转移至新地址以支持该标准

• Gas 开销更大：引入的 user operation 会带来更高的 gas 消耗

• 兼容问题：现有的某些 dapp 或协议可能禁止了与合约账户的交互

尽管有诸多实际的问题，但 Vitalik 希望在短期内先大力支持 ERC-4337 ，在实践的过程中研究更优的方案，并不断对其进行完善和改进。在实现了大规模的推广后，形成共识与规模效应，将有利于促使现有应用做出更改，支持合约账户的交互和支持 ERC-1271 的合约签名标准。目前， EIP 4337 仍然处于 Draft 状态，等待继续推进至下一阶段。

EIP-5189

方案简介：

该提案是改造交易打包过程的 ERC 提案，同样不需要对底层代码进行改动。该提案引入了一个 endorser 的角色，合约钱包的开发者定义 endorser 合约，从而帮助确认提交的元交易的质量，帮助 bundler 确定该交易是否该留在 mempool 中。该提案将账户抽象为 bundler 带来的风险转移至钱包开发者，希望开发者负责编码、部署 endorser 合约。

优势：

降低了 bundler 筛选元交易的门槛和风险

问题及现状：

该提案目前刚形成草案，尚在早期阶段。

在该阶段，账户抽象的方案从早期的暴力革命转化为了平和演变。虽然力度更弱，但实施起来更加容易，可以推进智能合约钱包的发展，吸引并积累一定的用户群体。

未来 - 强制实施

Vitalik 在提到，希望在推行 ERC-4337 的过程中，不断再推出新的提案对 ERC-4337 的缺憾进行完善，比如实现 EOA 向合约地址的升级，以及 gas 费用的优化。可能的路径将从自愿采用到广泛普及，再到最终实施强制转换，达成以太坊账户类型统一为一种的终极目标。

EIP-3074

方案简介：

EIP 3074 的提出实际早于 EIP 4337 ，它没有引入新的交易类型，而是引入了 AUTH 和 AUTHCALL 两个操作码，允许将 EOA 控制权委托给智能合约，这让所有的 EOA 可以拥有智能合约钱包的功能。

优势：

• 代付 gas ： gas 费用可以由另一个账户支付，不持有 ETH 的地址也可以发送代币。

• 批量交易：通过单个调用发送多笔交易，降低了交易费用

问题及现状：

该提案需要对以太坊代码进行更改，计划是在上海升级阶段进行实施，目前由于各种安全性的不确定，仍然在 review 阶段进行审查。

EIP-5003

方案简介：

该提案是对 EIP 3074 的拓展提案，再引入了新的操作码 AUTHUSURP ，允许被授权地址设置授权地址的代码，实现 EOA 向合约账户的升级。

优势：

实现 EOA 向合约账户的升级

现状：

该提案基于 EIP-3074 ，目前仍然处于 draft 阶段，进度应该会受 EIP-3074 进度的影响。

Layer 2 ？

从上述的 EIP 发展历史可以看出，账户抽象是为了解决以太坊双账户体系的遗留问题，然而直接对协议进行变更的方案虽然更直接，却需要动用更多的开发人员，而账户抽象的紧迫性尚不高，因此遇到了很多阻碍。相较起来，直接变更代码的方案可能更适用于生态刚起步的新 layer 2 公链。例如 Starknet ，就是一条原生支持账户抽象的链，其只有一种统一的账户类型，可以编程，可以发送交易、收发资产等。 10 月 zksync 2.0 主网上线，也引入了账户抽象的新功能，账户可以发起交易，也可以执行被部署其上的代码逻辑。

此外，在 Layer 2 相较于以太坊主网来说往往有更低的 gas 费用，对于部署就需要支付 gas 的智能合约账户来说，用户体验会更好，成本更低廉。

因此，在账户抽象最终在以太坊主网实现之前， Layer 2 可能才是账户抽象与合约钱包发展的前沿。

账户抽象赛道图谱

账户抽象，意味着未来的账户都将拥有合约账户的类似功能。在账户抽象在共识与底层代码全面实现之前，目前已经有一些智能合约钱包产品（ Smart Contract Wallet-SCW ），看到了合约账户的优势，正在为用户提供 EOA 账户体系以外的选择。

在此，通过对智能合约钱包以及相关智能合约平台的产品梳理，我们可以了解目前的 SCW 的发展方向，并借此畅想 ERC-4337 或是账户抽象完全实现之后，钱包可能的应用场景。

账户抽象概念项目对比

从 SCW 的发展历史上看，大致分为几个阶段：最初是以 Safe 为代表的 to B 产品，使用多签的模式解决账户及资产的安全问题；随后， defi 的繁荣发展，促使了普通用户的需求增加， Argent ， Pillar ， Authereum 这类主打易用性，降低用户使用门槛、优化使用体验的产品 随之出现 ；如今，账户抽象在以太坊直接暴力改革的可能性降低以及以太坊主网高昂的 gas 费用，为 Layer 2 提供了新的机会， Loopering 之类基于 layer 2 的合约钱包也应势而生， Argent 的开发重心也逐渐向 Zksync 、 Straknet 倾斜，近期基于 ERC-4337 的 soulwallet 、 unipass 等也都选择先在 layer 2 上进行发展；未来，随着账户抽象及合约账户的普及和兼容，在更多具体场景下，合约钱包会有更多的生机与潜力，比如 A 3 S 协议将账户 NFT 化可以实现账户的金融化以及账户的临时代管； defisaver 的模块化功能可以给予普通用户定制化合约钱包功能、设置账户逻辑的可能。

账户抽象有必要吗？

MetaMask 这样传统的 EOA 钱包一直饱受用户体验差的诟病，用户需要自己妥善管理私钥或是助记词，承担私钥泄漏风险。这也使得进入 web3 世界的第一步就有着相当高的门槛。

近期，许多拥有大量用户和流量的 web2 公司都在尝试向 web3 进行拓展，例如 Reddit 面向用户发行了 reddit NFT ，轻而易举地带来了远超 Opensea 现有用户体量的新用户。在 NFT 铸造流程的引导上， reddit 竭尽所能地降低用户的理解门槛，模糊了关于地址、私钥、 NFT 等复杂的概念。

如果采用无私钥的合约钱包，就能从根本上消除门槛，为大体量的 web2 用户提供一种更好地进入 web3 的渠道。

但，安全性、无私钥的体验必须要通过账户抽象或合约地址才能实现吗？

并不。

第一类选择是目前大多交易所采用的托管型钱包，即私钥并不是掌握在用户自己手中，而是由交易所代表用户持有并管理资产，用户无法全盘掌握自己的资金。这样的托管型钱包能极大程度地降低用户门槛，但也存在相应的信任风险。近期 FTX 的突然爆雷，让用户意识到，托管的资产可能被挪用，看似强大的机构也可能崩塌。只有将资产的控制权完全掌握在自己的手中才是最安全的选择。 Not your key, not your coins 。

还有一类钱包应用了一种叫做多方安全计算（ Multi-Party Compution - MPC ）的技术，同样可以实现部分合约钱包想要达成的安全性、无私钥的用户体验。

一般来说 MPC 大多使用的是门限签名（ TSS- Threshold Signature Scheme ）的方法，简单来说就是将私钥碎片化，并将碎片交由去中心化的网络进行计算和加密。需要进行私钥签名时，则将碎片拼接起来形成完整的私钥，通过分散控制权的方式避免了单点失败的安全问题。这种方式介于自托管和托管之间，可以被称为半托管型钱包。

这个逻辑和多签钱包有一定的相似度，但区别在于，多签钱包每一位多签人都提供完整的私钥签名控制合约账户；而 TSS 的验证过程只涉及一个私钥，且是链下的，与智能合约并无直接关联。

现在也存在很多优秀的 MPC 钱包产品，比如 To B 的 Safeheron 以及 To C 的 Bitizen 。

MPC 也可以实现无私钥等功能，且 MPC 可以基于 EOA ，在使用上似乎更便宜，兼容性也更好。 MPC 技术不仅仅适用于 EVM 链，其他非 EVM 的账户也可以适用。那么，基于无私钥等目的的合约钱包，或是账户抽象是否真的必要呢？

这样的争论确实存在，在今年五月， Coinbase 在自己的 MPC 钱包的推广推特中质疑了合约钱包的 gas 昂贵、用户可能无法找到足够信任的 guardians 等问题。

而 Vitalik 也在此 twitter 下也表达了自己的态度：

可以看出， Vitalik 希望在协议层面上进行账户抽象，以实现账户签名算法能够自定义的目标。以太坊目前强制的 ECDSA 签名算法并不是最优的选择， MPC 不过是在基于 ECDSA 的一种局部的安全方案。 而实现账户抽象后，则可以根据技术的发展，直接 使用 更先进、更安全的签名算法（比如抗量子的）。

因此，账户抽象在更安全的签名算法、更优秀的用户体验、更完全的资产控制权等维度仍然存在相当的必要性。

账户抽象钱包的究极形态

账户抽象普及并达成共识后，合约账户的兼容性、经济性都将得到提升。在此，我们也对这类产品的终态，对其能提供的功能和适用的场景进行乐观地预测或者说是期待，我们认为可能会包括以下功能和应用场景：

1. 无私钥：用户无需再保管助记词或私钥；可以通过生物验证、设备验证等多种验证方式

2. 账户恢复：可以通过生物识别、社交验证等方式进行账户恢复

3. 无 gas 交互：用户可以使用交易中涉及的 ERC-20 代币进行 gas 支付，或直接指定固定的账户进行支付，而无需提前准备 ETH 作为 gas ；或在交易失败时无需支付 gas 费用

4. 自定义安全机制：可以随着密码学的发展，选择更优的安全机制

5. 隐私性：基于环签名等方式实现的更有效的链上隐私性

6. 账户临时托管：用户可以设置管理方、时常、交互等要求，将账户托管给他人进行管理，达到时间或要求后自动收回。

7. 账户抵押 / 交易：账户内包含资产及积累的链上信用历史，账户本身可以在链上市场进行直接的抵押、交易

8. 账户权限限制和分割：可以许可给他人部分账户权限，比如仅能使用账户内的 NFT 而不能使用代币

9. 自定义工作流：设置自动的触发点和流程。比如 A 账户余额每比 1 Eth 多出 0.5 ETH 时，就自动将多余的 0.5 ETH 转入 B 账户， B 账户在某个 token 达到一定价格时，就自动将 ETH swap 成某 token……

10. 交易限制：可以设置交易时间、额度，超过时间或超出额度的交易则不能成功

11. 白名单 / 黑名单：限制与黑名单的地址进行交互，比如黑名单地址发送的资产会被自动退回，以规避之前 tornado cash 被制裁后，向其他地址 “ 投毒 ” ，导致地址被其他协议前端错误封禁的情况。

12. 账户分类管理系统：用户在不同场景下使用专用的账户，拥有一个更合理的账户管理体系。比如某个账户作为 gas 账户仅存放 ETH ，其他所有账户的交互都由 gas 账户进行支付；某个账户仅存放蓝筹 NFT ，不会被轻易动用；某个账户作为游戏专用账户

13. 模块化代码功能：为用户提供不同的功能模块，用户无需懂代码，只需按照自己的需求，组合功能模块，即可自定义符合自己习惯和需求的账户。

结语：

账户抽象的落地值得所有人的期待。因为这不仅会帮助链上用户数量大幅增长，账户抽象给开发者带来的高度自由度更是会解决目前账户系统的痛点，并诞生新的应用、玩法、和想象空间。

在代码层面实现账户抽象充满了阻碍与不确定，虽然 EIP-4337 这样的妥协方案也仍然存在 gas 高、兼容性差等实际问题，但大力推进 EIP-4337 也不失为一种概念推广、增强共识的选择。随着概念的普及，账户抽象以及合约钱包将可以从小众走向主流，从用户需求推动协议兼容，形成新的账户范式。最终，在广泛的共识下，以太坊才拥有直接更改底层代码达成账户抽象的条件。

在最终的账户抽象落地后，目前账户系统的高门槛和复杂的使用体验将不再是理所当然的事情。这种新的账户体系将更利于为 web3 吸引新用户和流量，激励生态的蓬勃发展，从而形成正向的循环。