Gasto duplo

Origem: Wikipédia, a enciclopédia livre.

Gasto duplo é uma possível causa de falha de sistemas de criptomoedas. O gasto duplo acontece quando um usuário consegue gastar as mesmas moedas digitais mais de uma vez. Diferentemente de moedas físicas, arquivos digitais podem ser duplicados, logo, o ato de gastar uma moeda digital não implica uma transferência de posse da mesma para outrem.[1] Portanto, é necessário que outros meios sejam utilizados para prevenção contra o gasto duplo.

Descrição[editar | editar código-fonte]

Gasto duplo em um sistema simples de criptomoedas. Alice transfere uma mesma moeda tanto para Bob como a Carl. O subscrito cp representa uma chave pública.

O gasto duplo acontece quando uma mesma moeda é utilizada mais de uma vez em diferentes transações em um dado sistema de criptomoedas. O problema de gasto duplo pode ser visualizado em um sistema simples de moedas digitais, que segue apenas os conceitos básicos de um sistema de tal porte.

Dado que as regras de um sistema sejam as seguintes:

  • Qualquer pessoa que possua uma moeda pode repassá-la para outrem assinando uma declaração que confirma que a moeda em questão deve ser transferida para uma chave pública K.
  • Novas moedas podem ser criadas por alguma entidade a partir da assinatura de uma declaração de que uma nova moeda está sendo criada com um número de identificação único.
  • Qualquer pessoa pode conferir se uma moeda é válida apenas seguindo a sequência de ponteiros hash de cada transação até o momento de criação da moeda em questão, verificando a validade de todas as assinaturas envolvidas durante o percurso.

A situação de gasto duplo pode ocorrer quando, por exemplo, uma certa usuária Alice tentar transferir uma moeda para outro usuário Bob, mas não informar nenhum outro usuário do sistema sobre essa transação. Alice, portanto, pode criar outra transação com a mesma moeda para outro usuário Carl e esta ainda será válida sob as regras do sistema. Isso faz com que ambos os usuários recipientes da moeda de Alice possuam uma mesma moeda, que foi gasta duas vezes pela mesma pessoa.

Prevenção[editar | editar código-fonte]

As abordagens utilizadas para prevenir o problema de gasto duplo dividem-se em abordagens centralizadas e descentralizadas.

Centralização[editar | editar código-fonte]

A prevenção do gasto duplo feita por meio de uma centralização é geralmente realizada a partir da presença de uma entidade à parte, de autoridade máxima, que segue certas regras de negócio para autorizar as transações realizadas no sistema, verificando se as moedas em questão foram gastas.[1] Essa abordagem apresenta alguns problemas, tais como o fato de haver um ponto único de falha no sistema, tanto do ponto de vista técnico como do ponto de vista de confiança. Isto é:

  1. Um erro de funcionamento na entidade autoritária pode fazer com que todas as transações do sistema não sejam processadas enquanto a entidade não tiver seus serviços normalizados.
  2. Todos os participantes do sistema devem ter total confiança na corretude da entidade central no processamento das transações.

Descentralização[editar | editar código-fonte]

Abordagens descentralizadas abrem mão de uma autoridade central em troca de um protocolo distribuído específico para lidar com as tentativas de gasto duplo. Por volta do ano 2007, diversos sistemas distribuídos feitos para tratar tentativas de gasto duplo haviam sido propostos.[2][3]

Como não há uma autoridade central envolvida nessas abordagens, o problema de ponto único de falha é descartado, dando maior confiança no sistema.

