De BIP a Votação de Mineradores: O Mecanismo de Atualização do Protocolo Bitcoin

Resumo

O desenvolvimento do Bitcoin é impulsionado por uma comunidade global de código aberto, e as mudanças no protocolo são normalizadas através das Propostas de Melhoria do Bitcoin (BIPs). Essas propostas estão sujeitas a rigorosas revisões da comunidade e mecanismos de consenso, incluindo votos de sinalização dos mineradores. Este modelo de código aberto, embora promova transparência e ampla participação, também apresenta o desafio de alcançar consenso rapidamente e coordenar o desenvolvimento. Em um sistema sem autoridade centralizada, o processo de tomada de decisão pode se tornar longo e contencioso.

A ViaBTC Capital analisará a estrutura única do desenvolvimento descentralizado do Bitcoin, revisará o papel central e as controvérsias do Bitcoin Core na manutenção do protocolo, revisitará os caminhos de ativação de atualizações importantes como SegWit e Taproot, e aprofundará no debate sobre 'programabilidade' desencadeado por novos BIPs como OP_CAT. Isso leva a uma questão profunda: O princípio do Bitcoin de 'imutabilidade igual a segurança' está se tornando o grilhão definitivo para sua inovação ecológica?

1. Visão Geral do Modelo de Desenvolvimento Descentralizado do Bitcoin

1.1 O Papel Central do Bitcoin Core na Manutenção do Protocolo

O Bitcoin Core é a principal implementação de software do protocolo Bitcoin e é considerado seu cliente de referência. Ele contém software de nó completo para verificação completa da blockchain, bem como uma carteira bitcoin. A maioria dos usuários e mineradores de Bitcoin opta por usar o Bitcoin Core como seu nó completo, o que é essencial para manter a descentralização da rede e repelir possíveis ataques. Além disso, o projeto mantém softwares relacionados, como a biblioteca de criptografia libsecp256k1 .

Embora o desenvolvimento do Bitcoin seja descentralizado, até junho de 2025, cerca de 90% de todos os nós completos na rede usam o Bitcoin Core. Portanto, o Bitcoin Core ocupa uma posição única e de fato influente como a "implementação de referência". Esta autoridade de fato significa que, uma vez que as mudanças são incorporadas ao código-base do Bitcoin Core, elas frequentemente se tornam o padrão de fato, mesmo sem imposição explícita de uma autoridade central. Esta adoção generalizada e voluntária define efetivamente as regras operacionais e o estado atual do protocolo. Consequentemente, os desenvolvedores que contribuem para o projeto Bitcoin Core, especialmente seus mantenedores, exercem influência significativa. Seu trabalho, após passar por uma revisão rigorosa e ser incorporado, impacta diretamente a funcionalidade geral e a segurança da rede. Isso cria uma forma única de "centralização suave" em torno do projeto Bitcoin Core, que é continuamente equilibrada por sua natureza transparente de código aberto e processo de revisão por pares distribuído.

1.2 O Papel Evolutivo do Mantenedor: De Satoshi Nakamoto à Gestão Coletiva

O papel dos mantenedores do Bitcoin Core evoluiu significativamente, da liderança pessoal de Satoshi Nakamoto para um modelo de gestão coletiva compartilhado por múltiplos mantenedores.

• Os Primórdios e Saída de Satoshi Nakamoto: O misterioso criador do Bitcoin, Satoshi Nakamoto, inicialmente desenvolveu e esteve ativo no projeto Bitcoin Core até o final de 2010, quando anunciou em abril de 2011 que havia "passado para outros projetos" e entregou a responsabilidade pelo Bitcoin Core a Gavin Andresen. Este momento marcou a primeira vez que a liderança do Bitcoin passou de Satoshi Nakamoto para a comunidade, e foi um marco importante na descentralização do projeto.
• A Sucessão e Controvérsia de Gavin Andresen: Considerado o "herdeiro aparente" de Satoshi Nakamoto, Gavin Andresen assumiu como o principal mantenedor do Bitcoin Core e liderou o desenvolvimento do Bitcoin nos anos seguintes, resultando em maior estabilidade e aceitação. No entanto, em 2016, Gavin Andreessen esteve envolvido em uma grande controvérsia quando afirmou publicamente que o australiano Craig Wright era Satoshi Nakamoto. Esta afirmação foi posteriormente amplamente contestada pela comunidade, levando à revogação temporária do acesso de Gavin Andreessen ao código-base principal do Bitcoin no GitHub por outros mantenedores.
• Wladimir J. van der Laan e Subsequente Manutenção Coletiva: Em 8 de abril de 2014, Wladimir J. van der Laan sucedeu Gavin Andreessen como mantenedor principal. Desde então, o papel de mantenedor principal evoluiu para ser compartilhado por múltiplos mantenedores, descentralizando ainda mais o processo de lançamento. Atualmente, apenas alguns desenvolvedores têm acesso ao código do Bitcoin Core, e suas responsabilidades incluem mesclar patches de contribuidores e realizar verificações finais para garantir que os patches sejam seguros e atendam aos objetivos do projeto.

