资源锁定Hook

模块化智能账户的新构建块

互操作性就是所有资源锁。过去是，现在是，将来也是。自从 DeFi 和 Token Bridge 出现以来，托管合约一直被用作链上借贷、借款和跨链流动性的基础组件。托管合约就是资源锁。它们通过限制提款和索赔条件，在维护自我托管的同时，保护交易对手免受用户出尔反尔的影响。

链抽象为资源锁定引入了一种新的形式：由账户抽象驱动的账户原生资源锁。这些锁能够实现低延迟和原子化的跨链意图——无需桥，无需 gas。然而，账户原生资源锁可以实现更多功能。

本文介绍了资源锁的不同形式，并深入探讨了 Rhinestone 如何旨在为任何新兴产品用例（而不仅仅是跨链意图）实现可组合的资源锁。

概要

在 2025 年第一季度，Rhinestone 将推出一种新的账户原生资源锁系统。 其核心是 资源锁 Hook。该模块使任何专门的执行层都能够与 ERC-7579 账户集成，并通过单个签名无缝执行任何意图。

现有的账户原生资源锁模型（联合签名人和托管）有许多权衡，要么会降低用户体验，要么会损害用户智能账户的可组合性和互操作性。资源锁 Hook 结合了两者的优点，提供了一种信任最小化、高度可组合且可互操作的资源锁。我们相信，这种方法将成为许多应用程序的基础，这些应用程序可以与单个锁定的余额无缝集成。资金没有分离，也不需要共同签署所有交易的根签名验证器模块。

什么是账户原生资源锁？

账户原生资源锁（以下简称“资源锁”）利用智能账户为用户账户带来链上保证，为用户通过单个签名表达的任何类型的执行或意图创建出尔反尔和最终性保护。用户选择在指定条件下进行审查，作为外部交易对手的促成因素。如果 Session Key 是正向权限——即用户授予临时和有范围密钥的能力——那么资源锁是负向权限，用户选择有条件地进行审查，从而让其他参与者保证用户无法执行某些操作。

资源锁允许用户向专门的执行层表达任何意图，而无需严格要求原子化结算。这使得执行速度非常快，并且从用户的角度来看，感觉是原子化的。然而，负向权限可以用于许多新的应用程序，例如账户原生信用系统（其中抵押品被资源锁定）、具有闪电般执行速度和账户上延迟结算的链下订单簿等等。如果资源锁能够以通用和可组合的方式构建，它们就可以成为智能账户上任何开发人员构建的关键乐高积木。

当前的资源锁定形式

目前有两种流行的资源锁定形式。每种形式都有其优点和缺点。

• 共同签名人 (Co-signer)：链下系统仅在交易不违反预先向交易对手做出的保证时才共同签署所有交易。
• 托管 (Escrow)：资金被转移到一个单独的合约中，用户的访问受到限制，以便为外部方提供保证。

共同签名人 (Co-signer)

在智能账户的上下文中，共同签名人作为账户上的（签名）验证器模块安装。此验证器模块可以是 Passkey 或 ECDSA 验证器，但重要的是，只有当用户和共同签名系统提供有效签名时，验证才会通过。资源锁发生在链下系统中，该系统根据一个会计模型发出签名，该模型监听用户意图、记录用户的资产负债，并且仅在某意图不违反用户已经做出的承诺时才签名。

有许多方法可以运行这些信任要求较低的共同签名人实体，例如 MPC 和 TEE，但这不是本文的重点。

共同签名人方法的优势

该方法的优点是，管理资源锁的复杂性被转移到链下，并且来自账户的每个用户操作（跨链意图与否）都流经此根验证器，因此更容易管理可能允许用户重复花费系统的安全威胁。例如，如果共同签名人认为账户升级和模块安装/卸载交易对未决承诺构成威胁，它可以阻止所有此类交易。这种方法还确保资产不会被分离或包装到一个具有受限提款条件的新合约中——这是读取和跟踪与用户账户关联的余额的应用程序的一项 生活质量 功能。

共同签名人方法的缺点

共同签名人方法的缺点是，来自账户的每笔交易都必须由此链下系统审查和验证。这对某些人来说是一个很高的信任门槛，并且可能会引入审查和活跃性风险，但链上紧急出口可以补救这一点。所有 userOp 验证都通过共同签名人这一更重要的外部性在于，它限制了智能账户的可组合性。安装在账户上的所有验证器模块都必须与共同签名人集成。与这些验证器模块的每次交互也必须与共同签名人集成（以便共同签名人不会对通过账户的请求视而不见）。这对于在智能账户上构建并希望利用模块启用的功能的任何开发人员来说都是非常具有限制性的。

托管 (Escrow)

托管模型将资源锁定机制转移到链上。用户的资产被转移到托管合约，该合约具有针对用户的有范围的提款条件，以及针对代表用户执行任何操作的交易对手的有范围的索赔条件。由 Uniswap 的 0age 开发的 The Compact 就是一个例子。

托管方法的优势

