Sendo um dos princípios fundamentais de conceção da Bitcoin, o modelo UTXO tem sido um paradigma técnico significativo no domínio da cadeia de blocos desde a sua criação. Desempenha um papel crucial na garantia da segurança e rastreabilidade das transacções, proporcionando um caminho alternativo para 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 tem sofrido constante evolução e extensão, como eUTXO, cell, Strict access list, entre 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, utilizamos um exemplo:

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

É evidente que a Alice acaba por ficar com $3 e o Bob acaba por ficar com $7. Este método contabilístico de tipo aritmético elementar é comum nos sistemas bancários e é designado por "modelo de conta/balanço". Neste modelo, o saldo de uma conta existe como um único valor numérico.

Se adoptássemos uma abordagem diferente do modelo de conta, como a utilização de UTXO para representar a transferência de riqueza entre Alice e Bob, o diagrama ilustrativo assumiria uma aparência diferente:

Neste momento, Alice ainda tem $3 e Bob ainda tem $7, mas estes $7 não são representados por um único valor numérico. Em vez disso, são divididos em "$5" e "$2". Esta abordagem não convencional parece-lhe um pouco estranha? Este é o método contabilístico único conhecido como UTXO.

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

No modelo UTXO, não existem conceitos explícitos de "contas" e "saldos". O UTXO funciona como uma estrutura de dados que ajuda na execução da transação, registando informações como o montante que 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 utilizados como entradas e, após a sua destruição, são gerados novos UTXOs como saídas da transação.

É assim que a Bitcoin mantém as contas: com cada transação, os UTXOs antigos são destruídos e os novos são criados. O montante total de UTXOs destruídos é igual ao montante de UTXOs recém-criados (com uma parte atribuída como taxas de transação aos mineiros). Isto garante que os fundos não podem ser aumentados arbitrariamente.

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

Suponha que um grupo de utilizadores inicia um grande número de pedidos de transação em simultâneo. Como é que a situação seria tratada utilizando o modelo UTXO em comparação com o modelo de conta/balanço?

No modelo de conta/saldo, cada utilizador tem uma conta com informação de saldo registada. Quando ocorre uma transação, é necessário atualizar o saldo da conta correspondente, o que envolve operações de "leitura" e "escrita". No entanto, se duas transacções envolverem a mesma conta, isso resulta frequentemente em conflitos de leitura-escrita, levando a uma contenção de estado, uma situação que deve ser evitada.

Os sistemas de bases de dados tradicionais tratam normalmente a contenção de leitura-escrita com um mecanismo de "bloqueio". Neste cenário, as transacções que contendem pelos mesmos dados têm frequentemente de ser colocadas em fila de espera, impedindo a execução simultânea e reduzindo a eficiência do processamento das transacções. Quando existe um grande número de transacções a aguardar processamento, isto pode criar estrangulamentos de desempenho significativos, com as transacções em contenção a enfrentarem tempos de espera prolongados sem um processamento rápido.

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

Além disso, no modelo UTXO, as carteiras encriptadas geram normalmente um novo endereço para o utilizador depois de iniciar uma transação. Esta abordagem aumenta a privacidade, tornando mais difícil a associação de 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 as suas limitações. Foi inicialmente concebido para facilitar transferências de moeda simples e não é adequado para lidar com lógica comercial complexa. Embora as funcionalidades básicas, como a multi-assinatura e os bloqueios de tempo, possam ser implementadas utilizando linguagens de script, a informação mínima de estado que o UTXO da Bitcoin pode registar torna-o menos capaz de lidar com operações mais complexas.

As limitações do UTXO da Bitcoin contribuíram indiretamente para o aparecimento 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 entender para a maioria das pessoas, aborda os desafios que a UTXO enfrenta no tratamento de aplicações de estado rico. Como Vitalik afirmou no livro branco do Ethereum:

O UTXO pode ser gasto ou não gasto; não há oportunidade para contratos em várias fases ou guiões que mantenham qualquer outro estado interno para além desse. Isto dificulta a criação de contratos de opções em várias fases, ofertas de troca descentralizadas ou protocolos de compromisso criptográfico em duas fases (necessários para recompensas computacionais seguras). Significa também que o UTXO só pode ser usado para construir contratos simples e únicos e não contratos mais complexos "com estado", como organizações descentralizadas, e torna os meta-protocolos difíceis de implementar. O estado binário combinado com a cegueira de valor também significa que outra aplicação importante, os limites de levantamento, é impossível.

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