Aos algoritmos mais conhecidos de consenso pertencem: prova de trabalho (PoW), prova de participação (PoS) e prova de autoridade (PoA). [4]

  • PoW. O algoritmo PoW foi oferecido em 1993. Os autores ofereceram a seguinte ideia: para ter acesso ao recurso geral o usuário deve calcular uma certa função que é bastante complicada e que consume muitos recursos, mas com isso resolvida durante um tempo aceitável.[5] O cálculo de função ao lado de cliente deve ser bastante mais complicado que a verificação de resultado ao lado de servidor. Em 2004 Hal Finney ofereceu usar a prova múltipla de execução de trabalho (inglês Reusable-Proofs-of-Work, RPOW, RPoW) para organizar a moeda eletrônica.[6] A particularidade principal dos cálculos aplicados consiste em asimetria dos gastos de tempo, estes são significantes para encontrar a decisão, e são bastante poucos para verificação. Por isso as criptoredes que usam PoW são vulneráveis ao ataque a 51%.[7]
  • PoS. Por primeira vez a ideia de PoS foi oferecida no foro “Bitcointalk” em 2011. A primeira realização de protocolo PoS foi apresentada em 2012 em criptomoeda PPCoin (na atualidade PeerCoin).[8] Em vez de capacidades de cômputo dos participantes, o valor o tem o número de criptomoeda que fica em sua conta. Assim a probabilidade de formação pelo participante de seguinte bloco em blockchain é proporcional à porção formada pelas unidades de cálculo desta criptomoeda com respeito a sua quantidade total que pertence a este participante. .[9] O algoritmo empurra até acumulação dos fundos em umas mãos, o que pode levar à centralização da rede.
  • PoA. Nas redes sobre base de PoA as transações e os blocos são verificados pelas contas aprovadas conhecidas como validadores.[10] O sistema Finney tem usado PoW Hashcash para cunhagem de novos tokens. No entanto, o sistema de proteção contra o gasto duplo era devido ao servidor centralizado.

Gasto duplo em Bitcoin[editar | editar código-fonte]

Exemplo de uma tentativa de gasto duplo em Bitcoin. 6 confirmações geralmente são esperadas.

A criptomoeda Bitcoin implementa uma solução descentralizada para lidar com tentativas de gasto duplo no seu sistema. Essa solução é possível devido à resolução de um famoso problema da criptografia denominado Problema dos Generais Bizantinos, publicada em 2009 no também famoso white paper de Satoshi Nakamoto.[11]

Bitcoin utiliza um esquema chamado Prova de Trabalho, que abre mão de uma autoridade central para manter um histórico das transações realizadas. Os diversos nós participantes no sistema seguem um mesmo protocolo e, para validar transações, trabalham em um consenso. As transações são gravadas em uma base de dados pública chamada block chain.

Devido ao protocolo de consenso, a probabilidade de uma transação de gasto duplo ser aceita diminui exponencialmente a cada confirmação que uma transação recebe, devido ao fato da maior parte dos nós participantes serem honestos. Geralmente, 6 confirmações apresentam um bom equilíbrio entre o tempo gasto esperando pela aceitação de uma transação e a confiança que se pode ter de que a transação em questão é válida.[12]

Ainda assim, Bitcoin ainda tem certa exposição a situações de gasto duplo, principalmente quando transações são aceitas com 0 confirmações.[13] Um dos possíveis ataques de gasto duplo é chamado de ataque de corrida. Ele pode acontecer quando vendedores aceitam um pagamento imediatamente (0 confirmações), pagamento este que foi uma tentativa de gasto duplo com o outro gasto (transação) sendo comunicado para outro participante. Caso a segunda transação mencionada for a primeira a ser aceita na block chain, o vendedor torna-se uma vítima da fraude. Os vendedores, porém, podem tomar precauções para diminuir o risco de um ataque de corrida, mas este risco não pode ser totalmente eliminado se transações continuarem sendo aceitas com 0 confirmações. Por causa disso, aceitar transações não-confirmadas deve ser ponderado pelo vendedor. Algumas recomendações para prevenir/evitar esse tipo de ataque já foram publicadas em meios científicos.[14]

Gasto duplo em Ripple[editar | editar código-fonte]

Ripple, ou protocolo de transações Ripple, é um sistema de trocas e negociações monetárias, construído sobre um protocolo de código aberto para a Internet, um registro de consenso e uma moeda nativa chamada XRP (ripples).[15][16] O principal objetivo do sistema é proporcionar pagamentos internacionais de qualquer quantia que sejam seguros, instantâneos e de baixo custo.