托管方法的核心好处是，它将资源锁定隔离到一个专门构建的合约中。构建智能账户是为了让用户对其资产拥有最大的访问权限和控制权。智能账户内的资源锁定需要在链上具有更大的复杂性，以确保不诚实的用户无法重复花费该系统。在托管中锁定资产还可以保持智能账户的最大可组合性和互操作性。例如，对安装在账户上的验证器模块没有任何限制；像 Smart Sessions 这样的创新将继续开箱即用。最后，托管方法在信任模型方面具有灵活性。用户无需锁定所有资金，只需锁定链抽象意图或其他启用资源锁的应用程序所需的资产。

托管方法的缺点

托管需要从智能账户执行额外的存款步骤。必须抽象此步骤，才能使此模型感觉“账户原生”。随着时间的推移，用户将开始期望他们的整个余额都被链抽象化，并且要做到这一点，他们的整个余额必须永久驻留在托管中。这需要在资金进入账户后立即自动存入托管，并同步智能账户和托管之间的有效签名（以确保用户在执行后但在索赔事件之前不能通过使签名无效来欺骗solver）。本质上，托管成为账户，而智能账户则成为特权签名者。这对模块化智能账户 x 资源锁的设计空间产生了连锁反应，而这些设计空间尚未得到充分探索（至少在公共领域是这样）。

可以说，在托管模型下读取应用程序数据的问题比共同签名人方法更糟糕（至少在短期内）。虽然在两种方法下，总的可花费余额都是错误的（应用程序目前不会查询多个链以获取余额），但在托管方法中，现有 Token 的新包装版本必须被广泛认可为等效，或者像索引器这样的服务必须知道这些托管。

介绍：资源锁 Hook

理想的资源锁模型兼顾了两者的优点。

• 灵活的信任模型
• 没有资产分离
• 维护智能账户的可组合性和互操作性

在 Rhinestone，我们正在开发一种新的资源锁模型，该模型利用智能账户上的 Hook 模块。Hook 模块通过Hook在执行前或执行后并强制执行针对执行的条件或任何自定义逻辑来增强智能账户的执行流程。资源锁 Hook 是一个智能账户模块，它Hook到每次执行并检查一个简单的不变式：执行、执行期间进行的任何批准是否会将账户余额减少到低于资源锁定的金额？如果为假，则资源锁 Hook 允许交易通过。如果为真，则交易只有在来自链下定序器的签名的情况下才能通过，该定序器执行与上面讨论的共同签名人类似的功能（或者在 The Compact 的情况下为“分配器”）。

灵活的信任模型

资源锁 Hook 允许用户永久锁定所有资产、部分锁定或及时锁定。这提供了一系列完整的选项，从具有最纯净 UX 的更高信任度（所有交易都需要签名）到具有较慢执行速度的低信任度。该模块仅在模块认为交易违反了资源锁时才请求链下定序器的签名。共同签名行为仅限于锁定的资金，并具有退出系统的链上紧急出口。

没有资产分离

这种新的资源锁方法继承了托管的灵活信任模型，而不会将用户的资金分离到新的合约中。尽管可以争辩说这是语义上的——例如，ERC-20 Token 存储在具有所有者地址和余额的 ERC-20 合约中——但确保采用用于准确读取和跟踪用户余额的新Token包装标准仍然是一个短期的协调问题。

可组合性和互操作性

资源锁 Hook 不会干扰模块化智能账户的标准操作。用户可以使用任何模块扩展账户，而不会受到共同签名机制的干扰。这包括所有核心 ERC-7579 模块、Smart Sessions 和未来的任何创新，例如 Biconomy 的 MEE、ZK Emails 恢复模块或 Superforms DeFi 自动化模块。

对链下排序的需求

所有资源锁定解决方案都需要一个链下会计系统，以确保用户不能重复花费交易对手。为了使资源锁定系统真正可组合和可互操作，锁定的资金应该可以随时用于任何专门的执行层，而不是与一个用例结婚。例如，考虑一个利用资源锁的简单借记卡提案。用户应该期望他们的资金同样可以用于通过 Visa 支付轨道 IRL 花费，也可以在任何网络上进行跨链花费。他们不应该将资产隔离到特定于用例的锁中。要做到这一点，链上和链下锁定系统必须是模块化和可组合的——更多关于这一点即将推出^TM。

结论

资源锁定和链抽象的解决方案空间正在迅速扩大。资源锁 Hook 改进了现有模型，为开发人员提供了一个与现有智能账户功能和基础设施完全兼容的可组合构建块。在 2025 年第一季度，资源锁 Hook 和随附的基础组件将启动，以链抽象化任何 ERC-7579 智能账户。该系统已经启动并准备好让早期采用者使用。 联系以获取更多信息。

关注我们

• 在 X 上 @ Rhinestonewtf
• 通过电子邮件 gm@rhinestone.wtf
• 查看我们的 网站 和 文档

• 原文链接： blog.rhinestone.wtf/reso...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～