Stash Cloud：从专有解决方案到通用云 RLN 基础设施

在过去接近一年的时间里，Stash Cloud 完成了从「服务自有产品的专用基础设施」到「面向 RGB 闪电网络行业的云 RLN 基础设施」的演进。这篇文章记录了我们在这一过程中遇到的核心技术挑战、做出的关键设计决策，以及为什么我们认为这些选择对整个 RGB 生态都有价值。

一、为什么要做这件事

最初的定位

Stash Cloud 最初是为 Stash Wallet、RGB Dex、Flash Dex 三个自有产品量身定制的云 RLN 服务。RGB 协议采用客户端验证模型，资产状态由每个用户在自己的节点上本地维护和验证——这意味着大规模节点运行、生命周期管理、节点安全策略是 RGB 生态从概念走向生产的前提。

我们投入了一支具有十年以上 DevOps 经验的团队，基于开源 Kubernetes 从零搭建了这套基础设施。它解决了 RGB 闪电节点运维的核心难题：

自动化生命周期管理 — 创建、启动、休眠、恢复由平台编排完成
弹性伸缩（Scale to Zero） — 休眠期间零计算消耗；唤醒无需重同步链上状态，通常在分钟内恢复运行
百万级在线 + 千万级离线 — 多集群架构可支撑大规模并发与海量离线存储
信任最小化安全架构 — 节点级隔离、独立磁盘、加密存储

演进的契机

经过接近一年的实践与架构演进，我们发现一个事实：这套基础设施能力不仅能服务好我们自己的三个产品，也同样能够服务整个 RGB 闪电网络生态的其他项目与开发者。

Kubernetes 的控制平面与工作节点分工、声明式工作负载、网络策略与存储编排——这些能力对应的是 RGB 节点通用的基础需求，而不是某个特定产品的专有技术。

更重要的是，我们意识到：RGB 生态的发展需要降低运维门槛。小型团队不应该因为无力搭建和维护节点基础设施，就被挡在 RGB 应用开发的门外。

目标

将 Stash Cloud 从「服务自有产品的专用基础设施」升级为「面向 RGB 闪电网络行业的云 RLN 基础设施」：

任何 RGB 生态的项目与开发者都能用标准管理 API（/v3）快速接入云节点能力
无需自建运维团队，专注于应用层产品开发
保持信任最小化安全架构，用户数据所有权始终归属助记词持有者

二、从专有到通用：核心挑战与解决方案

将专用基础设施升级为通用云 RLN 基础设施，不是简单地「开放 API」就能完成的。我们需要在成本、安全、灵活性之间找到平衡点，并确保架构设计能够支撑生态级的规模。

2.1 挑战 1：基于开源 Kubernetes 开发，而非托管 K8s 服务

问题

托管 K8s 服务（如 AWS EKS、Google GKE、阿里云 ACK）提供了开箱即用的集群管理，为什么我们选择从零搭建自管理集群？

要回答这个问题，先回到 Kubernetes 官方对集群架构的划分（参见 Kubernetes 架构与组件概述）：

层次	核心组件	职责
控制平面（Control Plane）	`kube-apiserver`、`etcd`、`kube-scheduler`、`kube-controller-manager`、可选的 `cloud-controller-manager`	集群全局决策：接收声明式 API、持久化集群状态、调度 Pod、运行控制回路、对接云厂商
工作节点（Node）	`kubelet`、`kube-proxy`（或等价网络实现）、容器运行时（如 containerd / CRI-O）	在机器上实际拉起并维护 Pod，提供运行时与节点网络规则
插件（Addons）	集群 DNS、CNI 网络插件、监控与日志等	为 Service 发现、Pod 互通、可观测性提供集群级能力

生产环境中，控制平面通常跨多台机器部署，工作节点也按规模横向扩展，以提供容错与高可用。托管 K8s 的典型做法，是把控制平面抽象成云厂商托管服务——运维负担更低，但对调度器、存储类、网络策略与控制回路的深度改造空间也更小。

官方文档也明确指出：Kubernetes 不是传统的包罗万象 PaaS。它在容器层提供部署、扩缩、负载均衡等能力，但默认方案大多是可选、可插拔的；平台方保留对存储、网络、调度与扩展点的选择权。Stash Cloud 要做的正是在这个底座上构建面向 RGB 节点的专用平台能力，而不是被托管模板锁死。

