O Bitcoin é um sistema de pagamento distribuído. Por natureza, nenhuma pessoa ou entidade o administra. No entanto, seu protocolo às vezes é modificado para introduzir novas funcionalidades. Essas mudanças geralmente são feitas por meio de um mecanismo conhecido como “garfo macio”.
Para implementar esses soft forks de maneira ideal, mantendo a integridade do consenso atual, métodos de ativação específicos são usados. Esses mecanismos, embora às vezes desconhecidos, desempenham um papel crucial na compreensão da dinâmica associada às mudanças no protocolo Bitcoin. Neste artigo, exploramos os vários métodos de ativação de soft forks usados no Bitcoin.
Qual é a diferença entre um garfo macio e um garfo duro?
O protocolo Bitcoin é algo intangível por natureza. Ele simplesmente representa um grupo de regras não ditas, que permitem que diferentes nós se sincronizem e formem uma rede. Todos esses nós implementam as regras do protocolo por meio de software, sendo o mais usado o Bitcoin Core.
Quando ocorre uma alteração nessas regras de protocolo, esse evento é chamado de “bifurcação”. Cada nó fica então livre para escolher se deseja implementar essa bifurcação ou se a recusa. É assim que se busca o consenso para cada modificação do Bitcoin, sem a necessidade de recorrer a uma autoridade central.
Existem dois tipos principais de garfos: garfos duros e garfos macios. A diferença entre os dois é a compatibilidade com versões anteriores da atualização.
O hard fork altera o protocolo removendo regras ou tornando as existentes menos restritivas, tornando-o não compatível com versões anteriores dos nós mais antigos. Em seguida, faz com que o blockchain seja separado em duas cadeias distintas: aquela com os nós atualizados e aquela com os nós antigos.
O soft fork, por outro lado, altera o protocolo adicionando regras ou tornando as existentes mais restritivas. Dessa forma, o novo protocolo permanece compatível com o antigo e nenhuma separação em cadeia deve ocorrer. No Bitcoin, exceto em casos excepcionais, preferimos usar soft forks para modificar as regras do protocolo.
A dificuldade está no fato de que, mesmo com o uso de um soft fork, às vezes pode haver uma separação da blockchain em duas ramificações. Esse cenário ocorre quando menores que não atualizaram representam mais de 50% da capacidade de computação da rede. Nesse caso, a ramificação em duas cadeias distintas persiste enquanto a corrente que não integrou o garfo macio tiver mais trabalho acumulado do que a corrente que a adotou.
Para preservar a unidade do Bitcoin, queremos evitar essas ramificações a todo custo. Para fazer isso, os mineiros deverão decidir com antecedência sobre a aceitação de um garfo macio. Embora a grande maioria indique que concorda em apoiá-lo, os riscos de um garfo durante a ativação do garfo macio são consideravelmente reduzidos. Esse processo de consulta e consenso prévio é chamado de “método de ativação”.
Qual é a diferença entre um UASF e um MASF?
Em seguida, diferenciamos entre duas categorias de garfos macios. Quando sua implementação vem diretamente dos usuários, isso é chamado de “UASF” (Soft Fork ativado pelo usuário). Esse método ocorre quando os nós da rede optam por aplicar um soft fork modificando seu software, sem esperar pela aprovação dos mineradores. Geralmente usado em situações de emergência, especialmente quando a maioria dos menores se opõe à adoção de um soft fork, o UASF é, na realidade, um instrumento dissuasivo que permite aos usuários combater um potencial abuso de poder por menores. No entanto, o UASF não está isento de riscos: ele pode levar a uma ramificação do blockchain, colocando os usuários que o adotam em uma cadeia potencialmente sem valor econômico e menos segura.
Em um processo mais consensual, preferimos usar a ativação do soft fork por menores. Falamos então de um “MASF” (Garfo macio ativado por minerador). Nesse caso, menores podem aprovar a modificação do protocolo. Quando a grande maioria deles concorda com a implantação do soft fork, a atualização é validada e ativada um pouco mais tarde. Esse método permite evitar a ramificação do blockchain e manter a unidade da rede.
Como você pode ver, como não há um planejamento central sobre o Bitcoin, cada atualização pode rapidamente se tornar caótica. Assim, os desenvolvedores propuseram vários métodos de ativação para executar um soft fork e, ao mesmo tempo, reduzir o risco de quebrar o consenso do Bitcoin.
Métodos informais de ativação
Na época de Satoshi Nakamoto, não havia nenhum procedimento formal para ativar garfos macios. O próprio Satoshi fez as mudanças, que geralmente foram adotadas sem muita oposição por uma comunidade ainda pequena. Às vezes, nem mesmo os anunciava com antecedência, como quando impôs unilateralmente um limite de tamanho de bloco de 1 MB em 2010.
Entre os primeiros métodos usados, também encontramos o “Dia da Bandeira”. Consistia em definir e impor uma data específica para ativar o soft fork. Apesar de simples, esse método é muito rígido e não permite que possíveis divergências dentro da comunidade sejam consideradas.
Depois que Satoshi saiu no início de 2011, procedimentos de ativação mais formalizados começaram a surgir. A ativação do BIP16, que introduz o P2SH (Hash de pagamento por script), esteve no centro de um dos primeiros grandes debates dentro da comunidade. Foi durante esse período tenso que os primeiros métodos de ativação, levando em consideração a opinião de menores, foram usados.
Após esses debates sobre o P2SH, Gavin Andresen propôs o BIP34, que introduziu uma estrutura inicial para métodos de ativação. Essa abordagem possibilitou levar em consideração a opinião de menores e executar o soft fork quando um determinado limite de aprovação fosse atingido.
Posteriormente, outros soft forks usaram métodos semelhantes, com janelas de ativação se estendendo por várias semanas. No entanto, ainda não havia um método padronizado para ativar uma mudança de protocolo. As ativações foram realizadas mais ou menos de acordo com as recomendações do BIP34, mas este último não levou em consideração a sinalização de vários garfos macios simultaneamente.
Ative um garfo macio com o BIP9
O BIP9, projetado em 2015 por Pieter Wuille, Peter Todd, Peter Todd, Greg Maxwell e Rusty Russell, estabelece uma estrutura padrão para ativar garfos flexíveis, melhorando o conceito inicial do BIP34. Seu funcionamento é muito simples. Quando um soft fork é decidido, a comunidade o submete ao relatório de menores de idade. Para fazer isso, uma data de início e uma duração máxima para a sinalização são determinadas. Durante esse período, os mineradores podem usar um bit específico no campo de versão do bloco para indicar seu suporte ao soft fork.
Assim que 95% dos blocos relatam sua aprovação durante um período fixo de blocos de 2016, o soft fork é então bloqueado. Esse período coincide com cada ajuste na dificuldade de prova de trabalho. Após esse bloqueio, um curto período de tempo é concedido aos mineradores para se alinharem com a atualização, antes que o soft fork seja realmente executado. Se o limite de aprovação de 95% não for atingido dentro do tempo especificado, o soft fork será abandonado.
Em comparação com o BIP34, o BIP9 oferece a possibilidade de reportar vários soft forks simultaneamente. No entanto, ele também tem suas desvantagens, incluindo o fato de ser baseado inteiramente em um MASF, dando assim aos menores um poder considerável. De fato, se o limite de 95% de sinalização não for atingido durante a janela de votação, a mudança proposta é simplesmente abandonada.
Em particular, o BIP9 foi usado para ativar o SegWit em 2017. Como você provavelmente sabe, as coisas não correram conforme o planejado. Durante meses, a maioria dos menores se recusou a relatar seu acordo com o SegWit, apesar do consenso dos usuários.
Assim, o BIP9 introduz uma certa ambigüidade na governança do Bitcoin, levando os mineradores a pensar que controlam a ativação de soft forks. Na realidade, seu papel se limita a sinalizar sua prontidão para adotar o novo código, a fim de evitar uma ramificação do blockchain. Apesar da complexidade do assunto, são os usuários que exercem controle definitivo sobre o protocolo, por meio de seus nós completos.
Por esse motivo, o desenvolvedor Shaolin Fry propôs o BIP148 em março de 2017, que permitia aos usuários fazer um UASF. O objetivo era impor o SegWit a menores, sem o consentimento deles. Essa iniciativa, amplamente apoiada pela comunidade, exerceu pressão suficiente sobre os mineradores, que, por medo de perder sua renda, finalmente aprovaram o SegWit por meio de um processo de sinalização mais tradicional.
O processo de ativação do SegWit, portanto, se transformou em um fiasco e poderia ter sido um desastre para o Bitcoin. Por esse motivo, em 2017, Shaolin Fry e Luck Dashjr propuseram o BIP8, um novo método de ativação que retoma a ideia do BIP9 enquanto adiciona um mecanismo automático de UASF no final do período de votação.
Ele especifica um novo parâmetro chamado “LOT” (Bloqueie o tempo limite), que pode assumir o valor de “verdadeiro” ou “falso”. Se essa variável for definida como “false”, o BIP8 funcionará de maneira semelhante ao BIP9. Uma janela de aprovação para menores é especificada e, quando o limite é atingido, o soft fork é bloqueado. Por outro lado, se o parâmetro LOT for definido como “verdadeiro”, o BIP8 prevê que, se o limite exigido não for atingido no final do período de votação, um UASF será acionado automaticamente pelos usuários. Esse mecanismo visa pressionar os mineradores a forçarem a ativação do garfo flexível no caso de um bloqueio no processo de aprovação.
O BIP8 com LOT ativado é, portanto, um método muito mais agressivo contra menores. Isso os deixa com apenas duas opções:
Seja cooperativo e, assim, facilite o processo de ativação;
Não coopere; nesse caso, os usuários fazem um UASF para aplicar o soft fork.
O BIP8 também corrigiu algumas falhas no BIP9. Em vez de usar carimbos de data e hora para especificar o período de votação, ele o configura para bloquear alturas. Dessa forma, o BIP8 elimina a possibilidade de os mineradores fazerem com que a taxa de hash na rede caia drasticamente para distorcer o processo. Além disso, ele adiciona a capacidade de determinar livremente o limite mínimo de votação e introduz um parâmetro especificando a altura mínima do bloco, abaixo da qual o soft fork não pode ser ativado. Essa configuração dá aos menores tempo para se prepararem para a alteração do código, ao mesmo tempo em que permite que eles sinalizem sua concordância com antecedência.
Ative um soft fork no Speedy Trial
O processo “Speedy Trial”, proposto por David A. Harding no início de 2021 com base em uma ideia de Russell O'Connor, é um novo método de ativação projetado inicialmente para o soft fork Taproot. É baseado no uso do BIP8 com o parâmetro LOT definido como “falso”, mas com uma redução significativa na janela de ativação para apenas três meses. Dessa forma, a aprovação de menores pode ser verificada muito rapidamente. Se o limite exigido for atingido durante um dos períodos, o soft fork é ativado vários meses depois, deixando tempo suficiente para os mineradores atualizarem seu software. Embora esse método ainda não tenha sido formalizado em um BIP específico, ele já foi usado para ativar o Taproot em novembro de 2021.
Apesar de sua eficácia para o Taproot, que teve um grande consenso na comunidade, o método Speedy Trial não é necessariamente o mais adequado para todas as atualizações do Bitcoin. Alguns desenvolvedores expressam reservas sobre seu uso futuro, temendo que isso incentive uma sucessão de soft forks muito rapidamente e, portanto, possa comprometer a estabilidade do protocolo Bitcoin.
Os métodos para ativar soft forks no Bitcoin estão evoluindo com novas atualizações. É um padrão de tentativa e erro que é sempre muito semelhante: definimos um método de ativação padrão; o usamos para o próximo grande soft fork; ele não acontece conforme o esperado; então definimos outro padrão considerando nossos erros do passado.
Até o momento, existem basicamente três métodos de ativação:
BIP9, que permite solicitar a aprovação de menores antes de ativar um garfo macio;
BIP8, que é essencialmente como o BIP9, mas adiciona a possibilidade de UASF automático se os menores não cooperarem;
E o Speedy Trial, que é como o BIP8, mas com um período de votação muito curto.
%201.png)
