Qual é o real potencial do protocolo de emissão de ativos BTC RGB?

Autor**|**A Jian

Link original:

Este artigo tenta fornecer uma descrição sucinta do RGB, um protocolo de distribuição de ativos no BTC (que também pode ser entendido como um sistema de contrato inteligente off-chain), e aponta como ele difere de outros protocolos que visam alcançar a mesma funcionalidade ou similar, o que torna o protocolo RGB muito mais escalável do que eles são, e deixa mais espaço para programação. Além de apresentar os projetos já concluídos do RGB, também exploraremos essas possibilidades de programação.

O que é o protocolo RGB?

A ideia de emitir ativos em BTC já existe há muito tempo. No entanto, o protocolo BTC tem suas próprias características: seu estado é expresso por e apenas por UTXOs BTC (“saídas de transação não gastas”), um UTXO carrega apenas dois dados: sua própria denominação (valor BTC) e uma “chave pública de script” (também conhecida como “script de bloqueio”) que é usada para programar as condições sob as quais os fundos são gastos, como fornecer uma assinatura para uma chave pública, e opcodes que permitem que o script de bloqueio seja programado são fornecidos pelas regras de consenso do BTC, que não podem ser usadas para implementar regras de segurança arbitrárias. Como resultado, não é possível criar outros ativos dentro do UTXO - scripts BTC não podem programar verificações de segurança para esses ativos. Isso significa que toda a ideia de emitir ativos em BTC é essencialmente um uso criativo do espaço de bloco BTC. Isso significa que precisamos projetar um sistema de contrato inteligente off-chain e exigir que as informações sobre as etapas que mudam o estado do contrato - por exemplo, o contrato A altera parâmetros, B transfere uma certa quantidade de um ativo para C - sejam carregadas no blockchain, para que o estado mais recente do sistema de contrato inteligente possa ser obtido coletando essas informações.

Uma ideia de design bruto é carregar as informações das etapas que mudam o estado do contrato para o blockchain BTC intacto. Claro, isso pode funcionar, no entanto, enfrentará vários problemas: (1) devido ao upload de informações completas, pode consumir mais espaço de bloco, e quando os usuários precisam alterar o estado do contrato (como transferências), eles também precisarão pagar mais taxas on-chain. Em particular, quando queremos que esse sistema de contrato off-chain tenha melhor programabilidade do que o BTC, o aumento na programabilidade pode vir ao custo de consumir mais espaço de bloco: (2) a informação em quase qualquer lugar do bloco tem o potencial de alterar o contrato inteligente off-chain, então o usuário deve obter todos os dados do bloco BTC para obter o estado mais recente do sistema de contrato off-chain, ou seja, é mais caro verificar, (3) dependendo do design do sistema de contrato inteligente off-chain, ele só pode obter a mesma ou até pior privacidade que o BTC, e se puder fornecer mais privacidade, pode precisar consumir mais espaço de bloco。

No passado, um protocolo muito usado chamado “Omni” não carregava as informações completas das transações de contrato off-chain, apenas o hash da transação. Esta abordagem resolve o problema 1 acima, dissociando a complexidade das transações de contrato off-chain de seus custos econômicos, mas os usuários ainda precisam obter a quantidade total de dados de bloco BTC para obter o estado mais recente do protocolo Omni, e isso não melhora especificamente a privacidade.

O RGB, por outro lado, utiliza um novo paradigma chamado “selos de uso único”. A maneira como funciona é simples: o RGB exige que cada estado de cada contrato seja anexado a um UTXO BTC, e uma vez que esse estado deve ser alterado, o UTXO deve ser gasto para que a transação que o gastou seja confirmada pelo blockchain, e a transação BTC que o gasta também deve fornecer um hash da transição de estado para indicar o UTXO ao qual o estado alterado está anexado.

