Desenvolvedores de Bitcoin ainda estão divididos sobre os detalhes da ativação do Taproot

O código para Taproot, a maior atualização do Bitcoin em anos, está finalizado efoi empacotado em uma atualização futura. Só que ele ainda não está pronto para ser implantado porque os desenvolvedores do Bitcoin têm opiniões diferentes sobre o melhor caminho para ativação.

O Taproot aprimorará as capacidades de contrato inteligente do Bitcoin implementando um novo esquema de assinatura digital, Schnorr. Implementar a atualização requer um “soft fork” do código do Bitcoin, e há algumas propostas concorrentes sobre como ativá-lo.

Em uma tentativa de agilizar as discussões sobre a implementação, o colaborador do Bitcoin CORE, AJ Towns, entrevistou recentemente 12 outros desenvolvedores que estiveram ativos no processo de implementação para obter suas opiniões sobre como a ativação deveria ser.

Leia Mais: O futuro do Bitcoin: exatamente como uma atualização futura pode melhorar a Política de Privacidade e a escalabilidade

O resultados da pesquisamostram que, embora os desenvolvedores geralmente estejam alinhados quando se trata do panorama geral da ativação do Taproot, eles discordam nos detalhes. Enquanto debatem os pontos mais sutis, a deliberação conservadora e cuidadosa do desenvolvedor pode parecer uma crítica mesquinha para pessoas de fora.

Mas mostra que as chamadas atualizações de “soft-fork” como o Taproot não são Eventos totalmente isentos de risco – e que o espectro de o controverso soft fork Segwittem assombrado discussões.

Propostas de ativação da Taproot, explicadas

O aumento da carga de transações do Segwit foi o último soft fork do Bitcoin, ou uma atualização que é “compatível com versões anteriores”, o que significa que o software que executa a versão antiga do código ainda pode interagir com a versão atualizada.

A ativação do Segwit foi tudo menos suave e contou com ajustes ao longo do caminho depois que os mineradores falharam em adotar a atualização em seu primeiro ano. Para KEEP que a atualização falhasse, uma nova proposta de implementação foi adotada no meio do processo de ativação. Em um esforço para pressionar os mineradores a atualizar, uma proposta até sugeriu que os operadores de nó – aqueles usuários do Bitcoin que executam o software do Bitcoin e KEEP uma cópia de seu livro-razão – rejeitassem transações dos mineradores que T tinham atualizado para o SegWit para agilizar sua adoção.

Leia Mais: Taproot foi fundido ao Bitcoin CORE: aqui está o que isso significa

Em um mundo perfeito, tanto os usuários de nós quanto os mineradores fariam upgrade simultaneamente para garantir que nenhum conflito “dividisse” a cadeia – ou resultasse em duas facções rivais apoiando duas versões diferentes do código do Bitcoin.

Embora o Taproot seja uma atualização não controversa, a memória do Segwit está deixando os desenvolvedores cautelosos ao avaliar esta atualização mais recente.

Duas propostas

Duas das principais propostas de implementação para o Taproot dependem de uma mistura de sinalização de mineradores e ativação de usuários. O BIP 8, introduzido em 2017 pelos desenvolvedores do Bitcoin Luke Dashjr e Shoalinfry, incluiria um período de sinalização para mineradores; se mineradores suficientes T ativarem para chegar a um consenso sobre a atualização, então um “dia de sinalização” para ativação atualizaria automaticamente os nós do Bitcoin que baixaram a v0.21 do Bitcoin CORE.

Esses nós rejeitariam blocos e transações de mineradores que não suportassem Taproot, então, em teoria, esse método incentivaria os mineradores a adotar o novo conjunto de regras para que não perdessem lucros.

Em uma segunda proposta de implementação do Taproot, o Modern Softfork Activation do desenvolvedor CORE Matt Corallo funde o BIP 8 com o BIP 9 (sendo este último a proposta originalmente adotada para ativar o Segwit, mas que se mostrou inadequada).

O modelo híbrido da Corallo inclui primeiro um período de sinalização de um ano para mineradores. Segundo, se uma supermaioria de mineradores não atualizar durante esse período, então a atualização estaria sujeita a uma revisão de seis meses para fazer alterações (se houver) na proposta.

A terceira e última etapa é um período de ativação de dois anos no estilo BIP 8, com um dia de sinalização não obrigatório para os usuários do nó ativarem a atualização.

O que os desenvolvedores do Bitcoin pensam