因此我们的取舍是：

成本：托管服务的管理费用高昂，按节点数收费的模式在百万级节点规模下难以承受。

灵活性：RGB 闪电节点的独特需求——独立磁盘、节点级网络隔离、差异化生命周期策略（user 节点 48 小时无活跃自动休眠，LSP 须显式授权后保活，Hub 节点 7×24 常驻）——难以在托管服务的标准模板下实现，无法根据 RGB 闪电节点的特有场景进行定制改造优化。

控制权：我们需要完整掌控控制平面与节点组件的部署与策略，才能实现「百万级在线 + 千万级离线」的弹性伸缩。这要求对调度决策、存储类、网络策略乃至控制器行为进行深度定制——而这些恰恰是托管控制平面最不开放的部分。

解决方案

基于开源 Kubernetes（https://github.com/kubernetes/kubernetes）从零搭建自管理集群，让控制平面与工作节点都在我们自己的运维边界内：

控制平面侧：声明式 API + 可扩展控制回路

对外与对内编排统一走 kube-apiserver：节点创建、休眠、唤醒、删除都表达为期望状态，由控制器持续收敛，而不是一次性脚本
集群状态落在高可用 etcd；生产环境必须有明确的 etcd 备份与恢复预案（官方架构文档同样强调这一点）
kube-scheduler 负责把尚未落点的 Pod 绑定到合适工作节点；调度会综合资源需求、亲和 / 反亲和、数据位置与策略约束——我们据此区分用户节点、LSP 节点与 Hub 节点的放置与生命周期
kube-controller-manager 内的控制回路（如 Node、Job、EndpointSlice、ServiceAccount 等）负责故障响应与对象联动；云侧能力若需要，再通过 cloud-controller-manager 与云厂商 API 解耦集成
Kubernetes 本身支持自定义调度器、CRD 与 API 聚合；我们在不改上游源码的前提下，把 RGB 节点语义扩展进平台

工作节点侧：kubelet + 容器运行时承载有状态负载

每个工作节点上的 kubelet 按 PodSpec 保证容器处于运行且健康
容器运行时（containerd 等）负责容器生命周期；节点网络由 CNI 插件分配 Pod IP，并由 kube-proxy（或插件等价实现）维护 Service 相关网络规则
RGB 闪电节点作为有状态工作负载，使用 StatefulSet：为每个 Pod 保留稳定、唯一的标识与持久存储。与 Deployment 不同，StatefulSet 中的 Pod 不可彼此替换；Pod 重建后仍能通过稳定 ID 重新挂回原来的卷——这正是「休眠后唤醒无需重新同步链上状态」的架构前提

深度定制存储类（StorageClass）：

每个节点独占一块云盘，reclaimPolicy: Retain 确保删除节点后磁盘不自动回收
支持动态扩容，根据节点数据增长自动扩展磁盘容量
磁盘快照定时备份；节点在线期间即将加密异地副本异步存到 Arweave 与 IPFS

深度定制网络策略（NetworkPolicy）：

默认拒绝所有内网流量，节点间完全隔离（包括同一租户下的节点）
所有节点通信统一走公网域名，避免白名单配置错误导致的安全漏洞

深度定制调度与生命周期策略：

user / lsp / hub 分别遵循不同的生命周期策略
user 节点连续 48 小时无管理 API 或运行时访问则自动休眠（Scale to Zero），释放 CPU 和内存；StatefulSet 缩容到 0 时计算资源释放，关联卷按策略保留。应用也可主动 stop，不必等到 48 小时
LSP 须显式授权，不会在注册钱包或创建 user 节点时自动转换；授权期间豁免空闲回收
Hub 节点 7×24 常驻，不受空闲回收影响

自研节点编排服务：

对集群能力做场景化封装，对外只暴露 RGB 节点管理语义（开发者面对的是「节点」，而不是裸的 Pod / PVC）
通过 API 服务器写入期望状态，再由控制平面收敛到实际状态
实现节点生命周期管理（创建/启动/停止/删除）与数据导出任务编排

技术栈与架构映射：

