Whitepaper Bitcoin explicado em português
Tudo começou com o whitepaper Bitcoin, um documento explicativo sobre o conceito de uma tecnologia que nos dias de hoje não deixa dúvidas. Bitcoin e a sua tecnologia subjacente, blockchain, tornaram-se uma das maiores revoluções tecnológicas dos últimos tempos. Os seus conceitos permitem aplicações com um potencial incrível. Ainda há muito a ser descoberto, mesmo fora do setor financeiro para o qual foi originalmente criado.
Mas como tudo começou?
Como explicamos no artigo sobre "Quem criou o Bitcoin?",Satoshi Nakamoto publicou um documento num fórum em XNUMX. Nele, teoricamente definiu um método de pagamento global sem intermediários entre os usuários. Um ecossistema feito de peças combinadas nunca vistas até à data. O documento, com apresentação em estilo académico, é denominado “Bitcoin Paper”, que pode conferir aqui.
Prepare-se para mergulhar nas palavras originais do criador do Bitcoin. É a primeira menção oficial da ferramenta que mudou muito mais do que o financiamento. Descubra como procurou moldar todo um universo de revoluções tecnológicas ao seu redor.
Aqui está a versão traduzida para português do whitepaper Bitcoin.
Bitcoin: Um Sistema de Dinheiro Eletrónico Pessoa-a-Pessoa Satoshi Nakamoto
www.bitcoin.org
Resumo Uma versão puramente peer-to-peer de dinheiro eletrónico permitiria que pagamentos on-line 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 é necessário para evitar o gasto duplo. Nós propomos uma solução para o problema de gasto duplo usando uma rede peer-to-peer.
A rede insere data e hora nas transações através de um hash em uma cadeia contínua de prova-de-trabalho à base de hash, formando um registo que não pode ser alterado sem refazer a prova-de-trabalho. A cadeia mais longa não só serve como prova da sequência de eventos testemunhados, mas prova de que ela veio do maior pool de CPUs.
Enquanto a maioria do poder doss CPUs é controlado por nós que não estão cooperando para atacar a rede, eles irão gerar a cadeia mais longa e superar os atacantes. A própria rede requer estrutura mínima. As mensagens são espalhadas em regime de melhor esforço, e nós podem sair e regressar a rede à vontade, aceitando a cadeia mais longa de prova-de-trabalho, como prova do que aconteceu enquanto eles estavam fora.
Introdução O comércio na Internet tem dependido quase exclusivamente de instituições financeiras que servem como terceiros confiáveis para processar pagamentos eletrónicos. Enquanto o sistema funciona bem para a maioria das operações, ainda sofre com as deficiências inerentes ao modelo baseado em confiança. Transações completamente não-reversíveis não são possíveis, uma vez que as instituições financeiras não podem evitar a mediação de conflitos.
O custo da mediação aumenta os custos de transação, o que limita o tamanho mínimo prático da transação e elimina a possibilidade de pequenas transações ocasionais, e há um custo mais amplo na perda da capacidade de fazer pagamentos não reversível para serviços não reversíveis. Com a possibilidade de reversão, a necessidade de confiança se espalha. Comerciantes devem ser cautelosos com os seus clientes, incomodando-os para obter mais informações do que seria de outra forma necessária.
Uma certa percentagem de fraude é aceita como inevitável. Estes custos e incertezas de pagamento podem ser evitados ao vivo usando moeda física, mas não existe nenhum mecanismo para fazer pagamentos ao longo 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 a quaisquer duas partes dispostas a transacionar diretamente uma com a outra sem a necessidade de um terceiro confiável. Transações que são computacionalmente impraticáveis de reverter protegeriam os vendedores de fraudes e mecanismos rotineiros de disputa poderiam ser facilmente implementados para proteger os compradores.
Neste artigo, nós propomos uma solução para o problema de gasto duplo usando um servidor de horas distribuído peer-to-peer para gerar prova computacional da ordem cronológica das operações. O sistema é seguro desde que nós honestos controlem coletivamente mais poder de CPU do que qualquer grupo cooperado de nós atacantes.
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 ambas ao final da moeda. Um beneficiário pode verificar as assinaturas para verificar a cadeia de propriedade.
O problema, claro, é o beneficiário não poder confirmar se um dos pagadores não fez gasto duplo da moeda. Uma solução comum é a introdução de uma autoridade central confiável, ou casa da moeda, que verifique o gasto duplo para todas as transações. Depois de cada transação, a moeda deve ser devolvida à casa da moeda para a emissão de uma nova, e apenas moedas emitidas diretamente da casa da moeda são confiáveis de não ser gastas duplamente.
O problema desta solução é que o destino de todo o sistema monetário depende da empresa que gere a casa da moeda, com todas as transações tendo de passar por ela, assim como um banco. Nós precisamos de uma forma em que o beneficiário possa saber se os proprietários anteriores não assinaram quaisquer transações anteriores.
Para os nossos propósitos, a transação mais antiga é a que conta, por isso, nós não nos preocupamos com as tentativas posteriores de gasto duplo. A única forma de confirmar a ausência de uma transação é estar ciente de todas as transações. No modelo baseado em casa da moeda, a mesma está ciente de todas as transações e decide qual chegou primeiro. Para alcançar este objetivo 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 histórico único a ordem em que foram recebidas. O beneficiário precisa da prova que, no momento de cada transação, a maioria dos nós concorda que ela está a ser recebida pela primeira vez.
Servidor Timestamp A solução que propomos começa com um servidor de timestamp. Um servidor de carimbo de data / hora funciona misturando um bloco de dados a ser datado e publicando-o amplamente, assim como faria num jornal ou publicação da Usenet [2-5]. O carimbo de data / hora prova que os dados obviamente devem ter existido no momento para serem incluídos no hash. Cada timestamp inclui o timestamp anterior no seu hash, formando uma cadeia, de forma que cada timestamp adicional reforce os anteriores a uma dada.
Prova-de-Trabalho Para implementar um servidor de timestamp seguindo um esquema de usuário para usuário, precisaremos usar um sistema de prova de trabalho semelhante ao Hashcash de Adam Back [6], ao invés de usar uma publicação num jornal ou na Usenet. A prova de trabalho envolve explorar um valor tal que, ao calcular um hash, como SHA-256, ele comece com um número especificado de bits zero. O trabalho médio necessário será exponencial ao número de bits necessários com um valor zero, mas isso pode ser verificado executando um único hash.
Para a nossa rede de timestamps implementamos a prova de trabalho aumentando o valor de um campo nonce, pertencente ao bloco, até que seja encontrado um valor que forneça o número necessário de bits com valor zero para o hash do mesmo. Uma vez que o esforço da CPU foi gasto para satisfazer a prova de trabalho, o bloco não pode ser alterado sem refazer todo o trabalho. À medida que mais blocos são encadeados após um determinado, o trabalho para alterar um bloco incluiria refazer todos os blocos após este.
A prova-de-trabalho também resolve o problema da determinação da representação na tomada de decisão da maioria. Se a maioria fosse baseada num endereço IP um voto, isso poderia ser subvertido por qualquer pessoa capaz de alocar muitos IPs. Prova-de-trabalho é, essencialmente, "um-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 maioria do poder de CPU é controlado por nós honestos, a cadeia honesta vai crescer mais rápido e superar quaisquer cadeias concorrentes. Para modificar um bloco passado, o atacante terá de refazer a prova-de-trabalho do bloco e depois de todos os blocos posteriores e, em seguida, alcançar e superar o trabalho dos nós honestos.
Vamos mostrar mais tarde que a probabilidade de um atacante mais lento ter sucesso diminui exponencialmente quando blocos subsequentes são adicionados.
Para compensar o aumento da velocidade do hardware e o interesse variável dos nós de execução ao longo do tempo, a dificuldade da prova de trabalho é determinada por uma média móvel direcionada por um número médio de blocos por hora. Se forem gerados muito rapidamente, a dificuldade aumenta.
A Rede Os passos para executar a rede são os seguintes:
Novas transações são emitidas para todos os nós. Cada nó recolhe novas transações num bloco. Cada nó trabalha para encontrar uma difícil prova-de-trabalho para o seu bloco. Quando um nó encontra uma prova-de-trabalho, emite o bloco para todos os nós. Os nós aceitam o bloco somente se todas as suas transações são válidas e já não foram gastas. Os nós expressam a sua aceitação do bloco, trabalhando na criação do próximo bloco na cadeia, usando o hash do bloco aceite como o hash anterior. Os nós sempre consideram a cadeia mais longa para ser a correta e continuarão trabalhando para estendê-la. Se dois nós transmitirem diferentes versões do bloco seguinte simultaneamente, alguns nós podem receber um ou o outro primeiro. Nesse caso, eles trabalham com o primeiro recebido, mas salvam o outro ramo caso ele se torne o mais longo. O empate será quebrado quando a próxima prova de trabalho for encontrada e um ramo se torne mais longo; os nós que estavam trabalhando no outro ramo, então, mudarão para o mais longo.
As novas emissões de transações não precisam necessariamente atingir todos os nós. Quando atingirem muitos nós, acabarão entrando num bloco em pouco tempo. A emissão dos blocos também é tolerante à perda de mensagens. Se um nó não receber um bloco, ele o pedirá quando receber o próximo bloco e perceber que perdeu um.
Incentivo Por convenção, a primeira transação no bloco é uma transação especial que gera uma nova moeda de propriedade do criador do bloco. Isto adiciona um incentivo para os nós apoiarem a rede e fornece uma maneira inicial de distribuir e colocar em circulação as moedas, uma vez que não há autoridade para criá-las. Essa adição estável de uma quantidade constante de novas moedas é análoga aos mineiros de ouro que gastam recursos para colocá-la em circulação. No nosso caso, os recursos são o tempo de CPU e a eletricidade gasta.
O incentivo também pode ser estabelecido com custos de transação. Se o valor de saída de uma transação for menor que o valor de entrada, a diferença será uma taxa de transação que será adicionada ao valor de incentivo do bloco que a contém. Uma vez que um número predeterminado de moedas tenha entrado em circulação, o incentivo pode evoluir inteiramente em taxas de transação e ser completamente livre de inflação.
O incentivo também pode ajudar a encorajar os nós a permanecerem honestos. Se um invasor egoísta for capaz de reunir mais poder de CPU do que todos os nós honestos, ele terá que escolher entre usá-lo para fraudar pessoas roubando os seus pagamentos ou usá-lo para gerar novas moedas. Deverá achar que é mais lucrativo jogar de acordo com as regras, pois as regras o favorecerão com mais moedas que combinar todos os outros nós, do que minar o sistema e a validade da sua própria riqueza.
Recuperação do espaço em disco Uma vez que a transação mais recente de uma moeda está enterrada sob blocos suficientes, as transações gastas anteriormente podem ser descartadas para economizar espaço em disco. Para facilitar isso sem quebrar o hash do bloco, o hash das transações é feito numa árvore de merkle [XNUMX] [XNUMX] [XNUMX], e apenas a raiz é incluída no hash do bloco. Blocos velhos podem então ser compactados removendo galhos da árvore. Os hashes internos não precisam ser armazenados.
O cabeçalho de um bloco sem transações terá cerca de 80 bytes. Se assumirmos que cada bloco é gerado a cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4.2 MB por ano. Com os computadores sendo vendidos geralmente com 2 GB de RAM em 2008 e a lei de Moore prevendo um crescimento atual de 1.2 GB por ano, o armazenamento não deve ser um problema, mesmo que os cabeçalhos dos blocos devam permanecer na memória.
Verificação de Pagamento Simplificada É possível verificar os pagamentos sem executar um nó de rede completo. Um usuário só precisa manter uma cópia dos cabeçalhos de bloco da cadeia mais longa da prova de trabalho, que pode ser obtida fazendo uma pesquisa nos nós da rede até que esteja convencido de que possui a cadeia mais longa, e obtenha o ramo da árvore Merkle, que vincula a transação ao bloco no qual foi datada. Embora não possa verificar a transação sozinho, ao vinculá-la em algum lugar da cadeia, pode ver que algum nó na rede a aceitou, de modo que os blocos adicionados posteriormente confirmariam ainda mais essa aceitação pela rede.
Como tal, a verificação é confiável, pois nós honestos controlam a rede, mas se tornam mais vulneráveis se a rede for dominada por um invasor. Contanto que os nós da rede possam verificar as transações por conta própria, o método simplificado pode ser enganado por transações fabricadas por um invasor, desde que o invasor possa dominar a rede. Uma estratégia para se proteger é aceitar alertas dos nós da rede quando eles detectarem um bloco inválido, pedindo ao usuário para baixar todo o bloco e as transações alertadas para confirmar a inconsistência. As empresas que recebem pagamentos com frequência desejarão executar os seus próprios nós para uma segurança mais independente e verificação mais rápida.
Combinando e Dividindo Valor Embora fosse possível manipular moedas individualmente, seria difícil lidar com transações separadas para cada centavo de 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 valores menores, e pelo menos duas saídas: uma para pagamento e outra para devolver o troco, se houver, ao emissor .
Deve-se levar em conta que este sistema é em forma de leque, de forma que uma transação pode depender de várias transações, e estas por sua vez dependem de muitas outras, o que não é um problema. Nunca há necessidade de extrair uma única cópia completa do histórico de transações.
Privacidade O modelo bancário tradicional alcança seu nível de privacidade, limitando o acesso às informações às partes envolvidas e ao terceiro de confiança. A necessidade de anunciar todas as transações publicamente impede esse método, mas a privacidade ainda pode ser mantida interrompendo o fluxo de informações noutro lugar: mantendo as chaves públicas anónimas. Publicamente, pode-se verificar que alguém está a enviar uma determinada quantia para outra pessoa, mas sem informações que vinculem a transação a alguém em particular. Isso é semelhante ao nível de informação mostrado nas bolsas de valores, onde o tempo e o tamanho das transações individuais, a "fita", são públicos, mas sem dizer quem são as partes.
Como um firewall adicional, um novo par de chaves deve ser usado para cada transação para que eles possam ser associados a um proprietário comum. Alguns tipos de associação com transações de entradas múltiplas são inevitáveis, o que pode revelar que as suas entradas pertencem ao mesmo proprietário. O risco seria que, se o proprietário de uma chave for revelado, o vinculador poderia revelar outras transações que pertenceram ao mesmo proprietário.
Cálculos Consideramos o cenário em que um invasor tenta gerar uma cadeia alternativa mais rápido do que a cadeia honesta. Mesmo que isso fosse alcançado, não abriria o sistema para mudanças arbitrárias, como criar valor do ar ou tirar dinheiro que nunca pertenceu ao invasor. Os nós não aceitariam uma transação inválida como pagamento e nós honestos nunca aceitariam um bloco que as contivesse. Um invasor só pode tentar alterar apenas suas próprias transações para recuperar o dinheiro que gastou recentemente.
A corrida entre a cadeia honesta e uma cadeia atacante pode ser caracterizada como uma Caminhada Aleatória Binomial. O evento de sucesso é a cadeia honesta sendo prorrogada por mais um bloco, aumentando a sua liderança por +1, e o evento de falha é cadeia do atacante sendo prorrogada por um bloco, reduzindo a lacuna por -1.
A probabilidade de que um atacante possa nos atingir, a partir de um determinado déficit, é análoga ao problema da ruína do jogador. Suponha que um jogador com crédito ilimitado comece com déficit e potencialmente faça um número infinito de tentativas para tentar empatar. Podemos calcular a probabilidade de que atingiu o ponto de equilíbrio, ou de que atingiu a cadeia honesta, da seguinte forma [8]:
p = probabilidade de um nó honesto encontrar o próximo bloco
q = probabilidade de o atacante encontrar o próximo bloco
qz = probabilidade do atacante alcançar partindo de z blocos atrás.
Dada nossa hipótese de que p> q, a probabilidade cai exponencialmente enquanto o número de blocos que o atacante deve alcançar aumenta. Com as probabilidades contra você, se você não fizer uma jogada de sorte logo no início, suas chances se tornam extremamente pequenas quanto mais você fica para trás.
Agora, vamos considerar quanto tempo o beneficiário de uma nova transação precisa esperar antes de ter certeza suficiente de que o emissor não pode alterá-la. Presumimos que o emissor seja um invasor que deseja fazer o beneficiário acreditar que foi pago por um tempo e, em seguida, alterar a transação para pagar a si mesmo depois de um tempo, o beneficiário será alertado quando isso acontecer, mas o emissor espera que seja tarde demais.
O beneficiário gera um novo par de chaves e entrega a chave pública ao emissor logo após a assinatura. Isso evita que o emissor prepare um blockchain com antecedência e pode trabalhar nele continuamente até ter a sorte de se antecipar e, então, executar a transação nesse ponto. Assim que a transação é enviada, o remetente desonesto começa a trabalhar secretamente em uma cadeia paralela que contém uma versão alternativa de sua transação.
O destinatário espera até que a transação tenha sido adicionada a um bloco e z blocos sejam ligados depois. Ele não sabe a quantidade exata de progresso do atacante, mas assumindo que os blocos honestos tomaram o tempo médio esperado por bloco, o progresso potencial do atacante será uma distribuição de Poisson com valor esperado:
Para obter a probabilidade de que o invasor ainda possa nos alcançar agora, multiplicamos a densidade de Poisson pela quantidade de progresso que ele poderia ter feito vezes a probabilidade de que ele pudesse chegar a esse ponto:
Reorganizamos para evitar a soma da cauda infinita da distribuição ...
Convertendo para código C...
Corremos alguns resultados, podemos ver que a probabilidade cai exponencialmente com z.
Resolvendo para P menor que 0.1%...
Conclusão Propusemos um sistema de transações eletrónicas, sem depender de confiança. Começamos com o framework habitual de moedas feitas de assinaturas digitais, que fornece um forte controlo de propriedade, mas é incompleto sem uma forma de evitar o gasto duplo. Para resolver isso, propusemos uma rede peer-to-peer usando prova de trabalho para gravar um histórico público de transações que rapidamente se torna computacionalmente impraticável para um atacante para mudar se nós honestos controlarem a maioria do poder de CPU.
A rede é robusta na sua simplicidade não estruturada. Os nós trabalham todos de uma vez, com pouca coordenação. Eles não precisam ser identificados, uma vez que as mensagens não são roteadas para qualquer lugar particular e só precisam ser apresentadas em regime de melhor esforço. Os nós podem sair e voltar a rede à vontade, aceitando a cadeia de prova de trabalho, como prova do que aconteceu enquanto eles estavam fora. Eles votam com o seu poder de CPU, expressando a aceitação de blocos válidos, trabalhando em estendê-los e rejeitando blocos inválidos, recusando-se a trabalhar com eles. Todas as regras e incentivos necessários podem ser aplicados com este mecanismo de consenso.
Referências [1] W. Dai, "b-money" https://www.weidai.com/bmoney.txt, 1998. [2] H. Massias, XS Avila e J.‑J. Quisquater, “Design de um serviço de registo de data e 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, "Como marcar um documento digital com data e hora", 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 tempo digital”, nas Seqüê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, “Nomes seguros para cadeias de bits”, Nos Anais da 4ª Conferência da ACM sobre Segurança de Computadores e Comunicações, páginas 28-35, abril de 1997. [6] A. Back, "Hashcash - uma contra-medida de negação de serviço" https://www.hashcash.org/papers/hashcash.pdf, 2002. [7] RC Merkle, "Protocolos para sistemas de criptografia de chave pública", In Proc. Simpósio de 1980 sobre Segurança e Privacidade, IEEE Computer Society, páginas 122-133, abril de 1980. W. Feller, "Uma introdução à teoria das probabilidades e suas aplicações", 8.[1]
Referências:
