O destinatário recebe um consignment com o histórico relevante, valida-o contra o genesis e o schema e confirma que as state transitions correspondentes estão ligadas a transações Bitcoin válidas.
RGB Protocol assenta em Client-Side Validation e single-use seals. Bitcoin não replica os dados detalhados do contrato; os participantes guardam-nos e validam-nos, enquanto UTXO e transações Bitcoin fornecem prova pública do fecho dos selos e proteção contra double-spend. [6]
Um contrato começa com uma operação Genesis e muda depois por state transitions num grafo acíclico dirigido. As transições consomem o owned state anterior, criam novo estado e ligam os seus commitments, através de um anchor, a uma Bitcoin witness transaction. [3]
Um schema é um modelo declarativo de lógica de negócio: define tipos de dados, estado próprio e global, operações permitidas e regras de validação. Genesis cria então uma instância concreta do schema, como a emissão e as alocações iniciais de um ativo fungível ou único. [2]
Numa transferência, o remetente entrega ao destinatário um consignment com genesis, schema, histórico relevante e provas. Antes de aceitar, o destinatário valida localmente toda a cadeia, os anchors e as ligações ao Bitcoin; um ticker ou valor mostrado na wallet não prova validade. [4]
O registo público de versões classifica v0.10 como estável e a série v0.11 como pré-lançamento; as versões beta também alertam para mudanças no consenso RGB, não no consenso Bitcoin. O uso em produção exige uma versão exata e compatível de toda a stack cliente, não uma alegação genérica de suporte RGB. [5]
A designação RGB é ambígua sem contexto. A documentação atual separa expressamente o RGB Protocol on Bitcoin descrito da proposta distinta e inacabada v0.12 e do RGB++ em Nervos/CKB; a mesma sigla não garante arquitetura comum nem interoperabilidade. [1]
Privacidade e escala têm um custo de disponibilidade de dados. Bitcoin não reconstrói um consignment perdido a partir do commitment; o destinatário deve obter todo o histórico relevante e o proprietário deve fazer backup seguro do stash e dos outros dados do cliente. [4]
Para avaliar uma afirmação sobre RGB, é preciso confirmar versões exatas de protocolo e bibliotecas, schema e genesis, contract ID, tipo de commitment, camada suportada, integridade do consignment e estado das auditorias. A expressão on Bitcoin não prova, por si, interoperabilidade, segurança ou recuperação. [5]
Para ter uma visão mais completa, leia este verbete junto com Client-Side Validation, UTXO, Taproot, Lightning Network, Sidechain, Hash. Também há referências a este verbete em Taproot Assets, Runes.
01Os contratos RGB ficam diretamente na blockchain do Bitcoin?+
Não. Bitcoin transporta transações e commitments criptográficos necessários à ordem e ao fecho dos selos; o estado detalhado e o histórico de validação são transmitidos e guardados no lado do cliente.
02Todos os tokens chamados RGB são compatíveis entre si?+
Não automaticamente. A wallet deve suportar a versão concreta do protocolo, o schema, a interface e o processo de commitment. Antes de aceitar, confirme o contract ID e o consignment completo, não apenas o nome ou ticker.