Modelos de Blockchains: UTXO vs Contas

Texto Original: https://academy.horizen.io/technology/expert/utxo-vs-account-model/

UTXO VS MODELO DE CONTA

Para que o dinheiro digital seja útil, ele precisa ser transferível. A transferência de dinheiro em uma blockchain é iniciada pelo proprietário, criando uma transação. Essa transação informa à rede quanto dinheiro está mudando de mãos e quem é o novo proprietário.

A criptografia de chave pública-privada garante a validade do proprietário que está transferindo fundos de sua carteira para outra. A chave é comprovada e verificada em uma blockchain, um aspecto fundamental para permitir transações seguras.

Neste artigo, veremos os modelos de contabilidade/saldo usados ​​em blockchains. Um dos modelos é o UTXO (unspent transaction output), usado pelo Bitcoin por exemplo. O segundo método para rastrear saldos de usuários, conforme aplicado no Ethereum, é o modelo de conta.

Começaremos analisando suas semelhanças e, em seguida, mergulharemos profundamente em cada modelo individualmente. Por fim, compararemos os dois modelos e mostraremos brevemente como eles podem ser combinados para criar um sistema híbrido.

A Blockchain é uma Máquina de Estado

Antes de entrarmos nos diferentes modelos de saldo, faz sentido dar um passo atrás e olhar para a blockchain em termos mais gerais - como uma máquina de estados.

De acordo com a Wikipedia, “um sistema é descrito como stateful se for projetado para lembrar eventos anteriores ou interações do usuário; a informação lembrada é chamada de estado do sistema”. Portanto, uma blockchain se qualifica como um sistema com estado. Todo o seu objetivo é registrar eventos passados ​​e interações do usuário. A cada novo bloco o sistema passa por uma transição de estado que acontece de acordo com a lógica de transição de estado definida em seu protocolo.

Cada blockchain, não importa se usa o UTXO ou o modelo de conta, segue esse esquema. As interações do usuário, principalmente transações, são transmitidas para a rede e, a cada novo bloco, um conjunto delas é gravado permanentemente. Os saldos das partes transacionais são atualizados quando o sistema transita para o novo estado. A diferença entre o modelo UTXO e o modelo de conta está na forma como a escrituração é feita. Por escrituração queremos dizer registrar o estado e fazer a transição de um estado para outro.

Registrando o Estado

A primeira diferença significativa entre os dois modelos de balanço é como o estado do sistema é registrado. No modelo UTXO, a movimentação de ativos é registrada como um grafo acíclico direcionado (DAG) entre endereços, enquanto o modelo de contas mantém um banco de dados de estados da rede.

Um grafo é definido como um conjunto de nós ou vértices conectados por arestas. Em um grafo direcionado, cada aresta tem uma direção, geralmente indicada por setas. Grafos acíclicos direcionados não permitem relacionamentos circulares entre nós. Vamos dar uma olhada mais detalhada nas figuras aqui.

A figura acima mostra à esquerda um grafo acíclico direcionado do modelo UTXO. Cada estado representa um bloco na blockchain. Cada saída de transação compreende a um nó no DAG e cada transação é representada por uma ou mais arestas originadas de uma saída de transação. Portanto, uma saída de transação sem gastos não tem uma aresta originada dela. No exemplo acima, as saídas de transação 3, 5, 6 e 7 não possuem gastos.

À direita, o gráfico mostra uma representação dos diferentes estados no modelo de conta. A cada novo bloco, o estado do sistema é atualizado de acordo com as transações contidas no bloco. O número de contas permanece constante e independente do número de transações realizadas, desde que o número de usuários ou contratos inteligentes permaneça constante.

No modelo UTXO, todo o grafo das saídas da transação, gastas e não gastas, representa o estado global. No modelo de contas, apenas o conjunto atual de contas e seus saldos representam o estado global. No exemplo acima, este é o conjunto de contas A, B e C e seus respectivos saldos.

A diferença conceitual é que o modelo de conta atualiza os saldos dos usuários globalmente. O modelo UTXO registra apenas recebimentos de transações. No modelo UTXO, os saldos das contas são calculados no lado do cliente somando as saídas disponíveis de transações não gastas (UTXOs) .

