Em 10 de junho, o autor do protocolo RGB ++ e fundador do CELL Studio, Cipher, o cofundador do DotSwap, Lin, o cofundador da Shell Finance, Timxie, e o CMO NIGO da TBC (Turingbitchain) foram convidados no Twitter Space do UTXO Stack para discutir se o modelo UTXO pode ser usado. nascimento de um novo modelo de ecologia Bitcoin.

UTXO Stack é uma plataforma modular de emissão de cadeia BTC L2 com um clique que pode ajudar os desenvolvedores de projetos a emitir Bitcoin L2 com base na arquitetura UTXO com um clique e integra nativamente o protocolo RGB++. Em termos de segurança, UTXO Stack garante a segurança do L2 penhorando os ativos do Bitcoin, CKB e Bitcoin L1. Simplificando, podemos pensar no UTXO Stack como o OP Stack + EigenLayer do ecossistema Bitcoin.

A UTXO Stack concluiu uma rodada inicial de financiamento, co-liderada pela ABCDE e SNZ Capital, com a participação de instituições conhecidas como OKX Ventures, Waterdrip Capital, Matrixport, y2z Ventures, DRK Lab e UTXO Management, o braço de capital de risco da Empresa controladora da Bitcoin Magazine, BTC Inc.

A seguir está o conteúdo principal organizado de acordo com o áudio:

1. Quais são as diferenças e vantagens essenciais entre o modelo UTXO e o modelo de conta em termos de filosofia de design, segurança, eficiência, etc.?

Cipher: Acho que existem algumas diferenças principalmente na filosofia de design e na eficiência. A segurança pode depender mais do mecanismo de consenso e tem pouco a ver com o modelo de conta.

Em termos de filosofia de design, o UTXO está mais focado na verificação do que no cálculo. Conhecemos o modelo de conta do Ethereum. Quando você escreve um programa ou envia uma transação, você não sabe o resultado da transação. O que você envia é uma ação ou uma chamada de função. transação é Você não saberá o resultado até que seja empacotado em blocos.

Um exemplo típico é, supondo que você tenha apenas 0,1 ETH em sua conta, você pode enviar uma transação para transferir 0,2 ETH? Sim, você pode enviá-lo, mas depois que a transação entrar no pool de transações, ela pode ser empacotada e um erro será retornado porque você não tem tanto dinheiro, mas sua taxa de gás ainda será deduzida. Mas se alguém transferir uma quantia em dinheiro para sua conta ao mesmo tempo que você a envia, fazendo com que o saldo de sua conta exceda 0,2 ETH, então sua transação será executada com sucesso e, claro, a taxa de gás será deduzida.

Mas para o modelo UTXO, sua transação não pode ser enviada porque sua conta não tem dinheiro suficiente e você não consegue gerar insumos suficientes. Portanto, não há estado de falha de transação no modelo UTXO. Ele possui apenas dois estados: sucesso de transação ou falha no envio. Ou seja, a chamada falha de transação significa que a verificação falha e sua taxa de manuseio não será deduzida. UTXO acredita que o blockchain é uma máquina de verificação e não uma máquina de cálculo. Ethereum, que usa o modelo de conta, já teve um apelido chamado de computador mundial. É para cálculo, que é uma filosofia de design completamente diferente.

Há também uma diferença muito grande entre os dois em termos de eficiência. UTXO indica claramente qual estado foi usado antes, depois destrói-o e atualiza-o para o novo estado. Quando o Ethereum chama uma função, ele não sabe quais estados irá acessar antes da chamada, portanto só pode lidar com o pior cenário, ou seja, sem pré-processamento de todos os estados. Portanto, cada transação no Ethereum só pode ser executada em série. Um computador desktop comum possui uma CPU com pelo menos seis núcleos e 12 threads, mas para um EVM padrão, ele ainda é executado em um único thread. UTXO é diferente. Todas as suas transações podem distinguir automaticamente quais transações conflitantes não serão enviadas para o pool de transações. . Claro, agora existe uma narrativa chamada EVM paralela, que quer resolver esse problema de alguma forma, mas pela descrição feita agora, todos também podem perceber que isso não pode ser resolvido essencialmente.

