Whitepaper Bitcoin explicado em português

Tudo começou com o white paper Bitcoin, um documento explicativo sobre o conceito de uma tecnologia que hoje não tem dúvidas. Bitcoin e sua tecnologia subjacente, blockchain, se tornou uma das maiores revoluções tecnológicas dos últimos tempos. Este conceito permite criar aplicações com um potencial incrível, pois ainda há muito por descobrir, mesmo fora do setor financeiro, para o qual foi inicialmente criado.

Mas como tudo começou?

Como explicamos no artigo sobre "Quem criou o Bitcoin?", Satoshi Nakamoto publicou um documento em um fórum em 2008. Nele, ele definiu teoricamente um Meio de pagamento global sem intermediários entre usuários. Um ecossistema formado por peças combinadas nunca antes vistas. O documento, com apresentação em estilo acadêmico, chama-se "Bitcoin Paper", e você pode conferir aqui.

A seguir, deixamos a versão traduzida para o espanhol do whitepaper do Bitcoin.

Bitcoin: Um Sistema de Dinheiro Eletrónico Pessoa-a-Pessoa

Satoshi Nakamoto

satoshin@gmx.com

www.bitcoin.org

Resumo

Uma versão puramente eletrônica do dinheiro permitiria que pagamentos online fossem enviados diretamente, de uma entidade para outra. Tudo isso, sem precisar passar por uma instituição financeira. As assinaturas digitais fornecem parte da solução para o problema, mas os principais benefícios são perdidos se um terceiro confiável tiver que existir para impedir o gasto duplo. Propomos uma solução para o problema da dupla despesa usando uma rede de usuário para usuário.

A rede carimba as transações que entra em uma cadeia contínua de prova de trabalho com base em cálculos de hash. Desta forma, um registro está sendo formado que não pode ser alterado sem recriar a prova de trabalho completa. A cadeia mais longa não serve apenas como token e prova da sequência de eventos, mas também garante que veio do pool com o maior processamento da CPU.

Enquanto a maior parte do poder de processamento da CPU estiver sob o controle de nós que não cooperam para atacar a rede. Dessa forma, eles gerarão a cadeia mais longa e terão vantagem sobre os atacantes. A própria rede requer uma estrutura mínima. As mensagens são enviadas com base no menor esforço e os nós podem sair e se juntar à rede sempre que acharem adequado. Sempre aceitando a cadeia mais longa de prova de trabalho, como prova do que aconteceu durante a sua ausência.

Introdução

O comércio pela Internet passou a depender exclusivamente de instituições financeiras, que atuam como terceiros confiáveis, para o processamento de 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, porque as instituições financeiras não podem evitar a mediação em disputas.

O custo da mediação aumenta os custos de transação. Isso limita o tamanho mínimo prático por transação e elimina a possibilidade de realizar pequenas transações casuais, havendo um custo maior por essa perda e a impossibilidade de efetuar pagamentos irreversíveis por serviços irreversíveis. Com a possibilidade de reversão, a necessidade de confiança se expande. Os comerciantes devem cuidar de seus clientes, importunando-os para obter mais informações do que seriam necessárias.

Uma certa porcentagem de fraude é aceita como inevitável. Esses custos e incertezas nos pagamentos podem ser evitados se a pessoa usar dinheiro físico. Mas não há mecanismo para fazer pagamentos por meio de um canal de comunicação sem um terceiro confiável. O que é necessário é um sistema de pagamento eletrônico baseado em provas criptográficas em vez de confiança. Isso visa permitir que as duas partes interessadas realizem transações diretamente sem a necessidade de um terceiro de confiança. As transações cuja reversão é computacionalmente impraticável protegeriam os vendedores contra fraudes. E, da mesma forma, mecanismos rotineiros de custódia poderiam ser facilmente implementados para proteger os compradores.

