Mara van der Laan é uma programadora conhecida pela conta laanwj e, nos registos históricos, como Wladimir van der Laan. Trabalhou na manutenção de Bitcoin Core, software para verificar autonomamente a cadeia Bitcoin. Essa função implicava responsabilidade pelo programa, não autoridade para decidir por toda a rede.
O perfil público laanwj apresenta hoje Mara van der Laan e a sua antiga função de manutenção de Bitcoin Core. Os registos antigos usam o nome histórico Wladimir van der Laan. Referem-se ao trabalho da mesma programadora, não a duas pessoas diferentes. Manter um projeto exige mais do que inventar funcionalidades. É também necessário avaliar se as alterações estão prontas, coordenar a sua integração e colaborar com quem revê e testa o código. Esta parte menos visível ajuda a compreender o seu contributo. [1] [4]
Num texto de 21 de janeiro de 2021, van der Laan descreveu um problema comum em projetos duradouros: demasiadas tarefas acabam por depender de uma pessoa específica. Bitcoin Core já tinha vários responsáveis de manutenção, mas ela queria delegar mais e reduzir o seu envolvimento. Não anunciava o fim completo dos contributos. Pretendia que os passos importantes deixassem de esperar especificamente por ela. Imagine uma versão pronta para publicação, parada apenas porque uma pessoa indispensável não está disponível. Partilhar responsabilidades ajuda a evitar isso. [2]
O plano de 2021 abrangia a distribuição do programa, a assinatura das versões e os espaços de colaboração. Van der Laan considerava IPFS para partilha distribuída de ficheiros e Radicle para trabalhar no código sem depender de um servidor central. O objetivo era que a indisponibilidade de uma pessoa, site ou fornecedor não impedisse o trabalho dos restantes. Mencionar uma ferramenta documenta uma proposta, não a sua adoção concluída. Identificar uma fragilidade, planear uma solução e utilizá-la realmente são etapas distintas. [2]
Na reunião de programadores de 11 de agosto de 2022, laanwj anunciou que deixava a manutenção de Bitcoin Core. Em concreto, deixaria de integrar alterações no código comum e de preparar versões. Manteve a possibilidade de rever código ocasionalmente: é possível analisar propostas sem ocupar aquela função. Expressou também confiança nas pessoas que já faziam grande parte do trabalho. As datas são, por isso, importantes. Um título antigo não descreve automaticamente a situação atual, e sair de uma função não elimina todas as formas de contribuir. [3]
Bitcoin Core descreve os responsáveis de manutenção como pessoas que integram alterações revistas e aceites pela equipa, fazendo uma última verificação. Um repositório guarda o código e o seu histórico; ter acesso não obriga os operadores de nós a instalar uma versão. Um nó é um computador que verifica as regras de Bitcoin com o software escolhido. Influenciar um programa importante não permite alterar, com uma ordem, o comportamento de todos. Distinguir a gestão do projeto das regras adotadas pela rede torna a descentralização mais concreta. [4]
A responsabilidade também chega a quem descarrega Bitcoin Core. O ficheiro SHA256SUMS contém as somas de verificação da versão. Compará-las permite confirmar se o ficheiro corresponde à impressão digital indicada. Mas um atacante poderia substituir o programa juntamente com a lista. Por isso, verificam-se também as assinaturas digitais e a impressão digital da chave, um identificador curto da chave pública do signatário. É necessário compará-lo com informação obtida de forma fiável. Um nome associado a uma chave não prova identidade. Ficheiro, assinatura e titularidade da chave exigem verificações relacionadas, mas diferentes. [5]
O código-fonte é a forma legível e editável do programa; a compilação transforma-o em ficheiros executáveis. As compilações reproduzíveis de Bitcoin Core permitem produzir independentemente ficheiros idênticos e comparar as suas impressões digitais com as da versão publicada. Assim, diminui a necessidade de confiar cegamente no computador que preparou a transferência. A correspondência não prova, porém, que o código esteja isento de erros. Um erro no código pode repetir-se fielmente em todas as compilações iguais. A verificação da origem e a revisão técnica do código complementam-se, sem se substituírem. [5]
Falta outra pergunta: essa versão ainda recebe correções? Bitcoin Core publica o ciclo de vida das versões, distinguindo as suportadas das que chegaram ao fim do suporte. Estas últimas geralmente deixam de receber correções de segurança. Uma assinatura antiga válida pode continuar a comprovar a origem do ficheiro original, sem garantir manutenção atual. Ao escolher o programa, verifique também o suporte e as notas da versão. A história do projeto, a autenticidade do ficheiro e a adequação atual da versão são questões relacionadas, mas distintas. [6]
Para ter uma visão mais completa, leia este verbete junto com Peter Todd, Andrew Poelstra, Bitcoin Core. Também há referências a este verbete em Peter Todd, Andrew Poelstra.