Aos olhos dos desenvolvedores RGB, esse design é semelhante aos selos de plástico numerados: é fácil saber se ele foi removido e, uma vez removido, não é mais utilizável. No entanto, a outra maneira de olhar é usar o UTXO possuído como um contêiner ou um cofrinho de cerâmica neste estado - para tirar o dinheiro do cofrinho, você tem que quebrar o cofrinho e colocar o dinheiro dentro em um novo.

Este design contrasta fortemente com protocolos anteriores que tratam todo o bloco como um grande letterboard: usar UTXO como um contêiner significa que as transações que não gastam este UTXO não podem ter qualquer efeito sobre o estado do contrato no contêiner, então para verificar um determinado estado de um contrato, não precisamos obter todos os dados do bloco, tudo o que precisamos é de uma série de transações BTC, prova de que essas transações BTC existem em um bloco, e esses compromissos RGB BTC da exchange Transições de estado (em pares com transações BTC relacionadas). Estes dados, que podem ser concatenados numa cadeia, devem permitir-nos remontar ao estado inicial do contrato, permitindo-nos identificar a essência desse estado.

Para os leitores que estão familiarizados com sistemas de contratos inteligentes on-chain (como o ETH Fang), uma das coisas que é difícil de entender sobre esse processo é que, se ele não depende do consenso do blockchain (o que significa que o estado inicial do contrato e cada mudança de estado serão verificados por cada nó), como garantir que a segurança desse sistema de contrato inteligente seja garantida, como garantir que os ativos que você recebe sejam do tipo que você deseja e como garantir que os ativos não sejam emitidos ilegalmente?

A resposta é simples, chama-se “validação do lado do cliente” – você mesmo verifica. No sistema de contrato on-chain, os nós verificam cada operação de transição de estado e rejeitam operações inválidas de acordo com as regras de transição de estado público, de modo a calcular o estado mais recente de acordo com o estado inicial. No entanto, desde que as regras de transição de estado e o estado inicial sejam conhecidos, a verificação por consenso on-chain não é a única maneira, e os usuários podem verificar se cada etapa da transição de estado segue as regras de transição de estado originalmente definidas com base nas informações fornecidas pelo pagador. Desta forma, a parte verificadora (presumivelmente o destinatário do ativo) também pode detetar transições ilegais de Estado e recusar-se a aceitá-las.

Finalmente, vamos usar um exemplo para ilustrar as características do protocolo RGB:

Agora, Alice é proprietária da UTXO A’, que detém o ativo Y de X unidades emitidas sob a licença RGB, e ela quer transferir unidades Z de Y para Bob. Foram necessários um total de 5 proprietários anteriores (incluindo o emissor) dos ativos para chegar a Alice. Portanto, Alice quer fornecer a Bob evidências dessas 4 transições de estado (as 3 primeiras foram fornecidas a Alice pelo proprietário anterior), incluindo o estado inicial do contrato e as regras de transição de estado, as transações BTC usadas para cada transferência, cada transação RGB comprometida BTC na bolsa e as evidências de que essas transações BTC foram confirmadas por um bloco, e enviá-las para Bob, que verificará essas 4 de acordo com as regras de transição de estado do contrato transferir sem quebrar as regras e, em seguida, decidir se aceita ou não. Quando Alice constrói uma transação RGB, uma vez que Z é menor que X, ela também organiza um UTXO para si mesma para receber o resto. Finalmente, Alice incorpora o hash da transação RGB na transação BTC que custa UTXO A’ para concluir o pagamento.

Eventualmente, graças ao uso de contêineres UTXO, o estado mais recente de um contrato RGB pode ser representado como um ponto em um gráfico acíclico direcionado que ainda não tem descendentes (cada ponto representa um estado armazenado dentro de um contêiner UTXO). E, para o proprietário P no diagrama abaixo, ele só saberá o processo desde o estado inicial G do contrato até ele, que é o processo circulado em vermelho, e não saberá nada sobre os pontos cinzas:

Vantagens do RGB

Status legal verificável

