Encaminhar o Título Original 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态'

Resumo:· O protocolo de ativos RGB++ proposto pela equipe CKB propôsA essência da ideia de "vinculação isomórfica" é usar CKB, Cardano, Fuel e outras blockchains baseadas no modelo de programação UTXO como uma camada de expansão funcional que carrega "contêineres" de ativos RGB.Esta vinculação isomórfica também é aplicável aos protocolos de ativos ecológicos do Bitcoin com características UTXO, como Atomical e Runes, tornando fácil a construção de uma camada de contrato inteligente fora da cadeia para o Bitcoin.

· No protocolo RGB ++, os usuários não precisam executar o cliente para verificar pessoalmente os dados da transação e podem transferir tarefas como verificação de validade de ativos e armazenamento de dados para cadeias UTXO como CKB e Cardano. Contanto que você seja “otimista” e acredite que a segurança das mencionadas cadeias públicas é relativamente confiável, não há necessidade de verificar por si mesmo;

· O protocolo RGB++ suporta os usuários a voltarem para o modo de verificação do cliente. Neste momento, você ainda pode usar CKB como uma camada de armazenamento de dados/DA sem precisar manter os dados você mesmo. O protocolo RGB++ não exige ativos entre cadeias e pode operar ativos na cadeia CKB através de contas do Bitcoin, e pode reduzir a frequência de emissão de Compromissos para a cadeia do Bitcoin, o que também é benéfico para apoiar cenários de Defi;

· Se estiver sob o sistema de contrato EVM, muitas características do RGB++ não são fáceis de suportar. Em conjunto, uma camada de expansão de função/cadeia pública adequada para realizar a ligação isomórfica deve ter as seguintes características:

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

2. Tem uma considerável programabilidade UTXO, permitindo que os desenvolvedores escrevam scripts de desbloqueio;

3. Existe um espaço de estado relacionado a UTXO que pode armazenar o status do ativo;

4. Pode apoiar a operação de nós leves do Bitcoin através de contratos inteligentes ou outros meios;

· Além do CKB, Cardano e Fuel também podem suportar um vínculo isomórfico. No entanto, os dois últimos podem ter algumas desvantagens em termos de linguagem de contrato inteligente e detalhes de design de contrato. Atualmente, parece que o CKB é mais adequado do que os dois últimos como uma camada de expansão de função para protocolos de ativos Bitcoin vinculados isomorficamente.

Em 2017, Cipher, co-fundador do Nervos CKB, propôs a ideia do produto de associação isomórfica pela primeira vez. Comparado com outras soluções do Layer 2 do Bitcoin, a associação isomórfica pode ser melhor compatível com protocolos de ativos como RGB, Runes e Atomical, e pode evitar fatores como ativos entre cadeias que trazem encargos adicionais de segurança.

Simplificando, a ligação isomórfica usa UTXO nas cadeias CKB e Cardano como “recipientes” para expressar ativos UTXO como RGB, adicionando assim programabilidade e cenários mais complexos. Anteriormente, a web3 Geek havia aparecido em Do BTC para Sui, ADA e Nervos: modelo UTXO e extensões relacionadasAo ter resumido uma série de blockchains que suportam UTXO programável, este artigo irá explorar mais a fundo se essas blockchains podem se adaptar ao esquema de ligação isomórfica.

RGB++ e ligação isomórfica

Antes de analisar a compatibilidade de diferentes cadeias de UTXO com ligação isomórfica, devemos primeiro introduzir o princípio da ligação isomórfica. A ligação isomórfica é um conceito proposto pela equipe CKB no protocolo RGB++, então aqui usamos o fluxo de trabalho RGB++ para introduzir o que é a ligação isomórfica baseada em CKB.

Antes de introduzir o protocolo RGB++, vamos entender brevemente o protocolo RGB. RGB é um protocolo de ativos/rede P2P executado sob a cadeia Bitcoin, um pouco como a Lightning Network. Além disso, o RGB também é um protocolo de ativos parasitários baseado no UTXO do Bitcoin. O chamado parasitismo significa que o cliente RGB declarará sob a cadeia Bitcoin a qual UTXO certos ativos RGB estão vinculados na cadeia Bitcoin. Uma vez que você possui este UTXO, os ativos RGB vinculados a ele também estão à sua disposição.