A evolução do papel de mantenedor do Bitcoin Core, de um único líder para múltiplos mantenedores compartilhando o papel, reflete os esforços contínuos do projeto para encontrar um equilíbrio entre descentralização e eficiência. Inicialmente, Satoshi Nakamoto conseguia fazer o projeto avançar rapidamente como o único tomador de decisões. No entanto, à medida que o projeto amadureceu e a comunidade cresceu, especialmente após a saída de Satoshi Nakamoto, os riscos deste modelo tornaram-se cada vez mais aparentes. Descentralizar a autoridade para múltiplos mantenedores, por outro lado, reduz o risco de um único ponto de falha e garante um processo de tomada de decisão mais robusto e resistente à censura. No entanto, isso também significa que a velocidade com que os projetos podem alcançar consenso e implementar grandes mudanças pode ser reduzida. Este trade-off inerente revela a complexidade de governança dos sistemas descentralizados: como manter um senso suficiente de eficiência e direção sem sacrificar os princípios fundamentais de descentralização.

Ao mesmo tempo, a composição da equipe de mantenedores e a dinâmica de poder dentro dela têm um impacto profundo na direção e estabilidade de todo o ecossistema Bitcoin. A Blockstream é uma empresa especializada em infraestrutura Bitcoin e blockchain, e vários dos desenvolvedores envolvidos na manutenção do Bitcoin Core costumavam trabalhar para esta empresa. Ao apoiar esses desenvolvedores, a Blockstream tornou-se um importante contribuidor para o código do Bitcoin Core, levantando questões na comunidade sobre sua independência de desenvolvimento e corporativização. Por exemplo, a insistência da Blockstream em resolver o problema de escalabilidade do Bitcoin através de solução de camada 2 e sua oposição ao escalonamento direto da cadeia principal levaram a divisões na comunidade e forks do Bitcoin; além disso, a crise de confiança entre desenvolvedores e mineradores e a feroz competição com a comunidade ethereum tornaram a Blockstream um centro de controvérsia nos círculos cripto.

1.3 Contribuições e Controvérsias da Comunidade de Desenvolvedores

O desenvolvimento do Bitcoin é um processo aberto e colaborativo, e qualquer pessoa pode fazer Pull Requests para mudanças de código, revisões ou testes abertos. Desde o início do programa, mais de mil desenvolvedores contribuíram para ele, melhorando a funcionalidade do software, corrigindo bugs e adicionando novos recursos, e interagindo com a comunidade para obter feedback e resolver problemas. O processo de tomada de decisão é colaborativo e frequentemente depende do consenso entre desenvolvedores e a comunidade mais ampla.

No entanto, essa abertura também levou a controvérsias dentro da comunidade, especialmente com o surgimento de novos casos de uso como as Inscrições.

Luke Dashjr e a Controvérsia das Inscrições: O desenvolvedor do Bitcoin e co-fundador da Ocean Mining Pool, Luke Dashjr, criticou fortemente inscrições como Ordinals e tokens BRC-20, chamando-os de "spam" no Bitcoin. Ele argumenta que as inscrições exploram uma vulnerabilidade no Bitcoin Core que permite que elas contornem o limite de tamanho de dados extras nas transações, disfarçando os dados como código de programa. Dashjr argumenta que essa "vulnerabilidade" foi corrigida no Bitcoin Knots v25.1 e espera que o Bitcoin Core também a corrija antes do lançamento da v27. Ele até argumenta que, uma vez que a vulnerabilidade seja corrigida, os Ordinals e tokens BRC-20 deixarão de existir, pois "nunca realmente existiram e são fraudulentos".

