protocolo RGB: os utilizadores devem verificar os dados por si mesmos

O protocolo RGB é um protocolo de ativos P2P especial e um sistema de computação sob a cadeia Bitcoin. É semelhante a um canal de pagamento em alguns aspectos: os usuários precisam executar o cliente por si próprios e verificar seu próprio comportamento de transferência (Verificar por si próprios). Mesmo que você seja apenas um destinatário de ativos, primeiro você deve garantir que não haja erros na declaração de transferência do remetente de ativos antes que a declaração de transferência possa entrar em vigor. Obviamente, isso é completamente diferente da forma tradicional de enviar e receber ativos. Chamamos isso de “transferência interativa”.

Por que isso deve ser assim? A razão é que, para garantir a privacidade, o protocolo RGB não adota o “protocolo de consenso” nas blockchains tradicionais como o Bitcoin e o Ethereum. (Uma vez que os dados passam pelo protocolo de consenso, eles serão observados por quase todos os nós na rede, e a privacidade não é garantida). Como garantir que as alterações de ativos sejam seguras sem um processo de consenso envolvendo um grande número de nós? A ideia chamada “Verificação do Cliente” (Verificar por si mesmo) é usada aqui. Você precisa executar o cliente você mesmo e verificar pessoalmente as alterações de ativos relacionadas a você. Suponha que haja um usuário RGB chamado Bob que conhece Alice, e Alice quer transferir 100 tokens TEST para Bob. Depois que Alice gera as informações de transferência de “Alice para Bob”, ela deve primeiro enviar as informações de transferência e os dados do ativo envolvidos para Bob, e deixá-lo verificar pessoalmente para garantir que está correto antes de prosseguir para o processo subsequente, e finalmente se torna uma transferência RGB válida. Dessa forma, o protocolo RGB permite que os usuários verifiquem pessoalmente a validade dos dados, substituindo o algoritmo de consenso tradicional. Mas sem consenso, os dados recebidos e armazenados por diferentes clientes RGB são inconsistentes. Cada um armazena apenas seus próprios dados de ativos localmente e não sabe o status do ativo dos outros. Ao proteger a privacidade, isso também constitui uma “ilha de dados”. Se alguém afirmar ter 1 milhão de tokens TEST e quiser transferir 100.000 para você, como você pode acreditar? Na rede RGB, se alguém quiser transferir dinheiro para você, ele deve primeiro mostrar a prova dos ativos, rastrear a fonte histórica dos ativos desde a emissão inicial até várias mudanças de mãos, e garantir que o Token a ser transferido para você esteja limpo. Isso é como quando você recebe notas de banco de origem desconhecida e pede à outra parte para explicar a fonte histórica dessas notas de banco e se foram feitas pelo emissor designado, para evitar moeda falsificada.

(Fonte da imagem: Coinex)

Os processos acima ocorrem sob a cadeia do Bitcoin, e esses processos sozinhos não podem tornar o RGB diretamente relacionado à rede Bitcoin. Nesse sentido, o protocolo RGB adota uma ideia chamada “selo de uso único” para vincular ativos RGB ao UTXO na cadeia do Bitcoin. Desde que o UTXO do Bitcoin não seja consumido duplamente, os ativos RGB vinculados não serão gastos duplamente. Dessa forma, a rede Bitcoin pode ser usada para prevenir a “Reorganização” dos ativos RGB. Naturalmente, esse Compromisso precisa ser publicado na cadeia do Bitcoin e o opcode OP_Return é usado.

Aqui está um resumo do fluxo de trabalho do protocolo RGB:

1. Os ativos RGB estão ligados ao Bitcoin UTXO, e Bob possui certos Bitcoin UTXOs. Alice quer transferir 100 tokens para Bob. Antes de receber os ativos, Bob diz a Alice antecipadamente qual Bitcoin UTXO de Bob deve ser usado para ligar esses ativos RGB.

(Fonte da imagem: Geekweb3/GeekWeb3)

1. Alice constrói um dado de transferência de ativos RGB “Alice para Bob”, juntamente com as fontes históricas desses ativos, e dá-os a Bob para verificação.
2. Depois de Bob confirmar localmente que os dados estão OK, ele envia um recibo para Alice, dizendo-lhe que a transação pode prosseguir.
3. Alice constrói os dados de transferência RGB de “Alice para Bob” em uma Árvore de Merkle e publica a Raiz de Merkle na cadeia de Bitcoin como um Compromisso. Podemos simplesmente entender o Compromisso como o hash dos dados de transferência.
4. Se alguém quiser confirmar no futuro que a transferência acima mencionada de 'Alice para Bob' realmente ocorreu, ele precisa fazer duas coisas: obter as informações completas da transferência de 'Alice para Bob' sob a cadeia Bitcoin e depois verificar se há uma transação correspondente na cadeia Bitcoin. Compromisso (hash dos dados de transferência), é isso.

