Por que os CORE desenvolvedores do Bitcoin querem várias versões

Debates recentes sobre se as pessoas deveriam ter permissão para fazer suas próprias alterações no protocolo Bitcoin destacaram uma noção importante: talvez desenvolver o Bitcoin CORE, a versão de referência do código, T seja a única maneira das pessoas contribuírem.

Uma alteração recente no código Bitcoin que chegou a uma variante do Linux chamada Gentoodeixou algumas pessoas furiosas antes que o desenvolvedor o desligasse por padrão.

"Eles nunca serão mesclados ao repositório Bitcoin no Github, mas as pessoas que quiserem usá-los podem", disse o desenvolvedor líder do Bitcoin , Wladimir J van der Laan.

Mas o que é o Github, por que van der Laan tem autoridade para escolher o que vai nele e como o Bitcoin é desenvolvido em primeiro lugar?

Como o Bitcoin é desenvolvido

A implementação de referência para o protocolo Bitcoin é chamada de Bitcoin CORE. Este é o código que Satoshi originalmente entregou a um grupo CORE de desenvolvedores antes de desaparecer.

Esses "discípulos" agora mantêm esse código, junto com a ajuda de uma comunidade mais ampla de desenvolvedores. O foco é tornar o código mais eficiente, mas fazê-lo com cuidado e de forma conservadora, para que nada seja quebrado.

O Bitcoin CORE é gerenciado usando um sistema de controle de versão de software chamado Git. Isso permite que as pessoas KEEP em quais versões do código estão trabalhando e quais alterações fizeram.

Os desenvolvedores de Bitcoin que executam o Git em seus computadores se conectam a um serviço central para que todos possam trabalhar em versões do mesmo projeto ao mesmo tempo. Este serviço, chamado Github, tem muitos projetos diferentes mantidos por diferentes grupos de pessoas. O Bitcoin é um desses projetos e tem seu próprio Página do Github.

O código do projeto é mantido em um único lugar no Github, chamado repositório. A versão oficial e implementável do repositório Bitcoin é conhecida como repositório upstream, mas as pessoas que querem trabalhar em suas próprias alterações no código podem criar suas próprias versões do repositório, copiando-o para um 'fork' online.

Os desenvolvedores podem modificar seus forks o quanto quiserem. Eles podem pedir que seu fork seja mesclado de volta ao repositório mestre emitindo uma 'pull Request', que abre sua versão do repositório para outros membros do projeto, que podem revisá-lo e comentá-lo.

"A ideia é que outros desenvolvedores na comunidade revisem a mudança", explicou van der Laan. "Então, o remetente corrige os problemas levantados por outros. Também pode ser necessário Rally algumas pessoas para testar a mudança, especialmente se ela for complicada, ou se houver um componente subjetivo (por exemplo, para mudanças de UI ou RPC)."

Se pessoas suficientes gostarem das mudanças feitas em um pull Request, então ele é mesclado de volta ao repositório mestre. Mas quem realmente consegue mesclar o pull?

Acontece que há um sacerdócio Bitcoin , de certa forma, que administra o que finalmente entra no código do Bitcoin CORE . Van der Laan, cientista chefe e ex-desenvolvedor líder Gavin Andresen, Jeff Garzik, Gregory Maxwell e Pieter Wuille são a equipe que toma a decisão final, e isso T é algo que é decidido por votação, como você pode encontrar em uma democracia.

“Repositórios Github únicos não são democráticos”, explicou van der Laan. “Seus mantenedores cooperam no desenvolvimento e decidem o que é mesclado e quando, e o que não é. Problemas técnicos difíceis não são resolvidos por votação popular."

BIPS e solicitações de pull

Quando possível, porém, o desenvolvimento do Bitcoin normalmente opera por meio de consenso popular. Existem duas categorias de mudança, falando de modo geral.

O Bitcoin CORE é mantido de forma intencionalmente conservadora, e a maioria das mudanças são feitas de forma “não controversa e zeladora”, disse van der Laan. Elas lidam com pequenas mudanças incrementais, em vez de grandes e revolucionárias. Um patch do Bitcoin pode mover algum código para torná-lo mais legível, ou talvez otimizar algum uso de memória.

Há outra classe de mudanças no Bitcoin que tem muito mais ramificações, e essas são as que mudam as regras de consenso. As regras de consenso são as regras técnicas que todos os clientes Bitcoin devem aderir para que a rede Bitcoin opere corretamente.

"Esses precisam ser examinados de perto. Eles precisam ser discutidos na lista de discussão primeiro, e deve haver um BIP, e os pulls são geralmente controversos e ficam abertos por um longo tempo para discussão", disse ele.

Um BIP – abreviação deProposta de Melhoria do Bitcoin– é um documento que sugere uma mudança global em algum aspecto do Bitcoin. Ele pode se estender para coisas fora do Bitcoin CORE, incluindo carteiras móveis ou geração de chaves em carteiras de hardware. Ele também pode governar processos em torno do Bitcoin, como mudanças no processo de tomada de decisão.

Qualquer pessoa pode criar um BIP, desde que seja escrito emeste formato. A comunidade fala sobre isso e, se as pessoas gostarem, seu status pode ser alterado para "ativo" ou "final".

Mudanças nesse sentido são a mudança emBIP 62, que foi uma mudança que lida com ofalha de maleabilidade de transação em Bitcoin.

