介绍
从外部拥有账户（EOA）转向智能合约账户（SCA）的转变正逐渐加速，已被包括Vitalik在内的许多热心人士所接受。尽管大家对此感到兴奋，但SCA的普及程度并不如EOA。其中的关键挑战包括熊市带来的问题、迁移的担忧、签名问题、气体开销以及最关键的工程难题。
账户抽象（AA）最显著的优势是能够使用代码自定义功能。然而，一个主要的工程挑战是AA功能的非互操作性，这种碎片化阻碍了集成，并为厂商锁定打开了大门。此外，确保安全性的同时进行升级和组合功能可能相当复杂。
进入模块化账户抽象，作为更广泛AA运动的一个子集，这种创新方法可以将智能账户与其定制功能分离。其目标是创建一个模块化结构，以开发具有多样功能的安全、无缝集成的钱包。未来，它可以实现一个自由的智能合约账户“应用商店”，使钱包和dApp不再专注于构建功能，而是专注于用户体验。
阅读本文后，读者将获得以下方面的洞见：
什么是模块化账户抽象
账户如何与模块互动
调用模块的顺序是什么
如何以开放的方式查找和验证模块
对AA的简要回顾
智能合约账户（SCA）景观
传统的外部拥有账户（EOA）带来了许多挑战，如种子短语、气体、跨链和多重交易。我们从未打算引入复杂性，但事实上，区块链对大众来说并不是一项简单的游戏。
账户抽象（AA）利用智能合约账户，允许可编程验证和执行，用户能够一次性批准一系列交易，而不是签署并广播每一个，还能实现更多功能。它为用户体验（例如气体抽象和会话密钥）、成本（例如批量交易）和安全性（例如社交恢复、多重签名）带来了好处。目前，有两种实现账户抽象的方式：
协议层：一些协议本身提供了原生账户抽象支持，比如ZKsync交易无论是来自EOA还是SCA，都遵循相同的流程，使用单一的内存池和交易流程支持AA，而Starknet已经去除了EOA，所有账户都是SCA，它们拥有像Argent这样的原生智能合约钱包。
合约层：对于以太坊及其等效的L2s，ERC4337引入了一个单独的交易入口点，支持AA而无需改变共识层。像Stackup、Alchemy、Etherspot、Biconomy、Candide和Plimico等项目正在构建打包基础设施，还有更多像Safe、Zerodev、Etherspot和Biconomy等正在构建栈和SDK。
👉 如果你不熟悉AA或ERC4337，请查看SevenX之前的研究。
采用 SCA 的困境
账户抽象（AA）这个话题自 2015 年以来就一直在讨论，今年 ERC4337 进一步将其推向了人们的视线。然而，已部署的智能合约账户数量与 EOA 相比仍然相形见绌。
让我们深入研究这个困境：
- 让我们深入这个困境：
- 熊市影响：
- 尽管AA引入了诸如无缝登录和气体抽象等好处，但目前的熊市主要由受过教育的EOA用户组成，而不是新用户，因此dApp和钱包没有动力。即便如此，领先的应用仍在逐步采用AA，比如Cyberconnect仅凭借其AA系统和无气体解决方案，一个月就推动了大约360,000次UserOps（AA的交易）。
- 迁移障碍：
- 对于已经积累了用户并在EOA中存储资产的钱包和应用来说，安全方便地迁移资产仍然是一个挑战。尽管如此，像EIP-7377这样的倡议允许EOA发起一次性迁移交易。
- 签名问题：
- 智能合约本身自然无法签名消息，因为它不像EOA那样拥有私钥。像ERC1271这样的努力使之成为可能，但在第一笔交易之前，消息签名将无法工作，这对于使用反事实部署的钱包提出了挑战。Ambire提出的ERC-6492是ERC-1271的向后兼容继任者，可能解决了之前的问题。
- 气体开销：
- 部署、模拟和执行SCA的成本比标准EOA高。这成为了采纳的阻碍。然而，已经进行了几项测试，如将账户创建与用户操作解耦，以及正在考虑取消账户盐和存在检查，以降低这些成本。
- 工程难题：
- ERC-4337团队已经建立了eth-infinitism仓库，为开发者提供基础实现。然而，当我们分支出更多针对不同用例的细微或特定功能时，集成和解码变得具有挑战性。
在本文中，我们将深入探讨第五个问题：工程难题：
🤔️
模块化智能合约账户解决工程难题
进一步阐述工程难点：
- 碎片化： \
现在可以通过多种方式启用功能，无论是通过特定的 SCA 本身还是通过独立的插件系统。每个平台都遵循其标准，迫使开发人员决定支持哪些平台。这会导致潜在的平台锁定或冗余工作。 - 安全： \
虽然帐户和功能之间的灵活性提供了优势，但它可能会加剧安全问题。功能可能会受到集体审核，但缺乏独立评估可能会增加帐户漏洞的风险。 - 可升级性： \
随着功能的发展，保留添加、替换或删除功能的能力非常重要。每次更新时重新部署现有功能会带来复杂性。
为了在这些水域航行，我们需要可升级合约 确保安全高效的升级，可重复使用的核心 提高整体开发效率，以及标准化接口 确保合约账户能够在不同前端之间顺利过渡。
这些术语集中在一个单一的概念上：构建模块化帐户抽象架构（模块化 AA）。
模块化 AA 是更广泛的 AA 运动中的一个利基市场，该运动设想模块化智能帐户，为用户进行定制，并使开发人员能够以最少的限制无缝增强功能。
然而，在任何行业，建立和推广新标准都是一个巨大的挑战。在每个人都确定主要解决方案之前，初始阶段可能会经历许多不同的解决方案。然而，令人鼓舞的是看到那些致力于账户抽象的人们，无论是 4337 SDK、钱包开发人员、基础设施团队还是协议设计人员，都齐心协力加快这一进程。
模块化结构：主账户和模块
账户如何调用模块实现功能
委托调用和代理合约
外部呼叫和委托呼叫：
关于 delegateCall
尽管委托调用 类似于称呼，但它不是在自己的上下文中执行目标合约，而是在调用合约的当前状态的上下文中执行它。这意味着目标合约所做的任何状态更改都会对调用合约的存储进行。
代理合约和 delegateCall
要实现可组合、可升级的结构，需要一个基础知识，称为“代理合约”。
- 代理合约：普通合约存储其逻辑和状态，部署后无法更新。 A代理合同 使用委托调用 到另一份合同。通过引用实现函数，它在代理合约的当前状态下执行它。
- 使用案例：虽然代理合约保持不变，但您可以在代理后面部署新的实现。代理合约用于可升级性，并且在公共区块链上部署和维护成本更低。
安全架构
Safe架构
什么是Safe:
Safe是领先的模块化智能账户基础设施，旨在提供经过实战测试的安全性和灵活性，它赋予开发者创建多样化应用程序和钱包的能力。值得注意的是，许多团队正在Safe之上构建或受其启发。Biconomy通过扩展Safe，加入了原生4337和1/1多重签名，推出了其账户。Safe部署超过164,000个合约并锁定了超过307亿美元的价值，毫无疑问，它是该领域的佼佼者。
Safe的结构是什么
Safe账户合约：主代理合约（有状态）
Safe账户是一个代理合约，因为它通过delegatecall调用单例合约。Safe账户包含所有者、阈值和实现地址，这些都作为代理的变量设置，因此定义了其状态。
单例合约：集成中心（无状态）
单例服务于Safe账户，并集成并定义不同的集成，包括插件、钩子、函数处理器和签名验证器。
模块合约：自定义逻辑和特性：
模块功能强大。作为模块化类型的插件可以定义不同的特性，如支付流、恢复机制和会话密钥，并可以通过获取链下数据在web2和web3之间架起桥梁。其他模块如安全防护的钩子和响应任何指令的函数处理器。
采用Safe时会发生什么：
可升级合约：
每当引入新插件时，需要部署一个新的单例。用户保留升级到所需单例版本的自主权，以符合他们的偏好和要求。
可组合和可重用模块：
插件的模块化特性使开发者能够独立制定功能。然后他们可以自由选择和组合这些插件，基于他们的用例，培育出高度定制化的方法。
ERC-2535 钻石代理
ERC2535钻石架构
关于ERC2535，钻石代理：
ERC2535标准化了一种名为“钻石”的模块化智能合约系统，该系统可在部署后进行升级/扩展，并且几乎没有大小限制。到目前为止，许多团队受到了它的启发，例如Zerodev的Kernel和Soul Wallet的实验。
什么是钻石结构：
钻石合约：主代理合约（有状态）钻石是一个代理合约，它使用delegatecall从其实现中调用功能。
模块/插件/面切合约：自定义逻辑和功能（无状态）所谓的模块或面切是一个无状态合约，可以将其功能部署到一个或多个钻石上。它们是独立的、相互独立的合约，可以共享内部函数、库和状态变量。
当我们采用钻石时会发生什么：
可升级合约：钻石提供了一种系统化的方式来隔离不同的插件，并将它们连接在一起，彼此之间共享数据，还可以直接使用diamondCut函数添加/替换/移除任何插件。随着时间的推移，可以向钻石中添加的插件数量没有限制。
模块化和可重用的插件：部署的插件可以被任意数量的钻石使用，极大地降低了部署成本。
安全智能账户与钻石方式的区别：
安全智能账户”（Safe）和”钻石方式”（Diamond）架构之间存在许多相似之处，两者都依赖于其核心的代理合约并引用逻辑合约来实现可升级性和模块化。
然而，它们之间的主要区别在于逻辑合约的处理方式：
灵活性 ：
在”安全智能账户”中，当启用新插件时，需要重新部署其 Singleton 合约以实现代理中的更改。
相比之下，”钻石方式”可以直接通过切割钻石来实现代理中的函数更改。这种方法的不同意味着”安全智能账户”保留了更高程度的控制，而”钻石方式”引入了更强的灵活性和模块化。
安全性 ：
委托调用在两种架构中都被使用，允许外部代码操作主合约的存储。
在”安全智能账户”中，委托调用指向单个逻辑合约，而”钻石方式”采用委托调用跨多个模块合约-插件。因此，”钻石方式”中恶意插件有可能覆盖另一个插件，引入存储冲突的风险，从而损害代理的完整性。
成本 ：
“钻石方式”的固有灵活性与增加的安全问题同时存在，这增加了成本因素，因为每次添加新插件都需要进行全面审核。
关键是确保这些插件不会干扰彼此的功能，这对于努力维持强大安全标准的中小型企业来说可能是一个挑战。
总之，”安全智能账户方法”和”钻石方法”是两种不同的代理和模块化架构示例。如何平衡灵活性和安全性至关重要，这两种方法可能会相互补充，取决于特定应用的需求和风险偏好。
模块顺序：验证器（Validator）、执行器（Executor）和钩子（hook）
调用模块的顺序是怎样的
让我们通过介绍ERC6900来扩展我们的讨论，这是Alchemy团队提出的一种标准，受到Diamond的启发，并专门为ERC-4337量身定制。它通过提供通用接口来解决智能账户中的模块化挑战，并协调插件与钱包开发者之间的努力。
说到AA的交易流程，主要有三个流程：验证器（Validator）、执行器（Executor）和钩子（hook）。正如我们前面所讨论的，这些步骤都可以通过使用代理帐户调用模块来管理。虽然不同的项目可能使用不同的名称，但掌握相似的底层逻辑很重要。
不同设计中的函数名称
- 验证：确保帐户调用者的真实性和权限。
- 执行：执行帐户允许的任何自定义逻辑。
- 钩子：充当在另一个函数之前或之后运行的模块。它可以修改状态或导致整个调用撤销。
ERC6900
根据不同的逻辑分离模块至关重要。标准化方法应该规定如何编写智能合约帐户的验证、执行和挂钩函数。无论是 Safe 还是 ERC6900，标准化都有助于减少特定于某些实施或生态系统的独特开发工作的需求，并防止供应商锁定。
模块发现与安全
如何以开放的方式查找和验证模块
目前逐渐流行的一种解决方案是创建一个平台，让用户能够发现可验证的模块，我们可以称之为“注册中心”。这个注册中心的功能类似于“应用商店”，旨在培育一个简化但充满活力的模块化市场。
Safe{Core} 协议
Safe{Core} 协议
Safe{Core} 协议是一种开源的、可互操作的智能合约账户协议，旨在提高各种供应商和开发者的可访问性，同时通过明确的标准和规则保持强大的安全性。
账户：在 Safe{Core} 协议中，账户的概念是灵活的，不绑定于特定的实现。这使得多种账户服务提供商能够参与其中。
管理者：管理者作为账户、注册中心和模块之间的协调者。它还负责作为权限层的安全性。
注册中心：注册中心定义安全属性，并强制执行像 ERC6900 这样的标准，旨在为模块创造一个开放的“应用商店”环境，以实现可发现性和安全性。
模块：模块处理功能，并有各种初始类型，包括插件、钩子、签名验证器和功能处理器。这些都是开放给开发者的，前提是他们满足既定的标准。
Rhinestone设计
Rhinestone设计的过程如下：
创建模式定义：模式是为认证所需的预定义数据结构。企业可以根据其特定用例自定义模式。
基于模式创建模块：智能合约将作为模块进行注册，获取字节码并选择一个模式ID。这些数据随后存储在注册表中。
为模块获取认证：认证者或审计员可以基于模式为模块提供认证。这些认证可以包括一个独特的标识符（UID），以及对其他认证的引用以建立链接。它们可以在区块链上传播，并验证目标链是否满足特定阈值。
使用解析器实现复杂逻辑：可选设置的解析器开始发挥作用。它们可以在模块创建、认证建立和撤销时被调用。这些解析器允许开发者在保持认证结构的同时融入复杂和多样的逻辑。
用户友好的查询访问：查询为用户提供了一种从前端访问安全信息的方式。
尽管这个模式目前还处于初期阶段，但它具有建立去中心化和协作标准的潜力。他们的注册表使开发者能够注册他们的模块，审计员可以验证其安全性，而钱包可以轻松地定位模块并验证其认证信息。未来可能有几种用途：
认证者：像Safe这样的可信实体可以与Rhinestone合作，充当内部模块的认证者。同时，独立的认证者也可以加入。
模块开发者：随着开放市场的形成，模块开发者可以通过注册表将其工作货币化。
用户：通过用户友好的界面，如钱包或dApps，用户可以查看模块信息，并将信任委托给不同的认证者。
“模块注册表”的概念为插件和模块开发者开辟了货币化的途径。它还可能为“模块市场”的建立铺平道路。其中一些方面可能由Safe团队监管，而其他方面可能表现为去中心化市场，邀请贡献并为所有人提供透明的审计记录。通过这种方式，我们可以避免供应商锁定，并通过增强的用户体验支持EVM的扩展，吸引更广泛的受众。
尽管这些方法保证了单个模块的安全性，但智能合约账户的更广泛安全性并不是毫无风险。合并合法模块并证明它们没有存储冲突可能是一个挑战，强调了钱包或AA基础设施在解决此类问题上的重要性。
结束语
通过采用模块化的智能合约账户栈，钱包提供商和去中心化应用（dApps）能够降低技术维护的复杂性。同时，外部模块开发者有机会提供专业服务，以满足不同需求。然而，面临的挑战包括如何在灵活性和安全性之间取得平衡，推动模块化标准的发展，以及实施标准化接口，以便用户能够轻松升级和修改他们的智能账户。
然而，模块化的智能合约账户（SCA）只是推广的一部分。为了充分发挥SCA的潜力，还需要来自第二层解决方案的额外协议支持，包括健壮的捆绑器基础设施和点对点交易池、更经济有效的SCA签名机制、跨链SCA同步和管理，以及开发用户友好的界面。
展望未来，我们可以设想一个广泛参与的未来，其中涌现出一些有趣的问题：一旦SCA订单流变得足够有利可图，传统的矿工可提取价值（MEV）机制如何进入该领域，构建捆绑器并捕获价值？当基础设施成熟时，账户抽象（AA）如何成为支持“基于意图”的交易的基础层服务？请继续关注；这一领域正在以每分钟的速度迅速发展演变。
声明：
- 本文转载自[SevenX Ventures ]，著作权归属原作者[SevenX Ventures ]，如对转载有异议，请联系Gate Learn团队，团队会根据相关流程尽速处理。
- 免责声明：本文所表达的观点和意见仅代表作者个人观点，不构成任何投资建议。
- 文章其他语言版本由Gate Learn团队翻译， 在未提及Gate.io的情况下不得复制、传播或抄袭经翻译文章。
Artigos relacionados
