El problema principal: Más allá del binario, verificando la confianza

Cuando la mayoría de las personas descargan Bitcoin Core, su interacción con el sistema de compilación termina en unos pocos clics. Obtienen el binario ejecutable del software, verifican una firma (¡esperemos que sí!), y comienzan a ejecutar un nodo de Bitcoin. Lo que ven de inmediato es un software en funcionamiento. Lo que no ven es el sistema de compilación y los procesos extensos que produjeron ese software. Un sistema de compilación que representa los principios de descentralización, transparencia y verificabilidad de Bitcoin.

Detrás de esa descarga se esconden años de trabajo de ingeniería diseñados para responder a una pregunta sencilla: “¿Por qué alguien debería confiar en este software?” La respuesta es: no debería ser necesario. Deberías poder verificarlo.

En una época en la que los ataques a la cadena de suministro de software acaparan titulares mundiales, desde paquetes npm comprometidos, bibliotecas con puertas traseras, servidores CI piratas, el proceso de compilación de Bitcoin Core se presenta como un proyecto silencioso de disciplina. Sus métodos pueden parecer lentos y complicados en comparación con la conveniencia sin fricciones del “push to deploy”, pero ese es el punto. La seguridad no es conveniente.

Para entender el sistema de compilación de Bitcoin Core, debemos comprender:

• Filosofía del Sistema de Compilación de Bitcoin Core

• Compilaciones Reproducibles

• Minimización de Dependencias

• Sin Actualizaciones Automáticas

• Integración Continua

• Adaptación Continua

Filosofía del Sistema de Compilación de Bitcoin Core

Cuando se trata de la descentralización de Bitcoin, la mayoría de las personas se concentran en los mineros, nodos y desarrolladores. Pero la descentralización no se detiene en los participantes del protocolo. Se extiende a la forma en que el software mismo se construye y distribuye.

Un principio en el ecosistema de Bitcoin es “no confiar, verificar”. Ejecutar tu propio nodo es un acto de verificación, comprobando cada bloque y transacción contra las reglas de consenso. Pero el sistema de compilación en sí mismo te da otra oportunidad para verificar, a nivel de software. Bitcoin es dinero sin intermediarios de confianza y Bitcoin Core trabaja para ser un software sin constructores de confianza. El sistema de compilación hace grandes esfuerzos para garantizar que cualquiera, en cualquier lugar, pueda recrear de forma independiente los mismos binarios que aparecen en el sitio web bitcoincore.org.

Esta filosofía se remonta al ensayo de Ken Thompson de 1984, Reflections on Trusting Trust, que advertía que incluso un código fuente con buena apariencia no puede ser confiable si el compilador que construyó ese software fue comprometido. Los desarrolladores de Bitcoin tomaron esa lección muy en serio. En palabras del colaborador de Bitcoin Core, Michael Ford (fanquake):

“Las compilaciones reproducibles son críticas, porque ningún usuario de nuestro software debería tener que confiar en que lo que contiene es lo que decimos que es. Esto debe ser siempre verificable de forma independiente.”

Una declaración que es tanto un objetivo técnico como parte del ethos de Bitcoin.

En el mundo de la seguridad, la gente habla de “superficies de ataque”. El sistema de compilación de Bitcoin Core trata el proceso de construcción en sí mismo como una superficie de ataque que debe minimizarse y protegerse.

Compilaciones Reproducibles: Verificación en todos los niveles

El proceso para producir una versión de Bitcoin Core comienza con el código abierto en GitHub. Cada cambio es público. Cada solicitud de extracción es revisada. Pero el camino desde el código legible por humanos hasta el software binario ejecutable implica compiladores, bibliotecas de terceros y sistemas operativos que son en sí mismos posibles vectores de manipulación, puertas traseras o errores.

“Las terceras partes de confianza son agujeros de seguridad” – Nick Szabo (2001)

Para abordar estas preocupaciones, Bitcoin Core diseñó un proceso de compilación usando Guix, un gestor de paquetes creado para generar entornos de software reproducibles y deterministas.

Cuando se etiqueta una nueva versión de Bitcoin Core, múltiples colaboradores independientes construyen los binarios desde cero usando Guix. Cada constructor trabaja en un entorno aislado que garantiza cadenas de herramientas, versiones de compiladores y bibliotecas del sistema idénticas. Si todos los constructores producen salidas idénticas, saben que la compilación es determinista.

Luego, los colaboradores firman criptográficamente los binarios resultantes y publican esas firmas en un repositorio separado de GitHub, ‘guix.sigs’, que lista estas attestaciones para cada versión de Bitcoin Core. Algunos constructores son desarrolladores de Bitcoin Core, pero no es un requisito, ya que el proceso de attestación está abierto a cualquier persona del público. De hecho, muchos contribuyentes no relacionados con el código contribuyen regularmente con firmas.

Este proceso se conoce como compilaciones reproducibles, y es la antidote a la “confianza en la confianza” de Thompson. Significa que cualquiera puede tomar el código abierto, el mismo entorno Guix, y confirmar de forma independiente que el binario oficial coincide con lo que ellos mismos construyeron. Aunque las compilaciones reproducibles verifican que el software es una representación genuina del código fuente, la corrección del software queda en manos de procesos de pruebas exhaustivas y revisión de código.

La mayoría de las personas nunca realizarán una compilación completa ni verificarán los manifiestos de Guix o compararán hashes de construcción. No lo necesitan. La existencia de esa infraestructura, y las personas que la mantienen, brindan a cada usuario una base de confianza ganada.

Los binarios oficiales en bitcoincore.org no son solo “producidos por los mantenedores de Bitcoin Core”. Son la intersección de las salidas de docenas de constructores independientes. Lo que finalmente descargues es lo que todos los demás construyeron y verificaron como auténtico.