Poder de Mercado dos Ordinals e Tokens BRC-20: Ordinals e tokens BRC-20, embora considerados "spam" pelos conservadores, mostraram grande vitalidade no mercado. De acordo com a Dune Analytics, até dezembro de 2023, transações relacionadas a inscrições geraram uma receita adicional de 172 milhões de dólares para os mineradores, um incentivo financeiro real que está remodelando o ecossistema bitcoin, e inovações como Taproot Wizards continuam a explorar os limites da programabilidade do bitcoin, sugerindo que as forças do mercado podem ser capazes de contornar as restrições tecnológicas dos desenvolvedores. Em sistemas descentralizados, os incentivos econômicos estão se tornando a arma mais poderosa para quebrar os grilhões da ideologia.

Implicações Mais Profundas da Controvérsia: Alguns desenvolvedores insistiram que o Bitcoin deveria permanecer funcionalmente puro, e que quaisquer funções financeiras não essenciais poderiam ameaçar a cibersegurança. Esta filosofia de "imutabilidade" evitou a fragmentação ecológica que vem com frequentes hard forks, mas também está enfrentando sérios desafios. Quando os desenvolvedores tentam remover aplicações inovadoras como inscrições corrigindo "bugs", eles efetivamente recebem "direitos de veto funcional" de facto, uma tendência centralizada que vai contra o espírito descentralizado do Bitcoin. Se os desenvolvedores conseguirem bloquear aplicativos inovadores, ficará claro que a "imutabilidade" se tornou um grilhão para a inovação. O resultado deste jogo determinará se o Bitcoin pode manter sua vantagem de segurança enquanto evita cair vítima do conservadorismo tecnológico. No contexto de rápida inovação em blockchains públicas concorrentes como o Ethereum, a comunidade Bitcoin precisa encontrar um equilíbrio entre preservar o valor central da segurança e estabilidade da rede, enquanto deixa espaço para inovação sensata. Afinal, em um mundo regido por código e aritmética, o mercado acabará por dar o veredicto mais justo.

2.Propostas de Melhoria do Bitcoin (BIPs): Um Mecanismo Formal de Atualização

2.1 Definição, Propósito e Importância das BIPs

As Propostas de Melhoria do Bitcoin (BIPs) são documentos padronizados que descrevem possíveis mudanças, melhorias ou adições ao protocolo Bitcoin. Elas fornecem uma plataforma colaborativa para desenvolvedores, pesquisadores e membros da comunidade proporem, discutirem e implementarem mudanças, garantindo transparência e amplo consenso da comunidade. As BIPs permitem que a comunidade Bitcoin enfrente desafios emergentes e se adapte às necessidades em constante mudança da comunidade, permitindo que qualquer pessoa contribua para seu desenvolvimento, garantindo que as mudanças sejam feitas de maneira transparente com amplo consenso da comunidade.

2.2 Tipos de BIPs

Existem três tipos principais de BIPs do Bitcoin, cada um com um propósito único:

• BIPs de Padrão: Estas BIPs descrevem mudanças que afetam as regras de consenso do protocolo Bitcoin. Elas propõem alterações em aspectos fundamentais de como o Bitcoin funciona que requerem amplo consenso da comunidade para implementar. Por exemplo, as atualizações Segregated Witness (SegWit) e Taproot se enquadram nesta categoria.
• BIPs Informativas: BIPs informativas fornecem materiais educacionais, guias gerais ou descobertas de pesquisa relacionadas ao Bitcoin. Elas oferecem aos desenvolvedores e entusiastas insights valiosos sobre vários aspectos do ecossistema Bitcoin e os ajudam a aprofundar sua compreensão da rede. Estas BIPs não alteram o código ou as regras do Bitcoin, mas são mais como sugestões ou recomendações projetadas para educar a comunidade.
• BIPs de Processo: BIPs de processo propõem mudanças no próprio processo de desenvolvimento do Bitcoin. Elas visam melhorar a eficiência, governança ou mecanismos de tomada de decisão dentro da comunidade Bitcoin. BIPs de processo podem abordar tópicos como processos de revisão de código, metodologias de gerenciamento de projetos ou iniciativas de coordenação da comunidade. Elas são semelhantes às BIPs de rastreamento padronizadas, pois requerem consenso da comunidade, mas diferem no sentido de que se aplicam a processos fora do protocolo Bitcoin.

O processo de categorização e padronização das BIPs reflete a estratégia da comunidade Bitcoin para gerenciar a evolução de tecnologias complexas em um ambiente descentralizado. Ao categorizar propostas em diferentes tipos, a comunidade consegue aplicar diferentes níveis de revisão e intensidade de consenso para mudanças de naturezas diferentes. Por exemplo, BIPs de rastreamento de padrões que afetam as regras de consenso requerem o maior limiar de consenso porque podem levar à fragmentação da rede, enquanto BIPs informativas são mais lenientes. Esta abordagem estruturada, embora possa parecer complicada, minimiza o risco de mudanças maliciosas ou insuficientemente consideradas na estabilidade central da rede.

