Avato Labs 基于 RGB 协议的非托管钱包架构设计

Charlie-DCharlie-D
5 min read

Dario & Suwannaphum / AvatoLabs

  1. 执行摘要

Avato Labs 正在开发一款基于 RGB 协议的非托管钱包，致力于为比特币和闪电网络生态提供高隐私、高安全、高性能的智能合约解决方案。本文概述了 Avato Labs 的 RGB 钱包技术架构，该架构以客户端验证为核心，通过 Rust 后端和 WebAssembly 前端的结合，实现了用户对资产的完全控制权，同时保证系统的高性能表现和隐私保护能力。

Avato Labs 的方案具有以下关键特点：

  1. 客户端验证与数据控制：所有 RGB 状态数据存储在用户设备上，保证用户对资产的完全控制权

  2. Rust + WASM 技术栈：采用全栈 Rust 后端和 WebAssembly 前端，确保高性能和跨平台能力

  3. 去中心化通信：支持点对点数据传输并提供备用中继机制，保障系统抗审查能力

  4. 强化隐私保护：集成零知识证明技术，保护交易隐私

  5. 闪电网络整合：设计支持与闪电网络的无缝集成，实现链下即时支付

  6. 多层次安全架构：从密钥管理到数据传输的全方位安全设计

我们的方案既符合 RGB 协议的去中心化理念，又满足现代网络应用的用户友好性需求，为比特币生态的智能合约应用开辟新的可能性。

  1. 背景与愿景

RGB 协议是构建在比特币和闪电网络之上的可扩展且具隐私性的智能合约系统。与传统的区块链智能合约不同，RGB 采用"客户端验证"模式，即合约数据（例如资产状态）由用户（客户端）存储和验证，而非全局账本。这种设计提供了前所未有的隐私性和灵活性，使得在不修改比特币基础层的情况下实现图灵完备的链下智能合约成为可能。

Avato Labs 认为 RGB 协议代表了比特币生态系统发展的重要方向，可以在不牺牲比特币安全性和去中心化特性的前提下，丰富其功能生态。我们的愿景是打造一款专业的 RGB 非托管钱包，将 RGB 协议的创新优势与出色的用户体验相结合，为市场提供真正去中心化且高度隐私的智能合约解决方案。

本文详细阐述了 Avato Labs RGB 非托管钱包的技术架构，重点涵盖以下八个关键方面：

  1. stash 数据存储方式：分析 stash 数据理论上应存储在用户浏览器中的原因，以及将其存储在后端服务器上对协议精神的影响；

  2. 前后端交互机制：研究如何合理设计前后端交互，既保持钱包符合 RGB 协议去中心化的精神，又能保证数据管理上的便利；

  3. 流程风险分析：讨论可能存在的安全漏洞、数据泄露风险及攻击面，特别是将 stash 数据存储在服务器上可能引发的隐私问题；

  4. 零知识证明（ZK）的安全性：探讨 ZK 在 RGB 生态中的应用、安全性及如何提高其计算效率；

  5. 架构设计：结合全栈 Rust 后端以及部分前端功能编译成 WebAssembly (WASM) 的钱包前端插件，设计一个切实可行的架构方案；

  6. 性能优化：针对 RGB 协议及未来对接闪电网络的需求，分析性能优化策略，确保架构不会拖慢闪电网络的速度；

  7. 实现方案：推荐合适的框架、数据库及开发工具，确保架构的可实现性；

  8. 参考文献：整合 RGB 官方文档、相关学术研究及业界最佳实践，确保论述有理有据。

  9. Stash 数据存储：客户端存储与服务端存储的对比

  10. 客户端数据存储的核心价值：

在 Avato Labs 的 RGB 钱包设计中，所有用于验证合约状态的数据（stash）将存储在用户的客户端设备上。这是 RGB 协议"客户端验证"理念的核心实现，确保只有用户（以及与其交易的对手方）拥有资产相关的完整合约数据。

客户端存储机制提供了三重核心优势：

  • 隐私保护：无第三方可以查看合约完整细节

  • 抗审查能力：没有集中式服务器可以冻结或阻止资产使用

  • 去信任化：所有验证在本地进行，无需依赖中心化服务确认状态

Avato Labs 的钱包设计将利用现代 Web 技术（HTML5 的 localStorage、IndexedDB 或浏览器插件中的文件存储）在客户端存储这些数据。系统将在本地对 stash 进行加密，确保即使设备遭到入侵，攻击者也无法读取明文数据。

  1. 数据持久性解决方案：