开源 Kubernetes 1.30+（自管理控制平面 + 工作节点）
  ├── Control Plane
  │     kube-apiserver / etcd / kube-scheduler / kube-controller-manager
  ├── Node
  │     kubelet + container runtime + CNI（+ kube-proxy 或等价实现）
  ├── 工作负载：StatefulSet（稳定标识 + 持久卷 + 有序扩缩）
  ├── 存储：自定义 StorageClass（独立磁盘，reclaimPolicy: Retain）
  ├── 网络：NetworkPolicy（默认拒绝，节点间内网隔离，统一走公网）
  └── 节点编排服务
        └── 生命周期（创建 / 启动 / 停止 / 删除）→ 声明式期望状态

成果

成本降低 60%+（相比托管 K8s 服务）：控制平面自管后的管理费用节省、资源利用率提升（Scale to Zero）、存储成本优化（按需扩容）。

多集群架构可支撑 100 万+在线节点、1000 万+离线节点存储：这是控制平面水平扩展（例如可多实例部署的 kube-apiserver）、工作节点横向扩容与成本控制共同给出的容量目标，而不是单一集群的当前在线普查。

节点启动时间从小时级降低到分钟级：通过 Scale to Zero + StatefulSet 稳定标识与持久卷，休眠节点唤醒时无需重新同步区块链数据，直接恢复到休眠前状态。

2.2 挑战 2：节点间的内网隔离——即使同一租户下也完全隔离

问题

传统多租户场景通常只隔离外网访问，内网可能共享（如微服务内部调用）。但 RGB 闪电节点场景要求绝对的节点级网络隔离：

即使在同一 K8s 集群内，即使属于同一租户（开发者/项目方），节点 A 也不能访问节点 B
闪电网络节点的敏感端口（RPC、P2P）一旦暴露给其他节点，存在攻击风险
租户的概念是给开发者/项目方的，但安全隔离的粒度必须下沉到每个独立节点：同一租户下的不同节点之间也不能内网互通

在 Kubernetes 默认模型里，同一集群内的 Pod 往往可以通过 CNI 分配的 Pod IP 与集群 DNS / Service 彼此发现——这对微服务很友好，但对「节点即安全边界」的 RGB 场景是风险面。

解决方案

Kubernetes NetworkPolicy（依赖支持策略的 CNI）：

NetworkPolicy 在 IP / 端口层面（OSI 第 3/4 层）约束 Pod 与其它实体的通信。官方模型区分 Ingress（入站）隔离 与 Egress（出站）隔离：默认 Pod 在两个方向上都是「非隔离」的（允许所有连接）；一旦有策略选中该 Pod 并声明对应 policyTypes，则只允许策略显式放行的流量。策略是相加的；要从源 Pod 连到目的 Pod，双方的出口与入口策略都必须允许。

我们的落地方式：

为每个租户使用独立的命名空间（Namespace），并在命名空间内为节点 Pod 下发策略
默认拒绝未显式允许的内网 Ingress / Egress：把「节点间内网互通」从默认能力变成禁止能力
节点 A 的 Pod 无法依赖集群内 Service DNS / Pod IP 访问节点 B
即使属于同一租户的节点也完全隔离；节点间业务通信统一走公网域名
重要前提：NetworkPolicy 必须由支持策略实施的网络插件生效——只创建资源对象而无控制器，不会产生隔离效果

独立域名：

每个节点获得独立的二级域名：{node-id}-{network}.stashcloud.net

域名在创建节点时自动分配，无需额外配置
租户凭证与节点归属在访问时校验（管理 API 为 Bearer API Key）
跨租户访问请求在编排层被拒绝，不会到达节点 Pod

设计哲学：

虽然统一走公网带来了额外的带宽与流量开销，但不依赖内网白名单才是安全的基石。集群 CNI 仍然存在；我们用 NetworkPolicy 把节点 Pod 之间的集群内路径默认拒绝，业务只走公网域名。

内网互通意味着需要维护复杂的白名单规则（哪些节点可以访问哪些节点、哪些端口可以放行）。一旦配置错误——比如白名单范围过宽、规则更新不及时——就可能产生安全漏洞。

完全禁止内网通信，让所有节点通过公网域名访问，虽然成本略高，但安全模型更简单、更可靠：

