Em vez de publicar globalmente todos os dados do contrato, os participantes transferem o histórico necessário off-chain, verificam as regras por conta própria e conferem no Bitcoin os commitments criptográficos e o fechamento de single-use seals.
Cada destinatário aplica as regras do protocolo específico somente à parte do histórico que leva ao estado recebido. É uma replicação parcial: os demais participantes não precisam conhecer nem guardar todo o grafo privado do contrato. [4]
Os dados necessários circulam fora do Bitcoin como um pacote de histórico e provas. O destinatário não deve aceitar apenas o saldo atual; precisa verificar a sequência de transições até uma origem confiável e o vínculo de cada etapa com seu commitment on-chain. [4]
Um single-use seal é um commitment abstrato que só pode ser fechado validamente uma vez sobre a mensagem escolhida. Um UTXO do Bitcoin pode ser esse selo: gastá-lo é uma prova pública e ordenada pelo consensus do fechamento, embora o Bitcoin não avalie o significado dos dados privados. [3]
Proof-of-Publication ancora um commitment compacto na ordem pública das transações e permite detectar o uso do mesmo selo em transições incompatíveis. Miners e full nodes verificam as regras do Bitcoin, não a lógica comercial escondida atrás do hash. [2]
Client-Side Validation é um modelo geral de projeto, não sinônimo de RGB. O registro LNP/BP lista LNPBP-9 como draft informativo, e as bibliotecas relacionadas fornecem interfaces para commitments, serialização e single-use seals; protocolos concretos definem seu próprio estado e regras. [5]
Privacidade e escala transferem aos proprietários a obrigação de guardar os dados. Se o remetente não entregar todo o histórico ou o destinatário perder uma parte necessária, a blockchain pública não consegue reconstruí-la a partir do commitment e a validação local pode ficar sem estado comprovável. [4]
O público costuma ver apenas uma transação Bitcoin e um commitment curto, não o contrato inteiro. Isso reduz a pegada global de dados, mas não garante anonimato: tempo, contrapartes, entrega de dados e estruturas reconhecíveis de anchors podem gerar metadados. [1]
A verificação exige o protocolo exato, genesis ou schema confiável, definição do seal, commitment scheme, histórico completo encadeado, estado da transação Bitcoin e versão do software. A simples existência de um hash on-chain não prova validade, valor nem propriedade do ativo. [5]
Para ter uma visão mais completa, leia este verbete junto com UTXO, Gasto duplo, Hash, Taproot, Sidechain, Regras de consenso. Também há referências a este verbete em RGB Protocol, Taproot Assets.
01Bitcoin full nodes fazem Client-Side Validation?+
Não. Full nodes verificam a transação Bitcoin e suas regras de consenso; o destinatário verifica localmente os dados privados e suas regras com o cliente adequado.
02Client-Side Validation exige soft fork?+
O modelo pode usar transações, commitments e gastos de UTXO já existentes sem mudar o consenso. O protocolo concreto ainda precisa divulgar com precisão seus pressupostos e regras adicionais.