Hoje não há dúvida em afirmar que o Bitcoin e sua tecnologia subjacente, blockchain, se tornou uma das maiores revoluções tecnológicas dos últimos tempos e que seus conceitos permitem aplicações com um potencial incrível, muitas das quais ainda não descobertas, mesmo fora do setor financeiro, o objetivo inicial para o qual foi criado.

Mas como tudo começou?

Como já explicamos em Quem criou Bitcoin, Satoshi Nakamoto publicou um documento em 2008 em um fórum onde, de maneira teórica, definiu em detalhes um meio de pagamento global sem intermediários, entre usuários, formado por um ecossistema de peças combinadas nunca vistas até esse dia. O documento, com uma apresentação de estilo acadêmico, é o chamado “Bitcoin Paper”, que você pode ver aqui.

Prepare-se para mergulhar nas palavras originais do criador do Bitcoin, na primeira menção oficial que surgiu da ferramenta que mudou muito mais do que as finanças, dando forma a todo um universo de revoluções tecnológicas em torno dela. Então deixamos a versão traduzida para o portugues da Bitcoin Paper.

Bitcoin: um sistema de caixa eletrônico de usuário para usuário

Satoshi Nakamoto

satoshin@gmx.com

www.bitcoin.org

Resumo: Uma versão puramente eletrônica do dinheiro permitiria que pagamentos on-line fossem enviados diretamente, de uma entidade para outra, sem ter que passar por uma instituição financeira. Assinaturas digitais fornecem parte da solução para o problema, mas os principais benefícios são perdidos se for preciso ter uma terceira parte confiável para evitar gastos duplicados.

Propomos uma solução para o problema do gasto duplo usando uma rede de usuário para usuário. A rede coloca registros de tempo nas transações que ele insere em uma cadeia contínua de testes de trabalho com base no cálculo de hashes, formando um registro que não pode ser alterado sem recriar o teste de trabalho completo. A cadeia mais longa não serve apenas como testemunha e teste da sequência de eventos, mas também garante que ela está vindo do cluster com o maior processamento da CPU.

Enquanto a maioria do poder de processamento da CPU estiver sob o controle de nós que não cooperam para atacar a rede, eles gerarão a cadeia mais longa e aproveitarão os invasores. A rede em si requer uma estrutura mínima. As mensagens são enviadas sob a premissa de menor esforço, e os nós podem sair e se juntar à rede quando acharem adequado, aceitando a mais longa cadeia de prova de trabalho, como prova do que aconteceu durante sua ausência.

1. Introdução

O comércio na Internet depende exclusivamente de instituições financeiras, que servem como terceiros confiáveis, para o processamento de pagamentos eletrônicos. Enquanto o sistema funciona bem o suficiente para a maioria das transações, ele ainda sofre com as fraquezas inerentes do modelo baseado em confiança. Transações completamente não reversíveis não são realmente possíveis, porque 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 por transacção e eliminando a possibilidade de fazer pequenas transações ocasionais, havendo um custo mais elevado para esta perda e da incapacidade de fazer pagamentos para não-reversíveis serviços não-reversíveis.

Com a possibilidade de reverter, a necessidade de confiança se expande. Os comerciantes devem cuidar de seus clientes, irritando-os, solicitando mais informações do que seria necessário. Uma certa porcentagem de fraude é aceita como inevitável. Estes custos e pagamentos incertezas podem ser evitados se a pessoa usa o dinheiro físico, mas não há nenhum mecanismo para fazer pagamentos para um canal de comunicação sem uma terceira parte confiável. O que é necessário é um sistema de pagamento eletrônico que é baseada em testes de criptografia, em vez de confiança, permitindo que as duas partes para transacionar diretamente, sem a necessidade de uma terceira parte confiável.

Transações que são computacionalmente impossível de inverter a proteger os vendedores de fraude, assim como depósito de mecanismos de segurança de rotina poderia ser facilmente implementada para proteger os compradores. Neste trabalho, propomos uma solução para o problema dos gastos dupla usando um servidor timestamps de usuario a usuario distribuído para gerar uma prova computacional da ordem cronológica de transações. O sistema é seguro, pois nós honestos controlam coletivamente mais poder de processamento (CPU) do que qualquer grupo 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 a próxima 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 é que o beneficiário não pode verificar se algum dos proprietários anteriores não gastou o dobro da moeda. A solução comum é introduzir uma autoridade central confiável, uma espécie de hortelã, que verificaria se cada transação tinha gastos duplicados ou não. Após cada transação, a moeda deve ser devolvida à casa da moeda para gerar uma nova moeda, de modo que apenas as moedas geradas diretamente por essa casa de moeda sejam aquelas que estão confiantes em não ter despesas duplicadas.

