Como um dos principais princípios de design do Bitcoin, o modelo UTXO tem sido um paradigma técnico significativo no domínio do blockchain desde sua criação. Ele desempenha um papel fundamental para garantir a segurança e a rastreabilidade das transações, oferecendo um caminho alternativo além do modelo tradicional de saldo de conta. Com a contínua evolução e expansão da tecnologia blockchain nos últimos anos, o próprio modelo UTXO vem passando por constante evolução e extensão, como eUTXO, cell, Strict access list e outros.

Este artigo apresenta o modelo UTXO em linguagem simples, fornecendo uma breve visão geral do modelo UTXO e dos métodos de implementação do BTC, Sui, Cardano, Nervos e Fuel.

O que é UTXO?

Para ilustrar o modelo UTXO, usamos um exemplo:

Imagine dois indivíduos, Alice e Bob, cada um inicialmente com US$ 5. Posteriormente, surge um conflito, e Alice foi roubada em US$ 2 por Bob. As participações finais de cada um são as seguintes:

É evidente que Alice acaba ficando com US$ 3 e Bob, por fim, com US$ 7. Esse método contábil de aritmética elementar é comumente visto em sistemas bancários e é chamado de "modelo de conta/balanço". Nesse modelo, o saldo de uma conta existe como um único valor numérico.

Se adotássemos uma abordagem diferente do modelo de conta, como o uso do UTXO para representar a transferência de riqueza entre Alice e Bob, o diagrama ilustrativo teria uma aparência diferente:

Nesse momento, Alice ainda tem US$ 3 e Bob ainda tem US$ 7, mas esses US$ 7 não são representados por um único valor numérico. Em vez disso, eles são divididos em "$5" e "$2". O senhor acha que essa abordagem não convencional é um tanto desconhecida? Esse é o método contábil exclusivo conhecido como UTXO.

O acrônimo em inglês UTXO significa Unspent Transaction Output (saída de transação não gasta). De acordo com essa abordagem contábil, cada transação na cadeia se manifesta como alterações e transferências em UTXOs. Por exemplo, no evento de transação mencionado, os "US$ 5" que Alice possui inicialmente servem como parâmetros de entrada, rotulados como UTXO_0, que serão marcados como gastos; simultaneamente, o sistema gera "US$ 2" (UTXO_1) e "US$ 3" (UTXO_2) como parâmetros de saída. O UTXO_1 será transferido para Bob e o UTXO_2 será devolvido para Alice, completando assim a transferência de riqueza entre Alice e Bob.

No modelo UTXO, não há conceitos explícitos de "contas" e "saldos". O UTXO funciona como uma estrutura de dados que auxilia na execução da transação, registrando informações como o valor que ele representa e o índice de transação associado. Cada UTXO representa uma entrada de transação não gasta, com um proprietário designado. Quando ocorre uma transação, determinados UTXOs podem ser usados como entradas e, após sua destruição, novos UTXOs são gerados como saídas da transação.

É assim que o Bitcoin mantém as contas: a cada transação, os UTXOs antigos são destruídos e os novos são criados. A quantidade total de UTXOs destruídos é igual à quantidade de UTXOs recém-criados (com uma parte alocada como taxas de transação para os mineradores). Isso garante que os fundos não possam ser aumentados arbitrariamente.

Comparação entre o modelo UTXO e o modelo de conta/balanço

Suponha que um grupo de usuários inicie um grande número de solicitações de transações simultaneamente. Como o senhor lidaria com a situação usando o modelo UTXO em comparação com o modelo de conta/balanço?

No modelo de conta/balanço, cada usuário tem uma conta com informações de saldo registradas. Quando ocorre uma transação, o saldo da conta correspondente precisa ser atualizado, o que envolve operações de "leitura" e "gravação". No entanto, se duas transações envolverem a mesma conta, isso geralmente resulta em conflitos de leitura e gravação, levando à contenção de estado, uma situação que deve ser evitada.

Os sistemas de banco de dados tradicionais geralmente tratam a contenção de leitura e gravação com um mecanismo de "bloqueio". Nesse cenário, as transações que causam contenção pelos mesmos dados geralmente precisam entrar em uma fila, impedindo a execução simultânea e reduzindo a eficiência do processamento de transações. Quando há um grande número de transações aguardando processamento, isso pode criar gargalos de desempenho significativos, com transações em contenção enfrentando tempos de espera prolongados sem um processamento rápido.

