Cuando la mayoría de las personas descargan Bitcoin Core, su interacción con el sistema de construcción concluye en unos pocos clics. Obtienen el archivo ejecutable del software, verifican una firma (¡esperemos que sí!) y comienzan a ejecutar un nodo de Bitcoin. Lo que inmediatamente observan es software en funcionamiento. Sin embargo, lo que no ven es el sistema de construcción y los extensos procesos que hicieron posible ese software, un sistema que representa los principios de descentralización, transparencia y verificabilidad de Bitcoin.
Detrás de esa descarga hay años de trabajo de ingeniería destinado a responder a una pregunta sencilla: “¿Por qué debería alguien confiar en este software?” La respuesta es clara: no deberías tener que confiar. Deberías poder verificar.
En un momento en el que los ataques a la cadena de suministro de software acaparan los titulares, desde paquetes de npm comprometidos hasta bibliotecas con puertas traseras, el proceso de construcción de Bitcoin Core se erige como un tranquilo proyecto de disciplina. Sus métodos pueden parecer lentos y complicados en comparación con la conveniente inmediatez del “desplegar con un clic”, pero esa es precisamente la intención. La seguridad no es conveniente.
Para comprender el sistema de construcción de Bitcoin Core, es necesario conocer:
- La filosofía del Sistema de Construcción de Bitcoin Core
- Construcciones Reproducibles
- Minimización de Dependencias
- Sin Actualizaciones Automáticas
- Integración Continua
- Adaptación Continua
La filosofía del Sistema de Construcción de Bitcoin Core
Cuando se habla de descentralización en Bitcoin, la mayoría de la gente se enfoca en mineros, nodos y desarrolladores. Sin embargo, la descentralización no se limita a los participantes del protocolo; también se extiende a la manera en la que el software se construye y se distribuye.
Un principio fundamental en el ecosistema de Bitcoin es “no confíes, verifica”. Ejecutar tu propio nodo es un acto de verificación, comprobando cada bloque y transacción en función de las reglas de consenso. Pero el propio sistema de construcción te brinda otra oportunidad para verificar, a nivel de software. Bitcoin es dinero sin intermediarios de confianza y Bitcoin Core busca ser un software sin constructores de confianza. El sistema de construcción se esfuerza en asegurar que cualquier persona, en cualquier lugar, pueda recrear de manera 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 que parece limpio no puede ser confiable si el compilador que construyó ese software está comprometido. Los desarrolladores de Bitcoin tomaron esa lección en serio. Según palabras de Michael Ford (fanquake), colaborador de Bitcoin Core:
“Las construcciones 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 manera independiente.”
Una afirmación que es tanto un objetivo técnico como parte del ethos de Bitcoin.
En el ámbito de la seguridad, se habla de “superficies de ataque”. El sistema de construcción de Bitcoin Core considera el proceso de construcción como una superficie de ataque que debe ser minimizada y defendida.
Construcciones Reproducibles: Verificación en todos los niveles
El proceso de producción de una versión de Bitcoin Core comienza con la base de código de código abierto en GitHub. Cada cambio es público y cada solicitud de extracción es revisada. Pero el camino desde el código legible por humanos hasta el software ejecutable implica compiladores, bibliotecas de terceros y sistemas operativos que son, en sí mismos, vectores potenciales de manipulación, puertas traseras o errores.
“Los terceros de confianza son agujeros de seguridad” – Nick Szabo (2001)
Para abordar estas preocupaciones, Bitcoin Core diseñó un proceso de construcción utilizando Guix, un gestor de paquetes concebido para crear 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 utilizando Guix. Cada constructor opera 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 construcción es determinista.
Los colaboradores luego firman criptográficamente los binarios resultantes y publican esas firmas en un repositorio de GitHub separado, ‘guix.sigs’, que lista estas atestaciones para cada versión de Bitcoin Core. Algunos constructores son desarrolladores de Bitcoin Core, pero no es un requisito, dado que el proceso de atestación está abierto a cualquier persona del público. De hecho, muchos colaboradores que no codifican contribuyen regularmente con firmas.
Este proceso se conoce como construcciones reproducibles y es el antídoto al “trusting trust” de Thompson. Significa que cualquier persona puede tomar el código abierto, el mismo entorno de Guix y confirmar de manera independiente que el binario oficial coincide con lo que han construido ellos mismos. Aunque las construcciones reproducibles pueden verificar que el software es una representación genuina del código fuente, la correcta funcionalidad del software depende de procesos de pruebas exhaustivas y revisiones de código.
La mayoría de las personas nunca realizarán una compilación completa, revisarán los manifiestos de Guix o compararán hashes de construcción. No necesitan hacerlo. La existencia de esa infraestructura y las personas que la mantienen proporcionan a cada usuario una base de confianza bien ganada.
Los binarios oficiales en bitcoincore.org no son simplemente “producidos por los mantenedores de Bitcoin Core”. Son la intersección de los resultados de docenas de constructores independientes. Lo que finalmente descargas es lo que todos los demás construyeron y verificaron para ser auténtico.
Es verificación en todos los niveles.
Minimización de Dependencias: Menos confianza necesaria
La reproducibilidad es solo un lado de la ecuación. El otro consiste en minimizar lo que necesita ser reproducido. El código de Bitcoin Core no es el único código que se ejecuta al ejecutar Bitcoin Core. También confía en código y bibliotecas de terceros externos para acelerar el desarrollo y la productividad.
Durante la última década, los desarrolladores de Bitcoin Core han ido eliminando de manera constante estas dependencias externas y a veces problemáticas, como OpenSSL y MiniUPnP. Ya sea una biblioteca externa o un kit de herramientas, estas dependencias añaden complejidad o introducen suposiciones ocultas. Proyectos como Boost y Libevent, que alguna vez fueron elementos fundamentales del código de Core, están siendo gradualmente eliminados o reemplazados por alternativas más simples y autónomas.
¿Por qué? Porque cada dependencia que heredas es un riesgo potencial de cadena de suministro. Es más código que no has escrito, que no auditas y que no puedes controlar completamente. Reducir las dependencias hace que el sistema de construcción sea más ágil, seguro y fácil de verificar.
Brink destacó recientemente este esfuerzo en su“blog de Minimización de Dependencias”[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 menos que el proyecto debe confiar y una menos con potencial para puertas traseras.
El objetivo final es producir binarios estáticos completamente: ejecutables que contengan todo lo necesario para funcionar, sin dependencias dinámicas o de tiempo de ejecución. Esta autosuficiencia significa que no hay dependencia 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 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 de decisiones sobre si actualizar el software en absoluto. Instalás una aplicación y esta se actualiza silenciosamente y automáticamente a las versiones más recientes en segundo plano. Si bien esto es conveniente, es antitético a la filosofía de Bitcoin Core.
Bitcoin Core nunca ha incluido actualizaciones automáticas, y sus desarrolladores han asegurado que nunca lo hará. Las actualizaciones automáticas concentran el poder. Crean un único grupo que puede impulsar código (potencialmente malicioso) a cada nodo de la red. Este es exactamente el tipo de control centralizado que Bitcoin se propuso evitar. Al requerir que los usuarios descarguen, verifiquen e instalen manualmente nuevas versiones, Bitcoin Core refuerza la responsabilidad individual y el consentimiento verificable.
El sistema de construcción y la falta de actualizaciones automáticas son dos mitades de un mismo principio. Solo el operador del nodo decide qué ejecutar y puede verificar que el software que se ejecuta es auténtico.
Integración Continua: Avanza lento y corrige las cosas
En Silicon Valley, la integración continua y el despliegue continuo (CI/CD) son los sellos distintivos del desarrollo ágil de software. Envía rápido. Itera más rápido. Deja que la automatización haga el resto.
Bitcoin Core adopta un enfoque diferente. Sus sistemas de CI existen no para acelerar el despliegue, sino para salvaguardar la integridad. Las construcciones automatizadas prueban la consistencia a través de plataformas. El sistema de construcción de Bitcoin Core está diseñado para ser agnóstico respecto al hardware y los sistemas operativos tanto como sea posible. 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 asegura esta compatibilidad, así como la integridad del software, realizando cientos de pruebas para cada cambio propuesto.
El resultado es una cultura donde la “integración continua” significa pruebas, verificación y seguridad continuas, no innovación constante.
Avanza lento y corrige las cosas.
Adaptación Continua: ¿Ya hemos terminado?
El sistema de construcción no es estático. Los desarrolladores continúan refinándolo, reduciendo dependencias, mejorando las construcciones cruzadas de arquitectura y explorando un futuro de construcción completamente estático con cero dependencias de tiempo de ejecución.
Si bien el sistema de construcción de Bitcoin Core busca el determinismo, el propio sistema de construcción no puede ser estático. El mundo en el que opera está en constante cambio. Los sistemas operativos, compiladores, bibliotecas y arquitecturas de hardware evolucionan. Cada nueva versión de macOS o glibc, cada deprecación de un flag de compilador o nueva arquitectura de CPU introduce sutilezas incompatibles que deben ser abordadas. Un sistema de construcción que se mantuviera quieto, con el tiempo, dejaría de funcionar.
La paradoja de las construcciones reproducibles es que requieren una evolución continua para seguir siendo reproducibles. Los desarrolladores deben constantemente fijar, parchear y a veces reemplazar cadenas de herramientas para preservar el determinismo frente a un paisaje cambiante. Mantener este equilibrio entre estabilidad y adaptabilidad es parte de la resiliencia continua de Bitcoin.
No te pierdas la oportunidad de adquirir The Core Issue— con artículos escritos por muchos desarrolladores de Core, explicando los proyectos en los que trabajan.
Este artículo es la Carta del Editor presentada en la última edición impresa de Bitcoin Magazine, The Core Issue. Lo compartimos aquí como una mirada anticipada a las ideas exploradas a lo largo de la publicación completa.
[1] https://brink.dev/blog/2025/09/19/minimizing-dependencies/
Fuente: bitcoinmagazine.com