O que melhora a chance de uma mudança proposta ser implementada no protocolo? Ajuda para o autor de um BIP ter escrito um exemplo do código para as pessoas testarem e revisarem, van der Laan acrescentou.

Revisão e aprovação

Consultor de Bitcoin e auditor de segurança Sérgio Lernergostaria de ver mais formalização no processo de aprovação do código.

"Quando você vê uma Request de pull que foi mesclada, é difícil dizer quem a aprovou [e até que ponto] o patch foi revisado", disse ele. "Você tem que ler muitos comentários e alguns '+1' que você pode interpretar como 'Eu concordo em mesclar', mas você também pode interpretar como 'Eu gosto, mas eu realmente T revisei o código.'"

Lerner gostaria de ver ummulti-assinatura processo de aprovação de patch, no qual uma certa proporção de desenvolvedores aprova formalmente o código assinando a revisão. Essa seria uma versão maior do processo atualmente usado em algumas carteiras, onde múltiplas assinaturas precisam ser usadas para que um endereço de Bitcoin seja usado.

Outras coisas que Lerner gostaria de ver incluem um registro de bugs encontrados e uma análise do motivo pelo qual eles não foram detectados a tempo, uma revisão de código externa focada na segurança por patch, uma descrição formal da documentação que deve acompanhar um patch e uma descrição do que realmente significa revisar um patch.

“Isso significa uma revisão do código-fonte linha por linha? Isso significa verificar se a documentação da mudança é suficiente?” Lerner perguntou. “Isso significa analisar a mudança contra vetores de ataque conhecidos?”

O problema é que tudo isso leva tempo e recursos Human , disse Lerner:

"Obviamente, implementar tudo isso requer mais manutenção, um orçamento maior e mais recursos de desenvolvedores CORE (que atualmente são escassos). Mas um software que mantém uma indústria de US$ 6 bilhões exige isso."

Além do Bitcoin CORE

Enquanto Lerner descreve alguns requisitos para revisões de código, van der Laan ecoa o discurso principal de Gavin Andresen naConferência Bitcoin 2014, onde ele disse quemais poderia ser feito para agilizar a aprovação do BIP.

“O processo BIP poderia usar algum trabalho. Eu ficaria feliz se os desenvolvedores de outras implementações de nós (completos) fossem mais ativos em comentar propostas (ou apresentar propostas)”, disse ele.

Andresen também propõe mover a discussão sobre o BIP e outras preocupações de implementação cruzada da lista de discussão geral sobre desenvolvimento de bitcoin para uma lista de discussão específica sobre o BIP.

Assim como no desenvolvimento de software em um projeto de código aberto, a responsabilidade de fazer isso acontecer é sempre dos usuários.

“Como é inerentemente um processo global, distribuído e desorganizado, não cabe a uma única organização gerenciar o processo do BIP, então a responsabilidade recairia sobre as pessoas e organizações que se importam em BAND e fazer alguma coisa”, sugeriu van der Laan.

Mas a Bitcoin Foundation, a principal organização comercial do bitcoin, T deveria estar cuidando dessas coisas? Não, ele argumenta. Em vez disso, as coisas no mundo do Bitcoin estão se expandindo além disso, e a equipe de desenvolvimento acolhe diferentes implementações do Bitcoin.

Van der Laan disse:

"A palestra de Gavin no Bitcoin 2014deixou claro que seu foco é diversificar. Ele falou sobre diferentes implementações de full node, até disse 'quanto mais, melhor'. Embora manter o Bitcoin CORE seja meu trabalho, tendo a concordar com isso."

A responsabilidade não deve mais recair sobre o desenvolvimento do Bitcoin CORE, acredita van der Laan.

"Nos anos iniciais, o Bitcoin CORE talvez fosse excessivamente importante, e seus desenvolvedores tinham que KEEP a luz acesa para a infraestrutura do nó (e ficar acordados à noite para corrigir bugs conforme eles apareciam). Mas, avançando, para que o Bitcoin seja o sistema distribuído global que deveria ser, devemos ir além disso."

Então, pode haver um sacerdócio benevolente para o Bitcoin CORE, no sentido de que a decisão final sobre o que vai para o código cabe a um pequeno grupo de pessoas. Mas isso T significa que esse grupo queira que as coisas sejam exclusivas ou elitistas – longe disso.

Pelo menos alguns dos desenvolvedores CORE estão ativamente encorajando outros a expandir a rede com suas próprias implementações, partindo do pressuposto de que a maioria deles seguirá as regras de consenso. Aqueles que T seguirem sairão da sincronia, tornando óbvio quem está na minoria e forçando-os a consertar isso.

A evolução do Bitcoin nessa direção poderia criar espaço para os tipos de variações de Política que algumas pessoas têm perguntado por, preservando as regras de consenso: as partes que realmente fazem do Bitcoin o que ele é. Também aliviaria a pressão sobre um conjunto sobrecarregado de pessoas tentando dar suporte à Tecnologia que sustenta um negócio em rápido crescimento. E, feito corretamente, pode introduzir alguns dos novos processos que participantes como Lerner estão pedindo.

A questão é: como o Bitcoin desenvolverá uma variedade tão grande de implementações alternativas de forma limpa, eficiente e sem nenhum drama associado?

Diversificar imagemvia Shutterstock