Em contraste com o modelo de saldo de conta, o modelo UTXO do Bitcoin está mais bem equipado para lidar com problemas de contenção de dados. Nessa abordagem, a entidade de processamento direto de cada transação não é mais uma "conta" específica, mas sim UTXOs individuais e independentes. Como os diferentes UTXOs não interferem uns nos outros, cada transação na rede Bitcoin opera de forma independente. Como resultado, os nós da rede Bitcoin podem processar várias transações simultaneamente sem a necessidade de "bloqueios", melhorando significativamente a taxa de transferência do sistema e o desempenho da simultaneidade.

Além disso, no modelo UTXO, as carteiras criptografadas normalmente geram um novo endereço para o usuário após o início de uma transação. Essa abordagem aumenta a privacidade, tornando mais difícil associar uma transação a um indivíduo específico. Em contrapartida, o modelo de conta/balanço, que utiliza endereços fixos, é mais suscetível à análise de associação.

No entanto, o modelo UTXO tem suas limitações. Ele foi inicialmente projetado para facilitar transferências simples de moeda e não é adequado para lidar com lógica comercial complexa. Embora as funcionalidades básicas, como assinaturas múltiplas e bloqueios de tempo, possam ser implementadas usando linguagens de script, as informações mínimas de estado que o UTXO do Bitcoin pode registrar o tornam menos capaz de lidar com operações mais complexas.

As limitações do UTXO do Bitcoin contribuíram indiretamente para o surgimento do "Ethereum". Vitalik, um dos primeiros colaboradores da Bitcoin Magazine, estava bem ciente das deficiências do Bitcoin. O modelo de conta/balanço, que é mais fácil de ser entendido pela maioria das pessoas, aborda os desafios que a UTXO enfrenta ao lidar com aplicativos de estado rico. Como Vitalik afirmou no whitepaper da Ethereum:

O UTXO pode ser gasto ou não gasto; não há oportunidade para contratos de vários estágios ou scripts que mantenham qualquer outro estado interno além desse. Isso dificulta a criação de contratos de opções de vários estágios, ofertas de troca descentralizadas ou protocolos de compromisso criptográfico de dois estágios (necessários para recompensas computacionais seguras). Isso também significa que o UTXO só pode ser usado para criar contratos simples e únicos, e não contratos mais complexos "com estado", como organizações descentralizadas, e dificulta a implementação de metaprotocolos. O estado binário combinado com a cegueira de valor também significa que outra aplicação importante, os limites de saque, é impossível.

Aplicação, otimização e extensão do modelo UXTO

Antes de nos aprofundarmos em várias aplicações e otimizações do modelo UTXO, vamos analisar as áreas que podem ser melhoradas, preservando suas vantagens. Elas podem ser resumidas da seguinte forma:

1. Abstrair o significado do estado armazenado em UTXOs.

2. Abstração da propriedade do estado.

3. Resolução de problemas de contenção de estado ao compartilhar UTXOs.

No BTC, o único significado do estado é a quantidade de tokens, a propriedade é normalmente definida usando chaves públicas e a contenção de estado não é amplamente abordada, pois o BTC não foi projetado para dApps.

Sui

O Sui oferece aos desenvolvedores dois tipos de objetos: OwnedObject e SharedObject. O primeiro é semelhante ao UTXO (especificamente uma versão aprimorada), enquanto o segundo é comparável ao modelo de conta/balanço. Ambos podem ser usados simultaneamente.

Um objeto pode ser compartilhado, o que significa que qualquer pessoa pode ler ou gravar nesse objeto. Diferentemente do OwnedObject mutável (com apenas um gravador), o SharedObject exige consenso para ordenar as leituras e gravações.

Em outras blockchains, cada objeto é compartilhado. No entanto, os desenvolvedores do Sui geralmente podem optar por usar OwnedObject, SharedObject ou uma combinação de ambos para implementar casos de uso específicos. Essa escolha pode afetar o desempenho, a segurança e a complexidade da implementação.

No Sui, os Owned Objects são semelhantes aos UTXOs, e somente o proprietário pode operar neles. Os objetos também têm números de versão, e uma versão de um objeto só pode ser gasta por seu proprietário uma única vez. Portanto, uma versão de um objeto corresponde essencialmente a um UTXO.

Com relação aos problemas de contenção de estado, o Sui os aborda por meio de um tratamento especial (ordenação local, semelhante ao Fuel) em SharedObjects.

Cardano