如果将 stash 数据移到后端服务器上存储，则会削弱上述原则。将用户的 RGB 数据存储在服务器上实际上会使控制权集中于服务器运营者，他们可能获取用户资产和合约历史的敏感信息。这不仅引入了隐私风险（本应只为资产拥有者所知的数据会被服务器看到），也违背了客户端验证的架构理念——服务器可能成为单点故障或攻击目标。如果服务器被攻破，stash 数据有泄露或篡改的风险。即便服务器本身是可信的，依赖它也可能削弱用户对资产的主权。换句话说，将 stash 存储在服务器上违背了 RGB 的“精神”，因为 RGB 强调用户对数据的控制与验证。正如 RGB 官方文档中指出的那样，客户端自行控制存储可以降低外部攻击和数据泄露的风险。此外，失去对 stash 的控制意味着用户可能失去其资产：如果 stash 丢失或不可访问，用户就无法证明对 RGB 资产的所有权，这与丢失私钥类似。因此，stash 应当存储在用户的持有的设备上。现代 Web 技术（例如 HTML5 的 localStorage、IndexedDB 或浏览器插件中的文件存储）可以支持在客户端存储这些数据。钱包可以在本地对 stash 进行加密和备份，从而确保即使服务提供方也无法读取明文数据，这既保持了 RGB 协议的去中心化精神，又为用户提供了良好的使用体验。

因此我们的钱包还会采用多层次数据保护策略，确保用户数据安全的同时不妥协 RGB 协议的去中心化原则：

  1. 端到端加密的云备份：

    1. 用户可启用自动加密备份功能

    2. 采用 AES-256 加密算法保护 stash 数据

    3. 加密密钥通过 PBKDF2 从用户主密码派生，服务器永远无法获取密钥

    4. 用户可选择 Avato Labs 提供的云存储或连接自己的云服务

  2. 多形式导出选项：

    1. 支持完整 stash 数据导出为加密文件

    2. 提供简化的恢复短语机制（12-24个单词）

    3. 支持二维码格式导出关键数据

    4. 自动提示在关键操作后备份

  3. 确定性跨设备恢复：

    1. 基于 BIP-32/39/44 确定性密钥推导机制

    2. 支持从相同种子短语重建完整 stash 数据

    3. 在新设备上自动重构资产历史

    4. 通过区块链数据验证确保一致性

所有持久化机制均在本地设备上执行加密操作，确保明文数据永不离开用户设备，实现隐私保护与便捷使用的完美平衡。

  1. stash 与图数据库（Graph DB）的潜在协同

Avato Labs 钱包在下个阶段规划了集成图数据库技术，优化 RGB 状态转移的存储和查询效率。在许多应用场景中，RGB 的状态转移历史呈现出图结构（或更具体地说是有向无环图，DAG），每一次转移都可以视为图中的一个节点和边。若用户或服务商希望对大量状态转移数据进行分析、检索或可视化，图数据库（如 Neo4j、JanusGraph 等）可能提供更高效的查询或聚合能力。

  • 客户端本地集成：在浏览器或本地应用中，可以嵌入轻量级的图数据库或图结构索引，加快 stash 中复杂查询的速度，如查询某笔转移的来龙去脉、统计某资产交易关系等。

  • 服务端辅助分析：对于高端用户或企业级应用（如区块链分析、数字资产审计），可在严格加密和用户授权的前提下，将只读且去隐私化的部分转移数据（或 Merkle/哈希承诺）同步到一台运行图数据库的后端，以进行聚合分析。这种模式下，服务端并不掌握敏感明文——它仅根据用户选择性披露的数据来构建图结构，用于可视化或审计。

  • 注意隐私与安全：无论是否使用图数据库，都要遵循 RGB 的“最小披露”原则，确保不会大规模暴露用户的交易细节；同时，通过 Pedersen 承诺或 Bulletproofs 等机制隐藏金额等敏感信息。

  1. 前后端交互机制

设计钱包前端（在浏览器中运行）与后端服务之间的交互机制，对于保持去中心化设计同时提供必要功能至关重要。在 RGB 钱包中，前端应负责所有敏感操作——包括用户私钥管理、签名生成以及 stash 数据处理；而后端则负责非敏感任务，例如获取区块链数据或传递消息。关键在于如何实现用户体验的便利性，而不将后端变成一个受信任的托管者。因此Avato Labs 的前后端交互机制设计遵循"最小信任原则"，确保关键操作在前端执行，后端仅作为辅助服务存在。

  1. 降低对后端信任度：

