Com novos lançamentos, softwares concorrentes de Bitcoin criam planos de longo prazo

As divisões no atual debate sobre o tamanho dos blocos ficaram mais pronunciadas esta semana após uma conferência privada e um pico na atividade da rede, que fez com que os usuários esperassem mais e pagassem mais para ter as transações confirmadas.

O debate em curso sobre como a blockchain do Bitcoin deve ser dimensionada para acomodar novos usuários foi supostamente um ponto de foco, já que o recenteMesa redonda Satoshi, um retiro exclusivo para convidados que uniu desenvolvedores e líderes empresariais. No entanto, os sinais sugerem que os participantes saíram do evento com umamais negativovisão do estado do discurso.

Mas mesmo com as tensões persistentes, o desenvolvimento de ambas as versões concorrentes do software Bitcoin – Bitcoin Clássico e Bitcoin CORE– continua enquanto os grupos fazem lobby por apoio da base mais ampla de usuários da rede.

No final de fevereiro, o Bitcoin CORE, o maior e mais antigo grupo de desenvolvedores da rede, lançou um novoroteiro, e junto com ele, o último lançamento – versão0,12,0– do software.

Logo depois, a equipe por trása implementação alternativa do Bitcoin O Bitcoin Classic anunciou seu roteiro para 2016 <a href="https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md">https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md</a> e, esta semana, lançou a versão mais recente do Classic, baseada na versão CORE 0.12.0.

Os lançamentos continuam sendo de interesse da comunidade, pois quando se trata de uma possível bifurcação do Bitcoin , o resultado pode ser o vencedor levando tudo.

Os principais tecnólogos acreditam que o grupo que conseguir chegar a um consenso em torno de sua visão verá rapidamente seus conjuntos de regras serem implementados e que, apesar das preocupações, o risco de a rede se dividir em duas versões incompatíveis do blockchain continua baixo.

O CEO da Bloq, Jeff Garzik, disse ao CoinDesk:

"A rede Siga rapidamente a bifurcação vencedora, [há] bilhões em incentivos."

Este artigo LOOKS a composição desses dois lançamentos e como ambos os grupos estão avançando para implementar sua visão para a rede Bitcoin .

Roteiro clássico

Em seu roteiro oficial de 2016, a equipe de desenvolvimento responsável pelo Classic divulgou o plano pretendido para lançar o software nos próximos 11 meses.

Durante a primeira fase, a equipe espera implementar o BIP 109, proposto originalmente para o CORE pelo desenvolvedor Gavin Andresen, que aumentaria o tamanho dos blocos de transação na rede Bitcoin dos atuais 1 megabyte (MB) por bloco para 2 MB por bloco.

O limite para essa transição seria quando 751 dos 1.000 blocos anteriores fossem minerados com o código suportando blocos maiores. Ao atingir esse limite de 75%, um período de ativação de 28 dias começaria.

Andresen disse ao CoinDesk:

"O perigo de um limite alto é que um minerador ou operador de pool pode ser coagido a exercer esse veto – eles podem ser ameaçados ou chantageados. Este não é um risco teórico. Vemos ataques de negação de serviço contra pools ou serviços 'votando da maneira errada' e houve até mesmo relatos de ameaças de morte."

O período de 28 dias deixou alguns na comunidade preocupados, mas Andresen comentou em um recentepostagem de blog que "vários dos principais mineradores de Bitcoin , bolsas [e] provedores de carteiras virtuais" indicaram que o período de ativação lhes dá "tempo suficiente" para alterar seu software.

Ele ainda defendeu o período de carência de 28 dias, comparando-o à última atualização da versão em bloco.

Andresen explicou que levou aproximadamente um mês para atingir 75% do hashrate e, uma vez que isso aconteceu, levou apenas mais sete dias para atingir 95% do hashrate.

Em outras palavras, ele acredita que T parece haver preocupação significativa em relação a uma janela de transição de 28 dias.

Fases futuras para o Classic

Caso o hard fork comece, o Classic entrará em sua segunda fase durante o segundo ou terceiro trimestre de 2016 com o objetivo de resolver problemas com o tamanho dos blocos.

"O objetivo da fase dois é eliminar as barreiras técnicas (devido a um protocolo de rede ineficiente) que limitam a capacidade da rede. Em vez de transmitir uma enorme explosão de dados quando um novo bloco é encontrado, uma pequena quantidade de dados será transmitida, referenciando dados de transação que já devem ter sido transmitidos", explicou Andresen.

Ele continuou afirmando que essas eficiências não são uma preocupação em blocos de 1 MB ou 2 MB, mas que o objetivo final da fase dois era "parar a tomada de decisão central sobre o tamanho máximo 'certo' e retornar à visão original de Satoshi de um sistema autorregulador".

O passo final para a equipe Classic é introduzir um limite dinâmico de tamanho de bloco, mas somente após "mineradores e empresas confirmarem que a fase dois resolveu com sucesso suas preocupações com o tamanho de bloco".

Uma proposta apresentada no roteiro é usar uma variação do tamanho de bloco adaptávelcom base no tamanho médio de bloco recente descrito em uma postagem de blog recente de Stephen Pair, CEO da BitPay.

"Para determinar o limite de tamanho do bloco, você calcula o tamanho médio do bloco em uma amostra recente de blocos e aplica um múltiplo", escreveu Pair.

Pair continua explicando que, diferentemente do tamanho médio de bloco, a mediana é muito mais difícil de manipular. Com um tamanho médio de bloco, os mineradores poderiam inflar o tamanho do bloco com suas próprias transações ou, por outro lado, não colocar transações em blocos. Com a mediana, "você precisaria de uma ação coordenada de mais de 50% da capacidade de mineração".

