在我们的上一篇博文中，我们主张使用 ERC-7579 而不是 ERC-6900 作为模块化智能账户的标准。这篇博文引发了许多有益的讨论，包括来自 Alchemy 的 Noam 的一份详细回应。
但你可能会想，为什么 7579 和 6900 会有差异呢？也就是说，为什么两组理性和聪明的人会在技术问题上产生如此强烈的意见分歧？难道不应该每个人都得出相同且正确的结论吗？
在这篇文章中，我们将展示 7579 和 6900 的差异源于理念上的根本区别。也就是说，没有严格的对与错 —— 这只是一个视角问题。是的，就像生活中的大多数事情一样。
首先，让我们研究一个最根本的问题：智能账户插件究竟是做什么的？
智能账户插件的每一个用例都必须回答三个问题：谁、何时、以及什么。
- 谁被授权执行此操作？
- 何时（即在什么条件下）他们可以执行此操作？
- 什么是具体的操作？
以下是通过这个视角看待用例的一些例子：
- NFT 订阅：DApp（谁）可以每月一次为我铸造一个 NFT（什么）（何时）。
- 限价订单：DApp（谁）可以在价格达到给定点时为我发送交易（什么）（何时）。
- 社交恢复：一组监护人（谁）可以随时为我更改账户签名者（什么）（何时）。
在模块化智能账户的术语中，谁是 validator，何时是 hook（我们在 Kernel 中也称之为“策略”），而什么是 executor。但请注意，这条界线并非完全明确 —— 例如，可以以某种方式实现 validator，使其同时回答谁和何时。但总的来说，我们认为一个设计良好的插件只会回答这三个问题中的一个，以保持范围的小而清晰。
这就引出了我们要问的问题：如果一个插件只回答这三个问题中的一个，那么谁负责将三个插件组合起来以解决一个用例？
这正是 7579 和 6900 设计理念的关键区别所在：
- ERC-6900 认为，插件开发者有责任决定插件如何组合在一起。
- ERC-7579 认为，插件用户有责任决定插件如何组合在一起。
当你在 6900 中开发一个插件时，你需要指定一个“manifest”，其中列出了插件之间的依赖关系。例如，如果你正在开发一个社交恢复插件，你可能会在 manifest 中指定，更新账户签名者的 executor（什么）必须通过监护人插件（谁）进行验证。
在 7579 中，插件被开发时不需要指定任何此类依赖关系。因此，插件开发者将开发 executor（什么），而另一个开发者可能会开发 validator（谁），只有当用户安装插件时，他们才会指定 executor 必须通过 validator 进行验证。请注意，当我们在这里说“插件用户”时，我们指的不是最终用户（人）—— 在实践中，通常是 DApp 作为“插件用户”将不同的插件组合在一起，供用户安装到他们的账户上。
这就是为什么你可能会听到“ERC-6900 是 ERC-7579 加上权限”的说法，这与事实相差不远。“权限”部分指的是插件如何绑定在一起，即执行插件如何与验证插件相关联。ERC-6900 对权限有明确的看法，而 ERC-7579 则将权限排除在范围之外。
这取决于你优先考虑什么。当每个插件指定其自身的依赖关系时，你将获得更高的可移植性，因为 DApp 不需要决定插件如何组合在一起。但是，插件的组合性会降低，因为你无法混合搭配不同的“谁”、“何时”和“什么”插件，因为它们具有硬编码的依赖关系。
在 Kernel 中，我们选择可组合的插件，因为我们相信：
- 它可以让插件开发者的生活更轻松，因为他们可以开发更小、更简单的插件。
- 它可以赋予用户和 DApp 更多的权力，因为他们可以混合搭配插件来解决原始插件开发者可能没有想到的用例。
例如，考虑 Kernel 的 签名者（谁）和 策略（何时）插件。你可以将任何签名者与任何策略匹配，因此你可以启用的用例数量是指数级的。例如：
- 将 ECDSA 签名者与 gas 策略一起使用。
- 将 WebAuthn 签名者与 gas 策略一起使用。
- 将 ECDSA 签名者与 gas 策略 + 合约策略一起使用。
- 将 WebAuthn 签名者与执行策略一起使用。
- ……
通过不硬编码插件之间的任何依赖关系，我们允许 DApp 和钱包开发者随意组合插件。使用 ZeroDev SDK，代码如下所示：
Copyconst account = await toKernelAccount({
signer: webauthnSigner,
policies: [contractPolicy, gasPolicy]
})
换句话说，使用 Kernel 和 ERC-7579，你可以在“运行时”（当使用插件时）组合插件，而不是在“编译时”（当构建插件时）组合插件。
重要的是要注意，ERC-6900 和 ERC-7579 都在积极发展中，因此本文中的某些细节在你阅读时可能已过时。也就是说，我们确实认为这种理念上的差异可能会持续存在，这将推动双方在继续改进标准时做出的设计决策。
在某种程度上，这场辩论本身就证明了设计智能账户的“正确”方式远未确定，因此在某种意义上，目前强制执行标准是否真的有帮助甚至还不清楚。这就是为什么我们推动像 ERC-7579 这样的小标准，而不是像 ERC-6900 这样的大标准，以便我们为项目保留试验和创新的空间，最终这将为下一个十亿 Web3 用户带来更好的智能账户。
