Os codificadores de Bitcoin enfrentam um velho dilema: como atualizar uma rede inteira

Um antigo debate está ressurgindo na comunidade de desenvolvedores de Bitcoin , ressaltando um dos desafios críticos enfrentados pelos sistemas descentralizados: como atualizar o software quando aparentemente ninguém está no comando.

O catalisador desta vez é chamado Taproot/Schnorr, uma atualização de Política de Privacidade e dimensionamento que levou anos para ser feita e que foi vista progresso emocionante recentemente, especialmente agora que o código na forma de "pull Request" está sendo revisado e testado, trazendo uma mudança discutida pela primeira vez anos atrás para mais perto da realidade.

A mudança de código em si T é controversa entre os desenvolvedores até agora. O que éem discussão é a melhor maneira de ativar a mudança, tornando finalmente possível o envioBitcoin (BTC) transações dessa nova maneira.

No cerne do porquê de haver uma questão sobre isso é que o Bitcoin não tem um líder e é distribuído pelo mundo. Como toda a rede atualiza suavemente de uma forma que seja compatível com versões anteriores, permitindo que aqueles com versões mais antigas do software continuem participando? Qual é a melhor maneira para o Bitcoin fazer esse tipo de mudança sem interrupção?

Para ser claro: o código do bitcoin é atualizadoquase todo diapela rede global de desenvolvedores do projeto de código aberto. Mas mudanças de código "consensuais", que atingem uma parte mais profunda do Bitcoin, exigem um "soft fork", que por sua vez requer uma certa quantidade de coordenação para passar sem problemas.

"Há uma série de designs de soft-fork que recentemente têm feito um bom progresso em direção à implementação e adoção futura. No entanto, por várias razões, os métodos de ativação ... têm tido discussão limitada,"Bitcoin COREo colaborador Matt Corallo escreveu emum e-mail para a lista de desenvolvedores de Bitcoin do mês passado que reabriu o debate.

Existem duas opções principais para promulgar um soft fork. Uma opção, Bitcoin Improvement Proposal (BIP) 9, foi usada para alguns soft forks no passado. Ela garante que mineirossão preparadas antes de um soft fork, para garantir que uma mudança se propague suavemente por toda a rede. Uma objeção comum a essa abordagem é que ela dá muito poder aos mineradores.

Alternativamente, há o BIP 8, também conhecido como soft fork ativado pelo usuário (UASF), que ativa independentemente de os mineradores sinalizarem que estão prontos ou não. Dependendo da execução, essa abordagem pode causar outros problemas, advertiu Corallo.

Aula de história

A discussão começou em 2017, quando o BIP 9 foi usado para ativar o Segregated Witness, ou SegWit, uma mudança integral ao grande debate de escala do bitcoin. Para proteger os mineradores de minerar blocos inválidos e perder dinheiro, o SegWit não seria ativado até que 95 por cento dos mineradores levantassem uma bandeira mostrando que estavam prontos.

A maioria dos pools de mineração (grupos de mineradores que combinam seu poder computacional na rede) declararam que não apoiariam o SegWit – essencialmente vetando-o – a menos que fosse pareado com um aumento no parâmetro de tamanho do bloco. (O misterioso criador do Bitcoin havia estabelecido o teto em 1 megabyte, limitando o número de transações que poderiam ser colocadas em blocos, que são publicados a cada 10 minutos ou mais.)

Essa era uma demanda controversa que muitos acreditavam que poderia levar à centralização da rede (e que T poderia ser executada com sucesso a menos que o Bitcoin fosse centralizado, de qualquer forma).

Resumindo a história, o incidente mostrou que os pools de mineração poderiam usar o limite de 95% para extrair outras mudanças em vez do propósito pretendido: ajudá-los a se adaptar à mudança para que T perdessem dinheiro.

Muitos bitcoiners não gostaram disso, vendo isso como uma tentativa dos mineradores de usar seu poder para promover uma mudança que nem todos os usuários queriam.

Enquanto esse debate se acirrava, um desenvolvedor misterioso que atendia pelo pseudônimo Shaolinfry apontou que os bitcoiners ainda poderiam fazer a atualização. A raiz da ideia é que os usuários e as exchanges de Bitcoin devem decidir se uma mudança deve ser feita, e os mineradores Siga seus desejos – e não o contrário. Esse método foi usado para ativar outras mudanças de Bitcoin . Shaolinfy formalizou essa ideia no BIP 8, também conhecido como UASF.

Uma grande faixa de usuários declarou em alto e bom som apoio ao SegWit UASF nas mídias sociais e começou a executar o software. Isso pareceu ter o efeito desejado. Antes do dia em que o UASF seria ativado, os mineradores começaram a sinalizar apoio ao SegWit.

Notavelmente, havia alguns sabores de UASF circulando durante esse período tumultuado, um mais cauteloso (e com tempo mais conservador) e menos controverso do que o outro. Mas sem entrar em detalhes, a conclusão para alguns desenvolvedores de Bitcoin foi que UASF era uma maneira melhor de promulgar mudanças.