Neste trabalho, propomos uma solução para o problema do gasto duplo usando um servidor timestamp distribuído usuário a usuário para gerar uma prova computacional da ordem cronológica das transações. O sistema é seguro desde que os nós honestos controlem coletivamente mais poder de processamento (CPU) do que qualquer grupo 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 ambos 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 nossos propósitos, a transação mais recente ou mais antiga é a que conta. Portanto, não nos importaremos com novas tentativas de gastos duplos. A única maneira de confirmar a ausência de uma transação é estar ciente de todas as transações existentes. No modelo da casa da moeda, era a casa da moeda que estava ciente de todas as transações e decidiria quais seriam as primeiras. Para conseguir isso sem um terceiro confiável, as transações devem ser anunciadas publicamente [1], e precisaremos de um sistema de participantes concordando em uma única história, da ordem em que essas transações foram recebidas. O beneficiário precisa saber que, no momento de cada transação, a maioria dos nós concordou em qual deles foi recebido primeiro.

Servidor Timestamp

A solução que propomos começa com um servidor de timestamp. Um servidor de timestamp funciona por fazer hash de um bloco de dados a ser datado e publicá-lo amplamente, assim como você faria em um jornal ou postagem na Usenet [2-5]. O carimbo de data/hora prova que os dados obviamente devem ter existido naquele momento para serem incluídos nos dados. hash. Cada timestamp inclui o timestamp anterior em seu hash, formando uma cadeia, de modo que cada timestamp adicional reforce os anteriores.

Prova-de-Trabalho

Para implementar um servidor de registro de data e hora de usuário para usuário, precisaremos usar um sistema de prova de trabalho semelhante ao Hashcash por Adam Back [6], em vez de usar um jornal ou postagem na Usenet. A prova de trabalho envolve a verificação de um valor, de modo que, ao calcular um hash, como SHA-256, começa com um certo número de bits com valor zero. O trabalho médio necessário será exponencial ao número de bits necessários com valor zero mas que 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.

La prova de trabalho também resolve o problema de determinar como representar a decisão da maioria. Se essa maioria fosse baseada em um voto por endereço IP, ela poderia ser adulterada por alguém capaz de atribuir muitos IPs. Proof of Work é essencialmente “um-CPU-um-voto”. A decisão majoritária é representada pela cadeia mais longa, que possui a prova de trabalho com o maior esforço investido.

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:

1. Novas transações são emitidas para todos os nós.
2. Cada nó recolhe novas transações num bloco.
3. Cada nó trabalha para encontrar uma difícil prova-de-trabalho para o seu bloco.
4. Quando um nó encontra uma prova-de-trabalho, emite o bloco para todos os nós.
5. Os nós aceitam o bloco somente se todas as suas transações são válidas e já não foram gastas.
6. 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.

A string mais longa é sempre considerada a correta. e eles começam a trabalhar para estendê-lo. 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 recebem, mas salvam o outro ramo para o caso de ficar mais longo. O empate é desfeito quando a próxima prova de trabalho é encontrada e uma ramificação se torna mais longa; os nós que estavam trabalhando no outro ramo são posteriormente trocados para aquele que agora é mais longo.

As emissões de novas transações não precisam atingir todos os nós. No momento em que atingirem muitos nós, eles acabarão entrando em um 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 solicitará quando receber o próximo 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 de entrada, a diferença será uma taxa de transação que será adicionada ao valor do incentivo do bloco que o contém. Uma vez que um número predeterminado de moedas tenha entrado em circulação, o incentivo pode evoluir inteiramente para 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 geralmente sendo fornecidos 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 de bloco devam permanecer na memória.

Verificação de Pagamento Simplificada

É 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 mais longa da prova de trabalho, que pode ser obtida pesquisando os nós da rede até se convencer de que eles têm a cadeia mais longa e obtendo o ramo da árvore Merkle que vincula a transação ao bloco em que foi datada. Embora você não possa verificar a transação por si mesmo, ligando-se a ela em algum lugar da cadeia, você pode ver que ela foi aceita por algum nó da rede; portanto, os blocos adicionados posteriormente confirmariam ainda mais essa aceitação pela rede.