Aqui, o Bitcoin atua como o registo histórico da rede RGB, mas apenas o hash/Merkle root dos dados da transação é registado no registo, em vez dos próprios dados da transação. Graças à validação do lado do cliente e ao selamento único, o protocolo RGB possui uma segurança extremamente alta. Uma vez que a rede RGB é composta por clientes de utilizadores dinâmicos de forma P2P e livre de consenso, pode alterar a contraparte a qualquer momento sem enviar pedidos de transação a um número limitado de nós. Assim, as redes RGB são extremamente resistentes à censura e esta forma organizacional é mais resistente à censura do que grandes cadeias públicas como o Ethereum.

(Fonte da imagem: BTCEden.org)

Certamente, a segurança extremamente alta, a resistência à censura e a proteção da privacidade vêm com custos óbvios: os usuários têm que executar o cliente para verificar os dados eles mesmos. Se a outra parte lhe enviar alguns ativos que mudaram de mãos dezenas de milhares de vezes e têm uma longa história, você tem que verificá-los todos sob pressão.

Além disso, cada transação requer múltiplas comunicações entre as duas partes. A parte receptora deve primeiro verificar a origem dos ativos do remetente e depois enviar um recibo para aprovar o pedido de transferência do remetente. Durante este processo, pelo menos três mensagens devem ser trocadas entre as duas partes. Esse tipo de "transferência interativa" é seriamente inconsistente com a "transferência não interativa" com a qual a maioria das pessoas está acostumada.

Consegue imaginar alguém querer transferir-lhe dinheiro, mas ter de lhe enviar os dados da transação para verificação e só depois de receber a sua mensagem de recibo poder o processo de transferência ser concluído?

Além disso, mencionámos que a rede RGB não tem consenso e cada cliente é uma ilha, o que não é propício para migrar cenários complexos de contratos inteligentes na cadeia pública tradicional para a rede RGB, porque o protocolo Defi na Ethereum ou Solana depende de um livro-razão globalmente visível e transparente. Como otimizar o protocolo RGB, melhorar a experiência do utilizador e resolver os problemas acima mencionados? Este tornou-se um problema inevitável para o protocolo RGB.

RGB++: A verificação do lado do cliente torna-se custódia otimista

O protocolo chamado RGB++ propõe uma nova ideia. Combina o protocolo RGB com cadeias públicas que suportam UTXO como CKB, Cardano e Fuel. Este último serve como a camada de verificação e camada de armazenamento de dados para os ativos RGB, e converte dados originalmente processados pelos utilizadores no trabalho de verificação e é entregue a plataformas de terceiros/cadeias públicas como CKB. Isto equivale a substituir a verificação do cliente por uma “plataforma de verificação descentralizada de terceiros”, desde que confie em cadeias públicas como CKB, Cardano, Fuel, etc.. Mesmo que não confie nelas, pode voltar ao modo RGB tradicional.

RGB++ e o protocolo RGB original são teoricamente compatíveis entre si.

Para alcançar os efeitos acima mencionados, precisamos usar uma ideia chamada "ligação isomórfica". Cadeias públicas como CKB e Cardano têm seu próprio UTXO estendido, que é mais programável do que o UTXO na cadeia BTC. A "ligação isomórfica" é usar o UTXO estendido nas cadeias CKB, Cardano e Fuel como "recipientes" para os dados do ativo RGB, escrever os parâmetros dos ativos RGB nesses recipientes e exibi-los diretamente no blockchain. Sempre que ocorre uma transação de ativos RGB, o recipiente de ativos correspondente também pode mostrar características semelhantes, assim como a relação entre entidades e sombras. Esta é a essência da "ligação isomórfica".

(Fonte da imagem: RGB++ LightPaper)

Por exemplo, se Alice possui 100 tokens RGB e UTXO A na cadeia do Bitcoin, e também possui um UTXO na cadeia CKB, este UTXO é marcado com "Saldo de Tokens RGB: 100", e as condições de desbloqueio estão relacionadas ao UTXO A.

