Com a crescente popularidade do RGB++ e 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, percebe-se que, para entender o RGB++, é necessário primeiro 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. O Geek Web3 já publicou duas interpretações sistemáticas do RGB e RGB++ (disponíveis no histórico de nossa conta pública), mas, de acordo com o feedback da comunidade, esses artigos eram longos e complexos demais. Para permitir que mais pessoas entendam rapidamente os protocolos RGB e RGB++, o autor deste artigo completou apressadamente 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 RGB++ de forma melhor e mais intuitiva.

Protocolo RGB: Usuários Precisam 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, você deve primeiro confirmar que a declaração de transferência do remetente está correta antes que a transferência possa ter efeito. Essa 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 as mudanças de ativos podem ser garantidas como seguras? Aqui é onde a ideia de "verificação do cliente" ("Verifique por si mesmo") entra. Você tem que executar seu cliente e verificar pessoalmente as mudanças de ativos relacionadas a você.

Por exemplo, vamos considerar um usuário RGB chamado Bob que conhece Alice. Alice deseja transferir 100 tokens TEST para Bob. Após gerar as informações de transferência de “Alice para Bob”, Alice envia as informações de transferência e os dados de ativos relacionados para Bob verificar pessoalmente. Somente quando Bob confirma que tudo está correto, a transferência prossegue para se tornar uma transferência RGB válida. Portanto, o protocolo RGB requer que os usuários verifiquem a validade dos dados por si mesmos, substituindo os algoritmos de consenso tradicionais. No entanto, sem consenso, os dados recebidos e armazenados por diferentes clientes RGB são inconsistentes. Todos armazenam apenas os dados de ativos relevantes para si localmente e não conhecem os estados de ativos dos outros. Embora isso 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 você, como você confia neles? Na rede RGB, se alguém quiser transferir ativos para você, eles devem primeiro fornecer prova de ativos, rastreando a história dos ativos desde a emissão inicial até várias transferências, garantindo que os tokens que desejam transferir para você sejam legítimos. É como quando você recebe notas de banco não explicadas, você pede ao remetente para explicar a história dessas notas, se foram emitidas pelo emissor designado, para evitar dinheiro falso.

(Fonte da imagem: Coinex)

O processo acima ocorre sob a cadeia do Bitcoin e essas etapas por si só não estabelecem uma conexão direta entre o RGB e a rede Bitcoin. Para resolver isso, o protocolo RGB emprega o conceito de "selos de uso único", que vinculam os ativos RGB aos UTXOs (Unspent Transaction Outputs) na cadeia do 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" dos ativos RGB. Obviamente, isso requer a publicação de Compromissos na cadeia do Bitcoin e o uso do opcode OP_Return.

Vamos esboçar o fluxo de trabalho do protocolo RGB:

1. 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 dados da transação para a transferência de ativos RGB de 'Alice para Bob', juntamente com o histórico desses ativos, e entrega a Bob para verificação.
2. Depois que Bob confirma 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, eles precisam fazer duas coisas: obter as informações completas da transferência de “Alice para Bob” na cadeia do Bitcoin e depois verificar se o Compromisso correspondente (o hash dos dados da transferência) existe na cadeia do Bitcoin.

O Bitcoin serve como o log histórico para a rede RGB, mas o log apenas registra o hash/Merkle root 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 uso único, o protocolo RGB oferece segurança extremamente alta. Uma vez que a rede RGB é composta por clientes de usuários dinâmicos de forma P2P, sem consenso, você pode alterar os contrapartes da transação a qualquer momento sem precisar enviar solicitações de transação para um número limitado de nós. Portanto, a rede RGB apresenta forte resistência à censura. Essa estrutura organizacional a torna mais resistente à censura em comparação com grandes 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 vêm com custos significativos. Os usuários precisam executar seu cliente para verificar dados. Se alguém lhe enviar ativos com um longo histórico de transações envolvendo milhares de transferências, você precisará verificá-las todas, o que pode ser bastante oneroso.

Além disso, cada transação requer várias comunicações entre as partes. O destinatário precisa verificar a origem do ativo do remetente e então enviar um recibo para aprovar a solicitação de transferência do remetente. Esse processo envolve pelo menos três trocas de mensagens entre as partes. Essa 'transferência interativa' é muito diferente da 'transferência não interativa' à qual a maioria das pessoas está acostumada. Imagine alguém precisando lhe enviar dinheiro e tendo que enviar os dados da transação para sua inspeção, aguardando sua mensagem de recibo antes de concluir 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 enfrentar 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 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 você confie em plataformas/cadeias como CKB, Cardano ou Fuel, você está pronto para começar. Se você não confia neles, você sempre pode voltar para o modo tradicional RGB.

RGB++ e o protocolo original RGB 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'. Cadeias públicas como CKB e Cardano possuem seus próprios modelos UTXO estendidos, que oferecem mais programabilidade em comparação com os UTXOs na cadeia do Bitcoin. 'Ligação homomórfica' é a ideia de usar os UTXOs estendidos em cadeias como CKB, Cardano e Fuel como os 'contêineres' para dados de ativos RGB. Os parâmetros dos ativos RGB são escritos nesses contêineres e exibidos diretamente na blockchain. Sempre que ocorre uma transação de ativo RGB, o contêiner 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 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.

Em seguida, Alice gasta UTXO A na cadeia do Bitcoin, publica a declaração acima e depois inicia uma transação na cadeia CKB. Esta transação consome o contêiner UTXO que contém 100 tokens RGB, criando dois novos contêineres: um contendo 30 tokens (para Bob) e outro contendo 70 tokens (controlados por Alice). Durante esse 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 de DA (Disponibilidade de Dados), respectivamente, 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 apostas de ativos. Claro, a abordagem acima também sacrifica a privacidade. Isso envolve essencialmente um equilíbrio entre privacidade e usabilidade do produto. Se você prioriza a máxima segurança e privacidade, pode voltar para o modo RGB tradicional. Se você não se importa com esses compromissos, 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 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 consistindo em um grande número de nós através do protocolo de consenso é confiável e livre de erros. Se você não confiar na CKB, pode seguir o processo de comunicação interativa e verificação 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 aproveitar as características dos UTXOs nas referidas cadeias públicas e definir as condições de desbloqueio do contêiner de Células 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 talvez nem precisem publicar frequentemente Compromissos na cadeia do Bitcoin. Em vez disso, podem agregar e enviar um Compromisso para a cadeia do Bitcoin após várias transferências de RGB terem ocorrido. Isso é conhecido como o recurso de “dobramento de transação”, que pode reduzir os custos de transação.

É importante observar que os "contêineres" usados em ligações homomórficas precisam ser suportados por cadeias públicas que usam o modelo UTXO ou têm recursos semelhantes em sua infraestrutura de armazenamento de estado. As cadeias baseadas em EVM não são muito adequadas para esse propósito e podem encontrar muitos desafios. (Este tópico poderia ser abordado em um artigo separado, pois envolve muito conteúdo. Os leitores interessados podem consultar os artigos anteriores do Geek Web3 intitulados "RGB++ e Ligações Homomórficas: Como CKB, Cardano e Fuel Potencializam o Ecossistema Bitcoin.“)

Em resumo, 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 que os desenvolvedores escrevam scripts de desbloqueio.
3. Tenha um espaço de estado relacionado aos UTXOs que pode armazenar estados de ativos.
4. Tenha pontes ou nós leves relacionados ao Bitcoin disponíveis.

Aviso legal:

1. Este artigo foi reeditado 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 Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de Responsabilidade: As 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 da Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.