O Modelo UTXO

O modelo UTXO não incorpora contas ou carteiras no nível do protocolo. O modelo é baseado inteiramente em transações individuais, agrupadas em blocos. Podemos comparar isso com pessoas que detêm certas quantias em dinheiro.

• Um usuário que detém 50 ZEN pode estar no controle de um único UTXO no valor de 50 ZEN ou uma combinação de UTXOs que somam 50 ZEN.
• Comparando com dinheiro, se um usuário tiver US$50, ele pode ter uma única nota de US$50 ou uma combinação de valores menores.

As saídas da transação devem ser gastas como um todo, pois os registros nos blocos anteriores não podem ser editados (reduzidos). Quando uma transação está gastando um UTXO, e o usuário não quer transferir todo o valor dele, o dinheiro em excesso (a diferença entre o tamanho do UTXO e o valor que o usuário está disposto a gastar) é enviado para um endereço como mudança.

• Gastar 10 ZEN de um UTXO no valor de 50 ZEN significa criar duas saídas na transação: uma saída de 10 ZEN para o beneficiário e uma saída de troco de 40 ZEN para o proprietário original.
• Gastar $10 com uma nota de $50 significa entregar seu dinheiro e receber $40 de troco do beneficiário depois.

No entanto, existem duas diferenças cruciais:

• Em um pagamento em dinheiro, você confia na sua contraparte para devolver o troco. No caso do modelo UTXO, o beneficiário nunca está no controle da mudança em primeiro lugar.
• A outra diferença é que o dinheiro existe em denominações discretas. Existem notas de $1, $5, $10 e assim por diante. As saídas de transação no modelo UTXO podem ter valores arbitrários, por exemplo, 11.79327 ZEN.

Como não há conceito de contas ou carteiras no nível do protocolo, o “ônus” de manter o saldo de um usuário é transferido para o lado do cliente. As carteiras mantêm um registro de todos os endereços controlados por um usuário e monitoram a blockchain para todas as transações associadas. A soma de todas as saídas de transações não gastas que ele pode controlar determina o saldo atual.

Transições de estado no modelo UTXO

Cada transação no modelo UTXO pode fazer a transição do sistema para um novo estado, mas a transição para um novo estado com cada transação é inviável. Todos os participantes da rede devem permanecer sincronizados no estado atual. Projetar um mecanismo de consenso que mantenha todos os nós sincronizados torna-se mais difícil, quando as transições de estado ocorrem com mais frequência. Isso se torna intuitivo quando você considera que o intervalo de tempo entre os blocos dá aos nós a chance de baixar o bloco mais recente e processá-lo. Quanto menor o período para os nós atualizarem o estado, maior a chance de atingir um estado inconsistente, onde alguns nós têm uma visão diferente dos eventos passados ​​do que outros. Como resultado, as transações são agrupadas em blocos e cada novo bloco apresenta uma transição de estado do sistema.

No exemplo abaixo, observamos uma transição de estado UTXO com apenas uma única transação hipotética para simplificar.

Suponha que Alice queira transferir 8 ZEN para Bob e ela controle um único UTXO no valor de 10 ZEN. A transação que ela cria consome sua saída de transação UTXO₁ como uma entrada. Para gastar UTXO, ele precisa ser “desbloqueado”.

O Pubkey Script incluído em cada saída de transação define as condições de gastos. Os dados necessários para satisfazer este script são fornecidos com a transação de gastos e incluem a assinatura digital do proprietário - neste caso Alice.

Em seguida, ela define o que deve acontecer com seu dinheiro. Ela faz isso criando saídas de transação. Alice quer transferir oito ZEN para Bob, então ela cria duas saídas: uma pagando a Bob e outra devolvendo o dinheiro em excesso para um endereço autocontrolado. Para ambas as saídas, as condições de gastos também são definidas na transação criada por Alice.

Observe como a soma das saídas não é igual à totalidade da entrada consumida. A diferença entre saídas e entradas é definida como a taxa de transação no nível do protocolo. Neste caso, a taxa de TX é de 0.001 ZEN.

