Bitcoin: um sistema de dinheiro eletrônico ponto a ponto
Satoshi Nakamoto
satoshin@gmx.com
www.bitcoin.org
Resumo . Uma versão puramente peer-to-peer de dinheiro eletrônico permitiria que pagamentos online fossem enviados diretamente de uma parte para outra sem passar por uma instituição financeira. As assinaturas digitais fornecem parte da solução, mas os principais benefícios são perdidos se um terceiro confiável ainda for necessário para evitar gastos duplos. Propomos uma solução para o problema do gasto duplo usando uma rede peer-to-peer. A rede registra as transações com hash em uma cadeia contínua de prova de trabalho baseada em hash, formando um registro que não pode ser alterado sem refazer a prova de trabalho. A cadeia mais longa não serve apenas como prova da sequência de eventos testemunhados, mas também como prova de que veio do maior pool de energia da CPU. Enquanto a maior parte da potência da CPU for controlada por nós que não estão cooperando para atacar a rede, eles gerarão a cadeia mais longa e ultrapassarão os invasores. A própria rede requer uma estrutura mínima. As mensagens são transmitidas com base no melhor esforço e os nós podem sair e voltar à rede à vontade, aceitando a cadeia de prova de trabalho mais longa como prova do que aconteceu enquanto eles estavam ausentes.
1. Introdução
O comércio na Internet passou a depender quase exclusivamente de instituições financeiras que atuam como terceiros confiáveis para processar pagamentos eletrônicos. Embora o sistema funcione bem o suficiente para a maioria das transações, ele ainda sofre das fraquezas inerentes do modelo baseado em confiança. Transações completamente irreversíveis não são realmente possíveis, uma vez que as instituições financeiras não podem evitar a mediação de disputas. O custo da mediação aumenta os custos de transação, limitando o tamanho prático mínimo da transação e eliminando a possibilidade de pequenas transações casuais, e há um custo mais amplo na perda da capacidade de efetuar pagamentos irreversíveis por serviços irreversíveis. Com a possibilidade de reversão, a necessidade de confiança se espalha. Os comerciantes devem ser cautelosos com seus clientes, importunando-os para obter mais informações do que de outra forma precisariam. Uma certa porcentagem de fraude é aceita como inevitável. Esses custos e incertezas de pagamento podem ser evitados pessoalmente usando moeda física, mas não existe nenhum mecanismo para fazer pagamentos por meio de um canal de comunicação sem uma parte confiável.
O que é necessário é um sistema de pagamento eletrônico baseado em prova criptográfica em vez de confiança, permitindo que quaisquer duas partes dispostas transacionem diretamente entre si sem a necessidade de um terceiro confiável. As transações cuja reversão é computacionalmente impraticável protegeriam os vendedores contra fraudes, e mecanismos de custódia de rotina poderiam ser facilmente implementados para proteger os compradores. Neste artigo, propomos uma solução para o problema de gasto duplo usando um servidor de timestamp distribuído peer-to-peer para gerar prova computacional da ordem cronológica das transações. O sistema é seguro desde que nós honestos controlem coletivamente mais poder de CPU do que qualquer grupo cooperativo de nós atacantes.
2. Transações
Definimos uma moeda eletrônica como uma cadeia de assinaturas digitais. Cada proprietário transfere a moeda para o próximo assinando digitalmente um hash da transação anterior e a chave pública do próximo proprietário e adicionando-os ao final da moeda. Um beneficiário pode verificar as assinaturas para verificar a cadeia de propriedade.
O problema, claro, é que o beneficiário não pode verificar se um dos proprietários não gastou duas vezes a moeda. Uma solução comum é introduzir uma autoridade central confiável, ou cunhagem, que verifique cada transação em busca de gastos duplicados. Após cada transação, a moeda deve ser devolvida à casa da moeda para emitir uma nova moeda, e apenas moedas emitidas diretamente da casa da moeda são confiáveis para não serem gastas duas vezes. O problema com esta solução é que o destino de todo o sistema monetário depende da empresa que administra a casa da moeda, com cada transação tendo que passar por ela, assim como um banco.
Precisamos de uma maneira de o beneficiário saber que os proprietários anteriores não assinaram nenhuma transação anterior. Para nossos propósitos, a transação mais antiga é a que conta, então não nos importamos com tentativas posteriores de gastar duas vezes. A única maneira de confirmar a ausência de uma transação é estar ciente de todas as transações. No modelo baseado na casa da moeda, a casa da moeda estava ciente de todas as transações e decidia qual chegaria primeiro. Para fazer isso sem uma parte confiável, as transações devem ser anunciadas publicamente [1], e precisamos de um sistema para que os participantes concordem com um único histórico da ordem em que foram recebidas. O beneficiário precisa de prova de que, no momento de cada transação, a maioria dos nós concordou que foi o primeiro recebido.
3. Servidor de carimbo de data/hora
A solução que propomos começa com um servidor de timestamp. Um servidor de timestamp funciona pegando um hash de um bloco de itens a serem timestampados e publicando amplamente o hash, como em um jornal ou postagem na Usenet [2-5]. O timestamp prova que os dados devem ter existido no momento, obviamente, para entrar no hash. Cada timestamp inclui o timestamp anterior em seu hash, formando uma cadeia, com cada timestamp adicional reforçando os anteriores.
4. Prova de trabalho
Para implementar um servidor de carimbo de data/hora distribuído em uma base ponto a ponto, precisaremos usar um sistema de prova de trabalho semelhante ao Hashcash de Adam Back [6], em vez de postagens de jornal ou Usenet. A prova de trabalho envolve a verificação de um valor que quando hash, como com SHA-256, o hash começa com um número de zero bits. O trabalho médio necessário é exponencial no número de zero bits necessários e pode ser verificado executando um único hash.
Para nossa rede de carimbo de data/hora, implementamos a prova de trabalho incrementando um nonce no bloco até que seja encontrado um valor que dê ao hash do bloco os bits zero necessários. Uma vez que o esforço da CPU foi despendido para satisfazer a prova de trabalho, o bloco não pode ser alterado sem refazer o trabalho. Como os blocos posteriores são encadeados depois dele, o trabalho para alterar o bloco incluiria refazer todos os blocos depois dele.
A prova de trabalho também resolve o problema de determinar a representação na tomada de decisão da maioria. Se a maioria fosse baseada em um-endereço-IP-um-voto, poderia ser subvertida por qualquer pessoa capaz de alocar muitos IPs. A prova de trabalho é essencialmente uma CPU-um-voto. A decisão da maioria é representada pela cadeia mais longa, que tem o maior esforço de prova de trabalho investido nela. Se a maior parte da potência da CPU for controlada por nós honestos, a cadeia honesta crescerá mais rapidamente e ultrapassará quaisquer cadeias concorrentes. Para modificar um bloco anterior, um invasor teria que refazer a prova de trabalho do bloco e de todos os blocos posteriores a ele e, então, alcançar e superar o trabalho dos nós honestos. Mostraremos mais tarde que a probabilidade de um atacante mais lento alcançá-lo diminui exponencialmente à medida que blocos subsequentes são adicionados.
Para compensar o aumento da velocidade do hardware e o interesse variável na execução de nós ao longo do tempo, a dificuldade de prova de trabalho é determinada por uma média móvel visando um número médio de blocos por hora. Se forem gerados muito rápido, a dificuldade aumenta.
5. Rede
As etapas para executar a rede são as seguintes:
1) Novas transações são transmitidas para todos os nós.
2) Cada nó coleta novas transações em um bloco.
3) Cada nó trabalha para encontrar uma prova de trabalho difícil para seu bloco.
4) Quando um nó encontra uma prova de trabalho, ele transmite o bloco para todos os nós.
5) Os nós aceitam o bloco somente se todas as transações nele forem válidas e ainda não gastas.
6) Os nós expressam sua aceitação do bloco trabalhando na criação do próximo bloco na cadeia, usando o hash do bloco aceito como o hash anterior.
Os nós sempre consideram a cadeia mais longa como a correta e continuarão trabalhando para estendê-la. Se dois nós transmitem versões diferentes do próximo bloco simultaneamente, alguns nós podem receber uma ou outra primeiro. Nesse caso, eles trabalham no primeiro que receberam, mas salvam o outro ramo caso ele se torne mais longo. O empate será desfeito quando a próxima prova de trabalho for encontrada e uma ramificação se tornar mais longa; os nós que estavam trabalhando no outro ramo mudarão para o mais longo.
Novas transmissões de transação não precisam necessariamente atingir todos os nós. Contanto que alcancem muitos nós, eles entrarão em um bloco em pouco tempo. As transmissões em bloco também toleram mensagens descartadas. Se um nó não receber um bloco, ele o solicitará quando receber o próximo bloco e perceber que perdeu um.
6. Incentivo
Por convenção, a primeira transação em um bloco é uma transação especial que inicia uma nova moeda de propriedade do criador do bloco. Isso adiciona um incentivo para os nós apoiarem a rede e fornece uma maneira de distribuir inicialmente as moedas em circulação, uma vez que não há autoridade central para emiti-las. A adição constante de uma quantidade constante de novas moedas é análoga aos mineradores de ouro gastando recursos para adicionar ouro à circulação. No nosso caso, é gasto tempo de CPU e eletricidade.
O incentivo também pode ser financiado com taxas de transação. Se o valor de saída de uma transação for menor que seu valor de entrada, a diferença é uma taxa de transação que é adicionada ao valor de incentivo do bloco que contém a transação. Uma vez que um número predeterminado de moedas tenha entrado em circulação, o incentivo pode transitar inteiramente para taxas de transação e ser completamente livre de inflação.
O incentivo pode ajudar a encorajar os nós a permanecerem honestos. Se um invasor ganancioso for capaz de reunir mais poder de CPU do que todos os nós honestos, ele terá que escolher entre usá-lo para fraudar as pessoas roubando seus pagamentos ou usá-lo para gerar novas moedas. Ele deve achar mais lucrativo jogar de acordo com as regras, regras que o favorecem com mais moedas novas do que todos os outros juntos, do que minar o sistema e a validade de sua própria riqueza.
7. Recuperando espaço em disco
Depois que a última transação em uma moeda é enterrada em blocos suficientes, as transações gastas antes dela podem ser descartadas para economizar espaço em disco. Para facilitar isso sem quebrar o hash do bloco, as transações são hash em uma Merkle Tree [7][2][5], com apenas a raiz incluída no hash do bloco. Blocos antigos podem então ser compactados arrancando galhos da árvore. Os hashes internos não precisam ser armazenados.
Um cabeçalho de bloco sem transações teria cerca de 80 bytes. Se supusermos que os blocos são gerados a cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4,2 MB por ano. Com os sistemas de computador sendo vendidos normalmente com 2 GB de RAM a partir de 2008, e a Lei de Moore prevendo o crescimento atual de
1,2 GB por ano, o armazenamento não deve ser um problema, mesmo que os cabeçalhos dos blocos devam ser mantidos na memória.
8. Verificação Simplificada de Pagamento
É possível verificar pagamentos sem executar um nó de rede completo. Um usuário só precisa manter uma cópia dos cabeçalhos de bloco da cadeia de prova de trabalho mais longa, que ele pode obter consultando os nós da rede até se convencer de que possui a cadeia mais longa e obter a ramificação Merkle que vincula a transação ao bloco ele tem um carimbo de data/hora. Ele não pode verificar a transação por si mesmo, mas, ao vinculá-la a um local na cadeia, ele pode ver que um nó de rede a aceitou e os blocos adicionados depois confirmam ainda mais que a rede a aceitou.
Como tal, a verificação é confiável desde que os nós honestos controlem a rede, mas é mais vulnerável se a rede for dominada por um invasor. Embora os nós da rede possam verificar as transações por si mesmos, o método simplificado pode ser enganado pelas transações fabricadas por um invasor enquanto o invasor continuar dominando a rede. Uma estratégia para se proteger contra isso seria aceitar alertas de nós da rede quando eles detectam um bloco inválido, solicitando que o software do usuário baixe o bloco completo e as transações de alerta para confirmar a inconsistência. As empresas que recebem pagamentos frequentes provavelmente ainda desejarão executar seus próprios nós para obter segurança mais independente e verificação mais rápida.
9. Combinando e Dividindo Valor
Embora fosse possível lidar com moedas individualmente, seria complicado fazer uma transação separada para cada centavo em uma transferência. Para permitir que o valor seja dividido e combinado, as transações contêm várias entradas e saídas. Normalmente, haverá uma única entrada de uma transação anterior maior ou várias entradas combinando quantias menores e, no máximo, duas saídas: uma para o pagamento e outra devolvendo o troco, se houver, de volta ao remetente.
Deve-se notar que o fan-out, onde uma transação depende de várias transações, e essas transações dependem de muitas outras, não é um problema aqui. Nunca há a necessidade de extrair uma cópia autônoma completa do histórico de uma transação.
10. Privacidade
O modelo bancário tradicional atinge um nível de privacidade ao limitar o acesso à informação às partes envolvidas e ao terceiro de confiança. A necessidade de anunciar todas as transações publicamente impossibilita esse método, mas a privacidade ainda pode ser mantida quebrando o fluxo de informações em outro local: mantendo as chaves públicas anônimas. O público pode ver que alguém está enviando um valor para outra pessoa, mas sem informações vinculando a transação a ninguém. Isso é semelhante ao nível de informação divulgado pelas bolsas de valores, onde o tempo e o tamanho dos negócios individuais, a "fita", são tornados públicos, mas sem dizer quem eram as partes.
Como um firewall adicional, um novo par de chaves deve ser usado para cada transação para evitar que sejam vinculados a um proprietário comum. Alguns vínculos ainda são inevitáveis com transações multi-input, que necessariamente revelam que seus inputs pertenciam ao mesmo proprietário. O risco é que, se o proprietário de uma chave for revelado, a vinculação poderá revelar outras transações que pertenceram ao mesmo proprietário.
11. Cálculos
Consideramos o cenário de um invasor tentando gerar uma cadeia alternativa mais rapidamente do que a cadeia honesta. Mesmo que isso seja feito, não abre o sistema para mudanças arbitrárias, como criar valor do nada ou pegar dinheiro que nunca pertenceu ao invasor. Os nós não aceitarão uma transação inválida como pagamento e os nós honestos nunca aceitarão um bloco que os contenha. Um invasor só pode tentar alterar uma de suas próprias transações para recuperar o dinheiro que gastou recentemente.
A corrida entre a cadeia honesta e a cadeia atacante pode ser caracterizada como um Passeio Aleatório Binomial. O evento de sucesso é a cadeia honesta sendo estendida em um bloco, aumentando sua liderança em +1, e o evento de falha é a cadeia do atacante sendo estendida em um bloco, reduzindo a lacuna em -1.
A probabilidade de um atacante recuperar-se de um determinado déficit é análoga a um problema de Ruína do Jogador. Suponha que um jogador com crédito ilimitado comece com déficit e jogue potencialmente um número infinito de tentativas para tentar atingir o ponto de equilíbrio.
Dada nossa suposição de que p > q, a probabilidade cai exponencialmente à medida que aumenta o número de blocos que o invasor precisa alcançar. Com as probabilidades contra ele, se ele não der uma investida de sorte logo no início, suas chances se tornam cada vez menores conforme ele fica para trás.
Agora consideramos quanto tempo o destinatário de uma nova transação precisa esperar antes de ter certeza de que o remetente não pode alterar a transação. Assumimos que o remetente é um invasor que deseja fazer o destinatário acreditar que ele o pagou por um tempo e, em seguida, mudar para pagar de volta a si mesmo depois de algum tempo. O destinatário será alertado quando isso acontecer, mas o remetente espera que seja tarde demais.
O receptor gera um novo par de chaves e dá a chave pública ao remetente pouco antes de assinar. Isso evita que o remetente prepare uma cadeia de blocos com antecedência, trabalhando nela continuamente até que tenha a sorte de avançar o suficiente e, em seguida, execute a transação naquele momento. Assim que a transação é enviada, o remetente desonesto começa a trabalhar em segredo em uma cadeia paralela contendo uma versão alternativa de sua transação.
O destinatário espera até que a transação seja adicionada a um bloco e z blocos sejam vinculados depois dela. Ele não sabe a quantidade exata de progresso que o invasor fez, mas assumindo que os blocos honestos levaram o tempo médio esperado por bloco, o progresso potencial do invasor será uma distribuição de Poisson.
12. Conclusão
Propusemos um sistema de transações eletrônicas sem depender de confiança. Começamos com a estrutura usual de moedas feitas de assinaturas digitais, que fornece forte controle de propriedade, mas é incompleta sem uma maneira de evitar gastos duplos. Para resolver isso, propusemos uma rede ponto a ponto usando prova de trabalho para registrar um histórico público de transações que rapidamente se torna computacionalmente impraticável para um invasor alterar se os nós honestos controlarem a maior parte da potência da CPU. A rede é robusta em sua simplicidade não estruturada. Os nós funcionam todos de uma vez com pouca coordenação. Eles não precisam ser identificados, pois as mensagens não são roteadas para nenhum local específico e precisam apenas ser entregues na base do melhor esforço. Os nós podem sair e voltar à rede à vontade, aceitando a cadeia de prova de trabalho como prova do que aconteceu enquanto eles estavam ausentes. Eles votam com seu poder de CPU, expressando sua aceitação de blocos válidos trabalhando para estendê-los e rejeitando blocos inválidos recusando-se a trabalhar neles. Quaisquer regras e incentivos necessários podem ser aplicados com este mecanismo de consenso.
Referências[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998.[2]H. Massias , XS Ávila e J.-J. Quisquater , "Projeto de um serviço de carimbo de data/hora seguro com requisitos mínimos de confiança", no 20º Simpósio sobre Teoria da Informação no Benelux, maio de 1999.[3] S. Haber, WS Stornetta , "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, páginas 99-111, 1991.[4] D. Bayer, S. Haber, WS Stornetta , "Melhorando a eficiência e a confiabilidade do carimbo de data/hora digital," Em Sequências II: Métodos em Comunicação, Segurança e Ciência da Computação, páginas 329-334, 1993.[5] S. Haber, WS Stornetta , "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997.[6] A. Back, " Hashcash - uma contramedida de negação de serviço," http://www.hashcash.org/papers/hashcash.pdf, 2002.[7] RC Merkle, "Protocolos para criptosistemas de chave pública," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, páginas 122-133, abril de 1980.[8]W. Feller, "Uma introdução à teoria da probabilidade e suas aplicações", 1957.
Comprando Bitcoin
Você pode comprar Bitcoin aqui .