Avato Labs 钱包前端（UI 和 WASM 模块）会作为主要执行者，持有用户私钥和 stash，并执行 RGB 合约状态的客户端验证。当用户希望发送或接收 RGB 资产时，前端会构造所需数据（例如生成转移的 consignment 供发送方使用，或者验证接收到的 consignment 与比特币承诺相符）。后端的作用应局限于辅助：例如，提供 API 用于广播比特币交易、查询 UTXO 状态，或在接收方离线时临时存储和转发 consignments。需要注意的是，Avato Labs 钱包前端发送到后端的数据不会暴露敏感信息——例如，可以发送比特币交易的十六进制数据或加密后的 consignment，但绝不会发送整个 stash 或任何私钥材料。通过这种职责分离，钱包在本质上依旧是非托管型的，符合 RGB 的点对点精神，即使在实际操作中后端在流程中发挥一定作用。

  1. 去中心化通信方案：

RGB 协议本身对状态传输采用了与传输层无关的设计，不规定具体的 consignments 数据交换方式。目前主要有两种方案：

  1. 通过类似于 Storm 协议的点对点（P2P）通信，利用闪电网络通道作为数据传输媒介，也就是实现所谓的RGB闪电网络(RLN, RGB Lightning Network)；

  2. 采用简单的客户端—服务器模式，通过 RGB 代理服务器使用 HTTP/JSON-RPC 进行数据交换。

在我们的设计中，前端可尝试直接进行 P2P 数据传输（例如使用 WebRTC 或 Nostr、Storm 等技术直接与对方钱包建立连接），使 consignments 能够直接从发送方传输给接收方，从而体现 RGB 的“纯”点对点模式。然而，由于浏览器环境下受 NAT、防火墙或信令需求的影响，直接建立 P2P 连接可能存在一定难度，因此必要的场景下，Avato Labs 的方案之一，也可以支持更去中心化的、在采用服务端中继作为备用方案：发送方将 consignment 上传至服务器，对方随后下载该数据。

需要注意的是，RGB 标准允许使用第三方服务器进行数据交换，但同时警告称依赖此类服务器会“影响隐私和抗审查性，但不会影响安全性”。因此，如果钱包采用集中式服务器中继信息，必须假设该服务器可能记录元数据或拒绝服务，但不能伪造有效状态（因为客户端能自行验证有效性）。为了降低隐私泄露风险，可以在通过服务器传递 consignments 时采用端到端加密，使服务器无法看到数据内容。此外，我们也准备开源命令行工具，来支持用户自行部署可信的非托管钱包（在钱包中也会提供配置选项），以增加用户对系统的信任，就像 Electrum 钱包允许用户指定自己的 Electrum 服务器一样。

  1. 保证数据管理的便利性：

在设计前后端交互时，我的方案会确保操作简单。典型流程如下：

  • 用户浏览器中的钱包调用后端 API，仅用于获取诸如“获取 UTXO X 的比特币交易信息”、“广播此交易到网络”或“为用户 Y 存储此数据块”之类的操作。

  • 服务器处理这些请求并返回结果，而无需理解底层的 RGB 合约细节。

  • 业务逻辑（例如检查 consignment 中的加密承诺是否与比特币区块链数据匹配）最大限度得由前端插件得wasm构件来完成。

这种设计确保钱包在精神上仍保持去中心化——后端仅作为辅助服务存在，而不是权限机构。同时，也提升了用户体验：用户无需运行完整的比特币节点或始终在线，因为服务器可弥补这些缺陷。API 的设计可以遵循 REST 或 JSON-RPC 模式。事实上，RGB 代理标准建议采用 JSON-RPC 接口来上传/下载数据，例如可以设计 POST /rgb/upload 端点用于上传 consignment，以及 GET /rgb/download?param=... 供接收方下载。前端在需要时调用这些 API。整个过程中，我们始终遵循最小信任原则：后端无需存储长期用户秘密或单方面做出决策，所有由前端发起的操作都是原子性的，并可由前端独立验证。通过这样精心设计 API 并保持服务端状态的最小化，我们既符合 RGB 协议的去中心化理念，又兼顾了客户端—服务器架构的便捷性。

  1. 流程风险分析（安全性与隐私）

任何处理加密资产的 Web 钱包都必须对潜在风险进行分析。Avato Labs 的 RGB 钱包采用全方位的安全策略，实现比特币层（UTXO 和密钥）和 RGB 层（链下状态数据）的双重防护。我们的安全架构系统性地应对各类风险，确保用户资产和数据的完整保护。以下将针对潜在漏洞、数据泄露风险及攻击面进行讨论，特别关注将 stash 数据存储在服务器上可能带来的风险。

  1. 安全防护体系：

Avato Labs 钱包面临的主要威胁之一是恶意代码注入（如跨站脚本攻击，XSS）。若攻击者入侵 Web 应用或其加载的第三方脚本，可能窃取私钥或 stash 数据等敏感信息。我们的钱包前端严格遵循 Web 安全最佳实践：实施内容安全策略（CSP）屏蔽未授权脚本，确保所有代码（尤其是 WASM 模块）经过完整性检查和数字签名，并以浏览器插件和渐进式 Web 应用（PWA）形式分发，显著降低对远程托管代码的依赖风险。

前后端通信通道是另一个重要防护领域。Avato Labs 确保所有交互通过安全通道（HTTPS 或加密的 WebSocket）进行，防止中间人攻击窃听 consignments 或比特币交易数据。虽然 consignments 本身受加密保护（攻击者篡改后会导致验证失败），但我们认识到消息丢失或重放攻击仍可能造成拒绝服务或混淆。因此，我们在协议中集成了防重放机制，使用时间戳、随机数和会话令牌组合策略，同时实现智能超时处理和备用传输机制，确保通信韧性。

在服务器端，Avato Labs 实施了严格的安全控制。我们理解，提供云服务的钱包运营商是攻击者的重点目标。特别是当服务端存储 stash 数据（如为跨设备登录提供便利）时，服务器遭到入侵可能导致用户资产历史数据泄露，甚至使攻击者在未来合约更新中冒充用户。为此，Avato Labs 采用客户端主导的架构设计，将 stash 数据保存在客户端。对于用户选择的服务端备份，我们实施端到端加密，确保即使服务器被攻破，攻击者也无法获取有价值信息。我们的多层次服务器安全包括访问控制、定期安全审计、漏洞扫描和异常监测，构建了坚固的防御体系。

  1. 隐私保护机制：

隐私是 RGB 协议的核心特性，Avato Labs 钱包秉承"数据只属于所有者，不对外公开"的设计理念。即使资产的未来持有者也无法看到完整历史记录，仅能看到选择性披露的部分信息。我们精心设计钱包架构，避免引入隐私泄露风险。例如，当服务器用于中继 consignments 时，我们采取特殊措施防止服务器记录和关联用户身份与交易数据，避免形成可追踪的元数据链。

Avato Labs 钱包集成了多种隐私增强技术：内置 Tor 网络支持，掩盖用户真实 IP 地址；优先采用 Storm 点对点网络，实现类似洋葱路由的多层加密传输；在中继服务中实施无需身份认证的盲签名令牌机制。此外，我们的钱包支持用户选择多种备用服务器和直接通信渠道，确保单一服务器无法形成通信瓶颈或实施审查。我们的元数据保护系统严格遵循最小化原则，仅传输必要信息，并实施定期数据清理，防止长期分析风险。

  1. 数据完整性保障：

Avato Labs 深刻理解客户端验证系统固有的数据可用性风险：每个用户的 stash 是其资产状态的唯一记录，一旦因设备故障或误删而丢失，用户将无法证明资产所有权，类似于比特币私钥丢失的后果。为此，我们在钱包中实施了全面的数据保护策略。我们的系统在每次重要操作后智能提醒用户备份 stash，并提供简便的一键加密备份功能。对于启用云备份的用户，系统自动执行加密备份，确保数据安全。

为防止 stash 数据篡改，Avato Labs 钱包采用校验和和版本控制机制，在部分写入失败时自动回滚到最近有效状态。我们还将开发了专业的"stash 审计"功能，定期通过比对比特币区块链数据验证所有资产承诺，确保长期完整性。这些措施共同构建了强大的数据保护屏障，即使在极端情况下也能保障用户资产安全。

  1. 架构设计：基于 Rust 后端与 WASM 前端

Avato Labs 采用 Rust 开发后端并通过 WebAssembly（WASM）支持前端核心功能的架构方案。Rust 语言在安全性、内存管理及性能方面的优势，使其成为处理加密和并发任务的理想选择，特别适合 RGB 钱包的开发需求。我们的架构由浏览器端前端组件与后端服务协同工作，各自职责明确划分。

6.1 Rust 模块化后端

Avato Labs 将后端设计为一组微服务模块，每个模块专注于特定领域，完全符合 LNP/BP 标准协会为 RGB 节点提出的设计理念。我们的后端包括三个核心组件：

  1. 比特币接口模块：负责与比特币节点或区块链索引交互，获取 UTXO 状态、广播交易等功能；

  2. 闪电网络模块：管理支付通道，处理原子交换和通道资金管理，支持通过闪电网络转移 RGB 资产；

  3. RGB 数据处理模块：提供类似 Bifrost/Storm 服务器的功能，负责存储及转发 consignments 和 invoices。