A Cardano utiliza um modelo UTXO estendido, conhecido como eUTXO. O eUTXO oferece suporte a uma maior capacidade de programação e, ao mesmo tempo, mantém as vantagens do modelo Bitcoin UTXO.

Em Cardano, o significado do estado é expandido ainda mais por meio de scripts, e a propriedade do estado é definida de forma mais generalizada. Os conjuntos UTXO são usados para minimizar os problemas de contenção de estado. Especificamente, o eUTXO é aprimorado em dois aspectos:

1. O modelo eUTXO inclui endereços mais generalizados. Esses endereços não se baseiam apenas no hash de chaves públicas, mas podem ser definidos com base em qualquer lógica que especifique as condições sob as quais o eUTXO pode ser gasto, permitindo a programabilidade da propriedade do estado.

2. Além de endereços e valores, as saídas podem conter (quase) qualquer dado, o que permite programar o significado do estado por meio de scripts.

Mais especificamente, o eUTXO permite que os usuários adicionem dados arbitrários em um formato semelhante ao JSON aos UTXOs, chamados de Datum. O Datum permite que os desenvolvedores forneçam funcionalidade semelhante ao estado para scripts, associados a UTXOs específicos.

Além disso, as transações em Cardano podem conter parâmetros relacionados a usuários específicos, conhecidos como redentores. O Redeemer permite que o iniciador da transação defina como os UTXOs são utilizados e podem ser empregados por desenvolvedores de dApp para várias finalidades.

Quando uma transação é validada, o script de validação opera usando Datum, Redeemer e o contexto que contém os dados da transação. Esse script inclui a lógica para usar UTXOs quando as condições são atendidas.

Vale a pena observar que o eUTXO ainda realiza tarefas de extensão por meio de scripts e difere significativamente da noção tradicional de "contratos inteligentes" (Charles Hoskinson, o fundador, sugere chamá-lo de "validador programável", mas o termo "contratos inteligentes" é mais amplamente aceito no mercado).

Nervos

No Nervos (CKB), o significado do estado é abstraído pelo TypeScript, e a propriedade do estado é abstraída por um lockscript. Um modelo simples de otimização do UTXO na forma de um código de célula é o seguinte:

pub struct CellOutput {

    capacidade do pub: Capacity,

 pub data: Vec<u8>,

 pub lock: Script,

 pub type_: Option<Script>,

}

Quanto à questão da contenção de estado, o CKB está atualmente avançando na pesquisa sobre Open Transaction, em que os usuários podem propor um UTXO parcial especificando a finalidade da transação e, em seguida, os matchmakers os agregam em uma transação completa.

O modelo de célula da Nervos é uma versão "generalizada" do UTXO, e Jan forneceu uma explicação detalhada no fórum da Nervos:

O foco da Camada 1 é o estado e, com a Camada 1 como alvo do projeto, o CKB naturalmente se concentra no estado.

O Ethereum separa o histórico de transações e o histórico do estado em duas dimensões, em que blocos e transações representam eventos que desencadeiam transições de estado, e não o estado em si. Em contrapartida, o protocolo Bitcoin mescla transações e estados em uma única dimensão - as transações são o estado e o estado é a transação. É uma arquitetura centrada no estado.

Ao mesmo tempo, o CKB tem como objetivo verificar e preservar não apenas o nValue como o estado, mas todos os dados considerados valiosos e aprovados por consenso para preservação de longo prazo. A estrutura de saída de transações do Bitcoin é inadequada para essa finalidade, mas nos forneceu uma ampla inspiração. Ao generalizar o nValue e transformá-lo de um espaço que armazena números inteiros em um espaço capaz de armazenar qualquer dado, obtemos um "CTxOut" ou Cell mais generalizado.

Em uma célula, nValue se transforma em dois campos: capacidade e dados. Esses campos representam conjuntamente um espaço de armazenamento, em que a capacidade é um número inteiro que indica o tamanho do espaço em bytes, e os dados são onde o estado é armazenado e podem acomodar qualquer sequência de bytes. O scriptPubKey se torna um bloqueio, apenas uma mudança no nome, expressando quem é o proprietário desse espaço de consenso - somente a pessoa que pode fornecer parâmetros (como uma assinatura) para fazer com que o script de bloqueio seja executado com êxito pode "atualizar" o estado nessa célula. O número total de bytes ocupados por todo o CellOutput deve ser menor ou igual à capacidade. O CKB tem vários Cells, e sua coleção forma o estado atual completo do CKB, armazenando conhecimento compartilhado em vez de apenas uma moeda digital específica.

