I would strongly vouch for changing the name of RGB++ to something else, because it’s misleading to investors and users alike, let me explain…
As already discussed on this forum (RGB++ Protocol Light Paper (Translation)) and in extension also in our discussion with cipher on twitter (https://twitter.com/NervosNetwork/status/1763488636857958625) we figured out that OBJECTIVELY RGB & RGB++ are taking different design routes, while RGB is striving for a post-blockchain purely client-side-validated world, RGB++ is on a route of adding more blockchains to CKB and creating L2 scaling solution on CKB to scale RGB++.
RGB++ would imply (from the naming) that it is an upgrade over RGB, which we see is not objectively the case (they are 2 projects taking very different paths). Therefore for the sake of investor & user clarity (and also for not being labeled as RGB affinity scam) I would recommend renaming RGB++ to something else.
Just like C++ is not an upgrade to C, but rather adds some new things based on C’s functionality and philosophy. Thus, many people express that they do not like the new parts added by C++ and only prefer the pure C, which is completely reasonable.
The situation now is similar; RGB++ adds some things, which does not mean it represents an upgrade to RGB.
Furthermore, RGB++ transactions can entirely operate and be verified in a pure client environment independent of CKB, so RGB++ does not force users to use more blockchain to achieve functionality for BTC (So, I do not think what you are saying holds. For example, after RGB v0.11 is finalized, it is possible to implement an RGB indexer on CKB. Does RGB changed because of this new possibility? I do not think giving users more choices is wrong, as different users may have completely different needs), although from an engineering perspective, I do not know if the RGB++ team will initially launch such a client.
Version numbers indicate upgrades, while plus-plus signifies it is something else.
The problem is that unlike C and C++, the RGB++ is not designed to be compatible with RGB. C features are (for the most part) subset of C++, same cannot be said about RGB being a subset of RGB++, since the two are way different. They use different off-chain data structure & different VM, both of which are in no way compatible with original RGB protocol.
If you want to name it RGB++ then build on the existing RGB protocol by extending its feature set, in such a way that RGB contracts are naturally compatible with RGB++.
In fact, people who write C++ know that they write C++, not C, and they are incompatible in many places.
If the RGB code can be compiled with no-std, then it can naturally be compiled to riscv-64, and there is no problem in maintaining compatibility at some level.
Yes, but people who write C know that they can further down the line use the very same code with C++. Thus C++ is backwards compatible with C (C is a subset of C++)
It is not about compiling RGB code. It is about RGB contracts (and their off-chain data structures and VM) being compatible with RGB++.
So RGB++ should first make RGB work with CKB as an indexer, this SHOULD NOT require any change to RGB itself. Then if you want to use RISC-V instead of AluVM, fork the RGB code and add the possibility to support multiple VMs, keeping AluVM for backwards compatibility and adding RISC-V so you can write more extensive logic. Then it would make at least some sense to call this new fork RGB++ (since you are extending RGB while being backwards compatible with it), however a better name for it would be e.g. RGB-RISCV.
What RGB++ is instead doing, is creating the whole protocol from the ground up, maintaining no compatibility with the existing RGB protocol, since off-chain data structures (history, consignments) & VM would be incompatible. Calling such thing RGB++ makes no sense, since it shares nothing (except using single-use-seals) with RGB protocol.
I am not saying we should only have one route to advance the concept. I am not a communist, let everyone do what they want. It’s just the naming that I see confusing.
Doesn’t change the fact that RGB & RGB++ contracts are incompatible. If I have an RGB asset, such as USDT I cannot really send it to a wallet which only supports RGB++.
What do you mean by code frozen? I am just saying that for creating an indexer of RGB on CKB you don’t need to change RGB at all (for this you would actually just compile RGB runtime to RISC-V to run on CKB).
In fact, this is entirely possible, as long as RGB can assign a chainID to CKB, it can be accomplished through some interaction between on-chain scripts and off-chain commitments. UTXO is already a very flexible model, and Extended UTXO is even more flexible. As a universal verification layer, it can validate a wide variety of state transitions.
Indeed, but I guess the RGB++ team wanted to move forward and explore more rapidly, so they did not initially prioritize compatibility with RGB. They chose an already long-established extended UTXO model—the Cell model—and selected an existing virtual machine, the CKB-VM based on the RISC-V ISA, by reusing these mature components to accelerate development progress. Moreover, at the application development level, it is possible to use Rust to develop applications based on RGB++, without the need to learn a new language, because finding programmers who can quickly learn a new scripting language and develop applications is challenging.
So this is more like RGB assets need to be transfered to CKB first (with xchain). Where they are then constrained in a special eUTXO which bridges those assets over to the RGB++. But then that’s more like a bridging/wrapping of RGB assets inside RGB++.
Yes, I am not objecting that, let them do whatever they want. But if they want to move forward rapidly to a point where they are building it as a completely new protocol from scratch (as far as I can tell they are no intending to fork RGB) they probably shouldn’t be calling it RGB++.
On a personal level, unless they apologize for the unfounded accusations, I will not consider the name issues.
From the perspective of the entire community, it has become a shared understanding within the community, and I don’t believe anyone has the right to change it.
My last response on this: talk is cheap, let’s buidl.
Are there any other projects pioneering single-use-seals, aside from RGB?
If the answer is no, then it seems apparent that RGB++ utilises a key design feature inspired by RGB, but implemented differently. That contradicts your suggestion that it’s something built completely from scratch. It’s using a pre-established idea that has been championed primarily - if not solely - by RGB.
In fact, unlike other projects which RGB have claimed copied them, like Taro, at least RGB++ makes clear its source of inspiration.
So we can reject outright the notion that that there’s no link whatsoever. Perhaps your argument is that the link is tenuous. That is more subjective, and these discussions are proof of that.
Given there is
no rulebook on the level of affiliation needed to use ++
RGB++ documentation explaining that ++ is an expression of clear divergences from the original protocol
RGB (LNP-BP) statements clearly disassociating from RGB++ ,
I don’t see a pressing need for the name to be changed, and I don’t see a realistic scenario where a researcher will be confused or misled. In a free society and with open source, permissionless protocols, it seems quite ironic that the objection feels more like gatekeeping and protecting IP (I don’t think RGB has much traction, market or brand awareness for this to be a valid concern).
In conclusion: the best solution, outside of mutual acceptance and collaboration, is to let the market decide.
I think RGB is a foundational technical concept, just like zkp. In recent years, the zkp field has developed very rapidly due to the entry of many talents and projects. RGB is essentially the same as zkp, it is something fundamental, just like zkp has many different proving systems, and almost all zk engineers are learning from each other and helping each other.
RGB in the context of Bitcoin stands for “Really Good Bitcoin.”, it is not at all related to client-side validation, the technology it uses. So your analogy with zkp has no value. You are just using an original brand for your own project. It is as simple as that.
I think this falls into that umbrella, much like many other ideas and projects past, present and future.
Also possibly related is this bullet from the What is RGB? page.
RGB uses blockchain as a state commitment layer and Bitcoin script as an ownership control system; while smart contract evolution is defined by off-chain schema
What I could interpret in this context is that CKB is off-chain from BTC