¿Por primera vez en cuatro años, Bitcoin podría enfrentar una «bifurcación suave liderada por los usuarios»?

La comunidad base de Bitcoin ha comenzado a promover cambios en el software subyacente de Bitcoin, algo poco común en más de cuatro años.

Escrito por: GaryMa 吴说区块链

Según informa Blockspace, la comunidad básica de Bitcoin ha comenzado a impulsar cambios en el software subyacente de Bitcoin, algo poco común en más de cuatro años (cambios significativos en el fondo anteriormente eran liderados por el grupo de desarrolladores principales).

Esta vez, el apoyo a nivel básico está surgiendo para dos propuestas de mejora de Bitcoin (BIP), a saber, BIP-119 (CTV) y BIP-348 (CSFS). Estas dos propuestas presentan una nueva forma de escribir scripts de Bitcoin, que permitirá a Bitcoin implementar la funcionalidad de “contratos” (Covenants). Estas dos propuestas podrían implementarse en la próxima bifurcación suave de Bitcoin.

Para evitar que algunos lectores no comprendan temporalmente la relación entre los Covenants de Bitcoin y estos específicos planes BIP, aquí aclaramos lo siguiente:

En términos simples, los Covenants son un concepto funcional en la red de Bitcoin, y los dos BIP mencionados en el texto son diferentes enfoques para implementar este concepto funcional.

¿Qué son los Covenants de Bitcoin?

Definición:

Covenants es un mecanismo propuesto en el protocolo de Bitcoin que permite establecer condiciones o restricciones en las transacciones, especificando cómo se puede gastar o transferir Bitcoin. Estas condiciones pueden abarcar múltiples transacciones, limitando la forma en que se puede gastar en el futuro, lo que mejora la funcionalidad del script de Bitcoin.

Función:

• Mejorar la capacidad de los contratos inteligentes de Bitcoin, apoyando aplicaciones más complejas (como préstamos, intercambios descentralizados, bóvedas).
• Aumentar la seguridad para prevenir el robo o uso indebido de fondos.
• Optimizar el rendimiento de la red, como reducir las tarifas de transacción o mejorar la privacidad.

Aquí podemos entender claramente que los Covenants son un concepto, y BIP-119 (CTV) y BIP-348 (CSFS) mencionados en este artículo son implementaciones específicas de este concepto funcional de Covenants.

Estado actual:

La red principal de Bitcoin actualmente no ha integrado oficialmente ninguna funcionalidad relacionada con Covenants, aunque las discusiones y propuestas relacionadas (como BIP-119) han avanzado durante años.

BIP 119: OP_CHECKTEMPLATEVERIFY (CTV)

Un código de operación propuesto para Bitcoin que permite a las salidas de la transacción especificar una “plantilla” (Template), exigiendo que las salidas de las transacciones de gasto posteriores deben coincidir con esa plantilla.

Propuesto por el anterior contribuidor principal de Bitcoin, Jeremy Rubin, ha existido por más de cinco años. Implementa la funcionalidad de “llevar estado” al restringir que los fondos solo puedan gastarse de la manera predefinida.

Los escenarios de aplicación incluyen:

• Crear pagos en lote (Batch Payments) para reducir las tarifas de transacción. Construir un intercambio descentralizado (DEX) o un protocolo de préstamos.
• Implementar Vaults (bóvedas) para proteger los fondos de robos.
• CTV es una implementación ligera de Covenants, que se centra en las restricciones de formato de salida, sin involucrar lógica compleja.

BIP 348：OP_CHECKSIGFROMSTACK (CSFS)

Un código de operación propuesto para Bitcoin que permite verificar si una firma es válida para cualquier mensaje (Message), y no solo para el hash de la transacción actual. Toma la firma, la clave pública y el mensaje de la pila de datos y verifica si la firma coincide.

Propuesto oficialmente por Jeremy Rubin y Brandon Black en noviembre de 2024.

OP_CSFS es una poderosa herramienta para implementar Covenants más flexibles, ya que permite la “introspección” de las entradas de la transacción, es decir, examinar el contenido o estado completo de la transacción firmada.

Aplicaciones específicas:

• Implementación de Covenants: OP_CSFS se puede utilizar para crear lógica condicional compleja, asegurando que los fondos solo se puedan gastar de acuerdo con reglas específicas. Por ejemplo, los validadores pueden verificar si las entradas de la transacción cumplen con plantillas o restricciones predefinidas.
• Mejora de la seguridad: soporte para Vaults y protocolos descentralizados, previniendo robos o gastos no autorizados a través de la verificación de firmas.
• Escalabilidad: en combinación con otros códigos de operación (como OP_CAT), se pueden construir contratos inteligentes más complejos.

Y al mencionar los Covenants de Bitcoin y las propuestas BIP-119 (CTV) y BIP-348 (CSFS), no se puede pasar por alto OP_CAT.

BIP 347: OP_CAT

Historia:

Existencia temprana: OP_CAT es parte del lenguaje de script original de Bitcoin, incluido por Satoshi Nakamoto en el lanzamiento de Bitcoin en 2009. Fue diseñado originalmente para mejorar la flexibilidad de los scripts y soportar lógica más compleja.

Razón para la eliminación (2010):

• OP_CAT fue eliminado (deshabilitado) en 2010, debido a la prevención de posibles vulnerabilidades de seguridad y el abuso de recursos.
• Problema específico: si no hay restricciones, OP_CAT puede ser utilizado por usuarios malintencionados para generar datos de longitud infinita (a través de llamadas recursivas), lo que lleva a un “ataque de denegación de servicio” (DoS Attack), ya que los nodos de Bitcoin necesitan procesar estos datos, aumentando los costos de cálculo y almacenamiento.
• En ese momento, el lenguaje de script de Bitcoin fue simplificado, manteniendo las funciones más básicas, asegurando la ligereza, la seguridad y la descentralización del protocolo.

Definición y función:

OP_CAT es un código de operación (Opcode) del lenguaje de script de Bitcoin, no es una implementación directa de Covenant, pero es una herramienta potencial para construir lógica Covenant compleja. En comparación con los dos códigos de operación anteriores, OP_CAT es más versátil, adecuado para operaciones de datos, pero necesita combinarse con otros códigos de operación para lograr funciones complejas.

Estado actual:

La comunidad de Bitcoin ha vuelto a discutir el regreso de OP_CAT en los últimos años, que anteriormente apareció en forma de la propuesta BIP-420 con un enfoque más lúdico para la comunidad, pero que ahora se ha fusionado oficialmente en el repositorio bitcoin/bips bajo el número BIP-347.

¿Cómo va el progreso?

Según Coindesk, en las últimas semanas, muchos desarrolladores de Bitcoin occidentales han expresado su apoyo a CTV y CSFS en Twitter — — esto sin duda es una señal fuerte que indica que al menos en el círculo de las redes sociales, parte de la comunidad de Bitcoin está avanzando hacia la aceptación de estos cambios.

Además, los desarrolladores generalmente consideran que la definición de estas dos propuestas es “estrecha”. En términos simples, esto significa que, una vez activadas, la posibilidad de que sean abusadas accidentalmente por los usuarios es baja. La comunidad de desarrolladores de Bitcoin siempre ha tenido una actitud cautelosa hacia los cambios en Bitcoin. Por ejemplo, aunque BIP 119 ha estado en espera durante casi cinco años, hace poco CTV aún se consideraba demasiado radical para ser activado.

Los cofundadores de estas dos propuestas, Jeremy Rubin, enfrentaron una fuerte oposición en sus esfuerzos anteriores por promover CTV, especialmente por las críticas de algunos líderes de opinión en Bitcoin con muchos seguidores, como Adam Back y Jimmy Song. Las diversas críticas finalmente se convirtieron en un amplio descontento dentro de la comunidad de Bitcoin, lo que llevó a Rubin a retirarse del campo de Bitcoin.

Entonces, ¿qué ha causado exactamente este cambio? La reciente promoción del opcode OP_CAT parece haber ampliado el rango de propuestas de Bitcoin que se consideran “aceptables”, enmarcando CTV y CSFS como opciones relativamente “conservadoras”. Es notable que la mayoría de las personas que apoyan OP_CAT también apoyan BIP 119 y BIP 348 (así como la mayoría de las otras propuestas).

¿Qué podemos esperar a continuación? Primero, la discusión continuará. Se espera que los desarrolladores exploren más estas propuestas en varias conferencias técnicas, como OPNEXT programada para abril, BTC++ en julio y TABConf en octubre. Una vez que los desarrolladores alcancen un consenso preliminar, la activación real del soft fork se trasladará a los mineros, la comunidad y los inversores para la confirmación final.

¿Cómo seguir el progreso de la discusión de los BIPs en la comunidad / el proceso de bifurcación suave?

¡La respuesta es muy difícil!

La comunidad técnica de Bitcoin suele tener discusiones profundas sobre estas propuestas. Pero este es un proceso de discusión que parece oscuro y cíclico.

En términos simples, el proceso de bifurcación suave de Bitcoin requiere estimar aproximadamente el grado de apoyo de las partes interesadas de Bitcoin, incluyendo desarrolladores, custodios, inversionistas y mineros. El indicador de apoyo más directo generalmente proviene de los mineros, ya que pueden indicar su aprobación de los cambios en el código enviando señales en los bloques que extraen. Normalmente, Bitcoin Core requiere que el 95% de los bloques emitan señales de apoyo durante un período de tiempo antes de que se bloquee la actualización para su activación.

Sin embargo, no hay un consenso claro sobre cómo definir el “apoyo generalizado”, y el consenso de Bitcoin sigue evolucionando constantemente. Los mineros se han convertido en importantes proveedores de señales, simplemente porque son una entidad “contable” en la red de Bitcoin. En otras palabras, debido a la estructura descentralizada de Bitcoin, es difícil medir el consenso general desde una perspectiva “visible”.