Um gasto duplo em Ripple representa um grande problema, visto que, por exemplo, um vendedor pode irreversivelmente entregar um produto a um comprador, confiando em uma certa transação, e podem acabar nunca recebendo o pagamento prometido caso a transação avaliada seja descartada como um gasto duplo. Similarmente a Bitcoin, Ripple utiliza um protocolo de consenso para lidar com tentativas de gasto duplo em seu sistema. É importante notar que as confirmações de transações em Ripple são irreversíveis.[17] Uma causa possível de um gasto duplo seria um bug no sistema, porém com a maturação do sistema a probabilidade de ocorrer um bug decresce devido a testes contínuos, fiscalização do código fonte e conserto de bugs.[17]

Um gasto duplo também poderia ocorrer quando uma transação passa com sucesso pela lógica de confirmação do servidor mas é em seguida invalidada. A lógica de confirmação de transações do servidor confirma transações quando elas aparecem em registros que foram confirmados pela lógica de confirmação de registros do servidor, logo, nesse caso, um gasto duplo precisaria convencer o servidor a aceitar totalmente um registro que, logo em seguida, sumiria da sequência de registros pública.

Essa lógica de confirmação total de um registro acontece em duas etapas: Primeiramente, o registro precisa ser tido como o resultado do processo de consenso da rede, isto é, a maior parte dos validadores confiáveis e operantes na rede devem concordar que o registro é de fato válido. Em seguida, a maior parte dos validadores na lista de confiança do servidor devem certificar que eles notaram que, majoritariamente, os validadores confiados por estes também observaram o mesmo processo de consenso pelo qual o registro em questão passou e também concordaram na validade desse registro. Nota-se uma lógica inerentemente complexa para validar registros.

Para prevenir-se contra gastos duplos, Ripple cria barreiras tanto a nível de rede como a nível de servidores individuais:

  • Servidores individuais protegem-se contra gastos duplos a partir da seleção de validadores que não tendem a discordar.
  • A rede Ripple como um todo protege-se contra gastos duplos a partir da manutenção de um conjunto diverso de validadores operados por indivíduos, organizações e negócios notáveis e de boa reputação. Essa proteção cresce proporcionalmente ao crescimento da rede Ripple.

Em última instância, caso algum participante do sistema fosse vítima de um gasto duplo, todos na rede teriam provas criptográficas que esse gasto duplo de fato aconteceu e saberiam que validadores/operadores quebraram a confiança dada a eles. Portanto, a própria ocorrência de um gasto duplo ajudaria na prevenção futura contra demais gastos duplos, visto que os elementos envolvidos poderiam ser facilmente identificados e possivelmente punidos.

Uma descrição técnica aprofundada do algoritmo de consenso utilizado pelo Ripple pode ser encontrada no white paper disponível publicamente no site da empresa.[18] É importante notar que diversos dos ataques de gasto duplo listados para Bitcoin também são ataques com os quais Ripple precisa lidar.[13]

Gasto duplo em outros serviços[editar | editar código-fonte]

O serviço Ethereum, que é tanto uma plataforma de criptomoedas como um framework Turing-completo que permite que pessoas administrem seus próprios smart contracts sem a intervenção de uma autoridade central, utiliza o algoritmo de prova de trabalho Ethash.[19] A partir desse algoritmo e o ajuste dinâmico da dificuldade das soluções de prova de trabalho para que um bloco seja produzido aproximadamente a cada 12 segundos na rede, Ethereum garante que manter uma bifurcação dos blocos na rede para permitir tentativas de gasto duplo é impossível a não ser que o atacante possua mais da metade de todo o poder de mineração da rede para si (um chamado ataque de 51%).[20] Já se discutiu também a possível aplicação de um algoritmo de prova de participação no sistema, em detrimento de um algoritmo de prova de trabalho, para tratar tentativas de gasto duplo e critérios de mineração em geral.[21]