As transações ainda representam mudanças/migrações do estado. A mudança de estado ou a "atualização" do conteúdo da célula é, na verdade, realizada por meio da destruição e da criação (e não pela modificação direta do conteúdo da célula original). Cada transação destrói efetivamente um lote de células e, ao mesmo tempo, cria um novo lote de células. As células recém-criadas têm novos proprietários e armazenam novos dados, mas a capacidade total destruída é sempre maior ou igual à capacidade total criada, garantindo que ninguém possa aumentar arbitrariamente a capacidade. Como a capacidade pode ser transferida, mas não aumentada arbitrariamente, possuir capacidade é equivalente a possuir uma quantidade correspondente de espaço de estado de consenso. A capacidade é o ativo nativo da rede CKB. A destruição de uma célula apenas a marca como "destruída", semelhante à forma como os UTXOs de Bitcoin não gastos se tornam gastos e não são fisicamente removidos do blockchain. Cada célula só pode ser destruída uma vez, assim como cada UTXO só pode ser gasto uma vez.

As características desse modelo são:

1. O estado é de importância primordial.

2. A propriedade é um atributo do estado, sendo que cada estado tem um único proprietário.

3. Os Estados são continuamente destruídos e criados.

Portanto, uma célula é uma versão generalizada do UTXO.

Combustível

O Fuel adota o modelo Strict Access List, que é uma otimização UTXO baseada no conceito de Contract UTXO.

Conforme apresentado anteriormente, o UTXO tradicional em BTC tem apenas dois atributos: quantidade de moedas e proprietário. Em contrapartida, o Contract UTXO fornece propriedades fundamentais adicionais, incluindo quantidade de moedas, ID do contrato, hash do código do contrato e raiz de armazenamento.

Se estiver usando um modelo de execução sem estado, somente o UTXO de contrato requer hash de código de contrato e raiz de armazenamento. Em um modelo de execução com estado, esses campos podem ser omitidos no Contract UTXO, mas é necessário um tipo separado de Storage Element UTXO. O ID do UTXO, um identificador exclusivo para cada UTXO que serve como chave em um banco de dados de armazenamento de valores chave, é gerado a partir do ponto de saída do UTXO ou de sua variante (por exemplo, hash do ponto de saída e seus campos).

Nesse modelo, o Contrato UTXO, semelhante aos contratos inteligentes, pode ser chamado por qualquer pessoa.

É essencial observar que o Fuel oferece funcionalidades mais próximas de contratos inteligentes do que de scripts. As limitações do próprio modelo UTXO tornam o desenvolvimento de aplicativos com uma VM desafiador, especialmente no tratamento de problemas de contenção do UTXO. Geralmente, há três soluções: primeiro, processar fora da cadeia, como no rollup; segundo, pré-sequenciar o trabalho adicional, que o Fuel emprega; terceiro, a transação aberta mencionada acima no CKB, em que cada usuário pode propor transações parciais e um matchmaker (semelhante a um sequenciador) as combina em transações completas. A solução correspondente no BTC é o PBST.

Conclusão

Com este artigo, compreendemos os princípios fundamentais do UTXO, reconhecemos os pontos fortes e fracos de seu modelo em comparação com o modelo de conta/balanço da Ethereum e obtivemos uma visão mais clara do conceito de UTXO e de suas extensões relacionadas.

Como um dos principais princípios de design do Bitcoin, o modelo UTXO desempenha um papel crucial para garantir a segurança e a rastreabilidade das transações. Com a evolução e a expansão contínuas da tecnologia blockchain, o modelo UTXO vem se desenvolvendo (como EUTXO, cell, Strict Access List), oferecendo mais possibilidades para a transação e o gerenciamento de ativos digitais. Por meio de pesquisa e compreensão aprofundadas do conceito UTXO e de suas extensões relacionadas, podemos compreender melhor a essência da tecnologia blockchain, estabelecendo uma base mais sólida para inovações e aplicações futuras.

Isenção de responsabilidade：

1. Este artigo foi reimpresso de[极客 Web3], todos os direitos autorais pertencem ao autor original[0xAyA]. Se houver alguma objeção a essa reimpressão, entre em contato com a equipe do Gate Learn, que tratará do assunto imediatamente.
2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são de responsabilidade exclusiva do autor e não constituem consultoria de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.