RGBDEX 集成 LSPS1、LSPS2 与 LSP 网络拓扑学习笔记
本文是 Stash Labs 集成 Bitlight Labs 提供的 RLN LSPS1、LSPS2 API 的产品侧集成记录，用来向社区分享产品研发进展，以及对未来方向的一些思考。本文不作为生产交付的确定性承诺，只作为学习笔记。
前言
对用户来说，最理想的闪电网络体验是「扫码、付款、到账」，不需要知道通道、容量、租期这些词。
对 LSP 来说，最理想的平台体验是「登记能力、设定价格、接单、结算」，不需要理解背后复杂的协议原理。
RGBDEX 的 LSP 功能，就是把这两件事做成同一个简洁的界面。
一、先看产品：LSP 在 RGBDEX 里是什么
RGBDEX 的 LSP 页面本身就是一个流动性市场，用户在这里能直接比较和购买。
- 服务商注册能力、设定费率、公开节点信息和可租容量；
- 用户浏览服务商，比较费率、容量、评分和成功率，再决定向谁租通道或开 JIT 发票；
- 平台负责登记、审核、展示、订单对账。
这张列表就是产品的入口。用户在这里看到的是「这个 LSP 有多少容量、收多少费、评分多少、当前能不能用」，协议规范都留在页面背后。查看地址：https://test.rgbdex.net/lsp.html
二、成为 LSP 的价值是什么？我们的结论：BTC/RGB 在自托管状态下也能生息
在闪电网络出现之前，BTC 几乎没有能生息的产品。链上没有能安全托管双边储备的借贷合约，中心化理财又要求把资产交出去。绝大多数 BTC 的唯一去处是冷钱包：安全，但完全静止。持有者为了安全付出的代价是收益——把资产放得越安心，它越不产生现金流。
闪电网络改变的不仅是支付速度，它把「流动性」本身变成了一种可以出售的资源：
- 收款方要有入站容量才能收钱，付款方要有出站余额才能付钱；
- 通道两侧的余额是有限的、有方向的，谁把资金锁在正确的一端，谁就能为别人的支付提供路径；
- 提供这条路的人收取路由费与开通道费，而资金始终留在自己的节点里。
关键在于：这门生意的本金不需要交给任何人。 把 BTC 存进中心化理财，或者放进链上合约池，资产控制权都要先交出去；LSP 的资产则一直在自己的节点通道里，收入来自提供流动性服务，托管权始终留在自己手里。这是闪电网络给 BTC 持有者带来的变化：自托管和流动性收入可以同时成立。
2.1 这门生意的潜力有多大？
据行业统计与运营测算，具备技术能力的 LSP 通过通道服务、JIT 开通道和流动性定价，可以把 BTC 资金做到约 2.5%–4% 的年化收入；对 RGB 这类早期风险资产，由于资产供给稀缺、通道需要垫付专仓资产、可服务的对手方更少，预估年化可以到 10%–30%。
有三点需要说清楚：
- 这些是估算区间，仅供参考。实际结果取决于资金规模、通道方向性管理、链上开闭通道成本和对手方的真实需求；
- RGB 的高区间对应的是高风险与低流动性：资产价格波动、资产名册与路径约束、需求不稳定，都会让实际收入明显高于或低于这个区间；
- 收益的前提是有人真的需要这条通道。没人用的容量只会变成成本。
但方向是明确的：在 RGB 闪电网络里，BTC 和 RGB 不再只能「存放」，它们可以在自托管状态下持续产生现金流。
2.2 为什么 LSP 会成为生态里最重要的一环
把上面两件事放在一起看，LSP 的位置就很难被替代：
- 它是所有资金的入口。 用户要收 RGB 资产，就得先有承载该资产的入站容量；没有 LSP 垫付另一侧储备，资产名册再完整也换不成能收款的通道。
- 它是资本、定价和风险的汇合点。 容量按时间定价、JIT 按笔定价、RGB 按资产定价，风险溢价也在这里被定价和分散，由市场上的多个参与者共同承担。
- 它是网络效应的来源。 一个 LSP 只能服务自己的对手方；多个 LSP 组成网络之后，一条通道的价值能被整个生态复用。
也正因为如此，LSP 是 RGB 闪电生态最底下的一层，AMM 和订单簿也建在这一层上。通道市场解决「钱能不能进来」，有了进来的钱，订单簿和 AMM 才有意义。
2.3 目标：让非技术用户也能拿到这份收益
上面的年化区间有一个隐含前提：你得会跑节点、会管通道方向性余额、会算链上开闭通道的成本、会在需求消失时及时关掉低效通道。这是技术门槛，和资金规模关系不大。目前这份收益只属于极少数有能力自己运营节点的人，绝大多数持币者被挡在门外。
Stash Labs 的目标就是把这道门槛拆掉：
- 用户不需要自己跑节点，也不需要理解通道方向性，就能通过 LSP 服务让自己的 BTC 与 RGB 资产参与流动性供给；
- 服务商不需要理解背后复杂的协议原理，也不需要自建运营后台，只要注册能力、设定价格、处理订单；
- 平台不托管任何一方的资金，只负责把「谁有流动性、谁需要流动性、价格是多少」做成可比较、可交易、可追责的界面。
2.4 为什么 RGB 更适合走 LSP 网络
RGB 采用客户端验证：资产状态由持有者在本地维护，链上只留下密码学承诺。它没有 Ethereum 那样的全局合约状态，也就不存在一个能托管双边储备的「公共池」。
这带来一个直接的产品结论：
传统 LP：用户把资产存进链上合约 → 链上合约控制资金
LSP：LSP 用自己的节点和通道提供流动性 → 平台负责撮合与展示所以在 RGBDEX 上，流动性来自一张由独立节点组成的网络，平台资产负债表不承担这个角色。平台的价值在于让这张网络可发现、可比较、可交易，同时把资金留给各自的持有者。
三、底层能力从哪里来：基于 Bitlight Labs 的 RLN
LSPS1、LSPS2 起源自闪电网络社区（bLIP-51 / bLIP-52），由 Bitlight Labs 在 RLN 中结合 RGB 协议实现。RGBDEX 的 LSP 产品对接的正是这层能力，把它们做成 RGBDEX 里可注册、可定价、可购买的服务。
| 本文涉及的分工 | 提供方 | 具体做什么 |
|---|---|---|
| 协议实现与节点能力 | Bitlight Labs（RLN：RGB 闪电网络节点） | LSPS0 传输、LSPS1 通道订单、LSPS2 JIT 报价与出票、RGB 通道与资产状态 |
| LSP 市场与运营界面 | Stash Labs / RGBDEX | 能力注册、定价与审核、公开列表、订单对账、钱包签名回执、平台授权 |
LSPS0 的传输层跑在闪电节点之间的 P2P 连接上，浏览器里的 HTTP 请求做不了这件事。这个技术细节对产品很关键：钱包本身得是一个闪电节点，或者内嵌一个节点，才能发起 LSPS 请求。RGBDEX 的界面把这层复杂度藏在钱包和云节点后面，用户只需要点「购买」或「生成发票」。
四、一个能力，两种卖法：LSPS1 与 LSPS2
在 RGBDEX 里，服务商注册的是一个叫 Channel Capacity（通道容量） 的能力，LSPS1 和 LSPS2 是同一个能力下的两种交付方式，两种可以同时启用：
| LSPS1：提前租通道 | LSPS2：JIT 即时通道 | |
|---|---|---|
| 用户什么时候付钱 | 先付钱，LSP 再开通道 | 先出票，付款到达时才开通道 |
| 适合什么场景 | 稳定、可预测的收款 | 第一次收款、低频收款、先收到再说 |
| 收费基准 | 通道容量 + 租期 | 单笔付款金额（比例费 + 最低费） |
| 通道形态 | 可公告、有租期、可指定确认数 | 0 确认、不公告、私有通道 |
| 用户拿到什么 | 一段时间内的确定性入站容量 | 一张现在就能付的发票 |
把两者放在同一个能力里，是因为服务商卖的其实是同一件东西：入站流动性。区别只在交付时点。
LSPS1：把容量按时间租出去
LSPS1 的产品语言是「租」。服务商在能力配置里设定容量费、租期，以及这条通道允许多大的余额区间；系统再根据租期是否到期决定通道的去留。
这些设定最终会变成用户在 LSP 公开页上看到的报价条件。用户不用理解通道内部参数，只需要知道「这条通道能租多久、总共要付多少」。
LSPS2：把开通道的时点推到付款到达
LSPS2 的产品语言是「先出票，后开通道」。服务商主要配置两件事：每笔付款按多大比例收开通道费（含最低收费），以及愿意接受多大的付款金额范围。
这里最容易被误解的一点是：出票时并不会立刻开通道。 用户拿到发票时，通道数仍然是 0；只有付款方的 HTLC 到达 LSP，LSP 才会拦下这笔付款，开一条 0 确认通道，再把钱转给收款方。发票里的 SCID 指向一条还没开出来的通道，只是先在发票里占了个别名。
对用户来说，这带来两个能感知到的结论：JIT 发票有有效期，过期了要重新报价；没被付款的发票会暂时占住 LSP 已经备好的流动性，所以服务商要限制同一时间能挂出多少张，并及时把久未付款的收回去，才能继续服务下一位用户。
用户侧：Alice 看到什么
Alice 打开 LSP 详情页，看到一张能力卡和三个动作：
Rent BTC inbound channel/Rent RGB inbound channel：走 LSPS1 租通道；Open BTC JIT Invoice/Open RGB JIT Invoice：走 LSPS2 生成 JIT 发票；Connect node和Open channel：把自己的节点接入 LSP，或者手动开通道。
LSPS1 的购买框先让用户填容量和租期。页面上写得很清楚：浏览和报价只读取 LSP 的卖家配置，不会访问用户节点；只有确认下单时才会打开 Stash Wallet。
报价页把费用拆成 Fee、Channel starting balance、Amount to pay、租期和保护截止时间。产品上特意写明「起始余额属于用户自己的通道余额，不算平台手续费」，免得用户把它当成平台收费。
RGB 通道租赁多一步选资产。页面说明 LSP 在通道另一侧垫付资产并收取年租，报价里同时列出 LSP-funded asset 和 Asset rent。这对应产品边界：用户租到的是租期内的资产通道使用权，资产本身仍归持有人所有。
LSPS2 更简单：用户只输入要收多少钱，页面给出预估的 LSP 费用和发票有效期。点了 Create JIT Invoice 才会唤起钱包；出票时通道仍然是 0，付款到达后 LSP 才开通道。
RGB JIT 则是让用户输入要收的资产数量，系统自动算出 BTC carrier amount 和 channel fee cap，并提示最终报价以钱包为准。
整套用户流程里，用户碰不到协议层的术语，也不用关心通道租期怎么换算。产品把协议参数翻译成容量、费用、租期和有效期，签名动作留给钱包。
五、运营一个 LSP：从配置到结算
服务商进入个人中心的 LSP Console，看到的是自己的经营面板：状态、评分、收益、节点公钥，以及能力、订单、流动性、通道，都在同一处管理。
5.1 配置能力
点「Edit configuration」会重新走一遍审核向导。改价格、余额区间、租期或 JIT 参数，都会先生成一份新的待审核能力，审核通过后才替换线上报价。
5.2 查看 LSPS1 订单
LSPS1 的订单列表直接对应 RLN 节点的订单状态：已完成、待付款、开通道中、失败，以及「结果未知」。
「结果未知」是 LSPS1 里必须认真对待的状态：钱包没有返回订单结果时，平台会留一条待对账记录，等钱包回执确认后再定状态。下单重试可能开出两条通道，这比慢一点更糟。
5.3 查看 LSPS2 JIT 账本
LSPS2 没有节点侧的订单列表，RGBDEX 会为每一笔 JIT 付款记一条账本，逐笔对账。
这张表回答的是服务商最关心的问题：我出了多少张 JIT 发票、其中多少已经付款、每笔收了多少开通道费、发票还有多久过期。
5.4 管理流动性与通道
能力列表下面是真实的资产与通道视图。流动性来自 LSP 自己的节点余额，编辑流动性等于重新声明可服务的数量。
5.5 对外展示
服务商的公开页把能力、价格、节点信息、评分和通道状态放在一起展示，用户可以直接在这里发起购买。
六、授权边界：平台能代操作什么
RGBDEX 把节点分成两类：
- 用户节点：平台不能直接调用，也不能代理操作。所有读写都由 Stash Wallet 在用户会话里直接发起，后端只接收钱包返回的数据或签名回执，再做验签、校验和记账。
- LSP 节点：平台可以在钱包签署的授权范围内代操作。这个授权限定 API 白名单、有有效期、可随时撤销，而且只覆盖卖家侧接口。
涉及资金的操作用长期授权覆盖不了，每一笔都要钱包当场签名。LSPS1 下单时，钱包读取买家节点并生成签名回执，平台拿回执和 LSP 卖家节点的订单账本核对，买家节点的读取权始终留在用户手里。
这条边界落到用户身上其实就一句话：平台能帮你展示和撮合，但只要动到钱、或者要读你的节点，都得经过你的钱包。
七、拓扑演进：从一条通道到一个网络
LSPS1 和 LSPS2 只规定「用户与 LSP 之间」怎么交互，不管 LSP 与 LSP 之间怎么连。网络里不止一个 LSP 之后，问题就从「怎么开通道」变成「钱怎么走到收款方」。
7.1 四个阶段
| 阶段 | 解决什么 | 代价 | 什么时候进入下一阶段 |
|---|---|---|---|
| 直连 | 简单、可控 | 对手方一多就维护不过来 | 通道数量超过团队运维能力 |
| 单环 | 减少通道数量 | 一条边故障会让大量路径被迫绕行 | 需要冗余和故障切换 |
| 双 Hub | 降低小 LSP 接入成本 | 流动性集中在 Hub | Hub 成为流量和资金瓶颈 |
| 核心 Mesh / 混合 | 降低 Hub 压力、增加冗余 | 资金和运维成本高 | 大 LSP 流量足以支撑直连 |
直连：每两个 LSP 之间都有一条通道
四个 LSP 需要六条通道；推广到 N 个 LSP，就是 N × (N - 1) / 2 条。它的好处是路径短、状态可控；坏处是每多一个对手方，运维和资金占用都跟着线性上升。
单环：把所有 LSP 串成一个环
四个 LSP 只需要四条通道，比全直连少。但任意两点之间只能沿环绕行，一条边出问题，大量路径就得改走另一侧，容量和延迟一起变差。
双 Hub：小 LSP 通过两个 Hub 接入
小 LSP 不再两两直连，只要接入 Hub 就行。接入成本降下来了，但流量和流动性会往 Hub 集中；Hub-A 和 Hub-B 之间的主链路，决定了故障切换到底有没有意义。
核心 Mesh / 混合：核心直连，边缘走 Hub
大 LSP 之间用 Partial Mesh 保留直连和冗余，小 LSP 继续通过 Hub 接入。这样「核心要容量和故障切换」和「边缘要低接入成本」两个问题同时解决，代价是运维复杂度最高。
7.2 产品视角下的拓扑
拓扑直接影响产品体验，它的价值远不止把图画得好看：
- 发现：用户能不能在列表里找到有容量、费率合适的 LSP；
- 报价：不同 LSP 的容量、租期、JIT 费率能不能放在一起比；
- 方向性：通道「有余额」不等于「这个方向能付款」，每一跳都要有正确的出站余额和入站容量；
- 故障切换：一个 Hub 没钱了，另一条路径上得真有可用余额，图上画的线本身不提供流动性。
现实中稳定的形态通常是第四种：边缘用 Hub 降低接入门槛，核心用 Partial Mesh 提供冗余和容量。对 RGB 来说还多一层约束：路径上每一跳都要有对应资产，所以「有 BTC 流动性」不等于「能完成 RGB 支付」。
7.3 双 Hub 的真正难点
双 Hub 的关键价值，在于两个 Hub 的流动性状态并不同步。如果它们总被同一批收款方抽干同一侧，故障切换的路径还在，但两条路都没钱。
处理顺序从便宜到贵：
① 换路 → ② 再平衡 → ③ 调容量预算 → ④ 关低效通道这也是 LSP Console 里「通道」和「流动性」要分开看的原因：通道数量代表供给规模，方向性余额才决定可用性。
八、下一步：从通道市场到交易市场
LSP 网络是 RGBDEX 流动性的来源，也是通往更大产品图景的起点。接下来的产品路线会沿着「先形成市场，再连接生态」推进：
- FlashDEX 订单簿：先让 RGB 资产在订单簿里形成价格和深度；
- AMM Swap：等市场流动性建立起来，再用曲线池承接更连续的兑换需求；
- 统一报价接口与 RFQ 适配：把 FlashDEX 订单簿和 AMM Swap 的报价封装成通用接口，并适配 Bitlight Labs 实施的 RFQ，让钱包、做市商和其他生态应用用同一套接口拿到报价和成交路径。这样 Stash Labs 的产品才能走向开放，为整个生态提供流动性；
- LSP 能力基础设施化：进一步研究怎么把 LSP 能力从 RGBDEX 的内部产品，开放成生态可接入的 LSP 流动性基础设施，让其他钱包和交易场景也能复用。