O problema com essa solução é que o destino de todo o sistema monetário depende da empresa que administra a casa da moeda, com todas as transações tendo que passar por elas, como faria um banco. Portanto, precisamos encontrar uma maneira de o beneficiário saber que os proprietários anteriores não assinaram nenhuma transação anterior. Para nossos propósitos, a última transação ou a mais antiga é a que conta, por isso não nos importaremos com outras tentativas subsequentes de gastos duplicados.

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 essa casa que estava ciente de todas as transações e decidiu qual vinha primeiro. Para conseguir isso sem um terceiro confiável, as transações devem ser anunciadas publicamente [1], e precisaremos de um sistema de participantes que concordem com uma única história, na 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 com o primeiro que foi recebido.

3. Servidor de timestamp

A solução que propomos começa com um servidor de timestamp (marcas do tempo). Um servidor de timestamp trabalha fazendo um bloco de dados para ser datado e publicando-o amplamente, como seria feito em um jornal ou em uma publicação da Usenet [2-5]. O timestamp prova que os dados, obviamente, devem ter existido naquele momento para serem incluídos no hash. Cada registro de data e hora inclui em seu hash o registro de data e hora anterior, formando uma cadeia, para que cada registro de data e hora adicional reforce os anteriores para um determinado.

marcasdetiempo

4. À prova de trabalho

Para implementar um servidor de registro de data e hora seguindo um esquema de usuário para usuário, precisaremos usar um sistema de teste de trabalho semelhante ao Hashcash de Adam Back [6], em vez de usar um jornal ou uma publicação da Usenet. O teste de trabalho envolve a exploração de um valor, de tal forma que, ao calcular um hash, como SHA-256, ele começa com um certo número de bits com valor zero. O trabalho médio necessário será exponencial para o número de bits necessários com valor zero, mas isso pode ser verificado pela execução de um único hash.

Para nossa rede de timestamps, implementamos o teste 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 mesmo hash. Uma vez gasto o esforço da CPU para satisfazer o teste 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 ele.

prueba-de-trabajo

O teste 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, ele poderia ser alterado por alguém capaz de atribuir muitos IPs. A prova de trabalho é essencialmente “one-CPU-one-vote”. A decisão da maioria é representada pela cadeia mais longa, que tem o teste de trabalho com o maior esforço investido.

Se a maior parte do poder da CPU for controlada por nós honestos, a cadeia honesta crescerá mais rapidamente e deixará para trás qualquer outra cadeia que esteja competindo. Para modificar um bloco no passado, um invasor teria que refazer o teste de trabalho do bloco e todos os blocos subseqüentes e, em seguida, atingir e ultrapassar o trabalho dos nós honestos. Em seguida, mostraremos que a probabilidade de um atacante mais lento alcançar a cadeia mais longa diminui exponencialmente à medida que mais blocos subseqüentes são incorporados.

Para compensar o aumento na velocidade do hardware e o interesse variável de executar nós no tempo, a dificuldade do teste de trabalho é determinada por uma média móvel direcionada por um número médio de blocos por hora. Se estes são gerados muito rapidamente, a dificuldade aumenta.

5. A Rede

As etapas que a rede executa são as seguintes:

  1. Novas transações são emitidas para todos os nós.
  2. Cada nó coleta novas transações em um bloco.
  3. Cada nó trabalha em encontrar um teste de trabalho difícil para o seu bloco.
  4. Quando um nó encontra um teste de trabalho, ele emite o bloco para todos os nós.
  5. Os nós aceitam o bloco se todas as transações no bloco são válidas e não foram 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 um hash anterior.

Os nós sempre consideram a cadeia mais longa como a correta e começam a trabalhar na sua extensão. Se dois nós emitirem versões diferentes do próximo bloco simultaneamente, alguns nós poderão receber um ou outro primeiro. Nesse caso, eles trabalham no primeiro que recebem, mas mantêm o outro ramo caso fique mais longo. O empate quebra quando o próximo teste de trabalho é encontrado e um ramo se torna mais longo; os nós que estavam trabalhando na outra ramificação depois são alterados para o que agora é mais longo.

Os problemas de novas transações não precisam necessariamente atingir todos os nós. No momento em que eles alcançam muitos nós, eles acabam entrando em um bloco antes de passar um longo tempo. A emissão dos blocos também é tolerante à perda de mensagens. Se um nó não receber um bloco, ele irá solicitá-lo quando receber o próximo bloco e perceber que perdeu um.