O tamanho da taxa de transação é estimado pela carteira com base na quantidade de dados registrados na cadeia. Os mineradores só podem colocar uma quantidade limitada de dados em um bloco e, usando a métrica 'dinheiro por quantidade de dados', os mineradores podem determinar quais transações incluir no bloco. Eles normalmente escolherão as transações com as taxas mais altas por byte.

O modelo de conta

O modelo de transação baseada em conta representa ativos como saldos dentro de contas, semelhantes às contas bancárias. O Ethereum usa este modelo de transação. Existem dois tipos diferentes de contas:

• contas de usuário controladas por chave privada; e
• contas controladas por código de contrato.

Quando você cria uma carteira Ethereum e recebe sua primeira transação, uma conta controlada por chave privada é adicionada ao estado global e armazenada em todos os nós da rede. O deploy (implantação) de um contrato inteligente leva à criação de uma conta controlada por código. Os contratos inteligentes podem conter fundos próprios, que podem redistribuir de acordo com as condições definidas na lógica do contrato. Cada conta em Ethereum tem um saldo, armazenamento e espaço de código para chamar outras contas ou endereços.

Uma transação no modelo baseado em conta aciona nós para diminuir o saldo da conta do remetente e incrementar o saldo da conta do destinatário. Para evitar ataques de repetição, cada transação no modelo de conta tem um nonce anexado. Um ataque de repetição ocorre quando um beneficiário transmite uma transação fraudulenta na qual é paga uma segunda vez. Se a transação fraudulenta fosse bem-sucedida, a transação seria executada uma segunda vez - ela é repetida - e o remetente seria cobrado duas vezes o valor que desejava transferir.

Para combater esse comportamento, cada conta em Ethereum tem um nonce visível ao público que é incrementado em 1 com cada transação de saída. Isso evita que a mesma transação seja enviada à rede mais de uma vez.

As taxas de transação também funcionam de maneira diferente no modelo de conta: elas são calculadas com base no número de cálculos necessários para concluir a transição de estado. O Ethereum se propôs a ser um computador global. Por isso, eles decidiram que as taxas deveriam ser baseadas no número de recursos computacionais consumidos e não na capacidade de armazenamento utilizada.

O modelo de conta acompanha todos os saldos como um estado global. Este estado pode ser entendido como um banco de dados de todas as contas, chave privada e código de contrato controlados, e seus saldos atuais dos diferentes ativos da rede.

O estado global no modelo UTXO é o conjunto de todas as saídas da transação (segundo gráfico à esquerda). O estado global é sempre o grafo inteiro de UTXOs. O estado no modelo de conta é a lista de contas e seus saldos. Assim, no segundo gráfico, o estado global (n+3) é esta lista de 3 contas (A, B e C) e seus saldos.

A principal diferença se resume ao estado global no modelo UTXO sendo estendido apenas com novos UTXOs, enquanto no modelo de conta, o estado global é atualizado e os saldos mudam.

Transições de estado no modelo de conta

Em um modelo direto, uma transação apresenta um evento que aciona uma transição de estado da blockchain sujeita à lógica de transição de estado. Assim como no modelo UTXO, é inviável fazer a transição do sistema para um novo estado a cada transação sem arriscar um estado inconsistente. As transações também são agrupadas em blocos no modelo de conta e, a cada novo bloco, o sistema passa para um novo estado. Assim como fizemos antes, consideramos um exemplo simples em que uma única transação faz a transição do sistema para um novo estado abaixo.

A configuração é a mesma de antes: Alice quer transferir 8 ZEN para Bob. Sua carteira criará uma transação que define a conta de gastos, a conta de recebimento e o valor a ser transferido. Esta transação é então assinada com a chave privada de Alice. Neste caso, ela está gastando do seu endereço, o destinatário é Bob, e o valor a transferir é 8 ZEN.

Quando o sistema transita para um novo estado (n+1) com o próximo bloco, o saldo da conta de Alice será globalmente reduzido para 2 ZEN, enquanto o saldo de Bob será aumentado para 9 ZEN.

O PubKey- e Signature Scripts não existem em blockchains baseadas em contas. A verificação de assinaturas em blockchain baseada em conta, Ethereum por exemplo, é baseada em três parâmetros, r, s e V fornecidos pelo remetente. Esses três valores compõem a assinatura. Solidity, a linguagem de programação usada pelo Ethereum, fornece um método, ecrecover que retorna um endereço de acordo com esses parâmetros. Se o endereço devolvido corresponder ao endereço do remetente, a assinatura e, em troca, a transação é válida.

