Au lieu de publier mondialement toutes les données du contrat, les participants transmettent hors chaîne l’historique nécessaire, vérifient eux-mêmes les règles et contrôlent sur Bitcoin les commitments cryptographiques et la fermeture des single-use seals.
Chaque destinataire applique les règles du protocole concerné à la seule partie de l’historique menant à l’état reçu. Il s’agit d’une réplication partielle : les autres participants n’ont pas à connaître ni conserver tout le graphe privé du contrat. [4]
Les données requises circulent hors de Bitcoin sous forme d’un paquet d’historique et de preuves. Le destinataire ne doit pas accepter un simple solde actuel ; il vérifie l’enchaînement des transitions jusqu’à une origine fiable et le lien de chaque étape avec son commitment on-chain. [4]
Un single-use seal est un engagement abstrait qui ne peut être valablement fermé qu’une seule fois sur un message choisi. Un UTXO Bitcoin peut jouer ce rôle : sa dépense est une preuve publique et ordonnée par le consensus de la fermeture, sans que Bitcoin interprète les données privées. [3]
Proof-of-Publication ancre un commitment compact dans l’ordre public des transactions et rend détectable l’emploi du même sceau pour des transitions incompatibles. Mineurs et full nodes vérifient les règles Bitcoin, pas la logique métier cachée derrière le hash. [2]
Client-Side Validation est un modèle de conception général, pas un synonyme de RGB. Le registre LNP/BP classe LNPBP-9 comme brouillon informatif, et les bibliothèques associées offrent des interfaces de commitments, sérialisation et single-use seals ; chaque protocole définit ensuite son propre état et ses règles. [5]
Confidentialité et passage à l’échelle reportent sur les propriétaires l’obligation de conserver les données. Si l’émetteur ne remet pas tout l’historique ou si le destinataire perd une pièce requise, la blockchain publique ne peut pas la reconstruire depuis le commitment et la validation locale peut rester sans état démontrable. [4]
Le public ne voit généralement qu’une transaction Bitcoin et un court commitment, pas le contrat entier. Cela réduit l’empreinte globale sans garantir l’anonymat : chronologie, contreparties, transmission des données et structure reconnaissable des anchors peuvent produire des métadonnées. [1]
La vérification exige le protocole exact, un genesis ou schema fiable, la définition du seal, le commitment scheme, l’historique lié complet, l’état de la transaction Bitcoin et la version logicielle. La seule présence d’un hash on-chain ne prouve ni validité, ni valeur, ni propriété de l’actif. [5]
Pour une vision complète, lisez aussi UTXO, Double dépense, Hash, Taproot, Sidechain, Règles de consensus. Cette entrée est également citée par RGB Protocol, Taproot Assets.
01Les full nodes Bitcoin effectuent-ils Client-Side Validation ?+
Non. Ils valident la transaction Bitcoin et ses règles de consensus ; le destinataire vérifie localement les données privées et leurs règles avec le client approprié.
02Client-Side Validation exige-t-il un soft fork ?+
Le modèle peut employer les transactions, commitments et dépenses d’UTXO existants sans changer le consensus. Le protocole concret doit néanmoins publier précisément ses règles et hypothèses supplémentaires.