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 cuantos clics. Obtienen el binario ejecutable del software, verifican una firma (¡ojalá!), y comienzan a ejecutar un nodo de Bitcoin. Lo que ven de inmediato es software en funcionamiento. Lo que no ven es el sistema de compilación y los extensos procesos que produjeron ese software. Un sistema de compilación que representa los principios de Bitcoin de descentralización, transparencia y verificabilidad.

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

En una época en la que los ataques a la cadena de suministro de software acaparan titulares globales, desde paquetes npm comprometidos, hasta librerías con puertas traseras, servidores CI de mala fe, el proceso de compilación de Bitcoin Core se mantiene como un proyecto silencioso de disciplina. Sus métodos pueden parecer lentos y complicados en comparación con la comodidad sin fricción de “enviar para desplegar”, pero esa es la clave. La seguridad no es conveniente.

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

• Filosofía del sistema de compilación de Bitcoin Core
• Compilaciones reproducibles
• Minimizar dependencias
• No hay actualizaciones automáticas
• Integración continua
• Adaptación continua

Filosofía del sistema de compilación de Bitcoin Core

En lo que respecta a la descentralización de Bitcoin, la mayoría de la gente se centra en mineros, nodos y desarrolladores. Pero la descentralización no se detiene en los participantes del protocolo. Se extiende a la forma en que el propio software se construye y distribuye.

Un principio 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 contra las reglas de consenso. Pero el sistema de compilación en sí te brinda otra oportunidad para verificar, a nivel de software. Bitcoin es dinero sin intermediarios confiables y Bitcoin Core trabaja para ser software sin constructores confiables. El sistema de compilación se esfuerza enormemente para asegurar que cualquiera, en cualquier lugar, pueda recrear de forma independiente los binarios exactos que aparecen en el sitio bitcoincore.org.

Esta filosofía se remonta al ensayo de Ken Thompson de 1984 Reflections on Trusting Trust, que advirtió que incluso el código fuente que parece limpio no puede confiarse si el compilador que construyó ese software fue a su vez comprometido. Los desarrolladores de Bitcoin tomaron esa lección muy en serio. En palabras del contribuidor 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 poder verificarse de forma independiente siempre.”

Una declaración que es a la vez un objetivo técnico y 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 compilación en sí como una superficie de ataque que debe minimizarse y defenderse.

Compilaciones reproducibles: verificación hasta el fondo

El proceso de producir una versión de Bitcoin Core comienza con la base de código de código abierto en GitHub. Cada cambio es público. Cada solicitud de extracción (pull request) se revisa. Pero el recorrido desde el código legible por humanos hasta el binario ejecutable de software implica compiladores, librerías de terceros y sistemas operativos que, a su vez, son vectores potenciales para manipulación, puertas traseras o errores.

“Los terceros de confianza son agujeros de seguridad” – Nick Szabo (2001)

Para abordar estas preocupaciones, el arquitecto de Bitcoin Core diseñó un proceso de compilación en forma de pipeline usando Guix, un gestor de paquetes diseñado para crear entornos de software reproducibles y deterministas.

Cuando se etiqueta una nueva versión de Bitcoin Core, múltiples contribuyentes independientes compilan los binarios desde cero usando Guix. Cada compilador (builder) trabaja en un entorno aislado que garantiza toolchains idénticas, versiones del compilador y librerías del sistema. Si todos los compiladores producen salidas idénticas a nivel de bits, saben que la compilación es determinista.

Luego, los contribuyentes 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 compiladores son desarrolladores de Bitcoin Core, pero no es un requisito: el proceso de atestación está abierto a cualquiera del público. De hecho, muchos contribuyentes que no escriben código aportan firmas con regularidad.

Este proceso se conoce como compilaciones reproducibles, y es el antídoto contra el “confiar en la confianza” de Thompson. Significa que cualquiera puede tomar el código abierto, el mismo entorno de Guix, y confirmar de forma independiente que el binario oficial coincide con lo que ellos mismos compilaron. Si bien las compilaciones reproducibles pueden verificar que el software es una representación genuina del código fuente del software, la corrección del software se deja en manos de procesos alrededor de pruebas exhaustivas y revisión de código.

La mayoría de las personas nunca realizará una compilación completa o revisará los manifiestos de Guix o comparará hashes de compilación. No lo necesitan. La existencia de esa infraestructura y las personas que la mantienen le dan 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 compiladores independientes. Lo que finalmente descargas es lo que todos los demás construyeron y verificaron como auténtico.

