Com a crescente popularidade do RGB++ e da emissão de ativos relacionados, as discussões sobre os princípios dos protocolos RGB e RGB++ gradualmente se tornaram um tópico de interesse para mais pessoas. No entanto, percebeu-se que para entender o RGB++, primeiro é necessário compreender o protocolo RGB. O protocolo RGB original é um tanto técnico em sua estrutura, com materiais de referência dispersos, e até o momento não houve muitos materiais de referência sistemáticos e facilmente compreensíveis. A Geek Web3 já publicou duas interpretações sistemáticas do RGB e do RGB++ (disponíveis no histórico de nossa conta pública), mas, de acordo com o feedback da comunidade, esses artigos eram longos e muito complexos. Com o objetivo de permitir que mais pessoas entendam rapidamente os protocolos RGB e RGB++, o autor deste artigo completou rapidamente uma breve interpretação leiga do RGB e RGB++ durante um evento em Hong Kong. Pode ser lido em apenas alguns minutos, com o objetivo de ajudar mais entusiastas da comunidade a entenderem o RGB e o RGB++ de maneira melhor e mais intuitiva.

Protocolo RGB: Os utilizadores precisam de verificar pessoalmente os dados

O Protocolo RGB é um tipo especial de protocolo de ativos P2P, operando sob o sistema computacional da cadeia Bitcoin. De certa forma, é semelhante aos canais de pagamento: os usuários precisam executar seu cliente pessoalmente e verificar as ações de transferência relacionadas a si mesmos ("Verificar por si mesmo"). Mesmo se você for apenas um destinatário de ativos, primeiro deve confirmar que a declaração de transferência do remetente está correta antes que a transferência possa ter efeito. Este abordagem, conhecida como "transferência interativa", é marcadamente diferente dos métodos tradicionais de transferência e recepção de ativos. Por que isso é necessário? A razão é que o protocolo RGB, para proteger a privacidade, não utiliza o "protocolo de consenso" encontrado em blockchains tradicionais como Bitcoin e Ethereum (onde os dados, uma vez no protocolo de consenso, são observados por quase todos os nós na rede, tornando a privacidade difícil de proteger). Sem um processo de consenso envolvendo um grande número de nós, como garantir que as alterações nos ativos sejam seguras? Aqui é onde entra a ideia da "verificação do cliente" ("Verificar por si mesmo"). Você deve executar seu cliente e verificar pessoalmente as alterações de ativos relacionadas a você.

Por exemplo, vamos considerar um utilizador RGB chamado Bob que conhece a Alice. Alice quer transferir 100 tokens TEST para Bob. Depois de gerar a informação de transferência "Alice para Bob", Alice envia a informação de transferência e os dados de ativos relacionados para Bob verificar pessoalmente. Só quando Bob confirma que tudo está correto é que a transferência prossegue para se tornar uma transferência RGB válida. Assim, o protocolo RGB requer que os utilizadores verifiquem a validade dos dados por si próprios, substituindo os algoritmos de consenso tradicionais. No entanto, sem consenso, os dados recebidos e armazenados por diferentes clientes RGB são inconsistentes. Todos só armazenam localmente os dados de ativos relevantes para si próprios e não sabem sobre os estados de ativos dos outros. Embora isto proteja a privacidade, também cria "ilhas de dados". Se alguém afirmar ter 1 milhão de tokens TEST e quiser transferir 100.000 para si, como pode confiar neles? Na rede RGB, se alguém quiser transferir ativos para si, primeiro tem de fornecer prova de ativos, rastreando a história dos ativos desde a emissão inicial até múltiplas transferências, garantindo que os tokens que querem transferir para si são legítimos. É como quando recebe notas de banco inexplicáveis, pede ao remetente que explique a história destas notas, se foram emitidas pelo emitente designado, para evitar dinheiro falso.

(Fonte da imagem: Coinex)

O processo acima ocorre sob a cadeia Bitcoin, e essas etapas por si só não estabelecem uma conexão direta entre RGB e a rede Bitcoin. Para resolver isso, o protocolo RGB emprega o conceito de "selos de uso único," que ligam ativos RGB a UTXOs (Unspent Transaction Outputs) na cadeia Bitcoin. Desde que o UTXO do Bitcoin não seja gasto duas vezes, os ativos RGB vinculados não estarão sujeitos a pagamento duplicado, aproveitando assim a rede Bitcoin para evitar a "Reorganização" de ativos RGB. Claro, isso requer a publicação de Compromissos na cadeia Bitcoin e o uso do opcode OP_Return.

Vamos delinear o fluxo de trabalho do protocolo RGB:

1. Os ativos RGB estão vinculados aos UTXOs do Bitcoin, e Bob possui certos UTXOs do Bitcoin. Alice quer transferir 100 tokens para Bob. Antes de receber os ativos, Bob informa a Alice qual UTXO do Bitcoin dele deve ser usado para vincular esses ativos RGB.