3.3 Ciclo de Vida e Processo de Ativação das BIPs

Uma BIP do Bitcoin passa por várias fases diferentes antes de se tornar parte do protocolo Bitcoin:

1. Fase de Rascunho: Nesta fase, as propostas são criadas e refinadas por seus autores, e a BIP passa por revisão inicial e feedback da comunidade.
2. Fase de Proposta: Durante esta fase, a BIP recebe mais atenção da comunidade. Ela é apresentada aos desenvolvedores, pesquisadores e entusiastas do Bitcoin para revisão e feedback adicionais. Esta fase permite o brainstorming coletivo e o refinamento da proposta para garantir sua robustez.
3. Fase Final: Uma vez que a BIP tenha ganhado amplo apoio na comunidade e tenha sido minuciosamente examinada, ela entra na fase final. Durante esta fase, a proposta é incluída no repositório de Propostas de Melhoria do Bitcoin (BIP), indicando que está pronta para implementação.
4. Implementação e Ativação: Os desenvolvedores do Bitcoin então integram as mudanças no protocolo Bitcoin por consenso. Para grandes mudanças no nível do protocolo, geralmente há um limite de ativação, e as melhorias só entram em vigor quando participantes suficientes da rede atualizaram para a nova versão. As atualizações podem ser soft forks (compatíveis com versões anteriores), como o SegWit, que permitem que nós mais antigos continuem a operar, ou hard forks (incompatíveis), que podem levar à divisão da rede e à criação de novas criptomoedas, como o hard fork do Bitcoin Cash (BCH) em 2017.

Este ciclo de vida de múltiplos estágios das BIPs e o rigoroso processo de ativação são uma manifestação central do modelo de governança descentralizada do Bitcoin. Isso garante que quaisquer modificações no protocolo não sejam impostas por alguns poucos, mas sim através de extensa discussão e adoção voluntária por múltiplos stakeholders. Este mecanismo combina efetivamente a tomada de decisão técnica com o consenso social, tornando a evolução dos protocolos um processo orgânico e altamente resistente à censura. Por outro lado, no entanto, este modelo baseado em consenso pode resultar em atualizações lentas, mas aumenta muito a resiliência e a confiabilidade da rede Bitcoin porque evita o risco de fragmentação da rede ou centralização que poderia resultar de mudanças obrigatórias. Cada ativação bem-sucedida de BIP prova que a comunidade, através de colaboração e compromisso, é capaz de trabalhar em conjunto para manter e fazer crescer este sistema monetário global e sem confiança.

3.Principais BIPs e Seu Impacto

A evolução do protocolo Bitcoin foi possível através de uma série de BIPs-chave, propostas que melhoraram significativamente a eficiência, privacidade e escalabilidade da rede.

3.1 BIPs-Chave Ativadas

