Los desarrolladores de protocolos a menudo parecen tener una visión más pesimista sobre el futuro de Bitcoin que la mayoría de los entusiastas. La exposición diaria a las imperfecciones de Bitcoin ciertamente moldea una perspectiva más sobria, y es esencial reflexionar sobre los logros de esta criptomoneda. Cualquier persona en el mundo, independientemente de su raza, edad, género, nacionalidad u otro criterio arbitrario, puede almacenar y transferir valor en una red monetaria neutral que es más robusta que nunca. Sin embargo, Bitcoin presenta problemas que muchos usuarios no conocen, pero que podrían amenazar su futuro si no se abordan adecuadamente. Las vulnerabilidades arregladas por la Limpieza de Consenso son un ejemplo de ello.
La Limpieza de Consenso (BIP 541) es una propuesta de soft fork que busca corregir múltiples vulnerabilidades de larga data dentro del protocolo de consenso de Bitcoin. Como propuesta de soft fork, se diferencia en su naturaleza de la mayoría de los otros esfuerzos de Bitcoin Core presentados en esta edición. Aunque la propuesta ha sido históricamente promovida por personas asociadas con el proyecto Bitcoin Core, en realidad pertenece a la categoría más amplia del desarrollo del protocolo de Bitcoin.
Vamos a analizar cada uno de los cuatro puntos de la propuesta, describiendo el impacto del problema abordado y la solución aplicada. Discutiremos cómo las mitigaciones propuestas evolucionaron para abordar comentarios y nuevas vulnerabilidades. Finalizaremos con una breve descripción del estado actual de la propuesta de soft fork.
La red de Bitcoin ajusta la dificultad de minería para mantener una tasa promedio de un bloque cada 10 minutos. Un error de programación común, conocido como «off by one», en su implementación, abre la puerta a un ataque llamado Timewarp, mediante el cual una mayoría de mineros puede acelerar artificialmente la producción de bloques manipulando la dificultad hacia abajo.
Afortunadamente, este ataque requiere un umbral del 51% o más de mineros, pero acelerar artificialmente la tasa de creación de bloques es un problema crítico. Esto significa que los nodos completos ya no controlan el uso de recursos y que un atacante podría acelerar considerablemente el cronograma de emisión de subsidios de Bitcoin.
Aunque requiere de un «minero al 51%», es una desviación significativa del modelo de amenaza estándar de Bitcoin. Un ataque del 51% generalmente permite a un minero prevenir la confirmación de una transacción mientras mantenga su ventaja. Sin embargo, la existencia de este error les otorga el poder de paralizar la red en tan solo 38 días al reducir rápidamente la dificultad de la red.
En lugar de derribar la red, es más probable que un atacante explote este error en menor medida. Los mineros actuales podrían coordinarse para cuadruplicar la tasa de bloques (a bloques de 2.5 minutos) mientras mantienen la red de Bitcoin en un estado aparentemente funcional, cuadruplicando efectivamente el espacio de bloques disponible y robando subsidios de bloques a futuros mineros. Los usuarios con una visión a corto plazo podrían verse incentivados a apoyar este ataque, ya que más espacio de bloques disponible significaría, ceteris paribus, tarifas más bajas para las transacciones en cadena. Esto, por supuesto, sería a expensas de los operadores de nodos completos y socavaría la estabilidad a largo plazo de la red.
El ataque Timewarp se aprovecha del hecho de que los periodos de ajuste de dificultad no se superponen, permitiendo que las marcas de tiempo de los bloques se configuren de manera que un nuevo periodo parezca empezar antes de que el anterior haya finalizado. Dado que hacer que se superpongan causaría un hard fork, la siguiente mejor mitigación es vincular las marcas de tiempo de los bloques en los límites de los periodos de ajuste de dificultad. Las especificaciones de BIP 54 estipulan que el primer bloque de un periodo no puede tener una marca de tiempo anterior a la del último bloque del periodo anterior por más de dos horas.
Además, las especificaciones de BIP 54 exigen que un periodo de ajuste de dificultad siempre tome un lapso de tiempo positivo. Es decir, para un periodo de ajuste de dificultad dado, el último bloque nunca puede tener una marca de tiempo anterior a la del primer bloque. ¿Te sorprende que esto no sea ya así? A nosotros nos sorprendió que fuera necesario. Resulta que esta es una solución simple para un ataque ingenioso, relacionado con Timewarp, que el desarrollador seudónimo Zawy y Mark «Murch» Erhardt sugirieron al revisar la propuesta de Limpieza de Consenso.
Cualquier minero puede explotar ciertas operaciones de validación costosas para crear bloques que tardan mucho en verificarse. Mientras que un bloque normal de Bitcoin toma cerca de cien milisegundos para validar, los tiempos de validación para estos «bloques de ataque» varían desde más de diez minutos en una computadora de alta gama hasta hasta diez horas en una Raspberry Pi (una opción popular de hardware para nodos completos).
Un atacante motivado externamente podría aprovechar esto para interrumpir toda la red, mientras que en una variante económicamente más racional del ataque, un minero puede retrasar a su competencia el tiempo suficiente para aumentar sus ganancias sin crear una interrupción general de la red.
Los intentos históricos de mitigar este problema han sido tumultuosos, ya que requieren imponer restricciones a las capacidades de scripting de Bitcoin. Tales restricciones tienen el potencial de ser confiscatorias, lo cual es fundamental evitar en cualquier diseño serio de soft fork.
La propuesta original de Matt Corallo de 2019, la Gran Limpieza de Consenso, buscaba solucionar estos largos tiempos de validación de bloque invalidando un par de operaciones obscuras en el Script no Segwit (“legacy”). Algunos expresaron preocupaciones de que, aunque las transacciones que usan esas operaciones no se habían transmitido ni minado por defecto por Bitcoin Core durante años, alguien, en algún lugar, podría seguir dependiendo de ellas sin que nadie lo supiera. Por supuesto, esto tiene que sopesarse frente al riesgo práctico que todos los usuarios de Bitcoin corren ante la explotación de este problema por un minero.
Aunque la preocupación de confiscación es relativamente teórica, hay un punto filosófico sobre cómo llevar a cabo el desarrollo de protocolos de Bitcoin al tratar de diseñar una mitigación adecuada para la vulnerabilidad con la superficie confiscatoria más pequeña posible. Mi iteración posterior de la propuesta de Limpieza de Consenso abordó esta preocupación introduciendo un límite que señala exactamente el comportamiento dañino, sin invalidar ninguna operación específica del Script de Bitcoin.
Los encabezados de bloque de Bitcoin contienen una raíz Merkle que se compromete a todas las transacciones en el bloque. Esto hace posible proporcionar una prueba concisa de que una determinada transacción es parte de una cadena con una cierta cantidad de Prueba de Trabajo. Esto se refiere comúnmente como una «prueba SPV».
Debido a una debilidad en el diseño del árbol Merkle, incluir una transacción de 64 bytes específicamente elaborada en un bloque permite a un atacante falsificar tal prueba para una transacción ficticia (inexistente) arbitraria. Esto podría utilizarse para engañar a los verificadores SPV, comúnmente utilizados para validar pagos entrantes o depósitos en un sistema secundario. Existen mitigaciones que permiten a los verificadores rechazar dichas pruebas inválidas; sin embargo, a menudo se pasan por alto, incluso por expertos en criptografía, y pueden ser complicadas en ciertos contextos.
La Limpieza de Consenso aborda este problema invalidando transacciones cuyo tamaño serializado es exactamente 64 bytes. Tales transacciones no pueden ser seguras en primer lugar (solo pueden quemar fondos o dejarlos para que cualquier persona los gaste), y no han sido transmitidas ni minadas por defecto por Bitcoin Core desde 2019. Se discutieron enfoques alternativos, como una forma indirecta de mejorar la mitigación existentea, pero los autores decidieron solucionar la raíz del problema, eliminando tanto la necesidad de que los implementadores apliquen la mitigación como la necesidad de que incluso conozcan la vulnerabilidad en primer lugar.
a: comprometiendo la profundidad del árbol Merkle en parte del campo de versión del encabezado de bloque.
“Micro… Mezzo… Macroflación—Economía Sobrecalentada” es el título de una entrada de blog4 publicada por Russell O’Connor en febrero de 2012, en la que describe cómo se pueden duplicar las transacciones de Bitcoin. Este fue un fallo crítico en Bitcoin, que rompió la suposición fundamental de que los identificadores de transacción (hashes) son únicos. Esto se debe a que las transacciones de coinbase de los mineros tienen una única entrada en blanco, lo que significa que cualquier transacción de coinbase con las mismas salidas tendría un identificador de transacción idéntico.
Esto fue solucionado por los desarrolladores de Bitcoin Core (entonces aún llamado «Bitcoin») con el BIP 302, que requería que los nodos completos realizaran una validación adicional al recibir un bloque. Esa validación adicional no era estrictamente necesaria para resolver el problema y fue eludida con el BIP 343 el mismo año. Desafortunadamente, la solución introducida en el BIP 34 es imperfecta y la validación adicional del BIP 30 será nuevamente requerida en 20 años. Más allá de no ser estrictamente necesaria, esta validación no puede ser realizada por diseños alternativos del cliente de Bitcoin, como Utreexo, y de hecho les impediría validar completamente la cadena de bloques.
La Limpieza de Consenso introduce una solución más robusta y a prueba de futuro para el problema. Todas las transacciones de Bitcoin, incluidas las transacciones de coinbase, contienen un campo para “bloquear temporalmente” la transacción. El valor del campo representa la última altura de bloque en la que una transacción es inválida. Las especificaciones de BIP 54 requieren que todas las transacciones de coinbase establezcan este campo en la altura de su bloque (menos 1).
Combinado con una sugerencia ingeniosa de Anthony Towns para asegurarse de que la validación de bloqueo temporal siempre ocurra, esto garantiza que ninguna transacción de coinbase con el mismo valor de bloqueo temporal haya podido ser incluida en un bloque anterior. Esto, a su vez, garantiza que ninguna transacción de coinbase puede tener el mismo identificador único (hash) que ninguna pasada, sin requerir validación de BIP 30.
Las vulnerabilidades abordadas por la Limpieza de Consenso (BIP 54) no son una amenaza existencial para Bitcoin en este momento. Si bien algunas tienen el potencial de paralizar la red, es poco probable que sean explotadas por ahora. Dicho esto, esto podría cambiar, y es fundamental mitigar proactivamente los riesgos a largo plazo para la red de Bitcoin, incluso si eso significa tener que asumir la carga a corto plazo de coordinar un soft fork.
El trabajo sobre la Limpieza de Consenso comenzó con la propuesta original de Matt Corallo en 2019. Se consolidó seis años después con mi publicación del BIP 54 y la implementación del soft fork en Bitcoin Inquisition, un banco de pruebas para cambios de consenso en Bitcoin. A lo largo de este tiempo, la propuesta recibió comentarios considerables, se consideraron diversas alternativas y se incorporaron mitigaciones para debilidades adicionales. Creo que ahora está lista para ser compartida con los usuarios de Bitcoin para su consideración.
La Limpieza de Consenso es un soft fork. Los desarrolladores de protocolos de Bitcoin eligen qué mejoras priorizar y poner a disposición del público. Pero la decisión final de adoptar un cambio en las reglas de consenso de Bitcoin recae en los usuarios. La elección es tuya.
No te pierdas la oportunidad de poseer El Problema Central — ¡que presenta artículos escritos por muchos desarrolladores centrales explicando los proyectos en los que trabajan!
Este artículo es la Carta del Editor destacada en la última edición impresa de Bitcoin Magazine, El Problema Central. Lo compartimos aquí como una mirada anticipada a las ideas exploradas en todo el número completo.
[1] https://github.com/bitcoin/bips/blob/master/bip-0054.md
[2] https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki
[3] https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki
Fuente: bitcoinmagazine.com