Como é revisar o código do Bitcoin

Em 19 de junho, o desenvolvedor do Chaincode, John Newbery, reuniu um grupo de desenvolvedores para examinar uma proposta de alteração no código do bitcoin.

Ocorrendo via Internet Relay Chat (IRC), o tópico era se a mudança, que ajudaria a impedir que um grupo de mineradores desonestosacelerando a taxa de produção dos blocos de bitcoin, é positivo <a href="https://bitcoin-core-review-club.github.io/15481.html one with">, com</a> riscos de segurança limitados ou impactos adversos.

O objetivo de Newbery, então, é transmitir o que ele sabe sobre a revisão desse código.

Esse bloqueio de 'ataque de distorção temporal' foi uma mudança sólida?

"O timewarp explora isso empurrando o bloco de ajuste de dificuldade para o futuro e, em seguida, o próximo bloco de volta para o presente", escreveu Newbery, explicando o vetor de ataque.

Mas o fato de Newbery estar realizando essas sessões pode ser visto como um sinal da maturidade da comunidade de desenvolvedores do bitcoin, pois este é um exemplo de como os principais codificadores do projeto têm trabalhado arduamente para tornar o projeto mais inclusivo. O processo de revisão de código talvez T tenha sido discutido tão aberta e profundamente antes.

Newbery iniciou o Bitcoin CORE Review Club <a href="https://bitcoin-core-review-club.github.io/">https://bitcoin-core-review-club.github.io/</a> para dar dicas aos codificadores sobre como descobrir como revisar uma alteração e determinar se ela é benéfica para a Criptomoeda. As transcrições das reuniões agora são publicadas no site toda semana.

Isso é possível porque o código do bitcoin é de código aberto, residindono GitHubpara qualquer pessoa com uma conexão de internet olhar – ou até mesmo mudar. Esse processo levou o projeto do código que as pessoas chamavam de "bolha monolítica"para software que é mais fácil para os desenvolvedores lerem com menos bugs críticos. As pessoas estão constantemente tentando melhorá-lo, com o objetivo final elevado de torná-lo uma base de código valiosa para o futuro do dinheiro.

Então, também é possível ser uma das pessoas que contribuem para o código do bitcoin. Diferentemente do código proprietário, seu código qualquer um pode ver e usar - o que é conhecido como "código aberto".

Um dos motivos pelos quais é chamado de “dinheiro programável” é que, diferentemente de outros tipos de dinheiro digital, qualquer pessoa no mundo com o conhecimento certo pode tentar adicionar novos recursos de código ao dinheiro. Uma das maneiras de Aprenda a base de código é revisar e testar o código que os programadores enviam, para garantir que ele realmente funcione e T introduza um bug ou — uma realidade infeliz — divida acidentalmente a rede Bitcoin ao meio.

Mas olhando as páginas de código e centenas de mudanças propostas, é difícil saber por onde começar.

"Este clube semanal de IRC é para pessoas que querem ajudar a revisar solicitações de pull do Bitcoin CORE , mas acham o processo intimidador", explica o site do clube, continuando:

"Revisar e testar pull requests é a melhor maneira de começar a contribuir para o Bitcoin CORE, mas é difícil saber por onde começar. Existem centenas de pull requests abertas, muitas exigem muito conhecimento contextual, e os Colaboradores e revisores geralmente usam terminologia desconhecida."

Como tal, enquanto o código para essa moeda digital está disponível para qualquer um olhar ou alterar, não é necessariamente fácil fazê-lo. É preciso prática para saber o que revisar.

Veja como é o processo.

Qualquer um pode fazer isso

Para começar, os usuários podem ir ao GitHub, um site que hospeda todos os tipos de projetos de código-fonte aberto. Há um especificamente para o Bitcoin CORE, a implementação de software Bitcoin subjacente que a maioria dos usuários executa.

Você notará que há muito no GitHub, mas revisar o código é basicamente olhar para "solicitações de pull, uma série de mudanças que os desenvolvedores de todo o ecossistema enviaram para revisão.

Em outras palavras, há 300 alterações que ainda T foram revisadas o suficiente para serem oficialmente adicionadas à base de código, desde tornar a documentação que descreve o código mais fácil de ler até melhorar o desempenho do Bitcoin.

