Por Gavin Andresen (@gavinandresen)
Hace casi dos años, cuando dejé de ser el encargado principal del mantenimiento de Bitcoin Core, escribí:
Me alegra poder concentrarme más en el protocolo, en cuestiones relacionadas con la implementación transversal y menos en cuestiones específicas del software Bitcoin Core.
Aún sigo interesado en trabajar a nivel del protocolo, pero últimamente me he dedicado a ayudar con algunas otras implementaciones (primero XT, recientemente Bitcoin Classic, y pronto quizás Bitcoin Unlimited), lo cual ha generado mucha controversia (y herido los sentimientos de algunos).
¡Locura! ¡Caos! ¡ANARQUÍA! … escucho decir a algunas personas, pero hay un método dentro de esa locura. Cuando era el encargado principal del mantenimiento de Core mis tres principales prioridades eran las siguientes:
1) Mantener el sistema seguro. 2) Mantener fiable el procesamiento de transacciones de la red. 3) Eliminar los puntos únicos de fallo.
Esas siguen siendo mis principales prioridades, pero intento tener una perspectiva más amplia, mirando a todo el ecosistema Bitcoin en lugar de sólo la implementación del software Core. Entonces, si esas son mis principales prioridades, ¿en qué debería estar trabajando?
El protocolo Bitcoin está muy bien en cuanto a su seguridad; el reporte de vulnerabilidades ha permanecido en silencio durante muchos meses. Y ver la adopción del sistema de múltiples firmas «p2sh» («pay-to-script-hash») me genera una gran satisfacción. Todavía sigo haciendo preguntas tontas a gente más inteligente que yo para tratar de evitar cometer errores a medida que el protocolo evoluciona.
Me sigue preocupando la fiabilidad de la red en el corto plazo, que es el motivo por el cual he estado hablando tanto sobre el tema del límite al tamaño del bloque, y que es parte de la razón por la que estoy apoyando alternativas a Bitcoin Core. A la larga, creo que todo saldrá bien, pase lo que pase con el límite del bloque.
Los ingenieros siempre encontrarán formas de esquivar dicho límite, sin importar realmente si se hace por medio de ‘extensión de bloques’ o de Lightning Network o de una cadena lateral a la cual todo el mundo envía sus monedas. Yo preferiría una solución simple, clara y limpia, pero ya tengo edad suficiente como para saber que la mayoría de las grandes tecnologías del mundo están construidas sobre horribles montones de cosas heredadas que se fueron acumulando, y funcionan muy bien casi todo el tiempo.
Y Bitcoin sobrevivirá sin una solución a corto plazo, pero la adopción y el crecimiento podría retrasarse uno o dos años.
La pregunta de qué hacer con los problemas de escalabilidad a corto plazo me lleva a mi tercera prioridad: la eliminación de puntos de fallo únicos. También conocido como «descentralizar todas las cosas» / «la diversidad es buena» / «la competencia es buena».
Una manera de eliminar los puntos de fallo únicos es probar diferentes soluciones para un problema al mismo tiempo. Asumiendo que tienes los recursos, esa es una buena estrategia –maximizas tus posibilidades de éxito, porque solo fracasas en la solución del problema si todas las diferentes soluciones fallan–.
Si aplicamos este razonamiento a los equipos de desarrollo, y suponiendo que contamos con los recursos, es mejor tener varios equipos ya que habrá menos problemas si uno de ellos falla.
Hace seis años, el ecosistema Bitcoin no contaba con recursos para mantener múltiples equipos de desarrollo –ahora sí, indudablemente–.
La especialización es natural a medida que las tecnologías maduran; Ford Motor Company solía recibir la materia prima en un extremo de su enorme fábrica y los autos terminados salían por el otro extremo. Hoy en día, Ford ensambla partes fabricadas por miles de proveedores, y trata de asegurarse de tener más de un proveedor para todo, a efectos de eliminar los puntos únicos de fallo.
Estoy haciendo todo lo que puedo para acelerar este proceso natural en el caso de Bitcoin. Voy a aportar mis consejos y experiencia (y revisión de código, y código) para Bitcoin Classic y Bitcoin Unlimited y Core, y tal vez para otros proyectos de código abierto. Espero que todos tengan éxito, y que puedan determinar en qué parte del ecosistema Bitcoin deberían especializarse –quizás Bitcoin Classic sea la distribución preferida por los mineros y Bitcoin Unlimited se dedique a funciones específicas para los usuarios finales; quizás Bitcoin Core decida centrarse en las mejoras a largo plazo a nivel del protocolo–.
O tal vez se especialicen gestando diferentes culturas de desarrollo o procesos para la toma de decisiones. Si esto te parece loco, te propongo que investigues cómo las diversas distribuciones de Linux difieren en cuanto a las prioridades, la toma de decisiones, la cultura, etc. La diversidad es buena.
Pero, ¿y si las diversas implementaciones no pueden ponerse de acuerdo en algo que todos necesitan hacer de la misma manera? Linux tiene a Linus… ¿quién va a tomar la decisión final sobre cuáles son las reglas de consenso para Bitcoin?
Satoshi respondió a esa pregunta en las últimas oraciones de su paper:
Los nodos pueden abandonar la red y reintegrarse a voluntad, aceptando la cadena de prueba de trabajo como prueba de lo que sucedió mientras estaban fuera. Ellos votan con su poder de cómputo, expresando su aceptación de los bloques válidos al trabajar en la extensión de los mismos, y rechazando los bloques no válidos al rehusarse a trabajar en ellos. Las reglas y los incentivos necesarios se pueden hacer cumplir por medio de este mecanismo de consenso.
Planeo escribir más sobre los incentivos y el proceso de llegar a un consenso en un futuro cercano.
Leer versión original en inglés
Imagen por geralt