Sin embargo, una desarrolladora famosa por sus NFT de Bitcoin, Taproot Wizards, utiliza OP_CAT como ejemplo para revelar, a través de un diagrama de flujo, el largo y complejo proceso de la bifurcación suave de Bitcoin. Los lectores interesados pueden consultarlo por sí mismos; aquí intentaremos resumirlo un poco:

Ciclo de vida de las propuestas BIPs | El largo y complejo proceso de bifurcación suave de Bitcoin

1. La propuesta fue presentada y discutida inicialmente en la lista de correo de desarrolladores de Bitcoin.

2. Entrar en una discusión más amplia de la comunidad, se ha entrado en un dilema de discusión a largo plazo sobre las ventajas y desventajas de la función de propuestas; si no se puede avanzar más, se quedará aquí.

3. Las comunidades de base redactan el borrador del BIP para la propuesta en Github.

4. Los desarrolladores comienzan a implementar el código relacionado, deben tener un Bug de auditoría a largo plazo resuelto para poder continuar.

5. Después de la revisión por parte de los editores del almacén de Bitcoin BIP y el reconocimiento preliminar de la comunidad, se asigna un número BIP oficial.

6. Entrar en la red de prueba Signet. Signet es una red de prueba de Bitcoin que permite a los desarrolladores experimentar con nuevas funciones o cambios de código sin afectar la red principal. (Es posible que la mayoría de las nuevas funciones se queden permanentemente en este paso.)

7. Posible entrada en la cadena lateral Liquid para experimentación.

8. Enviar PR a Bitcoin Core.

9. Ingresar al proceso de revisión del código principal de Bitcoin y fusión de propuestas, con alta incertidumbre. Solo si se evitan la mayoría de las objeciones y se cumplen los requisitos técnicos (sin errores graves) la propuesta tiene la oportunidad de entrar en la fase de fusión; la opinión de desarrolladores clave (como Pieter Wuille) suele ser crucial, recibir aprobación o rechazo puede afectar enormemente el destino de la propuesta.

10. Si la revisión del código no presenta problemas, espera a que los mantenedores del repositorio de Bitcoin fusionen la PR en el proyecto principal. Actualmente hay cinco mantenedores: Michael Ford (fanquake), Hennadii Stepanov (hebasto), Andrew Chow (achow101), Gloria Zhao (glozow), Ryan Ofsky (ryanofsky).

11. Continúan las posibles controversias y discusiones entre diferentes grupos, como los desarrolladores de Bitcoin y los mineros.

12. Elegir mecanismo de activación:

a. Bifurcación suave liderada por mineros (MASF): activada por los mineros a través de una señal (generalmente un umbral del 95%), como el modo predeterminado de BIP-9 o BIP-8. Es más estable, pero requiere coordinar un amplio consenso y pruebas, por lo que toma más tiempo;

b. Bifurcación suave impulsada por el usuario (UASF): activación forzada de nuevas reglas (como “Lockinontimeout: True” de BIP-8) por parte de los operadores de nodos (usuarios), eludiendo la resistencia de los mineros, con riesgos potenciales de bifurcación de cadena y desacuerdos dentro de la comunidad.

Conclusión

Wu dijo que anteriormente había informado que el mantenedor del dominio Bitcoin.org, Cobra, advirtió que en 2025 la red de Bitcoin podría enfrentar un soft fork liderado por los usuarios (UASF) iniciado por desarrolladores anónimos fuera del núcleo de Bitcoin, refiriéndose en realidad a los cambios potenciales de BIP 119 mencionados en este artículo. Cobra cree que estas mejoras podrían provocar una división entre la “facción de conservación” y la “facción de mejora”, liderada por la comunidad de base y promovida por desarrolladores que no forman parte del núcleo de Bitcoin.

Se entiende que UASF (bifurcación suave dirigida por el usuario) es una actualización de protocolo iniciada por los usuarios de Bitcoin, al actualizar el software del nodo para hacer cumplir las actualizaciones de protocolo, incluso si los mineros u otras partes no lo admiten, por lo que también significa el riesgo de bifurcación de la cadena. Por supuesto, no hay necesidad de preocuparse por eso en este momento, después de todo, muchos aún no están resueltos. Por ejemplo, ¿las futuras bifurcaciones suaves solo contendrán CTV y CSFS? ¿Se tendrá en cuenta el OP_CAT, que a menudo se discute con este conjunto de códigos de operación? ¿Cómo se desarrollará el proceso real de activación de la bifurcación suave? ¿Prestarán suficiente atención otras partes interesadas, como los mineros de Bitcoin?

Después de todo, siempre que el consenso de los BIPs sea lo suficientemente grande, las propuestas impulsadas por la comunidad base también pueden llevarse a cabo en forma de bifurcación suave liderada por mineros (MASF). Además, incluso en el caso de UASF, ha habido casos de éxito en la historia. UASF jugó un papel clave en la actualización de SegWit de 2017, donde los usuarios impulsaron con éxito la bifurcación suave, evitando la bifurcación dura y promoviendo la expansión de Bitcoin.

Enlace de referencia: