Utexo 的 RGB 技术栈:SDK、Bridge 与实时钱包演示

Utexo 的 RGB 技术栈:SDK、Bridge 与实时钱包演示

本文基于2026 年 7 月 30 日举行的 RGB 社区通话,这是一场面向开发者的会议,主讲人是 Renat SkitsanUtexo 的 CTO,由 RGB Protocol Association 的 Birk 主持。Renat 详细介绍了 Utexo SDK 套件,并现场演示了 Bridge 和一个基于浏览器的 RGB 闪电钱包。

简要概览

  • 比特币上的 RGB 协议已经覆盖了稳定币的核心使用场景(私密支付、原子交易、借贷);更广泛的可编程性是一个规模更小、相对独立的方向。
  • Utexo 的 SDK 覆盖 Node.js、浏览器 JS/TS、React Native,以及即将上线的 Flutter,还有一项尚未正式公布、内置于 Tether 自有钱包开发套件(Wallet Development Kit,WDK)中的集成。
  • Bridge 使用可信执行环境(trusted execution environment,TEE)而非联合体信任来在 RGB 上铸造 USDT;现场演示展示了从一条 EVM 链到基于浏览器的 RGB 闪电钱包的完整流程。
  • 比特币上 USDT 上线的一个现实但非承诺性的时间窗口:2026 年夏末到 9 月中旬

什么是比特币上的 RGB 协议?它对 USDT 为什么重要?

Renat 首先为通话中的新人做了一个入门介绍。比特币上的 RGB 协议是一种客户端验证协议:一种在比特币的 UTXO 模型之上叠加记账系统、并最终实现完整智能合约系统的方式,而不需要把这些逻辑推到基础链本身上。

比特币区块链只用于防止双花。其余的一切(实际的状态转换、合约逻辑)都发生在客户端。RGB 之所以具备可扩展性,正是因为任意数量的状态转换都可以打包进同一个 UTXO,并通过一笔比特币交易完成最终确认,而不会受限于「每笔支付对应一笔交易」的限制。Renat 将「把除双花防护之外的一切都移出基础链」描述为一个真正独特的设计选择,也正是 RGB 能够远超典型协议规模进行扩展的原因。

他把这条脉络追溯到 Omni Layer(最早尝试在比特币之上实现另类记账的「Master Coin」项目),当年正是因为比特币还没有足够具备表达力的系统,才把早期稳定币的发行推向了以太坊。RGB 被视为比特币社区最终建立起来、用来弥补这一空白的系统:既保留了与比特币本身相同的抗审查性和去中心化特性,又具备在 UTXO 之上承载额外逻辑的能力。

这套逻辑的直接目标:比特币上的 USDT,还附带一个好处——RGB 转账不会像今天的 USDT 交易那样,在区块浏览器上公开可见

从可编程性到元资产标准:叙事为何转变

RGB 的客户端验证模型在设计上比通用型 EVM 可编程性更「窄」,但它已经覆盖了真正能产生价值的那些使用场景:

  • 支付与稳定价值转移:已完全覆盖,可以运行在比特币 Layer 1、闪电网络,或 Ark、Spark 等其他 Layer 2 技术之上。
  • 交易:比特币的 HTLC 原语已经支持原子交换,因此这一场景同样已被覆盖。
  • 以 USDT 和比特币为抵押的借贷:已经有项目在积极构建这类产品。

Renat 估计,这三种场景大约覆盖了当今加密领域真正产生价值部分的 90%,并指出过去一年里,其他地方通用可编程性所催生出的很多东西,最终都会消失。剩下的 10%(质押、杠杆头寸,以及更小众的金融工具)是一个规模更小、仍在持续研究的方向,对流动性较低的代币比对 USDT 这类资产更重要。

在需要更多可编程性的地方,Renat 指出 RGB 可以扮演元协议的角色:由于它可以运行在任何 UTXO 之上,资产可以进入具备更强可编程表达力的 Layer 2 系统(比如 KaleidoSwap 发布的、将 RGB 与 Liquid 上的 Simplicity 相结合的工作),同时资产本身仍以 RGB 计价。在 Renat 看来,把 RGB 定位为元协议,是描述它本质的最佳方式:这是一种既不污染比特币链、又能保护隐私,并让比特币真正发挥其设计初衷的方案。

