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

By [Dfax_official](https://paragraph.com/@dfax-official) · 2023-01-05

---

原文：[《长文深度解读“账户抽象”：7年路线演化及赛道图谱》](https://www.odaily.news/post/5184056)

需要自我托管的钱包地址是用户在链上世界的”账户”，但同时也是阻碍用户进入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则是被部署在以太坊网络中的智能合约，由其代码进行控制，没有私钥。两类账户的异同之处如下所示：

![](https://storage.googleapis.com/papyrus_images/909acad61c06898cc3f521bf31c853d9af9c055d5a085257abf2a12aaffdaca8.png)

抽象

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

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

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

账户抽象

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

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

1.  密码学抽象：即账户的签名验证不再仅限于特定的加密算法，用户可以自定义选择不同的加密算法作为安全机制
    
2.  账户功能抽象：支持代码逻辑，实现自定义功能
    
3.  交易抽象：账户都可以发起交易；gas支付自定义
    

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

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

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

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

![](https://storage.googleapis.com/papyrus_images/ef898bfc07599edc09f5fa6c9349a14c7ec31a84e61ce1e383d46802f4d007a8.png)

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

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

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

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

![](https://storage.googleapis.com/papyrus_images/efef060b10ee9d8e9a58b1761ceb746fe54e3728b4a0f2c4cea53d31f3786788.png)

> **过去-激进改革**

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

**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 或是账户抽象完全实现之后，钱包可能的应用场景。

![](https://storage.googleapis.com/papyrus_images/662aa25e8811f37d0fd57f3be21c7fed728737aad68cf7982b94bd3894c09259.png)

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

![](https://storage.googleapis.com/papyrus_images/e3b7848742ddcf05ea4a371ed3a89742ba5a0626c62914e456c723d1c5efe5e8.png)

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

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

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

![](https://storage.googleapis.com/papyrus_images/e05b57187ac6a4309994d3346ba15db9e2d2e32ef7e6e125f873320a3c621859.png)

可以看出，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吸引新用户和流量，激励生态的蓬勃发展，从而形成正向的循环。

[Subscribe](null)

---

*Originally published on [Dfax_official](https://paragraph.com/@dfax-official/7)*