Autor: Faust, geek web3 e BTCEden.org Lianchuang

Com a popularidade da emissão de RGB++ e ativos relacionados, a discussão sobre os princípios dos protocolos RGB e RGB++ tornou-se gradualmente um tema de preocupação para mais pessoas. Mas todos percebem que para entender o RGB++, você deve primeiro entender o protocolo RGB.

O protocolo RGB original é um pouco obscuro em termos de estrutura técnica e os materiais de referência estão dispersos. Não existem muitos materiais de referência sistemáticos e fáceis de entender até o momento. Embora o geek web3 tenha publicado anteriormente dois artigos de interpretação sistemática sobre RGB e RGB++ (Você pode ver o histórico de nossa conta oficial), mas de acordo com o feedback dos membros da comunidade, o artigo mencionado é muito longo e cansativo.

Para permitir que mais pessoas entendam os protocolos RGB e RGB++ com mais rapidez, o autor deste artigo se apressou em completar uma breve interpretação vernácula de RGB e RGB++ durante o evento em Hong Kong. Ela pode ser lida em poucos minutos e espera ajudar. mais interesses da comunidade. Os leitores podem entender RGB e RGB++ melhor e mais intuitivamente.

Protocolo RGB: os próprios usuários devem fazer a verificação dos dados

O protocolo RGB é um protocolo especial de ativos P2P e um sistema de computação fora da cadeia Bitcoin. É semelhante a um canal de pagamento em alguns aspectos: os próprios usuários devem executar o cliente e verificar seu próprio comportamento de transferência (verifique você mesmo). Mesmo se você for apenas um destinatário de ativos, primeiro certifique-se de que não haja erros no extrato de transferência do remetente do ativo antes que o extrato de transferência entre em vigor. Obviamente, isso é completamente diferente da forma tradicional de envio e recebimento de ativos que chamamos de “transferência interativa”.

