RGB++ Protocol Light Paper

中文 CKB 开发与技术讨论
4

链外计算

  • 选中下一次要使用的一次性密封条，例如 btc_utxo#2

这里好像是选中 btc_utxo#1 ?

5

虽然看不懂，但大受震撼，牛逼完事了

1 Like
6

需要一段时间研究

7

Thanks for taking the time to do this :smiling_face::wave:

1 Like
8

个人研究RGB也有一段时间了，觉得RGB最大的优势是打破了区块链的枷锁，可以做到更好的隐私（数据主权）和无限扩展（百万级tps），对RGB++白皮书中的RGB痛点也深有体会，也期待RGB做得更好。现有两个问题：

1、RGB++中原始交易数据保存在Nervos网络还是其他地方？如果在Nervos网络是不是所有人可见？如果在其他地方，如何访问？

2、RGB的客户端验证在钱包就能很好的完成，不需要依赖节点，RGB++是否也能不依赖Nervos节点，只在钱包做到验证，如何做的？

9

你好，很高兴和您讨论 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 确认。安全的级别是用户自选的，你不需要信任任何人。

3 Likes
10

感谢回复！
一个项目或产品，都是各方面的权衡和取舍。

关于非交互转账，我想是可以通过一个agent（智能合约）来自动进行，这个agent可以既是智能合约也是RGB钱包，以及其他更丰富的功能。

1 Like
11

你好，我看完了你的文章了，感觉非常有启发。不过由于此前我对 CKB 基本没有什么了解，是刚刚看完了官方的文档，所以我也遇到了一些疑问：

  • CKB 本身也是基于 UTXO 模型的，而且还支持智能合约（这个让我觉得非常惊喜，我一直想多了解一些基于 UTXO 模型且支持智能合约的区块链）。如果我真的要使用 CKB 的话，那我为什么还要使用 RGB 呢？如果我使用 RGB 是为了能够享受到 Bitcoin 的安全性的话，那么一旦我大规模地使用 RGB++ ，我必然需要依赖 CKB 的安全性（比如用到 Intent Cell 的场景或者非交互式转账的场景），如此一来整个系统的安全性就依赖于 CKB 了，我使用 RGB 的意义好像就变弱了

  • CKB 是怎么解决和 Bitcoin 的同步问题的呢？考虑到 CKB 是一个 L1 ，并不是类似于 Stacks 的基于 Bticoin 的 L2 （一旦 Bitcoin 出现 reorg ，Stacks 已经上已经被确认的交易也会尝试重新 settlement）。一旦 Bitcoin 出现 reorg ，再加上比特币链上可能出现的对交易的 RBF ，可能会导致比特币链的部分交易被修改，比如原本存在于某个 TX 的某个 OP_RETURN 因为 RBF 而消失了，而这个时候 CKB 没有相应的发生回滚，于是出现了 RGB++ 交易的 BTC TX 消失，而 CKB TX 依旧存在的情况。这个时候出现的混乱要怎么解决呢？（可能还有相反的情况，就是 BTC TX 还在，但是 CKB TX 没了，但是我没那么确定 CKB 会不会发生这种情况）

我想了想，好像我上面提到的两个问题其实归结起来就还是安全问题。是不是这就是你在 RGB++ Protocol Light Paper - #9 by Cipher 里说的 “那么你只需要同样在确认交易的时候多等几个 bitcoin 确认 & ckb 确认” ？

也就是说，如果我使用 RGB++ ，我有两种选择：

  1. 我可以同时发布 BTC TX 和 CKB TX ，这样出问题的概率是不是从 P(btc) 变成了 P(btc) + P(ckb) ？
  2. 如果我希望先确保 CKB TX 不会发生 reorg 然后再广播 BTC TX 并确保 BTC TX 也不会发生 reorg，那么我需要等待的时间就变成了 (ckb block time) * (ckb wait block) + (btc block time) * (btc wait block) ，这样会不会太久了？

期待你的回复，谢谢

1 Like
12

专业的问题，都是大牛！

13

很好的问题，我刚好打算写一篇安全方面的思考，这两天贴出来。不过我可以先对你的问题里面一个重要的细节讨论一下。

关于 reorg 的安全问题：注意 UTXO 链语境下，reorg 不等于交易失败或双花。如果没有交易发起人的恶意行为（对同一个 UTXO 签署两笔交易），那么区块 reorg 不会对确定性的交易有影响。所以在考虑安全问题时，这个点需要注意。剩下的我会在安全方面的文章里面详细讨论。

1 Like
14

感谢回复

关于 reorg 的安全问题：注意 UTXO 链语境下，reorg 不等于交易失败或双花。如果没有交易发起人的恶意行为（对同一个 UTXO 签署两笔交易），那么区块 reorg 不会对确定性的交易有影响。所以在考虑安全问题时，这个点需要注意。剩下的我会在安全方面的文章里面详细讨论。