Se Alice quiser enviar 30 tokens para Bob, ela pode primeiro gerar um Compromisso. A declaração correspondente é: transferir 30 dos tokens RGB associados ao UTXO A para Bob e transferir 70 para outros UTXOs que ela controla.

Posteriormente, Alice gasta UTXO A na cadeia do Bitcoin, publica a declaração acima e depois inicia uma transação na cadeia CKB para consumir o recipiente UTXO que transporta 100 tokens RGB e gerar dois novos recipientes, um contendo 30 tokens (para Bob), outro contendo 70 tokens (controlado por Alice). Neste processo, a tarefa de verificar a validade dos ativos de Alice e a validade da declaração de transação é concluída por nós de rede como CKB ou Cardano através de consenso, sem intervenção de Bob. Neste momento, CKB e Cardano atuam como a camada de verificação e a camada DA sob a cadeia do Bitcoin.

(Fonte da imagem: RGB++ LightPaper)

Os dados de ativos RGB de todos são armazenados na cadeia CKB ou Cardano, que tem características globalmente verificáveis e é propícia à implementação de Defi, como pools de liquidez e protocolos de garantia de ativos. Claro, a abordagem acima também sacrifica a privacidade. A essência é fazer um compromisso entre privacidade e facilidade de uso do produto. Se você busca segurança e privacidade definitivas, pode voltar ao modo RGB tradicional; se não se importa com isso, pode usar com segurança o modo RGB++, tudo depende das suas necessidades pessoais. (Na verdade, com a completa funcionalidade poderosa de cadeias públicas como CKB e Cardano, ZK pode ser usado para implementar transações privadas)

Deve ser enfatizado aqui que o RGB++ introduz uma suposição de confiança importante: Os utilizadores devem ser otimistas de que a cadeia CKB/Cardano, ou a plataforma de rede composta por um grande número de nós que dependem de protocolos de consenso, é confiável e sem erros. Se não confiar na CKB, também pode seguir o processo de comunicação interativa e verificação no protocolo RGB original e executar o cliente por si mesmo.

Sob o protocolo RGB++, os utilizadores podem utilizar diretamente as suas contas Bitcoin para operar os seus contentores de ativos RGB nas cadeias UTXO, como CKB/Cardano, sem necessidade de fazer transações entre cadeias. Basta aproveitar as características do UTXO na referida cadeia pública e definir a condição de desbloqueio do contentor Cell associada a um determinado endereço Bitcoin/UTXO Bitcoin. Se ambas as partes envolvidas em transações de ativos RGB confiarem na segurança do CKB, nem precisarão de emitir Compromissos frequentemente na cadeia Bitcoin. Após várias transferências RGB serem feitas, um Compromisso pode ser enviado para a cadeia Bitcoin. Isso é chamado de função de "dobragem de transações", que pode reduzir os custos de utilização.

Mas tenha cuidado, o "contêiner" usado na ligação isomórfica necessita de uma cadeia pública que suporte o modelo UTXO, ou uma infraestrutura com características semelhantes no armazenamento de estado. A cadeia EVM não é adequada e encontrará muitos obstáculos. (Este tópico pode ser escrito separadamente e envolve muito conteúdo. Os leitores interessados podem consultar os artigos anteriores da Geek Web3).“RGB++ e Ligação Isomórfica: Como CKB, Cardano e Fuel potenciam o ecossistema Bitcoin”；

Em resumo, uma camada de expansão de função/cadeia pública adequada para realizar ligação isomórfica deve ter as seguintes características:

1. Utilize o modelo UTXO ou esquema de armazenamento de estado semelhante;
2. Tem uma considerável programabilidade UTXO, permitindo aos programadores escrever scripts de desbloqueio;
3. Existe um espaço de estado relacionado com UTXO que pode armazenar o estado do ativo;
4. Existem pontes ou nós leves relacionados ao Bitcoin;

Aviso Legal:

1. Este artigo é reproduzido a partir de [ Geek Web3], o título original é "Design de protocolo RGB e RGB++ em poucos minutos: instruções simples", os direitos autorais pertencem ao autor original [Faust], se tiver alguma objeção à reprodução, por favor contacteGate Equipa de Aprendizagem, a equipa irá tratar disso o mais breve possível de acordo com os procedimentos relevantes.

2. As opiniões e pontos de vista expressos neste artigo representam apenas as opiniões pessoais do autor e não constituem qualquer conselho de investimento.

3. Outras versões linguísticas do artigo são traduzidas pela equipa Gate Learn. Sem referenciarGate.io, a cópia, distribuição ou plágio dos artigos traduzidos é proibida.