Bitcoin Core :: Escalonamento na cadeia

MEDIA TEAM

A postagem a seguir tem como objetivo destacar os marcos de desenvolvimento que ajudaram a preservar uma experiência confiável para os usuários do software cliente Bitcoin ao longo dos anos. Apresentamos diversas atualizações que foram críticas para manter as propriedades descentralizadas da rede e mitigar a carga de recursos de seus participantes. Descrevemos como foram feitas inúmeras otimizações de ordens de grandeza para que a rede Bitcoin pudesse suportar o crescimento da atividade de transações sem aumentar drasticamente os custos de participação para usuários novos e existentes. Por fim, observamos como todas essas melhorias se enquadram em uma abordagem mais ampla e sistemática para o desenvolvimento de protocolos que utiliza insights de conceitos de complexidade Big-O e aproveita algoritmos mais inteligentes que fazem uso mais eficiente dos recursos da rede.

Cache de Assinatura

Lançamento: Bitcoin-Qt 0.7.0

A verificação das assinaturas ECSDA é uma das operações computacionalmente mais pesadas realizadas no nível dos pares. Como precisam ser verificados para cada transação, qualquer validação supérflua leva a uma sobrecarga significativa de recursos para o usuário final. Esse foi o caso das primeiras versões do software, que verificavam as assinaturas antes de entrarem em um mempool de nó e depois de serem recebidas em um bloco.

Para ganhar eficiência, os desenvolvedores criaram um cache que permite aos nós armazenar assinaturas previamente validadas e ignorar o trabalho redundante assim que as transações chegarem a um bloco aceito.

Além disso, o cache de assinatura também mitiga um vetor DoS introduzido pelo potencial de transações especificamente criadas para paralisar clientes Bitcoin.

Mais informações

Ultraprune + LevelDB

Lançamento: Bitcoin-Qt 0.8.0

O Ultraprune foi uma das primeiras grandes atualizações do software Bitcoin com o objetivo de resolver a sobrecarga associada à validação de dados de transação do blockchain. As versões anteriores do cliente de referência Bitcoin mantinham um índice de todas as saídas de transações, gastas ou não. O Ultraprune reduziu significativamente o tamanho desse índice com a percepção de que você só precisava monitorar as saídas não gastas, e uma saída – uma vez gasta – pode ser totalmente removida dos índices.

Para conseguir isso, foi implementado um novo layout de banco de dados que aloca as saídas de transações não gastas em um formato compacto personalizado, a fim de reduzir o tamanho das informações necessárias para o trabalho de validação.

Para otimizar ainda mais o desempenho do sistema, o Ultraprune foi introduzido em paralelo com o LevelDB, que descontinuou a antiga tecnologia de banco de dados BDB. No geral, o impacto foi notável: dependendo do hardware, os usuários poderiam experimentar uma melhoria de pelo menos uma ordem de magnitude ao validar dados de blockchain. Essa nova estrutura de banco de dados também abriria caminho para trabalhos futuros de poda e implementações mais leves de nós completos do Bitcoin.

Mais informações

Verificação de script paralelo

Lançamento: Bitcoin-Qt 0.8

Embora tenha sido uma mudança mais sutil, a transição da verificação de script para um processo mais paralelizado eliminou uma sobrecarga significativa dos tempos de validação de bloco. As versões anteriores do software validavam os dados do script das entradas entre cada busca UTXO, criando um problema de desempenho devido ao processamento linear de todas as ações. Isto viola um princípio básico para a concepção de processos de computação eficientes, que determina que a computação deve acontecer simultaneamente com trabalhos de E/S, sempre que possível. Pensando nisso, o mecanismo de validação de bloco foi reprojetado para poder alocar verificações de script para threads paralelas para que sua verificação possa acontecer antes mesmo de o cliente terminar de buscar todos os UTXOs do bloco. Para conseguir isso, as ações de verificação de script são armazenadas em uma fila após o processamento da transação e são tratadas separadamente de outros trabalhos de validação de entrada.

Como consequência, a sincronização até a ponta da cadeia acontece muito mais rapidamente, fazendo uso mais eficiente dos recursos do peer. Durante os testes da implementação, os desenvolvedores notaram uma aceleração de 35% a 100% ao comparar com versões anteriores do software.

Mais informações

Lançamento: Bitcoin Core 0.10

Esforçando-se para melhorar ainda mais o tempo de download inicial do bloco, o projeto Core introduziu no final de 2014 uma importante rearquitetura do mecanismo usado pelos nós para sincronizar com a cadeia válida de maior trabalho.

Inicialmente, o processo de inicialização de um novo cliente Bitcoin envolveria um usuário buscando dados de bloco de um único ponto, com a consequência de que qualquer interrupção ou diminuição na qualidade da conexão paralisaria significativamente o processo. Com um tamanho de blockchain cada vez maior, isso resultaria em um tempo de espera às vezes enorme para a conclusão da sincronização, com uma grande porcentagem de usuários relatando períodos de vários dias, dependendo de seu hardware.

A primeira sincronização dos cabeçalhos atenua completamente esse problema usando um novo método que envolve primeiro os nós baixando e validando os cabeçalhos dos blocos de um único ponto e, em seguida, buscando os dados dos blocos em paralelo de uma infinidade de outros.