Antes de nos debruçarmos sobre as várias aplicações e optimizações do modelo UTXO, vamos analisar as áreas que podem ser melhoradas, preservando as suas vantagens. Estas podem ser resumidas da seguinte forma:

1. Abstração do significado do estado armazenado nos UTXOs.

2. Abstração da propriedade do Estado.

3. Resolução de problemas de contenção de estado quando partilha UTXOs.

No BTC, o único significado do estado é a quantidade de tokens, a propriedade é tipicamente definida usando chaves públicas e a contenção do estado não é extensivamente abordada, uma vez que o BTC não foi concebido para dApps.

Sui

O Sui fornece aos programadores dois tipos de objectos: OwnedObject e SharedObject. O primeiro é semelhante ao UTXO (especificamente uma versão melhorada), enquanto o segundo é comparável ao modelo de conta/balanço. Ambos podem ser utilizados em simultâneo.

Um Objeto pode ser partilhado, o que significa que qualquer pessoa pode ler ou escrever nesse Objeto. Ao contrário do OwnedObject mutável (com apenas um escritor), o SharedObject requer consenso para ordenar leituras e escritas.

Noutras cadeias de blocos, todos os objectos são partilhados. No entanto, os programadores do Sui podem normalmente optar por utilizar OwnedObject, SharedObject ou uma combinação de ambos para implementar casos de utilização específicos. Esta escolha pode afetar o desempenho, a segurança e a complexidade da implementação.

No Sui, os Objectos Próprios são semelhantes aos UTXOs, e apenas o seu proprietário pode operar neles. Os objectos também têm números de versão, e uma versão de um objeto só pode ser gasta pelo seu proprietário uma vez. Por conseguinte, uma versão de um objeto corresponde essencialmente a um UTXO.

Relativamente aos problemas de contenção de estados, o Sui trata-os através de um tratamento especial (ordenação local, semelhante ao Fuel) nos SharedObjects.

Cardano

Cardano utiliza um modelo UTXO alargado conhecido como eUTXO. O eUTXO suporta uma maior capacidade de programação, mantendo as vantagens do modelo Bitcoin UTXO.

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

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

2. Para além de endereços e valores, as saídas podem transportar (quase) todos os dados, permitindo programar o significado do estado através de scripts.

Mais especificamente, o eUTXO permite aos utilizadores adicionar dados arbitrários num formato semelhante ao JSON aos UTXOs, designados por Datum. O Datum permite que os programadores forneçam uma funcionalidade semelhante a um estado para scripts, associada a UTXOs específicos.

Além disso, as transacções em Cardano podem conter parâmetros relacionados com utilizadores 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ários fins.

Quando uma transação é validada, o script de validação funciona utilizando Datum, Redeemer e o contexto que contém os dados da transação. Este script inclui a lógica para utilizar UTXOs quando as condições são cumpridas.

