Conteúdo
O que é double-spending?
Double-spending (gastos duplos) é um problema que pode ocorrer em um sistema de dinheiro digital em que os mesmos fundos são gastos duas vezes, ou seja, são enviados para dois destinatários ao mesmo tempo. Se um protocolo não utilizar contramedidas adequadas para resolver o problema, ele estará comprometido – os usuários não têm como verificar se os fundos que receberam já foram gastos ou não.
Quando se trata de dinheiro digital, é extremamente importante garantir que unidades específicas não possam ser duplicadas. Todo o sistema seria comprometido se Alice pudesse receber 10 unidades, copiá-las e colá-las 10 vezes e ter posse de 100 unidades. Da mesma forma, esse esquema não pode funcionar se Alice puder enviar as mesmas 10 unidades para Bob e Carol simultaneamente. Portanto, para que o sistema de dinheiro digital funcione, o uso de mecanismos para impedir esse comportamento é necessário.
Como o double-spending pode ser prevenido?
Abordagem centralizada
A implementação em um sistema centralizado é consideravelmente mais fácil do que em alternativas descentralizadas. Isso geralmente envolve um supervisor que gerencia o sistema e controla a emissão e distribuição de unidades. Um bom exemplo de solução centralizada para o problema do double-spending é a de David Chaum, para a eCash.
Nesse contexto, se o usuário Dan deseja receber $100 em dinheiro digital, ele é obrigado a informar o banco primeiro. Caso ele tenha saldo em sua conta, ele irá gerar um número aleatório (ou muitos, para denominações menores). Vamos supor que ele produz cinco números, cada um com um valor de $20. Para impedir que o banco rastreie unidades específicas, Dan ofusca os números aleatórios adicionando um blinding factor (fator de ocultação) a cada um deles.
Ele então entrega esses dados ao banco, que debita $100 de sua conta e assina mensagens certificando que cada uma das cinco informações possui um valor de resgate de $20. Dan agora pode gastar os fundos emitidos pelo banco. Ele vai até o restaurante de Erin e compra uma refeição que custa $40.
Agora Dan pode remover o blinding factor e expor o número aleatório associado a cada ”nota” de dinheiro digital, que serve como um identificador exclusivo para cada unidade (como um número de série). Ele revela dois deles para Erin, que deve resgatá-los imediatamente com o banco para impedir que Dan gaste os mesmo $40 com outra compra. O banco irá verificar se as assinaturas são válidas e, se tudo estiver correto, irá enviar $40 para a conta de Erin.
As duas "notas" usadas foram basicamente queimadas e agora será necessário emitir mais notas se Erin quiser gastar o saldo que recebeu.
A configuração de Chaum para a eCash pode ser valiosa para transferências privadas. Porém, ela apresenta falhas na resiliência pois o banco é um ponto central de falha. Uma nota digital emitida, em si, não tem valor, pois seu valor é derivado da vontade do banco ou do vendedor de trocá-la por dólares. Os clientes estão à mercê do banco e devem confiar em sua boa vontade para que o sistema de dinheiro funcione. Este é, precisamente, o problema que a criptomoeda pretende solucionar.
Abordagem descentralizada
Em um ecossistema sem supervisão, garantir que os fundos não possam ser gastos duas vezes é uma tarefa mais difícil. Os participantes, que detêm o mesmo poder, devem se coordenar em torno de um conjunto de regras que evitem fraudes e incentivem todos os usuários a agir honestamente.
Considere novamente o cenário do restaurante. Dan retorna ao restaurante e dessa vez nota um adesivo na janela escrito "Aceitamos Bitcoin". Ele gostou da última refeição que fez, então a pede novamente. O preço é de 0,005 BTC.
Conforme mencionado, a transação só é válida se for inserida em um bloco que é confirmado. Aceitar transações não confirmadas é como aceitar os $40 em eCash do exemplo anterior, sem descontar o valor imediatamente com o banco – permitindo que o valor seja gasto em outro lugar. Portanto, é recomendável que Erin aguarde pelo menos 6 confirmações de bloco (aproximadamente uma hora) antes de aceitar o pagamento de Dan.
Double-spending na Bitcoin
A Bitcoin é cuidadosamente projetada para evitar tentativas de double-spending, pelo menos quando o protocolo é usado conforme o esperado. Ou seja, se os indivíduos esperarem que as transações sejam confirmadas em um bloco, não existe uma maneira simples para que o remetente reverta o envio. Para isso, ele precisaria “reverter” toda a blockchain, o que requer uma quantidade absurda de hashing power (poder computacional).
No entanto, existem vários ataques de double-spending direcionados às partes que aceitam transações não confirmadas. Para compras de baixo valor, por exemplo, um comerciante pode não querer esperar que as transações sejam incluídas em um bloco. Um restaurante fast-food muito ocupado provavelmente não pode ficar aguardando enquanto a rede processa todas as compras. Portanto, se uma empresa aceita esses pagamentos “instantâneos”, ela se torna vulnerável a tentativas de double-spending. Alguém pode pedir um lanche, pagar por ele e depois enviar imediatamente os mesmos fundos para seu próprio endereço. Tendo uma taxa mais alta, é provável que essa nova transação seja confirmada primeiro e, portanto, invalidará a transação anterior destinada ao pagamento do lanche.
Existem três métodos populares para efetuar um golpe de double-spending:
- 51% attacks: quando uma única entidade ou organização consegue controlar mais de 50% da taxa de hash, o que permite excluir ou modificar a ordem das transações. Esse tipo de ataque é muito improvável no sistema da Bitcoin, mas já aconteceu em outras redes.
- Race attacks: duas transações em conflito são transmitidas em sucessão, usando os mesmos fundos – mas apenas uma transação é confirmada. O objetivo do invasor é invalidar o pagamento, validando apenas a transação que o beneficia (por exemplo, enviar os mesmos fundos para um endereço que ele controla). Os Race attacks exigem que o destinatário aceite uma transação não confirmada como pagamento.
- Finney attacks: o invasor previamente minera uma transação em um bloco, sem transmiti-la imediatamente para a rede. Em vez disso, ele gasta as mesmas moedas em outra transação e só então transmite o bloco minerado anteriormente, o que pode invalidar o pagamento. Os Finney Attacks exigem que uma sequência específica de eventos ocorra e também dependem da aceitação (do destinatário) de transações não confirmadas.
Como podemos ver, um comerciante que aguarda as confirmações de bloco, reduzirá drasticamente os riscos relacionados a tentativas de double-spending.
Considerações finais
O double-spending permite que um usuário engane um sistema de pagamento eletrônico para obter ganhos financeiros, usando os mesmos fundos mais de uma vez. A falta de soluções adequadas para este problema tem dificultado o progresso na área.