Por qué los desarrolladores CORE de Bitcoin quieren múltiples versiones

Los debates recientes sobre si se debería permitir a las personas realizar sus propios cambios en el protocolo Bitcoin han resaltado una noción importante: tal vez el desarrollo de Bitcoin CORE, la versión de referencia del código, no sea la única manera en que las personas puedan contribuir.

Una alteración reciente del código de Bitcoin que Llegó a una variante de Linux llamada GentooDejó a algunas personas furiosas antes de que el desarrollador lo desactivara de forma predeterminada.

"Estos nunca se fusionarán con el repositorio de Bitcoin en Github, pero las personas que quieran usarlos podrán hacerlo", dijo el desarrollador principal de Bitcoin , Wladimir J van der Laan.

Pero, ¿qué es Github?, ¿por qué van der Laan tiene la autoridad de elegir lo que contiene y cómo se desarrolla Bitcoin en primer lugar?

Cómo se desarrolló Bitcoin

La implementación de referencia del protocolo Bitcoin se denomina Bitcoin CORE. Este es el código que Satoshi entregó originalmente a un grupo CORE de desarrolladores antes de desaparecer.

Esos "discípulos" ahora mantienen ese código, con la ayuda de una comunidad más amplia de desarrolladores. El objetivo es hacer el código más eficiente, pero haciéndolo con cuidado y de forma conservadora, para que nada se rompa.

Bitcoin CORE se gestiona mediante un sistema de control de versiones de software llamado GitEsto permite a las personas KEEP un seguimiento de las versiones de su código en las que están trabajando y los cambios que han realizado.

Los desarrolladores de Bitcoin que ejecutan Git en sus computadoras se conectan a un servicio central para que todos puedan trabajar en versiones del mismo proyecto a la vez. Este servicio, llamado Github, tiene muchos proyectos diferentes mantenidos por diferentes grupos de personas. Bitcoin es ONE de esos proyectos y tiene su propio Página de Github.

El código del proyecto se encuentra en un único lugar de Github, llamado repositorio. La versión oficial e implementable del repositorio de Bitcoin se conoce como repositorio upstream, pero quienes deseen trabajar en sus propios cambios en el código pueden crear sus propias versiones del repositorio copiándolo en una bifurcación en línea.

Los desarrolladores pueden modificar sus bifurcaciones tanto como deseen. Pueden solicitar que su bifurcación se fusione de nuevo con el repositorio principal mediante una solicitud de incorporación de cambios (pull Request), que abre su versión del repositorio a otros miembros del proyecto, quienes pueden revisarla y comentarla.

"La idea es que otros desarrolladores de la comunidad revisen el cambio", explicó van der Laan. "Luego, quien lo envía corrige los problemas que otros han mencionado. También puede ser necesario Rally a algunas personas a probar el cambio, especialmente si es complejo o si tiene un componente subjetivo (por ejemplo, para cambios en la interfaz de usuario o RPC)".

Si suficientes personas están de acuerdo con los cambios realizados en una Request de extracción, esta se fusiona de nuevo en el repositorio principal. Pero ¿quién puede realmente fusionar la solicitud de extracción?

Resulta que existe una especie de sacerdocio de Bitcoin que gestiona lo que finalmente se integra al código de Bitcoin CORE . Van der Laan, el científico jefe y exdesarrollador principal Gavin Andresen, Jeff Garzik, Gregory Maxwell y Pieter Wuille son el equipo que toma la decisión final, y eso no se decide por votación, como podría ocurrir en una democracia.

“Los repositorios individuales de Github no son democráticos”, explicó van der Laan. “Sus mantenedores cooperan en el desarrollo y deciden qué se fusiona, cuándo y qué no. Los problemas técnicos complejos no se resuelven mediante votación popular”.

BIPS y solicitudes de extracción

Sin embargo, siempre que es posible, el desarrollo de Bitcoin suele operar por consenso popular. En términos generales, existen dos categorías de cambio.

El CORE de Bitcoin se mantiene de forma intencionadamente conservadora, y la mayoría de los cambios se realizan de forma "no controvertida y de mantenimiento", afirmó van der Laan. Se trata de cambios pequeños e incrementales, en lugar de grandes y revolucionarios. Un parche de Bitcoin podría modificar parte del código para hacerlo más legible o quizás optimizar el uso de memoria.

Existe otra clase de cambios en Bitcoin con muchas más ramificaciones: los que modifican las reglas de consenso. Estas reglas son las normas técnicas que todos los clientes de Bitcoin deben cumplir para el correcto funcionamiento de la red.

"Esas cuestiones deben analizarse minuciosamente. Deben discutirse primero en la lista de correo, y debe haber un BIP, y las solicitudes de admisión suelen ser controvertidas y permanecen abiertas durante mucho tiempo para su debate", dijo.

Un BIP – abreviatura dePropuesta de mejora de BitcoinEs un documento que sugiere un cambio global en algún aspecto de Bitcoin. Puede extenderse a aspectos externos a Bitcoin CORE, como las billeteras móviles o la generación de claves en billeteras físicas. También puede regir procesos relacionados con Bitcoin, como cambios en el proceso de toma de decisiones.

Cualquiera puede crear un BIP, siempre y cuando esté escrito eneste formatoLa comunidad lo comenta y, si a la gente le gusta, se puede cambiar su estado a "activo" o "final".