• BIP 16 (P2SH): Introduziu o recurso Pay-to-Script-Hash (P2SH), que foi ativado em 2012. O P2SH simplifica operações complexas de script e melhora a eficiência e privacidade das transações, permitindo que os remetentes enviem fundos para um hash de script em vez de um endereço de chave pública direta. Ele melhora a eficiência e privacidade das transações ao permitir que os remetentes enviem fundos para um hash de script em vez de um endereço de chave pública direta. Economiza espaço na blockchain e aumenta a privacidade ao ocultar a condição de gasto até que os fundos sejam gastos. Os endereços P2SH geralmente começam com um "3" para distingui-los dos endereços Bitcoin tradicionais (que começam com um "1"). O caso de uso mais comum para P2SH são transações multi-assinatura, onde múltiplas assinaturas são necessárias para executar uma transação, fornecendo uma camada adicional de segurança para empresas e organizações. Também é fundamental para o desenvolvimento de soluções de Camada 2, como a Lightning Network, que aumenta significativamente a capacidade de transação do Bitcoin ao bloquear condicionalmente fundos para suportar transações fora da cadeia. O BIP 16 foi implementado como um soft fork, o que significa que os nós mais antigos ainda podem validar e processar transações que seguem as regras atualizadas, mantendo a compatibilidade retroativa.
• BIP 141 (SegWit): Aborda a maleabilidade de transações e escalabilidade através do Segregated Witness (SegWit), ativado em 2017. A maleabilidade de transação é o risco de que o ID da transação (TXID) possa mudar quando a assinatura é modificada, mesmo que o efeito da transação permaneça o mesmo, o que representa um risco para o protocolo fora da cadeia. O SegWit resolve esse problema movendo o código de desbloqueio (a assinatura) para um novo campo "testemunha" nos dados da transação e excluindo-o do cálculo do TXID. Isso torna o TXID confiável. Além disso, o SegWit realmente aumenta o tamanho do bloco introduzindo "unidades de peso" em vez de bytes simples para calcular o tamanho do bloco. Bytes normais são contados como 4 unidades de peso, enquanto bytes testemunha são contados como 1 unidade de peso, o que se traduz em um desconto de 75% nos dados desbloqueados, criando assim mais espaço no bloco para dados transacionais. O SegWit também está sendo implementado como um soft fork, o que significa que os nós legados que não foram atualizados ainda tratarão os blocos SegWit como válidos, garantindo a compatibilidade da rede. Ele estabelece as bases para protocolos de Camada 2, como a Lightning Network, permitindo que seja construída com segurança sobre o Bitcoin.
• BIP 340, 341, 342 (Taproot): Juntos, esses BIPs compõem a atualização Taproot, que será ativada em novembro de 2021. O Taproot é a atualização mais significativa desde o SegWit, e foi projetado para melhorar a privacidade, eficiência e escalabilidade do Bitcoin, bem como para aumentar a flexibilidade dos contratos inteligentes.
• BIP 340 (Assinaturas Schnorr): Introduziu as assinaturas Schnorr, um esquema de assinatura mais seguro e eficiente do que as assinaturas ECDSA tradicionais. A principal vantagem das assinaturas Schnorr é sua capacidade de agregação de chaves, que permite que múltiplas chaves públicas e assinaturas sejam combinadas em uma só, fazendo com que transações multi-assinatura pareçam iguais a uma transação normal de assinatura única na cadeia. A principal vantagem das assinaturas Schnorr é sua capacidade de combinar múltiplas chaves públicas e assinaturas em uma única, fazendo com que transações multi-assinatura pareçam transações de assinatura única normais na cadeia, melhorando a privacidade e reduzindo o volume de dados.
• BIP 341 (Taproot): introduz uma estrutura genérica que integra os mecanismos de assinaturas Schnorr, Árvores de Sintaxe Abstrata Merkleizadas (MAST) e Pay-to-Taproot (P2TR). O MAST permite a ocultação de complexidade não utilizada em uma transação, revelando apenas a parte relevante da transação no momento em que é realmente gasta, melhorando a privacidade e reduzindo a quantidade de dados na cadeia. O P2TR fornece uma nova maneira de gastar Bitcoin, combinando a funcionalidade de P2PK e P2SH para aumentar ainda mais a privacidade e fazer com que todas as saídas Taproot pareçam semelhantes na cadeia.
• BIP 342 (Tapscript): Modificou a linguagem de script do Bitcoin para ser compatível com o BIP 340 e BIP 341 para suportar assinaturas Schnorr, verificação em lote e melhorias no hash de assinatura. A introdução do Tapscript também estabelece as bases para futuras atualizações no script do Bitcoin no futuro.

Esses BIPs ativados refletem a estratégia do protocolo Bitcoin de continuar expandindo a funcionalidade e otimizando a eficiência, mantendo sua estabilidade e segurança fundamentais. Ao priorizar soft forks em vez de hard forks, a comunidade Bitcoin conseguiu introduzir melhorias significativas enquanto evita o risco de fragmentação da rede. Essa ênfase na compatibilidade retroativa é um fator-chave na capacidade do ecossistema Bitcoin de permanecer estável. Isso demonstra que a evolução do protocolo não acontece da noite para o dia, mas sim é um processo de mudanças iterativas e deliberadas que gradualmente levam a uma rede mais forte, mais privada e mais eficiente.

3.2 BIPs em Discussão ou Propostos

A comunidade Bitcoin continua a discutir e propor novos BIPs em resposta às necessidades em mudança e desafios técnicos.

