En vez de publicar globalmente todos los datos del contrato, los participantes transfieren fuera de chain el historial necesario, verifican las reglas por sí mismos y comprueban en Bitcoin los commitments criptográficos y el cierre de single-use seals.
Cada receptor aplica las reglas del protocolo concreto solo a la parte del historial que conduce al estado recibido. Es una replicación parcial: los demás participantes no necesitan conocer ni conservar todo el grafo privado del contrato. [4]
Los datos necesarios se entregan fuera de Bitcoin como un paquete de historial y pruebas. El receptor no debe aceptar solo un saldo actual; debe verificar la secuencia de transiciones hasta un origen de confianza y vincular cada paso con su commitment on-chain. [4]
Un single-use seal es un compromiso abstracto que solo puede cerrarse válidamente una vez sobre un mensaje elegido. Un UTXO de Bitcoin puede actuar como ese sello: gastarlo es una prueba pública y ordenada por consenso del cierre, aunque Bitcoin no evalúa el significado de los datos privados. [3]
Proof-of-Publication ancla un commitment compacto en el orden público de transacciones y permite detectar el intento de usar el mismo sello para transiciones incompatibles. Los mineros y full nodes verifican las reglas de Bitcoin, no la lógica de negocio oculta tras el hash. [2]
Client-Side Validation es un modelo general de diseño, no un sinónimo de RGB. El registro LNP/BP enumera LNPBP-9 como borrador informativo, y sus bibliotecas ofrecen interfaces para commitments, serialización y single-use seals; cada protocolo define encima su propio estado y reglas. [5]
Privacidad y escalado trasladan a los propietarios la obligación de conservar los datos. Si el emisor no entrega todo el historial o el receptor pierde una parte necesaria, la blockchain pública no puede reconstruirla desde el commitment y la validación local puede quedar sin estado demostrable. [4]
El público suele ver solo una transacción Bitcoin y un commitment breve, no el contrato entero. Esto reduce la huella global de datos, pero no garantiza anonimato: tiempo, contrapartes, entrega de datos y una estructura de anchors reconocible pueden generar metadatos. [1]
Para verificar hacen falta protocolo exacto, genesis o schema fiable, definición del seal, commitment scheme, historial completo enlazado, estado de la transacción Bitcoin y versión del software. La mera presencia de un hash on-chain no prueba validez, valor ni propiedad del activo. [5]
Para obtener la imagen más completa, lee esta entrada junto con UTXO, Doble gasto, Hash, Taproot, Sidechain, Reglas de consenso. También enlazan con esta entrada RGB Protocol, Taproot Assets.
01¿Hacen Client-Side Validation los full nodes de Bitcoin?+
No. Los full nodes validan la transacción Bitcoin y sus reglas de consenso; el receptor valida localmente los datos privados y sus reglas con el cliente correspondiente.
02¿Requiere Client-Side Validation un soft fork?+
El modelo puede usar transacciones, commitments y gasto de UTXO existentes sin cambiar el consenso. El protocolo concreto debe publicar con precisión sus reglas y supuestos adicionales.