在实际部署中，这些模块既可作为独立服务运行（甚至部署于不同容器或进程中），也可合并为单一二进制文件。Avato Labs 充分利用 Rust 的 Tokio 异步运行时，使多任务运行和 RPC 通信变得高效简洁。我们的实现借鉴了官方 RGB 节点的设计思路："节点可以作为一组守护进程、多线程单进程，或钱包应用中的受管理线程组运行"。

针对面向终端用户的 Web 钱包，Avato Labs 部署统一的后端服务，内部集成各功能组件，通过统一的 HTTP/JSON-RPC API 向前端提供接口，简化了用户体验和部署流程。

我们的后端开发充分利用了生态系统中的优质库，包括用于比特币功能的 rust-bitcoin、用于闪电网络的 rust-lightning（或 LDK），以及用于 RGB 合约处理的 RGB 标准库（rgb-std）。Avato Labs 的架构同时从 MyCitadel（RGB 项目提供的高层钱包节点）汲取灵感，构建了统一节点同时提供 RGB 智能合约、闪电网络、比特币索引、去中心化数据存储和钱包服务。

6.2 WASM 前端核心

在客户端，Avato Labs 将核心钱包逻辑以 WebAssembly 形式部署，这些代码编译自与后端共享的 Rust 代码库。这种设计实现了"一次编写、前后端共用"的理念，同时确保验证、加密计算和数据管理在浏览器内高效安全地运行。

我们嵌入网页的 WASM 模块负责执行关键操作：

  • 密钥管理（从助记词派生密钥）

  • 比特币交易签名

  • RGB consignments 构造和验证

  • 本地 stash 加密管理

通过 WASM 技术，Avato Labs 钱包获得接近原生代码的执行速度，这对计算密集型的加密操作尤为重要。我们的前端 UI 采用现代 JavaScript/TypeScript 框架（React），与 WASM 模块通过函数调用进行交互，实现 "create_wallet(mnemonic)"、"get_balance(asset_id)" 等操作。WASM 模块还能通过专门开发的粘合代码访问浏览器存储，安全存储加密后的 stash 数据。

6.3 前后端通信

Avato Labs 实现了高效安全的前后端通信机制。前端与后端通过 HTTPS 和 WebSocket 双通道进行通信，传递请求数据（如查询 UTXO 状态）和指令（如广播比特币交易）。由于 stash 和密钥完全保留在前端，所有通信均为无状态操作，确保了安全性。

一个典型的 RGB 资产转移流程在 Avato Labs 钱包中是这样执行的：

  • 前端 WASM 模块构造包含承诺的比特币交易并生成 RGB consignment

  • 前端调用后端 API（如 /broadcast_tx）广播交易

  • 通过另一个 API 调用将 consignment 发送给接收方

服务器不存储任何操作状态，仅提供中继和辅助验证服务，所有关键验证过程完全在前端执行，确保去中心化和安全性。

6.4 闪电网络集成

Avato Labs 钱包的一大创新是与闪电网络的深度集成，实现 RGB 资产的即时转移（Bifrost 协议）。我们的架构专门为此预留了扩展空间，后端闪电网络模块不仅能传输比特币，还能携带 RGB 承诺的支付通道。

我们采用异步事件驱动设计处理闪电网络交互：用户可通过前端请求创建通道或执行原子交换，后端协调与远程节点的通信。闪电网络操作本质上是异步的，我们通过 WebSocket 向前端实时推送状态更新（如"支付成功"或"收到RGB资产"），确保用户界面及时反映最新状态。

这种事件驱动架构使 Avato Labs 钱包能无缝整合闪电网络功能，用户实时了解交易状态，在 RGB 与闪电网络对接过程中获得流畅体验，不会因通信延迟影响用户体验。

6.5 部署模型

Avato Labs 支持两种灵活的部署模式，满足不同用户需求：

  1. 自托管模式：技术型用户可在自己的设备或服务器上运行 Rust 后端，前端通过本地连接（localhost）访问。这种模式最小化信任风险，类似于运行个人比特币节点。

  2. 云托管模式：普通用户可使用 Avato Labs 运营的后端服务和 Web 前端，只需访问网站即可。这种模式极大提升了用户友好性，同时保持安全性。

两种模式无缝共存——我们的钱包设置允许高级用户配置自定义后端节点（甚至通过 Tor 连接），而普通用户则使用默认服务。由于所有关键验证均在客户端执行，即使使用云托管服务，核心安全性不受影响，用户资产安全得到保障。

Avato Labs 的 RGB 钱包架构实现了模块化、安全与高性能的完美结合：后端采用 Rust 构建的微服务处理网络交互，前端采用 WASM 运行核心逻辑，通过明确的 API 进行数据交换。这种设计不仅符合 RGB 的去中心化理念，还实现了代码重用和高效验证。共享 Rust 代码库降低了前后端不一致性风险，而将敏感逻辑保留在客户端，确保用户始终掌握对资产的完全控制权。

  1. 性能优化与闪电网络集成

