Le destinataire reçoit un consignment avec l’historique pertinent, le valide par rapport au genesis et au schema, puis vérifie que les state transitions correspondantes sont liées à des transactions Bitcoin valides.
RGB Protocol repose sur Client-Side Validation et les single-use seals. Bitcoin ne réplique pas les données détaillées du contrat : les participants les conservent et les valident, tandis que les UTXO et transactions Bitcoin fournissent la preuve publique de fermeture des sceaux et la protection contre la double dépense. [6]
Un contrat débute par une opération Genesis puis évolue via des state transitions dans un graphe orienté acyclique. Les transitions consomment l’owned state précédent, créent un nouvel état et lient leurs commitments, par un anchor, à une witness transaction Bitcoin. [3]
Un schema est un modèle déclaratif de logique métier : il définit types de données, état possédé et global, opérations admises et règles de validation. Genesis en crée une instance concrète, par exemple l’émission et les allocations initiales d’un actif fongible ou unique. [2]
Lors d’un transfert, l’expéditeur remet au destinataire un consignment contenant genesis, schema, historique pertinent et preuves. Avant acceptation, le destinataire valide localement toute la chaîne, ses anchors et ses liens avec Bitcoin ; un ticker ou un solde affiché par un wallet ne prouve pas la validité. [4]
La liste publique des versions qualifie v0.10 de stable et la série v0.11 de préversion ; les bêtas signalent aussi des changements du consensus RGB, pas du consensus Bitcoin. Un usage en production exige donc une version exacte et compatible de toute la pile cliente, au-delà d’une simple mention de prise en charge RGB. [5]
Le sigle RGB est ambigu sans contexte. La documentation actuelle distingue explicitement le RGB Protocol on Bitcoin décrit ici de la proposition différente et inachevée v0.12 ainsi que de RGB++ sur Nervos/CKB ; le même sigle ne garantit ni architecture commune ni interopérabilité. [1]
Confidentialité et passage à l’échelle ont un coût de disponibilité des données. Bitcoin ne peut pas reconstruire un consignment perdu à partir du commitment ; le destinataire doit obtenir tout l’historique pertinent et le propriétaire sauvegarder sûrement le stash et les autres données clientes. [4]
Pour évaluer une affirmation sur RGB, il faut vérifier versions exactes du protocole et des bibliothèques, schema et genesis, contract ID, type de commitment, couche prise en charge, intégrité du consignment et état des audits. La formule on Bitcoin ne prouve à elle seule ni interopérabilité, ni sûreté, ni récupération. [5]
Pour une vision complète, lisez aussi Client-Side Validation, UTXO, Taproot, Lightning Network, Sidechain, Hash. Cette entrée est également citée par Taproot Assets, Runes.
01Les contrats RGB sont-ils stockés directement dans la blockchain Bitcoin ?+
Non. Bitcoin contient les transactions et commitments cryptographiques nécessaires à l’ordre et à la fermeture des sceaux ; l’état détaillé et l’historique de validation sont transmis et conservés côté client.
02Tous les tokens appelés RGB sont-ils compatibles entre eux ?+
Pas automatiquement. Le wallet doit prendre en charge la version précise du protocole, le schema, l’interface et la procédure de commitment. Avant acceptation, il faut vérifier le contract ID et le consignment complet, pas seulement le nom ou le ticker.