Protocolos de ativos como o protocolo RGB e ERC-20 operam de maneiras muito diferentes. O contrato ERC-20 no Ethereum registra o status do ativo de todos os usuários, e o cliente de nó Ethereum irá sincronizar e verificar todas as informações de transferência, e registrar as atualizações de status após a transferência no contrato de ativo. Isso já é conhecido das pessoas há muito tempo, e não passa de depender do processo de consenso do Ethereum para garantir que as mudanças de status dos ativos sejam suaves. Como o consenso dos nós Ethereum é muito confiável, os usuários podem considerar a plataforma de custódia de ativos com base em contratos ERC-20 como “sem problemas”, mesmo que não executem o cliente.

Mas o protocolo RGB é muito estranho. Para aumentar a privacidade, ele simplesmente exclui o consenso do nó/cliente, o que é uma coisa convencional no mundo blockchain. Os usuários precisam executar o cliente RGB por conta própria e apenas receber e armazenar "dados do ativo relacionados a si mesmos". Eles não podem ver o que os outros fizeram. Ao contrário do Ethereum e do ERC-20, todos os registros de transferência são visíveis na cadeia.

Neste caso, se alguém transferir alguns ativos RGB para você, você não sabe antecipadamente como o dinheiro foi criado e de quem mudou de mãos. Se a pessoa do outro lado declarar um ativo do nada e depois transferir parte dele para você, como lidar com esse cenário maligno de falsificação de moeda?

O protocolo RGB adota essa ideia: Antes que cada transferência tenha efeito, o destinatário pede primeiro ao remetente para apresentar toda a história do ativo. Por exemplo, desde a fase de criação até o presente, quem emitiu esses ativos, quem passou por eles e se cada transferência de ativos que ocorre entre essas pessoas não viola os padrões contábeis (uma pessoa soma, outra subtrai).

Dessa forma, você pode saber se o dinheiro dado a você pela outra parte é “dinheiro questionável”, então a essência do RGB é permitir que as partes da transação executem o cliente para verificação. Com base no modo de verificação do cliente, correspondendo à suposição do jogo da pessoa racional, desde que as partes envolvidas sejam racionais e o software do cliente esteja OK, pode-se garantir que a transferência de ativos problemáticos não terá efeito ou será reconhecida por outros.

Vale ressaltar que o protocolo RGB comprimirá os dados da transação sob a cadeia do Bitcoin em um Compromisso (essencialmente uma raiz de merkle) e os enviará para a cadeia do Bitcoin. Isso permitirá que os registros de transferência sob a cadeia estejam diretamente conectados à rede principal do Bitcoin. Faça uma conexão.

(Fluxograma de interação do protocolo RGB)

Uma vez que não há consenso entre os clientes RGB, a liberação do contrato de ativos RGB não pode ser propagada para todos os nós “extremamente confiavelmente”. Os editores e usuários de contratos simplesmente aprendem os detalhes do contrato de ativos RGB espontaneamente por e-mail ou Twitter, e a forma é muito casual.

A figura abaixo mostra um cenário de transferência de ativos RGB maliciosos. Como usuário do RGB, precisamos armazenar o contrato inteligente correspondente ao ativo RGB localmente em nosso cliente. Quando outros nos transferem dinheiro, podemos saber se a transferência atual viola as regras definidas no contrato com base no conteúdo do contrato de ativo armazenado localmente. De acordo com as informações da fonte de ativos (registro histórico) fornecidas no lado oposto, é possível confirmar se há algum problema com a fonte dos ativos da outra parte (se foi declarado do nada).

Revisando o processo acima, não é difícil ver que os dados recebidos e armazenados por diferentes clientes RGB são frequentemente independentes, e muitas vezes você não sabe quais ativos os outros têm e quanto eles têm. Por sua vez, os outros basicamente não sabem o status dos seus ativos.

Esta é uma ilha de dados típica, ou seja, os dados armazenados por todos são inconsistentes. Embora teoricamente possa melhorar a privacidade, também traz muitos problemas. Você deve manter os dados de ativos RGB localmente em seu cliente. Uma vez que esses dados sejam perdidos, isso causará sérias consequências (o ativo ficará indisponível). Mas, na realidade, desde que você mantenha bem os dados locais, o protocolo RGB pode oferecer segurança basicamente equivalente à mainnet do Bitcoin.

