Rever código é entorpecente: perguntas e respostas com o mantenedor do Bitcoin , Andrew Chow

Poucas pessoas entendem os principais problemas técnicos que a Criptomoeda dominante do mundo enfrenta atualmente. Andrew Chow é um deles.

Chow é um dos quatro “mantenedores” de Bitcoin CORE (ou apenas CORE), o software mais popular para conexão à rede Bitcoin .

Os mantenedores revisam as mudanças no Bitcoin CORE conhecidas como “commits”, que são enviadas – por colegas desenvolvedores do Bitcoin – como “pull requests” ou “PRs”. Chow e outros mantenedores então aprovam ou “mesclam” essas mudanças no código-fonte do Core. A “revisão de código” é crítica para garantir que nenhum código com bugs seja mesclado.

O processo é transparente e, à medida que Chow analisa os commits, eletransmite o processo ao vivo no Twitch.

Chow é um gamer de coração, e só entrou no Bitcoin no ensino médio para pagar por videogames que ele T poderia pagar de outra forma. Seus pais T lhe deram um cartão de crédito, abriram uma conta bancária para ele ou mesmo lhe deram uma mesada. Ele recorreu ao trabalho freelancer Fórum BitcoinTalk e começou a escrever código em troca de Bitcoin (BTC).

Chow, que diz estar agora na faixa dos 20 anos, é pago como engenheiro na empresa de infraestrutura de Bitcoin Blockstream, onde, além de algumas tarefas corporativas, sua principal prioridade é trabalhar no Bitcoin CORE.

Ele diz que a revisão de código é um dos maiores desafios que o Bitcoin enfrenta hoje. A maioria dos desenvolvedores do CORE está interessada em escrever código para novos recursos, mas poucos gostam da tarefa mais mundana de revisar o código enviado por seus colegas. Chow diz que mais Colaboradores precisam se concentrar na revisão de código para lidar com os mais de 300 PRs no Core Repositório GitHub. A comunidade tem umaClube de revisão de RP do Bitcoin CORE que se reúne semanalmente para ajudar novos Colaboradores a Aprenda sobre o processo de revisão.

Chow concordou em dar uma entrevista ao CoinDesk no Avanço do Bitcoin conferência em Londres. Ele elaborou sobre o porquê da revisão de código ser tão crítica, explicou o que os Colaboradores do Bitcoin CORE fazem todos os dias e opinou sobre o debate atual sobre op_vault e teste rápido. Aqui está uma transcrição parcial dessa entrevista.

CoinDesk: Como você descobriu o Bitcoin?

Andrew Chow: Quando eu era mais jovem, no ensino médio, eu T tinha uma conta bancária porque eu tinha menos de 18 anos. Meus pais T abriram uma para mim. Eu T tinha um cartão de crédito – nem mesmo um cartão de crédito supervisionado – e eu T tinha uma mesada. Mas Vapor estava vendendo jogos por Bitcoin. Se você joga em PC, você pode baixar o Steam e ele tem basicamente todos os jogos de PC.

Também, embolsa.io, você poderia vender Bitcoin por coisas. Bem, eu queria jogar. Eu queria comprá-los. Quer dizer, eu estou bem com pirataria, mas, você sabe, piratear coisas é meio duvidoso. Você T sabe o que está baixando. Pode ser um malware completo.

Então eu pensei, tipo, essa coisa do Bitcoin é totalmente eletrônica. Talvez eu possa usar isso para comprar jogos – mas como eu consigo Bitcoin? Talvez eu possa fazer algum trabalho e ser pago em Bitcoin.

Conheço algumas pessoas que fizeram isso. Foi assim que aprendi a programar. Eu ia ao BitcoinTalk e as pessoas diziam: "Eu pago a você o quanto for para me escrever um script que faça isso."

Bem, isso parecia bastante simples. Eu também tinha um amigo no ensino médio. Ele estava tipo, "Ei, você já ouviu falar dessa coisa do Bitcoin ? Acho que você pode gostar." Ele definitivamente estava comprando drogas com Bitcoin.

Então foi assim que entrei no Bitcoin. E eventualmente eu fiquei tipo, "Bem, estou usando esta carteira e estou tendo estes problemas. Eu claramente sei como escrever um programa. Talvez eu possa consertar esta carteira." Foi assim que comecei a fazer desenvolvimento.

Eu estava executando essa coisa chamadaArsenal. Que basicamente não era mantido. Quer dizer, ainda é meio que mantido por um cara, então mal.

Na época em que eu estava usando, era meio bagunçado e T sempre funcionava. Eu estava descobrindo que alguns dos problemas que estavam acontecendo no Armory eram causados ​​por coisas que o Bitcoin CORE estava fazendo. Então eu comecei a entrar no Bitcoin CORE e perguntar o que o Bitcoin CORE estava fazendo? Ah, o Bitcoin CORE tem esse bug que está nos causando um bug.