Blockcypher, um serviço de navegação em Blockchains, utiliza um algoritmo de fator de confiança para tentar prever a probabilidade de uma transação sofrer uma tentativa de gasto duplo. Esse resultado é adicionado como um atributo de confiança a qualquer transação com 0 confirmações no serviço.[22] Por exemplo: caso o fator de confiança associado a uma certa transação for de 99,9%, o sistema prevê que há uma chance de 0.01% de que uma tentativa de gasto duplo seja bem sucedida. Esse cálculo do fator de confiança se baseia em aspectos das transações que podem ser divididos em duas categorias: Formato da transação e comportamento da transação. O formato da transação se refere aos aspectos da mesma que não variam com o tempo, enquanto o comportamento da transação se refere aos aspectos da transação que variam com o tempo. Sobre o formato diversos questionamentos são feitos, tais como questionamentos sobre a estrutura da transação, quais são as entradas e saídas e o tipo de assinatura. Já em relação ao comportamento, analisa-se como uma transação é propagada pela rede. É necessária uma grande quantidade de dados para se obter boas estimativas do comportamento de uma transação.

Ver também[editar | editar código-fonte]

Referências[editar | editar código-fonte]

  1. a b Mark Ryan. «Digital Cash». School of Computer Science, University of Birmingham. Consultado em 6 de dezembro de 2015 
  2. Jaap-Henk Hoepman (2008). «Distributed Double Spending Prevention». arXiv:0802.0832v1Acessível livremente [cs.CR] 
  3. Osipkov, I.; Vasserman, E. Y.; Hopper, N.; Kim, Y. (2007). «Combating Double-Spending Using Cooperative P2P Systems». 41 páginas. doi:10.1109/ICDCS.2007.91 
  4. «Episodio 5: La Web 3.0, el doble gasto y los generales bizantinos». Market Screener 
  5. «What is proof-of-work?». johndcook.com. Consultado em 18 de abril de 2022 
  6. «Consensus 101: What is Proof-of-Authority Consensus Algorithm?». kucoin.com. Consultado em 18 de abril de 2022 
  7. «Double-Spending». investopedia.com. Consultado em 18 de abril de 2022 
  8. «The Evolution of Proof of Stake – From Peercoin and Nxt to Algorand». bitcoinist.com. Consultado em 18 de abril de 2022 
  9. «What is double-spending?». Consultado em 22 de abril de 2022 
  10. «Proof of authority (PoA)». tokens-economy.gitbook.io. Consultado em 18 de abril de 2022 
  11. Nakamoto, Satoshi (24 de maio de 2009). «Bitcoin: A Peer-to-Peer Electronic Cash System» (PDF). Consultado em 7 de dezembro de 2015 
  12. «Confirmation». Consultado em 6 de dezembro de 2015 
  13. a b «Double Spending». Consultado em 6 de dezembro de 2015 
  14. Karame, G.O.; Androulaki, E.; Capkun, S. (2012). «Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin» (PDF) 
  15. «Ripple». Consultado em 7 de dezembro de 2015 
  16. Britto, Arthur. «The Ripple Ledger Consensus Process». ripple.com. Consultado em 9 de maio de 2015 
  17. a b «Ripple FAQ». Consultado em 7 de dezembro de 2015 
  18. Schwartz, D.; Youngs, N.; Britto, A. (2014). «The Ripple Protocol Consensus Algorithm» (PDF) 
  19. «Ethash». Consultado em 8 de dezembro de 2015 
  20. «Ethereum Frontier Guide - Mining». Consultado em 8 de dezembro de 2015 
  21. Buterin, Vitalik (15 de janeiro de 2014). «Slasher: A Punitive Proof-of-Stake Algorithm». blog.ethereum.org. Consultado em 8 de dezembro de 2015 
  22. «BlockCypher - Confidence factor». Consultado em 8 de dezembro de 2015