Regras de consenso e validação

Curiosidade

1. O que impede um minerador com mais poder de imprimir moedas infinitas?
2. Por que uma transação que seu nó se recusa a retransmitir ainda pode acabar em um bloco válido?
3. Se houver mudança no código de consenso, todos precisam fazer o upgrade exatamente ao mesmo tempo?

Explorar

1. As regras de consenso são os critérios rigorosos que todo nó completo utiliza para validar blocos. Elas definem o que é tecnicamente possível: o cronograma de emissão, o limite de peso do bloco de 4.000.000 de unidades, a dificuldade do proof-of-work e a validade das assinaturas. Um bloco que violar qualquer uma dessas regras é rejeitado por todos os nós honestos, independentemente da quantidade de poder de processamento utilizado para sua geração. Os mineradores propõem blocos; os nós decidem se eles são aceitos. Essa separação garante que nenhuma entidade possa alterar unilateralmente o estado do livro-razão.
2. As regras de política determinam o que um nó transmite para seus pares antes da mineração. Elas incluem limites de volume de transações, taxas mínimas de transmissão e tipos padrão de scripts. Uma transação que viola a política é descartada pela maioria dos nós, mas permanece válida se um minerador a incluir em um bloco. Essa distinção é importante: confiar na rejeição por parte das políticas para garantir segurança é arriscado, pois um agente determinado pode contornar os filtros dos pares e enviar as transações diretamente aos mineradores, forçando a rede a aceitar transações não padrão desde que elas atendam ao consenso.
3. O código é a especificação. As regras são aquelas que o software dos nós amplamente utilizados realmente impõe, incluindo os casos extremos, e é por isso que as alterações no código de consenso ocorrem lentamente e são revisadas com mais intensidade do que qualquer outro elemento no Bitcoin Core. Os bugs relacionados ao consenso são tratados como emergências: o bug de overflow de valores em 2010 e o bug de inflação em 2018 foram ambos corrigidos sob pressão, por meio de lançamentos coordenados.
4. Alterações nessas regras exigem adoção coordenada. Os soft forks tornam as regras mais rígidas, de modo que os nós não atualizados ainda aceitam os novos blocos; os hard forks as flexibilizam ou alteram, fazendo com que todos os nós precisem ser atualizados ou se separarem. Uma lição posterior abordará ambos em detalhes. O SegWit (agosto de 2017) foi um soft fork; o Bitcoin Cash (agosto de 2017) surgiu de uma disputa sobre hard forks relacionada aos limites de tamanho dos blocos.
5. Produzir um bloco é caro; verificar um é barato. Um minerador que produz um bloco inválido perde a recompensa e a energia gasta, pois todos os nós de validação o descartarão, o que torna a violação das regras uma aposta dispendiosa. Esse custo reforça a rigidez da validação: a segurança da rede depende de milhares de nós independentes que verificam cada cabeçalho e transação, garantindo que nenhum ponto único de falha possa corromper o estado compartilhado.
6. Abra um explorador de blocos como mempool.space ou blockchain.com. Selecione qualquer bloco recente e examine seu campo “peso”. Compare esse número com o limite de 4.000.000 de unidades de peso definido no BIP141. Observe quão perto os blocos modernos ficam desse teto, o que reflete os mineradores maximizando a receita por byte, ao mesmo tempo em que respeitam as restrições do consenso impostas por todos os nós.

Fatos-chave

Exercício nove, seis, três, um

Verificação de fatos

Datas, números e afirmações verificados com as fontes publicadas listadas abaixo.

• A. M. Antonopoulos & D. A. Harding, Mastering Bitcoin, 3rd ed. (2023), ch. 12
• E. Lombrozo, J. Lau & P. Wuille, BIP141: Segregated Witness (Consensus layer) (2015)
• Bitcoin Core source code: validation.cpp and policy.cpp
• Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, section 5