Closed afilini closed 6 years ago
So, your scope is to replicate a inheritance capability? that's nice.
I agree that some versioning control more advanced than just tag, should be in place.
I do think that 1 and 2 are the same, I mean you can still do a crowdsale and printing tokens (pre-mine?) in advance, right?
No, 1 and 2 are pretty different, that's why they have different types. With one you can do "pre-mine", while with the other you can do crowdsales
Ok, having only "centralized" blueprints can be tedious and slow process (incremental proposals?) compared to having a met-script language where you leave more freedom to issuers to craft their own without consensus.
PS: I don't have any ideas atm of different issuance mechanism (behaviors) to justify the meta script, but it can be a cool proposition.
Honestly, I don't think we really need a meta-script language. We could just add some "blueprints" for contracts, so that we define their behavior, while the issuer only needs to fill up some fields.
The first two blueprints I can think of are:
I agree that we need a versioning system, but I would use it to "tag" changes in the behavior of the blueprints themselves. Something like:
Crowdsale issuance (type
0x02
), version1.0
: Everyone can buy the tokensCrowdsale issuance (same type,
0x02
), but version2.0
: There is one more field that allows the issuer to force users to send segwit transactions only.This doesn't really make any sense, it's just an example of the following concept: every blueprint (contract) have a specific type, and a version number. By changing the version number we conceptually keep the same "behavior", while we can add some more features/improved privacy/security and even more.
This kind of structure allow users (or wallets) to ban specific contract types, while welcoming version updates on the kind they accept. Instead, with a "general" RGB version number we could risk forks when a controversial change is applied together with some useful updates, since someone would like to accept the "useful updates" while rejecting the "controversial change", possibly resulting in a fork.
Oh, and this would allow us to add a meta-script language in the future, by creating a new blueprint with a field that contains the script itself.