本文介绍了 Resource Locks 的概念及其在解决当前区块链用户面临的挑战中的作用,Resource Locks 通过临时锁定用户想要花费的资产,创建密码学承诺,保证资金的可用性,从而实现可靠的跨链执行,并改善用户体验,此外,文章还讨论了 Resource Locks 的不同类型与未来发展方向。
以太坊的以 Rollup 为中心的路线图,以及其他 Layer 1 协议,已经在区块链设计的演进中展示了显著的进展。然而,在机制设计中,将链扩展到 10,000 TPS 以上仍然是一个开放的研究领域。必须解决这个扩展挑战,才能实现建立在链上轨道上,且不牺牲去中心化的新金融系统的潜力。
当我们退一步,看看解决这个挑战需要什么时,很明显我们需要两类节点:(1)构建证明的非常强大的排序器;(2)保持系统抗审查、安全和活跃的轻量级验证器。向这种架构的过渡是一个重大的技术挑战,需要时间来解决。
除此之外,还发生着一场政治和社会变革:Robinhood 和 Coinbase 等公司越来越多地推出专用应用链,因为他们想拥有基础设施并捕获完整的费用堆栈,以便根据特定的监管或产品需求定制堆栈,并确保未来需求的空间。
这些是多链未来的主要推动力:没有一条链可以满足所有用例,同时保持真正全球金融系统的性能要求。
然而,这也带来了一系列迫切需要解决的独特问题:
本文介绍了资源锁,作为增强意图的基础,它能够实现可靠的跨链执行,同时提供主流区块链采用所需的用户体验。
当前底层复杂性的积累创造了一个环境,使得用户即使在链上表达最基本形式的意图也面临着巨大的挑战。
为了证明这一点,让我们来探讨一个例子,用户想要在 Polymarket(最受欢迎的链上应用之一)上下注,然后购买一个热门代币:
从 CEX 提款到 Polymarket: 将支持的资产存入 Polymarket(不同链上的稳定币变体或主要的 L1 代币),并支付任何提款或网络费用(这取决于交易所和资产)。
等待网络确认: 这将根据用于存款的代币和网络而有所不同,然后需要二次等待 Polymarket 处理存款。
存款转换为 Polygon 上的 USDC。
下注: 使用 USDC 在所需的市场上进行投注。这个过程立即发生,用户无需担心批准或 Gas 费。
将资金提取到外部钱包: 提款仅在 Polygon 上进行,并且只能提取 USDC,即使该用户存入了其他资产。他们需要将资金发送回 CEX 或外部钱包,并且需要在那里拥有 POL 作为 Gas 代币。
创建一个 Solana 钱包: 这个热门代币仅存在于 Solana 上,因此需要创建一个新的钱包,因为他们当前的钱包仅支持 EVM 网络。
将 USDC 桥接到 Solana: 为了将资金从 Polygon 转移,他们必须首先找到一个桥,这是一个新概念,用于将他们的 USDC 转移到 Solana,并且还需要支付少量的 Gas 费。
等待资金到达: 这可能需要几分钟,但对于不熟悉使用区块链的用户来说,这段时间感觉就像永恒。
用 SOL 为 Solana 钱包提供资金: 如果没有 SOL,用户将无法在 Solana 上使用他们的 USDC,因为他们需要 Gas 代币才能进行交易。
将 USDC 兑换为热门代币: 这可以在选择的钱包或 Solana 上的热门应用中进行,并且包括少量的 Gas 费。
在这场折磨结束时,用户现在有分散在多个链上的余额,用于 Gas 管理的不同代币,大量的钱包,浪费了等待资金到达各个网络的时间,并且已经克服了许多障碍。
原本应该是一致的体验,只需点击几下即可完成,但实际上却被彻底破坏了。
链抽象解决了这个问题。
对于链抽象有很多定义,但我将使用的定义为开发者和用户提供不同的属性:
对于开发者:
对于用户:
所有这些,同时保留了自我托管。
开发者希望在不受糟糕的跨链设计限制的情况下进行构建,而用户希望链上应用程序能够“正常工作”。
一些现有的协议和链已经尝试提供这些属性,但大多数需要完全信任中心化实体,并且在系统中引入单点故障。虽然这些代表着朝着链抽象的进步,但它们未能达到所需的无需信任、去中心化的基础设施。
资源锁使跨链交易的速度与同链交易一样快,甚至更快,即使涉及比特币或以太坊等较慢的链也是如此。它们的工作原理是临时锁定用户想要花费的特定资产和金额,创建一个加密承诺,保证基于预定条件(例如成功执行交易或到期时间)的独家资金可用性。
资源锁机器(也称为可信承诺机器,分配器或排序器)提供即时加密证明,表明资金专门为特定意图保留,允许求解器立即执行目标交易,同时保证付款,甚至在源链确认交易之前。这种承诺向求解器发出交易意图信号,使他们能够立即执行目标链交易,而无需源链包含,同时以密码学方式防止双重支出。
查看资源锁的另一种方式是,它们与 Rollup 非常相似,因为它们都具有:
Rollup 和资源锁之间的关键区别在于实时证明,其中证明在创建或修改锁时立即生成,而不是定期批量生成。此外,资源锁保持对多个结算链的本机状态的直接访问,从而无需维护单独的状态或要求用户在生态系统之间桥接资金。
然而,这并不是一个新概念。资源锁是传统金融和互联网基础设施的基础,用于数据库管理系统、金融交易处理和分布式计算环境,以防止竞争条件并保持一致性。当多个用户尝试同时访问或修改同一银行账户时,银行会应用锁以确保交易按顺序和准确地处理,从而防止双重支出并保持交易的原子性。同样,Web 服务在其 API 中实施资源锁,以管理状态更改并确保关键操作在没有干扰的情况下完成。
当这种经过验证的基础设施模型应用于加密货币中基于意图的系统时,它将变得特别强大,解决了它们的许多核心限制。理解这一点需要检查三个关键领域:意图今天如何工作,基于意图的系统中的当前问题,以及资源锁如何解决这些问题。
为了理解为什么资源锁正在增强意图,我们首先需要检查当前基于意图的交易流程及其固有的限制。
用户签署一条消息,其中包含所需的输出和授权的资产(用户愿意花费的资产)。意图在时间 T 包含在源链中,用户的资产被锁定以防止双重支出。
求解器看到用户的意图,并竞争在时间 T+1 创建所需输出的最佳解决方案。
选定的求解器在时间 T+2 在目标链上执行解决方案,同时等待来自源链的付款确认。
解决方案在时间 T+3 包含在目标链中,求解器在时间 T+4 收到用户锁定的资产,从而完成跨链交易。
虽然意图系统比传统的跨链交互提供了显着的改进,但它们面临着限制其有效性的基本架构约束。
由于其四步交易流程,基于意图的系统无法提供同步的可组合性,从而导致时间延迟,用户必须从 T 到 T+3 等待,直到其跨链交易完成。
存在这种多步流程的原因是,意图系统和求解器都需要防止双重支出。如果求解器要为用户的意图提供资金,用户可以更改其交易 nonce 并花费求解器希望收到的作为付款的资产。这将导致求解器损失其资金。
意图协议充当此过程中的受信任中介,保证用户将收到所需的输出,同时保护其资产以供求解器付款。同样,它可以确保求解器在执行用户意图后获得补偿。尽管此信任要求仅跨越 T 到 T+3 窗口,但它在协议的运行中创建了一个至关重要的中心化点。
资源锁通过引入一种新的协调机制,消除了困扰当前意图系统的基本计时和信任问题。
资源锁的功能类似于盖章机,为意图协议、用户和求解器提供必要的安全保障,同时消除现有基于中介的协议中存在的某些信任假设。
通过消除这些信任假设,意图系统现在可以提供具有 T+1 执行时间的同步可组合性,其中跨链交易的完成速度与单链操作一样快。这消除了当前意图系统特有的 T 到 T+3 延迟。但是,用户和求解器仍然必须信任资源锁机器。
当资源锁协议具有成本效益、速度快且具有足够的交易量时,它可以提供与在单个链上操作感觉相同的跨链体验,从而实现真正的链抽象。
这种架构的根本性转变解决了基于意图的系统的核心限制,但问题仍然存在:
资源锁究竟如何实现这些改进,以及是什么使其在技术上优于现有方法?
资源锁机器为钱包和应用程序提供必要的基础设施,从而在其各自的平台上实现互操作性。这些系统由两个主要部分组成:
链下基础设施的运行方式与传统的意图协议类似,但包含一个关键的附加组件:资源锁机器。该组件充当协调层,负责管理用户的交易排序权限并保护求解器免受双重支出的影响。
例如,考虑一个拥有 1 ETH 的用户提交了两个意图——首先,跨链转移 1 ETH,其次,简单的 1 ETH 转移。如果没有适当的排序,如果求解器执行了第一个意图,而系统同时允许处理第二次转移,那么当第二次转移耗尽用户的余额时,求解器可能会损失其资金。资源锁机器通过控制交易顺序来防止这种情况,从而维护了意图执行过程的完整性。
链上组件在不同实现方式之间有所不同,但遵循一致的架构模式。该组件对于系统的功能至关重要,并且由资源锁机器和用户的签名者控制的智能合约(钱包)组成。
智能合约支持各种配置,具体取决于具体的实现。有些允许主签名者在时间锁定期后删除资源锁机器,而另一些则完全依赖于资源锁机器。
对于各种安全和去中心化要求,存在不同的解决方案,从优先考虑用户控制的方法到强调协调效率的方法。
资源锁将序列权限从区块链转移到资源锁机器,不同的实现方式在安全性、去中心化和用户体验之间提供了不同的权衡。
完全链下的资源锁面临着一个独特的挑战:在不依赖智能合约的情况下提供安全保障。资源锁机器必须控制用户资金,同时对用户和求解器保持可信。
可信执行环境 (TEE) 提供计算完整性保证,并且在加密货币领域建立了用例,从隐私应用程序到 Rollup 状态转换验证。TEE 还可以通过为用户提供必要的信任假设来为资源锁机器提供支持。
在完全链下的资源锁中,控制用户帐户的私钥可以通过各种凭证系统进行管理,包括私钥、Passkey或 Google 帐户(基本上,任何可以用作凭证的东西)。这种方法最大限度地提高了用户身份验证的灵活性,同时通过使用基于 TEE 的执行来保持安全性。
基于 TEE 的资源锁机器通过一个简单的流程运行:
凭证验证:用户通过应用程序界面向 TEE 提供凭证,然后 TEE 验证其有效性并确认帐户所有权。
意图处理:TEE 验证凭证是否有效且属于用户,然后处理意图请求。
授权:验证后,TEE 授权求解器查看用户的意图并执行交易。
结算:一旦用户的意图得到执行,TEE 就会通过帐户控制使求解器能够收到付款。
此流程利用 TEE 可编程的前提条件,开发人员可以在其中配置 TEE 程序在执行之前必须验证的特定要求。在此实现中,程序使用安全存储在 TEE 环境中的私钥对消息进行签名。
完全链下的资源锁在简易性和用户体验方面提供了显着的优势。用户可以将资金存入帐户,并立即开始跨每个受支持的链进行消费,而无需复杂的链上智能合约交互。这种用户体验可以与传统中心化服务相媲美,同时保持加密安全保障。
但是,仅依赖 TEE 会产生审查问题(TEE 运营商可以决定审查和阻止特定用户)和活跃性问题(如果 TEE 停止工作,则无法转移你的资产)。由于资源锁本质上是将序列权限从区块链转移到资源锁机器,因此你需要在用户保管和改进的 UX 之间进行权衡。
半链上资源锁方法使用带有两个签名者的智能合约钱包。
第一个签名者属于用户(可以是Passkey、简单的 EOA 或任何可在链上证明的凭证)。
第二个签名者来自 TEE,为系统提供必要的资源锁保证。
实际上,用户将使用Passkey凭证登录,TEE 持有另一个私钥,从而使体验如下所示:
用户意图签名:用户使用其Passkey对意图进行签名(可以是任何类型的私钥,但我们以Passkey为例)。
TEE 验证:TEE 验证 TEE 内部的消息,并确保帐户所有者请求了此意图。
意图履行:求解器履行意图。
结算:在执行意图后,TEE 对消息进行签名,并且 2/2 多重签名链上智能合约执行另一笔交易,以便求解器获得报酬。
用户的签名者可以在时间锁定期后删除第二个签名者(即 TEE 签名者)。时间锁至关重要,因为它为求解器提供了双重支出保护和其他安全保障,以及删除 TEE 签名者的能力。
这种结构为用户提供了更好的审查保证,并为开发人员提供了更多的自主权。
虽然该系统在理论上看起来更加优雅,但它引入了实际的复杂性:开发人员必须处理跨链状态跟踪,并且在智能合约实施和密钥管理方面都存在额外的开销。
尽管如此,用户体验仍然可以与中心化交易所和其他高质量界面相媲美。
完全链上资源锁通过将所有协调移到链上来解决基于 TEE 的方法的信任和自主权问题。此方法利用子帐户结构,用户将资产存入单独的合约,从而使其主帐户保持不变。
这种子帐户机制使任何构建了自己的 ERC-7702 智能合约的钱包都可以在不调整其核心架构的情况下采用资源锁。它可以为子帐户提供资源锁功能,同时保持主要资产不变,从而在不中断现有基础设施的情况下实现增强的功能。
对于用户而言,其工作方式如下:
存款:用户在使用链抽象功能之前,将资金存入资源锁子帐户。
意图处理:系统通过子帐户处理用户的意图请求。
授权:授权的求解器可以使用子帐户资产查看和执行意图。
结算:链上智能合约处理从子帐户向求解器的付款。
但是,这也有一个缺点:用户必须将资金存入托管合约才能使系统运行,这会增加额外的步骤并损害所需的用户体验。
在讨论资源锁机器时,我们经常关注 TEE 支持的验证;但是,TEE 不是强制性的。一种实用的替代方法是将 RLM 的两个基本角色(执行意图和验证意图)分配给不同的参与者:
执行签名者(例如,分配器)
验证签名者(例如,预言机)
用户签名者
一个简单的实现是 3-of-3 多重签名,其中预言机、分配器和用户各自持有一个密钥。通过将执行与验证分离,开发人员可以采用与其风险承受能力相符的信任假设,而不是依赖于单个 TEE 保护的资源锁机器(一些团队已经在试验这些配置并提供可行的非 TEE 替代方案)。
资源锁已经超越了一个想法。一些专门的团队(如 OneBalance)和主要参与者(如 Circle 和 LiFi)现在正在开发具有资源锁的产品。虽然这些产品由于其开发的早期阶段尚未对我们的生态系统产生重大影响,但资源锁可能会面临一些潜在的挑战。
从总体上看,主要存在两个问题:
7702 具有“主密钥”,即使在用户将资产委托给另一个合约时,也无法构建纯粹的基于 7702 帐户的资源锁。
应用程序无法在不检查所有链的情况下确定可消费的资产(出于开销原因,它们可能不会实现)。
幸运的是,我们有解决这些挑战的方案……
以太坊最近进行了一次升级 (7702),这是通过为 EOA 启用升级功能,使帐户抽象进入网络方面朝着正确方向迈出的一步:
用户现在可以进行批量交易
利用支付方
将某些属性委托给智能合约
但是,仍然存在控制帐户的“主密钥”。虽然用户仍然可以利用完全链上的资源锁,但这是实现半链上资源锁的障碍。
半链上资源锁的工作方式取决于真正的“多重签名”所有权。为了使其正常运行,开发人员需要在密钥管理级别进行自定义,而 7702 不提供此功能。它也不允许将完整的帐户“权限”和“控制”委托给另一个合约。始终有一个主密钥保留对帐户的最终控制权。
幸运的是,有一个 EIP 可以解决此问题:它允许任何 EOA 将帐户所有权委托给智能合约,并可以选择让主密钥“延迟”重新获得控制权。这意味着我们可以在 EOA 帐户中使用具有半链上方法的资源锁。但是,此解决方案并不理想;它针对非常具体的用例对以太坊协议进行了更改,并且不太可能成为以太坊升级的一部分。
首选的解决方案是具有本机帐户抽象,并在密钥管理级别具有完全的可自定义性。但是,正如我们所看到的,这在短期内很遗憾不会发生……
尽管伟大的研究人员努力通过 ERC-4337 将帐户抽象引入以太坊生态系统,但很明显,存在一个难以克服的持久挑战:应用程序很懒,除非被迫,否则不想更改其 UI。
结果呢?一个经典的先有鸡还是先有蛋的问题,导致采用停滞:
应用程序不会支持帐户抽象钱包,因为没有足够的用户
用户不会采用帐户抽象钱包,因为应用程序不支持它们
资源锁将面临与帐户抽象相同的采用挑战,但复杂性更高:
应用程序尚未意识到资源锁
实现复杂性高于帐户抽象
挑战不在于理解资源锁的作用。这是应用程序支持它们面临的技术开销。成为资源锁感知意味着应用程序需要:
同时跟踪多个链上的用户资产
从分散的持有量计算总可花费余额
根据跨链资产的可用性创建适当的支出意图
解决方案:钱包应该处理复杂性,而不是应用程序
由于应用程序不太可能自行实现这种复杂的集成,因此钱包应该承担此责任。一个有希望的解决方案是钱包开发一个统一的 API,该 API 显示具有跨链总可花费资产的应用程序(它们已经在自己的界面中跟踪的内容)。这就是 ERC-7811 通过 GetAsset Proposal 提出的……
因此,getasset 提案将复杂性从应用程序构建者转移到钱包团队,他们已经在其系统中处理这些复杂的任务并提供这种共享的资源锁感知意识。
另一个挑战是将现有意图系统的求解器集成到资源锁机器中。如果资源锁机器无法利用现有的求解器基础设施和流动性,那么采用速度将会很慢。解决方案是在资源锁机器中创建模块化组件,这些组件可以在权衡特定属性的同时为用户提供最具成本效益的价格。
最后,重要的是要记住,并非每笔交易都需要跨链转移。当钱包在帐户级别使用资源锁时,可以在同一链上执行简单的转移。毕竟,当传统的支付轨道可用时,用户不想为 1,000 美元的转移支付 1 美元的费用。
我们正在进入链上 UX 的新时代,用户将专注于应用程序,而不是链。资源锁是最后缺失的部分:它们能够以 T+1 实现快速、可靠的意图执行。
不再有资产碎片化。不再有复杂的流程。不再有批准。
链上,如预期。
- 原文链接: cyber.fund/content/RL...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!