Este artigo tenta fornecer uma descrição concisa do RGB, um protocolo de emissão de ativos em Bitcoin (também pode ser entendido como um sistema de contrato inteligente off-chain), e aponta que é muito diferente de outros projetos que visam para alcançar protocolos funcionais iguais ou semelhantes, essas diferenças tornam o protocolo RGB muito mais escalável do que eles e deixam um espaço de programação mais amplo. Além de apresentar os designs concluídos do RGB, também exploraremos essas possibilidades de programação.
O que é o protocolo RGB?
A ideia de emitir ativos em Bitcoin já existe há muito tempo. Mas o protocolo Bitcoin tem suas próprias características: seu estado é expresso apenas por Bitcoin UTXO ("saída de transação não gasta"); um UTXO carrega apenas dois dados: sua própria denominação (valor Bitcoin) e uma "chave pública de script" (também conhecido como "script de bloqueio"), utilizado para programar as condições de gasto deste fundo, por exemplo: fornecer a assinatura de uma determinada chave pública; permitir que o opcode utilizado para programar o script de bloqueio seja determinado pelas regras de consenso do Bitcoin, desde que não possam ser usado para implementar regras de segurança arbitrárias. Portanto, é impossível criar outros ativos dentro do UTXO – o script Bitcoin não pode programar verificações de segurança para esses ativos. Isso significa que todas as ideias para emissão de ativos no Bitcoin são essencialmente usos criativos do espaço de bloco do Bitcoin. Isso significa que precisamos projetar um sistema de contrato inteligente fora da cadeia e exigir as etapas para alterar o estado do contrato - por exemplo, o contrato A altera os parâmetros e B transfere uma certa quantidade de um determinado ativo para C —— As informações são carregadas no blockchain, para que o status mais recente do sistema de contrato inteligente possa ser obtido através da coleta dessas informações.
Uma ideia aproximada de design é carregar intactas as informações das etapas que alteram o estado do contrato para o blockchain do Bitcoin. Isso certamente funciona, mas enfrenta vários problemas:
(1) Como as informações completas são carregadas, elas podem consumir mais espaço de bloco. Quando os usuários precisarem alterar o status do contrato (como uma transferência), eles também precisarão pagar mais taxas de manuseio na cadeia. Em particular, quando esperamos que tal sistema de contrato fora da cadeia tenha melhor programabilidade do que o Bitcoin, o aumento na programabilidade pode ocorrer à custa do consumo de mais espaço em bloco;
(2) Quase todas as informações do bloco podem alterar o contrato inteligente fora da cadeia, portanto, os usuários devem obter todos os dados do bloco Bitcoin para obter o status mais recente do sistema de contrato fora da cadeia, ou seja, é mais caro verificar;
(3) Dependendo do design do sistema de contrato inteligente fora da cadeia, você só poderá obter privacidade comparável à do Bitcoin, ou ainda pior; e se puder fornecer mais privacidade, poderá precisar consumir mais área. bloquear espaço.
No passado, um protocolo amplamente utilizado chamado “Omni” não carregava informações completas sobre transações contratuais fora da cadeia, mas apenas o valor de hash da transação. Esta abordagem resolve os problemas acima e dissocia a complexidade das transações contratuais fora da cadeia de seus custos econômicos; no entanto, os usuários ainda precisam obter a quantidade total de dados do bloco Bitcoin para obter o status mais recente do protocolo Omni; além disso, não não Projetado especificamente para aumentar a privacidade.
RGB usa um novo paradigma chamado “selos descartáveis”. Seu uso é muito simples: RGB exige que cada estado de cada contrato esteja anexado a um determinado Bitcoin UTXO; e uma vez que você queira mudar este estado, você deve gastar este UTXO e deixar que a transação que o gasta receba a Confirmação no blockchain; além disso, a transação Bitcoin que o gasta também deve fornecer um hash do conteúdo da transição de estado para indicar o UTXO anexado ao estado alterado.
Para os desenvolvedores RGB, o design é semelhante a um selo plástico numerado: é fácil saber se foi removido e, uma vez removido, não pode ser reutilizado. No entanto, outra perspectiva é considerar o UTXO possuído como o recipiente ou cofrinho de cerâmica neste estado - se você quiser retirar o dinheiro do cofrinho, você deve quebrá-lo. Em seguida, coloque o dinheiro dentro no novo frasco.
Este design contrasta fortemente com os protocolos anteriores que tratavam o bloco inteiro como uma grande placa de escrita: usar UTXO como contêiner significa que as transações que não gastam esse UTXO não podem ter qualquer impacto no estado do contrato no contêiner. um determinado estado de um determinado contrato, não precisamos obter os dados de todos os blocos. Tudo o que precisamos é de uma série de transações Bitcoin, evidências de que essas transações Bitcoin existem em um determinado bloco e esses bits A conversão de estado RGB prometida por a troca de moeda (par um para um com a transação Bitcoin relevante) é suficiente. Estes dados, que podem ser ligados em cadeia, deverão permitir-nos remontar ao estado inicial deste contrato, permitindo-nos identificar a essência deste estado.
Para leitores familiarizados com sistemas de contratos inteligentes on-chain (como Ethereum), uma coisa que é difícil de entender sobre esse processo é que se ele não contar com o consenso do blockchain (o que significa que o estado inicial do contrato e cada mudança de estado será verificada por cada nó), como é garantida a segurança deste sistema de contrato inteligente? Como garantir que os activos que recebe são os que deseja e como garantir que os activos não foram emitidos ilegalmente?
A resposta também é muito simples, é chamada de "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 de acordo com as regras de transição de estado público, rejeitam operações inválidas e, em seguida, calculam o estado mais recente com base no estado inicial. No entanto, desde que as regras de transição de estado e o estado inicial sejam conhecidos, a verificação através do consenso na cadeia não é a única maneira.Os utilizadores podem verificar se cada passo da transição de estado segue a transição de estado inicialmente definida com base nas informações fornecidas por o pagador. Desta forma, a parte verificadora (supostamente a destinatária do ativo) também pode detectar transições de estado ilegais e recusar-se a aceitá-las.
Por fim, utilizamos um exemplo para demonstrar as características do protocolo RGB:
Agora, Alice possui UTXO A, que contém X unidades do ativo Y emitidas de acordo com o protocolo RGB. Ela deseja transferir Z unidades de Y para Bob. Este lote de ativos passou por um total de 5 proprietários anteriores (incluindo o emissor do ativo) antes de chegar às mãos de Alice. Portanto, Alice precisa fornecer a Bob evidências dessas quatro transições de estado (as três primeiras foram fornecidas a Alice pelo proprietário anterior), incluindo o estado inicial do contrato e as regras de transição de estado, e os bits usados para cada transferência. . As transações de Bitcoin, as transações RGB cometidas por cada troca de Bitcoin e a evidência de que essas transações de Bitcoin foram confirmadas por um determinado bloco são enviadas para Bob. Bob verificará se essas quatro transferências não violam as regras de acordo com as regras de transição do estado do contrato. e então decidir se deseja aceitá-lo. Quando Alice constrói a transação RGB, como Z é menor que X, ela também precisa organizar um UTXO para receber a parte restante. Finalmente, Alice incorpora o valor hash desta transação RGB na transação Bitcoin que custa UTXO A' para concluir o pagamento.
Finalmente, devido 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 não possui descendentes (cada ponto representa um estado armazenado em um contêiner UTXO). Além disso, para o proprietário P da figura abaixo, ele só conhecerá o processo a partir do estado inicial G do contrato para alcançá-lo, ou seja, o processo marcado pelo círculo vermelho, e nada saberá sobre os pontos cinzas:
VANTAGENS #RGB
Estado verificável leve
Conforme mencionado acima, em comparação com os protocolos anteriores de emissão de ativos (sistemas de contrato fora da cadeia) que apareceram no Bitcoin, o RGB reduz significativamente o custo de verificação (um determinado estado de um contrato). Durante a transação, o receptor não precisa mais percorrer todos os blocos para coletar informações sobre mudanças no status do contrato, mas apenas obter uma série de transações Bitcoin, bem como as transações RGB prometidas por essas trocas, e os blocos desses Bitcoin as transações contêm evidências (com base na evidência Merkle no cabeçalho do bloco), você pode ter certeza de que o pagador realmente possui uma certa quantia de um determinado ativo.
Esta redução nos custos de verificação também reduz enormemente a dependência (confiança) dos utilizadores em grandes fornecedores de infra-estruturas. Nos protocolos anteriores, devido ao alto custo de verificação, era difícil para os usuários calcularem sozinhos o status mais recente do contrato, então os usuários tinham que confiar em alguns provedores (como o provedor de status do contrato usado por sua carteira); ao mesmo tempo tempo, porque eles poderiam arcar com isso. Há menos fornecedores para calcular custos, o que também significa centralização de fornecedores. Mas no RGB, os usuários só precisam usar o cliente Bitcoin light para verificar a parte da transação com Bitcoin e o protocolo RGB para verificar a parte da transação RGB, e eles podem pagar por isso.
Comparado 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; naqueles sistemas que não são baseados em UTXO, devido à falta de um mecanismo para controlar o acesso como o UTXO, qualquer transação pode alterar qualquer estado, então você É quase impossível verificar especificamente um determinado estado, mas só é possível determinar um determinado estado ao calcular todos os estados mais recentes - neste sentido, as características expressas como "estado global" deveriam na verdade ser. É chamado de "estado uniforme". fornece a característica de acesso cruzado entre contratos, também determina que seu custo de verificação será maior e será mais difícil obter confiança.
Nestes protocolos de contrato on-chain, uma medida importante de otimização é exigir que o cabeçalho do bloco se comprometa com o estado mais recente ("raiz do estado"), permitindo assim que clientes leves verifiquem um determinado estado de um contrato obtido do nó completo com base em esses compromissos. Este é um método de reaproveitamento de cálculos já ocorridos (cálculos que foram executados pelo nó completo), e também é muito eficiente, portanto, se não for considerada a falta de confiança, pode ser considerado mais eficiente que o RGB. No entanto, isso significa, afinal, que os nós leves dependem de nós completos para verificação básica de transações e cálculo do status do contrato. Na carteira RGB que usa o cliente Bitcoin light, a suposição de confiança em que se baseia é que a transação Bitcoin relevante é uma transação válida, e a parte relacionada ao status do contrato foi verificada pessoalmente pelo cliente, por isso é mais confiável. grátis. . A desvantagem é que o atraso na verificação é maior e é necessário manter mais dados.
Escalabilidade
A escalabilidade do RGB se reflete em dois aspectos:
Incorporado na transação Bitcoin está apenas um valor hash, o que significa que não há limite para o volume da transação RGB (exceto para as regras personalizadas do contrato) - mesmo se você dividir um ativo RGB em 100 partes (a transação RGB será muito grande) e há apenas um valor de hash que precisa ser incorporado em uma transação Bitcoin. Conforme mencionado na Nota 6, existem duas maneiras de incorporar esse valor hash: uma é usar a saída OP_RETURN, o que significa que consumirá o espaço na cadeia de um valor hash; a outra é ocultar a saída pública do script na chave Taproot - isso não consome nenhum espaço na cadeia. Isso também significa que os usuários não precisam sacrificar a economia pela programabilidade – considerando apenas as taxas na rede.
O último estado 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 um ao outro, o que significa que a simultaneidade é permitida. Na verdade, este é um recurso herdado do UTXO. Isto também significa que alterações inválidas (transações inválidas) que ocorrem em uma agência não afetarão outras agências, muito menos causarão o travamento de todo o contrato, portanto também podem ser consideradas como um benefício de segurança.
Um ponto que tem sido criticado pela escalabilidade do RGB é que cada transferência exige que o destinatário verifique todas as transações envolvidas, desde o estado inicial até o estado pagador - à medida que aumenta o número de vezes que o ativo muda de mãos, aumenta a carga de verificação sobre os destinatários subsequentes. ficará cada vez mais pesado. Esta crítica é verdadeira. Otimizá-lo significa que também precisamos encontrar uma forma de reutilizar operações que já ocorreram. Tecnologias de sistemas de prova, como os SNARKs, prometem fornecer tal solução.
Diferenciação da definição de ativos e mecanismo de custódia
O último benefício ainda está relacionado ao UTXO e depende de como entendemos o mecanismo de bloqueio do script do UTXO.
Um script de bloqueio pode ser utilizado para programar as condições de desbloqueio de um fundo e, portanto, pode implementar regras de custódia. Por exemplo, se um script de bloqueio contém uma e apenas uma chave pública, isso significa que apenas o proprietário da chave privada correspondente pode controlá-lo. No entanto, tais regras de custódia também são a base para a programação do protocolo de contrato Bitcoin. Por exemplo, um UTXO usando um script de bloqueio multi-assinatura 2 de 2 pode ser um canal relâmpago; durante a operação do canal, as duas partes podem pagar uma à outra quase inúmeras vezes sem qualquer alteração na forma on-chain de os fundos. Em outras palavras, neste momento, o script de bloqueio com múltiplas assinaturas 2 de 2 constitui um mecanismo de transferência de valor que permite que ambas as partes transfiram valor sem alterar a forma dos fundos na cadeia.
Tal mecanismo pode ser usado para o valor Bitcoin transportado pela UTXO. Naturalmente, também pode ser usado para os ativos RGB transportados por ela. Podemos emitir um ativo RGB e anexá-lo a um UTXO com múltiplas assinaturas 2 de 2, usando assim o mecanismo de canal relâmpago para pagar esse ativo um ao outro um número ilimitado de vezes. Da mesma forma, os ativos RGB também podem ser celebrados em outros contratos baseados em scripts Bitcoin.
Aqui, o script UTXO e o protocolo RGB formam uma diferenciação funcional: o primeiro está comprometido em realizar as regras de custódia e transferência de valor; enquanto o último se concentra na definição de ativos. Assim, a custódia dos bens e a definição dos bens podem ser separadas. Esta é uma importante melhoria de segurança e algo que as pessoas estão buscando em alguns outros sistemas de contrato em cadeia.
Design RGB já feito
As características acima são realmente verdadeiras para todos os protocolos baseados no selamento único UTXO e na verificação do cliente. Mas nesta base, o protocolo RGB foi desenvolvido posteriormente.
No atual desenvolvimento do protocolo RGB, os desenvolvedores estão particularmente preocupados com a privacidade do protocolo, portanto o RGB fortalece a privacidade em dois aspectos:
UTXO cego. Em uma transação RGB, o destinatário só precisa utilizar o identificador UTXO ofuscado para receber o ativo sem expor as características do UTXO que realmente recebeu o ativo. Isto não prejudica a capacidade do destinatário de fornecer provas ao próximo proprietário, ao mesmo tempo que permite que os destinatários subsequentes dos activos se defendam contra os olhares indiscretos do proprietário anterior do activo.
A prova de balas. Pode ser usado para ocultar o valor específico de cada transação. No entanto, os proprietários de ativos subsequentes ainda podem verificar se nenhuma emissão adicional ocorreu antes.
Espaço a ser explorado
Nesta seção discutirei o espaço que o protocolo RGB pode continuar a explorar, principalmente relacionado à programabilidade.
Atualmente, os modelos de contrato RGB (esquema) propostos concentram-se na emissão de ativos. No entanto, como o RGB usa o paradigma de "verificação do lado do cliente", podemos realmente adicionar a ele quaisquer características que possam ser garantidas pela verificação do lado do cliente - limitada apenas pela estrutura do UTXO.
Restrições
Com base no UTXO, um conceito que pode ampliar a programabilidade é chamado de “convênios”. A intenção original de uma 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, como:
Conjunto de fundos para saques não interativos. Podemos reunir os fundos de muitas pessoas no mesmo UTXO e utilizar cláusulas de restrição para garantir que qualquer uma delas possa retirar os seus próprios fundos sem a ajuda de terceiros. Isto pode ter o efeito de ajudar as pessoas a sair de locais de alto risco a baixo custo quando a procura por espaço nos blocos é elevada.
Contrato do cofre. Um fundo deve primeiro ser gasto em algum lugar e passar por um bloqueio de tempo antes de poder ser gasto livremente; durante o período de bloqueio de tempo, o proprietário do cofre pode interromper esse processo com uma chave de emergência e transferir imediatamente os fundos para outro local. Este dispositivo pode ser uma grande ajuda para a custódia autônoma.
O Bitcoin Script atual não tem esse recurso, portanto, ativar restrições no Bitcoin Script requer um soft fork.
No entanto, desde que estejamos dispostos a sacrificar alguns dos benefícios trazidos pela "diferenciação da definição de activos e mecanismos de custódia", podemos experimentar tais características em activos RGB. Podemos implementar tais funções ao nível do contrato RGB - embora possa apenas Não funciona para ativos RGB que o utilizam (e não para Bitcoin), mas com certeza abrirá um espaço interessante.
A pesquisa existente sobre cláusulas de restrição mostra que ela pode ampliar o espaço de programação das transações baseadas em UTXO e fornecer muitos recursos. Mas esses estudos são basicamente baseados no Bitcoin, e em protocolos como o Bitcoin seremos mais conservadores. No RGB, podemos generalizar com ousadia a capacidade central das cláusulas de restrição – a capacidade de ler transações que se gastam no nível do script – para fornecer uma programabilidade mais flexível: a capacidade de contratos de acesso cruzado.
Acesso cruzado
Termos minimamente restritivos significam que quando um UTXO é gasto, seu script pode ler a saída da transação de gasto. Mas uma restrição totalmente generalizada significa que ela pode ler todas as partes da transação que a gastou. Isso significa que ele também pode ler outras entradas da transação. Se não limitarmos outras entradas a virem do mesmo contrato, significa que ele pode ler o status de outros contratos.
No RGB, predefinimos que cada contrato é um universo independente com seu próprio gráfico acíclico direcionado. No entanto, ainda é possível que um usuário mantenha o status de dois contratos diferentes ao mesmo tempo. Se as transações RGB permitissem o gasto simultâneo de ativos de ambos os contratos, tais capacidades de acesso cruzado poderiam ter aplicações (embora pudessem tornar a verificação das transações mais complicada).
Na verdade, já existem sistemas de contrato on-chain baseados em estruturas semelhantes à UTXO (por exemplo: Rede Nervos), que utilizam isso para obter capacidades de acesso cruzado de contratos. Este é um campo muito novo, abrindo-se para áreas raramente abordadas por pesquisas anteriores sobre Bitcoin, e pode haver algumas surpresas enterradas ali.
para concluir
Neste artigo, os leitores descobrirão que existe um conceito que é mencionado com frequência e que permeia todos os processos de raciocínio e fantasia: “UTXO”. Esta é exatamente a minha intenção. Se você não entende o UTXO, não consegue entender o ponto de partida do design de um protocolo como o RGB, nem consegue entender as vantagens do design do protocolo RGB, nem consegue imaginar como as pessoas o usam. As características do protocolo RGB são amplamente moldadas por sua forma selada única de UTXO. Da mesma forma, a pesquisa sobre UTXO acumulada no campo de pesquisa do Bitcoin também pode ser aplicada à pesquisa sobre RGB.
Isso também explica por que as pessoas que não entendem o Bitcoin terão dificuldade em entender o RGB. Pessoas que gostam de Bitcoin reconhecerão o design que o RGB fez.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Entenda o verdadeiro potencial do protocolo de emissão de ativos RGB em um artigo
Autor: A Jian
Este artigo tenta fornecer uma descrição concisa do RGB, um protocolo de emissão de ativos em Bitcoin (também pode ser entendido como um sistema de contrato inteligente off-chain), e aponta que é muito diferente de outros projetos que visam para alcançar protocolos funcionais iguais ou semelhantes, essas diferenças tornam o protocolo RGB muito mais escalável do que eles e deixam um espaço de programação mais amplo. Além de apresentar os designs concluídos do RGB, também exploraremos essas possibilidades de programação.
O que é o protocolo RGB?
A ideia de emitir ativos em Bitcoin já existe há muito tempo. Mas o protocolo Bitcoin tem suas próprias características: seu estado é expresso apenas por Bitcoin UTXO ("saída de transação não gasta"); um UTXO carrega apenas dois dados: sua própria denominação (valor Bitcoin) e uma "chave pública de script" (também conhecido como "script de bloqueio"), utilizado para programar as condições de gasto deste fundo, por exemplo: fornecer a assinatura de uma determinada chave pública; permitir que o opcode utilizado para programar o script de bloqueio seja determinado pelas regras de consenso do Bitcoin, desde que não possam ser usado para implementar regras de segurança arbitrárias. Portanto, é impossível criar outros ativos dentro do UTXO – o script Bitcoin não pode programar verificações de segurança para esses ativos. Isso significa que todas as ideias para emissão de ativos no Bitcoin são essencialmente usos criativos do espaço de bloco do Bitcoin. Isso significa que precisamos projetar um sistema de contrato inteligente fora da cadeia e exigir as etapas para alterar o estado do contrato - por exemplo, o contrato A altera os parâmetros e B transfere uma certa quantidade de um determinado ativo para C —— As informações são carregadas no blockchain, para que o status mais recente do sistema de contrato inteligente possa ser obtido através da coleta dessas informações.
Uma ideia aproximada de design é carregar intactas as informações das etapas que alteram o estado do contrato para o blockchain do Bitcoin. Isso certamente funciona, mas enfrenta vários problemas:
(1) Como as informações completas são carregadas, elas podem consumir mais espaço de bloco. Quando os usuários precisarem alterar o status do contrato (como uma transferência), eles também precisarão pagar mais taxas de manuseio na cadeia. Em particular, quando esperamos que tal sistema de contrato fora da cadeia tenha melhor programabilidade do que o Bitcoin, o aumento na programabilidade pode ocorrer à custa do consumo de mais espaço em bloco;
(2) Quase todas as informações do bloco podem alterar o contrato inteligente fora da cadeia, portanto, os usuários devem obter todos os dados do bloco Bitcoin para obter o status mais recente do sistema de contrato fora da cadeia, ou seja, é mais caro verificar;
(3) Dependendo do design do sistema de contrato inteligente fora da cadeia, você só poderá obter privacidade comparável à do Bitcoin, ou ainda pior; e se puder fornecer mais privacidade, poderá precisar consumir mais área. bloquear espaço.
No passado, um protocolo amplamente utilizado chamado “Omni” não carregava informações completas sobre transações contratuais fora da cadeia, mas apenas o valor de hash da transação. Esta abordagem resolve os problemas acima e dissocia a complexidade das transações contratuais fora da cadeia de seus custos econômicos; no entanto, os usuários ainda precisam obter a quantidade total de dados do bloco Bitcoin para obter o status mais recente do protocolo Omni; além disso, não não Projetado especificamente para aumentar a privacidade.
RGB usa um novo paradigma chamado “selos descartáveis”. Seu uso é muito simples: RGB exige que cada estado de cada contrato esteja anexado a um determinado Bitcoin UTXO; e uma vez que você queira mudar este estado, você deve gastar este UTXO e deixar que a transação que o gasta receba a Confirmação no blockchain; além disso, a transação Bitcoin que o gasta também deve fornecer um hash do conteúdo da transição de estado para indicar o UTXO anexado ao estado alterado.
Para os desenvolvedores RGB, o design é semelhante a um selo plástico numerado: é fácil saber se foi removido e, uma vez removido, não pode ser reutilizado. No entanto, outra perspectiva é considerar o UTXO possuído como o recipiente ou cofrinho de cerâmica neste estado - se você quiser retirar o dinheiro do cofrinho, você deve quebrá-lo. Em seguida, coloque o dinheiro dentro no novo frasco.
Este design contrasta fortemente com os protocolos anteriores que tratavam o bloco inteiro como uma grande placa de escrita: usar UTXO como contêiner significa que as transações que não gastam esse UTXO não podem ter qualquer impacto no estado do contrato no contêiner. um determinado estado de um determinado contrato, não precisamos obter os dados de todos os blocos. Tudo o que precisamos é de uma série de transações Bitcoin, evidências de que essas transações Bitcoin existem em um determinado bloco e esses bits A conversão de estado RGB prometida por a troca de moeda (par um para um com a transação Bitcoin relevante) é suficiente. Estes dados, que podem ser ligados em cadeia, deverão permitir-nos remontar ao estado inicial deste contrato, permitindo-nos identificar a essência deste estado.
Para leitores familiarizados com sistemas de contratos inteligentes on-chain (como Ethereum), uma coisa que é difícil de entender sobre esse processo é que se ele não contar com o consenso do blockchain (o que significa que o estado inicial do contrato e cada mudança de estado será verificada por cada nó), como é garantida a segurança deste sistema de contrato inteligente? Como garantir que os activos que recebe são os que deseja e como garantir que os activos não foram emitidos ilegalmente?
A resposta também é muito simples, é chamada de "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 de acordo com as regras de transição de estado público, rejeitam operações inválidas e, em seguida, calculam o estado mais recente com base no estado inicial. No entanto, desde que as regras de transição de estado e o estado inicial sejam conhecidos, a verificação através do consenso na cadeia não é a única maneira.Os utilizadores podem verificar se cada passo da transição de estado segue a transição de estado inicialmente definida com base nas informações fornecidas por o pagador. Desta forma, a parte verificadora (supostamente a destinatária do ativo) também pode detectar transições de estado ilegais e recusar-se a aceitá-las.
Por fim, utilizamos um exemplo para demonstrar as características do protocolo RGB:
Agora, Alice possui UTXO A, que contém X unidades do ativo Y emitidas de acordo com o protocolo RGB. Ela deseja transferir Z unidades de Y para Bob. Este lote de ativos passou por um total de 5 proprietários anteriores (incluindo o emissor do ativo) antes de chegar às mãos de Alice. Portanto, Alice precisa fornecer a Bob evidências dessas quatro transições de estado (as três primeiras foram fornecidas a Alice pelo proprietário anterior), incluindo o estado inicial do contrato e as regras de transição de estado, e os bits usados para cada transferência. . As transações de Bitcoin, as transações RGB cometidas por cada troca de Bitcoin e a evidência de que essas transações de Bitcoin foram confirmadas por um determinado bloco são enviadas para Bob. Bob verificará se essas quatro transferências não violam as regras de acordo com as regras de transição do estado do contrato. e então decidir se deseja aceitá-lo. Quando Alice constrói a transação RGB, como Z é menor que X, ela também precisa organizar um UTXO para receber a parte restante. Finalmente, Alice incorpora o valor hash desta transação RGB na transação Bitcoin que custa UTXO A' para concluir o pagamento.
Finalmente, devido 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 não possui descendentes (cada ponto representa um estado armazenado em um contêiner UTXO). Além disso, para o proprietário P da figura abaixo, ele só conhecerá o processo a partir do estado inicial G do contrato para alcançá-lo, ou seja, o processo marcado pelo círculo vermelho, e nada saberá sobre os pontos cinzas:
VANTAGENS #RGB
Estado verificável leve
Conforme mencionado acima, em comparação com os protocolos anteriores de emissão de ativos (sistemas de contrato fora da cadeia) que apareceram no Bitcoin, o RGB reduz significativamente o custo de verificação (um determinado estado de um contrato). Durante a transação, o receptor não precisa mais percorrer todos os blocos para coletar informações sobre mudanças no status do contrato, mas apenas obter uma série de transações Bitcoin, bem como as transações RGB prometidas por essas trocas, e os blocos desses Bitcoin as transações contêm evidências (com base na evidência Merkle no cabeçalho do bloco), você pode ter certeza de que o pagador realmente possui uma certa quantia de um determinado ativo.
Esta redução nos custos de verificação também reduz enormemente a dependência (confiança) dos utilizadores em grandes fornecedores de infra-estruturas. Nos protocolos anteriores, devido ao alto custo de verificação, era difícil para os usuários calcularem sozinhos o status mais recente do contrato, então os usuários tinham que confiar em alguns provedores (como o provedor de status do contrato usado por sua carteira); ao mesmo tempo tempo, porque eles poderiam arcar com isso. Há menos fornecedores para calcular custos, o que também significa centralização de fornecedores. Mas no RGB, os usuários só precisam usar o cliente Bitcoin light para verificar a parte da transação com Bitcoin e o protocolo RGB para verificar a parte da transação RGB, e eles podem pagar por isso.
Comparado 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; naqueles sistemas que não são baseados em UTXO, devido à falta de um mecanismo para controlar o acesso como o UTXO, qualquer transação pode alterar qualquer estado, então você É quase impossível verificar especificamente um determinado estado, mas só é possível determinar um determinado estado ao calcular todos os estados mais recentes - neste sentido, as características expressas como "estado global" deveriam na verdade ser. É chamado de "estado uniforme". fornece a característica de acesso cruzado entre contratos, também determina que seu custo de verificação será maior e será mais difícil obter confiança.
Nestes protocolos de contrato on-chain, uma medida importante de otimização é exigir que o cabeçalho do bloco se comprometa com o estado mais recente ("raiz do estado"), permitindo assim que clientes leves verifiquem um determinado estado de um contrato obtido do nó completo com base em esses compromissos. Este é um método de reaproveitamento de cálculos já ocorridos (cálculos que foram executados pelo nó completo), e também é muito eficiente, portanto, se não for considerada a falta de confiança, pode ser considerado mais eficiente que o RGB. No entanto, isso significa, afinal, que os nós leves dependem de nós completos para verificação básica de transações e cálculo do status do contrato. Na carteira RGB que usa o cliente Bitcoin light, a suposição de confiança em que se baseia é que a transação Bitcoin relevante é uma transação válida, e a parte relacionada ao status do contrato foi verificada pessoalmente pelo cliente, por isso é mais confiável. grátis. . A desvantagem é que o atraso na verificação é maior e é necessário manter mais dados.
Escalabilidade
A escalabilidade do RGB se reflete em dois aspectos:
Incorporado na transação Bitcoin está apenas um valor hash, o que significa que não há limite para o volume da transação RGB (exceto para as regras personalizadas do contrato) - mesmo se você dividir um ativo RGB em 100 partes (a transação RGB será muito grande) e há apenas um valor de hash que precisa ser incorporado em uma transação Bitcoin. Conforme mencionado na Nota 6, existem duas maneiras de incorporar esse valor hash: uma é usar a saída OP_RETURN, o que significa que consumirá o espaço na cadeia de um valor hash; a outra é ocultar a saída pública do script na chave Taproot - isso não consome nenhum espaço na cadeia. Isso também significa que os usuários não precisam sacrificar a economia pela programabilidade – considerando apenas as taxas na rede.
O último estado 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 um ao outro, o que significa que a simultaneidade é permitida. Na verdade, este é um recurso herdado do UTXO. Isto também significa que alterações inválidas (transações inválidas) que ocorrem em uma agência não afetarão outras agências, muito menos causarão o travamento de todo o contrato, portanto também podem ser consideradas como um benefício de segurança.
Um ponto que tem sido criticado pela escalabilidade do RGB é que cada transferência exige que o destinatário verifique todas as transações envolvidas, desde o estado inicial até o estado pagador - à medida que aumenta o número de vezes que o ativo muda de mãos, aumenta a carga de verificação sobre os destinatários subsequentes. ficará cada vez mais pesado. Esta crítica é verdadeira. Otimizá-lo significa que também precisamos encontrar uma forma de reutilizar operações que já ocorreram. Tecnologias de sistemas de prova, como os SNARKs, prometem fornecer tal solução.
Diferenciação da definição de ativos e mecanismo de custódia
O último benefício ainda está relacionado ao UTXO e depende de como entendemos o mecanismo de bloqueio do script do UTXO.
Um script de bloqueio pode ser utilizado para programar as condições de desbloqueio de um fundo e, portanto, pode implementar regras de custódia. Por exemplo, se um script de bloqueio contém uma e apenas uma chave pública, isso significa que apenas o proprietário da chave privada correspondente pode controlá-lo. No entanto, tais regras de custódia também são a base para a programação do protocolo de contrato Bitcoin. Por exemplo, um UTXO usando um script de bloqueio multi-assinatura 2 de 2 pode ser um canal relâmpago; durante a operação do canal, as duas partes podem pagar uma à outra quase inúmeras vezes sem qualquer alteração na forma on-chain de os fundos. Em outras palavras, neste momento, o script de bloqueio com múltiplas assinaturas 2 de 2 constitui um mecanismo de transferência de valor que permite que ambas as partes transfiram valor sem alterar a forma dos fundos na cadeia.
Tal mecanismo pode ser usado para o valor Bitcoin transportado pela UTXO. Naturalmente, também pode ser usado para os ativos RGB transportados por ela. Podemos emitir um ativo RGB e anexá-lo a um UTXO com múltiplas assinaturas 2 de 2, usando assim o mecanismo de canal relâmpago para pagar esse ativo um ao outro um número ilimitado de vezes. Da mesma forma, os ativos RGB também podem ser celebrados em outros contratos baseados em scripts Bitcoin.
Aqui, o script UTXO e o protocolo RGB formam uma diferenciação funcional: o primeiro está comprometido em realizar as regras de custódia e transferência de valor; enquanto o último se concentra na definição de ativos. Assim, a custódia dos bens e a definição dos bens podem ser separadas. Esta é uma importante melhoria de segurança e algo que as pessoas estão buscando em alguns outros sistemas de contrato em cadeia.
Design RGB já feito
As características acima são realmente verdadeiras para todos os protocolos baseados no selamento único UTXO e na verificação do cliente. Mas nesta base, o protocolo RGB foi desenvolvido posteriormente.
No atual desenvolvimento do protocolo RGB, os desenvolvedores estão particularmente preocupados com a privacidade do protocolo, portanto o RGB fortalece a privacidade em dois aspectos:
UTXO cego. Em uma transação RGB, o destinatário só precisa utilizar o identificador UTXO ofuscado para receber o ativo sem expor as características do UTXO que realmente recebeu o ativo. Isto não prejudica a capacidade do destinatário de fornecer provas ao próximo proprietário, ao mesmo tempo que permite que os destinatários subsequentes dos activos se defendam contra os olhares indiscretos do proprietário anterior do activo.
A prova de balas. Pode ser usado para ocultar o valor específico de cada transação. No entanto, os proprietários de ativos subsequentes ainda podem verificar se nenhuma emissão adicional ocorreu antes.
Espaço a ser explorado
Nesta seção discutirei o espaço que o protocolo RGB pode continuar a explorar, principalmente relacionado à programabilidade.
Atualmente, os modelos de contrato RGB (esquema) propostos concentram-se na emissão de ativos. No entanto, como o RGB usa o paradigma de "verificação do lado do cliente", podemos realmente adicionar a ele quaisquer características que possam ser garantidas pela verificação do lado do cliente - limitada apenas pela estrutura do UTXO.
Restrições
Com base no UTXO, um conceito que pode ampliar a programabilidade é chamado de “convênios”. A intenção original de uma 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, como:
Conjunto de fundos para saques não interativos. Podemos reunir os fundos de muitas pessoas no mesmo UTXO e utilizar cláusulas de restrição para garantir que qualquer uma delas possa retirar os seus próprios fundos sem a ajuda de terceiros. Isto pode ter o efeito de ajudar as pessoas a sair de locais de alto risco a baixo custo quando a procura por espaço nos blocos é elevada.
Contrato do cofre. Um fundo deve primeiro ser gasto em algum lugar e passar por um bloqueio de tempo antes de poder ser gasto livremente; durante o período de bloqueio de tempo, o proprietário do cofre pode interromper esse processo com uma chave de emergência e transferir imediatamente os fundos para outro local. Este dispositivo pode ser uma grande ajuda para a custódia autônoma.
O Bitcoin Script atual não tem esse recurso, portanto, ativar restrições no Bitcoin Script requer um soft fork.
No entanto, desde que estejamos dispostos a sacrificar alguns dos benefícios trazidos pela "diferenciação da definição de activos e mecanismos de custódia", podemos experimentar tais características em activos RGB. Podemos implementar tais funções ao nível do contrato RGB - embora possa apenas Não funciona para ativos RGB que o utilizam (e não para Bitcoin), mas com certeza abrirá um espaço interessante.
A pesquisa existente sobre cláusulas de restrição mostra que ela pode ampliar o espaço de programação das transações baseadas em UTXO e fornecer muitos recursos. Mas esses estudos são basicamente baseados no Bitcoin, e em protocolos como o Bitcoin seremos mais conservadores. No RGB, podemos generalizar com ousadia a capacidade central das cláusulas de restrição – a capacidade de ler transações que se gastam no nível do script – para fornecer uma programabilidade mais flexível: a capacidade de contratos de acesso cruzado.
Acesso cruzado
Termos minimamente restritivos significam que quando um UTXO é gasto, seu script pode ler a saída da transação de gasto. Mas uma restrição totalmente generalizada significa que ela pode ler todas as partes da transação que a gastou. Isso significa que ele também pode ler outras entradas da transação. Se não limitarmos outras entradas a virem do mesmo contrato, significa que ele pode ler o status de outros contratos.
No RGB, predefinimos que cada contrato é um universo independente com seu próprio gráfico acíclico direcionado. No entanto, ainda é possível que um usuário mantenha o status de dois contratos diferentes ao mesmo tempo. Se as transações RGB permitissem o gasto simultâneo de ativos de ambos os contratos, tais capacidades de acesso cruzado poderiam ter aplicações (embora pudessem tornar a verificação das transações mais complicada).
Na verdade, já existem sistemas de contrato on-chain baseados em estruturas semelhantes à UTXO (por exemplo: Rede Nervos), que utilizam isso para obter capacidades de acesso cruzado de contratos. Este é um campo muito novo, abrindo-se para áreas raramente abordadas por pesquisas anteriores sobre Bitcoin, e pode haver algumas surpresas enterradas ali.
para concluir
Neste artigo, os leitores descobrirão que existe um conceito que é mencionado com frequência e que permeia todos os processos de raciocínio e fantasia: “UTXO”. Esta é exatamente a minha intenção. Se você não entende o UTXO, não consegue entender o ponto de partida do design de um protocolo como o RGB, nem consegue entender as vantagens do design do protocolo RGB, nem consegue imaginar como as pessoas o usam. As características do protocolo RGB são amplamente moldadas por sua forma selada única de UTXO. Da mesma forma, a pesquisa sobre UTXO acumulada no campo de pesquisa do Bitcoin também pode ser aplicada à pesquisa sobre RGB.
Isso também explica por que as pessoas que não entendem o Bitcoin terão dificuldade em entender o RGB. Pessoas que gostam de Bitcoin reconhecerão o design que o RGB fez.