Es verificación en todos los niveles.

Minimización de Dependencias: Menos en qué confiar

La reproducibilidad es una cara de la moneda. La otra es minimizar lo que necesita ser reproducido. El código de Bitcoin Core no es el único código que se ejecuta al correr Bitcoin Core. Bitcoin Core también depende de código y bibliotecas externas de terceros para acelerar el desarrollo y la productividad.

En la última década, los desarrolladores de Bitcoin Core han ido eliminando gradualmente estas dependencias externas innecesarias y a veces problemáticas, como OpenSSL y MiniUPnP. Ya sea una biblioteca externa o una herramienta, estas dependencias añaden complejidad o suponen supuestos ocultos. Proyectos como Boost y Libevent, que alguna vez fueron fundamentales en el código de Core, están siendo eliminados o reemplazados por alternativas más simples y autocontenidas.

¿Pero por qué? Porque cada dependencia que heredas es un riesgo potencial en la cadena de suministro. Es más código que no escribiste, no auditas y no puedes controlar completamente. Reducir dependencias hace que el sistema de compilación sea más liviano, más seguro y más fácil de verificar.

Brink destacó recientemente este esfuerzo en su publicación de blog “Minimizing Dependencies”[1], señalando que no se trata solo de simplicidad, sino de preservar la seguridad y autonomía del proyecto. Cada dependencia eliminada es una parte externa en la que el proyecto debe confiar menos y una menor posibilidad de puertas traseras.

El objetivo final es producir binarios completamente estáticos: ejecutables que contienen todo lo necesario para funcionar, sin dependencias dinámicas o en tiempo de ejecución. Esta autosuficiencia significa que no dependen de bibliotecas externas que podrían variar de un sistema operativo a otro.

En un mundo donde la mayoría del software se vuelve más pesado y más dependiente de ecosistemas de paquetes centralizados, Bitcoin Core avanza en la dirección opuesta: hacia el minimalismo y la independencia.

Sin Actualizaciones Automáticas

En la mayoría del software moderno, los usuarios están protegidos de decisiones sobre qué versión de software actualizar o si deben actualizar en absoluto. Instalas una app y esta se actualiza automáticamente en segundo plano a la última versión. Aunque esto es conveniente, va en contra de la filosofía de Bitcoin Core.

Bitcoin Core nunca ha incluido actualizaciones automáticas, y los desarrolladores han dicho que nunca lo harán. Las actualizaciones automáticas concentran poder. Crean un grupo único que puede enviar (potencialmente malicioso) código a cada nodo en la red. Esto es exactamente lo que Bitcoin fue diseñado para evitar. Requiriendo que los usuarios descarguen, verifiquen e instalen manualmente las nuevas versiones, Bitcoin Core refuerza la responsabilidad individual y el consentimiento verificable.

El sistema de compilación y la ausencia de actualizaciones automáticas son dos caras de la misma moneda. Solo el operador del nodo decide qué ejecutar y puede verificar que el software que se ejecuta es auténtico.

Integración Continua: Ir despacio y arreglar cosas

En Silicon Valley, la integración continua y el despliegue continuo (CI/CD) son los sellos distintivos del desarrollo ágil de software. Enviar rápido. Iterar más rápido. Dejar que la automatización haga el resto.

Bitcoin Core adopta un enfoque diferente. Sus sistemas de CI no existen para acelerar el despliegue, sino para salvaguardar la integridad. Las compilaciones automatizadas prueban la consistencia entre plataformas. El sistema de compilación de Bitcoin Core está diseñado para ser lo más agnóstico posible respecto al hardware y los sistemas operativos. El proyecto puede construir binarios para Linux, macOS y Windows, así como para múltiples arquitecturas, incluyendo x86_64, aarch64 (ARM) e incluso riscv64. El sistema de integración continua garantiza esta compatibilidad, además de la integridad del software, realizando cientos de pruebas para cada cambio propuesto.

El resultado es una cultura donde “integración continua” significa pruebas continuas, verificación y seguridad, no innovación continua.

Ir despacio y arreglar cosas.

Adaptación Continua: ¿Hemos terminado ya?

El sistema de compilación no es estático. Los desarrolladores siguen perfeccionándolo, reduciendo dependencias, mejorando las compilaciones entre arquitecturas y explorando un futuro de compilación completamente estática con cero dependencias en tiempo de ejecución.

Aunque el sistema de compilación de Bitcoin Core busca el determinismo, no puede ser estático. El entorno en el que opera está en constante cambio. Los sistemas operativos, compiladores, bibliotecas y arquitecturas de hardware cambian continuamente. Cada nueva versión de macOS o glibc, cada depreciación de una bandera de compilador, o la aparición de una nueva arquitectura de CPU, introduce incompatibilidades sutiles que deben abordarse. Un sistema de compilación que permaneciera inmóvil dejaría de compilar con el tiempo.

La paradoja de las compilaciones reproducibles es que requieren una evolución continua para seguir siendo reproducibles. Los desarrolladores deben ajustar, parchear y a veces reemplazar cadenas de herramientas para mantener el determinismo en un entorno cambiante. Mantener ese equilibrio entre estabilidad y adaptabilidad es parte de la resiliencia continua de Bitcoin.

¡Obtén hoy tu copia de The Core Issue!

No pierdas la oportunidad de poseer The Core Issue — con artículos escritos por muchos desarrolladores principales explicando los proyectos en los que trabajan.

Este artículo es la Carta del Editor que aparece en la última edición impresa de Bitcoin Magazine, The Core Issue. Lo compartimos aquí como una vista previa de las ideas exploradas en toda la edición.

[1]