MestreInvestirInvestimentos & Ganhos · masterinvest.info

Código Aberto vs. Fonte Disponível: O que a Falha do Coldcard Ensina Sobre Incentivos de Software Bitcoin

20-08-2026, 23:49
Código Aberto vs. Fonte Disponível: O que a Falha do Coldcard Ensina Sobre Incentivos de Software Bitcoin

Bitcoin Magazine

Código Aberto vs. Código Disponível: O que a Falha do Coldcard Ensina Sobre os Incentivos do Software Bitcoin

Código Fechado versus Código Aberto tem dividido a indústria do Bitcoin e do cripto em geral por mais de uma década. Os defensores do Bitcoin há muito argumentam que a infraestrutura financeira do mundo deve ser construída em público. Transparência e auditabilidade, dizem eles, são inegociáveis quando dinheiro real está em jogo. No entanto, as camadas de aplicativos e de finanças legadas muitas vezes discordam.

No entanto, o recente hack do Coldcard, uma popular carteira de hardware de autocustódia onde os usuários perderam mais de $100 milhões em bitcoin (mais de 1.500 BTC), lançou dúvidas sobre o que “Código Aberto” realmente significa. Revelou que talvez a maioria das pessoas, mesmo muitos bitcoiners fervorosos, estejam mal informadas sobre a filosofia de desenvolvimento de software de Código Aberto e quando ela falha.

Os Princípios e a Terminologia

A linguagem em torno do Código Aberto pode ser complicada. Software Livre e de Código Aberto (FOSS) e Software Livre/Libre e de Código Aberto (FLOSS) referem-se a software que atende a definições formais de liberdade do usuário.

A Free Software Foundation (FSF) define software livre através de quatro liberdades essenciais:

A FSF enfatiza que “livre” se refere à liberdade, não ao preço, em uma citação comum ouvida de defensores do FOSS: “‘livre’ como em ‘liberdade de expressão’, não como em ‘cerveja grátis.’”

A Definição de Código Aberto da Open Source Initiative adiciona dez critérios práticos. Estes incluem redistribuição gratuita sem royalties, disponibilidade do código-fonte na forma preferida para modificação, o direito de criar e distribuir obras derivadas, e nenhuma discriminação contra pessoas, grupos ou áreas de atuação — incluindo uso comercial. Uma licença deve atender a todos os dez critérios para se qualificar como Código Aberto sob o padrão da OSI.

“Código disponível” ou “código visualizável” é diferente. O código pode ser legível publicamente enquanto a licença restringe o direito de vendê-lo. O firmware da Coldcard, por exemplo, é lançado sob os termos do MIT mais a Cláusula Commons. A Cláusula remove especificamente o direito de “Vender” o software — definido como fornecê-lo a terceiros por uma taxa ou outra consideração em um produto ou serviço cujo valor deriva total ou substancialmente do próprio software. Em outras palavras, o firmware da Coldcard não poderia ser usado comercialmente.

O próprio FAQ da Commons Clause afirma a diferença explicitamente: “Isso é ‘Código Aberto’? Não.” Ele observa que aplicar a cláusula significa que o software atende a muitos elementos da Definição de Código Aberto, mas não a todos eles, e, portanto, não deve ser chamado de Código Aberto.

Essas distinções importam. Publicar o código-fonte cria a possibilidade de inspeção. Conceder o conjunto completo de direitos definidos pela Definição de Software Livre ou pela Definição de Código Aberto é o que torna o software FOSS ou FLOSS. Mas ter o selo de aprovação, poder agitar uma bandeira FOSS ou FLOSS, não é o ponto. A liberdade comercial no FOSS desbloqueia incentivos de terceiros para testar e revisar o código que, de outra forma, poderia não existir, argumentam os críticos.

As quatro liberdades formam o núcleo filosófico do Código Aberto. Na prática, elas se baseiam em uma suposição econômica: que pessoas suficientemente motivadas realmente examinarão o código. Quando essa suposição falha, o sistema produz uma clássica tragédia dos bens comuns, uma situação em que um recurso compartilhado é superutilizado ou negligenciado porque os usuários individuais agem em seu próprio interesse de curto prazo, em vez do interesse de longo prazo do grupo.