Na época, Rusty Russell, um desenvolvedor da startup de Bitcoin Blockstream, chegou a se desculpar por ter participado da construção do BIP 9.

"Eu T esperava que esse checkpoint fosse usado como um ponto de estrangulamento para resgatar a rede. Isso muda significativamente o modelo de risco;BIP-8é agora um método muito superior para atualizações de rede, onde os mineradores podem apenas acelerar o processo, não bloqueá-lo", escreveu ele em um Mediumpublicar.

Longas memórias

Lembrando de todo esse drama, alguns desenvolvedores estão cautelosos sobre usar o BIP 9 novamente para Schnorr/Taproot, ou outras mudanças futuras.

"Acho que o BIP 9 é um fracasso comprovado",disse Bitcoin CORE o desenvolvedor Luke Dashjr, respondendo a Corallo, passou a fornecer razões técnicas para sua objeção. Durante o debate sobre escala, Dashjr foi um dos proponentes mais vociferantes de um UASF para empurrar o SegWit.

Alex Bosworth, desenvolvedor da startup Lightning Labs, expressou uma Opinião semelhante, baseada em parte no drama recente em torno do Bitcoin Cash (BCH), uma Criptomoeda menor que se separou do Bitcoin em 2017.

Um grupo considerável de pools de mineração de Bitcoin Cash recentementepropostoque parte do BCH de cada novo bloco deveria ir para um fundo de desenvolvimento, o que Bosworth vê como outro exemplo de pools de mineração exibindo seus músculos de uma forma que é ruim para a descentralização das Criptomoeda .

"Eu sei que o pensamento comum para a implantação do soft fork é tentar o método tradicional do minerador amigável. Mas um bom [um terço] do nosso hashrate atual acabou de se organizar em um cartel para fins de censura para roubar subsídios de moedas", tweetouBosworth, que trabalha em infraestrutura para a rede lightning rápida e escalável.

É por isso que ele apoia um método UASF, embora com um horizonte de tempo mais longo.

"Um UASF de queima lenta parece mais apropriado para mim", acrescentou.

Síntese

Mas alguns, pedindo cautela, temem que considerar os UASFs como o único método de ativação possa abrir a possibilidade de aprovar mudanças que podem prejudicar o Bitcoin.

Por exemplo, um motivo pelo qual os desenvolvedores inicialmente gostaram do BIP 9 é que o limite de 95 por cento poderia fornecer uma espécie de rede de segurança. Se um problema viesse à tona enquanto os pools de mineração estivessem trabalhando para atualizar seu software, então os pools poderiam interromper a mudança. É mais difícil interromper uma ativação UASF uma vez iniciada.

É por isso que Corallo repropôs uma ideia antiga, algo como uma mistura de BIP 8 e BIP 9. O soft fork começaria com BIP 9. Então, se falhasse ao longo de um ano devido a "objeções irracionais", os usuários poderiam debater e se reagrupar ao longo de um período de seis meses. Depois disso, se a mudança for definitivamente algo que a comunidade quer, eles podem tentar BIP 8 ao longo do período de mais um ano.

Alguns desenvolvedores podem argumentar que esse período de tempo é longo demais para uma mudança sem "objeções irracionais". Mas Corallo pediu paciência.

Descobrir se as objeções são realmente "irracionais" pode levar algum tempo. "No caso de falhar, o processo BIP 9, de fato, fornece uma boa oportunidade de aprendizado quanto ao nível de prontidão da comunidade e desejo por uma determinada mudança", disse ele.

"Desenvolver Bitcoin não é uma corrida. Se tivermos que fazer isso, esperar 42 meses garante que não estamos estabelecendo um precedente negativo do qual nos arrependeremos à medida que o Bitcoin continua a crescer", disse ele. Os leitores podem ler o raciocínio completo de Corallo, bem como muitas das respostas diferenciadas dos desenvolvedores aqui.

E embora Russell parecesse bastante contra o BIP 9 em 2017, ele disse ao CoinDesk que agora concorda com essa abordagem híbrida.

"Como a tentativa dos mineradores de bloquear as mudanças T funcionou, e T sofremos muito com o atraso, T me importo com a ativação do BIP-9", ele disse. Mas ele propôs um cronograma mais curto do que o Corallo.

"Talvez o tempo limite de um ano do BIP-9 seja muito longo, e uma expiração de seis meses seria preferível. Dessa forma, os usuários podem organizar um UASF se a ativação do BIP-9 falhar e eles acharem que é devido ao obstrucionismo do minerador", disse Russell.

Engenheiros estão revisando meticulosamente o código Taproot/Schnorr proposto para consertar quaisquer problemas persistentes. Então ainda há tempo para os desenvolvedores discutirem opções de ativação. Mas a comunidade precisará decidir sobre algo antes que a mudança possa ser adicionada ao Bitcoin, construindo mais Política de Privacidade na rede.