Porque isto é assim? A razão é que para garantir a privacidade, o protocolo RGB não adota o “protocolo de consenso” em blockchains tradicionais como Bitcoin e Ethereum (uma vez que os dados passem pelo protocolo de consenso, serão observados por quase todos os nós da 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" (Verifique você mesmo) é usada aqui. Você mesmo deve executar o cliente e verificar pessoalmente as alterações dos ativos relacionados a você.

Suponha que haja um usuário RGB chamado Bob que conheça Alice e que Alice queira 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 dos ativos envolvidos para Bob, e deixá-lo verificar pessoalmente para ter certeza de que estão corretos antes de entrar no processo subsequente e, finalmente, torna-se uma transferência RGB válida. Portanto, o protocolo RGB permite aos usuários verificar pessoalmente a validade dos dados, substituindo o algoritmo de consenso tradicional.

Mas não há consenso, e os dados recebidos e armazenados por diferentes clientes RGB são inconsistentes. Todos armazenam apenas seus próprios dados de ativos localmente e não conhecem o status dos ativos de outros. Se alguém afirma ter 1 milhão de tokens TEST e deseja transferir 100.000 para você, como você pode acreditar nele?

Na rede RGB, se alguém quiser transferir dinheiro para você, ele deve primeiro mostrar prova de ativos, rastrear a origem histórica dos ativos desde a emissão inicial até múltiplas mudanças de mãos e certificar-se de que o Token a ser transferido para você está OK. É como quando você recebe Ao receber notas não identificadas, você pede à outra parte que explique a origem histórica dessas notas e se elas foram feitas pelo emissor designado, para evitar moeda falsificada.

Os processos acima ocorrem fora da cadeia Bitcoin, e esses processos por si só não permitem que o RGB esteja diretamente relacionado à rede Bitcoin. A este respeito, o protocolo RGB adota uma ideia chamada "selo de uso único" para vincular os ativos RGB ao UTXO na cadeia Bitcoin, desde que o Bitcoin UTXO não seja consumido duas vezes, os ativos RGB vinculados não serão duplicados. que a rede Bitcoin pode ser usada para evitar a “reorganização” dos ativos RGB. Claro, isso requer a emissão de um compromisso na cadeia Bitcoin e o uso do opcode OP_Return.

Vamos resolver o fluxo de trabalho do protocolo RGB:

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

  1. Alice constrói dados de transferência de ativos RGB "Alice para Bob", juntamente com as fontes históricas desses ativos, e os entrega a Bob para verificação.

  2. Depois que Bob confirma localmente que os dados estão corretos, ele envia um recibo para Alice, informando que a transação pode ser realizada.

  3. Alice constrói os dados de transferência RGB de "Alice para Bob" em uma árvore Merkle e publica a raiz Merkle na cadeia 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 de "Alice para Bob" mencionada acima realmente aconteceu, ele precisa fazer duas coisas: obter as informações completas de transferência de "Alice para Bob" na cadeia Bitcoin e, em seguida, verificar se existe uma transação correspondente no Compromisso da cadeia Bitcoin (hash de dados de transferência), é isso.

O Bitcoin aqui atua como o registro histórico da rede RGB, mas apenas a raiz hash/Merkle dos dados da transação é registrada no log, e não os dados da transação em si. Devido ao uso de verificação de cliente e selagem única, o protocolo RGB possui segurança extremamente alta, pois a rede RGB é composta por clientes usuários dinâmicos na forma de P2P e sem consenso, você pode alterar a contraparte a qualquer momento sem transação; as solicitações são enviadas para um número limitado de nós, portanto a rede RGB é extremamente resistente à censura. Essa forma organizacional é mais resistente à censura do que grandes cadeias públicas como a Ethereum.

É claro que o custo da segurança extremamente alta, da resistência à censura e da proteção da privacidade também é óbvio: os próprios usuários terão que executar o cliente para verificar os dados se a outra parte enviar alguns ativos que mudaram de mãos dezenas de milhares de vezes. uma longa história, você também tem que verificar tudo sob pressão;

Além disso, cada transacção requer múltiplas comunicações entre as duas partes. A parte receptora deve primeiro verificar a origem dos activos 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 passadas entre as duas partes. Esse tipo de “transferência interativa” é seriamente inconsistente com a “transferência não interativa” a que a maioria das pessoas está acostumada. Você pode imaginar que se alguém quiser transferir dinheiro para você, terá que enviar os dados da transação para verificar e receber. seu recibo? O processo de transferência só pode ser concluído após o recebimento da mensagem?

Além disso, mencionamos que a rede RGB não tem consenso e cada cliente é uma ilha, o que não conduz à migração de cenários complexos de contratos inteligentes em cadeias públicas tradicionais para a rede RGB porque todos os protocolos Defi em Ethereum ou Solana dependem de A livro razão globalmente visível e com dados transparentes. Como otimizar o protocolo RGB, melhorar a experiência do usuário e resolver os problemas acima? Isso se tornou um problema inevitável para o protocolo RGB.

RGB++: validação do cliente torna-se hospedagem otimista

O protocolo chamado RGB++ apresenta uma nova ideia. Ele combina o protocolo RGB com cadeias públicas que suportam UTXO, como CKB, Cardano e Fuel. Este último serve como camada de verificação e camada de armazenamento de dados para ativos RGB e converte dados originalmente executados. pelos usuários O trabalho de verificação é entregue a plataformas/cadeias públicas de terceiros, como CKB. Isso equivale a substituir a verificação do cliente por "plataforma descentralizada de terceiros para verificação". , Combustível, etc., se você não confia neles, também pode voltar ao modo RGB tradicional.

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

Para obter os efeitos mencionados acima, você precisa 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. "Ligação isomórfica" consiste em usar o UTXO estendido nas cadeias CKB, Cardano e Fuel como "contêineres" para dados de ativos RGB, escrever os parâmetros dos ativos RGB nesses contêineres e exibi-los diretamente no blockchain. Sempre que ocorre uma transação de ativos RGB, o contêiner de ativos correspondente também pode apresentar características semelhantes, assim como o relacionamento entre entidades e sombras. Esta é a essência da "ligação isomórfica".

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

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

Posteriormente, Alice gasta UTXO A na cadeia Bitcoin, publica a declaração acima e, em seguida, inicia uma transação na cadeia CKB para consumir o contêiner UTXO contendo 100 tokens RGB e gerar dois novos contêineres, um contendo 30 tokens (para Bob), um detém 70 tokens (controlados por Alice). Neste processo, a tarefa de verificar a validade dos ativos de Alice e a validade do extrato da transação é concluída por nós de rede como CKB ou Cardano por meio de consenso, sem a intervenção de Bob. Neste momento, CKB e Cardano servem como camada de verificação e camada DA sob a cadeia Bitcoin.

Os dados de ativos RGB de todos são armazenados na cadeia CKB ou Cardano, que possui características verificáveis ​​globalmente e conduz à implementação de cenários Defi, como pools de liquidez e protocolos de penhor de ativos. É claro que a abordagem acima também sacrifica a privacidade. A essência é fazer uma troca entre privacidade e facilidade de uso do produto. Se você não o fizer, poderá voltar ao modo RGB tradicional. se preocupe com isso, você pode usar RGB++ com segurança. O modo depende inteiramente de suas necessidades pessoais. (Na verdade, com a poderosa completude funcional de cadeias públicas como CKB e Cardano, ZK pode ser usado para implementar transações privadas)

Deve-se enfatizar aqui que o RGB++ introduz uma importante suposição de confiança: os usuários devem estar 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 livre de erros. Se você não confia no CKB, também pode seguir o processo interativo de comunicação e verificação no protocolo RGB original e executar o cliente você mesmo.

Sob o protocolo RGB++, os usuários podem usar contas Bitcoin diretamente para operar seus próprios contêineres de ativos RGB em cadeias UTXO como CKB/Cardano sem cross-chain. Eles só precisam usar as características do UTXO nas cadeias públicas acima para definir as condições de desbloqueio. do contêiner Cell. Basta configurá-lo para ser associado a um determinado endereço Bitcoin/Bitcoin UTXO. Se ambas as partes na transação de ativos RGB confiarem na segurança do CKB, elas nem precisarão publicar Compromissos com frequência na cadeia Bitcoin. Depois que muitas transferências RGB forem concluídas, elas poderão enviar um Compromisso para a cadeia Bitcoin. dobramento de transação". ”A função pode reduzir os custos de uso.

No entanto, deve-se notar que o "contêiner" usado na ligação isomórfica precisa de uma cadeia pública que suporte o modelo UTXO, ou de uma infraestrutura com características semelhantes no armazenamento de estado. A cadeia EVM não é adequada e encontrará muitas armadilhas. (Este tópico pode ser escrito separadamente e envolve muito conteúdo. Os leitores interessados ​​​​podem consultar o artigo anterior do Geek web3 "RGB++ e ligação isomórfica: como CKB, Cardano e combustível capacitam o ecossistema Bitcoin";

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

  1. Use o modelo UTXO ou esquema de armazenamento de estado semelhante;

  2. Possui programabilidade UTXO considerável, permitindo aos desenvolvedores escrever scripts de desbloqueio;

  3. Existe um espaço de estados relacionado ao UTXO que pode armazenar o status dos ativos;

  4. Existem pontes ou nós leves relacionados ao Bitcoin;