Reclamações sobre o tempo inicial de download do bloco têm prevalecido desde os primeiros dias do Bitcoin. Com a primeira sincronização dos cabeçalhos, o software deu um grande passo em termos de usabilidade para novos usuários. Em vez de perder muitas horas em sincronização não confiável, os nós agora poderiam aproveitar toda a sua rede de pares e reduzir significativamente o tempo de inicialização. Com o uso de algoritmos mais inteligentes, outra melhoria assintótica foi feita neste aspecto crucial da sustentabilidade a longo prazo do Bitcoin.

Mais informações

Bloquear remoção de arquivo

Lançamento: Bitcoin Core 0.11

A remoção de dados antigos foi um conceito descrito pela primeira vez por Satoshi Nakamoto em seu white paper como uma solução potencial para a escassez de espaço em disco. Infelizmente, o projeto original era inadequado e não pôde ser implementado conforme imaginado pelo seu criador. Sete anos depois, com o blockchain atingindo mais de cem gigabytes, a introdução da remoção de arquivos em blocos como a conhecemos hoje representa um grande benefício para usuários com recursos limitados.

A remoção de arquivos em bloco aproveita o trabalho anterior com o ultraprune; os usuários que baixaram e validaram inicialmente o blockchain agora podem descartar dados brutos com mais de 288 blocos. Como esses nós ainda preservam o conjunto UTXO completo, eles continuam capazes de validar dados não gastos, o que é suficiente para validar totalmente novos blocos e proteger contra possíveis gastos duplos.

É claro que a poda implica que ainda haja um número suficiente de nós de arquivamento para servir dados completos do blockchain. Por outro lado, esta inovação expande a gama de validadores, tornando mais rentável permanecer um. No geral, a solução é uma adição bem-vinda às opções disponíveis para reforçar a diversidade da rede.

Mais informações

libsecp256k1

Lançamento: Bitcoin Core 0.12

Após as medições, foi determinado que o próximo passo após resolver as ineficiências do download do blockchain seria enfrentar o gargalo da verificação de transações e sua pesada carga computacional. O projeto Core decidiu fazer isso usando uma nova biblioteca projetada para otimizar o desempenho das operações ECDSA. ECDSA (Algoritmo de Assinatura Digital de Curva Elíptica) é a espinha dorsal da infraestrutura de chave pública do Bitcoin e é usado sempre que um usuário movimenta moedas assinando uma mensagem com suas chaves privadas. Essas assinaturas precisam ser verificadas por todos os pares da rede para preservar a integridade do livro-razão.

Os primeiros desenvolvedores há muito consideravam a transição da biblioteca OpenSSL original e após 5 anos de considerações de design, testes e revisão por pares, a biblioteca libsecp256k1 de Pieter Wuille foi introduzida como sua substituta. Como esperado, a implementação levou a uma grande aceleração do processo de validação de assinatura por trás de cada transação Bitcoin. Os benchmarks relataram melhorias de 5 a 7 vezes em relação à implementação do OpenSSL. Para os usuários, isso significaria economizar até metade do tempo de inicialização normalmente dedicado às operações do ECSDA, uma das etapas mais trabalhosas na sincronização de um novo nó do zero.

Considerando o crescimento da atividade de transações de Bitcoin, esta atualização foi essencial para preservar uma experiência de usuário razoável para os pares da rede. Mais uma vez, a redução da complexidade algorítmica proporcionou aos utilizadores uma utilização mais eficiente dos seus recursos e reduziu drasticamente a barreira de entrada para novos participantes.

Mais informações

Limitação do pool de memória

Lançamento: Bitcoin Core 0.12

Uma vulnerabilidade de longa data do software Bitcoin era a sua incapacidade de lidar adequadamente com a inundação do conjunto de memória de um par. Na verdade, um invasor poderia enviar um grande número de transações de baixo valor e taxas baixas que se acumulariam no pool de memória até sobrecarregar a memória disponível. Isso faria com que nós com recursos de RAM relativamente baixos travassem durante períodos de atividade incomum. A única medida eficaz contra isso foi aumentar a taxa mínima de retransmissão do software, o que ainda não deixava nenhum limite máximo para o tamanho potencial do mempool.

Para remediar isso, os desenvolvedores do projeto Core implementaram um tamanho máximo estrito de pool de memória com políticas de despejo específicas, classificando as transações por taxas e despejando primeiro as que pagam menos. Para evitar que transações com a mesma taxa entrem novamente no pool de memória, o nó aumentará sua taxa de retransmissão mínima efetiva para corresponder à da última transação despejada mais a taxa de retransmissão mínima inicial.

A configuração do tamanho máximo é deixada para os usuários, sendo o tamanho padrão 300 megabytes. Esta atualização proporciona uma experiência muito mais robusta para usuários de nós com recursos limitados e, em geral, torna toda a rede mais confiável.

Mais informações

Na Parte 2, discutiremos melhorias mais recentes que se baseiam nas tecnologias apresentadas acima e melhoram ainda mais a robustez e o potencial de escalabilidade da rede.

Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *