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 un par de clics. Obtienen el binario ejecutable del software, verifican una firma (¡ojalá!) y empiezan 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 procesos extensos 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 copan titulares a nivel mundial, desde paquetes npm comprometidos hasta bibliotecas con puertas traseras, pasando por servidores CI corruptos, 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 conveniente fricción-cero de “enviar para desplegar”, pero ahí está el punto. La seguridad no es conveniente.

Para entender el sistema de compilación de Bitcoin Core, deberíamos entender:

• Filosofía del sistema de compilación de Bitcoin Core
• Compilaciones reproducibles
• Minimizar 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 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 se distribuye.

Uno de los principios del ecosistema de Bitcoin es “no confíes, verifica”. Ejecutar tu propio nodo es un acto de verificación: comprobar cada bloque y transacción contra las reglas de consenso. Pero el propio sistema de compilación te ofrece otra oportunidad de verificar, a nivel de software. Bitcoin es dinero sin intermediarios de confianza y Bitcoin Core trabaja para ser software sin constructores de confianza. El sistema de compilación lleva a cabo grandes esfuerzos para garantizar que cualquiera, en cualquier lugar, pueda recrear de forma independiente exactamente los mismos binarios que aparecen en el sitio bitcoincore.org.

Esta filosofía se remonta al ensayo de 1984 de Ken Thompson Reflections on Trusting Trust, que advirtió que incluso un código fuente con buena apariencia no puede confiarse si el compilador que construyó ese software estaba comprometido. Los desarrolladores de Bitcoin tomaron esa lección en serio. En palabras de Michael Ford, colaborador de Bitcoin Core (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 siempre debe ser verificable de forma independiente.”

Una afirmació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 propio proceso de compilación 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 se revisa. Pero el camino desde el código legible por humanos hasta el binario software ejecutable implica compiladores, bibliotecas de terceros y sistemas operativos que, por sí mismos, son vectores potenciales de 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 pipeline de proceso de compilación 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 contribuidores independientes construyen los binarios desde cero usando Guix. Cada compilador trabaja en un entorno aislado que garantiza toolchains idénticas, versiones del compilador y bibliotecas del sistema. Si todos los compiladores producen salidas idénticas en bits, saben que la compilación es determinista.

Luego, los contribuidores firman criptográficamente los binarios resultantes y publican esas firmas en un repositorio separado de GitHub, ‘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 contribuidores que no aportan código contribuyen con firmas con regularidad.

Este proceso se conoce como compilaciones reproducibles, y es el antídoto contra el “confingir la confianza” de Thompson. Significa que cualquiera puede tomar el código de código abierto, el mismo entorno Guix, y confirmar de forma independiente que el binario oficial coincide con lo que ellos mismos construyeron. 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 a procesos alrededor de pruebas exhaustivas y revisión de código.

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

Es verificación hasta el fondo.

Minimizar dependencias: Menos por 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 depende de código y bibliotecas externas de terceros para acelerar el desarrollo y la productividad.

Durante la última década, los desarrolladores de Bitcoin Core han ido eliminando de forma constante estas dependencias innecesarias y a veces problemáticas de terceros, como OpenSSL y MiniUPnP. Ya sea una biblioteca externa o un conjunto de herramientas, estas dependencias añaden complejidad o introducen supuestos ocultos. Proyectos como Boost y Libevent, que antes eran habituales en la base de código de Core, se están 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: también 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 menos para una puerta trasera.

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

En un mundo donde la mayoría del software crece más pesado y depende más de ecosistemas centralizados de paquetes, Bitcoin Core se mueve 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 frente a las decisiones sobre a qué versión de software actualizar, o incluso sobre si actualizar el software. Instalas una aplicación y se actualiza silenciosa y automáticamente a las versiones más recientes en segundo plano. Aunque esto 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 lo hará. Las actualizaciones automáticas concentran poder. Crean un único grupo que puede enviar (potencialmente malicioso) código a cada nodo en la red. Eso es exactamente el tipo de control centralizado que Bitcoin fue diseñado para evitar. Al exigir 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 falta 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: Avanza lento y arregla las cosas

En Silicon Valley, la integración continua y el despliegue continuo (CI/CD) son la marca distintiva del desarrollo ágil de software. Lanza rápido. Itera más rápido. Deja que la automatización se encargue del 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 ajeno 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 garantiza 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 las compilaciones entre arquitecturas y explorar un futuro de compilación totalmente estática con cero dependencias de tiempo de ejecución.

Si bien el sistema de compilación de Bitcoin Core busca la determinación, el propio sistema de compilación no puede ser estático. El mundo en el que opera cambia constantemente. Los sistemas operativos, los compiladores, las bibliotecas y las arquitecturas de hardware cambian. Cada nueva versión de macOS o glibc, cada desuso 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 permaneciera inmóvil dejaría de compilar con el tiempo.

La paradoja de las compilaciones reproducibles es que requieren una evolución continua para mantenerse reproducibles. Los desarrolladores deben fijar constantemente versiones, aplicar parches y, a veces, reemplazar toolchains para preservar la determinación frente a un panorama cambiante. 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 pierdas tu oportunidad de ser dueño de The Core Issue — ¡con artículos escritos por muchos Desarrolladores Core que explican los proyectos en los que trabajan ellos mismos!

Este texto es la Carta del Editor que aparece en la edición Print más reciente de Bitcoin Magazine, The Core Issue. La compartimos aquí como una primera mirada a las ideas que se exploran a lo largo de todo el número.

[1]