Para a primeira pergunta em sua pesquisa, AJ Towns pergunta aos desenvolvedores qual porcentagem de mineradores precisa sinalizar uma atualização para que seja considerada uma maioria segura. Oito acreditam que nada menos que 85%-95% seria suficiente. O pensamento é que qualquer coisa menos que isso ameaça uma "divisão" de rede onde alguns mineradores executam o código mais antigo e alguns o código mais novo, o que criaria dois históricos de transações conflitantes.

Na falta de uma ativação sinalizada por minerador, sete entrevistados acham que um dia de bandeira para ativação imposta por nó pode vir em 12-18 meses após o início da ativação. Se muito poucos mineradores adotarem a atualização, isso significaria que os nós poderiam impor o conjunto de regras Taproot e aceitar apenas blocos de mineradores que também sinalizaram para a atualização.

Em um mundo perfeito, tanto os usuários de nós quanto os mineradores fariam upgrade simultaneamente para garantir que nenhum conflito “dividisse” a cadeia – ou resultasse em duas facções rivais apoiando duas versões diferentes do código do Bitcoin.

Quase todos os desenvolvedores pesquisados querem esperar para ver se os mineradores e usuários adotam a atualização por conta própria antes de decidir uma data fixa para o dia da bandeira (se houver suporte inicial suficiente, um dia da bandeira pode não ser necessário).

Se a ativação T ocorrer por meio de ativação voluntária, então uma ativação de dia de bandeira é a última opção na mesa. A maioria dos entrevistados foi a favor de um dia de bandeira obrigatório para sinalizar automaticamente a atualização. Isso significaria que os nós atualizados rejeitariam blocos de mineradores que T sinalizaram para a atualização.

Desentendimentos sobre os detalhes mais sutis

A chamada sinalização forçada por meio do dia da bandeira teria o benefício de tornar o Taproot padrão em qualquer nó do Bitcoin CORE executando a versão 21; por sua vez, esses nós aceitariam apenas dados de bloco de mineradores que também sinalizaram a atualização, então, em teoria, isso encorajaria os mineradores a atualizar para não perderem seus negócios.

Mas e se os mineradores tiverem usuários de nós que aceitem seus blocos?

Esta é uma ressalva à sinalização forçada: se muitos mineradores e usuários de nós T aceitarem o Taproot e se recusarem a atualizar seus softwares, a rede pode se dividir em duas cadeias concorrentes. Se interesse econômico suficiente apoiar a versão “antiga” do Bitcoin, o resultado pode ser dois ativos concorrentes.

Esse resultado é, em parte, o motivo pelo qual alguns desenvolvedores, como Matt Corallo, acham que a sinalização forçada é desnecessária.

Como o Taproot tem sido amplamente incontroverso, seria um risco político forçar o sinal da atualização, ele argumenta. Ele considera o método de ativação uma relíquia do “soft fork ativado pelo usuário” do Segwit, uma proposta para ativar o Segwit por meios semelhantes depois que os mineradores falharam em adotar a atualização. O Segwit foi muito controverso e político. O Taproot não é, mas Corallo acredita que a sinalização forçada ameaça fazê-lo dessa forma.

Em sua postagem, Towns escreve que a sinalização obrigatória seria uma forma de impor definitivamente a ativação da Taproot em toda a rede após consenso suficiente ter sido estabelecido por meio de discussão e suporte do minerador.

“Se você quiser maximizar o número de nós que aplicarão as regras caso ocorra um dia de sinalização, mas também escolher apenas o dia de sinalização após uma tentativa de ativação inicial já ter sido amplamente implementada, então você não tem escolha a não ser tornar a sinalização obrigatória quando o dia de sinalização ocorrer”, escreve Towns.

Qual é o problema?

Towns apresenta uma proposta de ativação alternativa na pesquisa que apresenta um prazo de ativação de quatro anos. Como sempre na discussão sobre o desenvolvimento do Bitcoin , isso também recebeu alguma resistência.

“Uma vez que a decisão de ativar tenha apoio esmagador de desenvolvedores e usuários, quanto maior o prazo para ativação (além do que é praticamente necessário para que os mineradores atualizem com segurança), mais coisas podem dar errado”, disse o ex-desenvolvedor do Bitcoin CORE, Eric Lombrozo. disse a Towns no Twitter.

Riscos à parte, se a maioria dos desenvolvedores e Bitcoiners acham que o Taproot é uma opção certa para uma atualização, ele T deve levar quatro anos para ser ativado, principalmente porque já demorou tanto tempo para ser criado.

Afinal, se o Taproot está em desenvolvimento desde 2018, os mineradores e operadores de nós T deveriam saber o que esperar?

Como CEO da Blockstream, Adam Backcoloque no Twitter“A raiz principal T pode ser uma surpresa depois de vários anos.”