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 “ligaçã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 “containers” de ativos RGB.Esta ligaçã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 construir uma camada de contrato inteligente fora da cadeia para o Bitcoin.

No protocolo RGB++, os utilizadores não têm de executar o cliente para verificar pessoalmente os dados das transações e podem delegar tarefas como a verificação da validade dos ativos e o armazenamento de dados às cadeias UTXO, como CKB e Cardano. Desde que seja "otimista" e acredite que a segurança das referidas cadeias públicas é relativamente fiável, não há necessidade de verificar pessoalmente.

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

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

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

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

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

4. Pode suportar 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 ligação isomórfica. No entanto, os dois últimos podem ter alguma bagagem 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 ligados de forma isomórfica.

text:existRGB++Protocol LightPaperEm 2017, Cipher, cofundador da Nervos CKB, propôs pela primeira vez a ideia do produto de ligação isomórfica. Em comparação com outras soluções da Camada 2 do Bitcoin, a ligação isomórfica pode ser mais compatível com protocolos de ativos como RGB, Runas e Atômica, e pode evitar fatores como ativos de cadeia cruzada que trazem encargos adicionais de segurança.

Para simplificar, a ligação isomórfica utiliza UTXO nas cadeias CKB e Cardano como “contentores” para expressar ativos UTXO como RGB, adicionando assim programabilidade e cenários mais complexos. Anteriormente, o Geek web3 tinha aparecido em De BTC para Sui, ADA e Nervos: modelo UTXO e extensões relacionadasDepois de resumir uma série de blockchains que suportam UTXO programável, este artigo irá explorar ainda mais se esses 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 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 equipa CKB no protocolo RGB++, por isso aqui usamos o fluxo de trabalho RGB++ para introduzir o que é a ligação isomórfica baseada em CKB.

Antes de apresentar o protocolo RGB++, vamos entender brevemente o protocolo RGB. RGB é um protocolo de ativos/rede P2P que funciona sob a cadeia Bitcoin, um pouco como a Lightning Network. Além disso, RGB é também um protocolo de ativos parasitários baseado em Bitcoin UTXO. O chamado parasitismo significa que o cliente RGB declarará sob a cadeia Bitcoin a que UTXO certos ativos RGB estão ligados na cadeia Bitcoin. Uma vez que você possui este UTXO, os ativos RGB a ele vinculados também estão ao seu dispor.

Protocolos de ativos como o protocolo RGB e ERC-20 operam de maneiras muito diferentes. O contrato ERC-20 na Ethereum regista o estado do ativo de todos os utilizadores, e o cliente de nó Ethereum irá sincronizar e verificar todas as informações de transferência, e registar as atualizações de estado após a transferência no contrato de ativo. Isto tem sido conhecido das pessoas há muito tempo, e não passa de depender do processo de consenso da Ethereum para garantir que as alterações de estado dos ativos sejam suaves. Uma vez que o consenso dos nós da Ethereum é muito confiável, os utilizadores podem recorrer à 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, simplesmente elimina o consenso do nó/cliente, o que é uma prática convencional no mundo das blockchains. Os utilizadores têm de executar o cliente RGB por si próprios e apenas receber e armazenar "dados de ativos relacionados consigo mesmos". Eles não podem ver o que os outros fizeram. Ao contrário do Ethereum e do ERC-20, todos os registos de transferência são visíveis na cadeia.

Neste caso, se alguém lhe transferir alguns ativos RGB, não saberá 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 si, como lidar com este cenário malévolo de falsificação de moeda?

O protocolo RGB adota esta ideia: Antes de cada transferência ter efeito, o destinatário pede primeiro ao remetente que apresente todo o histórico do ativo. Por exemplo, desde a fase de criação até ao presente, quem emitiu estes ativos, quem os passou, e se cada transferência de ativo que ocorre entre essas pessoas não viola os padrões contabilísticos (uma pessoa adiciona, outra subtrai).

Desta forma, pode saber se o dinheiro dado pela outra parte é “dinheiro duvidoso”, sendo a essência do RGB permitir que as partes na 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 ser garantido 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 sejam 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 libertação do contrato de ativos RGB não pode ser propagada para todos os nós de forma 'extremamente confiável'. Os editores de contratos e os utilizadores simplesmente ficam a saber os detalhes do contrato de ativos RGB espontaneamente através de e-mail ou Twitter e a forma é muito informal.

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 no nosso cliente. Quando outras pessoas nos transferem dinheiro, podemos saber se a transferência atual viola as regras definidas no contrato com base no conteúdo do contrato de ativos armazenado localmente. De acordo com as informações da fonte de ativos (registro histórico) fornecidas no lado oposto, você pode 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 são. Por sua vez, os outros basicamente não sabem o estado 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. Deve manter os dados do ativo RGB localmente no seu cliente. Uma vez que estes dados se percam, causarão sérias consequências (o ativo ficará indisponível). Mas, na realidade, desde que mantenha bem os dados locais, o protocolo RGB pode oferecer-lhe segurança que é 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 espalhá-los para outros nós, e pedir-lhes para ajudar a armazená-los. (Note que estes dados estão encriptados, a outra parte não conhece o texto simples). Desde que não perca a chave, quando os dados locais são perdidos, pode restaurar os dados de ativos que originalmente detinha através de outros nós na rede.

