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上对应的交易应该已经被构造好了，那么交易折叠在哪些场景下可用呢？能否给出一个实际的例子。
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!