Ver código fonte para Gasto duplo

'''Gasto duplo''' é uma possível causa de falha de sistemas de [[criptomoeda]]s. 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.<ref name="Ryan">{{citar web|url=http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html|título=Digital Cash|autor =Mark Ryan|publicado=School of Computer Science, University of Birmingham|acessodata=2015-12-06}}</ref> Portanto, é necessário que outros meios sejam utilizados para prevenção contra o gasto duplo.

==Descrição==
[[Imagem:Gasto Duplo.png|thumb|direita|Gasto duplo em um sistema simples de criptomoedas. Alice transfere uma mesma moeda tanto para Bob como a Carl. O subscrito <sub>cp</sub> 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 [[criptomoeda]]s. 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 (criptografia)|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 [[Ponteiro (programação)|ponteiros]] [[Função hash|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==
As abordagens utilizadas para prevenir o problema de gasto duplo dividem-se em abordagens centralizadas e descentralizadas.

===Centralização===
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.<ref name="Ryan" /> 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 é:

# 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.
# Todos os participantes do sistema devem ter total confiança na corretude da entidade central no processamento das transações.

===Descentralização===
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.<ref name="prop2007" /><ref name="prop2008" />

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). <ref>{{Citar web|title= Episodio 5: La Web 3.0, el doble gasto y los generales bizantinos|url=https://es.marketscreener.com/noticias/ultimas/Episodio-5-La-Web-3-0-el-doble-gasto-y-los-generales-bizantinos--37520809/|work=Market Screener}}</ref>

* '''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.<ref>{{Citar web|title=What is proof-of-work?|url=https://www.johndcook.com/blog/2018/11/11/proof-of-work/|acessodata=18 de abril de 2022|work=johndcook.com}}</ref> 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.<ref>{{Citar web|title=Consensus 101: What is Proof-of-Authority Consensus Algorithm?|url=https://www.kucoin.com/pt/blog/what-is-proof-of-authority-consensus-algorithm|acessodata=18 de abril de 2022|work=kucoin.com}}</ref> 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%.<ref>{{Citar web|title=Double-Spending|url=https://www.investopedia.com/terms/d/doublespending.asp|acessodata=18 de abril de 2022|work=investopedia.com}}</ref>
* '''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|PeerCoin]]).<ref>{{Citar web|title=The Evolution of Proof of Stake – From Peercoin and Nxt to Algorand|url=https://bitcoinist.com/the-evolution-of-proof-of-stake-from-peercoin-and-nxt-to-algorand/|acessodata=18 de abril de 2022|work=bitcoinist.com}}</ref> 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. .<ref>{{Citar web|title=What is double-spending?|url=https://urbankenyans.com/what-is-double-spending/|acessodata=22 de abril de 2022}}</ref> 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.<ref>{{Citar web|title=Proof of authority (PoA)|url=https://tokens-economy.gitbook.io/consensus/chain-based-hybrid-models/proof-of-authority-poa|acessodata=18 de abril de 2022|work=tokens-economy.gitbook.io}}</ref> 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==
[[Imagem:Gasto Duplo Block Chain.png|thumb|direita|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]].<ref name="whitepaper" />

[[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.<ref name="Confirmation">{{citar web|url=https://en.bitcoin.it/wiki/Confirmation|título=Confirmation|acessodata=2015-12-06}}</ref>

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.<ref name="Double">{{citar web|url=https://en.bitcoin.it/wiki/Double-spending|título=Double Spending|acessodata=2015-12-06}}</ref> 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.<ref name="twoforone" />

==Gasto duplo em Ripple==
[[:en:Ripple (payment protocol)|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).<ref name="Ripple" /><ref name="RippleCon" /> 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.<ref name="DRipple" /> 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|código fonte]] e conserto de bugs.<ref name="DRipple" />

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.<ref name="WhiteRipple" /> É importante notar que diversos dos ataques de gasto duplo listados para Bitcoin também são ataques com os quais Ripple precisa lidar.<ref name="Double" />

==Gasto duplo em outros serviços==
O serviço [[:en:Ethereum|Ethereum]], que é tanto uma plataforma de criptomoedas como um [[framework]] Turing-completo que permite que pessoas administrem seus próprios [[:en:Smart contract|smart contracts]] sem a intervenção de uma autoridade central, utiliza o algoritmo de prova de trabalho Ethash.<ref name="Ethash" /> 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%).<ref name="Ethereum" /> 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.<ref name="Slasher" />

Blockcypher, um serviço de navegação em [[:en:Block chain (database)|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.<ref name="Confidence" /> 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==
* [[Prova de trabalho]]
* [[Prova de participação]]
* [[Assinatura digital]]
* [[:en:Blind signature|Assinatura Digital Cega]] {{en}}

==Referências==
{{reflist|30em|refs=

<ref name=prop2007>{{citar arXiv|eprint=0802.0832v1|autor1 =Jaap-Henk Hoepman|título=Distributed Double Spending Prevention|class=cs.CR|ano=2008}}</ref>

<ref name=prop2008>{{citar periódico
| doi = 10.1109/ICDCS.2007.91
|título= Combating Double-Spending Using Cooperative P2P Systems
|ano= 2007
|último1 = Osipkov |primeiro1 = I.
|último2 = Vasserman |primeiro2 = E. Y.
|último3 = Hopper |primeiro3 = N.
|último4 = Kim |primeiro4 = Y.
|páginas= 41
}}</ref>

<ref name="whitepaper">{{citar web |último = Nakamoto |primeiro = Satoshi |título= Bitcoin: A Peer-to-Peer Electronic Cash System |url= http://bitcoin.org/bitcoin.pdf |acessodata= 07/12/2015 |data= 24/05/2009}}</ref>

<ref name="twoforone">{{citar periódico
|título= Two Bitcoins at the Price of One? Double-Spending Attacks on Fast Payments in Bitcoin
|ano= 2012
|último1 = Karame |primeiro1 = G.O.
|último2 = Androulaki |primeiro2 = E.
|último3 = Capkun |primeiro3 = S.
| url=http://eprint.iacr.org/2012/248.pdf
}}</ref>
<ref name="Ripple">{{citar web|título=Ripple|url=https://ripple.com/|acessodata=07/12/2015}}</ref>

<ref name="RippleCon">
{{citar notícia
|título=The Ripple Ledger Consensus Process
|primeiro =Arthur
|último =Britto
| url         =https://ripple.com/knowledge_center/the-ripple-ledger-consensus-process/
|jornal=ripple.com
|data= 
|acessodata= 09/05/2015
}}</ref>

<ref name="DRipple">{{citar web|título=Ripple FAQ|url=https://wiki.ripple.com/FAQ#What_is_required_for_a_double_spend_to_happen.3F|acessdate=07/12/2015}}</ref>

<ref name="WhiteRipple">{{citar periódico
|título= The Ripple Protocol Consensus Algorithm
|ano= 2014
|último1 = Schwartz |primeiro1 = D.
|último2 = Youngs |primeiro2 = N.
|último3 = Britto |primeiro3 = A.
| url=https://ripple.com/files/ripple_consensus_whitepaper.pdf
}}</ref>

<ref name="Ethash">{{citar web|título=Ethash|url=https://github.com/ethereum/wiki/wiki/Ethash|acessdate=08/12/2015}}</ref>

<ref name="Ethereum">{{citar web|título=Ethereum Frontier Guide - Mining|url=https://ethereum.gitbooks.io/frontier-guide/content/mining.html|acessdate=08/12/2015}}</ref>

<ref name="Slasher">
{{citar notícia
|título=Slasher: A Punitive Proof-of-Stake Algorithm
|primeiro =Vitalik
|último =Buterin
| url         =https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/
|jornal=blog.ethereum.org
|data= 15/01/2014
|acessodata= 08/12/2015
}}</ref>

<ref name="Confidence">{{citar web|título=BlockCypher - Confidence factor|url=http://dev.blockcypher.com/#confidence-factor|acessdate=08/12/2015}}</ref>
}}

[[Categoria:Sistemas de pagamento]]
[[Categoria:Fraudes na Internet]]
[[Categoria:Computação distribuída]]