6. Incentivo

Por convenção, a primeira transação no bloco é uma transação especial que gera uma nova moeda cujo proprietário é o criador do bloco. Isso adiciona um incentivo para os nós suportarem a rede e fornece uma maneira inicial de distribuir e circular moedas, já que não há autoridade para criá-las. Esta adição estável de uma quantidade constante de novas moedas é análoga aos garimpeiros que gastam recursos para colocá-lo em circulação. No nosso caso, os recursos são tempo de CPU e eletricidade que são gastos.

O incentivo também pode ser estabelecido com os custos de transação. Se o valor de saída de uma transação for menor que a 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 nas 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 atacante egoísta é capaz de reunir mais poder de processamento do que todos os nós honestos, ele teria que escolher entre usá-lo para fraudar pessoas roubando seus pagamentos, ou usá-lo para gerar novas moedas. Você deve achar mais lucrativo jogar seguindo as regras, pois elas favorecerão mais moedas do que combinar todos os outros nós, o que prejudica o sistema e a validade de sua própria riqueza.

7. Reivindicando espaço em disco

Depois que a última transação é enterrada em blocos suficientes, as transações gastas antes disso podem ser descartadas para economizar espaço em disco. Para facilitar isso sem quebrar o hash do bloco, as transações são verificadas em uma árvore Merkle [7] [2] [5], com apenas a raiz incluída no hash do bloco. Blocos antigos podem ser compactados ao remover ramificações da árvore. Os hashes internos não precisam ser salvos.

espacio-disco

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 computadores vendendo 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 permaneçam 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 dos blocos da cadeia mais longa do teste de trabalho, que pode ser obtida fazendo uma pesquisa nos nós da rede até que ele esteja convencido de ter a cadeia mais longa e obtenha o ramo da árvore Merkle, que liga a transação ao bloco em que foi datada. Embora você não possa verificar a transação sozinho, vinculando-a a algum lugar na cadeia, é possível ver que algum nó na rede a aceitou, para que os blocos adicionados confirmem mais tarde essa aceitação por parte da rede.

SPV

Como tal, a verificação é confiável, pois os 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 em si, o método simplificado pode ser enganado por transações feitas por um invasor, desde que ele 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 o bloco inteiro 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 uma segurança mais independente e uma verificação mais rápida.

9. Combinando e Dividindo Valor

Embora seja 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. Geralmente, haverá uma entrada única, de uma pré-transação maior, ou várias entradas combinando valores menores e pelo menos duas saídas: uma para pagamento e outra para devolver a alteração, se houver, de volta ao emissor .

transaccion

Devemos ter em mente que esse sistema se abre em múltiplas possibilidades, de modo que uma transação pode depender de várias transações, e essas, por sua vez, dependem de muito mais, o que não é problema. Nunca há necessidade de extrair uma única cópia completa do histórico de transações.

10. Privacidade

O modelo bancário tradicional alcança seu nível de privacidade ao limitar o acesso à informação às partes envolvidas e ao terceiro de confiança. A necessidade de anunciar publicamente todas as transações se opõe a esse método, mas a privacidade ainda pode ser mantida quebrando-se o fluxo de informações em outro lugar: mantendo as chaves públicas anônimas. Publicamente, pode-se ver que alguém está enviando uma certa quantia para outra pessoa, mas sem informações relacionadas à transação para 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.

privacidad

Como um firewall adicional, um novo par de chaves deve ser usado para cada transação para que elas possam ser associadas a um proprietário comum. Alguns tipos de associação com várias transações de entrada são inevitáveis, o que pode revelar que suas entradas pertencem ao mesmo proprietário. O risco seria que, se o proprietário de uma chave fosse revelado, o link poderia revelar outras transações pertencentes ao mesmo proprietário.

11. Cálculos

Consideramos o cenário em que um invasor tenta gerar uma cadeia alternativa mais rapidamente que a cadeia honesta. Mesmo que isso fosse alcançado, não abriria o sistema para mudanças arbitrárias, como a criação de valor de ar ou a obtenção de dinheiro que nunca pertenceu ao invasor. Os nós não aceitariam 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 apenas suas próprias transações para recuperar o dinheiro que gastou recentemente.

A corrida entre uma corrente honesta e a corrente de um atacante pode ser caracterizada como uma maneira aleatória e binomial. O evento de sucesso é a cadeia honesta sendo estendida em um bloco adicional e aumentando sua vantagem em +1, e sendo o evento de falha que a cadeia atacante é estendida em um bloco reduzindo a distância em -1.