• BIP-177 (Redefinir a Unidade Base do Bitcoin): Esta proposta sugere redefinir a menor unidade do Bitcoin, o satoshi, como uma nova unidade base de 1 bitcoin, o que simplificaria a exibição de valores, eliminaria pontos decimais e estaria mais alinhado com os pagamentos da Lightning Network. Isso simplificaria a exibição de valores, eliminaria o ponto decimal e estaria mais alinhado com as práticas de pagamento da Lightning. A proposta envolve apenas ajustes na exibição de carteiras e exchanges, e não altera o protocolo subjacente ou o limite total de quantidade de Bitcoin. Os proponentes argumentam que isso reduziria a carga cognitiva, eliminaria o "medo da unidade" para novos usuários e simplificaria a experiência do usuário ao alinhar melhor com o verdadeiro design de contagem em números inteiros dentro do protocolo Bitcoin. Por exemplo, "0,00010000 BTC" seria exibido como "10.000 BTC". No entanto, a proposta também enfrentou resistência, sendo a principal objeção que ela propõe descartar a unidade "Satoshi" nomeada após Satoshi Nakamoto, o que poderia levar à confusão entre os usuários.
• OP_CAT (BIP-347): OP_CAT é um opcode que permite que dois pedaços de dados na pilha de script do Bitcoin sejam mesclados em um. "CAT" significa "concatenação". OP_CAT originalmente fazia parte da implementação do Bitcoin, mas foi descontinuado em 2010 devido a preocupações sobre potenciais vulnerabilidades e ataques de negação de serviço. Nos últimos anos, o interesse em reativar o OP_CAT foi reacendido com a introdução da atualização Taproot em 2021, que introduzirá capacidades de script aprimoradas e um limite de tamanho (520 bytes para Tapscript), aliviando preocupações de segurança anteriores.
• Usos Potenciais: OP_CAT é capaz de uma variedade de funções complexas, como construir e verificar árvores Merkle diretamente na pilha para permitir caminhos de retirada unilateral, dependência de transação em outras transações já contidas no bloco, etc. Também pode emular "covenants" através da natureza das assinaturas Schnorr, permitindo introspecção detalhada e compromisso com campos individuais de uma transação. Isso torna possível construir contratos inteligentes e aplicações descentralizadas mais complexas, como o CatVM.
• Caminho de Ativação e Desafios: Reintroduzir o OP_CAT exigirá um soft fork. O processo inclui uma proposta formal de BIP com uma revisão completa da comunidade, implementação e testes extensivos no Bitcoin Core, e amplo consenso entre mineradores, desenvolvedores e usuários. Embora o OP_CAT tenha sido "fortemente testado e pesquisado" e seja tecnicamente "direto", e o OP_CAT foi ativado no Bitcoin Signet em 01/05/24, seu caminho para ativação ainda depende de alcançar um consenso no Bitcoin Core. "amplo consenso entre mineradores, desenvolvedores e usuários." Alguns desenvolvedores preveem que os desenvolvedores do Bitcoin Core podem chegar a um consenso sobre o OP_CAT ou OP_CTV em 2025, com a implementação real provavelmente levando mais 1-2 anos.
• Promotor:

1. O Fractal Bitcoin habilitou o OP_CT em sua rede principal desde setembro de 2024 como um ambiente de teste em tempo real para novos protocolos que utilizam seus recursos.
2. A StarkWare criou um fundo de pesquisa OP_CAT de 1 milhão de dólares com o objetivo de avançar a pesquisa sobre a ativação do OP_CAT no Bitcoin. Enquanto isso, por outro lado, combinando OP_CAT com sua tecnologia de Prova de Conhecimento Zero (STARK).
3. CatVM é uma ponte cross-chain sem confiança baseada em OP_CAT proposta pela Taproot Wizards.