Mas as deficiências do protocolo original RGB 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 o pedido de transferência do remetente. Durante este processo, pelo menos três mensagens devem ser passadas entre as duas partes. Este tipo de "transferência interativa" é seriamente inconsistente com a "transferência não interativa" à qual a maioria das pessoas está habituada. Você consegue imaginar que quando alguém quer transferir dinheiro para você, eles têm que lhe enviar os dados da transação para verificação. Eles podem completar 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 estado verificável, mas o protocolo RGB não suporta inerentemente tais cenários, sendo assim muito desfavorável ao Defi; além disso, no protocolo RGB, os utilizadores têm de executar o cliente para realizar as suas próprias tarefas de verificação. Se receber acidentalmente um ativo que mudou de mãos por dezenas de milhares de pessoas, terá mesmo de verificar as dezenas de milhares de vezes que o ativo mudou de mãos. Obviamente, deixar os utilizadores resolver tudo por si mesmos não é propício à promoção e adoção do próprio produto.

Em relação às questões acima, a solução da RGB++ é permitir que os utilizadores alternem livremente entre o modo de autoverificação do cliente e o modo de alojamento de terceiros. Os utilizadores podem deixar o fardo da verificação e armazenamento de dados, alojamento de contratos inteligentes, etc., para a CKB. Claro, os utilizadores devem ser otimistas e confiar que a CKB, a cadeia pública de POW, é confiável; se algumas pessoas têm uma busca mais elevada por 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 curta])

em artigos anteriores“De RGB para RGB++: Como CKB capacita o protocolo de ativos ecológicos do Bitcoin”, popularizámos brevemente o “binding isomórfico” do RGB++. Aqui faremos uma rápida revisão:

CKB tem o seu próprio UTXO estendido chamado Cell, que é mais programável do que o UTXO na cadeia BTC. A "ligação isomórfica" é usar o Cell na cadeia CKB como um "contentor" 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 UTXO do Bitcoin, a forma lógica do ativo possui as características do UTXO. e a Cell, que também possui características de UTXO, é naturalmente adequada como um “contentor” para os ativos RGB. Sempre que ocorre uma transação de ativos RGB, o contentor Cell correspondente também pode mostrar características semelhantes, tal como a relação entre entidades e sombras. Esta é a essência da “ligação isomórfica”.

Por exemplo, se a Alice possui 100 tokens RGB e UTXO A na cadeia do Bitcoin e tem 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 Bitcoin, publica a declaração acima e depois inicia uma transação na cadeia CKB para consumir o contêiner de células que transporta 100 tokens RGB e gerar dois novos contêineres, um detendo 30 tokens (para Bob), outro detendo 70 tokens (controlado por Alice). Neste 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 consenso, sem intervenção de Bob. CKB atua agora como uma camada de verificação e camada DA sob a cadeia Bitcoin.

Isto é semelhante ao facto de que sempre que o status do contrato Ethereum ERC-20 muda, o utilizador não precisa de 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, 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.

Isto realmente introduz uma importante suposição de confiança: Os utilizadores 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, é fiável e livre de erros. Se não confiar no CKB, também pode seguir o processo de comunicação e verificação interativa no protocolo RGB original e executar o cliente por si próprio.

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

simplesmente, a ligação isomórfica 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 estado do ativo, 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 pode usar o modelo UTXO de CKB ou Cardano como um "contentor" para mostrar a forma e o estado do ativo. É conveniente cooperar com cenários como contratos inteligentes.

Sob o protocolo de ligação isomórfica, os utilizadores podem utilizar diretamente as suas contas de Bitcoin para operar os seus contentores de ativos RGB em cadeias UTXO como CKB sem cruzar a cadeia. Apenas precisa de utilizar a funcionalidade UTXO da Cell para definir as condições de desbloqueio do contentor da Cell a ser associado a um determinado endereço de Bitcoin/UTXO de Bitcoin. Uma vez que já explicámos as características da Cell no artigo de divulgação científica RGB++ anterior do Geekweb3, não iremos entrar em detalhes aqui.

