Divergencias, señalización y activación
Parece haber una cantidad considerable de confusión entre los usuarios de Bitcoin acerca de la naturaleza del proceso sobre el cual se basan los cambios al protocolo de Bitcoin. En una publicación anterior he descrito el proceso para efectuar cambios de código en el repositorio de software de Bitcoin Core. En esta publicación explicaré el aún más complejo proceso de efectuar cambios a las reglas de consenso que aseguran que todos se mantengan en la misma cadena de bloques y visualicen el mismo registro e historial de transacciones.
Cuando nodos diferentes terminan en cadenas diferentes se conoce como divergencia de consenso o una separación de la cadena. Tenga en cuenta que este tipo de divergencia (“fork”) es muy diferente a una de código (que se realiza usualmente al clonar el repositorio de otro). La mayoría de divergencias de código (si se hacen correctamente) no resultarán en nodos en diferentes cadenas a menos que se haga intencionalmente, como es el caso de las “altcoins”.
Cuando diferentes nodos terminan en diferentes cadenas bien cuando no ha sido esa la intención o bien como resultado de un ataque, se conoce como un fallo de consenso. La propiedad de anti-fragilidad depende estrictamente en la resilencia de la red a fallos de consenso.
De lejos la gran mayoría de cambios al código de Bitcoin no tiene impacto en las reglas de consenso.
Algunos cambios involucran simplemente mover código de un lugar a otro o cambiar el nombre de algunas cosas para hacerlas más claras, lo que también se conoce como “refactoring”. Un buen ejemplo de este tipo de cambio es la eliminación de los ficheros main.h y main.cpp por parte de Matt Corallo.
Otros cambios involucran optimización de ciertas operaciones bien para mejorar su rendimiento o para reducir el requerimiento de uso de recursos, como espacio o memoria. Ejemplos de este tipo incluyen la introducción de la sincronización “headers-first” (primero los encabezados) de Pieter Wuille que redujo drásticamente el tiempo de sincronización inicial cuando se arranca un nuevo nodo así como el uso de la biblioteca de cifrado secp256k1 (también desarrollada en su mayoría por Wuille) que mejoró notablemente la validación de firmas ECDSA haciendo que tome mucho menos tiempo el validar las transacciones y bloques y es hoy posiblemente mejor probada y más segura que la biblioteca OpenSSL a la cual reemplazo.
Los ejemplos mencionados hasta ahora ha producido un impacto significativo de beneficio al software y en general no ha causado impacto en compatibilidad con otros nodos.
Cuando se propone un cambio que afecta la compatibilidad con otros nodos, generalmente se requiere un BIP (Bitcoin Improvement Proposal). Puede encontrar una breve descripción del proceso BIP junto con una lista de BIPs existentes aquí.
Con el fin de ayudar a clasificar y priorizar los BIPs por su impacto en la compatibilidad, he escrito y publicado el BIP123 que actualmente está en efecto. Este BIP de proceso requiere que cualquier BIP que afecte la compatibilidad debe especificar a cual de las cuatro capas diferentes afecta: consenso, servicios punto a punto, API/RPC, y aplicaciones.
Todas las capas excepto la de consenso pueden permitirse la introducción de nuevas características opcionales y la eventual obsolencfa de características que están en desuso empleando técnicas que no representan riesgo de partición de la red o de la cadena.
La capa de consenso es por lejos la más difícil de cambiar puesto que define las reglas que determinan cuando un bloque en particular (y por tanto, una cadena de bloques en particular) es válida. Esto incluye verificaciones de formato de datos apropiado, límites de tamaño, asegurar que la recompensa del bloque no es excesiva, asegurar que todas las monedas gastadas existan en efecto, verificar las firmas de las transacciones, y más. Cualquier cambio a estas reglas puede generar una partición de la cadena.
En general los cambios a las reglas de consenso se pueden clasificar en dos categorías: “hard forks” y “soft forks”. Por definición, los “hard forks” relajan o eliminan reglas existentes mientras que los “soft forks” las ajustan o añaden nuevas reglas. Puede que no sea obvio inmediatamente pero esta distinción tiene implicaciones profundas.
Debido a que loas “hard forks” relajan o eliminan reglas existentes, los bloques que podrían haber sido rechazados por las reglas antiguas ahora son aceptados por los nodos que emplean estas nuevas reglas. Ejemplos incluyen el incremento de la recompensa por bloque, incremento del tamaño base máximo del bloque, cambio del formato de encabezado del bloque, o cambio de la función de prueba de trabajo. Los nodos que no actualizan sus reglas rechazarán estos bloques y continuarán siguiendo solo a las cadenas que refuerzan las reglas antiguas. Esto significa que al menos que los nodos actualicen, tendremos una partición en la cadena.
Hasta la fecha no se ha realizado un “hard fork” en Bitcoin. O al menos se cree que no ha sido el caso, debido a que generalmente es muy difícil asegurarse de que no existen comportamientos no documentados que resulten en una relajación de las reglas en efecto. Lo más cercano que hemos estado de esto ha sido la partición de la cadena en marzo del 2013 causada por un comportamiento no documentado (o lo que algunos llamaría un error) en una biblioteca de base de datos que causaba que algunos nodos rechacen bloques que debieron ser tomados como válidos. Este incidente se ha solucionado al rechazar este bloque explícitamente y reemplazando la biblioteca en versiones posteriores del software con una que (esperamos) no tenga este tipo de problemas.
Los “soft forks” simplemente ajustan o añaden nuevas reglas. Ejemplos incluyen recompensas, reducción del tamaño base máximo del bloque, modificar opcodes no utilizados de cierta manera a fin de que se creen nuevos, o añadir nuevos datos a los bloques y registrar el hash de la salida de una transacción OP_RETURN que es ignorada por nodos antiguos. Este último ejemplo es el mecanismo empleado en SegWit, de que hablaremos luego, para crear un espacio adicional en el bloque sin necesidad de un “hard fork”.
Al contrario de los “hard forks” con los “soft forks” los nodos antiguos continuarán aceptando los nuevos bloques debido que toda las verificaciones de validación serán aceptadas. Las nuevas versiones del software incluirán nuevas verificaciones de validación también, lo que significa que los bloques que pasan las verificaciones de validación de software antiguo podrían fallar en el nuevo. La implicancia importante para los “soft forks” es que mientras una mayoría de “hashpower” refuerce las nuevas reglas, todos los nodos continuarán convergiendo en una única cadena. Esto no es, sin lugar a dudas, el caso para “hard forks”.
Tanto los “hard forks” como los “soft forks” requieren un esfuerzo de coordinación para asegurar una transición sin dificultades y previenen o mitigan partición de la cadena. Los “hard forks” de manera predeterminada parten la cadena a menos que todos los nodos en la red actualicen su software en el momento en que las reglas cambien. Tome un tiempo para pensar en ello… considere las complicaciones logísticas y asuntos filosóficos respecto a forzar a todos los usuarios (y desarrolladores de aplicaciones) para aceptar el cambio o el riesgo real de seguridad de una potencial causa de fallo de consenso.
Los “soft forks” permiten mecanismos de despliegue sin mayor dificultad que no requieren que todos los nodos actualicen al mismo tiempo y ofrecen muchos más mecanismos de mitigación para prevenir la partición de la cadena. Además, los tipos de “soft forks” que se han desplegado en Bitcoin han sido especialmente diseñados para ser compatibles con versiones anteriores del software y preservan el comportamiento esperado por estas. Esto significa que usted puede abrir una billetera antigua que ha olvidado en algún disco duro viejo y ¡funcionará como se espera! Usted podrá enviar y recibir bitcoins de la misma manera que siempre lo ha hecho.
El proceso de transición a nuevas reglas de consenso se llama activación.
La introducción de Satoshi del límite de tamaño de bloque de 1MB en setiembre del 2010 es un ejemplo de un “soft fork”. Define una directiva de corte en un tamaño de bloque en especifico. Cualquier bloque después de este que exceda el límite será rechazado. Ha sido un mecanismo de activación muy crudo. Sin embargo, la red era lo suficientemente pequeña en ese momento y los riesgos suficientemente bajos que la coordinación ha sido simple y sin controversias.
Tiempo después, se ha empleado un mecanismo de activación que emplea una bandera de fecha en lugar de un tamaño de bloque. Dos “soft forks” se han desplegado utilizando este mecanismo: BIP16 (P2SH), que permite transacciones con múltiples firmas; y BIP30, que requiere que todas las transacciones tengan un identificador único.
Luego tuvimos BIP34, requiriendo que el tamaño del bloque se incluya en la transacción de coinbase, lo que introdujo un nuevo mecanismo de activación, afectuosamente llamando ISM (isSuperMajority) debido al nombre de la función de C++ que se invoca para verificar si debe activarlo. Este ha sido el primer mecanismo empleado que ha utilizado activación de “hashpower” (o minero), o lo que ahora se conoce como MASF (Miner Activated Soft Fork).
La premisa básica ha sido que la versión del bloque podría incrementarse en uno con cada activación de este tipo. Los bloques con la nueva versión serán requeridos de reforzar la regla adicional cuando el 75% de los bloques en un intervalo de 1000 bloques tengan la nueva versión. Luego una vez que el 95% de bloques tienen la versión más alta, los bloques con la versión inferior serán rechazados.
Este mecanismo se ha continuado utilizando para BIP65 (CHECKLOCKTIMEVERIFY) y BIP66 (Strict DER signatures). Sin embargo, limitaciones significativas de este mecanismo se hicieron evidentes. De manera crítica, debido a que cada despliegue de “soft fork” incrementaba la versión en uno, los “soft forks” solo se podían desplegar uno por vez - y hasta que todos los “soft fork” previos se hayan activado, era imposible activar otro. Si una activación fallaba por alguna razón, impediría el despliegue y activación de nuevos “soft forks”.
Esto ha llevado al desarrollo de BIP9 (Version bits), un mecanismo de activación de “soft fork” que permitía el despliegue y activación en paralelo al emplear diferentes bits en el campo de versión para cada “soft fork” en lugar de incrementar el número de versión. Una vez activado, no era necesario mantener el bit activado y podría usarse nuevamente para una activación futura. En principio, esto permitiría el despliegue en paralelo de hasta 29 “soft forks” activados de forma independiente. Esto todavía dependía de la señalización de “haspower” (al definir el bit de versión).
La razón por la que IsSuperMajority y BIP9 dependía de la señalización de “hashpower” es que incluso cuando los “soft forks” no requieren que todos los nodos se actualicen al mismo tiempo, los mineros deben actualizar para reforzar las nuevas reglas a fin de asegurarse de que no terminen minando bloques que serán rechazados por los nodos que refuerzan las nuevas reglas. El uso de la señalización del minero permitía una coordinación sin problemas -mientras que una super mayoría de mineros refuercen las nuevas reglas, el riesgo de una partición de la cadena estaría virtualmente eliminado. Se ha elegido 95% simplemente para asegurarse de que no existan problemas. Nunca ha sido la intención de convertirlo en una forma de votación. La idea ha sido de que los “soft forks” deben discutirse y revisarse previo a su despliegue para asegurarse de que tienen el suficiente respaldo del ecosistema. BIP9 ha sido simplemente una solución al problema de coordinación de la transición, evitando interrumpir la red lo máximo posible.
La activación de BIP66, sin embargo, debido a que incluso cuando los mineros estaban señalándolo, muchos no estaban reforzando las reglas en la práctica. Esto ha llevado a que algunos mineros construyan una cadena que ha sido rechazada por los nodos que reforzaban BIP66. Estos bloques subsecuentemente han sido rechazados por la red y los mineros que minaron en esta cadena perdieron sus recompensas. Esto se conoce como minería sin validación (validationless mining) y es una práctica que se desaconseja en general.
BIP9 se ha usado por primera vez para activar el paquete de “soft fork” BIP68/BIP112/BIP113 que ha añadido el opcode CHECKSEQUENCEVERIFY que permite timelocks relativos. Este despliegue y activación se produjo sin problemas. Luego ha venido el segundo “soft fork” que se ha declarado para activación empleando BIP9, BIP141 (SegWit), y aquí … es donde los problemas se iniciaron … y ya no volverá a ser lo mismo otra vez.
A pesar de haber realizado una inmensa cantidad de comunicación a los usuarios y la industria, este “soft fork” en específico se volvió altamente político como un resultado de malas interpretaciones así como lo que parece ser una divergencia de intereses que no se ha discutido de manera abierta y no se ha reconocido previo a su despliegue. Específicamente, a pesar de que todos los más grandes operadores de granjas de minado dijeron que lo señalarían, cuando finalmente se publique, un número significante de “hashpower” ha rechazado hacerlo. Algunas granjas de minado empezaron a emplear amenazas de utilizar otras versiones del software de Bitcoin que eran incompatibles en la capa de consenso y a efectuar demandas cambiantes, que para ser sincero, confundieron mucho a la mayoría de los desarrolladores.
En retrospectiva, se ha hecho evidente que no se puede depender en la activación de minero de los “soft fork” cuando existe una divergencia de intereses entre mineros y usuarios. En el caso de cooperación, es un mecanismos probado y validado que si se realiza correctamente se sabe que funciona sin problemas. Sin embargo, en el caso cuando estos son adversarios simplemente no funciona. BIP9 en efecto otorga una pequeña cantidad de poder de veto al “hashpower” sobre cualquier activación de “soft fork” sin importar cuan popular sea entre los usuarios e industria.
Recuerda, el 95% se ha concebido como una valla de seguridad, no como un medio de voto. Ha sido elegido arbitrariamente. En realidad, incluso un número tan bajo como 60% pudo haber sido suficiente para asegurar que no exista una partición permanente de la cadena, aunque el 95% tiene a reducir drásticamente el ratio de orfandad y el potencial de que una partición temporal de cadena persista por más de unos cuantos bloques.
Y recuerda que antes de la llegada de la activación de minero, Bitcoin dependía en una activación a través de una fecha bandera y tamaño de bloque lo que dependía en que los nodos económicamente importantes actualicen el software como el incentivo para que los mineros lo hagan. Este tipo de mecanismo por tanto ha recibido el nombre de UASF (User Activated Soft Fork).
Dado estas lecciones del pasado, parece que será necesaria una combinación de MASF y UASF para futuros despliegues a fin de enfrentar adecuadamente estos escenarios adversos. Es poco probable que BIP9 se vuelva a utilizar en un futuro.
Desafortunadamente, BIP141 (SegWit) ya se ha desplegado empleando el mecanismo BIP9 y al momento en que escribo esto se ejecta en alrededor del 80% de los nodos de acuerdo a las gráficas de Luke-Jr. El volver a desplegar empleando un nuevo mecanismo de activación es un proceso largo lleno de tensión con complicaciones. Esto significa que la activación de usuario solo se puede hacer de manera realista en un periodo corto de tiempo por los usuarios que ejecutan el software que requiere que los mineros lo señalen.
Esto ha conducido al desarrollo de BIP148 y BIP149 por Shaolin Fry. Ambos se pueden considerar mecanismos de activación de usuario pero son muy distintos. BIP148 requiere que los mineros señalicen BIP141 desde el 1 de agosto de 2017 hasta que la activación se asegure y es más agresivo que BIP149, que espera hasta que el proceso en curso de despliegue BIP9 expire en noviembre de 2017 y lo vuelve a desplegar empleando BIP8, una modificación de BIP9 que todavía permite a los mineros señalizar pero define una fecha de expiración estricta en la que se debe activar. BIP149 podría significar que BIP141 (SegWit) no se active hasta por lo menos el 2018.
Por favor tenga en cuenta de que ni BIP148 o BIP149 ¡requieren que los mineros soporten transacciones SegWit o las incluyan en sus bloques! Simplemente se aseguran de que los mineros no obstruyan a otros mineros de hacerlo
Dado las presiones de escalabilidad que la red está experimentando y el tremendo avance en tecnología de canal de pagos que depende de que BIP141 (SegWit) funcione adecuadamente, creo que el conflicto actual entre usuario y algunos mineros amerita una solución inmediata. BIP141 ya se ha activado exitosamente en otras cadenas de bloques incluyendo Litecoin cuyo precio ha crecido significativamente como resultado de su activación.
Al ejecutar BIP148 e insistir que las billeteras y casas de cambio que utilizas la soporten, ocasiona que se defina una fecha definitiva para su activación. Los mineros deben o bien activar en julio o deben señalizar desde el 1 de agosto hasta que se active. Los mineros deberán permitir que otros mineros minen bloques SegWit y permitir a los usuarios emplear software con SegWit activo. Si no lo hacen, sus bloques no serán aceptados por la mayoría económica y por tanto no podrán vender ningún Bitcoin que minen o recolecten como comisiones al precio de que los usuarios y empresas que apoyan SegWit están dispuestos a pagar.
Existen muchos escenarios posibles que pueden darse asumiendo que algunos mineros insistan en bloquear SegWit -aunque todo esto es muy costoso para tales mineros, mientras que minar en la cadena que apoya SegWit continuará siendo altamente rentable. Debido a que BIP148 es un “soft fork”, en el momento en que obtiene suficiente “hashpower” toda la red convergerá en ella como la cadena más larga válida y el ecosistema podrá continuar construyendo sobre las últimas innovaciones al protocolo. ¡Finalmente dejaremos el ruido y continuaremos construyendo el futuro!
Traducción del artículo original: Forks, Signaling, and Activation por Eric Lombrozo, desarrollador de Bitcoin.