A probabilidade de um atacante chegar até nós, a partir de um dado déficit, é análoga ao problema da Ruína do Jogador. Suponha que um jogador com crédito ilimitado comece em déficit e potencialmente jogue um número infinito de tentativas para tentar alcançar um ponto de equilíbrio. Podemos calcular a probabilidade de atingir o ponto de equilíbrio, ou de alcançar a cadeia honesta, como segue [8]:

p = probabilidade de que um nó honesto encontre o próximo bloco

q = probabilidade de que o atacante encontre o próximo bloco q

qz = probabilidade de que o atacante alcance z blocos de volta.

ecuacion1

Dada a nossa hipótese de que p> q, a probabilidade cai exponencialmente enquanto o número de blocos que o atacante deve atingir aumenta. Com probabilidades contrárias, se você não fizer uma jogada de sorte desde o início, suas chances se tornarão extremamente pequenas à medida que você for ficando para trás.

Agora vamos considerar o quanto o beneficiá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 quer fazer com que o beneficiário acredite que ele foi pago por algum tempo, depois mude a transação para que ele pague de volta uma vez que o tempo tenha passado.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 fazer a assinatura. Isso impede que o emissor prepare uma cadeia de blocos antecipadamente e pode estar trabalhando nela continuamente até ter a sorte de progredir o suficiente e, em seguida, executar a transação nesse momento. Depois 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 beneficiário aguarda que a transação seja adicionada a um bloco e que os blocos z tenham sido vinculados após a transação. Você não precisará saber a quantidade exata de progresso que o invasor fez, mas assumindo que os blocos honestos obtiveram a média esperada por bloco, o progresso potencial do invasor será uma distribuição de Poisson com um valor esperado de:

ecuacion2

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 obtido pela probabilidade de alcançar esse ponto:

ecuacion3

Re-organizamos para evitar a soma da cauda infinita da distribuição…

ecuacion4

Nós convertemos em código em C …

#include double
AttackerSuccessProbability(double q, int z)
{
     double p = 1.0 - q;
     double lambda = z * (q / p); 
     double sum = 1.0;
     int i, k;
     for (k = 0; k <= z; k++) 
     { 
          double poisson = exp(-lambda); 
          for (i = 1; i <= k; i++) 
               poisson *= lambda / i; 
          sum -= poisson * (1 - pow(q / p, z - k)); 
     } 
     return sum;
}

Executamos 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

Resolvemos para P menos 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

12. Conclusões

Propusemos um sistema de transações eletrônicas que não dependem de confiança. Começamos com a estrutura usual de moedas feita com base no uso de assinaturas digitais, que fornece um forte controle da propriedade, mas que é incompleta se não houver maneira de evitar gastos duplicados. Para resolver isso, propomos uma rede de usuário para usuário que usa o teste de trabalho para registrar um histórico de transações públicas e que rapidamente se torna computacionalmente insolúvel para um invasor que deseja alterá-lo, se os nós honestos controlarem a maior parte da energia da CPU. A rede é robusta devido à sua simplicidade não estruturada.

Os nós podem todos trabalhar ao mesmo tempo com pouca coordenação. Eles não precisam ser identificados, pois as mensagens não são roteadas para nenhum lugar específico e precisam ser entregues apenas com base no melhor esforço. Os nós podem ir e voltar da rede à vontade, aceitando a cadeia de teste de trabalho como prova do que aconteceu enquanto estavam ausentes. Eles votam com seu poder de CPU, expressando sua aceitação de blocos válidos ao trabalhar estendendo e rejeitando blocos inválidos ao reutilizar para trabalhar neles. Quaisquer regras ou 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, X.S. Avila, and J.-J. Quisquater, “Design of a secure timestamping service with minimal trust requirements,” In 20th Symposium on Information Theory in the Benelux, May 1999.
  • [3] S. Haber, W.S. Stornetta, “How to time-stamp a digital document,” In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.
  • [4] D. Bayer, S. Haber, W.S. Stornetta, “Improving the efficiency and reliability of digital time-stamping,” In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
  • [5] S. Haber, W.S. 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 – a denial of service counter-measure,” http://www.hashcash.org/papers/hashcash.pdf, 2002.
  • [7] R.C. Merkle, “Protocols for public key cryptosystems,” In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980.
  • [8] W. Feller, “An introduction to probability theory and its applications,” 1957.
Este articulo foi util?
Average Scoring: 3
➜ Share the knowledge and promote the decentralized revolution!