Além disso, o protocolo Bifrost usado para comunicação entre clientes RGB ajudará os usuários na comunicação p2p com outros clientes. Eles podem criptografar seus dados de ativos e distribuí-los para outros nós, e pedir-lhes para ajudar a armazená-los. (Observe que estes são dados criptografados, a outra parte não conhece o texto simples). Desde que não perca a chave, quando os dados locais forem perdidos, você pode restaurar os dados de ativos que você possuía originalmente através de outros nós na rede.

Mas as deficiências do protocolo RGB original ainda são óbvias. Em primeiro lugar, cada transação requer múltiplas comunicações entre as duas partes. A parte receptora deve primeiro verificar a origem dos ativos do remetente e depois enviar um recibo para aprovar a solicitação de transferência do remetente. Durante esse processo, pelo menos três mensagens devem ser trocadas entre as duas partes. Esse tipo de 'transferência interativa' é seriamente inconsistente com a 'transferência não interativa' à qual a maioria das pessoas está acostumada. Você consegue imaginar que, quando alguém quer transferir dinheiro para você, eles precisam enviar os dados da transação para você verificar. Eles podem concluir o processo de transferência apenas depois de receber a sua mensagem de recibo? (O fluxograma pode ser visto no artigo anterior)

Em segundo lugar, a grande maioria dos cenários de Defi requer contratos inteligentes com dados transparentes e status verificáveis, mas o protocolo RGB não suporta inerentemente tais cenários, sendo assim muito hostil ao Defi; além disso, no protocolo RGB, os usuários precisam executar o cliente para realizar suas próprias tarefas de verificação. Se você receber acidentalmente um ativo que mudou de mãos entre dezenas de milhares de pessoas, terá que verificar até mesmo as dezenas de milhares de vezes que o ativo mudou de mãos. Claramente, deixar os usuários resolverem tudo por conta própria não é propício para a promoção e adoção do próprio produto.

Em relação às questões acima, a solução da RGB++ é permitir que os usuários alternem livremente entre o modo de autoverificação do cliente e o modo de hospedagem de terceiros. Os usuários podem deixar o ônus da verificação e armazenamento de dados, hospedagem de contratos inteligentes, etc. para o CKB. Claro, os usuários devem ser otimistas e confiar que o CKB, a cadeia pública de POW, é confiável; se algumas pessoas têm um maior interesse na segurança e privacidade, por exemplo, grandes investidores com grandes quantidades de ativos também podem voltar ao modo RGB original. O que deve ser enfatizado aqui é que a RGB++ e o protocolo RGB original são teoricamente compatíveis entre si.

(Fluxograma de interação do protocolo RGB++ [versão resumida])

em artigos anteriores"De RGB para RGB++: Como CKB capacita o protocolo de ativos ecológicos do Bitcoin", nós popularizamos brevemente a “ligação isomórfica” do RGB++. Aqui iremos rapidamente revisar:

CKB tem seu próprio UTXO estendido chamado Cell, que é mais programável do que o UTXO na cadeia BTC. O “vínculo isomórfico” é usar o Cell na cadeia CKB como um “contêiner” para os dados de ativos RGB e escrever os parâmetros-chave do ativo RGB no Cell.

Uma vez que existe uma relação vinculativa entre os ativos RGB e o Bitcoin UTXO, a forma lógica do ativo possui as características de UTXO. E o Cell, que também possui características de UTXO, é naturalmente adequado como um “contêiner” para os ativos RGB. Sempre que ocorre uma transação de ativo RGB, o contêiner Cell correspondente também pode mostrar características semelhantes, assim como a relação entre entidades e sombras. Essa é a essência da “ligação isomórfica”.

Por exemplo, se Alice possui 100 tokens RGB e UTXO A na cadeia do Bitcoin e possui uma Célula na cadeia CKB, esta Célula é marcada com "Saldo do Token RGB: 100" e as condições de desbloqueio estão relacionadas ao UTXO A.

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

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

Isso é semelhante ao fato de que toda vez que o status do contrato Ethereum ERC-20 muda, o usuário não precisa executar a verificação do cliente. O princípio é semelhante. O protocolo de consenso e a rede de nós substituem a verificação do cliente. Além disso, os dados de ativos RGB de todos são armazenados na cadeia CKB, o que é globalmente verificável, o que é propício para a implementação de cenários Defi, como pools de liquidez e protocolos de garantia de ativos.

Isso realmente introduz uma importante suposição de confiança: Os usuários tendem a ser otimistas de que a cadeia CKB, 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 de comunicação interativa e verificação no protocolo RGB original e executar o cliente vocêm mesmo.

Claro, se alguém quiser executar o cliente RGB++ por si mesmo e verificar a fonte histórica dos ativos de outras pessoas, ele pode verificar diretamente a história relacionada ao contêiner de ativos RGB Cell na cadeia CKB. Desde que você execute um nó leve CKB e receba a Prova de Merkle e cabeçalhos de bloco CKB, você pode ter certeza de que os dados históricos que você recebeu não foram adulterados por atacantes maliciosos na rede. Pode-se dizer que o CKB atua como uma camada de armazenamento de dados históricos aqui.

Em termos simples, o vínculo isomórfico não se aplica apenas ao RGB, mas também a vários protocolos de ativos com características UTXO, como Runes e Atomic., transfere todo o status de ativos, dados históricos e contratos inteligentes correspondentes armazenados localmente no cliente do usuário para cadeias públicas UTXO como CKB ou Cardano para armazenamento e hospedagem. O protocolo de ativos UTXO mencionado acima pode usar o modelo UTXO da CKB ou Cardano como um “contêiner” para mostrar a forma e o status do ativo. É conveniente para cooperar com cenários como contratos inteligentes.

Sob o protocolo de ligação isomórfica, os usuários podem usar diretamente suas contas de Bitcoin para operar seus contêineres de ativos RGB em cadeias UTXO como CKB sem cruzar a cadeia. Você só precisa usar o recurso UTXO de Célula para definir as condições de desbloqueio do contêiner de Célula para ser associado a um certo endereço Bitcoin/Bitcoin UTXO. Uma vez que já explicamos as características da Célula no artigo de divulgação científica RGB++ anterior do Geekweb3, não entraremos em detalhes aqui.

Se ambas as partes envolvidas nas transações de ativos RGB puderem confiar na segurança do CKB, nem precisarão emitir Compromissos com frequência na cadeia do Bitcoin. Depois que muitas transferências RGB forem feitas, um Compromisso pode ser enviado para a cadeia do Bitcoin. Isso é chamado de função de 'dobramento de transação'. Pode reduzir os custos de uso.

No entanto, deve-se observar que o "contêiner" usado na ligação isomórfica frequentemente requer uma cadeia pública que suporte o modelo UTXO, ou uma infraestrutura com características similares no armazenamento de estado, e a cadeia EVM obviamente não é adequada, e haverá problemas de implementação técnica. Encontrados muitos obstáculos. Em primeiro lugar, como mencionado anteriormente, o RGB++ "pode operar contêineres de ativos na cadeia CKB sem interligação", o que é basicamente impossível de ser implementado na cadeia EVM; mesmo que seja implementado à força, o custo pode ser muito alto;

Além disso, no protocolo RGB++, muitas pessoas não precisam executar o cliente ou armazenar dados de ativos localmente. Se o método ERC-20 for usado para registrar o saldo de ativos de todos neste contrato, se alguém quiser voltar ao modo de autoverificação do cliente e propor verificar a origem dos ativos de alguém, neste momento ele pode ter que escanear todos os registros de transações que interagem com contratos de ativos, o que trará uma enorme pressão.

Para ser franco, contratos de ativos como ERC-20 acoplam e armazenam o status de ativos de todos. Se você quiser verificar individualmente o histórico de alterações de ativos de um deles, isso se tornará difícil. Assim como em uma sala de bate-papo pública, se você quiser saber quem enviou mensagens para Wang Gang, terá que folhear os registros de mensagens em toda a sala de bate-papo. UTXO é como um canal de bate-papo privado um-a-um e é fácil verificar o histórico.

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

1. Use o modelo UTXO ou esquema de armazenamento de estado semelhante;
2. Tem uma programabilidade UTXO considerável, permitindo que os desenvolvedores escrevam scripts de desbloqueio;
3. Existe um espaço de estado relacionado a UTXO que pode armazenar o status do ativo;
4. Existem pontes ou nós leves relacionados ao Bitcoin;