Neste ponto, os desenvolvedores estão tentando decidir se essas mudanças devem ser aprovadas. O problema é que há desenvolvedores limitados que têm experiência suficiente na revisão de mudanças de código para determinar se elas devem ser oficialmente adicionadas à base de código. Por causa disso, um colaborador do Bitcoin CORE descreveu uma vez a lista de solicitações de pull como uma “cemitério de ideias legais."

É por isso que a Newbery está tentando ajudar nesse processo.

Então, como ONE realmente faz para revisar uma mudança? Como Newbery descreve no site do clube, há algumas etapas importantes para começar, como olhar o “contribuindo para o guia Bitcoin CORE" e mexendo com C++, a linguagem de programação na qual o Bitcoin CORE foi escrito.

O próximo é simplesmente escolher uma mudança para revisar. Com mais de 300 solicitações de pull ativas e ativas, por onde começar? As melhores escolhas para alguém que ainda T conhece a base de código são mudanças de código que são especificamente rotuladas como “boas primeiras questões”.

Quando os preliminares terminam, o desenvolvedor precisa “clonar” o repositório ou usar o git para fazer uma cópia da base de código para seu computador, para que ele possa testar se a mudança funciona conforme o planejado.

Basta um comando simples para copiar toda a base de código para o seu computador.

A partir daí, você pode revisar o pull Request. Os desenvolvedores devem então executar todos os "testes" para garantir que a alteração do código T atrapalhe acidentalmente outro pedaço de código e, em seguida, passar para a revisão do restante do código.

Dentro da mente de um revisor

O que os revisores precisam pensar?

Primeiro, há preocupações de alto nível. Determinar se uma mudança deve ser feita, especialmente uma ONE, é basicamente baseado em “consenso aproximado”, o que significa que a maioria dos Colaboradores ativos concordaria que uma mudança deve ser buscada.

Em outra reunião do clube, Newbery dissehttps://bitcoin-core-review-club.github.io/16060.html:

“Meus pensamentos sobre abrir pull requests: ninguém lhe deve uma revisão. Qualquer um que revise seu código está lhe fazendo um favor. Se você abrir um pull Request, estará competindo com outros pull requests por tempo de revisão.”

“Se tiver dúvidas sobre o quão útil outras pessoas acham que sua Request de pull será, sinta-se à vontade para perguntar em #bitcoin-core-dev ou perguntando diretamente a outros Colaboradores”, acrescentou Newbery, referindo-se a outro grupo do IRC onde os desenvolvedores podem fazer perguntas relacionadas ao desenvolvimento do Bitcoin CORE .

Dito isso, os desenvolvedores T sempre concordam se uma mudança vale a pena adicionar ou não. Em uma semana, o grupo de desenvolvedores se concentrou em uma mudança de código controversa. Alguns argumentaram que o ruim superou o bom, enquanto outros ainda argumentam que poderia ser útil.

Mas mesmo que a ideia seja ONE em geral, também há preocupações de nível inferior. Há bugs? A mudança de código vem com testes que garantem que a mudança de código funcione conforme o planejado? Essas são as perguntas que muito tempo de revisão é gasto respondendo.

Na reunião de 29 de maio (cuja transcrição completa você pode encontrar aqui <a href="https://bitcoin-core-review-club.github.io/15741.html">https://bitcoin-core-review-club.github.io/15741.html</a> ), por exemplo, os desenvolvedores analisaram uma melhoria de desempenho para a parte da carteira do nó Bitcoin .

Um colaborador com o pseudônimo 'Ariard' liderou a reunião passando pelo processo de revisão que eles desenvolveram ao longo do tempo. “Tentei primeiro identificar que tipo de PR era: Doc, estilo de código, correção de buf, novo recurso ou adição de teste. Porque [na minha Opinião] saber esse fato vai orientar como você lê os commits pela primeira vez, quanto tempo você precisará para revisão e que tipo de testes são necessários”, disse o desenvolvedor.

Outro revisor apontou que eles notaram uma melhora apenas verificando quanto tempo o código levou para rodar – antes e depois. “Minha importação de 10000 chaves foi de 8 minutos para 3 segundos xD,” disse outro usuário que atende pelo nome de 'jb55.'

As transcrições das reuniões estão ainda mais repletas de várias outras dicas sobre como agilizar esse processo e torná-lo mais fácil de revisar, com mais reuniões a serem agendadas no futuro. As próximas seções serão lideradas pelo escritor técnico e contribuidor do Bitcoin , David Harding.

Imagem de Adam Back via arquivos de consenso