Como mencionado acima, o RGB reduz significativamente o custo de validação (um determinado estado de um contrato) em comparação com os protocolos de emissão de ativos (sistemas de contrato off-chain) que surgiram anteriormente no BTC. No momento da transação, o recetor não precisa mais iterar através de todos os blocos para coletar informações sobre a mudança no estado do contrato, mas só precisa obter uma série de transações BTC, bem como as transações RGB prometidas por essas exchanges, e o bloco contendo evidências dessas transações BTC (de acordo com a prova Merkle do cabeçalho do bloco), para ter certeza de que o pagador realmente possui uma certa quantidade de um determinado ativo.

Essa redução no custo de verificação também reduz consideravelmente a dependência (confiança) do usuário em relação a grandes provedores de infraestrutura. Nos protocolos anteriores, devido ao alto custo de verificação, era difícil para os usuários calcular o estado mais recente do contrato por si mesmos, então os usuários tinham que confiar em alguns fornecedores (como o provedor de estado do contrato usado por suas carteiras) e, ao mesmo tempo, porque havia menos fornecedores que podiam arcar com tais custos computacionais, o que também significava que o fornecedor estava centralizado. No entanto, em RGB, os usuários só precisam usar o cliente leve BTC para verificar a parte da transação com o BTC, e usar o protocolo RGB para verificar a parte da transação RGB, e eles podem pagar.

Em comparação com alguns sistemas de contrato on-chain, o RGB também é mais leve. Isso se reflete no fato de que o RGB pode verificar especificamente um determinado estado de um contrato, enquanto em sistemas que não são baseados em UTXOs, devido à falta de um mecanismo para controlar o acesso, como UTXOs, qualquer transação pode mudar qualquer estado, então é quase impossível verificar um determinado estado de forma direcionada, mas só pode determinar um determinado estado ao calcular todos os estados mais recentes - neste sentido, o recurso expresso como um “estado global” deve realmente ser chamado de " Estado uniforme", embora preveja o acesso cruzado entre contratos, também determina que será mais dispendioso verificar e mais difícil obter um acesso livre de confiança.

Uma otimização significativa nesses protocolos de contrato on-chain é a exigência de que os cabeçalhos de bloco se comprometam com o estado mais recente (“raiz do estado”), permitindo que clientes leves validem um determinado estado de um contrato a partir de nós completos em relação a esses compromissos. É uma forma de reutilizar cálculos que já aconteceram (cálculos que já foram executados por um nó completo), e também é muito eficiente, por isso pode ser considerado mais eficiente do que o RGB se a falta de confiança não for levada em conta. No entanto, isso significa que os nós leves dependem de nós completos para verificação da base de transação e cálculo do estado do contrato. Em uma carteira RGB que usa um cliente leve BTC, baseia-se na suposição de confiança de que a transação é relevante, a transação BTC é válida, e a parte relacionada ao estado do contrato é verificada pelo próprio cliente, então a falta de confiança é melhor. A desvantagem é que o atraso na verificação é maior e mais dados precisam ser mantidos.

Escalabilidade

A escalabilidade do RGB é dupla:

1. Apenas um hash está embutido na transação BTC, o que significa que não há limite para o tamanho da transação RGB (além das regras personalizadas pelo contrato) - mesmo que você divida um ativo RGB em 100 (a transação RGB em si será muito grande), há apenas um hash que precisa ser incorporado na transação BTC. Como observado na Nota 6, há duas maneiras de incorporar esse hash: usando a saída OP_RETURN, o que significa que ele consome um hash de espaço on-chain, ou ocultando-o na árvore de script prometida pela chave pública do script da saída Taproot - que não consome nenhum espaço on-chain. Isso também significa que os usuários não precisam sacrificar a economia pela programabilidade – apenas taxas on-chain.

2. O estado mais recente do contrato RGB é um ponto independente em um gráfico acíclico direcionado sem descendentes - isso significa que esses estados podem ser alterados independentemente sem afetar uns aos outros, ou seja, a simultaneidade é permitida. Este é realmente um recurso herdado do UTXO também. Isso também significa que alterações inválidas (transações inválidas) que ocorrem em uma agência não afetarão as outras filiais, muito menos causarão o congelamento de todo o contrato, portanto, também pode ser considerado um benefício de segurança.