(Fonte da imagem: Geekweb3/GeekWeb3)

1. Alice constrói os dados da transação para a transferência de ativos RGB de “Alice para Bob”, juntamente com o histórico desses ativos, e dá a Bob para verificação.
2. Depois de Bob confirmar que os dados estão corretos localmente, ele envia um recibo para Alice, informando-a de que a transação pode prosseguir.
3. Alice constrói os dados de transferência RGB "Alice para Bob" em uma Árvore de Merkle e publica a Raiz de Merkle na cadeia do Bitcoin como um Compromisso. Podemos simplesmente entender Compromisso como o hash dos dados de transferência.
4. Se alguém no futuro quiser confirmar que a transferência “Alice para Bob” realmente ocorreu, precisam de fazer duas coisas: obter a informação completa da transferência de “Alice para Bob” na cadeia de Bitcoin e depois verificar se o Compromisso correspondente (o hash dos dados da transferência) existe na cadeia de Bitcoin.

O Bitcoin serve como o registo histórico para a rede RGB, mas o registo apenas regista o hash/raiz de Merkle dos dados da transação, não os próprios dados da transação. Devido à adoção da verificação do lado do cliente e selos de utilização única, o protocolo RGB oferece uma segurança extremamente elevada. Uma vez que a rede RGB é composta por clientes de utilizadores dinâmicos de forma P2P, sem consenso, pode alterar as contrapartes da transação a qualquer momento sem necessidade de enviar pedidos de transação a um número limitado de nós. Portanto, a rede RGB exibe uma forte resistência à censura. Esta estrutura organizacional torna-a mais resistente à censura em comparação com cadeias públicas em larga escala como o Ethereum.

(Fonte da imagem: BTCEden.org)

Certamente, a alta segurança, resistência à censura e proteção da privacidade trazidas pelo protocolo RGB também têm custos significativos. Os utilizadores precisam de executar o seu cliente para verificar os dados. Se alguém lhe enviar ativos com um longo histórico de transações envolvendo milhares de transferências, terá de as verificar todas, o que pode ser bastante pesado.

Além disso, cada transação requer múltiplas comunicações entre as partes. O destinatário precisa verificar a origem do ativo do remetente e depois enviar um recibo para aprovar o pedido de transferência do remetente. Este processo envolve pelo menos três trocas de mensagens entre as partes. Esta “transferência interativa” é muito diferente da “transferência não interativa” à qual a maioria das pessoas está habituada. Imagine alguém precisando enviar-lhe dinheiro e tendo que enviar-lhe os dados da transação para sua inspeção, esperando pela sua mensagem de recibo antes de completar o processo de transferência.

Além disso, como mencionamos anteriormente, a rede RGB carece de consenso, e cada cliente opera de forma isolada, tornando difícil migrar cenários complexos de contratos inteligentes das cadeias públicas tradicionais para a rede RGB. Isso ocorre porque os protocolos DeFi no Ethereum ou Solana dependem de livros-razão globalmente visíveis e transparentes. Como otimizar o protocolo RGB, melhorar a experiência do usuário e lidar com esses desafios torna-se uma questão inevitável para o protocolo RGB.

RGB++ Introduz Uma Abordagem de Custódia Otimista, Substituindo a Verificação do Lado do Cliente.

O protocolo chamado RGB++ introduz uma nova abordagem ao combinar o protocolo RGB com cadeias públicas suportadas por UTXO, como CKB, Cardano e Fuel. Nesta configuração, este último serve como a camada de validação e armazenamento de dados para ativos RGB, transferindo as tarefas de verificação de dados originalmente realizadas pelos usuários para plataformas/cadeias de terceiros como CKB. Isso substitui efetivamente a verificação do lado do cliente pela 'verificação de plataforma descentralizada de terceiros'. Desde que confie em plataformas/cadeias como CKB, Cardano ou Fuel, está tudo bem. Se não confiar nelas, pode sempre voltar ao modo tradicional de RGB.

RGB++ e o protocolo RGB original são teoricamente compatíveis entre si; não se trata de um ou outro, mas sim de poderem coexistir.

Para alcançar o efeito mencionado, precisamos aproveitar um conceito chamado “ligações homomórficas.” As cadeias públicas como CKB e Cardano têm seus próprios modelos UTXO estendidos, que oferecem mais programabilidade em comparação com UTXOs na cadeia Bitcoin. “Ligação homomórfica” é a ideia de usar os UTXOs estendidos em cadeias como CKB, Cardano e Fuel como os “recipientes” para os dados de ativos RGB. Os parâmetros dos ativos RGB são escritos nesses recipientes e exibidos diretamente na blockchain. Sempre que ocorre uma transação de ativos RGB, o recipiente de ativos correspondente também pode exibir características semelhantes, semelhantes à relação entre entidades e sombras. Essa é a essência da “ligação homomórfica.”