对我明白，我指的就是存在恶意行为的场景，比如这种：

在一个非交互式转账的场景里，我先把一些 token 转到一个中间地址，我需要发起两个交易：BTC TX 和 CKB TX，在 CKB TX 和 BTC TX 确认后，我利用 BTC 的 reorg 的机会，发起一个 BTC TX 的 RBF ，修改掉这个交易。

此刻 CKB 链上的交易状态是我已经给中间地址转账了，在 BTC 链上是我没有给中间地址转账，如果我此刻运行的是一个基于 CKB 链上数据的客户端的话，我就会认为我基本上已经得到这个钱了，但其实在 BTC 链上我是没有得到这笔钱的

期待你的新文章

15

啊，关于我的第一个问题：

CKB 本身也是基于 UTXO 模型的，而且还支持智能合约（这个让我觉得非常惊喜，我一直想多了解一些基于 UTXO 模型且支持智能合约的区块链）。如果我真的要使用 CKB 的话，那我为什么还要使用 RGB 呢？如果我使用 RGB 是为了能够享受到 Bitcoin 的安全性的话，那么一旦我大规模地使用 RGB++ ，我必然需要依赖 CKB 的安全性（比如用到 Intent Cell 的场景或者非交互式转账的场景），如此一来整个系统的安全性就依赖于 CKB 了，我使用 RGB 的意义好像就变弱了

请问你的看法是什么呢？

如果我的整套系统的安全性是完全依赖 CKB 的话，那为什么我不直接使用 CKB 而是去使用 RGB++ 呢？

16

RGB++ 协议下折叠交易和 L1 交易的安全性可以做到等价，这块不用担心。如果用户不放心交易折叠，他们总是可以只使用 RGB++ L1 交易，而不使用交易折叠。此外，RGB++ 协议的资产主要是在 BTC 上发行。这就像 ETH L2 ，你不能说既然未来大规模采用必然发生在 L2 上，那大家就没必要用 L1 了。

17

我个人理解，虽然CKB已然非常灵活和强大且去中心化，这是从技术层面看，但BTC目前从共识上看仍然是大家最信赖的存在，也是共识度最高和共识最去中心化的，那么两者结合起来，在这个时间CKB经过四年的不间断的开发和完善，正好具备了承载BTC L2的基本条件（而不是像有些提出概念和想法，实现的时候还需要有链下或中心化服务端等的存在等），在当前环境下，回归BTC或者重新发掘UTXO和POW优势的呼声中，其实是更多的人想把ETH过于偏颇的方向在不同的方向能有不同的尝试，这是历史的潮流，那么正正好CKB和BTC的结合就是当下最好的叙事也是最好的尝试！未来CKB肯定不止是BTC的L2！

1 Like
18

如果BTC是区块链世界的原点和根，那么各种蓬勃发展的区块链项目就是这颗大树上的枝和枝丫，如果ETH是一个长的比较早且大的枝叉，那么CKB就是另外一个枝叉，他们生长的方向不一样，但是当这些枝叉变得大且繁茂的时候，还有很多藤蔓交织和贯通在一起，每个枝叉足够大的时候说不定自身又延伸弯曲并扎根于土壤变成了根，这是一个生机勃勃的新世界和生态。

1 Like
19

谢谢回复

在我看来 RGB++ 之于 RGB 不能以 L2 之于 L1 来类比

L2 是会有独属于自己的交易，只不过会在经过某些检查点时，把区块的验证信息 settle 到 L1 上（这更像是 RGB++ 的交易折叠）。而如果是 L2 上存在可能会影响 L1 的交易，比如从 L1 上转账到 L2 ，那么一旦 L1 发生 reorg ，L2 上的已经被确认的交易会被需要重新确认

我的感觉是 RGB++ 除了交易折叠的用例以外，其他情况下 CKB 链上的交易历史更像是 BTC 链上的交易记录的影子，我们需要始终保证 CKB 上的 RGB 交易和 BTC 上的 RGB 交易一一对应。我担心的情况就是在于，CKB 本身是一条 L1 ，它和 BTC 本身不存在什么关联，因此也没办法在 BTC 发生 reorg 的时候（并可能被人恶意利用或者破坏的时候）重新验证交易。