Claro, também esperamos que a cadeia pública usada para o vínculo isomórfico tenha segurança forte. Por outro lado, também esperamos que as condições de desbloqueio UTXO na cadeia pública sejam programáveis, para que os usuários possam usar diretamente o esquema de assinatura do BTC para desbloquear seu UTXO isomorficamente vinculado em outras cadeias públicas sem alterar o algoritmo de assinatura.

Atualmente, o script de bloqueio UTXO em CKB é programável, e o oficial também é compatível com os esquemas de assinatura de diferentes cadeias públicas. Para vinculação isomórfica, a rede CKB basicamente atende às características acima. E quanto a outras cadeias públicas baseadas em UTXO? Realizamos uma inspeção preliminar de Fuel e Cardano e acreditamos que teoricamente podem suportar a vinculação isomórfica.

Combustível: Ethereum OP Rollup baseado em UTXO

Fuel é um Ethereum OP Rollup baseado em UTXO e é um pioneiro na introdução do conceito de prova de fraude no ecossistema Ethereum Layer 2. Para suporte de função UTXO normal, Fuel é basicamente consistente com BTC.

Fuel divide seus UTXO internos nas seguintes três categorias:

Moeda de entrada: UTXO padrão, usado para representar os ativos do usuário, tem um bloqueio de tempo nativo e permite que os usuários escrevam predicados de script de desbloqueio;

Contrato de entrada: O UTXO usado para chamadas de contrato contém dados como a raiz do estado do contrato e os ativos do contrato;

Mensagem de entrada: UTXO usado para transmitir informações contém principalmente campos como destinatário de informações;

Quando um usuário gasta um UTXO, a seguinte saída é produzida:

Output Coin: Para transferências de ativos padrão;

Contrato de Saída : A saída gerada pela interação do contrato internamente contém a raiz do estado após a interação do contrato;

Contrato de saída criado: Um UTXO especial é a saída gerada ao criar um contrato, que contém o ID e a raiz do estado do contrato;

Ao contrário da Célula CKB, que contém todos os estados de contrato internamente, o UTXO da Fuel na verdade não carrega todos os estados de contrato relacionados à transação. A Fuel carrega apenas a raiz do estado do contrato Stateroot no UTXO, que é a raiz da árvore de estado. O estado completo do contrato é armazenado dentro da biblioteca de estados da Fuel e é de propriedade do contrato inteligente.

Vale ressaltar que, em relação ao processamento de status de contratos inteligentes, o contrato Fuel e o contrato de solidez são ideologicamente consistentes e até mesmo relativamente próximos em forma de programação. A figura abaixo mostra um contrato de contador escrito na linguagem Sway da Fuel. O contrato contém um contador. Quando o usuário chama a função increment_counter, o contador armazenado no contrato é incrementado em 1.

Podemos ver que a lógica de escrita do contrato Sway é semelhante à de um contrato Solidity geral. Primeiro, fornecemos o ABI do contrato, em seguida, as variáveis de estado do contrato e, em seguida, a implementação específica do contrato. Todos os processos de escrita de código não envolvem o sistema UTXO do Fuel.

Portanto, a experiência de programação de contratos da Fuel é diferente das linguagens de programação UTXO, como CKB e Cardano. A Fuel fornece uma experiência mais próxima da programação e desenvolvimento de contratos inteligentes EVM. Os desenvolvedores também podem usar a linguagem Sway para construir scripts de desbloqueio para implementar lógica de verificação de algoritmo de assinatura especial ou lógica de desbloqueio de múltiplas assinaturas complexas.

É basicamente viável implementar a ligação isomórfica dentro do Fuel, mas ainda existem os seguintes problemas:

A linguagem de balanço usada pelo Fuel é mais próxima da cadeia EVM em termos de design de contratos inteligentes do que do BTC ou CKB e Cardano. Emissoras de ativos UTXO como RGB e Atomics precisam construir especificamente um contrato inteligente no Fuel. CKB e outras cadeias usam outro, que é bastante complicado.

Cardano: cadeia pública eUTXO baseada em POS