Los cambios en este sentido son el cambio enBIP 62, lo cual fue un cambio que tuvo que ver con ladefecto de maleabilidad de la transacción en Bitcoin.

¿Qué mejora la probabilidad de que un cambio propuesto se implemente en el protocolo? Es útil que el autor de un BIP haya escrito un ejemplo del código para que la gente lo pruebe y revise, añadió van der Laan.

Revisión y aprobación

Consultor de Bitcoin y auditor de seguridad Sergio LernerMe gustaría ver más formalización del proceso de aprobación del código.

"Cuando ves una Request de incorporación de cambios fusionada, es difícil saber quién la aprobó y hasta qué punto se revisó el parche", dijo. "Hay que leer muchos comentarios y algún '+1' que se puede interpretar como 'Acepto fusionarlo', pero también como 'Me gusta, pero no he revisado bien el código'".

A Lerner le gustaría ver unamulti-firma Proceso de aprobación de parches, en el que un cierto porcentaje de desarrolladores aprueba formalmente el código firmando la revisión. Esta sería una versión más amplia del proceso que se utiliza actualmente en algunas billeteras, donde se requieren múltiples firmas para que se utilice una dirección de Bitcoin .

Otras cosas que a Lerner le gustaría ver incluyen un registro de errores encontrados y un análisis de por qué no se detectaron a tiempo, una revisión de código externa centrada en la seguridad por parche, una descripción formal de la documentación que debe acompañar a un parche y una descripción de lo que realmente significa revisar un parche.

"¿Significa una revisión del código fuente línea por línea? ¿Significa comprobar si la documentación del cambio es suficiente?", preguntó Lerner. "¿Significa analizar el cambio frente a vectores de ataque conocidos?"

El problema es que todo esto requiere tiempo y recursos Human , dijo Lerner:

Obviamente, implementar todo esto requiere más gestión, un mayor presupuesto y más recursos de CORE (que actualmente son escasos). Pero un software que mantiene una industria de 6 mil millones de dólares lo requiere.

Más allá de Bitcoin CORE

Mientras Lerner describe algunos requisitos para las revisiones de código, van der Laan se hace eco del discurso de apertura de Gavin Andresen en laConferencia Bitcoin 2014, donde dijo queSe podría hacer más para agilizar la aprobación del BIP.

“El proceso BIP podría mejorarse. Me alegraría que los desarrolladores de otras implementaciones de nodos (completos) fueran más activos comentando las propuestas (o presentando propuestas)”, dijo.

Andresen también propone trasladar la discusión de BIP y otras preocupaciones de implementación cruzada de la lista de correo general de desarrollo de Bitcoin a una lista de correo específica de BIP.

Al igual que ocurre con el desarrollo de software en un proyecto de código abierto, la responsabilidad de hacerlo realidad recae siempre en los usuarios.

“Dado que se trata inherentemente de un proceso global, distribuido y desorganizado, no es tarea de una sola organización gestionar el proceso BIP, por lo que la responsabilidad recaería en las personas y organizaciones que se interesen en BAND y hacer algo”, sugirió van der Laan.

Pero ¿ no debería la Fundación Bitcoin , la principal organización comercial de Bitcoin, encargarse de estas cosas? No, argumenta. En cambio, el mundo de Bitcoin se está expandiendo más allá de eso, y el equipo de desarrollo da la bienvenida a diferentes implementaciones de Bitcoin.

Van der Laan dijo:

"La charla de Gavin en Bitcoin 2014lo dejó claro Que su enfoque está en la diversificación. Habló de diferentes implementaciones de nodo completo, e incluso dijo que "cuanto más, mejor". Aunque mantener Bitcoin CORE es mi trabajo, suelo estar de acuerdo con eso.

Van der Laan cree que ya no debería recaer en el desarrollo de Bitcoin CORE.

En sus primeros años, Bitcoin CORE fue quizás excesivamente importante, y sus desarrolladores tuvieron que KEEP la infraestructura de nodos funcionando (y trabajar incansablemente para corregir errores a medida que aparecían). Pero, de cara al futuro, para que Bitcoin sea el sistema global distribuido que se suponía que sería, debemos ir más allá.

Así pues, puede que exista un sacerdocio benévolo para Bitcoin CORE, en el sentido de que la decisión final sobre el contenido del código recae en un pequeño grupo de personas. Pero eso no significa que este grupo quiera que las cosas sean exclusivas o elitistas, ni mucho menos.

Al menos algunos de los desarrolladores CORE animan activamente a otros a expandir la red con sus propias implementaciones, asumiendo que la mayoría se apegará a las reglas de consenso. Quienes no lo hagan perderán la sincronía, lo que hará evidente quiénes son minoría y los obligará a corregirlo.

La evolución de Bitcoin en esa dirección podría crear espacio para los tipos de variaciones de Regulación que Algunas personas han estado pidiendo, preservando al mismo tiempo las reglas de consenso: los elementos que realmente hacen de Bitcoin lo que es. También aliviaría la presión sobre un grupo de personas sobrecargadas que intentan respaldar la Tecnología que sustenta un negocio en rápido crecimiento. Y, si se hace correctamente, podría introducir algunos de los nuevos procesos que participantes como Lerner solicitan.

La pregunta es: ¿cómo logrará Bitcoin desarrollar tal variedad de implementaciones alternativas de manera limpia, eficiente y sin ningún drama asociado?

Diversificar la imagenvía Shutterstock