Smart Account 生态碎片化、全链账户抽象 UX 高度割裂 等问题该如何解决？
作者：Peter Pan, Co-founder and CTO of Particle Network，Faust，极客 Web3
自 2022 年至今，账户抽象一直都是被广泛热议的话题，以 EIP-4337 为核心的账号抽象领域的框架似乎已成为业内普遍共识。而意图概念的火热促使人们加强了对此类低门槛用户交互组件的重视。
但 EIP-4337 依然存在 Smart Account 账号碎片化、跨链间账户抽象用户体验高度割裂的痛点。本文以 Biconomy、Safe Core 和 Particle Network 等项目为例，探讨如何在 EIP-4337 框架下进一步推动账号抽象领域的发展。
从交易流程抽象的角度理解” 账户抽象 “概念
关于账户抽象，Vitalik 曾多次指出，它是降低以太坊用户门槛、实现 mass adoption 的必要条件，其核心愿景是让用户可以 自定义验签方式 + 享受 gas 代付、无任何资产就能在链上发起交易（俗称无 gas 交易）。只有实现了这些前提，才能提高 Web3 应用的新用户转化率。
以往的非账户抽象提案或智能合约钱包，虽然可以实现类似的体验，但还远不够灵活和高效，比如 Gnosis Safe 还是需要 EOA 地址去触发交易，而且付出的 Gas 成本极高。
而账户抽象打算从智能合约账户的结构底层进行优化，为下一代智能化账号体系铺平道路。
但是我们从实际的账户抽象提案来看，会发现他们的关注点不在账号模型本身。比如 EIP-86、EIP-4337 和 EIP-6900 等账户抽象相关提案，关注的是一笔交易从发起到被节点接收、验签、gas 支付等整套处理流程的抽象/模块化，并不是真正关注账号结构的抽象。所以，把现在的各类提案称为 “交易抽象” 似乎要更贴切一些。
如果我们从 “交易处理流程的抽象” 的角度去理解那些广为人知的账户抽象提案，就可以更轻松的理解到其要点：这种交易抽象，其实就是想把 Web2 级别的用户进入和使用产品的体验带入到以太坊体系内，比如黑名单/白名单、一段时间内发起交易无需身份验证、无 Gas 交易、法币支付手续费等。
但有人会问：这些东西在过去的智能合约钱包身上不就可以实现了吗？EIP-4337 这类账户抽象方案的价值又在哪里？
EIP-4337 的本质：账户抽象在以太坊生态落地的局部最优解
如上问题提到，过去的智能钱包虽然可以实现上面谈到的功能，但实现手法普遍比较粗糙，而且往往依赖于高度中心化的第三方设施。比如过去的 Gas 代付方案，要引入第三方的 Relayer 节点（EIP-2771）。而且，不同的智能钱包之间缺乏统一的标准，不利于配套的组件开发与铺陈。
而各类账户抽象相关 EIP 的核心诉求，是通过一套标准化的专为智能合约钱包设计的框架，解决这些存在于不同钱包项目身上的缺陷，推进以太坊生态内的账户结构从基础的功能结构转变为上限更高的智能结构。
这就好比，在 ERC-20 或 ERC-721 出现前，很多 Token 的实现方式、具备的功能、对外提供的函数/接口都不一致，而 “不一致” 就不利于配套的第三方设施开发，也不利于代码审计（难以想象没有 ERC-20 协议的话，Defi 应用该怎么发展到如今的繁荣程度）。
标准化的协议/功能实现标准，是模块化叙事的先决条件，而模块化开发方式则几乎是每个领域想要蓬勃发展的先决条件（分工是提高效率的第一原则）。
最终，EIP-4337 脱颖而出。
EIP-4337 是局部最优解，但其框架内有多个角度亟待优化
EIP-4337 定义了一整套的接口标准，明确了遵循 4337 协议的智能钱包至少要有哪些模块，每个模块应当实现哪些函数/接口，比如 Bundler、EntryPoint、Paymaster 这些组件应该对外提供哪些可调用的函数。
将这些条条框框明确了之后，不同组件之间的交互关系更为清晰，方便把模块化的设计思路引入到账户抽象与智能钱包的设计中，钱包模块的开发者们也大大受益。
当然，单纯从用户角度看，模块化的智能钱包开发范式带来的价值还不明确，因为短期内人们感受不到账户抽象钱包本身有多大变化。但从中长期来看，EIP-4337 等协议的价值就类似于 ERC-20 和 ERC-721，它为账户抽象钱包的长期发展奠定了基础，是有划时代意义的里程碑。
但 EIP-4337 还有许多问题没有解决：比如：
1. 账户抽象的功能还不够插件化，不同的开发者很容易重复造轮子；
2. 账户模块兼容度差，整个账号体系呈现生态呈现碎片化的状态倾向；
3. 不同链之间的账户抽象生态高度割裂，难以给终端用户和开发者提供统一且高质量的体验实现较好的 UX。
而下文中，我们将探讨这些问题的解决方案。
优化方向一：账户抽象的功能插件化将成为基础配置
可以说，现在与账户抽象相关的核心讨论点之一，就是如何更好的实现账号抽象钱包的模块化，将每个模块的划分粒度切的更细。
比如 Biconomy 就基于 EIP-4337（未来会引入粒度更细的 EIP-6900），提出了账户抽象功能插件化的叙事，以进一步推动账户抽象生态的模块化发展。
所谓的账户抽象功能插件化，其实就是通过一套协议，对外明确智能合约钱包涉及的关键模块都有哪些，这些模块应当实现哪些接口/函数，这些接口的名称和调用方式是怎样的。然后，第三方开发者会按照自己的想法，开发出细节各异的组件，但这些组件都会符合协议中提出的要求。
Biconomy 的 V2 版本以 EIP-4337 为协议骨架，制定了更详细的标准，增设了一批 4337 中没有提及的接口。在声明 Bundler、Smart Contract Wallet、Paymaster 这些模块应该具备哪些功能的同时，Biconomy 允许第三方开发者以不同的代码细节，实现特征相同、版本不同的模块，只要遵循 Biconomy 事先声明的协议细则即可（兼容 EIP-4337）。
同时，Biconomy 还提出了 “Module 商店” 的口号，在身体力行推出账户抽象模块 SDK 的同时，鼓励广大开发者提交自己设计的账户抽象模块，展开 “Module as a service”，让所有遵循 EIP-4337 协议的钱包项目都可以直接采用这些由外人写出来的账户抽象模块。用户通过前端页面创建智能账户时，对于采用哪些模块也有了更多样化的选择。
模块化在便于分工的同时，也方便了用户快捷的切换或添加、删除智能钱包中的某些功能（说白了就是把粒度切分的更细）。
Biconomy 指出，智能合约钱包的模块化程度越高，其更新或升级时所需要作出的改动越少（不需要更新用户已有的 Smart Contract Wallet 合约或采用 DelegateCall，只需要更新某些外部模块），方便不同的用户或开发者替换掉某些组件。
而在 Biconomy 未来的新版账户抽象方案中，还将参考比 EIP-4337 更利于模块化的 EIP-6900 提案。
优化方向二：更细粒度的模块切分，解决账号碎片化问题
关于 EIP-6900 提案，Safe（前 Gnosis Safe）其实在今年 8 月推出了一个与之相关联的 Safe Core Protocol 白皮书，其中借鉴最多的就是 EIP-6900。
EIP-6900 指出，目前模块化账户抽象的一个问题在于账号的 “碎片化”，或者说孤岛问题。比如不同的账户抽象模块供应商，或者不同的 DAPP 应用程序虽然会兼容 EIP-4337，但 EIP-4337 对不同模块的抽象程度不够高，划分粒度比较粗糙，给 Smart Account 模块开发者留下了 “过高” 的自由度（smart account 就是存放用户信息，记录自定义的交易验证、gas 支付逻辑 的最核心的部分）。
这样一来，不同的钱包项目方倾向于设计出具有独特属性的 smart account 模块。长此以往，其他的账户抽象模块供应商就必须优先考虑与谁提供的 Smart Account 模块兼容，慢慢会产生固定的上下游供应链，这必然会导致账户抽象模块生态的碎片化和彼此割裂。（这就好比在计算机行业早期，操作系统开发商要先考虑兼容哪家电脑硬件厂商提供的设备）
要解决生态的碎片化问题，提高不同供应商开发的账户抽象模块的兼容度，最佳的办法就是把智能合约钱包账户进一步抽象化，把模块切分粒度变得更细。
在借鉴了 EIP-6900 的思路后，Safe Core 协议白皮书对 Smart Account（用户的智能钱包账户）做出了更细致的优化。Safe Core 协议把每个智能钱包账户可调用的 Module 拆分为 Plugin 插件、Hooks、签名验证器、函数处理器等多种类别。
而智能账户模块尽可能轻量化，账户合约只存储最基本的数据和函数，能挪到外面去的函数就统统甩给 “函数处理器” 或 “Plugin” 这些细分模块去实现。这正应了所谓的奥卡姆剃刀原则——“若无必要，勿增实体”。
如果 smart account 本身足够轻量化，不涉及太繁琐的细节，不同厂商开发的 smart account 在内部构造上就会更接近，兼容度也会更高。
Safe Core 协议里还引入了注册表，类似于 iPhone 的应用商店，包含了所有被批准的可用模块。用户可以选择激活哪些模块，且每次激活新模块时，都要经由 Manger 合约去处理。
一般情况下，UserOperation 会先触发某个插件 Plugin，然后 Manger 合约会检查该插件的状态是否正常（注册表里有记录），若正常则会放行该插件的请求。如果有必要的话，Plugin 插件会调用某些 Hook 提供的功能，或者不调用。之后会对 UserOperation 涉及的 smart account 的状态进行更改。
通过上述细粒度的模块切分方式与调度流程，Safe Core Protocol 尝试推行一套开源的账户抽象模块互操作协议，其核心思路是把 Smart Account 轻量化，尽可能像 EOA 账户一样简单，以便于提高不同厂商提高的 Smart Account 模块的兼容度。
优化方向三：全链账户抽象，在不同链上实现统一账户
但即便有了前述解决方案，目前还有一个大问题没有解决：不同的链和不同 Layer2 都在推进细节各异的账户抽象实现方案，而且很多采用了与 EIP-4337 有冲突的形式，比如 zkSync Era、Starknet、Flow 等。这给用户带来了钱包 UX 上的割裂，比如用户在 Starknet 上的智能钱包地址与 Arbitrum 上的智能钱包地址压根无法统一。
而且，在多链环境下，用户在不同链上有独立部署的 Smart Account，对应的用户数据往往分散存储在这些合约中。如果用户数据如密钥等需要更新，则需要在多链重复发起交易，很难保证 Smart Account 的一致性。
Vitalik 本人此前曾提出过一套全链统一且易于管理的智能账户方案，该方案把以太坊或某个安全性极高的 ZKRollup 作为源链，部署 Keystore 合约，存储用户的全局密钥，然后用户在 L2 上的全部智能合约账户，共享 Keystore 合约中存放的全局密钥。
但这个方案成本极高，就是每当源链上的 Keystore 合约记录的全局密钥发生变更时，L2/目标链上的每个账户都需要通过跨链交互的方式来同步新的密钥。而以太坊到 L2 之间的跨链交互开销太高，用户根本承担不起。而且需要注意的是，智能合约账户不同于 EOA 账户，后者因其独特的地址生成方式，天生就是多链统一的（EVM 链之间统一），但智能合约账户则完全不同，很难让用户在不同的链上获得地址相同的智能合约账户。
对此，Particle Network 提出了自己的一种方法。虽然大体思路和 Vitalik 的想法一致，也是把智能账户的 Storage 和 Code 分离，但 Particle Network 打算以一个独立的链—Particle Network Chain 作为智能账户的全链 Storage 数据库，通过第三方的跨链消息传递方案（LayerZero、CCIP、Axelar、Connext 等）将某个用户对账户 Storage 的变更同步到其他链上的 Account 本地。
具体而言，Particle Network 的全链账户抽象系统要让用户在不同的 EVM 链上有一个统一的智能合约账户地址，这要在不同链上都部署一套 Deployer Contract；
用户必须在 Particle Network Chain 上触发新账户的生成，之后 Particle Chain 会触发所有链上的 Deployer Contract，保证在不同链上为用户生成的智能合约账户地址是统一的，或者用户可以在对其他链无感知的情况下，通过 Particle chain 上的合约完成多链交互过程，并且可以用 Unified Gas Token 作为统一的手续费支付方式。
全链账户抽象也让 Cross-Chain 的 User Operation 成为可能，通过源链的 User Operation 和支付对应的 Gas，来触发目标链的 Transaction，比如可以实现使用 Polygon 的 USDC 购买 Base 上的 NFT。
但 Particle Network 的方案需要 Deployer Contract 和跨链消息传递组件高度协同，来实现多链 Account 和源链 Storage 的同步，这其实就对其采用的预言机或者跨链消息桥有较高要求（这个问题似乎在所有和全链互操作有关的方案身上都会存在）。
不过用户的跨链账号同步可以灵活配置不同 Message Bridge 的组合，而不仅仅依赖某一个 Bridge，比如可以配置为 2/3 的策略，依赖 LayerZero、Axelar、Connext 任意两个的确认才在目标链上确认 Storage 的变更，可以近似解决这种单点依赖问题。
横跨 EVM 和非 EVM 的全链无缝互操作是以太坊生态内的全链账户抽象的更进一步
尽管有横跨 EVM 链的密钥管理和统一账户，但全链账户抽象依然有优化空间：不兼容 EVM 的链，比如 Aptos 和 Solana、Sui 等，无法保证用户生成的智能合约账户地址，与 EVM 链上的一致；同时非 EVM 链如果没有用等价的方案实现 EIP-4337 协议，就难以沿用前文中 Vitalik 和 Particle Network 提出的全链账户抽象的构想。
此外，兼容 EIP-4337 的钱包项目本身也存在进步的空间。大多数智能钱包使用的 Bundler 节点，都是官方独立运行的，彼此甚至都不互通，很多智能钱包项目实际自成一条链，这就会带来很多风险（抗审查性、可用性）。构建一个统一的横跨绝大多数链的单一前端界面，但这会非常困难。有一个解决思路是引入以意图为中心的设计，在全链账户抽象之上增设一层，把以太坊的 EIP-4337 生态或其他链的原生账户抽象设施（例如 zkSync），统统视作 Solver/Reactor 类型下的具体实例，而如何选择合适的 Solver 是更上层的任务。
仅以 Particle Network 为例，它提出了一套简洁的抽象化的 Intent-Centric 实现方案，而不同的账户抽象项目只是 Intent 方案中，被包含进 Solver 范畴内的一类实例。
首先，用户前端会负责将自然语言化的请求或者任意的用户交互，转变为具体的程式化描述，其中包含输入约束和输出约束（说白了就是能让符合用户要求的输入条件和输出结果区间），随后 Solver 网络中的某个或某些 Solver，会将包含具体输入输出约束的 Transaction，转发给部署在链上的 Solver 合约（Solver 不只有节点设施，还会有链上合约部分）。Solver 合约会将 Intent 指令传送给 Reactor 合约（管理用户在链上的账户），交由后者去调用其他模块完成最终交互。
用户的请求最先被 Solver 网络所获知，这样用户不需要过多的感知底层链或者不同账户抽象方案的构造，这一部分交由 Solver 去构造具体的解决方案即可。
当然这些构想目前还只是一个理论框架，而后面的实现细节还有待 Particle Network 官方的铺陈。
目前比较明确的是，未来必定会衍生出一个充满竞争的 Solver 市场，而用户可以发起竞拍，让多个 Solver 出不同的解决方案，通过本地模拟交易的形式，可以评选出最优的解决方案，并给予对应的 Solver 以激励。至于激励的形式，就要看 Solver 网络的协议设计者的考量（Particle Network 打算以 PNT 代币作为其 Solver 拍卖市场的激励代币）。
目前的 Intent 实质将下层的复杂细节屏蔽，抽象出了更高的一层，这样的一种带有 TCP/IP 协议性质的分层式设计，对于全链无缝互操作下的用户体验和开发者体验都是必要条件。
迎接账号抽象的大规模采用
当我们把以太坊生态内的 4337 框架从各个角度优化之后，同时也推进了横跨以太坊和非以太坊生态全链无缝互操作，为了支持账号抽象的大规模采用，我们觉得依然需要一个横跨供给侧和需求侧的产品。能够降低终端用户使用各类 Web3 产品服务的同时，聚焦服务开发者，降低开发者门槛。
这里面扮演这个角色的最佳产品之一是 Particle Network 的模块化的账户抽象钱包即服务 （Modular Smart Wallet-as-as-Service) 产品：
- 该服务提供一套易于使用的 API，使开发者能够轻松地在其应用程序中集成模块化的账户抽象功能；
- 开发者可以使用该服务创建和管理全链账户，进行跨链交互，并使用统一的手续费支付方式；
- 这样的服务将为开发者提供更灵活和便捷的方式来构建多链应用程序，并促进账号抽象的广泛采用。
除了以上开发者友好的特性以外，最重要的特点是 Particle Network 的模块化账户抽象钱包即服务（Modular Smart Wallet-as-as-Service) 产品构建了一个基于签名计算，面向开发者的账户抽象领域的开放生态，除了提供自研的账户抽象产品模块以外，整合了各类型的账户抽象产品与服务，能够快速推进整个账户抽象领域各个开发者的产品和服务的采纳度。
让技术服务于需求，在解决了 ERC-4337 框架的各个角度的限制之后，开发者体验的提升将促使更多拥有优秀用户体验的产品产生，加速 Web3 行业从加密朋克友好的金融行业转变为大众友好的消费级行业。
免责声明：作为区块链信息平台，本站所发布文章仅代表作者及嘉宾个人观点，与 Web3Caff 立场无关。本文内容仅用于信息分享，均不构成任何投资建议及要约，并请您遵守所在国家或地区的相关法律法规。