(Fonte da imagem: RGB++ LightPaper)

Por exemplo, se a Alice possui 100 tokens RGB e um UTXO (vamos chamá-lo de UTXO A) na cadeia do Bitcoin, bem como um UTXO na cadeia CKB marcado com 'Saldo do Token RGB: 100' e condições desbloqueadas associadas ao UTXO A:

Se Alice quiser enviar 30 tokens para Bob, ela pode primeiro gerar um Compromisso com a declaração correspondente: transferir 30 tokens RGB associados ao UTXO A para Bob e transferir 70 tokens para outro UTXO controlado por ela mesma.

De seguida, Alice gasta o UTXO A na cadeia do Bitcoin, publica a declaração acima e, em seguida, inicia uma transação na cadeia CKB. Esta transação consome o contentor UTXO que contém 100 tokens RGB, criando dois novos contentores: um com 30 tokens (para Bob) e outro com 70 tokens (controlados por Alice). Durante este processo, a tarefa de verificar a validade dos ativos de Alice e das declarações de transação é concluída por consenso entre os nós em redes como CKB ou Cardano, sem o envolvimento de Bob. Neste ponto, CKB e Cardano atuam como a camada de validação e a camada DA (Disponibilidade de Dados), respetivamente, sob a cadeia do Bitcoin.

(Fonte da imagem: RGB++ LightPaper)

Todos os dados de ativos RGB individuais são armazenados na cadeia CKB ou Cardano, fornecendo uma característica globalmente verificável que facilita a implementação de cenários DeFi como pools de liquidez e protocolos de aposta de ativos. Claro, a abordagem acima também sacrifica a privacidade. Essencialmente envolve uma troca entre privacidade e usabilidade do produto. Se você prioriza a máxima segurança e privacidade, pode voltar ao modo RGB tradicional. Se não se importar com essas trocas, pode adotar com confiança o modo RGB++, dependendo inteiramente de suas necessidades pessoais. (Na verdade, aproveitando a funcionalidade poderosa de cadeias públicas como CKB e Cardano, transações privadas podem ser alcançadas por meio do uso de ZK.)

É importante enfatizar que o RGB++ introduz uma suposição significativa de confiança: os usuários precisam acreditar otimisticamente que a cadeia CKB/Cardano ou a plataforma de rede composta por um grande número de nós por meio de protocolo de consenso é confiável e sem erros. Se você não confia na CKB, pode seguir o processo de comunicação e verificação interativa no protocolo RGB original executando seu cliente.

Sob o protocolo RGB++, os usuários podem usar diretamente suas contas de Bitcoin para operar seus contêineres de ativos RGB nas cadeias CKB/Cardano UTXO sem a necessidade de transações entre cadeias. Eles simplesmente precisam alavancar as características de UTXOs nas mencionadas cadeias públicas e definir as condições de desbloqueio do contêiner de células para ser associado a um endereço/UTXO específico de Bitcoin. Se as partes envolvidas nas transações de ativos RGB confiarem na segurança do CKB, elas podem nem precisar publicar frequentemente Compromissos na cadeia de Bitcoin. Em vez disso, podem agregar e enviar um Compromisso para a cadeia de Bitcoin após várias transferências RGB terem ocorrido. Isso é conhecido como o recurso de “dobrar transação”, que pode reduzir os custos da transação.

É importante notar que os “contentores” usados em ligações homomórficas precisam ser suportados por cadeias públicas que usam o modelo UTXO ou têm características semelhantes em sua infraestrutura de armazenamento de estado. As cadeias baseadas em EVM não são muito adequadas para este fim e podem enfrentar muitos desafios. (Este tópico poderia ser abordado em um artigo separado, pois envolve muito conteúdo. Os leitores interessados podem consultar artigos anteriores da Geek Web3 intitulados “RGB++ e Ligações Homomórficas: Como CKB, Cardano e Fuel capacitam o ecossistema Bitcoin.“)

Em resumo, as cadeias públicas ou camadas de extensão de funcionalidade adequadas para implementar ligações homomórficas devem ter as seguintes características:

1. Utilize o modelo UTXO ou esquemas de armazenamento de estado semelhantes.
2. Oferecer programabilidade UTXO suficiente, permitindo aos desenvolvedores escrever scripts de desbloqueio.
3. Tenha um espaço de estado relacionado aos UTXOs que pode armazenar estados de ativos.
4. Ter pontes ou nós leves relacionados ao Bitcoin disponíveis.

Aviso legal：

1. Este artigo é reproduzido a partir de [极客 Web3], Todos os direitos autorais pertencem ao autor original [Faust]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Responsabilidade de Isenção: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.