Whitepaper Bitcoin

O whitepaper do Bitcoin, Bitcoin: A Peer-to-Peer Electronic Cash System, foi publicado em 2008 por Satoshi Nakamoto. Lê abaixo a versão do documento em português.

Sinopse

Uma versão puramente ponto-a-ponto de dinheiro eletrónico permitiria que os pagamentos online fossem enviados directamente 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 perdem-se se um terceiro de confiança ainda for necessário para evitar o gasto duplo. Propomos uma solução para o problema das despesas duplas utilizando uma rede ponto-a-ponto. A rede adiciona um carimbo horário (timestamp) nas transacções colocando-as numa cadeia contínua de prova de trabalho (proof of work, PoW) através de um 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 também a prova de que veio do maior conjunto (pool) de potência de CPU. Enquanto a maioria da potência do CPU for controlada por nós que não estão a cooperar para atacar a rede, eles vão gerar a cadeia mais longa e suprimir os atacantes. A própria rede requer uma estrutura mínima. As mensagens são transmitidas com base no melhor esforço, e os nós (nodes) podem sair e voltar a juntar-se à rede à vontade, aceitando a mais longa cadeia de prova de trabalho como prova do que aconteceu enquanto estiveram fora.

1. Introdução

O comércio na Internet passou a depender quase exclusivamente de instituições financeiras que servem como terceiros de confiança para processar pagamentos electrónicos. Embora o sistema funcione bem o suficiente para a maioria das transacções, ainda sofre das fraquezas inerentes do modelo baseado na confiança. As transacçõ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 litígios. O custo da mediação aumenta os custos de transacção, limitando o tamanho mínimo das transacções e cortando a possibilidade de pequenas transacções casuais, e existe um custo mais amplo na perda da capacidade de fazer pagamentos não reversíveis para serviços não reversíveis. Com a possibilidade de inversão, a necessidade de confiança espalha-se. Os comerciantes devem ter cuidado com os seus clientes, incomodá-los para obter mais informações do que de outra forma. Uma certa percentagem de fraude é aceite como inevitável. Estes custos e incertezas nos pagamentos podem ser evitados pessoalmente através da utilização de moeda física, mas não existe qualquer mecanismo para fazer pagamentos através de um canal de comunicações sem uma parte de confiança.

O que é necessário é um sistema de pagamento electrónico baseado na prova criptográfica em vez de confiança, permitindo que qualquer duas partes dispostas transaccionem directamente entre si sem a necessidade de um terceiro de confiança. As transacções que são computacionalmente impraticáveis de reverter protegeriam os vendedores de fraudes, e mecanismos de caução de rotina poderiam facilmente ser implementados para proteger os compradores. Neste artigo, propomos uma solução para o problema do gasto duplo utilizando um servidor de carimbos de tempo distribuído entre pares para gerar provas computacionais da ordem cronológica das transacções. O sistema é seguro desde que nós honestos controlem colectivamente mais poder computacional do que qualquer grupo de nós atacantes em cooperação.

2. Transacções

Definimos uma moeda electrónica como uma cadeia de assinaturas digitais. Cada proprietário transfere a moeda para a seguinte, assinando digitalmente um hash da transacção anterior e a chave pública do próximo proprietário e adicionando-as ao fim 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 um dos proprietários não gastou a moeda duas vezes. Uma solução comum é introduzir uma autoridade central de confiança, ou casa da moeda, que verifique todas as transações para evitar gastos duplos. Após cada transacção, a moeda deve ser devolvida à casa da moeda para emitir uma nova moeda, e apenas as moedas emitidas directamente da casa da moeda são de confiança para não serem duplamente gastas. 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 transacções a terem de passar por ela, tal como um banco.

Precisamos de uma forma de o beneficiário saber que os proprietários anteriores não assinaram quaisquer transacções anteriores. Para os nossos propósitos, a primeira transacção é a que conta, por isso não nos importamos com tentativas posteriores de gastar duas vezes. A única forma de confirmar a ausência de uma transacção é estar ciente de todas as transacções. No modelo com base na casa da moeda, esta estava ciente de todas as transacções e decide qual chegou primeiro. Para o conseguir sem uma parte de confiança, as transacções devem ser publicamente anunciadas, e precisamos de um sistema para que os participantes cheguem a acordo sobre uma única história da ordem em que foram recebidas. O beneficiário precisa de provas de que, no momento de cada transacção, a maioria dos nós concordou que foi a primeira recebida.