O RGB tem sido criticado por sua escalabilidade: a cada transferência, o destinatário precisa verificar todas as transações envolvidas, desde o estado inicial até o estado pagador - à medida que o número de transferências de ativos aumenta, a carga de verificação sobre os destinatários subsequentes aumenta. Esta crítica é verdadeira. Otimizá-lo significa encontrar uma maneira de reutilizar cálculos que já ocorreram. Espera-se que tecnologias de sistemas de prova, como SNARKs, forneçam essa solução.

Diferenciação da definição de ativos e do mecanismo de declaração aduaneira

O último benefício ainda está relacionado às UTXOs, dependendo de como entendemos o mecanismo de script de bloqueio da UTXO.

Um script de bloqueio pode ser usado para programar as condições sob as quais um fundo será desbloqueado, para que possa implementar regras de custódia. Por exemplo, se um script de bloqueio contiver apenas uma chave pública, isso significa que apenas o proprietário da chave privada correspondente pode controlá-la. No entanto, tais regras de custódia também são a base para a programação do protocolo contratual BTC. Por exemplo, um UTXO que usa um script de bloqueio de 2 de 2 assinaturas múltiplas pode ser um canal relâmpago e, durante a operação do canal, duas partes podem pagar uma à outra quase um número infinito de vezes sem qualquer alteração na forma on-chain dos fundos. Em outras palavras, neste ponto, o script de bloqueio de 2 de 2 assinaturas múltiplas constitui um mecanismo de transferência de valor que permite que ambas as partes transfiram valor sem alterar a forma dos fundos on-chain.

Tal mecanismo pode ser usado para o valor do BTC transportado pelo UTXO e, naturalmente, para os ativos RGB que ele carrega. Podemos emitir um ativo RGB e anexá-lo a uma UTXO multi-assinatura 2-of-2, usando o mecanismo do canal lightning para pagar uns aos outros um número ilimitado de vezes. Da mesma forma, os ativos RGB também podem ser usados em outros contratos baseados em script BTC.

Aqui, os scripts da UTXO e os protocolos RGB formam uma diferenciação funcional: o primeiro se concentra na implementação das regras de custódia e transferência de valor, enquanto o segundo se concentra na definição de ativos. Assim, a custódia de ativos e a definição de ativos podem ser separadas. Esta é uma melhoria de segurança importante, e que as pessoas estão procurando em alguns outros sistemas de contrato on-chain.

RGB foi projetado

Os recursos acima são verdadeiros para praticamente todos os protocolos baseados em UTXO one-time sealing e verificação do lado do cliente. Mas, além disso, o protocolo RGB foi ainda mais projetado.

No desenvolvimento atual do protocolo RGB, os desenvolvedores estão particularmente preocupados com a privacidade do protocolo, então o RGB fortalece a privacidade de duas maneiras:

• UTXOs cegas. Em uma transação RGB, o recetor só precisa usar o identificador UTXO ofuscado para receber o ativo, sem expor as características do UTXO que realmente recebe o ativo. Isto não compromete de forma alguma a capacidade do destinatário de fornecer provas ao proprietário seguinte, ao mesmo tempo que permite que os destinatários subsequentes do ativo se defendam contra os olhares curiosos do anterior proprietário do ativo.
• À prova de balas。 Ele pode ser usado para ocultar o valor exato em cada transação. No entanto, os proprietários de ativos subsequentes ainda podem verificar se não houve emissão adicional antes.

Espaço explorável

Nesta parte, vou falar sobre as áreas onde o protocolo RGB pode continuar a explorar, principalmente relacionadas com a programação.

Atualmente, os modelos de contrato RGB propostos (esquemas) estão focados na emissão de ativos. No entanto, como o RGB usa o paradigma de “validação do lado do cliente”, na verdade, podemos adicionar qualquer coisa a ele que possa ser assegurada pela verificação do lado do cliente - limitada apenas pela estrutura UTXO.