Es verificación hasta el fondo.

Minimizar dependencias: menos cosas en las que confiar

La reproducibilidad es un lado de la ecuación. El otro es minimizar lo que necesita reproducirse. El código de Bitcoin Core no es el único código que se ejecuta al ejecutar Bitcoin Core. Bitcoin Core también se apoya en código externo de terceros y librerías para acelerar el desarrollo y la productividad.

En la última década, los desarrolladores de Bitcoin Core han ido eliminando de forma constante estas dependencias de terceros innecesarias y a veces problemáticas, como OpenSSL y MiniUPnP. Ya sea una librería o un conjunto de herramientas externo, estas dependencias añaden complejidad o importan suposiciones ocultas. Proyectos como Boost y Libevent, que antes eran elementos básicos del código base de Core, se van eliminando gradualmente o reemplazando por alternativas más simples y autocontenidas.

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

Brink resaltó recientemente este esfuerzo en su publicación de blog “Minimizing Dependencies”[1], señalando que no se trata solo de simplicidad: es cuestión de preservar la seguridad y la autonomía del proyecto. Cada dependencia eliminada es una parte externa menos a la que el proyecto debe confiar y una oportunidad potencial menos para una puerta trasera.

El objetivo final es producir binarios completamente estáticos: ejecutables que contienen todo lo que necesitan para funcionar, sin dependencias dinámicas ni en tiempo de ejecución. Esa autocontención significa que no hay dependencia de librerías externas que podrían diferir de un sistema operativo a otro.

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

No hay actualizaciones automáticas

En la mayoría del software moderno, los usuarios están protegidos de las decisiones sobre a qué versión de software actualizar o, incluso, si actualizar el software en absoluto. Instalas una aplicación y, de manera silenciosa y automática, se actualiza a las versiones más recientes en segundo plano. Aunque es conveniente, es contrario a la filosofía de Bitcoin Core.

Bitcoin Core nunca ha incluido actualizaciones automáticas, y los desarrolladores han dicho que nunca las incluirán. Las actualizaciones automáticas concentran poder. Crean un único grupo que puede enviar (posiblemente malicioso) código a cada nodo de la red. Esta es exactamente la clase de control centralizado que Bitcoin fue diseñado para evitar. Al exigir a los usuarios que descarguen, verifiquen e instalen manualmente 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 mitades del mismo principio. Solo quien ejecuta el nodo decide qué ejecutar y puede verificar que el software que se ejecuta es auténtico.

Integración continua: avanzar lento y arreglar las cosas

En Silicon Valley, la integración continua y la entrega continua (CI/CD) son el sello distintivo 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 agnóstico al hardware y a los sistemas operativos en la mayor medida posible. El proyecto puede compilar 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, al ejecutar 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.

Avanza lento y arregla las cosas.

Adaptación continua: ¿ya terminamos?

El sistema de compilación no es estático. Los desarrolladores continúan refinándolo al reducir dependencias, mejorar compilaciones entre arquitecturas y explorar un futuro de compilación completamente estática con cero dependencias en tiempo de ejecución.

Si bien el sistema de compilación de Bitcoin Core busca la determinación, el sistema de compilación en sí no puede ser estático. El mundo en el que opera está cambiando constantemente. Los sistemas operativos, los compiladores, las librerías y las arquitecturas de hardware cambian. Cada nueva versión de macOS o glibc, cada descontinuación de una bandera del compilador, o la aparición de una arquitectura de CPU introduce incompatibilidades sutiles que deben abordarse. Un sistema de compilación que se quedara inmóvil dejaría, con el tiempo, de poder compilar.

La paradoja de las compilaciones reproducibles es que requieren una evolución continua para seguir siendo reproducibles. Los desarrolladores deben fijar constantemente versiones, aplicar parches y, a veces, reemplazar toolchains para preservar la determinación frente al telón de fondo cambiante del cambio. Mantener este equilibrio entre estabilidad y adaptabilidad es parte de la resiliencia continua de Bitcoin.

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

No te pierdas tu oportunidad de ser dueño de The Core Issue — con artículos escritos por muchos Desarrolladores de Core que explican los proyectos en los que trabajan ellos mismos.

Este texto es la Carta del Editor destacada en la edición más reciente en papel de Bitcoin Magazine, The Core Issue. La compartimos aquí como una primera mirada a las ideas exploradas a lo largo del issue completo.

[1]