Um antigo debate está ressurgindo na comunidade de desenvolvedores de Bitcoin, ressaltando um dos desafios críticos que os sistemas descentralizados enfrentam: como atualizar o software quando ostensivamente ninguém está no comando.
O catalisador desta vez é chamado Taproot/Schnorr, uma atualização de escala e privacidade em anos recentes que registrou um progresso recentemente, especialmente agora que o código na forma de uma “solicitação pull” está sendo revisado e testado, trazendo uma mudança discutida pela primeira vez anos atrás, mais próxima da realidade.
A mudança de código em si não é controversa entre os desenvolvedores até agora. O que está em discussão é a melhor maneira de ativar a alteração, tornando finalmente possível enviar transações de BTC dessa nova maneira.
No centro de por que há uma dúvida sobre isso, é que o Bitcoin não tem líder e é distribuído em todo o mundo. Como toda a rede é atualizada sem problemas de uma forma compatível com versões anteriores, permitindo que aqueles com versões mais antigas do software continuem participando? Qual é a melhor maneira de o Bitcoin fazer esse tipo de alteração sem interrupção?
Para ficar claro: o código do Bitcoin é atualizado quase todos os dias por desenvolvedores do projeto de código aberto. Porém, as alterações no código de “consenso”, 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 fizeram bons progressos na implementação e adoção futura. No entanto, por várias razões, os métodos de ativação […] tiveram uma discussão limitada”, escreveu Matt Corallo, desenvolvedor do Bitcoin Core em um email para a lista de desenvolvedores de Bitcoin no mês passado que reabriu o debate.
Existem duas opções principais para decretar um soft fork. Uma opção, a Proposta de Melhoria do Bitcoin (BIP) 9, foi usada para alguns soft forks no passado.
Ele garante que os mineradores sejam preparados antes da atualização, para garantir que uma mudança se espalhe suavemente por toda a rede. Uma objeção comum a essa abordagem é que ela dá muito poder aos mineradores.
Como alternativa, existe o BIP 8, também conhecido como soft fork ativado por usuário (UASF), que é ativado independentemente de os mineradores sinalizarem que estão prontos ou não. Dependendo da execução, essa abordagem pode causar outros problemas, alertou Corallo.
Lição de história
A discussão começou em 2017, quando o BIP 9 foi usado para ativar a Segregated Witness, ou SegWit, uma mudança essencial ao grande debate de como escalar o Bitcoin.
Para proteger os mineradores da mineração de blocos inválidos e da perda de dinheiro, o SegWit não seria ativado até que 95% dos mineiros levantassem uma bandeira mostrando que estavam prontos.
A maioria das pools de mineração declarou que não apoiaria o SegWit – essencialmente vetando-o, a menos que estivesse associado a um aumento no parâmetro de tamanho do bloco.
O misterioso criador do Bitcoin havia estabelecido o limite de 1 megabyte, limitando o número de transações que poderiam ser empacotadas em blocos, que são transmitidos a cada 10 minutos.
A demanda de aumento de bloco era controversa pois muitos acreditavam que poderia levar à centralização da rede (e não poderia ser executada com sucesso, a menos que o Bitcoin fosse centralizado).
Para encurtar a história, o incidente mostrou que as pools de mineração poderiam usar o limite de 95% para negociar outras alterações em vez do objetivo pretendido: ajudá-los a facilitar a mudança para que não perdessem dinheiro.
Muitos bitcoiners não gostaram disso, vendo-os como mineradores tentando usar seu poder para realizar uma mudança que nem todos os usuários queriam.
À medida que esse debate prosseguia, o misterioso desenvolvedor Shaolinfry apontou que os bitcoiners ainda podiam fazer a atualização.
A raiz da ideia é que os usuários e as exchanges de Bitcoin devem decidir se uma mudança deve passar e os mineradores seguirão seus desejos – e não o contrário.
Este método foi usado para ativar outras atualizações do Bitcoin. Shaolinfy formalizou essa ideia no BIP 8, também conhecido como UASF.
Uma grande quantidade de usuários declarou em voz alta o suporte ao SegWit UASF nas mídias sociais e começou a executar o software. Isso parecia ter o efeito desejado. Antes do dia em que o UASF seria ativado, os mineradores começaram a sinalizar o suporte ao SegWit.
Notavelmente, havia alguns sabores de UASF circulando durante esse período tumultuado, um mais cauteloso e menos controverso que o outro.
Mas, sem entrar em detalhes, o principal argumento para alguns desenvolvedores de Bitcoin era que o UASF era a melhor maneira de promover mudanças.
Na época, Rusty Russell, um desenvolvedor da startup de Bitcoin Blockstream, chegou a pedir desculpas por ter desempenhado um papel na construção do BIP 9.
“Eu não esperava que esse ponto de verificação fosse usado como ponto de estrangulamento para sequestrar a rede.
Isso muda significativamente o modelo de risco; o BIP-8 agora é um método muito superior para atualizações de rede, onde os mineradores podem apenas acelerar o processo, não bloquear.”, ele escreveu em um post do Medium.
Antigas memórias
Lembrando de todo esse drama, alguns desenvolvedores têm receio de usar o BIP 9 novamente no Schnorr/Taproot ou em outras mudanças futuras.
“Acho que o BIP 9 é uma falha comprovada”, disse Luke Dashjr, desenvolvedor do Bitcoin Core, em resposta a Corallo, fornecendo razões técnicas para sua objeção.
Durante o debate sobre o SegWit, Dashjr foi um dos defensores mais vociferantes de um UASF para impulsionar o upgrade.
Alex Bosworth, desenvolvedor da Lightning Labs, expressou uma opinião semelhante, baseada em parte no recente drama 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 recentemente propôs que alguns BCH de cada novo bloco fossem para um fundo de desenvolvimento, que Bosworth vê como outro exemplo de pools de mineração flexionando seus músculos de uma maneira que é ruim para a descentralização de criptomoedas.
“Eu sei que o pensamento comum para a implantação de soft fork é tentar o método tradicional de mineração amigável. Mas [um terço] do nosso hashrate atual acaba de se organizar em um cartel com a finalidade de censura para roubar a recompensa de blocos”, tuitou Bosworth, que trabalha na LN.
É por isso que ele suporta um método UASF, embora com um horizonte de tempo mais longo.
“Um UASF de queima lenta parece mais apropriado para mim”, acrescentou.
Conclusão
Mas alguns, com cautela, temem que olhar para os UASFs como o único método de ativação possa abrir a possibilidade de realizar alterações que podem prejudicar o Bitcoin.
Por exemplo, um dos motivos pelo qual os desenvolvedores gostaram inicialmente do BIP 9 é que o limite de 95% poderia fornecer uma espécie de rede de segurança.
Se um problema surgisse enquanto as pools de mineração estavam trabalhando para atualizar seu software, eles poderiam interromper a mudança. É mais difícil interromper uma ativação do 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 o BIP 9, e então, se falhasse ao longo de um ano devido a “objeções irracionais”, os usuários poderiam debater e reagrupar por um período de seis meses.
Depois disso, se a mudança for definitivamente algo que a comunidade deseja, eles poderão experimentar o BIP 8 durante o período de outro ano.
Alguns desenvolvedores podem argumentar que esse período é 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, oferece uma boa oportunidade de aprendizado quanto ao nível de prontidão da comunidade e desejo de uma determinada mudança”, disse ele.
“Desenvolver Bitcoin não é uma corrida. Se precisarmos, esperar 42 meses pode garantir que não estamos estabelecendo um precedente negativo do qual vamos nos arrepender à medida que o Bitcoin continue a crescer”, disse ele.
Os leitores podem ler o raciocínio completo de Corallo, bem como muitas das respostas dos desenvolvedores aqui.
E enquanto Russell parecia 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 não funcionou e não sofremos muito com o atraso, não me importo com a ativação do BIP-9”, disse ele. Mas ele propôs um cronograma mais curto que Corallo.
“Talvez o tempo limite de um ano para o BIP-9 seja muito longo e uma expiração de seis meses seja preferível. Dessa forma, os usuários podem organizar um UASF se a ativação do BIP-9 falhar e acharem que é devido ao obstrucionismo do minerador”, disse Russell.
Os engenheiros estão revisando minuciosamente o código Taproot/Schnorr proposto para corrigir quaisquer problemas remanescentes.
Portanto, ainda há tempo para os desenvolvedores discutirem as opções de ativação. Mas a comunidade precisará decidir algo antes que a mudança possa ser adicionada ao Bitcoin, criando mais privacidade na rede.
E você, prefere atualizações em BIP 8 ou BIP 9? Sua opinião é valiosa para agregar ao debate, queremos ler na seção de comentários abaixo!