Protocolo RGB++ e o futuro do Bitcoin: Insights da Cipher do Bitcoin Singapura 2024

Em 9 de março, durante a conferência Bitcoin Singapore 2024, coorganizada pela Nervos Foundation e ABCDE, Cipher, fundador do CELL Studio e autor do protocolo RGB++, apresentou um discurso intitulado 'Visão geral e perspectivas do protocolo RGB++'.

Aqui está um resumo dos principais pontos da apresentação da Cipher:

Desafios enfrentados pelo protocolo RGB

O protocolo RGB existe há muitos anos, mas ainda não foi amplamente adotado devido a vários fatores:

Desafios com operações interativas

Nas transações envolvendo BTC , ETH , etc., o destinatário só precisa fornecer um endereço, e o remetente pode transferir fundos hoje ou amanhã, o que é muito conveniente. Em contraste, cada transação RGB exige que o destinatário primeiro emita uma fatura. Em seguida, o remetente deve construir uma transação RGB e gerar um comprovante do histórico do ativo para enviar ao destinatário. Ao receber esse comprovante, o destinatário deverá realizar a validação do lado do cliente (CSV). Após a validação bem-sucedida, eles devem armazenar esta prova para transações futuras.

Portanto, as transações RGB não dependem apenas de ambas as partes estarem online, mas também de ambas as partes armazenarem dados históricos relevantes. Isto representa um obstáculo significativo para produtos orientados para o consumidor.

Problemas de disponibilidade de dados (DA)

Nas transações RGB é imprescindível anexar a comprovação histórica do ativo. Se esta prova for perdida, será tão crítico quanto perder uma chave privada. A questão de quem ajudará os usuários a salvar seus ativos é um problema de disponibilidade de dados. No protocolo RGB original, que visa preservar a privacidade, ninguém mais armazena ativos para os usuários, o que significa que os usuários devem assumir a responsabilidade pelo armazenamento de seus próprios dados.

Mesmo com o armazenamento de dados adequado, considere um cenário em que Alice deseja transferir ativos RGB para Bob. Como ela lhe envia a prova histórica desses bens? Usando e-mail ou Whatsapp? Claramente, a transmissão através de qualquer canal centralizado é inadequada, necessitando do uso de um canal P2P especializado. No entanto, os canais P2P levantam questões de confidencialidade: porque é que alguém ajudaria na transmissão destes dados sensíveis? Isto leva a uma série de questões complexas.

Problemas de interoperabilidade

Os dados históricos de comprovação dos ativos RGB são retidos pelos próprios usuários e repassados ao destinatário durante as transações, mas não são disponibilizados publicamente. Isso resulta na dispersão dos dados por cada indivíduo na rede. Para alguém que constrói uma plataforma de negociação, seja centralizada ou descentralizada, são necessários dados de múltiplas fontes para manter o estado global do RGB. Existem alguns provedores de serviços RGB que centralizam e armazenam esses dados para desenvolvedores de aplicativos, mas essa abordagem diminui a privacidade do RGB. Apesar desta solução, permanecem desafios, como facilitar a transferência de dados entre vários prestadores de serviços que detêm dados RGB de diferentes utilizadores.

Problemas com ambiente de execução de script/contrato inteligente

Existem desafios significativos associados ao contrato inteligente ou aos ambientes de execução de scripts em RGB. Utiliza uma Máquina Virtual (VM) chamada AluVM, mas as especificidades de sua linguagem de programação ainda não foram finalizadas. Além disso, ferramentas críticas de desenvolvimento, como compiladores e depuradores, não estão totalmente desenvolvidas. Também carece de apoio a estados partilhados e contratos descentralizados (sem proprietário). Atualmente, é evidente que o AluVM ainda está em seus estágios iniciais.

Conseqüentemente, o RGB é confrontado com vários problemas complexos, cada um exigindo tempo e esforço consideráveis. Estes desafios contribuem significativamente para os atrasos na implementação efectiva da RGB.

Uma visão geral do protocolo RGB++

As transações RGB estão intrinsecamente ligadas às transações Bitcoin através de um processo de mapeamento. Além disso, as transações RGB exigem uma infraestrutura fora da cadeia, abrangendo disponibilidade de dados (DA), validação do lado do cliente, rede P2P, máquinas virtuais, estados compartilhados e contratos descentralizados. Ao considerar tal infraestrutura, o blockchain vem naturalmente à mente, dadas as suas capacidades em gestão de dados, validação, integração de máquinas virtuais, redes P2P, incentivos e contratos inteligentes. O conceito do protocolo RGB++ é baseado nesta intuição fundamental, propondo o uso do blockchain CKB baseado no modelo UTXO e Turing-completo como um substituto para a infraestrutura fora da cadeia exigida pelo RGB.

