Bitcoin no ha logrado activar ningún soft fork propuesto desde que Taproot se lanzó en 2021, lo que llevó al creador de Drivechain, Paul Sztorc, a argumentar que la red no puede aprobar ninguna de esas actualizaciones en el futuro previsible.
Resumen
- BIP-110 atrajo un 2.53% de apoyo de mineros antes de que su rama de aplicación se estancara después de dos bloques.
- Paul Sztorc dijo que todos los soft forks propuestos desde Taproot han fallado en activarse.
- Drivechains colocaría reglas experimentales en cadenas separadas, pero requeriría primero un cambio en el consenso de Bitcoin.
- Sztorc dijo que los ingresos por comisiones de las sidechains influirían en el incentivo de los mineros para proteger los retiros de Drivechain.
Paul Sztorc, CEO de LayerTwo Labs y creador de la propuesta Drivechain, dijo a crypto.news que la fallida activación de BIP-110 apunta a un problema que se extiende mucho más allá de una disputada actualización de Bitcoin.
“Todos los soft forks desde Taproot han fallado en activarse, y este no fue la excepción”, dijo Sztorc.
Su evaluación siguió al colapso de BIP-110, un soft fork temporal propuesto que buscaba restringir algunas formas de datos no financieros almacenados en transacciones de Bitcoin. La propuesta solo atrajo 51 bloques de apoyo durante un período de dificultad de 2,016 bloques, dejando la señalización de mineros en 2.53%.
Los nodos de aplicación de BIP-110 luego se separaron de la red dominante de Bitcoin en el bloque 961,632 el 8 de agosto. La nueva rama produjo solo dos bloques antes de estancarse, mientras que la cadena principal continuó procesando bloques a su ritmo habitual.
El fallo de BIP-110 apunta a un proceso de actualización de Bitcoin congelado
El resultado de BIP-110 mostró lo difícil que se ha vuelto para los desarrolladores asegurar apoyo para cambios en las reglas de consenso de Bitcoin, según Sztorc.
El proceso de activación voluntaria de la propuesta requería que el 55% de los bloques señalaran apoyo. Para el 2 de agosto, el objetivo se había vuelto matemáticamente inalcanzable porque solo 28 de los primeros 1,108 bloques habían señalado, según datos anteriores de mineros.
Su software de aplicación aún entró en un período de señalización obligatorio en el bloque 961,632. Los nodos que ejecutaban BIP-110 luego rechazaron bloques que no señalaban apoyo, aunque la mayoría de los mineros continuaron construyendo sobre la cadena de Bitcoin sin aplicación.
Para el 9 de agosto, la rama minoritaria permanecía congelada en el bloque 961,633 mientras la cadena principal avanzaba 111 bloques por delante. El endpoint BIP-110 de OCEAN mostró aproximadamente 257 petahashes por segundo asignados a la rama en ese momento, mientras que el presidente ejecutivo de Strategy, Michael Saylor, estimó que alrededor del 99.85% del poder de hash de Bitcoin había permanecido con la cadena dominante.
El estancamiento de la cadena de dos bloques se volvió más severo porque la rama heredó la dificultad de minería de Bitcoin de 127.48 billones. Sin suficiente poder computacional, sus mineros no pudieron producir rápidamente los bloques restantes requeridos para alcanzar un ajuste de dificultad.
BIP-110, formalmente llamado el Softfork Temporal de Datos Reducidos, propuso siete restricciones de consenso que durarían 52,416 bloques, o aproximadamente un año a la tasa normal de bloques de Bitcoin. Las reglas incluían un límite de 83 bytes en las salidas OP_RETURN, un límite de 256 bytes en ciertos empujes de datos, y restricciones que afectaban algunas funciones de Taproot.
Los partidarios, incluido el mantenedor de Bitcoin Knots, Luke Dashjr, argumentaron que las restricciones reducirían el almacenamiento arbitrario de datos vinculado a inscripciones y mantendrían a Bitcoin enfocado en transacciones monetarias. Críticos como Saylor y el cofundador de Blockstream, Adam Back, dijeron que la propuesta podría socavar la neutralidad de Bitcoin al rechazar estructuras de transacción que la red actualmente acepta.
Incluso OP_CAT enfrenta la misma barrera de consenso de Bitcoin
Sztorc dijo que BIP-110 no fue un fallo aislado, señalando la falta de activación de otros soft forks propuestos desde Taproot.
Taproot se activó en el bloque 709,632 el 14 de noviembre de 2021, después de que los mineros usaran el proceso de Speedy Trial para señalar preparación. La actualización introdujo firmas Schnorr y nuevas reglas de gasto de Taproot sin forzar a los nodos no actualizados a una blockchain separada.
Desde entonces, las propuestas que buscan agregar características o cambiar las reglas de scripting de Bitcoin han permanecido en discusión sin activación. Sztorc citó OP_CAT como ejemplo, describiéndolo como un pequeño cambio de código que apareció en el software original de Bitcoin y ha atraído apoyo de desarrolladores.
"Nada puede — ni siquiera OP_CAT, que son solo 13 líneas de código y estaba en el software original y tenía mucho apoyo", dijo cuando se le preguntó cómo BIP 300 podría superar la resistencia a los cambios de consenso.
"Bitcoin no puede activar ningún soft fork, en el futuro previsible."
OP_CAT permitiría a los scripts de Bitcoin unir dos elementos de datos. Satoshi Nakamoto deshabilitó la operación en 2010 por preocupaciones de seguridad, pero una propuesta posterior buscó restaurarla mediante un soft fork compatible con versiones anteriores.
Los partidarios dicen que el opcode podría ayudar a los desarrolladores a crear covenants, vaults, puentes y otras condiciones de gasto programables. Sin embargo, la propuesta de OP_CAT aún depende de la revisión técnica y de un acuerdo suficiente entre los desarrolladores de Bitcoin, los mineros, los operadores de nodos y los usuarios.
Otras propuestas enfrentan el mismo problema de coordinación. BIP-360, por ejemplo, propone un nuevo tipo de salida diseñado para admitir firmas post-cuánticas mediante un soft fork. Sus autores presentan el diseño como un posible camino para que los usuarios muevan fondos a direcciones resistentes a la computación cuántica, aunque la activación requeriría el tipo de acuerdo de red que Sztorc dice que Bitcoin ya no puede lograr.
Las Drivechains alejarían la experimentación de la capa base de Bitcoin
Las Drivechains están diseñadas para permitir a los desarrolladores probar diferentes reglas y aplicaciones en sidechains opcionales en lugar de buscar cambios repetidos en la capa base de Bitcoin.
Según BIP 300, los usuarios podrían mover BTC entre Bitcoin y sidechains separadas mediante un anclaje bidireccional. Cada sidechain podría aplicar sus propias reglas, permitiendo a los desarrolladores probar sistemas de privacidad, contratos inteligentes, transacciones más rápidas u otras funciones sin requerir que cada usuario de Bitcoin las adopte.
Las sidechains también mantendrían marcas y software separados, lo que Sztorc comparó con sistemas existentes como Liquid y Lightning. Los usuarios podrían elegir si mover fondos a una cadena en particular, mientras que las reglas base de Bitcoin permanecerían sin cambios después de la actualización inicial de Drivechain.
Cuando se le preguntó si múltiples Drivechains podrían fragmentar la liquidez y dejar a los usuarios inseguros sobre qué implementaciones confiar, Sztorc comparó el modelo con desarrolladores que lanzan altcoins separadas.
"Cada Drivechain tendrá su propia marca, igual que Liquid, Lightning, etc.", dijo.
Las Drivechains aún enfrentarían el mismo obstáculo inmediato identificado en la evaluación de Sztorc: BIP 300 en sí mismo necesita un cambio de consenso en Bitcoin. Sin activación, los desarrolladores no pueden implementar su sistema de retiro propuesto como parte de las reglas de la red.
"No puede", dijo Sztorc cuando se le preguntó cómo BIP 300 podría superar la resistencia que detuvo otras propuestas.
El control de los mineros sigue siendo la disputa de seguridad central de Drivechain
BIP 300 asignaría a los mineros de Bitcoin un papel importante en la aprobación de retiros de Drivechains, un arreglo que ha generado preocupaciones sobre robo, censura y colusión de mineros.
Según la propuesta, las solicitudes de retiro permanecerían pendientes mientras los mineros votan sobre ellas a través de bloques de Bitcoin. Una solicitud que reciba suficiente apoyo durante el período de votación requerido podría liberar BTC del anclaje de la sidechain.
Sztorc dijo que el modelo de seguridad depende en parte del valor económico que una sidechain popular crea para los mineros.
"Si la cadena es popular, generará tarifas para los mineros. Si estos ingresos por tarifas son grandes, en relación con el número de monedas en circulación en la L2, entonces será segura."
Por lo tanto, los usuarios necesitarían evaluar la relación entre los ingresos por tarifas de la sidechain, los incentivos de los mineros y el valor del BTC mantenido dentro del anclaje. Los críticos argumentan que los mineros podrían coordinarse para aprobar un retiro inválido, mientras que los partidarios sostienen que atacar una sidechain rentable podría destruir futuros ingresos por tarifas y dañar la confianza en el sistema.
Para los participantes estadounidenses, BIP-110 ya demostró cómo las operaciones mineras estadounidenses pueden involucrarse en disputas de gobernanza de Bitcoin. Foundry USA Pool pidió a los clientes mineros que votaran sobre la señalización de BIP-110 antes del período obligatorio, mientras que Strategy, una empresa que cotiza en EE. UU. y uno de los mayores tenedores corporativos de Bitcoin, se opuso públicamente a la propuesta a través de Saylor.
La bifurcación fallida también creó un riesgo práctico para los tenedores porque BIP-110 no incluía protección automática contra repetición. El desarrollador de Bitcoin Kevin Loaec advirtió que una transacción enviada en una rama podría potencialmente copiarse a la otra, poniendo en riesgo las monedas previas a la bifurcación si los usuarios intentaban mover o vender activos en la cadena minoritaria sin separarlos primero.
Los partidarios de BIP-110 también prepararon código para un posible cambio de prueba de trabajo, lo que permitiría a la rama estancada abandonar el algoritmo de minería existente de Bitcoin. El código incluía un tiempo de bifurcación dura configurable, aunque el desarrollador Chris Guida lo describió como una contingencia y no había establecido una fecha de activación.
