the way to properly implement this is with a cryptographic accumulator on CKB, with this design, only enough information to cryptographically prove inclusion of a block is required, it is on the order of about 1000 bytes
2 Likes
Are you saying that each user will each have to lock 1000 CKB to run a BTC light client if they want to use RGB++? @matt.bit
Only one for everyone.
1 Like
OK, thanks!
我这里有三个问题
- 原始的RGB在链下有着几乎不妥协的处理能力，可以处理一些对计算力有需求的场景，同时也只需要付出常数级别的交易费。而现在不仅需要根据交易复杂程度支付交易费，单笔交易的处理能力也受到了限制。
- 原始的RGB协议中借助于UTXO，只需要保证交易的偏序性就可以了。而如果要引入共享状态，那么由于存在对共享状态的争抢，交易的全序性就至关重要了，这是intent cell也无法解决的问题。如果CKB上交易被审查，将会影响已提交commitment的执行结果。
- 交易折叠的问题。在承诺-公开的两阶段框架下，在承诺被提交到btc链上时，CKB上对应的交易应该已经被构造好了，那么交易折叠在哪些场景下可用呢？能否给出一个实际的例子。
1 Like
Hi, after studied the lightpaper, I’m excited about the RGB++, but have a little concern about the aggregator. Could you please provide more information of the aggregator solution in current RGB++ protocol?
like 1. aggregator selection and management, 2. incentives and penalties mechanism, 3. intent Cell collection and ordering rules, etc.
I believe that clarifying these details would greatly help the community better understand and evaluate the RGB++ design and current development. Thanks!
1 Like
个人觉得这段的翻译可以优化下：
上面的例子是卖家挂单 RGB++ xudt，买家使用 Bitcoin 购买。交易结构原理是：买家需要提供包含了足够数量比特币的BTC utxo并提供 PBST 签名，同时构造 CKB 上的交易来符合卖家的要求。最终买家将构造好的 CKB 交易发送给卖家，卖家将 BTC 交易和 CKB 交易先后上链完成交易。
原文中：交易结构为买家提供了 … utxo并签名，这个表达很容易误解为：第三方提供的utxo和签名，很奇怪的感觉。去看了英文的才理解。这段话英文的语法结构比较清晰。