RGB++ introduz um conceito chamado tecnologia de ligação isomórfica . Cada transação Bitcoin inclui uma saída. No caso de uma transação RGB, é necessária a inclusão de um segmento OP_RETURN na saída do Bitcoin. Este segmento contém dados hash específicos, denominados compromisso. Se este compromisso coincidir com o hash de uma transação em outro blockchain público, e se as entradas e saídas de ambas as transações forem isomórficas - o que significa que correspondem em estrutura - e assumindo que o UTXO (Unspent Transaction Output) deste blockchain alternativo possua computação Turing-completa e capacidades de armazenamento de estado, então a transação na blockchain Bitcoin torna-se totalmente integrada ou vinculada à transação nesta outra blockchain. O blockchain CKB (Common Knowledge Base) satisfaz esses pré-requisitos. Conseqüentemente, conduzir uma transação no Bitcoin equivale efetivamente a realizar uma transação correspondente na cadeia CKB. Qualquer mudança no estado da transação Bitcoin reflete uma mudança no estado da transação na cadeia CKB, aderindo às restrições contratuais presentes no CKB. Isso encapsula a essência da tecnologia de ligação isomórfica. No entanto, este conceito abrange numerosos aspectos técnicos intrincados, incluindo a manutenção da consistência transacional e a prevenção de gastos duplos, que não são aprofundados neste momento.

A tecnologia de ligação isomórfica permite o aprimoramento das capacidades de estado do Bitcoin. Por exemplo, vamos considerar o btc_utxo#1 ilustrado no diagrama a seguir. Este Bitcoin UTXO (Unspent Transaction Output) normalmente exibe apenas dois estados: um script de bloqueio e um valor, este último representando o saldo. No entanto, na célula azul correspondente na blockchain CKB (Common Knowledge Base), conforme mostrado no diagrama, as capacidades são mais amplas. Ao contrário da funcionalidade limitada do Bitcoin UTXO para apenas mostrar o equilíbrio, esta célula isomórfica na cadeia CKB pode armazenar não apenas dados de saldo, mas também vários outros tipos de dados.

Além do componente de dados, o Cell possui um script de tipo. Este script tem um propósito específico: define as condições sob as quais os ativos são recebidos e impõe restrições aos tipos de ativos.

Além disso, a célula contém um script de bloqueio, que neste caso está explicitamente vinculado a btc_utxo#1. Esta ligação implica que a célula na blockchain CKB pode ser gasta apenas se e quando btc_utxo#1 for gasto.

Na plataforma CKB, implementamos um nó leve Bitcoin. Assim que uma transação Bitcoin é iniciada, ela é capturada por um mecanismo de retransmissão, que então transfere essa transação como forma de prova para o blockchain CKB. Este processo envolve verificar a presença da transação no nó leve do Bitcoin e garantir que o compromisso seja isomórfico com a transação.

Através desta abordagem, ampliamos significativamente as funcionalidades do Bitcoin. Ele abre caminho para a emissão de uma ampla gama de ativos diretamente no Bitcoin e facilita a expansão de contratos completos de Turing.

A vantagem dessa abordagem é que introduzimos com sucesso o script Turing-completo no domínio Bitcoin, mantendo um status de segurança quase idêntico ao da Camada 1 (L1) do Bitcoin. Isso ocorre porque todos os registros históricos, transações e compromissos estão vinculados através da cadeia UTXO no Bitcoin L1.

A compensação, no entanto, é uma ligeira diminuição na privacidade. No caso do RGB, os dados são dispersos entre usuários individuais, dificultando o acesso de terceiros aos dados RGB de qualquer usuário específico. Com RGB++, todos os dados fora da cadeia são publicados na blockchain CKB, que mantém esses estados, levando a uma redução na privacidade. No entanto, o pior cenário é apenas uma redução do nível de privacidade encontrado nas transações Bitcoin; não expõe endereços IP ou informações de identidade pessoal.

Na verdade, poderíamos implementar uma camada de privacidade aprimorada no CKB. Há quatro anos, colaboramos com a comunidade Grin para escrever um artigo discutindo o uso da tecnologia Mimblewimble no CKB para criar esta camada de privacidade aprimorada. No futuro, poderemos integrar esta camada no RGB++, permitindo não apenas a ocultação dos valores das transações, mas também cortando os links no histórico de transações. A privacidade resultante seria mais forte que a do RGB.