3. O servidor de carimbos temporais (timestamps)

A solução que propomos começa com um servidor de carimbos de tempo. Um servidor de timestamps funciona gerando um hash de um bloco de itens e publicando amplamente o hash, como num artigo de jornal ou um post na Usenet. O timestamp prova que os dados devem ter existido na altura, obviamente, para entrar no hash. Cada carimbo temporal inclui o carimbo anterior no seu hash, formando uma cadeia, com cada carimbo temporal adicional reforçando os anteriores.

4. Prova de Trabalho (Proof-of-Work, PoW)

Para implementar um servidor de timestamps distribuído, teremos de utilizar um sistema de prova de trabalho semelhante ao Hashcash de Adam Back, em vez de publicações de jornais ou usenet. A prova de trabalho envolve a procura de um valor que quando calculado o hash, como com SHA-256, o hash começa com uma série de bits zero. O trabalho médio necessário é exponencial no número de bits zero necessários e pode ser verificado executando um único hash.

Para a nossa rede de timestamps, 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 gasto o esforço do CPU para que satisfaça a prova de trabalho, o bloco não pode ser alterado sem refazer o trabalho. Como os blocos posteriores são encadeados, o trabalho para mudar um bloco incluiria a refazer todos os blocos depois dele.

A prova de trabalho também resolve o problema da determinação da representação na tomada de decisões por maioria. Se a maioria se baseasse em um voto por um endereço IP, poderia ser subvertida por qualquer pessoa capaz de atribuir muitos IPs. A prova de trabalho é essencialmente um voto único. A decisão maioritária é representada pela cadeia mais longa, que tem o maior esforço de prova de trabalho investido nela. Se a maioria do poder do CPU for controlada por nós honestos, a cadeia honesta crescerá mais rápido e ultrapassará quaisquer cadeias concorrentes. Para modificar um bloco passado, um intruso teria de refazer a prova de trabalho do bloco e todos os blocos depois dele e, em seguida, alcançar e superar o trabalho dos nós honestos. Mostraremos mais tarde que a probabilidade de um intruso mais lento recuperar diminui exponencialmente à medida que os blocos subsequentes são adicionados.

Para compensar o aumento da velocidade de hardware e o interesse variável em correr nós ao longo do tempo, a dificuldade da prova de trabalho é determinada por uma média móvel que visa um número médio de blocos por hora. Se forem gerados muito rápido, a dificuldade aumenta.

5. Rede

Os passos para correr a rede são os seguintes:

• Novas transações são transmitidas para todos os nós.
• Cada nó recolhe novas transacções num bloco.
• Cada nó trabalha em encontrar uma prova de trabalho para o seu bloco.
• Quando um nó encontra uma prova de trabalho, transmite o bloco a todos os nós.
• Os nós aceitam o bloco apenas se todas as transações nele forem válidas e ainda não 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 consideram sempre que a cadeia mais longa é a correcta e continuarão a trabalhar na sua extensão. Se dois nós transmitirem versões diferentes do próximo bloco simultaneamente, alguns nós podem receber um ou outro primeiro. Nesse caso, trabalham no primeiro que receberam, mas salvam a outra filial no caso de se tornar mais longa. O empate será quebrado quando a próxima prova de trabalho for encontrada e um ramo se tornar mais longo; os nós que estavam a trabalhar no outro ramo mudarão então para o mais longo.

As novas emissões de transacções não precisam necessariamente de chegar a todos os nós. Desde que cheguem a muitos nós, entrarão num bloco em pouco tempo. As transmissões de blocos também são tolerantes com as mensagens perdidas. Se um nó não receber um bloco, irá solicitá-lo quando receber o próximo bloco e perceber que perdeu um.

6. Incentivo

Por convenção, a primeira transacção num bloco é uma transacção especial que inicia uma nova moeda detida pelo criador do bloco. Isto adiciona um incentivo para que os nós apoiem a rede, e fornece uma forma de distribuir inicialmente as moedas em circulação, uma vez que não existe autoridade central para as emitir. A adição constante de uma quantidade constante de novas moedas é análoga aos mineiros de ouro que gastam recursos para adicionar ouro à circulação. No nosso caso, é o tempo do CPU e a eletricidade que são gastos.