无需白名单管理 — 没有复杂的规则配置，也就没有配置错误的风险
攻击面最小化 — 即使攻击者拿到某个节点的访问权限，也无法通过集群内网横向移动到其它节点 Pod

架构示意：

外网请求
  → Ingress / 节点编排服务
       └── 管理 API /v3：Bearer API Key + 租户归属校验
  → 目标节点所在工作节点上的 Pod
       └── NetworkPolicy（Ingress/Egress）
             拒绝节点 Pod ↔ 节点 Pod 的集群内网路径
             （包括同一 Namespace / 同一租户）

成果

实现真正的「信任最小化网络架构」（Trust-Minimized Network）：默认拒绝、最小权限、显式校验——与 Kubernetes NetworkPolicy「未声明即不放行」的隔离模型一致。

即使攻击者获得某个租户的 API Key，也无法访问其他租户的节点：归属校验在 Ingress 层完成，跨租户请求被拒绝。

节点级隔离：即使同一租户下的不同节点也完全隔离，单节点被攻破不会影响该租户下的其他节点。

通过完全禁止内网通信的极简策略，避免白名单配置错误导致的安全漏洞：无规则，无错误。

虽然带来额外带宽成本，但换来更简单、更可靠的安全模型：这是我们认为值得的权衡。

2.3 挑战 3：独立磁盘 + 禁止共享存储

问题

RGB 闪电节点的持久化数据（通道状态、RGB 资产状态、链上 UTXO 集）极其敏感。一旦数据泄露或损坏，用户可能永久丢失资产。

共享存储的风险：

传统云环境中，共享存储（如 NFS、Ceph）是常见选择——多个节点挂载同一块网络盘，降低存储成本。但这在 RGB 节点场景下存在严重问题：

跨租户数据泄露风险 — 共享存储的权限管理依赖文件系统 ACL，一旦配置错误，租户 A 可能读取到租户 B 的数据
性能瓶颈 — 共享存储的 I/O 性能远低于独立云盘，节点磁盘延迟直接影响闪电网络支付速度与通道管理效率
故障影响面大 — 共享存储单点故障会影响所有挂载的节点

解决方案

Kubernetes 的存储编排把「谁声明需要盘」与「谁真正提供盘」拆开，正好支撑我们的独立磁盘模型：

对象	含义
PersistentVolumeClaim（PVC）	工作负载声明需要的存储容量与访问模式
PersistentVolume（PV）	集群中实际可用的存储卷
StorageClass	动态制备规则：云盘类型、扩容能力、`reclaimPolicy` 等

独立 PVC + 独立 PV：

每个 RGB 节点创建时，由 StorageClass 动态制备一块独立云盘，并绑定到该节点 StatefulSet Pod 的 PVC
StorageClass 设置 reclaimPolicy: Retain：释放声明后卷不被自动回收，数据保留
访问模式限定为 ReadWriteOnce：磁盘只能被单个节点 Pod 独占挂载，从卷绑定层面隔离其它租户
这与 StatefulSet 的设计一致：官方说明删除或缩容 StatefulSet 默认不会删除关联存储卷，正是为了保全有状态数据——我们把它当作产品级软删除 / 休眠策略的基础，而不是意外副作用

禁止共享存储：

代码层面硬约束：禁止使用 ReadWriteMany 类型的 PVC
所有节点磁盘均为 ReadWriteOnce（单 Pod 独占）
不把多租户节点挂到同一块网络文件系统上「省钱」

磁盘保留策略：

节点休眠（Scale to Zero）时：StatefulSet 释放计算资源（Pod），PVC / PV 保留
节点删除：仅删除计算资源（Pod、StatefulSet）；热数据盘与备份按统一策略保留，不会清除持久化数据
异地副本：节点在线期间即异步加密上传到 IPFS 与 Arweave。节点删除后，IPFS 副本再保留 180 天，作为平台侧额外恢复窗口，180 天后写入到 Arweave，Arweave 一旦写入即永久保存
数据所有权归属：节点数据属于助记词的持有者（用户），而非任何开发商或平台
用户可通过数据导出功能自行下载磁盘归档，迁移到自托管环境

成果

