Como os desenvolvedores de Bitcoin se certificam de que suas modificações não afetam as regras de consenso ou o protocolo de rede em execução?
Eu entendo que as regras de consenso do Bitcoin são aplicadas por cada nó individualmente . No entanto, a maioria das pessoas executa a versão padrão do Bitcoin Core, o que torna as implementações feitas pelos desenvolvedores de Bitcoin as mais importantes.
Portanto, minha pergunta está no título: como eles garantem que as implementações não afetem as regras de consenso ou o protocolo de rede?
Embora eu também entenda que cada versão do Bitcoin é lançada com extremo cuidado e testes extensivos, fico me perguntando se existe uma prática sistemática para isso. Qualquer ponteiro seria muito apreciado.
Respostas
"Melhor esforço". Provas formais não ajudam. Tudo o que se pode fazer é escrever testes, como qualquer outro software bem escrito.
Eles também mantêm bifurcações de algumas dependências, como LevelDB, e não atualizam algumas delas, como BerkeleyDB .
Veja o que deu errado . Especialmente o hardfork de 2013 não teria acontecido se eles pudessem garantir um protocolo de consenso inalterado.
Os colaboradores do Core de longo prazo têm um entendimento geral de quais partes da base de código do Core tocam ou podem impactar o consenso entre os nós na rede. No entanto, o consenso é "escorregadio" e houve exemplos no passado em que mudanças foram feitas que não eram consideradas críticas para o consenso na época, mas acabaram sendo. O MCCCS destaca alguns desses exemplos na resposta acima.
Pieter Wuille discutiu os desafios de definir o que é consenso e o que não está no podcast do Chaincode Labs em janeiro de 2020.
Uma das coisas que acho que aprendi com isso é que é realmente difícil especificar quais são suas regras de consenso. Isso não significa que você não pode tentar, mas quem teria pensado que uma definição de configuração na camada de banco de dados que você está usando realmente vazou semanticamente para as regras de consenso definidas implicitamente do Bitcoin. Você pode atribuir isso ao fracasso humano, é claro. Devíamos ter lido a documentação e estar cientes disso.
Podemos falar sobre o limite ao tentar abstrair a parte da base de código que contribui intencionalmente para o consenso, mas é muito difícil dizer claramente que esse código não tem impacto no código de consenso porque bugs podem vazar. Acho que uma das coisas a aprender é que você realmente deseja um software destinado ao uso em um sistema de consenso, onde não só você tem o requisito de que, se todos se comportarem corretamente, todos aceitem a resposta certa, mas também que todos concordem sobre o que é um dados inválidos em lockstep.