Utexo 的产品套件:SDK、Bridge、Swap、Settlement、Cloud

在进入演示之前,Renat 先概述了 Utexo 的产品线:

  1. API 与 SDK:通过闪电网络和 RGB,在比特币上实现非托管、保密的 USDT 结算。
  2. Cloud:为不想自行运行节点的运营方提供全托管的 RGB-闪电网络基础设施。
  3. Mint:一个锁定并铸造(lock-and-mint)枢纽,可以从任意源链在比特币上发行 USDT。
  4. Swaps:基于意图(intent-based)的路由,实现非托管的 BTC ↔ USDT 兑换。

多平台覆盖与 Tether WDK 集成

已经拥有 USDT 用户(在 Tron、Ethereum 等网络上)的钱包,需要的是一个能嵌入其现有代码库、而不是独立节点的 SDK。Utexo 给出的方案,是一整套覆盖以下平台的 SDK:

  • Node.js:用于在现有后端中,把节点嵌入到服务端。
  • 浏览器 JavaScript/TypeScript:现场演示中使用的版本,被认为是展示能力最简便的方式。
  • React Native:面向 iOS 和 Android。
  • Flutter:即将上线,预计与 React Native 合计可覆盖约 90% 的 Web3 钱包。
  • 原生 Swift/Kotlin:已经支持,覆盖剩余那 10% 采用原生方式构建的钱包。