Em resumo, concretizamos a visão do RGB de uma forma mais simples e expandimos ainda mais as suas capacidades.

Desbloqueando o potencial dos ativos Bitcoin L1

Aqui está uma introdução simplificada ao conceito de salto.

A tecnologia de ligação homomórfica , que pode ser aplicada ao Bitcoin , é igualmente aplicável a Litecoin, Liquid e outras cadeias baseadas em UTXO. Conforme mencionado anteriormente, tanto nos sistemas RGB quanto RGB++, o beneficiário é um Bitcoin UTXO, dotado de autoridade exclusiva para gastar. Quando crio uma transação RGB++ em Bitcoin, tenho a opção de designar o beneficiário não como Bitcoin UTXO, mas como Litecoin UTXO. Consequentemente, este ativo ‘salta’ para Litecoin, uma vez que o seu gasto subsequente requer o desbloqueio por um Litecoin UTXO. Da mesma forma, esse ativo pode saltar para o Liquid ou até mesmo voltar para o Bitcoin.

Claro, há um caso especial a considerar. Quando um ativo salta para o blockchain CKB, sua camada de interpretação de dados, camada de contrato e propriedade estão todas no CKB. Isso significa que ele não depende mais de nenhuma outra cadeia e pode se envolver diretamente em transações e interagir com contratos inteligentes no CKB. Isso pode ser descrito como um salto para L2. No L2, os usuários podem realizar milhares ou até dezenas de milhares de transações até que alguém decida transferir o ativo de volta para o Bitcoin. Isso é o que chamamos de dobramento de transações. Quer seja RGB ou RGB++, as transações ocorrem na blockchain Bitcoin, onde as taxas de mineração são caras. No entanto, uma vez que um ativo salta para o CKB e passa por uma transação dobrada, as taxas tornam-se significativamente mais baixas e ele pode facilmente retornar ao blockchain do Bitcoin a qualquer momento. Todo esse processo não depende de pontes com múltiplas assinaturas ou da confiança em qualquer indivíduo; o único requisito é aguardar mais algumas confirmações de bloqueio. Saltar do blockchain Bitcoin para o blockchain CKB requer a espera de 6 confirmações de bloco Bitcoin. Para voltar do blockchain CKB para o Bitcoin, são necessárias 24 confirmações de bloco CKB, para evitar reversões de bloco/r.

É por isso que dizemos que introduzimos um novo paradigma. Claro, esta não é uma invenção nossa, mas sim uma ideia que existia nos primeiros materiais do RGB, onde os ativos RGB podiam saltar entre diferentes cadeias UTXO. Depois de combinar a completude de Turing com o salto para CKB, descobrimos que as aplicações potenciais são extensas e muito diferentes da narrativa tradicional das pontes de múltiplas assinaturas da Ethereum.

Perspectivas futuras

A seguir, vamos discutir a escalabilidade. A taxa de transação do Bitcoin é de aproximadamente 7 transações por segundo (TPS), enquanto o CKB atinge o pico em torno de 200 TPS. Se você levar em consideração os custos de execução de contrato e validação de script, o TPS poderá ser reduzido para cerca de 50, o que é menos de uma expansão dez vezes maior em comparação ao Bitcoin. Isso não é suficiente, então quais são as opções para aumentar a escala? Vemos duas direções principais:

• Canais estaduais : os canais estaduais representam uma solução de escalonamento definitiva, oferecendo um limite máximo de desempenho muito alto. O desafio, contudo, reside na complexidade da implementação de contratos multilaterais, tornando os canais estatais mais adequados para transações de pagamento e interações entre indivíduos e servidores. Jan deverá liderar a equipe no avanço da pesquisa nos canais estaduais.

  
  

• AppChain Stack : Construindo uma solução de Camada 2 (L2) baseada no modelo UTXO, o AppChain L2 garantirá sua ancoragem no CKB, alinhando-se isomorficamente a ele. Esta abordagem nos permite desenvolver estratégias de escala inovadoras dentro deste novo paradigma. Este também é um foco importante do CELL Studio no próximo ano.

  
  

Por último, gostaria de descrever a missão e o roteiro do RGB++. RGB++ tem como objetivo desenvolver módulos de protocolo básicos para facilitar o uso e a integração por desenvolvedores e usuários terceirizados. O roteiro do protocolo RGB++ é o seguinte, e o protocolo já está ativo na rede principal Bitoin e o RGB ++ SDK foi lançado em 3 de abril.

Por Cipher, fundador do CELL Studio e autor do protocolo RGB++.