你好，很高兴和您讨论 RGB/RGB++ 协议的细节
这些数据会被默认保存在 Nervos 网络，所有人都可见。这样解决了原始 RGB 协议的可组合性问题。但事实上，你也可以选择仅仅利用 Nervos CKB 的交易规则构造这些交易，而并不去提交/保存在 Nervos，这样就退化成了原 RGB 协议的方案——用户自己保存这些历史，仅在向收款人证明时提供这些“链外”数据。
我猜测你这里讲的“不需要依赖节点”应该是“不需要依赖【全节点】”的含义吧？RGB 的客户端验证需要 Bitcoin 块头哈希来验证 utxo 的存在性。RGB++ 协议是一样的，它的基础功能部分仅仅需要 BTC 的块头哈希证明，不需要依赖 CKB 的节点。关于这部分，做个简单的类比可以更好地说：假设我们可以构造一个 AluVM based UTXO chain，每一笔 RGB off-chain 交易都可提交到这个公链并被很好地验证，但你完全不需要依赖这个公链，因为只要你有足够的信息，用户可以自行验证 utxo 分支历史而不需要另一个链的共识机制帮你验证——尽管后者可以让应用开发、用户体验更加实用
但这里还有另外一个细节，就是 RGB++ 提出的交易折叠、非交互转账、共享状态等功能。如果说，RGB 协议的收款对象是 bitcoin utxo，那么 RGB++ 协议的收款对象既可以是 bitcoin utxo，也可以是 nervos address。在一个 RGB++ utxo 历史链条中，当收款对象在 btc utxo 和 ckb address 之间来回变化时，用户需要一个 ckb 轻节点来验证 ckb 的 PoW 块头以防止 ckb 上的 utxo 双花问题——这一点和我们需要 btc PoW 块头以防止 btc 上的 utxo 双花问题一样。那么安全性是否被妥协了呢？并没有，同样源自客户端验证的哲学理念，你认为 BTC 的 PoW 不够安全（唯一的攻击是 reorg 带来的双花攻击）你就在确认交易的时候多等几个确认；那么在使用 RGB++ 的交易折叠等功能时，如果你认为 CKB 的 PoW 不够安全（唯一的攻击同样是 reorg 带来的双花攻击），那么你只需要同样在确认交易的时候多等几个 bitcoin 确认 & ckb 确认。安全的级别是用户自选的，你不需要信任任何人。