Tim Xie: Concordo muito com o que a Cipher acabou de dizer: “O modelo UTXO do Bitcoin é mais focado na verificação, e o modelo de conta do Ethereum é mais focado no cálculo”. Durante o DeFi Summer, faremos algumas trocas, e a taxa de gás do Ethereum será muito alta. Embora o Ethereum tenha velocidade de geração de blocos mais rápida, blocos maiores e melhor desempenho do que o Bitcoin, o Ethereum tem A demanda por expansão é na verdade maior do que a do Bitcoin. Bitcoin. por que? A razão é que Ethereum é um modelo de computação. Quando jogamos DeFi, 98% das taxas de gás que pagamos podem ser gastas em cálculos. O custo de verificação, propagação e armazenamento do status da conta é, na verdade, muito pequeno. Bitcoin é uma rede de verificação que não realiza cálculos, então fazemos empréstimos ou swaps na segunda camada do Bitcoin. No mesmo cenário, a taxa de manuseio é na verdade mais barata que a do Ethereum.

O segundo é a simultaneidade. Por que o EVM serial? A Cipher acabou de explicar isso de forma muito clara. Que diferença isso trará nos negócios? Ao emprestar no Ethereum, você precisa depositar antes de poder pedir emprestado, porque a lógica de negócios é que você precisa ter garantias e esperar até que a transação hipotecária seja confirmada e o status seja corrigido antes de poder calcular o valor líquido de sua garantia e limites de liquidação, permitindo que você peça dinheiro emprestado, é tudo em série. UTXO pode fazer simultaneidade e podemos compactar todas as transações tanto quanto possível, o que significa que as transações de depósito e de empréstimo dos usuários podem ser mescladas para melhorar a eficiência.

Pela nossa experiência, usando o modelo UTXO para DeFi no Bitcoin, a experiência do usuário final não é tão ruim quanto as pessoas imaginam. Embora a experiência não seja tão tranquila quanto as aplicações no Ethereum ou Arbitrum, ainda não é tão ruim, ainda utilizável.

Lin: Deixe-me fazer um suplemento. A tecnologia existente está em constante evolução. Acho que o UTXO não faz cálculos, também pode fazer cálculos. Por exemplo, o código de operação Bitcoin recentemente discutido OP_CAT, se habilitado, pode reter o estado no UTXO do Bitcoin. Se removermos todas as limitações nativas do Bitcoin, podemos simular inúmeros Ethereums no UTXO do Bitcoin. Cada UTXO pode estar no estado de um Ethereum, e então armazenar dados e a execução neste estado pode ser realizada. deduzido para baixo, embora isso possa não necessariamente atingir a compatibilidade completa do EVM.

Então eu acho que o Bitcoin também pode fazer cálculos, e a lógica do Bitcoin é que você pode abrir um novo thread a qualquer momento, e você pode dividir um novo UTXO a qualquer momento. O novo UTXO é completamente separado do UTXO original. Bitcoin Uma característica do UTXO na computação.

Depois de adicionar OP_CAT, ele trará alguns cenários de aplicação muito inteligentes. Por exemplo, os tokens Ethereum ERC-20 manterão uma lista para saber quais contas têm quanto dinheiro. Depois de adicionar OP_CAT, podemos fazer coisas semelhantes no Bitcoin, e podemos até fazer melhor que o Ethereum.

Entre os UTXO, o compartilhamento de dados é, na verdade, um grande espaço desconhecido. Por exemplo, os acordos (restrições) ainda precisam de algum tempo para serem construídos. Quando este assunto avança, como compartilhar dados entre diferentes UTXOs, como referenciar dados fora da transação em transações, etc., pode haver um avanço.

