O Bitcoin falhou em ativar todos os soft forks propostos desde que o Taproot entrou em vigor em 2021, levando o criador do Drivechain, Paul Sztorc, a argumentar que a rede não pode aprovar nenhuma dessas atualizações no futuro previsível.
Resumo
- O BIP-110 atraiu 2,53% de apoio dos mineradores antes de seu ramo de execução estagnar após dois blocos.
- Paul Sztorc disse que todos os soft forks propostos desde o Taproot falharam em ativar.
- As Drivechains colocariam regras experimentais em cadeias separadas, mas exigiriam primeiro uma mudança no consenso do Bitcoin.
- Sztorc disse que a receita de taxas das sidechains influenciaria o incentivo dos mineradores para proteger os saques da Drivechain.
Paul Sztorc, CEO da LayerTwo Labs e criador da proposta Drivechain, disse ao crypto.news que a ativação fracassada do BIP-110 aponta para um problema que se estende muito além de uma única atualização disputada do Bitcoin.
“Todos os soft forks desde o Taproot falharam em ativar, e este não foi exceção”, disse Sztorc.
Sua avaliação seguiu-se ao colapso do BIP-110, um soft fork temporário proposto que buscava restringir algumas formas de dados não financeiros armazenados em transações Bitcoin. A proposta atraiu apenas 51 blocos de apoio durante um período de dificuldade de 2.016 blocos, deixando a sinalização dos mineradores em 2,53%.
Os nós de execução do BIP-110 posteriormente se separaram da rede Bitcoin dominante no bloco 961.632, em 8 de agosto. O novo ramo produziu apenas dois blocos antes de estagnar, enquanto a cadeia principal continuou processando blocos em seu ritmo habitual.
Falha do BIP-110 aponta para um processo de atualização do Bitcoin congelado
O resultado do BIP-110 mostrou como se tornou difícil para os desenvolvedores obter apoio para mudanças nas regras de consenso do Bitcoin, de acordo com Sztorc.
O processo de ativação voluntária da proposta exigia que 55% dos blocos sinalizassem apoio. Em 2 de agosto, a meta havia se tornado matematicamente inalcançável porque apenas 28 dos primeiros 1.108 blocos haviam sinalizado, de acordo com dados anteriores dos mineradores.
Seu software de execução ainda entrou em um período de sinalização obrigatória no bloco 961.632. Os nós executando o BIP-110 então rejeitaram blocos que não sinalizavam apoio, embora a maioria dos mineradores continuasse construindo na cadeia Bitcoin sem execução.
Em 9 de agosto, o ramo minoritário permanecia congelado no bloco 961.633 enquanto a cadeia principal avançava 111 blocos à frente. O endpoint BIP-110 da OCEAN mostrou cerca de 257 petahashes por segundo atribuídos ao ramo na época, enquanto o presidente executivo da Strategy, Michael Saylor, estimou que aproximadamente 99,85% do poder de hash do Bitcoin permaneceu com a cadeia dominante.
A estagnação da cadeia de dois blocos tornou-se mais severa porque o ramo herdou a dificuldade de mineração do Bitcoin de 127,48 trilhões. Sem poder computacional suficiente, seus mineradores não conseguiram produzir rapidamente os blocos restantes necessários para alcançar um ajuste de dificuldade.
O BIP-110, formalmente chamado de Reduced Data Temporary Softfork, propôs sete restrições de consenso com duração de 52.416 blocos, ou aproximadamente um ano na taxa normal de blocos do Bitcoin. As regras incluíam um limite de 83 bytes para saídas OP_RETURN, um limite de 256 bytes para certos envios de dados e restrições que afetavam algumas funções do Taproot.
Apoiadores, incluindo o mantenedor do Bitcoin Knots, Luke Dashjr, argumentaram que as restrições reduziriam o armazenamento arbitrário de dados ligado a inscrições e manteriam o Bitcoin focado em transações monetárias. Críticos como Saylor e o cofundador da Blockstream, Adam Back, disseram que a proposta poderia minar a neutralidade do Bitcoin ao rejeitar estruturas de transação que a rede atualmente aceita.
Até mesmo o OP_CAT enfrenta a mesma barreira de consenso do Bitcoin
Sztorc disse que o BIP-110 não foi uma falha isolada, apontando para a falta de ativação de outros soft forks propostos desde o Taproot.
O Taproot foi ativado no bloco 709.632 em 14 de novembro de 2021, depois que os mineradores usaram o processo Speedy Trial para sinalizar prontidão. A atualização introduziu assinaturas Schnorr e novas regras de gasto Taproot sem forçar nós não atualizados para uma blockchain separada.
Desde então, propostas que buscam adicionar recursos ou alterar as regras de script do Bitcoin permaneceram em discussão sem ativação. Sztorc citou o OP_CAT como exemplo, descrevendo-o como uma pequena mudança de código que apareceu no software original do Bitcoin e atraiu apoio de desenvolvedores.
“Nada pode — nem mesmo o OP_CAT, que é apenas 13 linhas de código e estava no software original e tinha muito apoio”, disse ele quando questionado sobre como o BIP 300 poderia superar a resistência a mudanças de consenso.
“O Bitcoin não pode ativar nenhum soft fork, no futuro previsível.”
O OP_CAT permitiria que scripts do Bitcoin unissem dois elementos de dados. Satoshi Nakamoto desativou a operação em 2010 por preocupações de segurança, mas uma proposta posterior buscou restaurá-la por meio de um soft fork compatível com versões anteriores.
Os apoiadores dizem que o opcode poderia ajudar desenvolvedores a criar covenants, vaults, bridges e outras condições de gasto programáveis. No entanto, a proposta do OP_CAT ainda depende de revisão técnica e de acordo suficiente entre desenvolvedores do Bitcoin, mineradores, operadores de nós e usuários.
Outras propostas enfrentam o mesmo problema de coordenação. O BIP-360, por exemplo, propõe um novo tipo de saída projetado para suportar assinaturas pós-quânticas por meio de um soft fork. Seus autores apresentam o design como um caminho possível para os usuários moverem fundos para endereços resistentes a quantum, embora a ativação exigisse o tipo de acordo de rede que Sztorc diz que o Bitcoin não consegue mais alcançar.
Drivechains moveriam a experimentação para longe da camada base do Bitcoin
Drivechains são projetadas para permitir que desenvolvedores testem regras e aplicações diferentes em sidechains opt-in, em vez de buscar mudanças repetidas na camada base do Bitcoin.
Sob o BIP 300, os usuários poderiam mover BTC entre o Bitcoin e sidechains separadas por meio de um peg bidirecional. Cada sidechain poderia aplicar suas próprias regras, permitindo que desenvolvedores testassem sistemas de privacidade, contratos inteligentes, transações mais rápidas ou outras funções sem exigir que todos os usuários do Bitcoin as adotassem.
As sidechains também manteriam marcas e softwares separados, o que Sztorc comparou com sistemas existentes como Liquid e Lightning. Os usuários poderiam escolher se moveriam fundos para uma cadeia específica, enquanto as regras base do Bitcoin permaneceriam inalteradas após a atualização inicial do Drivechain.
Questionado se múltiplas Drivechains poderiam fragmentar a liquidez e deixar os usuários inseguros sobre em quais implementações confiar, Sztorc comparou o modelo com desenvolvedores lançando altcoins separadas.
“Cada Drivechain terá sua própria marca, assim como Liquid, Lightning, etc.”, disse ele.
As Drivechains ainda enfrentariam o mesmo obstáculo imediato identificado na avaliação de Sztorc: o próprio BIP 300 precisa de uma mudança de consenso no Bitcoin. Sem ativação, os desenvolvedores não podem implantar seu sistema de saque proposto como parte das regras da rede.
“Não pode”, disse Sztorc quando questionado sobre como o BIP 300 poderia superar a resistência que impediu outras propostas.
O controle dos mineradores continua sendo a disputa central de segurança do Drivechain
O BIP 300 atribuiria aos mineradores do Bitcoin um papel importante na aprovação de saques das Drivechains, um arranjo que tem gerado preocupações sobre roubo, censura e conluio de mineradores.
Sob a proposta, as solicitações de saque permaneceriam pendentes enquanto os mineradores votassem nelas por meio de blocos do Bitcoin. Uma solicitação que recebesse apoio suficiente durante o período de votação exigido poderia liberar BTC do peg da sidechain.
Sztorc disse que o modelo de segurança depende em parte do valor econômico que uma sidechain popular cria para os mineradores.
“Se a cadeia for popular, ela estará gerando taxas para os mineradores. Se essa receita de taxas for grande, em relação ao número de moedas em circulação na L2, então será segura.”
Os usuários, portanto, precisariam avaliar a relação entre a receita de taxas da sidechain, os incentivos dos mineradores e o valor do BTC mantido dentro do peg. Críticos argumentam que os mineradores poderiam se coordenar para aprovar um saque inválido, enquanto apoiadores sustentam que atacar uma sidechain lucrativa poderia destruir a receita futura de taxas e prejudicar a confiança no sistema.
Para participantes dos EUA, o BIP-110 já demonstrou como operações de mineração americanas podem se envolver em disputas de governança do Bitcoin. A Foundry USA Pool pediu aos clientes de mineração que votassem na sinalização do BIP-110 antes do período obrigatório, enquanto a Strategy, uma empresa listada nos EUA e uma das maiores detentoras corporativas de Bitcoin, se opôs publicamente à proposta por meio de Saylor.
O fork fracassado também criou um risco prático para os detentores, porque o BIP-110 não incluía proteção automática contra replay. O desenvolvedor do Bitcoin Kevin Loaec alertou que uma transação enviada em um ramo poderia potencialmente ser copiada para o outro, colocando em risco as moedas pré-fork se os usuários tentassem mover ou vender ativos na cadeia minoritária sem primeiro separá-los.
Os apoiadores do BIP-110 também prepararam código para uma possível mudança de prova de trabalho, o que permitiria ao ramo estagnado abandonar o algoritmo de mineração existente do Bitcoin. O código incluía um tempo configurável de hard fork, embora o desenvolvedor Chris Guida o tenha descrito como um plano de contingência e não tivesse definido uma data de ativação.
