使用 ERC-7579 模块的全链智能账户

本文介绍了Rhinestone团队在WalletConnect Hacks 2中构建的跨链状态同步和资产花费原型,旨在为模块化智能账户提供理想的跨链体验。

跨链状态同步和资产花费原型(链抽象)

TL;DR

WalletConnect Hacks #2 期间,我们构建了一个原型,以演示模块化智能账户的理想跨链体验。具体来说,我们专注于两个主题:1) 跨链状态同步,允许跨链同步模块配置;2) 通过资源锁定模块实现的链抽象(或“余额抽象”),其灵感来自 CAKEMagicSpend++ 推广的框架。

对于跨链账户同步,我们利用 Scroll 的 Keystore,允许模块从另一个链读取状态,以确保其配置是最新的。对于链抽象,我们特别关注权限层和资源锁定。我们构建了一个验证器模块,一旦安装到帐户上,就可以在另一个链上访问资金以进行即时交易——无需托管合约,因此,无需用户隔离资金。对于求解器和结算层,我们利用 paymaster 作为“求解器”来简化此组件。这些功能已集成到 Rhinestone Wallet 中,以创建一个理想的 omnichain 智能钱包的工作原型。

在接下来的几个月里,我们将迭代此 omnichain 智能账户设置,并与链抽象堆栈中的其他参与者合作,以使工作原型投入生产。如果你是希望集成链抽象的应用程序或钱包开发人员,请联系我们

演示

下面,我们演示了 Hack 的链抽象组件。该记录显示了一个简单的流程,用户将Token发送到 Base 上的地址(Base Sepolia),但使用的是 Ethereum L1 上的资金(Sepolia)。没有桥。求解器(在本例中是一个简单的预付 paymaster)在 Base 上预付所需的Token,并在 L1 上收回余额。通过 L1 账户上的资源锁启用了两个单链交易。

动机

跨链状态同步是一个众所周知的智能合约问题。对于智能账户的直接影响是,跨链 UX 非常糟糕,并且可以说是 EOA 具有明显优势的唯一领域之一。当涉及到 跨多个链管理智能钱包的密钥 时,状态同步尤其具有挑战性。对于模块化智能账户,状态同步问题会进一步放大——即,确保用户的模块集和配置随着他们从一个链移动到下一个链而随之移动。

然而,随着 L2 的激增和以太坊生态系统(应用程序和流动性)的持续分裂,跨链 UX 为智能账户提供了一个机会,使其在另一个垂直领域超越 EOA。对于 EOA,用户必须 手动管理网络、gas Token、桥接等。智能账户提供了自动化和抽象所有这些的工具,同时仍然为用户维护数字自决权。

今年早些时候,我们探索了使用智能账户模块和 paymaster 来为用户抽象掉任何网络上的 gas,同时始终从用户的“主链”提供资金。这将把“主链智能账户”转变为用户在所有链上的个人 paymaster。MagicSpend++ 更进一步,允许完全的交易赞助。但是,它引入了一个托管合约,并要求用户将资金与他们的主账户隔离。

几种链抽象框架采用这种方法来消除重复花费的风险。有些还要求用户等待区块最终确认后才能在另一个链上访问资金。这是一种不佳的用户体验。这就像过去在出国旅行之前需要一张预装现金的专用 FX / 旅行借记卡。

在 WalletConnect Hacks #2 期间,我们的目标是构建一组模块的原型,这些模块允许使用具有状态同步和链抽象的 omnichain 账户(通过与新兴的链抽象框架集成),同时消除重复花费风险、区块重组风险以及托管资金的需求。

我们构建的内容概述

智能账户状态同步

在 Safe{Con}2 上,Scroll 宣布了 Keystore,这是智能钱包基础设施中的一个新组件,它分离了验证逻辑和资产持有量,这意味着资产可以分散在多个地方,而验证交易的代码位于一个地方(Keystore)。

在 WalletConnect Hacks #2 期间,我们构建了一个 ERC-7579 验证器模块,该模块利用 Keystore 并从另一个链读取状态(使用 L1SLOAD)。首先在 ETH Sepolia 上设置了一个智能账户,并安装了一个可拥有的 (ECDSA) 验证器。然后在 Scroll 测试网上配置了第二个账户,其中包含一个从 Sepolia 上的可拥有验证器读取状态的验证器。

图 1:智能账户状态同步

Omnichain 资产模块(即资源锁)

最近的框架(如 CAKE 和 Magicspend++)提出了一种跨链解决方案,该解决方案利用求解器网络来赞助目标链上的交易,并从源链上的用户提取资金。这 类似于 (Transfer)Wise 跨境支付。用户体验到“跨链”交易,但实际上,这是两个“本地”交易,一个是赞助实体在目标链上向目标接收者进行的交易,另一个是赞助实体在源链上收回资金进行的交易。

这里出现了两个挑战:重复花费和区块重组风险。消除这些风险的一种方法是通过托管合约。用户将资金存入托管,一旦区块达到最终确认,资金就可以跨链使用。用户从托管中提款的时间锁定可以防止重复花费。这种方法的缺点是资金隔离以及用户从零过渡到跨链访问资金的速度。

我们开发了一种使用带有共同签名者的 ERC-7579 验证器的替代方法。此验证器对帐户执行所需资金(例如,100 USDC)的资源锁定,并确保在资源锁定期间不能使用任何其他验证器,从而消除重复花费和区块重组风险。

图 2:余额抽象

求解器和结算层

为了本次演示的目的,我们构建了一个简单的 paymaster 实现,以赞助目标链上的完整交易。展望未来,我们将寻求与构建在求解器和结算层的项目合作,以完成链抽象产品。

后续步骤

我们计划继续开发支持链抽象的智能账户模块。当前原型存在一些已知的缺点,我们打算解决:

  1. 我们开发的共同签名者模块并非万无一失。此后,我们发现允许帐户被后门利用的漏洞和攻击媒介,必须在将此类方法投入生产之前加以解决。
  2. 引入共同签名者来解决重复花费和区块最终确认风险会创建一个新的信任层。我们正在积极探索最大限度地减少这些信任要求的方法。
  3. 在成功的跨链意图实现后,需要跨链证明来协调对求解器的补偿。至少可以说,这些证明系统还处于起步阶段。
  4. 该原型是为模块化智能账户构建的,不适用于 EOA,但 post-EIP-7702 之后也不起作用。我们的目标是在未来的迭代中解决这个问题。

多个框架已经广泛探索了整个链抽象堆栈(EverclearCAKEMagicspend++)。然而,在深入研究权限层、不同的方法和权衡时,很少有研究被分享。当我们考虑选择空间时,我们打算公开我们的研究。

如果你有兴趣合作或将链抽象集成到你的应用程序中,我们很乐意聊天!

关注我们

  • 原文链接: blog.rhinestone.wtf/omni...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Rhinestone
Rhinestone
Infrastructure and APIs for seamless wallet abstraction. Built on smart accounts. Powered by intents. https://linktr.ee/rhinestonewtf