性能是设计钱包架构时的一个关键考量，尤其考虑到未来 RGB 需与闪电网络对接，实现高速、大量交易。我们必须确保 RGB 的处理或架构设计不会成为瓶颈。本节讨论我们采用的性能优化策略，确保钱包架构在不拖慢闪电网络速度的前提下实现高效运行。

客户端验证效率：

我们的设计充分认识到 RGB 的特性，使得客户端仅存储和验证与自身资产相关的数据。这大大减少了单个用户需要处理的数据量。对于仅持有少量资产的用户，其 stash 中仅包含该资产的创世数据及一条转账链。验证新转账只需要校验链上最新的一次状态转移，而不是重新处理全部历史记录。这样，每次新转账只增加少量验证开销，而非从头到尾重算。我们的钱包通过缓存中间结果来进一步优化，例如，在用户首次导入资产时校验创世记录及初始历史，后续只验证增量变化。我们还采用高效数据结构，如利用 Merkle 证明实现数据包含性验证、哈希表快速查找上次状态，加快处理速度。

异步与并行处理：

我们的架构充分利用并发性来优化性能。Rust 的异步特性允许后端同时处理多个请求，例如，多用户同时查询数据或进行钱包操作而互不阻塞。当一 API 正在从比特币网络获取 UTXO 数据时，另一个可以同时处理闪电网络事件。在前端中，我们利用 WASM 和 Web Workers 实现并行计算，确保 UI 不因等待长时间任务而阻塞。

闪电网络的速度考量：

我们深知闪电网络以近乎即时的支付著称，必须确保加入 RGB 不会显著增加延迟。我们采用 RGB 团队提出的 Bifrost 协议，实现 RGB 状态更新通过闪电 HTLC 或通道承诺进行锁定，而无需每笔转账都上链。在我们的钱包中，后端闪电网络模块（基于 rust-lightning 或 LNP Node）协调这些操作。例如，当 Alice 希望通过闪电网络向 Bob 转移 RGB 资产时，RGB 模块先生成状态转移 consignment 和对应的加密哈希；该哈希随后被用于闪电网络 HTLC（作为 Bob 的发票）。Bob 的钱包在接收到闪电支付后，将在验证对应 RGB consignment 后才会完成支付。我们的钱包设计尽可能通过最快的通道发送 RGB consignment，可以与闪电消息整合或采用并行安全通道。两项操作——闪电支付与 RGB consignment 验证——并行执行。我们的架构使这二者无缝衔接：后端的闪电服务与 RGB 数据服务在同一服务器或进程中，它们通过内存队列直接通信；Bob 的后端同时接收 HTLC 信号和 consignment 数据。由于所有操作均为链下行为，速度主要受网络延迟影响（在互联网上通常仅需数毫秒），而 consignment 的验证通常在一秒内完成，对于用户体验而言几乎是瞬时的。通过我们的精心设计，RGB 资产转移可以借助闪电网络的速度，实现近实时资产交付。

减少 API 调用延迟：

特别是对于上链操作，查询比特币区块链可能存在延迟问题。我们的后端运行完整比特币节点并通过 RPC 调用查询，但为了优化，我们采用专门的索引数据库（例如 BP Node 或 Electrum 服务器），以便快速返回 UTXO 状态。我们还在后端维护缓存，一旦用户注册了其 UTXO（作为 RGB 资产锚定），服务器便开始监控该 UTXO 状态。当检测到 UTXO 被花费（通过 mempool 或新区块），服务器立即向客户端发送通知，从而避免客户端轮询，迅速告知状态变更。

吞吐量与可扩展性：

我们的钱包服务面向大量用户，必须保证后端能良好扩展。我们利用 Rust 高效的异步模型处理大量并发请求，同时，由于大多数 API 调用为无状态请求，系统可进行负载均衡或使用无服务器架构。由于关键验证均在客户端完成，服务器无需承担类似区块链全节点那样的巨大验证负担，用户数量的增加仅会带来轻微的网络 I/O 负担。这正是我们采用 RGB 模型的优势：通过避免全局共识机制，达到更高的扩展性。

确保闪电网络整合不产生滞后：

我们认识到闪电网络的性能也取决于用户设备对通道事件的响应速度。如果用户依赖远程服务器，我们的后端闪电模块全天候管理通道状态（类似于 watchtower 或托管通道），以便及时响应。尽管这在可用性上可能引入一定信任，但我们的设计确保即便服务器介入，也不会影响资产安全，服务器仅用于确保一旦发生通道争议能及时广播处罚交易。我们的专用闪电网络进程已经针对高并发消息处理进行了优化，并能够管理大量通道。我们配置了持久化存储以防止重启时丢失通道状态，以及提高鲁棒性。RGB 附加数据（通常仅 1-2 KB）不会对现代网络构成瓶颈。

