Para que Bitcoin funcione, todos los usuarios deben ponerse de acuerdo sobre un historial de transacciones (la cadena de bloques) y sobre un conjunto de reglas fundamentales que definan lo que se acepta en esta cadena de bloques y lo que no se acepta en esta cadena de bloques. Cuando no se puede alcanzar este consenso, la comunidad de usuarios puede dividirse en dos redes distintas, cada una con sus propias reglas. Esto es precisamente lo que ocurrió en 2017 durante la bifurcación dura que dio origen a Bitcoin Cash (BCH).
Pero, ¿cómo llegamos allí? En este artículo, te invito a revivir este período de conflictos dentro de la comunidad de Bitcoin, conocido como la «guerra del tamaño de los bloques», para entender cómo este debate ha moldeado permanentemente la ideología de los bitcoiners.
El origen del conflicto
La guerra del tamaño de bloques se originó en un debate técnico sobre la capacidad de Bitcoin para gestionar un volumen cada vez mayor de transacciones. Esto a veces se denomina «escalabilidad» o «ampliación». Al adoptarse como método de pago, el invento de Satoshi debe poder gestionar las transacciones de los nuevos usuarios y, al mismo tiempo, mantener tarifas razonables.
Entre estas limitaciones técnicas que reducen el flujo de transacciones, obviamente está el límite de tamaño de bloque en la cadena de bloques. Cuanto más grandes sean los bloques, más transacciones deberán confirmarse.
Cuando se lanzó en 2009, Bitcoin no tenía un límite explícito para este tamaño. Sin embargo, en 2010, Satoshi Nakamoto introdujo un límite establecido en 1 megabyte (mediante la constante TAMAÑO_MÁXIMO DE BLOQUE). El propósito de esta modificación era evitar los ataques de spam transaccional y garantizar una cierta descentralización de la red al evitar que bloques excesivamente grandes monopolizaran los recursos de los operadores de nodos.
En ese momento, el tamaño de 1 MB era más que suficiente para soportar el bajo número de transacciones en la red. Sin embargo, a medida que Bitcoin crecía en popularidad, la comunidad comenzó a debatir la necesidad de aumentar este límite para permitir una mejor gestión del volumen de transacciones sin que las comisiones se dispararan. Así es como surgió una primera brecha dentro de la comunidad de Bitcoin. Algunos, que más tarde serían llamados «grandes bloqueadores», creían que aumentar el tamaño de los bloques era una solución simple y directa para resolver los problemas de congestión. Por el contrario, otros, a los que llamaremos «pequeños bloqueadores», argumentaron que con este enfoque se corría el riesgo de centralizar la red al aumentar los requisitos de hardware de los nodos.
De hecho, dado que cada nodo completo debe comprobar y almacenar toda la cadena de bloques en la memoria, los bloques más grandes requieren discos de mayor capacidad, lo que es más caro y reduce los incentivos para ejecutar su propio nodo. Si hay menos nodos de Bitcoin, la seguridad del sistema está peor distribuida, lo que aumenta los riesgos individuales de coerción al centrar la seguridad en un número menor de actores.
Estas discusiones sobre el tamaño de los bloques son incluso más antiguas que en el período 2015-2017. En realidad, ya en 2010, ya se habían hecho propuestas para aumentar el límite, como El parche propuesto por Jeff Garzik.
Pero fue realmente a partir de 2015 cuando el debate se convirtió en un conflicto, con una primera ofensiva por parte de los desarrolladores de Bitcoin XT, un cliente alternativo lanzado por Mike Hearn y apoyado por Gavin Andresen (antiguo mantenedor principal de Bitcoin tras la marcha de Satoshi Nakamoto). Bitcoin XT fue originalmente una implementación del protocolo Bitcoin compatible con Bitcoin Core. Sin embargo, en agosto de 2015, la versión 0.11A de Bitcoin XT adoptó el BIP101: un hard fork que aumenta inmediatamente el límite de tamaño de los bloques de 1 MB a 8 MB, con la adición de un mecanismo para duplicar este límite cada dos años, hasta llegar a poco más de 8 GB por bloque en 2036. De hecho, los nodos de Bitcoin XT se han separado, por lo tanto, del resto de la red Bitcoin. Muchos consideran que este tour de force es el casus belli de una guerra del tamaño de una manzana.
Bloqueadores pequeños versus bloqueadores grandes
El conflicto de Blocksize War se estructuró en torno a dos bandos opuestos: los «grandes bloqueadores» y los «pequeños bloqueadores», cada uno defendiendo un enfoque diferente para resolver el problema de escalabilidad de Bitcoin.
Los «grandes bloqueadores» estaban a favor de aumentar el tamaño de los bloques para permitir que Bitcoin procesara una mayor cantidad de transacciones. Para ellos, este enfoque era necesario para reducir las tarifas de transacción y mejorar la experiencia del usuario a medida que Bitcoin crecía en popularidad. También sostuvieron que esta solución era técnicamente sencilla de implementar mediante bifurcaciones duras. En particular, los «grandes bloqueadores» contaban con el apoyo de los primeros desarrolladores, como Gavin Andresen, Jeff Garzik y Mike Hearn, y de actores influyentes como Roger Ver y la mayoría de las empresas mineras. Para ellos, el aumento del tamaño de los bloques era sinónimo de un aumento de sus ingresos. De hecho, si puedes incluir más transacciones en cada bloque, también puedes cobrar más comisiones.
Por el contrario, los «pequeños bloqueadores», representados principalmente por desarrolladores de Bitcoin Core como Pieter Wuille, Wladimir van der Laan, Peter Todd, Gregory Maxwell o Luke Dashjr, adoptaron un enfoque más conservador. Argumentaron que aumentar el tamaño de los bloques plantearía riesgos de centralización de la red, ya que supondría una carga mayor para los nodos, lo que limitaría la distribución de los riesgos. Los «pequeños bloqueadores» también querían que Bitcoin pudiera escalar, pero preferían soluciones de escalabilidad que alejaran las transacciones de la cadena de bloques principal, como la Lightning Network, por ejemplo. La idea era gestionar un gran volumen de transacciones sin cambiar el protocolo básico para preservar la descentralización de la red y, por lo tanto, la distribución de su seguridad. Los pequeños bloqueadores también prefieren los cambios conservadores realizados con bifurcaciones blandas en lugar de horquillas duras.
El debate técnico entre estas dos visiones de la escalabilidad ha dividido profundamente a la comunidad de Bitcoin. Cada bando movilizó estrategias de propaganda e influencia para tratar de hacer llegar sus ideas.
Propuestas e intentos de Forks
Los intentos y propuestas de Forks se multiplicaron entre 2015 y 2017. Como hemos visto, el primer intento real de bifurcación durante la guerra del tamaño de bloques fue el de BIP101 en Bitcoin XT. Esta propuesta contó con el apoyo de un gran número de mineros y de empresas influyentes en la época, como BitPay, Blockchain.info o Circle. Con el tiempo, Bitcoin XT no podrá conseguir el apoyo suficiente de la comunidad, y Mike Hearn acabará anunciando su marcha y la venta de sus bitcoins. Expresará su decepción en una entrada de blog en la que afirmará, en particular, que» Bitcoin falló ». Bitcoin XT marcó así el inicio de profundas diferencias en la comunidad, a las que pronto siguieron otras bifurcaciones.
A principios de diciembre de 2015, Pieter Wuille y Gregory Maxwell, desarrolladores de Bitcoin Core, propusieron un soft fork llamado «SegWit» (Testigo segregado). Esta propuesta tenía como objetivo separar los datos de las firmas de los datos de las transacciones en la cadena de bloques, a fin de resolver el problema de la maleabilidad de las transacciones. Este problema, vinculado al ECDSA, el algoritmo de firma digital utilizado en Bitcoin desde 2009, permite modificar ligeramente una firma válida para crear otra firma válida para la misma transacción. Esta vulnerabilidad impidió la implementación de Lightning Network. Por lo tanto, la intención de Maxwell y Wuille con SegWit era permitir un despliegue seguro de la Lightning Network y, por lo tanto, resolver los problemas de escalabilidad de Bitcoin. SegWit también incluyó un aumento leve y virtual del tamaño de los bloques, sin dejar de ser compatible con los nodos antiguos (bifurcación suave). Esta propuesta se convirtió rápidamente en la punta de lanza de los pequeños bloqueadores.
Sin embargo, tras el fracaso de Bitcoin XT, Gavin Andresen y Jeff Garzik regresaron unas semanas después con una nueva idea: Bitcoin Classic. Esta bifurcación, propuesta a principios de 2016, sugería un enfoque más moderado y consensuado que el de Bitcoin XT, con un aumento del tamaño de los bloques a 2 MB (mediante el BIP109). La iniciativa contó con el apoyo de numerosas empresas del sector, como Coinbase, así como de mineros.
A medida que Bitcoin Classic crecía en popularidad y amenazaba con dividir la red, el 20 de febrero de 2016 se organizó una reunión de emergencia: Mesa redonda de Hong Kong. Este evento reunió a mineros (incluidos Jihan Wu y Micree Zhan, los cofundadores de Bitmain), a algunas empresas influyentes y a desarrolladores de Bitcoin Core (incluidos Luke Dashjr, Matt Corallo y Peter Todd). Tras largas horas de negociación, se llegó a un acuerdo. Los desarrolladores principales se comprometen a implementar una bifurcación dura para SegWit, así como a duplicar el límite de tamaño de los bloques. Por su parte, los mineros y las empresas prometen apoyar esta bifurcación y utilizar exclusivamente el cliente Bitcoin Core, a fin de preservar la unidad de la red Bitcoin.
Se suponía que este acuerdo pondría fin a la guerra de Blocksize, pero en última instancia creó más conflictos. Cada parte interpretó el acuerdo de manera diferente y, en última instancia, nunca se implementará.
Algunos eventos externos también debilitaron este acuerdo, en particular el hackeo de The DAO en Ethereum, que llevó a un hard fork para recuperar los fondos robados, lo que provocó la división entre ETH (Ethereum) y ETC (Ethereum Classic). Este hard fork resultó ser un desastre para Ethereum, en particular debido a los ataques de repetición que interrumpieron a toda la industria (las transacciones de una cadena de bloques podían retransmitirse de forma idéntica en la otra cadena de bloques). Este fiasco puso de manifiesto todos los riesgos que una bifurcación dura podía suponer para Bitcoin y, por lo tanto, constituyó un argumento importante para los pequeños bloqueadores, que se encontraron en una posición de fortaleza. Al mismo tiempo, otros acontecimientos han empañado la reputación de algunos de los grandes bloqueadores, lo que ha reducido su credibilidad ante la comunidad. Este acuerdo de Hong Kong todavía tenía el mérito de frenar el impulso de Bitcoin Classic.
Los pequeños bloqueadores aprovechan esta reputación para lanzar únicamente los informes de SegWit, configurando que el soft fork se active si el 95% de la potencia informática lo aprueba durante un período de tiempo determinado. Sin embargo, durante las primeras semanas, el número de denuncias sigue siendo bajo y los menores no parecen querer cooperar. Al mismo tiempo, una nueva propuesta de bifurcación está ganando popularidad con Bitcoin Unlimited. Este cliente alternativo, promovido en particular por el empresario Roger Ver (apodado «Bitcoin Jesus»), propone aumentar el tamaño de los bloques de forma flexible mediante un hard fork. A diferencia de Bitcoin Classic, Bitcoin Unlimited no establece un límite superior para el tamaño de los bloques, lo que permite a los usuarios establecer sus propios ajustes.
Bajo la amenaza de esta nueva bifurcación, un desarrollador anónimo que se hacía llamar Shaolin Fry publicó BIP148 en marzo de 2017. El objetivo del BIP148 es forzar la activación de la actualización de SegWit sobre el protocolo Bitcoin, ante el estancamiento de la señalización de este soft fork por parte de los mineros mediante el clásico método BIP9. Para lograrlo, propone la implementación de una UASF (Soft Fork activado por el usuario), para activar SegWit por la fuerza por parte de los nodos el 15 de noviembre de 2017, si los mineros no habían bloqueado SegWit antes del 1 de agosto de 2017. Si los usuarios siguen el BIP148, los nodos de la red de Bitcoin rechazarán los bloques que no sean compatibles con SegWit, lo que presionará a los mineros para que adopten la actualización.
La comunidad ve esta propuesta de la UASF como una oportunidad para acabar finalmente con los grandes bloqueadores y, por lo tanto, está empezando a apoyarla activamente. La ropa con las siglas UASF está apareciendo en conferencias y la comunicación se está intensificando en Twitter.
Ante la amenaza de la UASF, los grandes bloqueadores se ven obligados a volver a la mesa de discusión a pesar de su posición de fuerza tras no denunciar SegWit. Por lo tanto, el 23 de mayo de 2017, se organizó una nueva reunión privada en Nueva York, al margen de la conferencia Consenso 2017, que reúne a más de 50 empresas del ecosistema Bitcoin. De esta reunión nació la propuesta de SegWit2x, que prevé dos cambios importantes en el protocolo de Bitcoin:
La adopción de SegWit con un umbral de activación establecido en el 80% de señalización;
Una bifurcación dura para aumentar el tamaño máximo de bloque de 1 MB a 2 MB.
James Hilliard (ingeniero de Bitmain) propuso entonces el BIP91 para facilitar la activación del soft fork de SegWit, definido en BIP141, BIP143 y BIP147, mediante un MASF del 80%. Este método tiene como objetivo hacer que el BIP148 (UASF) quede obsoleto y evitar una posible división de la cadena de bloques el 1 de agosto de 2017. El BIP91 se activó finalmente el 23 de julio de 2017 (en el bloque 477.120), justo antes de la fecha crítica del 1 de agosto establecida por el BIP148. Esto permite obligar a los menores a denunciar SegWit, que finalmente se bloqueará el 9 de agosto en el bloque 479 808 y se activará el 24 de agosto en el bloque 481 824.
Así que la UASF nunca ocurrió, pero desempeñó un papel decisivo en la adopción de SegWit al obligar a los mineros a bloquear el soft fork a través del BIP91. A largo plazo, el BIP148 sentó un importante precedente al demostrar la influencia que los usuarios pueden ejercer a través de sus nodos completos en las decisiones de gobernanza del protocolo Bitcoin, incluso si las grandes empresas y los mineros no están de acuerdo.
Paralelamente a la activación de SegWit, el 1 de agosto de 2017 en el bloque 478 559, parte de la comunidad de Bitcoin está llevando a cabo un hard fork para aumentar el tamaño del bloque a 8 MB. Esta división, denominada Bitcoin Cash (BCH), sigue existiendo hoy junto con Bitcoin, aunque su valoración es muy baja en comparación.
Tras la activación de SegWit, la segunda parte de SegWit2x aún tenía que implementarse en el bloque 494 784, es decir, durante el mes de noviembre de 2017, mediante un hard fork destinado a duplicar el tamaño de los bloques. Sin embargo, los pequeños bloqueadores se opusieron rotundamente a esta actualización, sobre todo porque se trataba de un hard fork sin todos los mecanismos de seguridad necesarios. Una nueva campaña de comunicación, denominada» NO 2X », surgió luego para evitar este aumento en el tamaño de los bloques. El 8 de noviembre, la bifurcación dura fue finalmente abandonada en el último momento, debido a la falta de consenso y ante el rechazo de la comunidad. Con frecuencia se considera que esta fecha marca el final de la guerra de Blocksize.
Es innegable que este episodio de la Guerra del Tamaño de Bloques dejó una huella en la comunidad de Bitcoin. Lo que comenzó como un simple debate técnico se convirtió gradualmente en un conflicto que podría haber puesto en peligro la existencia misma de Bitcoin, o al menos debilitarla significativamente. Este período también influyó profundamente en la forma en que se diseñaron las evoluciones de los protocolos: hoy en día, la mayoría de los bitcoiners prefieren un enfoque cauteloso y conservador en cuanto a las actualizaciones, prefiriendo los soft forks en vez de los hard forks, aunque eso complique el proceso. Además, la ideología de los pequeños bloqueadores es ahora ampliamente aceptada por los usuarios.
La guerra de Blocksize también sentó un precedente, al demostrar que la UASF podría ser una poderosa herramienta disuasoria que permitiera a los usuarios mantener su poder frente a los mineros y los principales actores de la industria.
Para profundizar en este tema de Blocksize War, te aconsejo que leas el libro La guerra del tamaño de un bloque de Jonathan Bier, con quien escribí este artículo.
.png)
.png)
.png)
.png)
.png)
.png)