Restrições

Além das UTXOs, um conceito que amplia a programabilidade é chamado de “covenants”. A intenção inicial da cláusula de restrição é limitar o destino para o qual uma quantia em dinheiro pode ser transferida. Com esta capacidade, podemos programar muitas aplicações interessantes, tais como:

• Pools de fundos para retiradas não interativas. Podemos reunir os fundos de muitas pessoas na mesma UTXO e usar restrições para garantir que nenhuma delas possa retirar seus próprios fundos sem a ajuda de outros. Isso pode servir para ajudar as pessoas a sair de lugares de alto risco a um baixo custo quando a demanda por espaço de bloco é alta.
• Contrato Vault. Faça com que um fundo tenha que ir a algum lugar, passar por um timelock antes de poder gastá-lo livremente e, durante o timelock, o proprietário do cofre pode interromper o processo com uma chave de emergência e mover imediatamente os fundos para outro lugar. Esse dispositivo pode ser de grande ajuda para o self-storage.

Os scripts BTC atuais não têm essa capacidade, portanto, habilitar restrições em scripts BTC requer um soft fork.

No entanto, desde que estejamos dispostos a sacrificar alguns dos benefícios da “definição de ativos e diferenciação de custódia”, podemos experimentar tal recurso em ativos RGB, e podemos implementar essa funcionalidade ao nível de contratos RGB - embora só possa funcionar para os ativos RGB que a usam (e não BTC), mas sem dúvida abrirá um espaço interessante.

Estudos de restrições existentes mostraram que ele amplia o espaço de programação para transações baseadas em UTXO, oferecendo uma série de recursos. Mas esses estudos são basicamente baseados no BTC, e seríamos um pouco mais conservadores em protocolos BTC como este. No RGB, podemos generalizar corajosamente a capacidade central da cláusula de restrição – a capacidade de ler transações que custam a si mesmas no nível do script – para fornecer uma programação mais flexível: a capacidade de contratos de acesso cruzado.

Acesso cruzado

A cláusula de restrição mínima significa que, quando um UTXO é gasto, seu script pode ler a saída da transação de gastos. Mas uma restrição totalmente generalizada significa que ele pode ler todas as partes da transação que lhe custaram. Isso significa que ele também pode ler os outros insumos da transação, e se não limitarmos os outros insumos ao mesmo contrato, significa que ele pode ler o estado dos outros contratos.

Em RGB, cada contrato é um universo independente com seu próprio gráfico acíclico direcionado. No entanto, ainda é possível que um usuário tenha dois contratos diferentes ao mesmo tempo. Se as transações RGB permitirem que ativos de ambos os contratos sejam gastos ao mesmo tempo, esses recursos de acesso cruzado podem ter um caso de uso (embora seja concebível que isso complique a verificação das transações).

De fato, já existem sistemas de contratos on-chain baseados em estruturas semelhantes a UTXO (por exemplo, Rede Nervos) que usam isso para alcançar recursos de acesso cruzado para contratos11. Este é um campo muito novo, abrindo-se para áreas que raramente foram tocadas por estudos anteriores do BTC, e pode haver algumas surpresas enterradas nele.

Conclusão

Neste artigo, o leitor notará que há um conceito que é frequentemente mencionado ao longo do processo de raciocínio e fantasia: “UTXO”. Era exatamente isso que eu pretendia. Se você não entende UTXO, você não pode entender o ponto de partida do design de um protocolo como RGB, as vantagens do design de protocolo RGB e a maneira como as pessoas podem usá-lo. A natureza do protocolo RGB é em grande parte moldada pelo seu UTXO, uma forma de selo único. Correspondentemente, a pesquisa sobre UTXOs acumulada no campo de pesquisa BTC também pode ser aplicada à pesquisa de RGB.

Isso também explica por que as pessoas que não entendem BTC, terão dificuldade em entender RGB. E aqueles que gostam de BTC reconhecerão os designs que a RGB já fez.