Onde no modelo UTXO parte do processo de verificação está verificando se o resultado de transação é não gasto, os nós no modelo de conta verificam se o saldo do remetente é maior ou igual ao valor transferido. Isso vale para o ativo nativo da cadeia, ether, por exemplo, bem como para todos os outros tokens da rede.

Uma transação no modelo baseado em conta é uma instrução sobre como fazer a transição de duas ou mais contas para o próximo estado. A transição real é executada pelos nós. Como o estado final não é especificado na transação, o tamanho da transação resultante é muito menor do que no modelo UTXO.

O estado das contas em Ethereum não é armazenado na blockchain, mas computado e armazenado localmente pelos nós. A blockchain armazena apenas as instruções (leia-se: transações) de como o sistema deve fazer a transição de um estado para outro.

Comparando o UTXO e o Modelo de Conta

Abaixo, compararemos os pontos fortes e fracos do UTXO e do modelo de conta. Começaremos comparando-os em uma visão computacional de alto nível e, em seguida, passaremos para escalabilidade, privacidade, recursos de contrato inteligente e muito mais.

Em suma, o modelo UTXO é um modelo de verificação. Isso significa que os usuários enviam transações que especificam os resultados da transição de estado, definidos como novas saídas de transação que podem ser gastas pelo(s) receptor(es). Os nós verificam então se os insumos consumidos não foram gastos e se a(s) assinatura(s) satisfazem as condições de gasto.

O modelo de conta, por outro lado, é um modelo computacional. Nesse modelo, os usuários enviam transações instruindo os nós sobre como devem ser as transições de estado. A rede então calcula o novo estado com base nas instruções. Esse método vem com implicações específicas em relação a soluções de escalabilidade de segunda camada, como state channels e sharding.

Escalabilidade

Existem várias abordagens que podemos usar para comparar a escalabilidade do UTXO e do modelo de conta. Uma maneira é focar nos requisitos gerais de armazenamento de cada sistema. Outra maneira é considerar qual modelo é mais adequado para a implantação de tecnologias de segunda camada no topo da blockchain principal.

Uma tecnologia de segunda camada, state e payment channels move a troca de dados da blockchain para uma rede dedicada _trustless _ (sem necessidade de confiança) de canais de comunicação bidirecionais.

Outra abordagem que poderia ser chamada de tecnologia de segunda camada é a de sharding. Sharding é um termo originário do mundo de banco de dados tradicional. Ele descreve o particionamento de um banco de dados em vários shards para manter cada partição individual com melhor desempenho, melhorando, por sua vez, todo o sistema. Os sidechains da Horizen podem ser considerados um mecanismo de sharding.

Vamos agora comparar os dois métodos de contabilidade e assumir que ambos os sistemas têm contagens de usuários e transações semelhantes.

Tamanho do Blockchain

O modelo de conta tem mais eficiência no uso de memória. Armazenar um único saldo de conta economiza memória em comparação com o armazenamento de vários UTXOs que compõem o saldo total de um usuário. As transações no modelo de conta também são menores em tamanho porque especificam apenas o remetente, o destinatário, o valor da transferência e uma única assinatura digital. Além disso, apenas eliminando as saídas referente aos trocos, muitos dados podem ser salvos no modelo de conta.

Em um nível conceitual, isso é intuitivo. Como uma transação UTXO especifica o estado após a transição (as saídas de transação recém-geradas), ele precisa incluir mais dados do que uma transação de conta. Também pode consumir vários UTXOs como entradas, enquanto a transação de conta especifica apenas qual quantidade deve ser deduzida de um saldo de conta. Para se ter uma ideia, o modelo de conta do Ethereum usa cerca de 100 bytes, enquanto uma transação UTXO no Horizen leva usa de 200-300 bytes.

Isso também significa que é mais rápido colocar novos nós online em um sistema que executa o modelo de conta porque são necessários menos dados para sincronizá-los. O número de contas geralmente será muito menor do que o total de UTXO definido em um sistema de tamanho comparável.