O incentivo também pode ser financiado com taxas de transacção. Se o valor de saída de uma transacção for inferior ao seu valor de entrada, a diferença é uma taxa de transacção que é adicionada ao valor de incentivo do bloco que contém a transacção. Uma vez entrado em circulação um número pré-determinado de moedas, o incentivo pode transitar inteiramente para as taxas de transacção e ser completamente livre de inflação.

O incentivo pode ajudar a encorajar os nós a manterem-se honestos. Se um atacante ganancioso for capaz de reunir mais poder de CPU do que todos os nós honestos, ele teria de escolher entre usá-lo para defraudar as pessoas roubando-lhe os pagamentos, ou usá-lo para gerar novas moedas. Ele deveria achar mais rentável cumprir as regras, tais regras que o favorecem com mais moedas novas do que todos os outros combinados, do que minar o sistema e a validade da sua própria riqueza.

7. Reclamando espaço em disco

Uma vez que a última transacção numa moeda é enterrada sob blocos suficientes, as transacções gastas anteriormente podem ser descartadas para economizar espaço em disco. Para facilitar isto sem quebrar o hash dos blocos, o hash das transacções é feito numa árvore Merkle (ref. 1, 2, 3), com apenas a raiz incluída no hash do bloco. Os blocos antigos podem então ser compactados arrancando ramos da árvore. As hashes interiores não precisam de ser armazenadas.

O cabeçalho de bloco sem transacções seria cerca de 80 bytes. Supondo que os blocos são gerados a cada 10 minutos, 80 bytes * 6 * 24 * 365 = 4,2MB por ano. Com sistemas informáticos normalmente vendidos com 2GB de RAM a partir de 2008, e a Lei de Moore que prevê um crescimento actual de 1,2GB 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 de pagamento simplificada

É possível verificar os pagamentos sem correr um nó de rede completo (full node). Um utilizador só precisa de guardar uma cópia dos cabeçalhos dos blocos da cadeia de prova de trabalho mais longa, que pode obter consultando outros nós da rede até que esteja convencido de que tem a cadeia mais longa, e obter a filial Merkle que liga a transacção ao bloco em que está marcada. Ele não pode verificar a transacção por si mesmo, mas ligando-a a um lugar na cadeia, ele pode ver que um nó na rede aceitou, e os blocos adicionados depois ajudam a confirmar que a rede a aceitou.

Como tal, a verificação é fiável desde que nós honestos controlem a rede, mas é mais vulnerável se a rede for dominada por um intruso. Enquanto os nós da rede podem verificar as transacções por si mesmos, o método simplificado pode ser enganado por transacções fabricadas por um intruso enquanto o intruso puder continuar a dominar a rede. Uma estratégia para proteger contra isso seria aceitar alertas de nós da rede quando detectam um bloco inválido, levando o software do utilizador a descarregar todo o bloco e a alertar as transacções para confirmar a inconsistência. As empresas que recebem pagamentos frequentes provavelmente continuarão provavelmente a querer executar os seus próprios nós para uma segurança mais independente e uma verificação mais rápida.

9. Combinando e dividindo valor

Embora fosse possível manusear as moedas individualmente, seria imprudente fazer uma transacção separada por cada cêntimo numa transferência. Para permitir a divisão e a combinação de valor, as transacções contêm múltiplas entradas e saídas. Normalmente, haverá uma única entrada de uma transacção anterior maior ou múltiplas entradas combinando montantes menores, e no máximo duas saídas: uma para o pagamento, e outra devolvendo o troco, se houver, de volta ao remetente.

Note-se que a difusão, em que uma transacção depende de várias transacções, e essas transacções dependem de muitas mais, não é um problema aqui. Nunca há necessidade de extrair uma cópia completa do histórico de uma transacção.

10. Privacidade

O modelo bancário tradicional alcança um nível de privacidade limitando o acesso à informação às partes envolvidas e aos terceiros de confiança. A necessidade de anunciar publicamente todas as transacções impede este método, mas a privacidade ainda pode ser mantida, quebrando o fluxo de informação noutro local: mantendo as chaves públicas anónimas. O público pode ver que alguém está a enviar uma quantia a outra pessoa, mas sem informações que liguem a transacção a alguém. Isto é semelhante ao nível de informação divulgado pelas bolsas de valores, em que o tempo e a dimensão das transacções individuais, a "fita", são tornados públicos, mas sem dizer quem eram as partes.