Claro, se alguém controlasse mais de 50% da capacidade de mineração, o Bitcoin teria problemas maiores a enfrentar do que o limite de tamanho do bloco.

Junto com o aumento do tamanho do bloco, a Classic está planejando realizar uma conferência "onde essas e futuras soluções e preocupações de dimensionamento podem ser discutidas entre a comunidade".

O novo lançamento, publicado em 7 de março, incorpora elementos do Bitcoin Core 0.12.0, mas deixa notavelmente o recurso de substituição por taxa (RBF) opcional, com o qual os usuários podem retransmitir transações com taxas mais altas, desde que T tenham sido incluídas em um bloco, definido como desabilitado por padrão.

CORE lança versão mais recente do software

O Equipe de desenvolvimento CORE anunciou o lançamento da v0.12.0 em 23 de fevereiro, que os desenvolvedores descreveram como potencialmente "a ONE até agora, com melhorias mais significativas do que qualquer outra antes".

A equipe enquadrou o lançamento como sendo focado na otimização do desempenho geral do software. Em muitos casos, o objetivo era reduzir os recursos computacionais necessários ou melhorar a velocidade com que as ações podem ocorrer.

Em novembro de 2015, o desenvolvedor do CORE , Pieter Wuille, enviou uma Request de pullpara mudar para uma validação ECDSA baseada em libsecp256k1. Nela, ele explicou que haveria três benefícios em fazer essa transição.

"A validação de assinatura é entre 2,5 e 5,5 vezes mais rápida; o código de consenso não depende mais do OpenSSL ou de seu analisador de assinatura; remove a vinculação com o OpenSSL do libconsensus", escreveu ele.

Também houve implicações de segurança ao abandonar o OpenSSL.

"O OpenSSL é muito abrangente em suas capacidades, mas esse enorme conjunto de recursos significa que sua superfície de ataque é bastante grande como resultado", escreveu a equipe em seu anúncio da versão 0.12.0.

Após passar quase três anos em desenvolvimento, o libsecp256k1 foi mesclado com o cliente Bitcoin CORE , resultando no que a equipe diz ser uma melhoria de sete vezes na velocidade de validação de assinatura. Além disso, como o libsecp256k1 é focado principalmente na validação de assinatura, a área para explorações de segurança é muito menor, de acordo com o CORE.

Dando continuidade à otimização, a equipe também implementou um mecanismo para evitar falhas de nós devido aos limites do pool de memória.

Outra mudança importante tem a ver com a forma como os nós armazenam transações que ainda T foram incluídas em um novo bloco.

Em uma postagem de blog publicada antes deledeixou a equipe do Bitcoin CORE, o desenvolvedor Mike Hearn alertou sobreo potencialpara uma redução significativa nos nós da rede.

Conforme as transações são feitas, elas entram no pool de memória onde são mantidas até que sejam exibidas no blockchain. Conforme mais transações ocorrem, mais são forçadas para o pool de memória. Para nós que têm muita memória, isso T é um problema; no entanto, aqueles que estão operando com quantidades mínimas de memória enfrentam uma situação potencialmente ruim.

Hearn descreveu três cenários possíveis que poderiam surgir dessa circunstância:

"O nó pode ficar incrivelmente lento ao entrar no inferno de swap; o nó pode travar ao tentar alocar memória e falhar; o nó pode ser morto pelo kernel do sistema operacional."

Para neutralizar isso, o CORE introduziu um recurso chamado limitação de pool de memória, que define um limite rígido padrão para o tamanho do pool de memória; especificamente, ele é definido como 300 MB na versão 0.12.0.

O que acontece efetivamente é que, à medida que um nó começa a receber mais transações, se o pool de memória atingir o limite de 300 MB, o nó primeiro descartará as transações que oferecem a menor taxa por bye, em vez de simplesmente aceitar mais transações.

Redução de custos de recursos

0.12.0 também introduz um fator de limitação de tráfego de upload. Com nós constantemente retransmitindo transações pela rede, isso pode resultar em aumento da quantidade de recursos de upload, colocando um fardo em nós individuais.

Um fator de limitação de tráfego de upload permite que o operador limite a quantidade de dados que são enviados e compartilhados com o resto da rede Bitcoin . No caso de atingir esse limite, o nó servirá os blocos que foram solicitados na semana passada, minimizando assim as necessidades de recursos.

Para evitar ainda mais que os nós fiquem sobrecarregados, a equipe introduziu a redução de carteira.

Atualmente, os nós armazenam uma cópia completa do blockchain. No momento em que este artigo foi escrito, isso significa que cada nó precisa armazenar 57,8 GB de dados de transação. Quanto maior isso for, mais espaço de armazenamento será necessário.

O novo 'modo podado' permite que aqueles que usam a carteira Bitcoin CORE reduzam o espaço em disco necessário de 60 GB para apenas 2 GB.

"Isso significa que o nó se concentrará apenas em monitorar as saídas não gastas e esquecerá os blocos processados anteriormente, bem como as saídas que foram gastas", explicou a equipe.

Embora tenha havido controvérsia com oinclusão de substituição por taxa, fundamentalmente, a nova versão se concentrou em tornar a operação dos nós menos intensiva em recursos.

Como onúmero de nós caiu nos últimos anos, reduzir os recursos necessários deve resultar em mais usuários optando por executar nós que validam completamente o blockchain. Quanto mais nós na rede, mais seguro o Bitcoin se torna.

Imagem de caminhante perdidovia Shutterstock