Construções de State- & Payment Channel

Atualmente, a construção mais avançada de canal de pagamento é a_ Lightning Network_ no Bitcoin. Ela usa um mecanismo de prova de envio e verificação à medida que os ativos entram e saem da segunda camada. Como mencionado acima, o modelo UTXO é essencialmente um modelo de verificação, enquanto o modelo de conta é um modelo computacional. Portanto, uma construção UTXO é mais adequada para esses tipos de abordagens de escalabilidade.

Sharding

Particionar uma blockchain em shards ou sidechains também é mais fácil ao usar o modelo UTXO. A agregação de saídas de transações passíveis de consumo e a definição das saídas acontecem no lado do cliente, reduzindo o estresse geral do sistema. No modelo de conta, cada nó precisa localizar a conta do remetente e do destinatário em diferentes fragmentos e editar ambos.

É claro que há mais sobre sharding do que essas mudanças bastante diretas, e usar um modelo de equilíbrio sobre o outro vem com efeitos de segunda e terceira ordem. Geralmente, o modelo UTXO permite o particionamento da estrutura de dados de forma mais simples.

Privacidade

Quando se trata de privacidade, há méritos tanto no UTXO quanto no modelo de conta. O modelo UTXO dificulta a vinculação de transações, enquanto o modelo de conta oferece melhor fungibilidade.

Quando mudanças de endereços são consequentemente usadas ​​no modelo UTXO, isso dificulta o rastreamento da propriedade de moedas em comparação com o modelo de conta. Um endereço recém-gerado não tem um proprietário conhecido e exige uma análise avançada da cadeia para vinculá-lo a um único usuário. O modelo de conta incentiva implicitamente a reutilização de endereços e, portanto, facilita a criação de um histórico de transações para um único usuário.

Com relação à fungibilidade, o modelo de conta oferece melhor privacidade. Há total transparência dos movimentos de UTXO (leia-se ativos) no modelo UTXO quando nenhuma técnica de preservação de privacidade é aplicada. No entanto, o modelo de conta vem com um tipo de “misturador de moedas” (coin mixer) embutido. Quando uma conta é financiada com várias transações, o resultado é um saldo único. Quando um pagamento dessa conta é feito, um observador não pode determinar qual das moedas recebidas está sendo gasta. Considere o exemplo do modelo de conta acima, onde Alice envia 8 ZEN para Bob e seu saldo é atualizado para 9 ZEN. Quando Bob subsequentemente gasta 1 ZEN, ninguém pode determinar se o único ZEN deriva de Alice ou de uma fonte diferente. Esta é uma visão muito simplificada. Mesmo quando os ativos não podem ser atribuídos de forma confiável a uma transação de financiamento, as ferramentas analíticas podem determinar se as moedas estão contaminadas, mas a ideia geral permanece.

Recursos de contrato inteligente

O modelo de conta oferece vantagens claras quando se trata de habilitar contratos inteligentes.

Primeiro, a lógica do modelo de conta é mais intuitiva. Adicionar e subtrair saldos torna mais fácil para os desenvolvedores criarem transações que exigem informações de estado ou envolvem várias partes. Uma transação assinada é válida desde que a conta de envio tenha saldo suficiente para pagar a execução. Verificar um saldo é computacionalmente mais barato do que verificar se uma saída de transação foi gasta ou não. Isso é especialmente verdadeiro para contas controladas por código que interagem com outros contratos inteligentes. As transações internas entre contratos podem ser realizadas em uma máquina virtual ajustando os saldos dos contratos. O modelo UTXO cria sobrecarga computacional porque todas as transações de gastos devem ser registradas explicitamente.

Contratos inteligentes em um modelo UTXO precisariam incluir lógica para escolher quais saídas usar ao enviar ativos e lógica para lidar com saídas de trocos. Como o modelo UTXO é inerentemente sem estado, ele força as transações a incluírem informações de estado, complicando o design geral.

Outras Diferenças

Um benefício do modelo UTXO é que ele permite de forma mais simples a paralelização de transações em contratos inteligentes. Vários UTXOs usados ​​em diferentes transações podem ser processados ​​ao mesmo tempo, pois todos se referem a entradas independentes.