磁盘 I/O 性能提升 10 倍+（相比共享存储）：独立云盘的 IOPS 和吞吐量远高于网络共享存储。

物理隔离杜绝跨租户数据泄露：每个节点的磁盘在云平台层面就是独立的 PV，不存在共享文件系统 ACL 配错的可能。

支持节点数据自主导出，用户真正拥有数据所有权：见博客《从云托管到自托管：我们如何把节点数据的所有权交还给用户》。

节点删除只回收计算 + 长期异地副本：删除后仍可从保留的 PVC、快照或异地副本恢复；IPFS 在删除后再保留 180 天。这与 Kubernetes「有状态负载优先保数据」的存储语义一致，并在平台层补齐了备份与所有权边界。

2.4 挑战 4：权限管控——API Key 作用域与密钥安全责任

问题

传统云服务通常使用账号密码或 OAuth 鉴权，但闪电网络钱包场景要求无 KYC、无平台账号密码。终端用户在 Stash Wallet 创建钱包，不等于再注册一个 Stash Cloud 账号。第三方开发者用钱包签名登录即可获得 API Key。同时需要细粒度权限：同一租户下可能有多个 API Key，分别用于只读、创建节点、删除节点。

更重要的是，用户需要清晰理解：Stash Cloud 只提供计算与存储基础设施，助记词与私钥始终由用户自行保管。不要误以为平台可以「帮我找回丢失的私钥」。

解决方案

API Key 的角色与使用场景：

API Key 是项目方/开发者用于替代用户申请钱包节点的凭证，而非用户自己的助记词
典型场景：钱包应用通过 API Key 为每个用户创建专属节点，用户的助记词需由用户自行保管
管理 API（/v3）作用域：nodes:read、nodes:write、nodes:delete（不是 read:nodes）
平台仅存储 Key 的哈希值（SHA-256），不保存明文

密钥保管说明：

Stash Cloud 为非托管基础设施：助记词/私钥由用户自行保管，平台不代管、不代签、不动用节点资金
若第三方应用自行保管用户助记词，属于该应用的产品策略，与 Stash Cloud 无关；接入前请向该应用确认密钥保管方式

Stash Cloud 的数据与责任边界：

Stash Cloud 提供的云 RLN 服务与云厂商提供的云服务器一致：仅提供计算与存储基础设施。

基础设施层隔离 — 每个节点独占命名空间与云盘，节点间网络默认拒绝，单节点被攻破不会横向波及其他节点
平台不具备代持资金的能力 — 节点身份私钥与内部访问令牌不写入 API 响应或日志；平台不代节点签名，也不动用节点资金
助记词/私钥由用户与开发者自行保管，丢失后无法通过 Stash Cloud 协助找回

这一责任边界设计至关重要：

责任主体	负责范围
Stash Cloud	基础设施安全（节点计算、磁盘存储、网络隔离、备份机制）
用户/开发者	密钥保管（助记词/私钥的生成、存储、备份、恢复）

管理 API 鉴权（/v3）：

请求头携带 Authorization: Bearer <API_KEY>，平台校验：

Key 哈希是否存在于数据库
请求的节点是否归属于该 Key 所属租户
Key 的作用域是否覆盖当前操作（如删除节点需要 nodes:delete）

Kubernetes 命名空间 + RBAC（与控制平面鉴权模型对齐）：

Kubernetes 用 Namespace 做资源隔离边界，用 RBAC（Role / RoleBinding，必要时 ClusterRole）约束「谁能对哪些 API 资源做什么」。我们的编排组件遵循同一最小权限原则：

平台编排组件仅授权访问节点所在命名空间，不授予集群级（ClusterRole）写权限
以最小权限精确控制可操作的资源类型（StatefulSet / Pod、PVC、NetworkPolicy 等）
禁止「全能」服务账号：即使编排服务被攻破，也难以横向操作其它命名空间的节点资源
对外开发者 API 的作用域（nodes:read / nodes:write / nodes:delete）与对内 K8s RBAC 分层：前者约束租户能做什么，后者约束平台组件在集群里能碰什么

成果

实现「无 KYC、无平台账号密码」的信任最小化鉴权：开发者通过钱包签名登录即可获得 API Key，无需提供个人信息。终端用户只在钱包里创建钱包，不单独注册 Stash Cloud。

API Key 泄露后可快速吊销，不影响其他 Key：每个 Key 独立管理，粒度细到单个 API Key。

清晰的责任边界：平台负责基础设施安全，用户/开发者负责密钥保管——这是信任最小化架构的延伸，也是用户数据所有权的真正体现。

三、从 RGB 专用到通用云 RLN 基础设施：标准化 API

向第三方开发者暴露标准 RESTful 管理 API，而非直接操作 K8s。基址示例：https://api.stashcloud.net（mainnet）。network 由实例绑定，不要放在创建请求体里。节点实现是 rgbldkd；type 只能是 user / lsp / hub。完整契约见管理 API。

端点	方法	说明
`/v3/nodes`	POST	创建节点（`label` / `type` / `wait`）
`/v3/nodes/{id}`	GET	查询节点（含 `provisioning` / `running` / `stopped` / `deleted` 等）
`/v3/nodes/{id}/start`	POST	启动休眠节点
`/v3/nodes/{id}/stop`	POST	停止节点（PVC 保留）
`/v3/nodes/{id}/export`	POST	导出节点数据（须先锁定节点；归档不含私钥）
`/v3/nodes/{id}/lsp/authorize`	POST	显式授权为 LSP
`/v3/nodes/{id}`	DELETE	删除节点（仅回收计算；磁盘与备份按统一策略保留）

鉴权：管理 API 使用 Authorization: Bearer <API_KEY>，并校验节点归属。

文档：管理 API 以本站 Stash Cloud API 为准。运行时 OpenAPI 见 rgb-ldk-api-public。

四、安全设计：信任最小化架构的五层防护

API Key 鉴权：管理 API 为 Bearer + 哈希存储，泄露后可单独吊销
节点级隔离：K8s Namespace + NetworkPolicy（Ingress / Egress 默认拒绝），节点间不走集群内网（包括同一租户），业务统一走公网域名
独立磁盘：每个节点独占 PVC / PV（ReadWriteOnce + reclaimPolicy: Retain），禁止共享存储
独立域名：{node-id}-{network}.stashcloud.net，访问时校验节点归属
RBAC 约束：平台编排组件仅能操作节点命名空间，无集群级写权限；对外 API 作用域与对内 RBAC 分层

额外保障：

节点在线期间即异步备份到 Arweave + IPFS（Arweave 一经写入即永久）
删除节点：计算资源立即释放，热数据盘与备份按统一策略保留；删除后 IPFS 副本再保留 180 天
数据所有权归属用户：节点数据属于助记词持有者，而非开发商或平台
用户可随时导出节点数据，迁移到自托管环境（见《从云托管到自托管》）
即使平台完全下线，用户通过「助记词 + 备份文件」仍可自行恢复节点
重要提示：助记词/私钥由用户/开发者自行保管，Stash Cloud 不对用户助记词或私钥管理负责，也无法协助找回丢失的密钥。平台对基础设施故障承担责任，对密钥丢失、双节点同时在线等自身原因不承担责任，见概览 — 责任边界

五、面向未来：从专用到开放的演进路线图

5.1 已完成（Q1-Q3 2026）

✅ 基于开源 K8s 构建自管理集群
✅ 实现节点级网络隔离（NetworkPolicy）
✅ 独立磁盘 + 禁止共享存储
✅ 节点数据导出与自托管迁移
✅ 支持 rgbldkd 节点的全生命周期管理（由 Bitlight Labs 开发）
✅ 管理 API /v3（Bearer API Key）文档已发布，见 Stash Cloud API

5.2 进行中（Q4 2026）

🚧 向第三方开发者开放 API 接入
🚧 发布 SDK（TypeScript、Python、Go）
🚧 多地域集群（降低延迟）；百万级在线是多集群架构能力，正在按地域扩展

5.3 计划中（2027）

📋 支持自定义节点配置（环境变量、启动参数）
📋 开放节点监控与告警 API（Prometheus + Grafana 集成）
📋 根据 RGB 生态需求扩展更多功能支持

六、为什么这对整个 RGB 生态有价值

降低门槛