优化 WASM 与 UI 性能：

在客户端，我们也关注内存和 CPU 限制。虽然 WASM 提供接近原生的性能，但我们精心管理内存，避免长时间运行过程中出现内存泄露问题，从而拖慢浏览器响应。我们采用的 UI 框架高效更新仅需变更的部分，例如，仅更新转账后资产余额而非重绘整个页面。

综上，通过充分利用本地验证（降低集中式负载）、异步设计、缓存机制和与闪电网络事件的直接整合，我们的架构满足高性能要求，确保 RGB 智能合约的引入不会拖慢闪电支付的速度，反而能实现近乎实时的资产转移。我们的精心设计避免了流程中任何单个环节成为瓶颈。

  1. 实现方案：框架、数据库与工具

在前述设计的基础上，我们选择了一系列实用的框架、库、数据库及开发工具，确保我们的架构既具理论性又易于落地。

Rust 后端框架：

采用高性能且异步的 Web 框架 Axum。Axum 是新兴的轻量框架，能够与 Tokio 异步运行时良好集成，并便于定义 HTTP/JSON-RPC 路由。Rust 的异步能力（Tokio）使我们的后端能处理大量并发请求而不阻塞线程。我们同时采用 JSON-RPC 框架（结合 serde_json 与 HTTP 实现）来实现严格遵循 RGB 代理规范的 RPC 接口。Rust 强类型系统帮助我们明确定义 consignments、UTXO 信息等数据模型，从而减少运行时错误。

RGB 相关库：

为了避免重复造轮子，我们使用官方提供的 RGB 协议开发工具，如 rgb-std 和 rgb-core 库，这些库提供了构造与验证 RGB 合约和 consignments 的必要函数。这确保我们的钱包符合协议共识规则。由于这些库由 LNP/BP 协会和相关组织维护，并会在协议冻结时固化，因此其可靠性得以保证。在加密操作上，我们使用经过审计的 Rust 库，如 secp256k1（用于比特币签名）、curve25519-dalek（用于 Ristretto 点和 Bulletproofs）以及 bulletproofs 库，借助社区验证的代码及其底层优化，确保安全性。

闪电网络集成：

选择了 Rust-Lightning（LDK）库，因为它作为一个库而非完整节点，方便集成到我们的自定义后端中。LDK 使我们可以控制密钥管理，且其模块化设计非常适合构建闪电网络解决方案。

数据库与存储： 我们的后端需要存储少量数据，例如用户账户数据（仅用于备份 stash 的可选登录），我们使用 PostgreSQL。这样可以存储加密后的 stash 数据并与用户 ID 映射。对于比特币数据的高速查询，我们采用与 Electrum Server（如 Electrs）配合的专门存储，其内部使用 RocksDB 存储整个比特币索引，并通过 API 快速查询。对于临时存储 consignments，我们采用 Redis 键值存储，键为 consignments 的唯一标识，值为 consignments 数据。由于 consignments 数据通常体积较小且存储时间不长，负载不会过重。

前端存储：

利用浏览器提供的存储能力。我们将 stash 序列化为 JSON 或 RGB 定义的严格编码格式后存储于 IndexedDB，支持二进制 Blob 存储。我们还设计了允许用户将 stash 导出为文件的功能，适用于浏览器插件时使用扩展存储，或作为文件下载进行备份。

WebAssembly 工具链：

使用 wasm-bindgen 与 wasm-pack 将 Rust 代码编译为 WASM。我们的代码库结构化为核心逻辑库 crate，该库既用于编译成 WASM 部署于前端，也可作为后端二进制的一部分。通过条件编译（feature flags）我们针对不同环境启用不同模块。wasm-bindgen 生成与 JavaScript 的粘合代码，使得前端可调用 WASM 导出的函数。我们为 WASM 模块设计了一套清晰的 API，如 create_wallet(mnemonic)、get_balance(asset_id)、send_assets(params) 等，供 JavaScript UI 调用。我们也对这些接口进行了测试，确保在多种浏览器环境下正常运行。

前端 UI 框架： 我们选用了 React（配合 Material-UI），以提供简洁直观的用户体验。UI 主要处理非加密相关的操作，如表单输入、资产列表展示、二维码扫描等，然后将关键加密操作交由 WASM 模块处理。对于传递发票或 consignments，我们集成了二维码生成/解析库。

开发与测试工具：