NIGO: Sempre pensei que o Ethereum mudou o modelo UTXO do Bitcoin para um modelo de conta, o que na verdade é uma típica etapa supérflua e transforma um sistema que originalmente era capaz de simultaneidade em um sistema serial. Ethereum é chamado de computador mundial por muitas pessoas. Por que a tarefa de cálculo de uma pessoa comum deveria ser calculada por mineradores de todo o mundo? Esse processo consome muita energia e é muito caro, mas não traz nenhum benefício substancial, mas o atrasa. eficiência geral. Depois que o Ethereum mudou para PoS, os mineradores (nós) de toda a rede perderam seu impulso evolutivo. O modelo UTXO projetado por Satoshi Nakamoto é naturalmente adequado para alta simultaneidade e alto desempenho. Acredito que mais usuários da Web3 verão o potencial do modelo UTXO.

2. É o modelo UTXO que faz com que o Bitcoin não tenha recursos de contrato inteligente? Se quisermos implementar capacidades de contrato inteligente baseadas no modelo UTXO, qual mecanismo geralmente é usado para alcançá-lo?

Cifra: Certamente existem muitas maneiras de implementar recursos de contrato inteligente baseados no modelo UTXO. Deixe-me apresentar como o CKB, com o qual estou mais familiarizado, o implementa.

CKB introduziu um script de bloqueio, que é consistente com o script de bloqueio do Bitcoin. Quando este UTXO for gasto, o script de bloqueio será usado automaticamente como entrada com base nos dados da testemunha, e a transação atual também será usada. como entrada para executar. A diferença entre ele e o script de bloqueio do Bitcoin é que ele suporta uma máquina virtual Turing completa completa em vez do ambiente de script muito limitado do Bitcoin, portanto é Turing completo neste estágio de desbloqueio.

Ao mesmo tempo, o CKB introduziu o campo de script de tipo, que será executado independentemente de ser entrada ou saída. É executado mais como uma categoria do ativo, ou o mesmo tipo representa o mesmo tipo de ativo. Por exemplo, a quantidade total de tokens fungíveis permanece inalterada antes e depois da transação, e a quantidade e o conteúdo dos tokens não fungíveis permanecem inalterados antes e depois da transação, ou pode ser usado para determinar quem tem o direito de emitir um novo ativo, etc. Também é uma VM Turing-completa.

A máquina virtual do CKB é baseada no conjunto de instruções de hardware RISC-V. Qualquer ajuste envolve re-silício, portanto o design do conjunto de instruções RISC-V é muito simplificado, eficiente e abrangente.

Para resumir, o CKB usa a máquina virtual RISC-V, que é Turing completa, e também possui dois locais: script de bloqueio e script de tipo para armazenar scripts de contrato inteligente, e também há um campo chamado dados para armazenar scripts de contrato inteligente. estado do contrato, portanto é um ambiente completo de execução de contrato.

Tim Xie: Em todo o processo de construção do produto do nosso Shell Finance, porque temos que fazer protocolo de empréstimo e liquidação, precisamos de algumas funções de contrato avançadas. No final, escolhemos DLC (Discreet Log Contracts). Tanto o DLC quanto o Lightning Network são tecnologias de expansão do mesmo nível, e ambos são offchain. A diferença é que o Lightning Network é usado principalmente para pagamento, enquanto o DLC é usado principalmente para oráculos. Na verdade, não somos Turing completos e ainda existem muitas restrições, mas mesmo com muitas restrições já podemos fazer empréstimos por DLC.

Na verdade, o Bitcoin tem muitos códigos OP. Se pudermos ativar ou desbloquear o OP_CAT mencionado por Lin do DotSwap antes, ou alguns outros códigos de operação, então poderemos continuar a criar mais na linha Lightning Network e DLC. , os contratos inteligentes podem definitivamente fazer isso. A questão central é se existe procura, se existem utilizadores, se existe um mercado e se mais pessoas investirão tempo e energia para concebê-lo, utilizá-lo e satisfazer as necessidades dos utilizadores. Enquanto houver pessoas usando e houver mercado, novas ideias e conceitos surgirão naturalmente.

