A História do Bitcoin: conheça sobre a Blocksize War
Qual seria então a motivação para implementar uma restrição de tamanho de bloco?
Dando continuidade à nossa série de artigos sobre o Bitcoin, na terceira parte, escrevemos sobre um importante acontecimento na história da rede, a Blocksize War. O artigo anterior pode ser conferido aqui.
Esse foi um conflito entre mineradores e usuários da rede sobre o tamanho que cada bloco deveria ter. Para elucidação, um bloco maior seria capaz de computar mais informações e consequentemente mais transações, dando maior escala à rede.
Qual seria então a motivação para implementar uma restrição de tamanho de bloco?
As configurações originais sobre tamanho de blocos
No momento da criação do Bitcoin, Satoshi Nakamoto não havia programado limite algum sobre o tamanho de blocos, entretanto havia uma limitação física de 32MB, consequência do tamanho máximo enviado em mensagens peer-to-peer na época. Dessa forma, caso houvesse blocos de tamanho superior, o protocolo estaria sujeito a um grande risco sistêmico.
Em julho de 2010, contudo, sem qualquer anúncio ou argumentação sobre a questão, Satoshi Nakamoto programou uma limitação de 1M para o tamanho máximo de cada bloco. Como os blocos tinham tamanho de poucos kilobytes, a mudança passou praticamente despercebida. Suas intenções quanto a essa limitação nunca foram conhecidas, já que as suas últimas interações em fóruns se deram no mesmo ano.
Quando identificado, o limite incomodou alguns usuários que enxergavam como um problema à adoção do protocolo por novos indivíduos. O racional era de que blocos pequenos seriam capazes de efetuar poucas transações e que a escala do protocolo seria bastante reduzida com blocos de apenas 1MB. Porém, levou tempo até que a discussão ganhasse tração e engajamento nos fóruns de discussão da rede. O primeiro movimento coletivo e os primeiros esforços para lidar com a restrição surgiram entre 2014 e 2015.
As discussões sobre o novo tamanho máximo
A primeira proposta de novo tamanho de bloco foi feita por Jeff Garzik, um expert de Bitcoin e CEO de uma empresa que fornece infraestrutura para aplicações em Web 3.0. A BIP 100 (Bitcoin Improvement Proposal) publicada em 2015 e previa um aumento gradual até 32MB, mas num approach de mercado livre de tamanho de blocos.
A definição de tamanho de blocos seria sempre em relação ao próximo bloco e decidida em conjunto pelos próprios mineradores, de forma que a eficiência da rede e o melhor ambiente para os participantes sejam sempre considerados.
A dinâmica foi bem recebida de forma geral, mas os participantes não queriam entregar todo o poder decisório aos mineradores. Esse misto de aceitação e crítica fez com que a proposta não avançasse naquele momento.
Pouco tempo após a primeira proposta, Gavin Andresen propôs um aumento diferente, para 20MB, de forma definitiva, na BIP 101. Naturalmente, a proposta causou bastante ruído nos fóruns e no debate, dado o expressivo aumento sugerido e dado que não havia sido discutido com outros core developers da rede.
O approach de Andresen era de um modelo mais previsível. O limite máximo, que fora discutido com mineradores após a sua primeira manifestação e assim reduzido a 8MB inicialmente, passaria a duplicar a cada 2 anos. A duplicação aconteceria por 20 anos, até alcançar sua limitação final em 2036.
O SegWit e o New York Agreement
Em maio de 2017, dezenas de empresas do segmento, inclusive mineradores, propuseram uma solução simples que traria um aumento de capacidade à rede. A proposta liderada pelo Digital Currency Group previa que, com a ativação do SegWit (mais à frente na linha do tempo e em nossa série de artigos) e com a sua capacidade de escala, bastaria aumentar o tamanho a 2MB para ter uma capacidade de processamento de 4MB.
Muitos enxergaram a proposta e suas consequências como um takeover dessas empresas sobre a rede, indo contra o pilar de descentralização da rede. Houve conflito e conciliação entre as empresas e os outros participantes da rede sobre o tema. Porém, mais uma vez, não houve consenso e sucesso no aumento de escala da rede.
Em 2017 ainda, houve um hard fork do Bitcoin que traria uma versão do protocolo com maior capacidade de processamento. O Bitcoin Cash nasceu com o objetivo de resolver a questão da escalabilidade. O limite de 1MB seria aumentado e o BCH poderia ser facilmente utilizado em transações peer-to-peer, com transações mais rápidas e taxas mais baixas.
O próprio Bitcoin Cash passou ainda por um hard fork, que originou uma versão limitada a 8MB e que foi expandida a 32MB desde então. Como boa parte dos hard forks, o BCH segue como uma alternativa paralela e com menor adoção que o Bitcoin.
A conclusão do debate veio justamente com a ativação da Atualização SegWit, após a conciliação, em agosto de 2017. A capacidade de escala era de duas vezes, e efetivamente foi para algo além, sem alterar o último código de Satoshi Nakamoto. Nenhuma nova proposta foi feita desde então, e a Lightning Network, viabilizada pelo SegWit, funciona como uma camada de pagamentos rápidos e de baixo custo.
__________________________________________________________________________________
Alexandre Ludolf é CIO da QR Asset. Engenheiro pela PUC-Rio e Mestre em Economia pela FGV-SP, com 18 anos de experiência como gestor de fundos de investimento e passagem por diversas instituições de renome como Santander, Safra e Mirae Asset. Alexandre possui vasta experiência na gestão de fundos de investimento e é um entusiasta de tecnologia, investidor de ativos digitais e startups.