我们利用 Rust 自带的测试框架对核心逻辑进行单元测试。在比特币及闪电网络集成方面，我们使用比特币 regtest 网络及轻量级闪电节点进行集成测试。我们利用 cargo test 搭配 feature flags，模拟 regtest 节点环境或内存中的比特币网络。我们在多种浏览器中测试了 WASM 的兼容性与性能，并使用 Puppeteer 工具自动化测试。为确保安全，我们对代码进行了审计，特别是加密部分，并使用 cargo fuzz 测试 consignments 的解析，尽早捕捉潜在漏洞。

持续集成与部署：

我们使用 GitHub Actions 对 Rust 原生代码和 WASM 目标进行构建与测试，确保跨平台的可靠性。CI 生成 WASM 构建包和后端 Docker 镜像，便于部署。我们将后端 Docker 化（包括 Rust 服务、bitcoind 等组件）有助于他人部署自己的实例。最终产品可分发为 Web 应用、浏览器插件，以及自托管后端二进制文件，供有需求的用户自行部署。

通过选择现代且成熟的框架和工具，我们确保项目具备高可靠性。Rust 与 WASM 的组合确保了性能与安全，RGB SDK 保证协议一致性，而结合 rust-bitcoin、rust-lightning 与 LDK 等成熟组件，则使整个系统站在了可靠技术的基础之上。这样的工具链不仅为我们提供了构建钱包的信心，也为后续的维护和扩展打下坚实基础。

  1. Avato Labs RGB非托管钱包开发路线图

2025年春季 - 2025年夏季

已完成工作（2024年秋季）

✓ 核心Rust代码库与WebAssembly框架搭建完成

✓ 钱包后端基本功能实现

✓ 初始原型验证与核心架构确立

2025年春季（Q1末-Q2初）：功能完善与创新技术开发

  • 用户界面与核心功能

    • 设计适合新手和专业用户的dashboard界面

    • 实现完整的钱包管理、资产转账与接收功能

    • 开发安全的本地stash加密和备份解决方案

  • 创新技术集成

    • 构建分布式stash存储架构，解决数据安全与恢复问题

    • 开发轻量级图数据库模块，优化RGB状态查询性能

    • 实现RGB合约发行工具，支持资产创建与管理

  • 安全与测试

    • 执行测试网集成测试与安全审计

    • 优化系统性能，确保在高负载下稳定运行

    • 进行用户体验测试，迭代改进界面设计

2025年初夏（Q2中-末）：主网发布与用户拓展

  • 正式发布

    • 主网版本上线，开放公众使用

    • 启动用户支持系统与教育资源

    • 开展社区建设活动

  • 技术迭代

    • 基于用户反馈持续优化产品体验

    • 扩展API功能，支持第三方集成

    • 巩固系统安全性，应对实际使用场景挑战

2025年盛夏（Q3-Q4）：生态拓展规划

  • 闪电网络集成规划

    • 设计RGB与闪电网络整合方案

    • 开发支付通道原型

    • 制定完整闪电网络功能路线图

  • 生态系统发展

    • 拓展战略合作伙伴关系

    • 探索更广泛的比特币Layer 2应用场景

    • 评估企业级需求，规划下一阶段发展

核心创新技术

  • 分布式stash管理：实现无需中心化服务器的安全数据存储与恢复机制，确保用户数据安全的同时保持去中心化本质。

  • 图数据库优化：通过专用图数据结构提升RGB状态转移的存储与查询效率，支持复杂资产历史可视化，降低验证计算资源消耗。

  • 零知识证明集成：强化交易隐私保护，实现资产转移的安全验证与最小信息披露。

  1. 尾声

Avato Labs 的 RGB 非托管钱包代表了比特币智能合约领域的重要突破，通过将 RGB 协议的去中心化与客户端验证优势与现代 Web 技术相结合，我们为用户提供了一个安全、高效且隐私保护的智能合约平台。该方案既保持了比特币的核心价值，又扩展了其功能边界，为比特币生态系统开创了新的可能性。

通过客户端数据控制、强大的隐私保护机制、高性能架构设计和闪电网络集成，Avato Labs 的钱包将成为 RGB 生态的重要基础设施，助力用户安全、便捷地参与这一创新技术。

我们坚信，RGB 协议将在比特币扩展性和功能性方面开辟新的篇章，而 Avato Labs 的钱包将在这一革命中扮演关键角色，为用户提供无缝、去中心化的智能合约体验。

1
Subscribe to my newsletter

Read articles from Charlie-D directly inside your inbox. Subscribe to the newsletter, and don't miss out.

AvatoRGBnoncustodialBTC

Written by

Charlie-D
Charlie-D