我们来想象一个例子：

  1. A 给 B 进行了一次转账 100z 消费掉了 UTXO#0 & Cell#0，大家等 BTC 和 CKB 上交易都确认了，此刻 B 有 UTXO#1 & Cell#1 。
  2. BTC 上发生了 reorg ，A 发现了这个情况，于是双花了 UTXO#0 ，把这 100z 发给了 C ，并且没有在 CKB 上发布任何交易（这是允许的对吧？我就进行一次 RGB 交易嘛）
  3. 于是我们现在的情况是 B 有 Cell#1 ，C 有 UTXO#2 ，这就变得很奇怪
  4. 我们再想象一下，假如 B 在收到 A 的转账后（A 还没进行双花），在一个交易折叠里进行了 20 多次转账，涉及到了 20 多个用户，这些交易里可能还添加了这些用户的其他 UTXO 作为输入，最后这些交易折叠到了一个 BTC 链上交易里。然后 A 实施了双花，于是这 20 多个用户的余额都出现了问题，对于 CKB 而言，那些 UTXO 应该已经被花掉了，但是整个交易链条又是有缺陷的（因为有一个 UTXO 已经不存在了），由于 CKB 上的交易不会因为 BTC 的 reorg 而触发重新确认，于是 CKB 上就出现了大规模的和 BTC 不一致的情况，而且状态没办法回滚到一开始的样子

RGB++ 想要实现的“共享状态”和“非交互式转账”好像也会遇到类似的情况，而为了避免这种情况：

  • 共享状态用例里的第三方聚合器就会需要多等几个 BTC block 才能进行聚合；
  • 非交互式转账的接收方会需要多等几个 BTC block 才能放心地把实体商品交给发送方

否则就有可能被发送方利用 reorg 破坏掉两条链上的交易记录的对应关系，实现恶意行为。尤其是对于共享状态用例，一旦对应关系被破坏，我感觉恢复起来可能也会比较麻烦

这是我比较担心的事情

20

谢谢回复，我也觉得 RGB++ 的想法挺好的，非常有意思，很期待它能真的生根发芽。

CKB 也非常有意思，我之前一直很期待想看看有没有一个 UTXO 模型的支持智能合约的区块链，不过之前一直不知道有 CKB ，这次看到以后就觉得很开心

2 Likes
21

没错，是这样的。但事实上要想真正的双花 RGB++ 交易，你不仅需要 reorg BTC 也需要同步 reorg CKB，因为 CKB 的交易的 input 同样有双花约束。不过仍然有因为 reorg 造成问题的可能性。

一个平庸的解决方案就是 CKB 上的 BTC 轻客户端只允许用户访问 Tip - N 之前的块头，这样确保所有 CKB 上的交易只能绑定“不可 reorg”的 BTC 交易。但我们也在思考一个更好的方案，允许交易绑定最新的 BTC 交易，但交易者或 dapp 自行决定可接受的 BTC 确认数，例如 N=2 还是 N=6 由用户自行决定。但这个设计还有一些细节需要思考。

1 Like
22

作为一个怀有恶意的人，我不一定是想要真正地去”双花“一个 UTXO ，我可能只是想“进行破坏”。如果是以进行破坏为目的的话，那么我只需要利用 BTC 链上的 reorg 创造出 CKB 和 BTC 上的数据不一致的情况就可以了。就比如我上面提到的情况：

我们再想象一下，假如 B 在收到 A 的转账后（A 还没进行双花），在一个交易折叠里进行了 20 多次转账，涉及到了 20 多个用户，这些交易里可能还添加了这些用户的其他 UTXO 作为输入，最后这些交易折叠到了一个 BTC 链上交易里。然后 A 实施了双花，于是这 20 多个用户的余额都出现了问题，对于 CKB 而言，那些 UTXO 应该已经被花掉了，但是整个交易链条又是有缺陷的（因为有一个 UTXO 已经不存在了），由于 CKB 上的交易不会因为 BTC 的 reorg 而触发重新确认，于是 CKB 上就出现了大规模的和 BTC 不一致的情况，而且状态没办法回滚到一开始的样子

在这种情况下，我能够以很小的成本创造出很大的混乱

如果由 dapp 自行决定可接受的 BTC 确认数，而 dapp 为了规避我上面提到的“尤其是对于共享状态用例，一旦对应关系被破坏，我感觉恢复起来可能也会比较麻烦”这种麻烦，可能会选择一个操作要等待 5、6 个 BTC block 才能确认，这实在是太难让人接受了

23

有你这么仔细的兄弟加入，以后CKB上APP的质量和容错相信一定会更上一个台阶，对做开发确实是得较真，不然怎么大规模应用，有时一个BUG就足以毁掉一次策划很久的项目的努力，前段时间OMIGA铭文上线就是有个小漏洞，结果手打铭文最后变成了脚本打铭文，虽然从另一个角度这对CKB也算是一次高频压力测试和验证，但从铭文本身看不得不承认这就是一次由BUG导致的事故，如果是完全手打来，估计现在这波铭文热度还没打完，结果都去刷脚本2天就结束了。。有你这样的人加入，兄弟，相信CKB生态会越来越好！

2 Likes