Como barreira adicional, um novo par de chaves deve ser usado para cada transacção para evitar que estejam ligados a um proprietário comum. Algumas ligações ainda são inevitáveis com transacções multi-entrada, que necessariamente revelam que as suas entradas eram propriedade do mesmo proprietário. O risco é que, se o proprietário de uma chave for revelado, a ligação pode revelar outras transacções que pertenciam ao mesmo proprietário.

11. Cálculos

Consideremos o cenário de um intruso tentar gerar uma cadeia alternativa mais rápido que a cadeia honesta. Mesmo que isso seja realizado, não abre o sistema a mudanças arbitrárias, como criar valor do nada ou receber dinheiro que nunca pertenceu ao agressor. Os nós não aceitarão uma transacção inválida como pagamento, e nós honestos nunca aceitarão um bloco que as contenha. Um agressor só pode tentar mudar uma das suas transacções para recuperar o dinheiro que gastou recentemente.

A corrida entre a cadeia honesta e uma cadeia de agressores pode ser caracterizada como um Passeio Aleatório. O evento de sucesso é a cadeia honesta ser estendida por um bloco, aumentando a sua vantagem em +1, e o evento de falha é a cadeia do atacante ser estendida por um bloco, reduzindo a diferença em -1.

A probabilidade de um intruso recuperar de um determinado défice é análoga a um problema da Ruína do Jogador. Suponha que um jogador com crédito ilimitado comece com um défice e jogua potencialmente um número infinito de testes para tentar chegar ao ponto de equilíbrio, o breakeven. Podemos calcular a probabilidade de ele chegar ao breakeven, ou que um intruso alguma vez apanhe a cadeia honesta, da seguinte forma:

Dada a nossa suposição de que p > q, a probabilidade diminui exponencialmente à medida que o número de blocos que o atacante tem de alcançar vai aumentando. Com as probabilidades contra ele, se ele não tiver muita sorte logo desde o início, as suas hipóteses tornam-se muito pequenas à medida que fica mais para trás.

Consideremos agora quanto tempo o destinatário de uma nova transacção precisa de esperar para ter a certeza de que o remetente não pode alterar a transacção. Assumimos que o remetente é um agressor que quer fazer o destinatário acreditar que lhe pagou durante algum tempo, e depois remete o pagamento para pagar a si mesmo. O receptor 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. Isto impede o remetente de preparar uma cadeia de blocos antes do tempo, trabalhando nele continuamente até ter a sorte de chegar suficientemente à frente e, em seguida, executar a transacção naquele momento. Uma vez que a transacção é enviada, o remetente desonesto começa a trabalhar em segredo numa cadeia paralela contendo uma versão alternativa da sua transacção.

O destinatário aguarda até que a transacção tenha sido adicionada a um bloco e z blocos foram ligados depois. Ele não sabe a quantidade exacta de progressos que o atacante fez, mas assumindo que os blocos honestos levaram o tempo médio esperado por bloco, o potencial progresso do atacante será uma distribuição de Poisson com valor esperado:

Para obter a probabilidade de o agressor ainda recuperar agora, multiplicamos a densidade de Poisson por cada quantidade de progresso que ele poderia ter feito pela probabilidade de ele recuperar a partir daí:

Convertendo para código 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;
}

Executando alguns resultados, podemos ver a probabilidade cair 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
Solving for P less than 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ão

Propusemos um sistema de transacções electrónicas sem depender da confiança. Começámos com o quadro habitual de moedas feitas a partir de assinaturas digitais, que proporcionam um forte controlo da propriedade, mas que está incompleta sem uma forma de evitar o gasto duplo. Para resolver isto, propusemos uma rede ponto-a-ponto usando a prova de trabalho para registar uma história pública de transacções que rapidamente se torna computacionalmente impraticável para um intruso mudar se nós honestos controlarem a maioria do poder de CPU. A rede é robusta na sua simplicidade não estruturada. Os nós funcionam todos de uma vez com pouca coordenação. Não precisam de ser identificados, uma vez que as mensagens não são encaminhadas para nenhum local específico e apenas precisam de ser entregues com o melhor esforço. Os nós podem sair e voltar a juntar-se à rede à vontade, aceitando a cadeia de prova de trabalho como prova do que aconteceu enquanto estiveram fora. Votam com o seu poder de CPU, expressando a sua aceitação de blocos válidos, trabalhando no seu alargamento e rejeitando blocos inválidos, recusando-se a trabalhar neles. Quaisquer regras e incentivos necessários podem ser aplicados com este mecanismo de consenso.

O documento original pode ser encontrado em bitcoin.org, em PDF.