A Armory estava fazendo algo não recomendado, que era ler os arquivos de bloco diretamente do Bitcoin CORE – você não deveria fazer isso. Quando eles mudaram o formato, quebrou tudo.

Eu estava tentando conciliar os dois, e então Armory simplesmente sumiu do meu mapa. Foi assim que eu fiz a transição para o Bitcoin CORE. Acabei parando de trabalhar no Armory porque consegui fazer mais no CORE.

Ontem falamos sobre a proporção de Colaboradores de Bitcoin que revisam código versus Colaboradores que escrevem código. Você pode compartilhar suas ideias sobre isso?

Nosso principal gargalo no Bitcoin CORE tem sido a revisão. Temos mais de 300 RPabertos e precisam ser revisados. Seja apenas para garantir que o código seja bom ou apenas conceitualmente, como, "Nós realmente queremos essa mudança?"

O problema com cada RP é que uma pessoa geralmente o escreve, mas precisamos de várias pessoas para revisá-lo, dar uma aprovação ou deixar comentários. Portanto, precisamos ter mais revisores do que pessoas escrevendo, mas não é assim que funciona.

Pessoalmente, acho a revisão de código um BIT chata. É um pouco irritante e pode ser meio entorpecente. Mas ainda assim faço isso. Acho que é como um mal necessário e é porque T acho divertido. Se eu fizer isso o suficiente, começo a sentir que vou me esgotar porque não é mais agradável.

Então você tem que encontrar algum equilíbrio entre escrever código e revisar código. É um BIT de catch-22. Temos que ter mais revisores do que codificadores, mas como você se torna competente o suficiente para revisar código se não está escrevendo código? É um enigma.

Estamos em um mercado de baixa e organizações como a Brink que financiam o desenvolvimento do Bitcoin estão dizendo que o financiamento caiu em cerca de 50%. Por que precisamos pagar Colaboradores e desenvolvedores do Bitcoin ?

Fundamentalmente, todo pedaço de software tem bugs. Sempre haverá bugs para encontrar e bugs para consertar. Isso é apenas manutenção geral de software que deve acontecer.

E mesmo assim, o software que existe agora não pode durar para sempre. Os sistemas operacionais irão evoluir e as bibliotecas irão evoluir e mudar. Eventualmente, o software irá simplesmente parar de compilar em um computador; ele pode simplesmente parar de rodar. E então, precisa haver trabalho constante apenas para KEEP -lo atualizado.

Então sempre há coisas para atualizar, mesmo sem novos recursos. Mas há novos recursos e queremos melhorar o Bitcoin. Não apenas as regras de consenso, mas também como retransmitimos transações, que tipo de transações aceitamos no pool de memóriase o protocolo ponto a ponto.

Pode haverDoS vetores que queremos consertar ou mudar que talvez ainda T tenham sido descobertos. Sempre tem alguma coisa.

Se eu for um novo colaborador do CORE , quais são alguns dos grandes problemas que preciso saber?

Atualmente, existem vários problemas, comoataques de fixação, que são muito bem documentados. Parece que ONE os explora, mas isso não é um bom motivo para não consertá-los.

Houve muito trabalho no mempool – como e quais transações são aceitas no mempool, quais métodos existem paraaumento de taxa, e coisas assim. É relevante paraRaioe outras redes [camada 2].

O que é um “ataque de fixação”?

Se nós dois abrirmos um canal Lightning juntos, posso fazer com que você nunca aumente a taxa dessa transação. Então posso fazer com que ela tenha uma taxa perpetuamente baixa e nunca seja minerada, e depois tentar gastá-la duas vezes mais tarde.

Há um monte de ataques que você pode fazer com as regras de Política de mempool existentes. Eles estão documentados na lista de discussão e são definitivamente problemas. Se alguém tentasse explorá-los, seria irritante, mas acho que T vimos ninguém tentar explorá-los.

Ainda queremos consertá-los e houve muito trabalho para fazer melhorias para que T tenhamos esses ataques de fixação, ou pelo menos, se você quiser fixar uma transação, será muito caro.

Também discutimos o op_vault e o Speed Trial ontem. Houve algumas tensões em torno da recomendação de James O’Beirne de implantar o op_vault usando o Speedy Trial. Algum comentário?

Com uma nova proposta como essa, a implantação deveria ser a última coisa a se pensar.

Algumas ideias sobre como implementar coisas são, por algum motivo, controversas. Se você quer ter uma discussão sobre a proposta, ter implementação ali meio que faz com que ela saia dos trilhos.

Então eu acho que James colocar isso aí provavelmente foi um erro.Raiz principal a seção de implantação T foi definida até depois do Taproot. As próprias alterações de código foram mescladas no Bitcoin CORE , mas não ativas. Não é incomum dizer que lidaremos com a implantação depois de descobrirmos o que queremos que as alterações de código sejam.

O Speedy Trial foi um experimento para o Taproot. Tentamos diferentes métodos de implantação ao longo dos anos com vários graus de sucesso.