Vale a pena notar que o eUTXO ainda realiza tarefas de extensão através de scripts e difere significativamente da noção tradicional de "contratos inteligentes" (Charles Hoskinson, o fundador, sugere chamar-lhe um "validador programável", mas o termo "contratos inteligentes" é mais amplamente aceite 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 sob a forma de um código de célula é o seguinte

pub struct CellOutput {

    capacidade do pub: Capacidade,

 pub data: Vec<u8>,

 pub lock: Script,

 pub type_: Opção<Script>,

}

Quanto à questão da contenção de estados, o CKB está atualmente a desenvolver investigação sobre a Transação Aberta, em que os utilizadores podem propor um UTXO parcial especificando o objetivo da transação e, em seguida, os matchmakers agregam-nos numa transação completa.

O modelo celular da Nervos é uma versão "generalizada" do UTXO e Jan forneceu uma explicação pormenorizada 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 transacções e o histórico do estado em duas dimensões, em que os blocos e as transacções representam eventos que desencadeiam transições de estado e não o próprio estado. Em contraste, o protocolo Bitcoin funde transacções e estados numa única dimensão - as transacções são o estado, e o estado é a transação. Trata-se de uma arquitetura centrada no Estado.

Ao mesmo tempo, o CKB tem como objetivo verificar e preservar não só o nValue como o estado, mas também todos os dados considerados valiosos e aprovados por consenso para preservação a longo prazo. A estrutura de saída de transacções da Bitcoin é inadequada para este fim, mas forneceu-nos uma ampla inspiração. Generalizando nValue e transformando-o de um espaço que armazena números inteiros num espaço capaz de conter quaisquer dados, obtemos um "CTxOut" ou Célula mais generalizado.

Numa célula, nValue transforma-se em dois campos: capacidade e dados. Estes 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 o local onde o estado é armazenado e podem acomodar qualquer sequência de bytes. O scriptPubKey torna-se lock, apenas uma mudança de nome, expressando quem é o proprietário deste espaço de consenso - apenas a pessoa que pode fornecer parâmetros (como uma assinatura) para fazer com que o script lock seja executado com sucesso pode "atualizar" o estado nesta Célula. O número total de bytes ocupados por toda a CellOutput tem de ser inferior ou igual à capacidade. A CKB tem numerosas Células e a sua coleção constitui o estado atual completo da CKB, armazenando conhecimentos partilhados e não apenas uma moeda digital específica.

As transacções continuam a representar alterações/migrações do estado. A mudança de estado ou a "atualização" do conteúdo da célula é, na verdade, realizada através da destruição e da criação (e não através da modificação direta do conteúdo da célula original). Cada transação destrói efetivamente um lote de células, criando simultaneamente 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 pode aumentar arbitrariamente a capacidade. Uma vez que 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 Bitcoin UTXOs não gastos se tornam gastos e não são fisicamente removidos da blockchain. Cada célula só pode ser destruída uma vez, tal como cada UTXO só pode ser gasto uma vez.

As características deste 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.

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

Combustível

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

Como introduzido 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 a quantidade de moedas, a ID do contrato, o hash do código do contrato e a raiz de armazenamento.

Se estiver a utilizar um modelo de execução sem estado, apenas o UTXO de contrato requer hash de código de contrato e raiz de armazenamento. Num modelo de execução com estado, estes campos podem ser omitidos no UTXO de contrato, mas é necessário um tipo UTXO de elemento de armazenamento separado. A ID do UTXO, um identificador único para cada UTXO que serve como chave numa base de dados de armazenamento de valores chave, é gerada a partir do ponto de saída do UTXO ou da sua variante (por exemplo, hash do ponto de saída e dos seus campos).

Neste modelo, o contrato UTXO, à semelhança dos contratos inteligentes, pode ser acionado por qualquer pessoa.

É essencial notar que o Fuel fornece funcionalidades mais próximas dos contratos inteligentes do que dos scripts. As limitações do próprio modelo UTXO tornam o desenvolvimento de aplicações com uma VM um desafio, especialmente no que respeita ao tratamento de problemas de contenção do UTXO. Existem geralmente três soluções: em primeiro lugar, processar fora da cadeia, como no rollup; em segundo lugar, pré-sequenciar o trabalho adicional, que o Fuel emprega; em terceiro lugar, a transação aberta acima mencionada no CKB, em que cada utilizador pode propor transacções parciais e um matchmaker (semelhante a um sequenciador) combina-as em transacções completas. A solução correspondente em BTC é PBST.

Conclusão

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

Como um dos princípios fundamentais de conceção da Bitcoin, o modelo UTXO desempenha um papel crucial para garantir a segurança e a rastreabilidade das transacções. Com a contínua evolução e expansão da tecnologia blockchain, o modelo UTXO tem vindo a desenvolver-se (como EUTXO, cell, Strict Access List), proporcionando mais possibilidades para a transação e gestão de activos digitais. Através de uma investigação e compreensão aprofundadas do conceito UTXO e das suas extensões relacionadas, podemos compreender melhor a essência da tecnologia blockchain, criando uma base mais sólida para futuras inovações e aplicações.

Declaração de exoneração de responsabilidade：

1. Este artigo foi reimpresso de[极客 Web3], Todos os direitos de autor pertencem ao autor original[0xAyA]. Se houver objecções a esta reimpressão, contacte a equipa da Gate Learn, que tratará prontamente do assunto.
2. Declaração de exoneração de responsabilidade: Os pontos de vista e opiniões expressos neste artigo são da exclusiva responsabilidade do autor e não constituem um conselho de investimento.
3. As traduções do artigo para outras línguas são efectuadas pela equipa Gate Learn. A menos que seja mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.