• BIP-420 (BIP não oficial): O número oficial é na verdade BIP-347. O BIP-420 foi originalmente criado por membros da comunidade como um número não oficial para a proposta OP_CAT na rede Bitcoin para abordar a distribuição lenta de números de propostas. Tradicionalmente, os números BIP eram atribuídos por um único desenvolvedor, Luke Dashjr, resultando em uma espera de aproximadamente seis meses para que as propostas OP_CAT recebessem um número oficial. No início de 2024, o desenvolvedor Anthony Towns criou um sistema de numeração alternativo, BINANA, e atribuiu ao OP_CAT o número BIN-2024-0001. Subsequentemente, os Membros do Taproot Wizards lançaram a campanha "BIP-420", usando o número simbólico "420" para criar impulso para a proposta. Ao mesmo tempo, a desenvolvedora principal Ava Chow propôs adicionar mais editores BIP para acelerar o processo de numeração. No final, após o impulso da comunidade e a expansão da equipe editorial, a proposta OP_CAT recebeu oficialmente o número BIP-347 em 24-04-2024, marcando o reconhecimento oficial da proposta e uma base de discussão mais ampla.
• BIP-119 (OP_CTV): Proposto por Jeremy Rubin em 2021, esta proposta permite regras de transação mais flexíveis através do CheckTemplateVerify e suporta funcionalidade de covenant. De maneira semelhante ao OP_CAT, esta proposta visa adicionar um recurso de "covenant" semelhante ao contrato inteligente do Ethereum à rede Bitcoin, como permitir instruções para limitar a transferência de fundos para um endereço específico ou automatizar transações, como transferências programadas, a fim de aumentar a programabilidade do Bitcoin. Também atualmente inativo, as discussões da comunidade estão em andamento, com alguns desenvolvedores recorrendo ao OP_CCV (BIP-443) como alternativa.
• BIP-348 OP_CHECKSIGFROMSTACK (CSFS): um novo opcode para Bitcoin, OP_CSFS, proposto por Jeremy Rubin e Brandon Black em novembro de 2024. o opcode permite a verificação se uma assinatura é válida para uma mensagem arbitrária, não limitada ao hash da transação atual, obtendo a assinatura da pilha de dados. o opcode também é usado para verificar se uma assinatura é válida para uma mensagem, não apenas o hash da transação atual, OP_CSFS é uma ferramenta importante para permitir Covenants mais flexíveis, possibilitando a criação de lógica condicional complexa para limitar o gasto de dinheiro, melhorar a segurança (por exemplo, Cofres e Prevenção de Roubo de Protocolo Descentralizado), e pode ser combinado com opcodes como OP_CAT para construir contratos inteligentes mais complexos. bip-119 (CTV) e bip-348 (CSFS), dois opcodes que são relativamente novos para o Bitcoin, foram propostos para o Bitcoin. CSFS), ambos os quais são mais cautelosos e conservadores em relação ao BIP-347 (OP_CAT), são em vez disso esperados para entrar em funcionamento na rede principal do Bitcoin antes do OP_CAT
• "Protocolo de Migração de Endereço Resistente a Quântico" (QRAMP): Uma grande proposta de um desenvolvedor Bitcoin para proteger o Bitcoin de futuras ameaças de computação quântica através de um único hard fork, o plano é forçar a rede Bitcoin a migrar de carteiras mais antigas criptografadas usando o tradicional ECDSA (Algoritmo de Assinatura Digital de Curva Elíptica) para carteiras mais novas que empregam técnicas de criptografia pós-quântica. Os computadores quânticos ameaçam a segurança do Bitcoin utilizando a capacidade dos bits quânticos (qubits) de existir em múltiplos estados ao mesmo tempo, aumentando dramaticamente o poder de computação e potencialmente quebrando os algoritmos de criptografia existentes. A proposta estabelece uma altura de bloco como ponto de corte da migração, momento em que os nós se recusarão a processar transações que ainda usam endereços criptográficos tradicionais, forçando os usuários a migrar seus fundos para uma carteira mais segura. Embora esta seja uma medida de precaução, e a computação quântica ainda não esteja em um ponto onde ameace o Bitcoin, a proposta desencadeou intensa discussão e preocupação da comunidade sobre hard forks com avanços recentes no campo de processadores quânticos por empresas como a Microsoft.

Essas discussões em andamento e BIPs propostos refletem os esforços contínuos da comunidade Bitcoin para equilibrar inovação, segurança e descentralização. A reativação de opcodes como OP_CAT, OP_CTV e outros visa desbloquear funcionalidades mais avançadas em scripts Bitcoin para suportar contratos inteligentes e aplicações mais complexas. No entanto, tais extensões de funcionalidade devem ser feitas sob rigoroso escrutínio de segurança para evitar repetir erros históricos que poderiam levar a potenciais ataques de negação de serviço. Ao mesmo tempo, mudanças aparentemente simples na interface do usuário como o BIP-177 desencadearam discussões profundas sobre cultura, percepção do usuário e imagem de marca, sugerindo que a evolução do Bitcoin não é apenas uma questão técnica, mas também um reflexo de fenômenos sociais e culturais.

4.O Impacto das Pools de Mineração nas Atualizações de Protocolo

Os mineradores desempenham um papel fundamental na ativação de atualizações do protocolo Bitcoin, especialmente durante a adoção de soft forks.

4.1 Sinalização de Mineradores e Mecanismos de Ativação