RGB 生态的小型团队无需雇佣 DevOps 工程师，即可为用户提供云 RLN 服务。开发者专注于应用层产品（钱包、DEX、支付网关），底层节点托管交给 Stash Cloud。

具体场景：

一个刚成立的 RGB 钱包团队，可能只有 2-3 名开发者。如果自建节点基础设施，需要：

租用服务器（云主机或物理机）
搭建 Kubernetes 集群（或直接用 Docker Compose）
配置存储、网络、监控、告警
编写节点生命周期管理脚本
维护集群稳定性（版本升级、故障恢复、容量规划）

这至少需要 1 名全职 DevOps 工程师，对小型团队来说是巨大的成本。

通过 Stash Cloud，这个团队只需：

typescript

const client = new StashCloudSDK(apiKey);
const node = await client.nodes.create({
  type: 'user', // 实现是 rgbldkd，type 只能是 user / lsp / hub
  wait: true,
});
// 通常在分钟内进入 running（无需重同步链上数据）

从「需要 1 名 DevOps + 数月搭建时间」到「几行代码 + 分钟级就绪」，这就是降低门槛的实际意义。管理 API 的真实路径是 POST /v3/nodes；network 由对接的实例决定。

成本控制

相比自建服务器 + 托管 K8s，成本大幅降低。弹性伸缩（Scale to Zero）使闲时节点零资源消耗，进一步优化成本结构。

安全可控

信任最小化架构 + 节点级隔离，企业级安全保障。用户随时可导出数据、迁移到自托管环境，无供应商锁定。

无供应商锁定的实际含义：

传统云服务的「锁定」来自两个层面：

数据格式锁定 — 平台使用专有格式存储数据，迁移到其他平台需要转换
功能依赖锁定 — 应用代码深度依赖平台特有 API，迁移成本高

Stash Cloud 的设计避免了这两个陷阱：

数据格式标准 — 导出的备份文件是上游 rgbldkd 标准格式，可直接在 Bitlight RGB LDK Control Panel 中恢复
API 语义通用 — 对外暴露的 API 是节点管理的通用语义（创建/启动/停止），而非 Stash Cloud 专有功能

用户可以随时：

导出节点数据（助记词 + 备份文件）
在自己的服务器上安装 rgbldkd
恢复节点，继续使用

这不是「理论上可以迁移」，而是「有完整文档、经过验证的迁移路径」。

七、写在最后：从专有到开放的哲学

RGB 闪电网络教会了我们什么

RGB 协议采用客户端验证模型，资产状态由每个用户在自己的节点上本地维护和验证——这恰好是区块链去中心化理念的自然延伸。

传统区块链（如以太坊）将所有状态发布到链上，全节点验证所有交易。这提供了强大的信任最小化特性，但牺牲了隐私性和可扩展性。

RGB 的选择是：每笔转账和每个通道状态仅在相关方之间进行本地验证，链上只留下不可伪造的密码学承诺。

这一设计理念的直接含义是：用户必须真正拥有数据所有权（助记词 + 节点备份），而非依赖平台托管。

这一理念推动 Stash Cloud 走向开放

从「只服务 Stash Wallet、RGB Dex、Flash Dex 自有产品」到「服务整个 RGB 闪电网络生态的所有项目与开发者」
从「平台托管」到「用户自主导出、自由迁移」
从「专有基础设施」到「标准 API + 开放接入」

如何正确理解 Stash Cloud：Stash Cloud 提供的云 RLN 服务与云厂商提供的云服务器一致——仅提供计算与存储基础设施，目的是减少开发者和用户进入 RGB 生态的难度。

我们相信

真正的基础设施应该是透明、开放、可迁移的。Stash Cloud 的目标不是锁定用户,而是降低整个 RGB 闪电网络生态的运维门槛,让更多团队能够快速落地 RGB 资产与闪电网络应用。

我们希望看到的未来是：

任何开发者都能在几小时内为用户提供 RGB 闪电节点服务
用户清楚地知道自己的数据在哪里、如何备份、如何迁移
RGB 生态的应用层创新不再受限于基础设施门槛

这就是我们将 Stash Cloud 从专有解决方案升级为通用云 RLN 基础设施的原因。

附录：技术栈总览