Cada pessoa tem um incentivo para pegar mais (ou contribuir menos) do que é sustentável, e o recurso se degrada como resultado. Isso acontece quando há desalinhamento entre o interesse próprio de curto prazo do indivíduo e o interesse de longo prazo do grupo. Às vezes, o alinhamento existe; às vezes, não.

Um desenvolvedor de Bitcoin colocou o problema de forma direta: “Usar mocks e stubs de código Open Source em testes é irresponsável e míope. O código Open Source é considerado seguro porque qualquer um pode verificá-lo. Se você não está disposto a fazer o mínimo de testar as funcionalidades das quais realmente depende, então você está se comportando como um sanguessuga.”

Como resultado, o Open Source não cria segurança por si só. Ele cria a possibilidade de verificação. Se essa verificação ocorre ou não depende de incentivos, habilidades e atenção. A história do FOSS é considerada endurecer ao longo do tempo à medida que vulnerabilidades são descobertas, divulgadas e corrigidas, criando bases sólidas sobre as quais outros constroem. O núcleo do Linux é um ótimo exemplo de FOSS endurecido; ele alimenta a grande maioria dos servidores do mundo, infraestrutura de nuvem, dispositivos Android e sistemas embarcados, tornando-se um dos softwares mais amplamente implantados da história.

Open Source conforme demonstrado pelo Bitcoin Core

O Bitcoin Core, a implementação de referência do Bitcoin, é outro exemplo perspicaz de funcionamento puro de código aberto em grande escala na prática. O software, que opera na maioria da infraestrutura relacionada ao Bitcoin, é lançado sob a licença MIT. Seu processo de desenvolvimento é amplamente público por design.

Qualquer pessoa pode abrir um pull request. A revisão de código é o principal filtro e o ponto de entrada recomendado para novos colaboradores. Os revisores usam um vocabulário formal—Concept ACK (reconhecimento e concordância com o objetivo), Approach ACK (concordância com o objetivo e método), ACK com um hash de commit específico (testado e aprovado para mesclagem), ou NACK (discordância, que deve ser acompanhada de uma justificativa técnica).

Os mantenedores ponderam o consenso entre os colaboradores e os méritos técnicos de uma mudança antes de mesclar. Mudanças críticas para o consenso enfrentam um padrão ainda mais alto e geralmente requerem uma Proposta de Melhoria do Bitcoin e extensas discussões de vários anos na lista de discussão bitcoin-dev e no IRC.

Não existe uma casta privilegiada de “desenvolvedores do Bitcoin Core.” A confiança é conquistada através da competência demonstrada ao longo do tempo. Os mantenedores existem por razões práticas—auditar e mesclar código, gerenciar lançamentos e moderação básica—mas o trabalho produzido é código aberto puro que qualquer um pode inspecionar, construir, bifurcar ou executar. Desenvolvedores que têm ‘commits’ de código mesclados no Bitcoin Core são amplamente chamados de Contribuidores do Bitcoin Core.

Calle, um desenvolvedor de Bitcoin de código aberto de longa data, resumiu a realidade recentemente: “As pessoas que pensam que o core é algum tipo de instituição opaca operando nas sombras são ou muito preguiçosas ou muito burras para dar uma olhada por si mesmas. Literalmente tudo o que eles fazem é público, qualquer um pode participar, e o resultado do trabalho deles é código Open Source puro.”

O financiamento para este trabalho vem principalmente de estruturas sem fins lucrativos e de subsídios, como Brink, OpenSats, Spiral e outros, em vez de um roteiro de produto tradicional de empresa. Discussões e debates técnicos ocorrem publicamente na lista de e-mails bitcoin-dev e no canal IRC #bitcoin-core-dev no Libera Chat, onde propostas são analisadas antes e durante o processo de pull-request. Problemas e pull requests no GitHub frequentemente têm históricos de comentários que se estendem por uma década. O resultado é uma cultura de desenvolvimento otimizada para correção e auditabilidade, em vez de velocidade ou velocidade de recursos comerciais.