O que tenho certeza agora é que o formato do ecossistema Bitcoin será completamente diferente daquele do EVM. Talvez no nível empresarial, os usuários possam ter sentimentos semelhantes. Ambos fazem trocas e empréstimos e também têm oráculos, mas os sistemas por trás deles e as ferramentas que podem ser usadas no final são, na verdade, muito diferentes. Se estiver na rede principal do Bitcoin, essa diferença será ainda maior, então estou ansioso por L2 com uma estrutura UTXO melhor, porque pode liberar ainda mais o potencial do ecossistema Bitcoin.

Lin: Acho que não é difícil projetar algo para ser Turing completo, mas é muito difícil tornar algo Turing incompleto. Projetar um script para ser não Turing completo é, na verdade, uma tarefa técnica muito avançada.

O script original do Bitcoin pode ser Turing completo, mas agora muitos recursos do Bitcoin foram selados. Por exemplo, o OP_CAT que mencionei antes é um recurso muito importante, mas esse recurso foi desativado pelo operador, em vez de dizer que o Bitcoin não tinha. esses operadores quando foi originalmente projetado. O Bitcoin envolveu muitos operadores no início, mas por causa da chamada segurança, ou dos chamados perigos ocultos desta segurança, ou porque não havia uma compreensão clara do que era, como usá-lo, etc., alguns operadores foram desativados. Alguns operadores estão desativados. Além do mais, muitas funções que poderiam ter sido usadas para contratos inteligentes foram filtradas pelas chamadas transações padrão. Todos dizemos que o Bitcoin é um sistema descentralizado, mas neste sistema descentralizado existe algo chamado transação padrão, que é determinada por certas organizações. As transações padrão não existem no campo dos mineiros, porque os mineiros podem empacotar qualquer transação legal. É uma questão de política baseada no lado do usuário.

Então, em geral, acho que a capacidade original do Bitcoin em si é muito poderosa, mas agora o Bitcoin foi sequestrado. Se você estiver interessado, pode ler o livro de Roger Ver "Hijacking Bitcoin: The Hidden History of BTC". Como as capacidades originais do Bitcoin foram seladas, somos forçados a encontrar saídas em vários lugares. Esta é a situação atual que enfrentamos, mas o futuro do Bitcoin é definitivamente melhor.

Tenho dito que muitos dos chamados Bitcoin L2s são, na verdade, protocolos parasitas. Eles não contribuem com seu próprio valor para o Bitcoin e não há como os mineiros terem rendimentos mais elevados, mas na verdade não há como, porque. Bitcoin tem muitas restrições. Deixe-me fazer uma analogia. O protocolo HTTP é, na verdade, L2 construído no protocolo TCP/IP, e nosso protocolo HTML é construído no protocolo HTTP. Acho que este é um conceito de camada por camada, em vez de os dados da transação serem completamente separados do TCP/IP, separados do protocolo da camada superior, executados para outro local e, em seguida, virarem-se e dizer aos outros que esta é a Camada 2 protocolo. O protocolo real da Camada 2 é, na verdade, empilhado camada por camada, portanto, o L2 que construímos também deve ser aceito como transações legais na camada superior. Esta é uma razão muito importante pela qual estamos atualmente explorando uma camada de troca. Acreditamos que, na maioria dos casos, precisamos de nos contentar com uma camada, e precisamos de ter muita verificação e consenso sobre a primeira camada, em vez de dizer que construirei uma chamada ponte de activos e depois transferirei os interesses de todos ativos para outro Um lugar onde isso pode não ser uma coisa particularmente boa.

