Proposta de dimensionamento 'Segwit2x' do Bitcoin: Desenvolvedores CORE assumem posição crítica

Dias após uma proposta amplamente apoiada, mas controversa, para aumentar a capacidade de transação do bitcoin ter sido revelada, detalhes técnicos sobre o plano estão vindo à tona.

Pode não ser particularmente surpreendente se você estiver familiarizado com o antigo debate sobre o tamanho dos blocos do bitcoin, mas o código provisório para o que está agoraconhecido como 'Segwitx2'T foi especialmente bem recebido pela comunidade de desenvolvedores de código aberto do projeto.

Um assim chamado Request de pulldo cofundador do Bloq, Jeff Garzik, por exemplo, foi recebido com um coro de comentários céticos. A maioria era bastante técnica, vinda de alguns desenvolvedores que trabalharam com Bitcoin por um longo tempo, mas a resposta pareceu se resumir a: 'Por que o grupo T está usando um método mais seguro – um que muitos de nós sugerimos antes?'

Alguns dos comentários pareciam ter um tom de zombaria. "Este pull Request é bem estranho", afirmou o líder de pesquisa de blockchain da Colu, Udi Wertheimer, em sua resposta.

"Ainda não há testes", afirmou simplesmente outro desenvolvedor.

Ainda assim, Garzik, um ex-desenvolvedor do Bitcoin CORE empregado pelo processador de Bitcoin BitPay, acolheu o feedback e, mais tarde naquele dia, respondeu em Médio. "Este foi umponto de partida", disse ele, indicando sua posição de que a implementação atual no GitHub deve ser um trabalho em andamento.

Garzik acrescentou que concorda com o feedback recebido e endossa fazer alterações que permitam que o código seja compatível com a versão existente do Segregated Witness (ou SegWit) – um plano para escalar o blockchainproposto pelos Colaboradores do Bitcoin COREem 2015.

"Se o resultado maximizar a compatibilidade ainda mais, reutilizar os testes existentes ainda mais, isso é uma WIN. Progresso para a frente", escreveu Garzik.

Medos de garfo

No entanto, apesar de todo o escárnio implícito, esse debate entre desenvolvedores pode ser visto como um exemplo de "colaboração" e revisão por pares.

Provavelmente vale a pena notar que nenhum dos desenvolvedores voluntários por trás do Bitcoin CORE assinou o 'acordo' sobre a proposta, anunciada pela primeira vez pela empresa de portfólio de investimentos DCG na semana passada. Conforme sugerido nas preocupações acima, isso ocorreu em parte por questões técnicas e em parte porque alguns T acreditam que um hard fork seja necessário agora.

Alguns argumentam que aumentos de capacidade além do SegWit podem ser obtidos de outras maneiras compatíveis com versões anteriores, T o risco de expulsar alguns participantes da rede do sistema.

Uma vez que a proposta foi lançada, e mesmo muito antes disso, os desenvolvedores deram feedback técnico sobrequal a melhor forma de implementar um hard fork, o que pode explicar uma pitada de amargura dos desenvolvedores em discussões recentes.

Mas, mesmo que muitos deles T estejam interessados ​​nos detalhes da proposta, até agora isso T impediu os desenvolvedores de tentar melhorar a implementação.

"Escrevi o BIP91 para tentar tornar a proposta mais sensata", disse o desenvolvedor do Bitcoin James Hilliard, acrescentando que, aos seus olhos, o cronograma atual do hard fork é "completamente irrealista".

Outros deram mais peso à proposta, que tem apoio de mais de 60 empresas e mais de 80% dos operadores e empresas de pools de mineração de bitcoin.

"Acho que deveríamos buscar construir a partir da proposta e melhorá-la", disse o CEO da Blockstream, Adam Back. No geral, Back surgiu como talvez uma das vozes mais positivas, com comentários sugerindo que a resistência dos desenvolvedores poderia criar problemas de percepção.

