La hoja de ruta de desarrollo de THORChain acaba de reestructurarse en torno a un único hito ineludible: la actualización THORChain v3.20. Un problema de consenso descubierto durante la rotación de bóvedas ha obligado a la red a pausar todo el churning, y hasta que se publique la v3.20, esa pausa se mantiene. Lo que comenzó como una modesta versión puntual se ha convertido en un despliegue mayor que incluye parches de seguridad, la tan esperada integración de Monero y un nuevo router V6. Este es el lanzamiento más trascendental en el calendario a corto plazo de THORChain.
Summary
Puntos clave
- La rotación de bóvedas (churn) de THORChain está en pausa hasta que se publique la v3.20, debido a un error de consenso desencadenado durante el churning.
- El parche v3.19.4 planificado se ha incorporado a v3.20, que también incluye la integración de Monero y el despliegue del router V6.
- El exploit reciente se originó en tres errores antiguos encadenados: cada uno inofensivo por sí solo, peligrosos en conjunto.
- Maya Protocol siguió procesando swaps durante toda la pausa de THORChain ejecutando una única bóveda verificada como sana.
- Moca está lanzando una beta discreta de punto de venta cripto, liquidando pagos a través de Maya Protocol y THORChain.
Churn de THORChain en pausa hasta el lanzamiento de v3.20
La rotación de bóvedas es uno de los mecanismos de seguridad más fundamentales de THORChain, y ahora mismo no se está ejecutando. Un problema de consenso aparece específicamente durante el proceso de churning, y la solución requiere cambios lo suficientemente profundos en Thornode como para que una versión puntual simplemente no pueda incluirlos. Eso descartó el parche v3.19.4 originalmente planificado el mismo día en que se discutió.
El equipo se reunió para preparar la v3.20 en su lugar, apuntando a una altura de actualización para la semana siguiente. Una vez que se publique la versión, el plan es reactivar primero Solana y luego restaurar el churning. Todo lo que se había previsto para v3.19.4 —incluido el trabajo de Monero— ahora se integra en esa única versión más grande junto con el nuevo código del router V6, que ya está listo y se está desplegando progresivamente. Para los usuarios, la experiencia tras la actualización sigue siendo la misma: los swaps se enrutan a través de THORChain Swap con normalidad.
La consolidación no es puramente reactiva. Agrupar múltiples mejoras en un único lanzamiento coordinado limita el número de veces que la red debe pasar por una secuencia de actualización de alto riesgo, lo cual importa mucho cuando la capacidad de los revisores ya está al límite.
Causa raíz del exploit: tres errores, una cadena
El exploit reciente no provino de un único fallo catastrófico. Según Aaluxx, cofundador de Maya Protocol y ahora desarrollador sénior en THORChain, la vulnerabilidad fue una combinación de tres errores antiguos que habían coexistido sin causar daño en la base de código hasta que alguien —o algo— descubrió que podían desencadenarse en secuencia.
«Fueron tres errores que, encadenados, eran explotables. Cualquiera de ellos individualmente era inofensivo.» — Aaluxx
Describió la mañana en que se produjo el exploit como helada. El equipo había fusionado recientemente parches de TSS desde un repositorio privado, y su temor inmediato fue que un error en esa fusión hubiera introducido la vulnerabilidad. Una comprobación rápida lo descartó: el commit estaba intacto y la causa raíz se remontaba a código mucho más antiguo. De hecho, el equipo había detectado un error encadenado similar —un posible doble gasto— apenas un par de meses antes, lo que significa que el patrón subyacente ya estaba en el radar.
Cómo detectó el equipo la bóveda comprometida
La detección fue técnicamente elegante. Al factorizar uno de los parámetros criptográficos de la configuración TSS y escanear en busca de números primos pequeños que no deberían estar presentes, los desarrolladores podían identificar si una bóveda determinada había sido envenenada. En THORChain, se descubrió que una de cinco bóvedas estaba comprometida, lo que explica por qué se drenó aproximadamente el 20% del TVL en lugar del monto total. El método proporcionó al equipo un diagnóstico fiable en una situación en la que la rapidez del triaje era crítica.
Aaluxx fue directo sobre la lección más amplia respecto al papel de la IA de cara al futuro: un equipo pequeño ahora puede explorar una base de código desde muchos más ángulos simultáneamente, lo que es una ventaja defensiva, pero la misma capacidad está disponible para cualquiera que intente encontrar vulnerabilidades desde fuera. Espera unos cuantos meses difíciles más mientras la industria se adapta a esa nueva realidad.
Resiliencia de Maya Protocol durante el tiempo de inactividad
Durante aproximadamente el mes en que THORChain estuvo en pausa, Maya Protocol siguió realizando swaps. El mismo error latente existía en la base de código de Maya, pero nunca se desencadenó. Más importante aún, Maya estaba ejecutando una única bóveda que el equipo podía verificar de forma independiente como sana, por lo que la mantuvieron operativa mientras pausaban el churning como medida de precaución, ya que un churn podría haber abierto la misma vía de explotación.
La consecuencia práctica fue real: los swaps nativos BTC-a-ETH permanecieron indisponibles en THORChain durante ese periodo, pero siguieron disponibles en Maya. Ese es el argumento de la redundancia hecho concreto.
«Necesitamos volar el jet con dos motores.» — Aaluxx
Tras el exploit y durante el periodo TCY anterior, algunas voces defendieron fusionar THORChain y Maya, usando RUNE para comprar CACAO y consolidar todo en un único DEX más grande. Aaluxx reconoció que habría sido una decisión empresarial razonable y aun así la rechazó. Dos DEX independientes y sin permisos que comparten los mismos ideales son una elección de diseño deliberada, no una ineficiencia que haya que optimizar. El coste de la redundancia es real, pero también lo es el coste de un único punto de fallo.
Cuellos de botella de desarrollo y reformas de gobernanza
La restricción que ralentiza la velocidad de lanzamiento de THORChain no es la falta de código. Es la falta de personas cualificadas para revisarlo y desplegarlo.
«Nuestro factor limitante no es la creación de código, es la revisión y el despliegue.» — Aaluxx
Actualmente, solo alrededor de tres personas tienen la profundidad de experiencia necesaria para revisar y desplegar cambios para THORChain. Añadir más desarrolladores o más pull requests no acelera automáticamente la entrega: añade carga de revisión a un cuello de botella ya estrecho. El equipo opera con una proporción deliberada de dos a uno: cada pieza de código escrita requiere al menos dos revisiones antes de avanzar.
Propuesta para reformar el proceso de ADR
En el lado de la gobernanza ha surgido un problema estructural. Con propuestas que ahora provienen de muchos colaboradores en lugar de un único organismo coordinador como Nine Realms, los números de ADR han colisionado y se han presentado ideas poco maduras como ADR formales antes de que estuvieran listas para construirse.
La solución propuesta es separar por completo la fase de idea de la fase de ADR. Un ADR, tal como lo planteó Aaluxx, ya debería ser una receta terminada: concisa, técnica y construible con los recursos disponibles. Lo que falta es un espacio previo —una especie de campo de batalla— donde las ideas en bruto se cuestionen, refinen o descarten antes de que califiquen para el estatus de ADR.
«Algunas personas piensan que ‘quiero pasta’ es un ADR. Eso no es un ADR, eso es un problema. Ven a nosotros con una receta.» — Aaluxx
Más adelante, los números de ADR podrían solicitarse y asignarse on-chain a través del relay de nodos, con el primer nodo aprobador asignando el siguiente número secuencial. Eso haría que la propiedad de una propuesta fuera inequívoca sin crear un guardián centralizado. Conviene repetirlo: un ADR no es un requisito previo para publicar código; cualquiera puede abrir issues y pull requests en GitLab hoy. Un ADR es una toma de temperatura que indica a los operadores de nodos si quieren que se dedique tiempo de desarrollador remunerado a algo.
Integraciones del ecosistema y nuevas funciones
A pesar de la pausa, las integraciones en todo el ecosistema siguieron avanzando. ShapeShift se ha unido ahora a Symbiosis como participante activo en el modelo de comisiones dinámicas, y los datos que están devolviendo ambos están resultando útiles. Se espera que tres o cuatro afiliados más se conecten en el plazo de una semana, a la espera de la disponibilidad de Chad Barraford para finalizar las integraciones.
Un aviso de la comunidad reabrió dos conversaciones de integración más grandes. Un mensaje directo frío a Randy Bechtold sacó a la luz Robinhood Chain como posible objetivo, y una mirada rápida reveló que está construida sobre Arbitrum, una red que THORChain ya había estado persiguiendo. Eso creó una oportunidad dos por uno: Bechtold tiene una llamada programada con el equipo de Arbitrum y planea pedir una presentación cálida con Robinhood durante la misma.
Aaluxx ofreció una nota técnica de precaución sobre Arbitrum: funciona a aproximadamente cuatro bloques por segundo, lo que inunda a los nodos con volumen de mensajes de una forma similar a Solana. Maya pasó alrededor de un año estabilizando su propio soporte de Arbitrum. La ventaja es que el trabajo duro está en gran medida hecho del lado de Maya, lo que da a THORChain un camino más corto.
Integración de Monero cerca del lanzamiento tras la auditoría de Least Authority
La integración de XMR es la función importante más cercana a su publicación. Aaluxx está en conversaciones con Least Authority para una auditoría de seguridad, una firma a la que considera entre las mejores para trabajo en cadenas de privacidad. Hay un precedente directo: Zcash financió una auditoría de Least Authority de su integración ZEC-hacia-Maya, que se completó recientemente con solo hallazgos menores de denegación de servicio y de calidad de vida, sin errores graves. El trabajo de Monero ya ha superado las pruebas chain-net y una revisión de desarrollador.
Fiel al enfoque habitual del protocolo, el pool de XMR se lanzará primero con liquidez superficial propiedad del protocolo y pequeños swaps de prueba, manteniendo los fondos de los usuarios fuera de escena mientras el cliente de la cadena se pone a prueba en producción.
«Rompe cosas, pero rómpelas en pequeño.» — Aaluxx
ZEC del lado de THORChain no tiene cronograma. El cuello de botella es la capacidad: reembolsos, trabajo de seguridad, el reinicio de la red y el lanzamiento de Monero compiten todos por la misma estrecha ventana de revisión y despliegue, y los churns tienen prioridad.
Moca lanza beta de punto de venta cripto a través de Maya y THORChain
El ángulo de pagos del ecosistema recibió su propia actualización. Moca, una red de punto de venta y pagos en cripto, liquida transacciones a través de Maya Protocol, THORChain y otros pocos backends. El objetivo es permitir que comerciantes ordinarios acepten cripto y liquiden en cripto sin fricción, con volumen del mundo real fluyendo de vuelta a través de los protocolos como resultado.
La beta es deliberadamente discreta, con lanzamiento previsto para el lunes de la semana siguiente, sin impulso de marketing al principio. El plan es abrir cuentas de empresa, recopilar comentarios, ejecutar pagos de prueba reales y cerrar errores antes de un despliegue más amplio.
«El lado de pagos de Maya ya está sobre nosotros.» — EricOnchain, Moca
Los constructores interesados en acceso temprano a la API pueden contactar directamente con EricOnchain o con la cuenta de Moca.
Lo que une todo esto es una red en un auténtico punto de inflexión. v3.20 no es solo un parche de seguridad: es la versión que restaura el churning, pone a Monero en producción, despliega el router V6 y prepara el terreno para las expansiones de Arbitrum y ShapeShift que le seguirán. La limpieza con la que se publique, y el resultado de la auditoría de Least Authority, dirán mucho sobre si la narrativa de recuperación de THORChain se sostiene bajo el peso de lo que está prometiendo.
FAQ
¿Por qué está pausada la operación de churn de THORChain?
Un problema de consenso específicamente vinculado al proceso de churning requiere correcciones a nivel de Thornode. Esos cambios son demasiado profundos para incluirlos en una versión puntual, por lo que la rotación de bóvedas permanece en pausa hasta que se despliegue la actualización completa v3.20.
¿Qué causó el exploit reciente de THORChain?
Tres errores antiguos que eran inofensivos de forma aislada se volvieron explotables cuando se desencadenaron en secuencia. La combinación permitió que una de las cinco bóvedas de THORChain fuera comprometida, lo que resultó en que se drenara aproximadamente el 20% del TVL.
¿Cómo mantuvo Maya Protocol los swaps durante el tiempo de inactividad de THORChain?
Maya estaba ejecutando una única bóveda que el equipo podía verificar de forma independiente como no comprometida. Al mantener esa bóveda operativa —mientras pausaba el churning como medida de precaución—, Maya siguió procesando swaps durante todo el mes de pausa de THORChain.
¿Cuál es el estado de la integración de Monero en THORChain?
La integración de XMR ha superado las pruebas chain-net y una revisión de desarrollador. Se está organizando una auditoría con Least Authority, y el pool se lanzará con liquidez superficial propiedad del protocolo y pequeños swaps de prueba para limitar la exposición durante la fase inicial.
{«@context»:»https://schema.org»,»@type»:»FAQPage»,»mainEntity»:[{«@type»:»Question»,»name»:»¿Por qué está pausada la operación de churn de THORChain?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Un problema de consenso específicamente vinculado al proceso de churning requiere correcciones a nivel de Thornode. Esos cambios son demasiado profundos para incluirlos en una versión puntual, por lo que la rotación de bóvedas permanece en pausa hasta que se despliegue la actualización completa v3.20.»}},{«@type»:»Question»,»name»:»¿Qué causó el exploit reciente de THORChain?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Tres errores antiguos que eran inofensivos de forma aislada se volvieron explotables cuando se desencadenaron en secuencia. La combinación permitió que una de las cinco bóvedas de THORChain fuera comprometida, lo que resultó en que se drenara aproximadamente el 20% del TVL.»}},{«@type»:»Question»,»name»:»¿Cómo mantuvo Maya Protocol los swaps durante el tiempo de inactividad de THORChain?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»Maya estaba ejecutando una única bóveda que el equipo podía verificar de forma independiente como no comprometida. Al mantener esa bóveda operativa —mientras pausaba el churning como medida de precaución—, Maya siguió procesando swaps durante todo el mes de pausa de THORChain.»}},{«@type»:»Question»,»name»:»¿Cuál es el estado de la integración de Monero en THORChain?»,»acceptedAnswer»:{«@type»:»Answer»,»text»:»La integración de XMR ha superado las pruebas chain-net y una revisión de desarrollador. Se está organizando una auditoría con Least Authority, y el pool se lanzará con liquidez superficial propiedad del protocolo y pequeños swaps de prueba para limitar la exposición durante la fase inicial.»}}]}
Artículo producido con la ayuda de inteligencia artificial y revisado por el equipo editorial.