Se ambas as partes envolvidas nas transações de ativos RGB podem confiar na segurança de CKB, nem sequer precisarão de emitir Compromissos frequentemente na cadeia Bitcoin. Depois de muitas transferências de RGB serem feitas, um Compromisso pode ser enviado para a cadeia Bitcoin. Isto é chamado de função de "dobra de transação". Pode reduzir os custos de utilização.

No entanto, deve-se notar que o 'contentor' usado na ligação isomórfica muitas vezes requer uma cadeia pública que suporte o modelo UTXO, ou uma infraestrutura com características semelhantes no armazenamento de estado, e a cadeia EVM claramente não é adequada, e haverá problemas de implementação técnica. Enfrentou muitas armadilhas. Em primeiro lugar, como mencionado anteriormente, o RGB++ 'pode operar contentores de ativos na cadeia CKB sem interligação', o que é basicamente impossível de implementar 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 registar 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 digitalizar todos os registros de transações que interagem com contratos de ativos, o que trará uma enorme pressão.

Para ser franco, os contratos de ativos como o casal ERC-20 armazenam o estado dos ativos de todos. Se quiser verificar individualmente o histórico de alterações de ativos de um deles, tornar-se-á difícil. Tal como numa sala de chat pública, se quiser saber quem enviou mensagens para Wang Gang, terá de folhear os registos de mensagens na sala de chat inteira. UTXO é como um canal de chat privado um-para-um, e é fácil verificar o histórico.

Em resumo, uma camada de expansão de função/cadeia pública adequada para realizar uma 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 aos desenvolvedores escrever scripts de desbloqueio;
3. Existe um espaço de estado relacionado com UTXO que pode armazenar o estado do ativo;
4. Existem pontes ou nós leves relacionados ao Bitcoin;

Claro, também esperamos que a cadeia pública usada para a ligação isomórfica tenha uma 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 utilizadores possam usar diretamente o esquema de assinatura do BTC para desbloquear isomorficamente o seu UTXO em outras cadeias públicas sem alterar o algoritmo de assinatura.

Atualmente, o script de bloqueio UTXO no CKB é programável, e o oficial também é compatível com os esquemas de assinatura de diferentes cadeias públicas. Para ligaçã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 da Fuel e do Cardano e acreditamos que teoricamente podem suportar a ligaçã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 da Camada 2 do Ethereum. Para suporte de função UTXO normal, o Fuel é basicamente consistente com BTC.

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

Moeda de Entrada: UTXO padrão, usado para representar ativos do utilizador, tem um bloqueio de tempo nativo e permite aos utilizadores escrever 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 ativos do contrato;

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

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

Moeda de Saída: 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 estados. O estado completo do contrato é armazenado dentro da biblioteca de estados da Fuel e é de propriedade do contrato inteligente.

Vale a pena mencionar 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, depois 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 da Fuel.

Assim, a experiência de programação de contratos da Fuel é diferente das linguagens de programação UTXO como CKB e Cardanao. 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 contrato inteligente 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

Cardano é outra blockchain que utiliza o modelo UTXO, mas ao contrário do Fuel, é uma cadeia pública de Camada 1. Cardano utiliza o 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;

Resgatadores: Os dados fornecidos pelos utilizadores para desbloquear o 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 o estado dos 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. Suponhamos que precisamos implementar um DAPP de leilão de ativos que exige que os usuários façam lances antes do fim 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 dá um lance mais alto, além de gerar um novo UTXO de contrato de leilão, também será gerado um UTXO de reembolso para a pessoa anterior. 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 o estado de declaração dentro do PlutusCore. Podemos ver que bBidder e bAmount exibem o lance do leilão e o endereço da carteira que deu o lance. Os parâmetros do leilão contêm as informações básicas do leilão.

Quando um usuário gasta este 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 verificação de lances do usuário e de verificar se o leilão atual ainda está em andamento. Certamente, como o 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 o Datum para armazenar o estado do ativo e escrever scripts específicos para serem compatíveis com algoritmos de assinatura relacionados ao Bitcoin. Mas o problema sério é que a maioria dos programadores pode não ser capaz de 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. Utilizar o modelo UTXO
2. Tem uma considerável programabilidade UTXO, permitindo aos desenvolvedores escrever scripts de desbloqueio
3. Existe um espaço de estado relacionado com UTXO que pode armazenar o estado dos ativos
4. Pode suportar a execução de nós leves do Bitcoin através de contratos inteligentes ou outros meios.

Devido à particularidade das suas ideias de programação de contratos inteligentes, o Fuel é compatível com a ligação isomórfica, mas ainda traz alguma bagagem; enquanto o Cardaon usa a linguagem de programação Haskell para programação de contratos, o que torna difícil para a maioria dos desenvolvedores começarem rapidamente. Com base nas razões 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 a ligação isomórfica.

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 Gate Learnequipe e eles lidarão com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer 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.