Revista Bitcoin
Código Abierto vs. Código Disponible: Lo que el Fallo de Coldcard Enseña Sobre los Incentivos del Software de Bitcoin
El código cerrado versus el código abierto ha dividido a la industria de Bitcoin y a la criptografía en general durante más de una década. Los defensores de Bitcoin han argumentado durante mucho tiempo que la infraestructura financiera del mundo debería construirse en público. La transparencia y la auditabilidad, dicen, son innegociables cuando hay dinero real en juego. Sin embargo, las capas de aplicaciones y de legado de las finanzas a menudo no están de acuerdo.
Sin embargo, el reciente hackeo de Coldcard, una popular billetera de hardware de autocustodia donde los usuarios perdieron más de $100 millones en bitcoin (más de 1,500 BTC), generó dudas sobre lo que realmente significa "Código Abierto". Reveló que quizás la mayoría de las personas, incluso muchos bitcoiners acérrimos, están mal informados sobre la filosofía de desarrollo de software de Código Abierto y cuándo falla.
Los Principios y la Terminología
El lenguaje en torno al Código Abierto puede ser complicado. El Software Libre y de Código Abierto (FOSS) y el Software Libre/Libre y de Código Abierto (FLOSS) se refieren a software que cumple con definiciones formales de libertad del usuario.
La Free Software Foundation (FSF) define el software libre a través de cuatro libertades esenciales:
- Libertad 0: La libertad de ejecutar el programa como desees, para cualquier propósito.
- Libertad 1: La libertad de estudiar cómo funciona el programa y cambiarlo para que realice tus cálculos como desees (el acceso al código fuente es una condición previa para esto).
- Libertad 2: La libertad de redistribuir copias para que puedas ayudar a otros.
- Libertad 3: La libertad de distribuir copias de tus versiones modificadas a otros (el acceso al código fuente es una condición previa para esto).
La FSF enfatiza que “libre” se refiere a la libertad, no al precio, en una cita comúnmente escuchada de los defensores del FOSS: “‘libre’ como en ‘libertad de expresión’, no como en ‘cerveza gratis.’”
La Definición de Código Abierto de la Iniciativa de Código Abierto añade diez criterios prácticos. Estos incluyen redistribución gratuita sin regalías, disponibilidad del código fuente en la forma preferida para modificación, el derecho a crear y distribuir obras derivadas, y ninguna discriminación contra personas, grupos o campos de esfuerzo — incluyendo el uso comercial. Una licencia debe cumplir con los diez criterios para calificar como Código Abierto bajo el estándar de la OSI.
“Código disponible” o “código visible” es diferente. El código puede ser legible públicamente mientras que la licencia restringe el derecho a venderlo. El firmware de Coldcard, por ejemplo, se publica bajo términos de MIT más la Cláusula de Commons. La Cláusula elimina específicamente el derecho a “Vender” el software — definido como proporcionarlo a terceros a cambio de una tarifa u otra consideración en un producto o servicio cuyo valor deriva total o sustancialmente del software mismo. En otras palabras, el firmware de Coldcard no podría ser utilizado comercialmente.
La propia FAQ de la Cláusula de los Comunes establece la diferencia de manera explícita: “¿Es esto ‘Código Abierto’? No.” Señala que aplicar la cláusula significa que el software cumple con muchos elementos de la Definición de Código Abierto, pero no con todos, y por lo tanto no debería ser llamado Código Abierto.
Estas distinciones importan. Publicar el código fuente crea la posibilidad de inspección. Conceder el conjunto completo de derechos definidos por la Definición de Software Libre o la Definición de Código Abierto es lo que hace que el software sea FOSS o FLOSS. Pero tener la insignia de aprobación, poder agitar una bandera FOSS o FLOSS, no es el objetivo. La libertad comercial en FOSS desbloquea incentivos de terceros para probar y revisar el código que de otro modo podría no estar presente, argumentan los críticos.
Las cuatro libertades forman el núcleo filosófico del Código Abierto. En la práctica, descansan sobre una suposición económica: que suficientes personas motivadas examinarán realmente el código. Cuando esa suposición falla, el sistema produce una tragedia clásica de los comunes, una situación en la que un recurso compartido es sobreutilizado o descuidado porque los usuarios individuales actúan en su propio interés a corto plazo en lugar de en el interés a largo plazo del grupo.
Cada persona tiene un incentivo para tomar más (o contribuir menos) de lo que es sostenible, y el recurso se degrada como resultado. Esto sucede cuando hay una desalineación entre el interés propio a corto plazo del individuo y el interés a largo plazo del grupo. A veces existe alineación; a veces no.
Un desarrollador de Bitcoin planteó el problema de manera contundente: “Usar mocks y stubs de código de código abierto en pruebas es irresponsable y miope. El código de código abierto se considera seguro porque cualquiera puede verificarlo. Si no estás dispuesto a hacer el mínimo de pruebas de las características de las que realmente dependes, entonces te comportas como una sanguijuela.”
Como resultado, el código abierto no crea seguridad por sí mismo. Crea la posibilidad de verificación. Si esa verificación ocurre depende de incentivos, habilidades y atención. Se cree que el FOSS histórico se endurece con el tiempo a medida que se descubren, divulgan y corrigen vulnerabilidades, creando bases sólidas sobre las que otros construyen. El núcleo de Linux es un gran ejemplo de tal FOSS endurecido; impulsa la gran mayoría de los servidores del mundo, la infraestructura en la nube, los dispositivos Android y los sistemas embebidos, convirtiéndolo en uno de los programas de software más ampliamente desplegados en la historia.
Código Abierto como lo Demuestra Bitcoin Core
Bitcoin Core, la implementación de referencia de Bitcoin, es otro ejemplo previsor de funcionamiento puro de código abierto a gran escala en el mundo real. El software, que funciona detrás de la mayoría de la infraestructura relacionada con Bitcoin, se publica bajo la licencia MIT. Su proceso de desarrollo es ampliamente público por diseño.
Cualquiera puede abrir una solicitud de extracción. La revisión de código es el filtro principal y el punto de entrada recomendado para nuevos colaboradores. Los revisores utilizan un vocabulario formal: Concept ACK (reconocimiento y acuerdo con el objetivo), Approach ACK (acuerdo con el objetivo y el método), ACK con un hash de commit específico (probado y aprobado para fusión), o NACK (desacuerdo, que debe ir acompañado de un razonamiento técnico).
Los mantenedores sopesan el consenso entre los colaboradores y los méritos técnicos de un cambio antes de fusionar. Los cambios críticos para el consenso enfrentan un estándar aún más alto y generalmente requieren una Propuesta de Mejora de Bitcoin y extensas discusiones de varios años en la lista de correo bitcoin-dev y en IRC.
No hay una casta privilegiada de “desarrolladores de Bitcoin Core.” La confianza se gana a través de la competencia demostrada a lo largo del tiempo. Los mantenedores existen por razones prácticas: auditar y fusionar código, gestionar lanzamientos y moderación básica, pero el trabajo producido es código de código abierto puro que cualquiera puede inspeccionar, construir, bifurcar o ejecutar. Los desarrolladores que logran que sus ‘commits’ de código se fusionen en Bitcoin Core son ampliamente llamados Contribuidores de Bitcoin Core.
Calle, un desarrollador de Bitcoin de código abierto desde hace mucho tiempo, resumió la realidad recientemente: “Las personas que piensan que el núcleo es algún tipo de institución opaca que opera en las sombras son demasiado perezosas o demasiado tontas para ir a verlo por sí mismas. Literalmente, todo lo que hacen es público, cualquiera puede participar, y el resultado de su trabajo es código de código abierto puro.”
La financiación de este trabajo proviene en gran medida de estructuras sin fines de lucro y de subvenciones como Brink, OpenSats, Spiral y otras, en lugar de una hoja de ruta de productos de una empresa tradicional. La discusión técnica y el debate tienen lugar públicamente en la lista de correo bitcoin-dev y en el canal IRC #bitcoin-core-dev en Libera Chat, donde las propuestas son examinadas antes y durante el proceso de solicitud de extracción. Los problemas y solicitudes de extracción de GitHub a menudo llevan historiales de comentarios que se remontan a una década. El resultado es una cultura de desarrollo optimizada para la corrección y la auditabilidad en lugar de la velocidad o la velocidad de características comerciales.
La Economía del Código Abierto
La mayoría de los usuarios de software de código abierto o disponible nunca leen el código ellos mismos. Confían en la suposición de que otros lo están examinando. En el caso de Coldcard, un defecto crítico de entropía permaneció en el firmware disponible públicamente durante aproximadamente cinco años antes de ser explotado y, por lo tanto, descubierto.
El error ingresó en la base de código durante una reescritura importante en 2021 que también eliminó el código derivado de GPL restante de Trezor, la primera billetera de hardware y ahora la segunda más grande en la industria de la autocustodia. La biblioteca en el centro de la falla de entropía, que reemplazó a trezor-crypto, se llama libngu y tuvo un escrutinio externo mínimo, con solo 7 estrellas y menos de 20 bifurcaciones en más de 5 años de uso en producción. Compáralo con las 512 estrellas que tiene la biblioteca trezor-crypto junto con 212 bifurcaciones, o las 793 bifurcaciones y 1.8k estrellas de la más moderna trezor-firmware. La disponibilidad de la fuente por sí sola no produjo la revisión que importaba, porque otras empresas con fines de lucro y bien financiadas estaban restringidas de usarla, o eso argumentarían los críticos.
Las apuestas son más altas en Bitcoin que en la mayoría de los dominios de software. Un error crítico puede convertirse directamente en fondos líquidos en el mercado abierto. Mientras que la primera mitad de los fondos de Coldcard robados todavía se mantienen en un puñado de direcciones y el hacker puede ser atrapado algún día, los hackers imitadores que siguieron fueron más cuidadosos, y algunos han robado más bitcoin y lo han blanqueado con éxito, según Galaxy Research. La resistencia a la censura de Bitcoin y su capacidad de transacción inmutable crean tanto un poderoso incentivo para los atacantes como un filtro darwiniano; solo los proyectos que atraen continuamente revisiones competentes, y los usuarios y empresas que toman precauciones serias, tienden a sobrevivir a largo plazo.
Las elecciones de licencia moldean esos incentivos según los defensores del FOSS que criticaron las decisiones de licencia de Coinkite durante años. Las licencias de código abierto puro maximizan el grupo de revisores potenciales y bifurcaciones. Las licencias restringidas de "código disponible" pueden reducir el aprovechamiento comercial, pero también disminuyen el círculo de personas con tanto el derecho legal como el motivo económico para invertir atención profunda. Lamentablemente, la carga de la revisión del código recae de nuevo en la empresa bajo una licencia restrictiva, colocándola en cierto sentido más cerca del código cerrado que del abierto.
Cómo la IA Cambia el Desarrollo de Código Abierto y Cerrado
La inteligencia artificial ahora también está alterando el equilibrio entre FOSS y el código cerrado.
Después del incidente de Coldcard, un esfuerzo de voluntarios conocido como el Bitcoin Red Team—liderado por desarrolladores como Calle y Rob Hamilton de AnchorWatch, y apoyado por OpenSats—utilizó modelos de IA de vanguardia para escanear cientos de repositorios de Bitcoin de código abierto. En un período intensivo, el equipo presentó miles de hallazgos, incluidos docenas clasificados como críticos o de alta gravedad, en cientos de proyectos. Se realizaron divulgaciones responsables a los mantenedores antes de la publicación más amplia. El ejercicio demostró que la revisión sistemática asistida por IA puede sacar a la luz problemas a una escala y velocidad previamente impracticables para equipos puramente humanos.
En este sentido, vale la pena señalar que el Red Team encontró que los modelos de peso abierto chinos eran mucho más confiables que los modelos estadounidenses de código cerrado, que, incluso con permisos cibernéticos y acceso de primera línea, se negaron a responder a las consultas del Red Team, una tendencia que los desarrolladores estadounidenses lamentan.
Al mismo tiempo, la avalancha de código generado por IA ha creado una nueva presión de denegación de servicio sobre los mantenedores de FOSS. Revisar la salida de la IA a menudo toma más tiempo que generarla. Algunos proyectos de código abierto fuera de Bitcoin han restringido los rastreadores de problemas o impuesto estrictas reglas anti-contribución de IA simplemente para mantenerse funcionales.
Fuente: BitcoinMagazine