接着 Renat 分享了一个他称之为「小小剧透」、尚未正式公布的消息:一个内置于 Tether 自有钱包开发套件(Wallet Development Kit,WDK中的 RGB 闪电模块——WDK 是 Tether 提供的模块化框架,用于构建嵌入了 USDT 所在各条链的自托管钱包。Utexo 的集成完全运行在 Node.js 和 Bare 之上,并且与 Tether 的点对点产品套件兼容,包括 KeetHypercore。Renat 称 WDK 是开发者构建新钱包最简便、最顺手的路径,因为已经有大量现有开发者群体在这个框架内工作,而且 Tether 团队和 Utexo 团队都能提供支持。

除 SDK 之外,Utexo 还在筹备一个完全开源的参考实现钱包,基于 WDK 和 Web SDK 构建,将同时以浏览器扩展和 iOS/Android 移动应用的形式发布,并上架 Apple 和 Google 应用商店。钱包备份使用 VSS 服务器,这是最初由闪电网络开发套件(Lightning Development Kit,LDK)团队设计的备份系统,现已扩展到同时覆盖 RGB 资产的备份。

基于 RGB 构建的钱包生态系统

Renat 列举了几个已经在集成 Utexo SDK、进度不一的钱包:

  • Tribe Wallet:开源。
  • Kaleidoswap:目前处于 beta 阶段。
  • Iris Wallet:预计还会有进一步更新。
  • Layer Z Wallet:知名的 Blue Wallet 的继任者,RGB 集成已进入最后阶段。
  • Xverse Wallet:此前以 ordinals/runes 钱包著称,现在正在加入 RGB。
  • Unisat:另一个以 ordinals 和 runes 闻名的钱包,集成已经完成,目前处于测试阶段,预计将成为发布合作伙伴之一。

Renat 还提到,除了上述这些比特币原生钱包之外,一些以稳定币为导向的钱包和通用 Web3 钱包也表现出了兴趣。

深入 Bridge:安全机制究竟如何运作

Bridge 采用锁定并铸造(lock-and-mint)的设计。在 EVM 一侧,一份经过审计的开源智能合约(兼容 USDT0LayerZero,因此可以从多条链引入 USDT)锁定资金并发出一个事件。这个事件会被 RGB 智能合约捕获并处理,在 RGB 一侧铸造对应的资产。由于 RGB 是客户端验证的,每一位接收方都会独立地把铸造历史一路核对回那笔锁定事件,因此铸造行为只能由一笔真实、可验证的锁定交易触发,别无他法。

Bridge 运行在可信执行环境(trusted execution environments,TEE)内部:这些 enclave 生成签名密钥,按照设计,这些密钥永远无法离开硬件边界。一个由多方组成的联合体运行着这些 TEE,但安全性并不建立在对这个联合体的信任之上:Renat 明确表示,Bridge 的安全假设来自客户端验证、密码学逻辑和 RGB 智能合约,而不是对联合体的信任,甚至即便联合体的多数被攻破,也仍然需要一笔真实有效的比特币交易,才能解锁任何资金。

联合体真正的职责,是提供在线可用性和抗审查性(确保 Bridge 始终可用),而不是充当信任锚点。在资金返回解锁时,TEE 会验证 RGB 销毁事件、核查 RGB 寄售包(consignment),并验证比特币的工作量证明(PoW),同时还会通过 EVM 一侧一个名为 BTC Relay 的智能合约进行交叉核验——只需要全球任意一位诚实参与者提交正确的最长链,就足以阻止一次欺诈性解锁。

锁定合约和 TEE 代码都是完全开源的,Bridge 及其 TEE 代码库已经完成了内部和外部审计。Renat 提到,团队计划尽快发布最终审计报告,并配套推出工具,让任何人都能独立验证某个联合体签名方运行的是否正是经过审计的代码——方法是在本地编译代码,并将得到的公钥哈希与 GitHub 上发布的内容进行比对。更长期的安全加固措施,包括把 TEE 的工作负载分散到多个云服务商(AWS、Google Cloud、Azure)上,而不是依赖单一供应商。

SDK 现场演示

现场演示:把 USDT 从一条 EVM 链发送进浏览器版 RGB 闪电钱包

接下来 Renat 切换到了现场演示环节,值得完整观看通话录像,而不只是阅读文字,因为很大一部分价值就在于亲眼看到实际的界面。以下是他所展示内容的简要总结:

Bridge 前端:连接钱包、选择源链(目前支持大约 68 条链,USDT 主要集中在 Ethereum 和 Tron 上,另外 Plasma 和 Polygon 已经上线,Solana 即将支持),并选择比特币/RGB 作为目标链。Renat 特意在 Arbitrum 上进行了现场转账,因为作为 Ethereum 的 L2,它与 Utexo 在 Ethereum 主网上所依赖的最终确认假设是一致的。在从 RGB 钱包一侧生成一张发票并输入到 Bridge 之后,一笔小额转账(约 2 美元)被提交并在 EVM 一侧得到确认。演示中最终确认耗时约 18 分钟,这是一个与 EVM 链上确认深度相关、而非与比特币或 RGB 本身相关的主网安全假设;Renat 预计在专用的开发环境中,最终确认速度会快得多。

基于浏览器的 RGB 闪电钱包:signet(一种比主网出块更快的比特币测试网络)上现场创建,助记词也是当场生成的。Renat 明确说明了这里实际发生的事情:闪电节点完全运行在浏览器内部,除了加密备份之外,不会调用任何外部服务器。随后,他连接到了一个 LSP(Lightning Service Provider,闪电网络服务提供方)——一个远程的 RGB 闪电节点,负责开通道并提供入向流动性,这样一个新钱包在能够接收付款之前,就不需要自己解决入向流动性的问题。

接收与发送资产:Renat 使用一个专为开发者体验打造的 Telegram 机器人,按资产 ID 申领测试资产,生成一张链上发票,并让 Bridge 支付这张发票,随后眼看着确认到账、钱包中的余额随之更新。钱包界面把「transactions」(链上资金变动)与「transfers」(生成的发票及其状态,例如「进行中」或「已完成」)区分开来,在确认数达到要求后更新资产余额。他还演示了两个 SDK 实例之间的点对点闪电支付,并简要展示了闪电地址(Lightning address)支付——让接收方无需为每一笔付款预先生成发票即可收款。

一个刚刚开通的闪电通道,起始时只有来自 LSP 的入向流动性,出向流动性为零;Renat 指出,出向流动性来自于先实际收到资金——无论是通过 Bridge,还是通过一笔潜艇兑换(submarine swap)注入通道。

演示中展示的一切都是开源的:Telegram 机器人、React Native SDK(配有一个沙盒移动应用),以及 Web SDK(文档涵盖了 LSP,以及底层的异步支付协议——因为浏览器钱包并不总是在线,无法实时接收付款,所以需要这套协议)。

如果在兑换过程中出现故障会怎样?

如果用户的设备或网络连接在交易过程中中断会怎样。Renat 的回答是:具体到 swap 这个产品(区别于 Bridge),按照设计,不存在「部分失败」的状态:一次兑换要么完成,要么不完成,中间不存在资金可能丢失的状态。这个系统是刻意设计成不依赖用户一侧的在线状态来保证交易本身有效:一笔广播出去的交易,只有在源链上对应的支撑交易确实存在时,才会最终确认。

正如 Renat 总结的那样,担心交易过程中断连会导致资金被烧毁,这种担忧是没有根据的:不会有任何损失,因为一次原子交换要么完全成功,要么完全不发生,不存在一个可能出错的中间状态。

唯一需要用户自己保证可用的,是 RGB 的寄售包(consignment)文件——按照 Renat 的说法,这和用户已经需要承担的助记词保管责任属于同一类别,并不是 RGB 设计额外引入的取舍。

RGB 闪电节点:从功能完备到安全加固

被问及 RGB 闪电节点本身的最新进展时,Renat 表示过去几个月的重点一直是互操作性:在移动端、浏览器、钱包扩展和服务端/云端全面构建 SDK,并配套异步支付协议和备份等支持性功能。这部分基础工作已基本完成,并已通过已经集成它的各个钱包得到验证,Utexo 的重心目前已转向专门针对 RGB 闪电节点的安全加固,遵循与 Bridge 相同的流程(先内部评审,再外部审计)。

被引入的外部审阅者包括知名的 LDK 和 RGB 闪电网络开发者。Renat 预计这一阶段的进度会比 Bridge 那一轮更快,因为团队不再需要同时在多个项目之间分散精力,相关成果也已经在 RGB 闪电节点开发小组内部分享,预计未来几天会有更多 pull request 提交。

交易所、支付服务商(PSP)与上线之路

在业务层面,Renat 介绍了一条活跃的交易所集成管线,已经吸收了各交易所团队的工程反馈。大多数交易所预计会首先支持闪电网络,因为闪电网络已经在一线和二线交易所中得到充分集成,其工程团队也已经很熟悉;在此基础上叠加 RGB,是比引入一个全新资产小得多的增量工作。一些只运行 RGB 链上部分的交易所理论上可以稍早上线,但目标是尽可能让两者同时上线。

在支付服务方面,Renat 提到了一项已经完成的集成:全球最大的加密货币博彩平台之一 Betfury已经完成了 RGB 闪电网络集成,并一直在协助测试真实世界的使用场景。

USDT 何时在比特币上线?

Renat 给出的不是一个确切日期,而是一份还需完成的清单:

  • 安全审计:Bridge 及其 TEE 代码库的审计已完成;RGB 闪电节点的安全加固仍在进行中(见上文)。
  • 合规:近期宣布的 Crystal Intelligence 集成解决了这一项;剩余的法律工作据称已进入最后阶段。
  • 互操作性:把支持范围从最初的一组链,扩展到按交易量计更广泛的 USDT 和 USDT0 链。
  • 一个新的代币标准「Bridged Fungible Asset」:主要由 RGB Protocol 团队开发,预计将作为未来几周内一次 RGB 闪电网络更新的一部分发布。

随着这些事项逐一收尾,Renat 给出了一个现实但明确非承诺性的时间窗口:从技术角度看,2026 年夏末到 9 月中旬是一个现实的时间点,这与此前已经公布的说法一致,不过他也特别强调,这仍然取决于 RGB 社区内部大量的协调工作。

最后的话

Renat 最后谈到了这一切 SDK 和基础设施工作背后更宏观的愿景:把 RGB、闪电网络和比特币的分层架构完全抽象掉,让最终普通用户只需要知道自己在使用比特币上的 USDT就够了,就像今天大多数人使用互联网时根本不会去想 TCP/IP 一样。他鼓励开发者把现在当作参与进来的最佳时机,用这些 SDK 去构建,并把反馈发给团队。


renat-stiksan

Renat Skitsan

Renat Skitsan 是 Utexo 的联合创始人兼 CTO,Utexo 是由 RGB 驱动的比特币 USDT 结算基础设施。

类似文章