Cardaon é outra blockchain que usa o modelo UTXO, mas ao contrário do Fuel, é uma cadeia pública de Camada 1. Cardano usa eUTXO (UTXO estendido) para se referir ao modelo de programação UTXO em seu sistema. Comparado com CKB, o eUTXO no Cardano contém as seguintes estruturas:

Script: Os contratos inteligentes são usados para verificar se UTXO pode ser desbloqueado e realizar transições de estado;

Redentores: Os dados fornecidos pelos usuários para desbloquear UTXO são geralmente dados de assinatura, semelhantes aos Testemunhos do Bitcoin;

Datum: O espaço de estado dos contratos inteligentes pode armazenar dados como status de ativos;

Contexto da Transação: Dados contextuais para transações UTXO, como parâmetros de entrada e resultados da transação (O processo de cálculo da transação da cadeia UTXO é realizado diretamente off-chain, e os resultados do cálculo são submetidos à cadeia para verificação. Se passarem na verificação, os resultados da transação são enviados para a cadeia)

Os desenvolvedores podem usar a linguagem PlutusCore para programar UTXO na cadeia Cardano. Semelhante ao CKB, os desenvolvedores podem escrever scripts de desbloqueio e algumas funções para atualizações de status.

Apresentamos o modelo de programação UTXO da Cardano com um processo de leilão baseado em UTXO. Suponha que precisamos implementar um DAPP de leilão de ativos que exige que os usuários façam lances antes do término do leilão. Especificamente, o usuário consome seu próprio UTXO, contrata UTXO com este leilão e depois gera um novo UTXO. Quando alguém faz um lance maior, além de gerar um novo UTXO de contrato de leilão, um UTXO de reembolso para a pessoa anterior também será gerado. O processo específico é o seguinte:

Para implementar o processo de leilão acima, alguns estados precisam ser armazenados no UTXO do contrato inteligente de leilão, como o preço mais alto do leilão atual e a pessoa que fez o lance. A figura abaixo mostra a declaração de status dentro do PlutusCore. Podemos ver que bBidder e bAmount exibem o lance do leilão e o endereço da carteira que fez o lance. Os parâmetros do leilão contêm as informações básicas do leilão.

Quando um usuário gasta esse UTXO, podemos atualizar o estado dentro do contrato. A figura abaixo mostra algumas atualizações de status específicas e lógica de negócios dentro do contrato de leilão. Por exemplo, a lógica de verificar os lances do usuário e verificar se o leilão atual ainda está em andamento. certamente, uma vez que PlutusCore é uma linguagem de programação Haskell, que é uma linguagem de programação puramente funcional, a maioria dos desenvolvedores pode não ser capaz de entender diretamente seu significado.

É viável construir ligações isomórficas no Cardano. Podemos usar Datum para armazenar o status do ativo e escrever scripts específicos para serem compatíveis com algoritmos de assinatura relacionados ao Bitcoin. Mas o problema grave é que a maioria dos programadores pode não conseguir se adaptar ao uso do PlutusCore para programação de contratos. Além disso, seu ambiente de programação é difícil de configurar e não é amigável para os desenvolvedores.

Resumir

A ligação isomórfica requer que a cadeia tenha as seguintes propriedades:

1. Use o modelo UTXO
2. Tem uma considerável programabilidade UTXO, permitindo que os desenvolvedores escrevam scripts de desbloqueio
3. Existe um espaço de estado relacionado a UTXO que pode armazenar o status do ativo
4. Pode suportar a execução de nós leves do Bitcoin por meio de contratos inteligentes ou outros meios.

Devido à particularidade de suas ideias de programação de contratos inteligentes, Fuel é compatível com binding isomórfico, mas ainda traz alguma bagagem; enquanto o Cardano usa a linguagem de programação Haskell para programação de contratos, o que torna difícil para a maioria dos desenvolvedores começar rapidamente. Com base nos motivos acima, o CKB, que adota o conjunto de instruções RISC-V e é mais equilibrado nas características da programação UTXO, pode ser uma camada de expansão de função mais adequada para o binding isomórfico.

Aviso legal:

1. Este artigo é reproduzido a partir de [极客 Web3]. Encaminhe o Título Original 'RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态'. Todos os direitos autorais pertencem ao autor original [Shew]. Se houver objeções a esta reimpressão, entre em contato com o Portão Aprenderequipe e eles cuidarão disso prontamente.
2. Isenção de Responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.