El receptor obtiene un consignment con el historial pertinente, lo valida frente al genesis y al schema, y comprueba que las state transitions correspondientes estén ligadas a transacciones Bitcoin válidas.
RGB Protocol se apoya en Client-Side Validation y single-use seals. Bitcoin no replica los datos detallados del contrato: los participantes los conservan y validan, mientras los UTXO y las transacciones Bitcoin aportan prueba pública del cierre de sellos y protección frente al doble gasto. [6]
Un contrato comienza con una operación Genesis y cambia mediante state transitions dentro de un grafo acíclico dirigido. Cada transición consume owned state anterior, crea estado nuevo y enlaza sus commitments, mediante un anchor, con una witness transaction de Bitcoin. [3]
Un schema es una plantilla declarativa de la lógica de negocio: define tipos de datos, estado propio y global, operaciones permitidas y reglas de validación. Genesis crea después una instancia concreta, como la emisión y las asignaciones iniciales de un activo fungible o único. [2]
En una transferencia, el emisor entrega al receptor un consignment con genesis, schema, historial pertinente y pruebas. Antes de aceptarlo, el receptor valida localmente toda la cadena, sus anchors y sus vínculos con Bitcoin; un ticker o una cifra en una wallet no demuestra validez. [4]
El registro público de releases marca v0.10 como estable y la serie v0.11 como preliminar; las betas también advierten de cambios en el consenso RGB, no en el consenso Bitcoin. Para producción hace falta una versión exacta y compatible de todo el stack cliente, no una afirmación genérica de soporte RGB. [5]
La etiqueta RGB es ambigua sin contexto. La documentación actual separa expresamente el RGB Protocol on Bitcoin descrito de la propuesta distinta e inacabada v0.12 y de RGB++ en Nervos/CKB; compartir sigla no implica arquitectura común ni interoperabilidad. [1]
La privacidad y la escalabilidad tienen un coste de disponibilidad de datos. Bitcoin no puede reconstruir un consignment perdido desde su commitment; el receptor debe obtener todo el historial pertinente y el propietario debe respaldar de forma segura el stash y los demás datos del cliente. [4]
Para evaluar una afirmación sobre RGB hay que verificar versiones exactas de protocolo y librerías, schema y genesis, contract ID, tipo de commitment, capa admitida, integridad del consignment y estado de auditoría. La expresión on Bitcoin no demuestra por sí sola interoperabilidad, seguridad ni recuperación. [5]
Para obtener la imagen más completa, lee esta entrada junto con Client-Side Validation, UTXO, Taproot, Lightning Network, Sidechain, Hash. También enlazan con esta entrada Taproot Assets, Runes.
01¿Se guardan los contratos RGB directamente en la blockchain de Bitcoin?+
No. Bitcoin contiene las transacciones y commitments criptográficos necesarios para ordenar y cerrar sellos; el estado detallado y el historial de validación se transfieren y guardan en el cliente.
02¿Son compatibles entre sí todos los tokens llamados RGB?+
No de forma automática. La wallet debe admitir la versión concreta del protocolo, el schema, la interface y el procedimiento de commitment. Antes de aceptar, hay que verificar el contract ID y el consignment completo, no solo nombre o ticker.