NIGO: O modelo UTXO pode suportar funções complexas de contratos inteligentes? Claro que é possível. Ele armazena a lógica e os dados do contrato em UTXO, depois usa a chamada e os parâmetros do contrato como entrada para tentar desbloquear o contrato, executa a lógica do contrato através de BVM (Blockchain Virtual Machine) e finalmente consegue o controle retornando verdadeiro ou falso da função de desbloqueio A finalidade do status do contrato. Este modelo pode não ser familiar para os desenvolvedores de contratos inteligentes Ethereum, mas na verdade, se você combinar ideias de programação funcional e converter alguns conceitos, os contratos inteligentes UTXO podem implementar uma lógica muito complexa.

Como o modelo UTXO não possui um estado global, ele precisa armazenar o estado e a lógica do contrato no UTXO e, em seguida, transferir e converter o estado através da transmissão da cadeia de chamadas da transação UTXO, de modo que cada transação UTXO consumirá o anterior UTXO. E gerar novo UTXO, desta forma, a transferência de estado em cadeia do contrato pode ser realizada. Portanto, se o UTXO pode ser desbloqueado corresponde ao resultado da execução do contrato e se permite a transferência de estado. Se o contrato determinar que o status não pode ser modificado, como transferências não são permitidas, modificação de dados não é permitida, etc., ele retornará falso, então o UTXO não será desbloqueado e a execução do contrato falhará.

Consideramos os contratos como máquinas de estado que transferem estados de dados, por isso podemos ver aqui a diferença entre contratos UTXO e contratos do tipo conta. O EVM do contrato de conta é manter o estado global. Uma transação pode fazer com que o EVM realize múltiplas transferências de estado e modifique frequentemente os dados do estado até que o contrato seja executado ou o gás seja consumido. Já a transação do contrato UTXO é um contrato de entrada. A chamada apenas acionará uma transferência de estado e, por mais complexa que seja a lógica dentro do contrato ou quantas vezes o estado seja transferido, a BVM registrará apenas a transferência de estado final. resultado na cadeia. Portanto, o contrato UTXO não possui estado global, apenas funções aguardando para serem executadas.

UTXO é múltiplas entradas e múltiplas saídas. O que Ethereum deseja fazer, incluindo o EVM paralelo que Monad também deseja fazer, pode realmente ser realizado por meio de UTXO. Se você precisar transferir o estado, primeiro você deve encontrar a função onde o estado está. localizado e modificar o estado por meio de chamadas de função e gerar novas funções. Este modelo torna a transferência de estado dos contratos UTXO.

Os contratos UTXO não dependem de estados externos, portanto, não importa quantas vezes um contrato seja chamado, seu resultado deve ser certo. Portanto, isso traz grande comodidade para análise de contratos, depuração e testes unitários. O contrato EVM depende do estado global, pelo que o resultado da execução do contrato é susceptível de ser afectado pelo ambiente externo, fazendo com que o resultado da execução do contrato seja incerto. Por exemplo, se o saldo for suficiente, será um. resultado, e se não for suficiente, será outro resultado. Portanto, esta é também uma questão importante para a segurança e previsibilidade dos contratos EVM.

É claro que passar o estado sempre não é isento de custos. Em alguns cenários onde a rastreabilidade é necessária, o status pode aumentar à medida que a cadeia de transferência UTXO aumenta, porque a rastreabilidade precisa ser verificada e há cada vez mais dados. em si se expandirá infinitamente. Nosso TBC resolveu um grande problema de expansão do estado através de outras tecnologias e meios criptográficos, como hashing e extração de dados. Portanto, uma característica importante que distingue os contratos inteligentes do TBC de outras cadeias UTXO é que o modelo UTXO é uma base para a expansão ilimitada do TBC. É muito simples usar o modelo UTXO para realizar transações de transferência padrão.

Em resumo, a TBC considerou plenamente as vantagens e desvantagens do modelo UTXO e, com base na absorção da essência do Ethereum e de outras cadeias públicas UTXO, introduziu um conceito BVM e outras tecnologias para implementar uma camada real de contratos inteligentes UTXO. , e então Juntamente com algumas ferramentas de desenvolvimento de contratos inteligentes mais amigáveis, o limite para escrever e implantar contratos inteligentes BVM é reduzido.

(Continua)