No modelo de conta, o resultado de uma transação depende do estado de entrada. A execução de transações em paralelo deve ser tratada com cuidado. Geralmente, as transações que afetam a mesma conta devem ser executadas sequencialmente.

Uma conclusão importante é que o modelo UTXO é melhor ao lidar com transações simples. O modelo de conta é benéfico ao lidar com lógica mais complexa. Portanto, uma tendência popular nas atuais plataformas de contratos inteligentes é usar um modelo híbrido em que o modelo UTXO é usado para saldos e o modelo de conta é usado para contratos inteligentes.

Sistemas Híbridos

QTUM é um exemplo de blockchain que utiliza um sistema híbrido de UTXOs e contas.

“No início, quando o Qtum estava sendo projetado, o processo de pensamento era construir uma blockchain pronta para os negócios e que fosse versátil e segura. Para realizar essas motivações, a Qtum escolheu o modelo UTXO (Unspent Transaction Output), utilizado pelo Bitcoin, mas construído sobre o modelo de contas em que as blockchains do estilo Ethereum são construídas. ” - Dev Bharel

O modelo UTXO foi usado como base para a arquitetura geral porque foi considerado “significativamente mais seguro” no momento da concepção. Além dessa camada UTXO, o QTUM permite “criar e executar contratos inteligentes usando o modelo de conta oferecido pela Ethereum” por meio de uma construção que eles chamam de Account Abstraction Layer (AAL)

A AAL combina UTXOs para um determinado contrato em uma nova transação assim que há dois ou mais deles disponíveis para o código do contrato. Ao usar o modelo UTXO como camada base, o QTUM também é capaz de implementar o protocolo Proof of Stake da BlackCoin, que requer provas paralelas e atividade UTXO.

Resumo

Para finalizar, vamos recapitular o que abordamos. Começamos apontando as semelhanças entre o UTXO e o modelo de conta. A blockchain pode ser considerada uma máquina de estado independente do esquema de contabilidade utilizado. Em ambos os casos, as transações acionam transições de estado em lotes - com cada novo bloco adicionado à blockchain.

No modelo UTXO, a movimentação dos ativos é registrada na forma de um grafo acíclico direcionado feito de saídas de transações. Novas saídas são adicionadas a cada bloco adicional. No modelo de contas, os saldos são armazenados como um estado global de contas, mantido por cada nó e atualizado a cada bloco. Isso é semelhante a um banco de dados.

As transações no modelo UTXO são maiores em tamanho e sobrecarregam mais o usuário e sua carteira. O modelo UTXO é um modelo de verificação, enquanto o modelo de conta é um modelo computacional.

Os sistemas baseados em contas oferecem benefícios de armazenamento porque o estado e as transações da conta são menores. O UTXO é mais eficiente na simplificação de soluções de dimensionamento, como construções de state e_ payment channels_, bem como um sharding.

Ambos os modelos têm prós e contras em relação à privacidade. Por exemplo, o modelo de conta facilita a vinculação de transações a um único usuário, mas também oferece um maior grau de fungibilidade.

O modelo de conta oferece vantagens claras em relação aos contratos inteligentes. Muitas novas plataformas de contratos inteligentes usam modelos híbridos em que UTXOs são usados ​​para saldos e contas são usadas para os contratos.

No final, depende do caso de uso, qual modelo é mais adequado para o trabalho. Você pode encaixar a maioria dos aplicativos em um ou outro modelo de saldo. A questão é se você deve fazer isso e por que você gostaria de fazer isso em primeiro lugar. Como não poderíamos expressar melhor, queremos terminar este artigo com uma citação:

“Dentro das plataformas de criptomoeda, há um conjunto diversificado de conceitos de design e mecanismos técnicos que entram na plataforma sendo capazes de funcionar como um sistema viável, seguro e utilizável. Os modelos de transação usados ​​por essas plataformas empregam o uso de criptografia para verificar a propriedade dos tokens na rede. O esquema UTXO funciona soberbamente para o Bitcoin, enquanto o modelo baseado em contas usado no Ethereum é voltado para suportar suas necessidades mais complexas de aplicativos e contratos.” - Brian Curran