Como tal, a verificação é confiável desde que os nós honestos controlem a rede, mas torna-se mais vulnerável se a rede for controlada por um invasor. Embora os nós da rede possam verificar as próprias transações, 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 detectam um bloco inválido, solicitando ao usuário que baixe todo o bloco e as transações alertadas para confirmar a inconsistência. As empresas que recebem pagamentos com frequência desejam executar seus próprios nós para obter 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 é espalhado, de modo que uma transação pode depender de várias transações, e estes, por sua vez, podem depender de muitos mais, 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 atinge seu 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 impede esse método, mas a privacidade ainda pode ser mantida interrompendo o fluxo de informações em outro lugar: manter as chaves públicas anônimas. Publicamente, pode-se ver que alguém está enviando uma determinada quantia para outra pessoa, mas sem informações que relacionem a transação a uma determinada pessoa. Isso é semelhante ao nível de informação exibido 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 possam ser associados a um proprietário comum. Alguns tipos de associação com transações multi-ticket são inevitáveis, o que pode revelar que seus tickets pertencem ao mesmo proprietário. O risco seria que, se o proprietário de uma chave fosse revelado, o vinculador poderia revelar outras transações que pertenciam a ele.

Cálculos

Consideramos o cenário em que um invasor tenta gerar uma string alternativa mais rapidamente do que a string honesta. Mesmo que isso fosse feito, não abriria 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 aceitariam uma transação inválida como pagamento, e nós honestos nunca aceitarão um bloco que os contenha. Um invasor 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

q_z = 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 atingir aumenta. Com as probabilidades contra você, se você não fizer uma jogada de sorte logo no início, suas chances se tornarão extremamente pequenas quando você ficar para trás.

Agora, vamos considerar quanto tempo o destinatário de uma nova transação precisa esperar antes de ter certeza suficiente de que o emissor não pode alterá-la. Assumimos que o emissor é um invasor que deseja fazer o beneficiário acreditar que foi pago por um tempo e, em seguida, mudar a transação para pagar a si mesmo depois de algum tempo. O beneficiário será alertado quando isso acontecer, mas o remetente 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 que a transação seja adicionada a um bloco e que z blocos sejam vinculados após a transação. Você não precisará saber a quantidade exata de progresso que o invasor fez, mas supondo que os blocos honestos obtiveram a média esperada por bloco, o progresso potencial do invasor será um Distribuição de veneno com um valor esperado de:

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...

#incluir probabilidade de sucesso de ataque duplo (q duplo, z int) {p duplo = 1.0 - q; lambda duplo = z * (q / p); soma dupla = 1.0; int i, k; para (k = 0; k <= z; k ++) {poisson duplo = exp (-lambda); para (i = 1; i <= k; i ++) poisson * = lambda / i; soma - = poisson * (1 - pow (q / p, z - k)); } soma de retorno; }

Corremos alguns resultados, podemos ver que a probabilidade cai exponencialmente com z.

q=0.1 
z=0 P=1.0000000
z=1 P=0.2045873 
z=2 P=0.0509779 
z=3 P=0.0131722 
z=4 P=0.0034552 
z=5 P=0.0009137 
z=6 P=0.0002428 
z=7 P=0.0000647 
z=8 P=0.0000173 
z=9 P=0.0000046 
z=10 P=0.0000012 

q=0.3 
z=0 P=1.0000000 
z=5 P=0.1773523 
z=10 P=0.0416605 
z=15 P=0.0101008 
z=20 P=0.0024804 
z=25 P=0.0006132 
z=30 P=0.0001522 
z=35 P=0.0000379 
z=40 P=0.0000095 
z=45 P=0.0000024 
z=50 P=0.0000006

Resolvendo para P menor que 0.1%...

P > 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340

Conclusão

Propusemos um sistema de transações eletrônicas que não depende de confiança. Começamos com a estrutura usual de moedas feitas com base no uso de assinaturas digitais, que fornecem forte controle de propriedade, mas que está incompleto se não houver como evitar o gasto duplo. Para corrigir isso, propomos uma rede usuário-a-usuário que usa prova de trabalho para registrar um histórico público de transações e que rapidamente se torna computacionalmente insolúvel para um invasor que deseja alterá-la, se os nós honestos controlarem a maior parte da CPU poder.

Uma rede robusta por sua simplicidade não estruturada. Os nós podem trabalhar todos ao mesmo tempo 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 entrar e sair da rede à vontade, aceitando a cadeia de prova de trabalho como prova do que aconteceu enquanto eles estavam fora. Eles votam com seu poder de CPU, expressando sua aceitação de blocos válidos trabalhando estendendo e rejeitando blocos inválidos recusando-se a trabalhar neles. Quaisquer regras ou 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.