Em particular, ele está tentando direcionar o interesse para uma proposta chamada 'spoonnet', um ramo depesquisa de hard fork do colaborador do Bitcoin CORE, Johnson Lau.

O colaborador do Bitcoin CORE, Eric Lombrozo, que trabalhou no código do SegWit, teve uma opinião colaborativa semelhante. "Vou trabalhar duro com [o fundador e CEO do DCG, Barry Silbert] para fazer disso um sucesso", ele escreveunas redes sociais, embora não sem algumas ressalvas.

Muito, muito cedo?

O ponto principal, porém, é que muitos desenvolvedores T acham que a proposta seja ONE.

O colaborador do Bitcoin CORE, Bryan Bishop, resumiu as preocupações de forma mais sucinta:

"Eu acho que, no final das contas, o hard-fork [DCG] vai falhar em fazer a transição segura de toda a rede. Não há proteção de replay. É um cronograma irracionalmente curto. Ele T faz uso dos esforços de pesquisa do hard-fork anterior."

"Acho que toda a indústria precisa acordar e perceber quanto tempo essas coisas levam", ele acrescentou, argumentando que a revisão por pares e os testes levam muito tempo. (Outros desenvolvedores e usuários de Bitcoin também questionaram o cronograma de seis meses.)

Talvez a questão mais importante seja: se o grupo abordar essas preocupações técnicas, mais desenvolvedores o apoiariam?

A resposta, como de costume, foi complicada e mista, com alguns expressando o desejo de considerar todas as compensações.

"Há um sentimento geral entre os desenvolvedores do Bitcoin CORE de que uma quantidade tremenda de capacidade pode ser obtida por soft forks e atualizações de compatibilidade com versões anteriores. T acho que os desenvolvedores do Bitcoin CORE vão Rally em torno de um hard fork no futuro NEAR , especialmente não um ditado por uma reunião Secret a portas fechadas", disse Bishop.

O desenvolvedor Jonas Schnelli, conhecido pela biblioteca libbtc, disse que possivelmente poderia apoiar um hard fork para aumentar o tamanho do bloco se tivesse mais tempo.

"Estou feliz com o SegWit2x se ele puder reduzir para 80% sem ser incompatível com a implementação [SegWit] existente", disse Schnelli. "E fazer o [hard fork] depois."

Outros simplesmente T acham que isso vai funcionar, parecendo tratá-lo com o mesmo interesse com que trataram Bitcoin XT ou Bitcoin Classic – outras propostas de hard fork que falharam (embora esse novo esforço tenha conquistado mais apoio).

Outras opções

Muitos desenvolvedores expressaram o sentimento de que a capacidade de transação poderia ser aumentada de outras maneiras, talvez mais seguras. Por um ONE, alguns tendem a pensar que o SegWit é uma solução melhor por si só – sem o hard fork que o acompanha, o que poderia levar a uma divisão de rede.

"No SegWit2x, não há razão técnica para acoplar [Segwit] com um [hard fork]. Apenas política. E o Bitcoin foi criado para ficar longe da política... é por isso que eu principalmente [não] o apoio", disse Schnelli.

O colaborador do Bitcoin CORE, Luke Dashjr, estava aberto a outra proposta recente, chamada COOP, que combina um monte de pesquisas de hard-fork em uma proposta de melhoria do Bitcoin (BIP), para uma implantação mais segura. Mas ele tinha reservas sobre aumentar o tamanho do bloco tão rapidamente.

Dashjr promoveu ativamente o BIP148, um controverso mecanismo de compatibilidade com versões anteriores que foiganhando impulsoe que também tem um prazo para ativação, embora alguns se preocupem que isso também possa resultar em uma divisão da cadeia.

Ele concluiu:

"De qualquer forma, o BIP148 começa em agosto."

Aviso Importante: CoinDesk é uma subsidiária do Digital Currency Group (DCG).

Homem na escada de construçãoimagem via Shutterstock