┌──────────────────────────────────────────────────────────────┐
│  Stash Cloud 技术栈（RGB 闪电网络通用云 RLN 平台）              │
├──────────────────────────────────────────────────────────────┤
│  应用层                                                        │
│    - Stash Wallet / RGB Dex / Flash Dex / 第三方 RGB 项目     │
├──────────────────────────────────────────────────────────────┤
│  API 层                                                        │
│    - 管理 API /v3（Bearer）                               │
├──────────────────────────────────────────────────────────────┤
│  编排层                                                        │
│    - 节点生命周期 / 数据导出 → 写入声明式期望状态              │
├──────────────────────────────────────────────────────────────┤
│  Kubernetes 1.30+（开源自管理）                                │
│    Control Plane                                               │
│      kube-apiserver / etcd / kube-scheduler                   │
│      kube-controller-manager（+ 可选 cloud-controller-manager）│
│    Worker Node                                                 │
│      kubelet + container runtime + CNI（+ kube-proxy）        │
│    工作负载与策略                                              │
│      StatefulSet（稳定标识 + 持久卷 + Scale to Zero）         │
│      PVC/PV + StorageClass（独立磁盘，Retain / RWO）          │
│      NetworkPolicy（Ingress/Egress 默认拒绝，统一走公网）     │
│      Namespace + RBAC（最小权限，无集群级写权限）             │
├──────────────────────────────────────────────────────────────┤
│  存储层                                                        │
│    - 本地云盘（独立 PV） / 定时快照 / Arweave + IPFS 异地副本 │
└──────────────────────────────────────────────────────────────┘

参考：Kubernetes 概述、组件、架构。

Stash Cloud：从专有解决方案到通用云 RLN 基础设施 ​

一、为什么要做这件事 ​

最初的定位 ​

演进的契机 ​

目标 ​

二、从专有到通用：核心挑战与解决方案 ​

2.1 挑战 1：基于开源 Kubernetes 开发，而非托管 K8s 服务 ​

问题 ​

解决方案 ​

成果 ​

2.2 挑战 2：节点间的内网隔离——即使同一租户下也完全隔离 ​

问题 ​

解决方案 ​

成果 ​

2.3 挑战 3：独立磁盘 + 禁止共享存储 ​

问题 ​

解决方案 ​

成果 ​

2.4 挑战 4：权限管控——API Key 作用域与密钥安全责任 ​

问题 ​

解决方案 ​

成果 ​

三、从 RGB 专用到通用云 RLN 基础设施：标准化 API ​

四、安全设计：信任最小化架构的五层防护 ​

五、面向未来：从专用到开放的演进路线图 ​

5.1 已完成（Q1-Q3 2026） ​

5.2 进行中（Q4 2026） ​

5.3 计划中（2027） ​

六、为什么这对整个 RGB 生态有价值 ​

降低门槛 ​

成本控制 ​

安全可控 ​

七、写在最后：从专有到开放的哲学 ​

RGB 闪电网络教会了我们什么 ​

这一理念推动 Stash Cloud 走向开放 ​

我们相信 ​

附录：技术栈总览 ​

Stash Cloud：从专有解决方案到通用云 RLN 基础设施

一、为什么要做这件事

最初的定位

演进的契机

目标

二、从专有到通用：核心挑战与解决方案

2.1 挑战 1：基于开源 Kubernetes 开发，而非托管 K8s 服务

问题

解决方案

成果

2.2 挑战 2：节点间的内网隔离——即使同一租户下也完全隔离

问题

解决方案

成果

2.3 挑战 3：独立磁盘 + 禁止共享存储

问题

解决方案

成果

2.4 挑战 4：权限管控——API Key 作用域与密钥安全责任

问题

解决方案

成果

三、从 RGB 专用到通用云 RLN 基础设施：标准化 API

四、安全设计：信任最小化架构的五层防护

五、面向未来：从专用到开放的演进路线图

5.1 已完成（Q1-Q3 2026）

5.2 进行中（Q4 2026）

5.3 计划中（2027）

六、为什么这对整个 RGB 生态有价值

降低门槛

成本控制

安全可控

七、写在最后：从专有到开放的哲学

RGB 闪电网络教会了我们什么

这一理念推动 Stash Cloud 走向开放

我们相信

附录：技术栈总览