As atualizações do protocolo Bitcoin são tipicamente ativadas através de uma "votação de sinal" pelos mineradores. Os mineradores indicam seu apoio e prontidão para um BIP incluindo sinais específicos nos blocos que minam (por exemplo, usando um número de versão especificado no cabeçalho do bloco). Para soft forks, um limite de ativação predefinido (por exemplo, 95 % dos blocos sinalizando durante um período de tempo) geralmente precisa ser alcançado para ativar uma nova regra. Uma vez que esse limite é alcançado, o soft fork é implementado e a comunidade (incluindo mineradores, nós completos, exchanges, provedores de serviços de pagamento, etc.) deve atualizar seu software para a nova versão.

4.2 Potencial para Veto de Mineradores

Os mineradores têm um poder de veto de fato na ativação de um soft fork. Se os mineradores não sinalizarem prontidão, a atualização não pode ser ativada. Isso é particularmente evidente na ativação do Segregated Witness (SegWit): os mineradores inicialmente têm baixo apoio e não sinalizam prontidão até que o mercado mostre demanda fraca por propostas concorrentes. Esse fenômeno sugere que as decisões dos mineradores nem sempre são baseadas em considerações puramente técnicas, mas são significativamente influenciadas pela dinâmica do mercado e incentivos econômicos.

4.3 Incentivos econômicos para mineradores

As pools de mineração, como uma coleção de recursos computacionais dos mineradores, têm enorme influência na rede Bitcoin, o que lhes confere significativo poder de decisão na adoção e ativação de BIPs. Ao mesmo tempo, o comportamento dos mineradores é frequentemente impulsionado por incentivos financeiros. Por exemplo, o aumento das inscrições levou a um aumento significativo nas taxas de transação na rede Bitcoin, gerando receita significativa para os mineradores, o que levou muitos mineradores a abraçar as inscrições mesmo que alguns desenvolvedores as vejam como "spam". Essa racionalização econômica explica por que, mesmo sendo controversos, certos casos de uso ainda são apoiados pelos mineradores e incluídos nos blocos. Ao escolher qual versão do software executar e se sinalizam ou não seu apoio, eles estão, de fato, exercendo uma espécie de "voto suave". Esse poder não é absoluto, já que usuários e todos os nós podem impor consenso rejeitando blocos que não estejam em conformidade com suas regras, mas o comportamento coletivo dos mineradores é certamente uma variável-chave na evolução do protocolo.

5.Um Processo de Atualização Demorado

Como o Bitcoin é uma rede descentralizada, qualquer mudança requer um amplo consenso entre desenvolvedores, mineradores e usuários, e esse processo de consenso é complexo e demorado, tornando o processo de atualização do Bitcoin lento. Historicamente, como o debate sobre o tamanho do bloco de 2017 (que levou ao fork do Bitcoin Cash) mostrou o risco de divergência, e a atualização Taproot (ativada em 2021) levou anos de discussão e testes. Além disso, complexidades técnicas como os riscos potenciais de segurança do OP_CTV e OP_CAT tornam um processo longo para a comunidade Bitcoin avançar com esses BIPs. Como resultado, a carteira Bitcoin Xverse lançou um site de petição comunitária (https://whatthefork.wtf/) para que as pessoas assinem uma assinatura de carteira indicando que desejam que o soft fork do BTC suporte OP_CTV e OP_CAT, para tentar impulsioná-lo através da voz da comunidade.

Devido a atualizações lentas, muitos projetos do ecossistema Bitcoin estão projetando soluções complexas com funcionalidade limitada atual. Por exemplo, o BitVM (Bitcoin Virtual Machine) propõe implementar funcionalidade de contrato inteligente através de um modelo provador-verificador que computa fora da cadeia e verifica na cadeia sem alterar as regras de consenso. Outra estratégia é usar o Bitcoin como uma Camada de Disponibilidade de Dados (DA), que utiliza a segurança do Bitcoin para armazenar dados e suportar extensões de sidechain ou Rollup.

6.Conclusão

O desenvolvimento e manutenção do Bitcoin é um processo descentralizado único e em constante evolução. É impulsionado por uma comunidade global de desenvolvedores de código aberto, e sem uma única entidade controlando seu desenvolvimento, o modelo de desenvolvimento do Bitcoin é um complexo ato de equilíbrio: a inovação tecnológica é prudentemente conduzida através de um processo estruturado de BIPs e um mecanismo de consenso multi-stakeholder sob os princípios de abertura, descentralização e orientação comunitária. Como resultado, este modelo inevitavelmente levou a um ritmo mais lento de desenvolvimento do Bitcoin, e precisaremos continuar a observar se ele é capaz de continuar se adaptando a novos desafios e necessidades, enquanto garante a resiliência, segurança e resistência à censura da rede Bitcoin.