A Economia do Código Aberto

A maioria dos usuários de software de código aberto ou disponível nunca lê o código por conta própria. Eles confiam na suposição de que outros estão examinando-o. No caso do Coldcard, uma falha crítica de entropia permaneceu no firmware disponível publicamente por aproximadamente cinco anos antes de ser explorada e, assim, descoberta.

O bug entrou na base de código durante uma grande reescrita em 2021 que também removeu o código derivado da GPL restante do Trezor, a primeira carteira de hardware e agora a segunda maior na indústria de autocustódia. A biblioteca no centro da falha de entropia, que substituiu a trezor-crypto, é chamada libngu e teve uma supervisão externa mínima, com apenas 7 estrelas e menos de 20 forks em mais de 5 anos de uso em produção. Compare isso com as 512 estrelas da biblioteca trezor-crypto ao lado de 212 forks, ou os 793 forks e 1.8k estrelas do mais moderno trezor-firmware. A disponibilidade da fonte sozinha não produziu a revisão que importava, porque outras empresas com fins lucrativos e bem financiadas foram restritas de usá-la, ou assim argumentariam os críticos.

Os riscos são maiores no Bitcoin do que na maioria dos domínios de software. Uma falha crítica pode ser convertida diretamente em fundos líquidos no mercado aberto. Enquanto a primeira metade dos fundos do Coldcard roubados ainda está mantida em um punhado de endereços e o hacker pode um dia ser capturado, hackers imitadores que se seguiram foram mais cuidadosos, e alguns roubaram mais bitcoin e o lavaram com sucesso, segundo a Galaxy Research. A resistência à censura do Bitcoin e a transacionabilidade imutável criam tanto um poderoso incentivo para atacantes quanto um filtro darwiniano; apenas projetos que atraem continuamente revisões competentes, e usuários e empresas que tomam precauções sérias, tendem a sobreviver a longo prazo.

As escolhas de licenciamento moldam esses incentivos de acordo com os defensores do FOSS que criticaram as decisões de licenciamento da Coinkite por anos. Licenças puramente de código aberto maximizam o pool de revisores e forks potenciais. Licenças restritas de "código disponível" podem reduzir a exploração comercial, mas também diminuem o círculo de pessoas com o direito legal e o motivo econômico para investir atenção profunda. Infelizmente, o ônus da revisão de código recai sobre a empresa sob uma licença restritiva, colocando-a, de certa forma, mais próxima do código fechado do que do aberto.

Como a IA Muda o Desenvolvimento de Código Aberto e Fechado

A inteligência artificial agora também está alterando o equilíbrio entre FOSS e código fechado.

Após o incidente do Coldcard, um esforço voluntário conhecido como Bitcoin Red Team—liderado por desenvolvedores incluindo Calle e Rob Hamilton da AnchorWatch, e apoiado pela OpenSats—usou modelos de IA de ponta para escanear centenas de repositórios de Bitcoin de código aberto. Em um período intenso, a equipe registrou milhares de descobertas, incluindo dezenas classificadas como críticas ou de alta severidade, em centenas de projetos. Divulgações responsáveis foram feitas aos mantenedores antes da publicação mais ampla. O exercício demonstrou que a revisão assistida por IA sistemática pode revelar problemas em uma escala e velocidade anteriormente impraticáveis para equipes puramente humanas.

Nesse aspecto, vale a pena notar que a Equipe Vermelha encontrou modelos chineses de peso aberto muito mais confiáveis do que modelos americanos de código fechado, que, mesmo com permissões cibernéticas e acesso de alto nível, se recusaram a responder às perguntas da Equipe Vermelha, uma tendência que os desenvolvedores americanos lamentam.

Ao mesmo tempo, a inundação de código gerado por IA criou uma nova pressão de negação de serviço sobre os mantenedores de FOSS. Revisar a saída da IA muitas vezes leva mais tempo do que gerá-la. Alguns projetos de código aberto fora do Bitcoin restringiram rastreadores de problemas ou impuseram regras rígidas contra contribuições de IA simplesmente para se manterem funcionais.

Fonte: BitcoinMagazine