Una actualización en Zcash desincronizó a todo su ecosistema

Múltiples exploradores de bloques, entre ellos Zcash Explorer, Blockchair, Block Explorer y 3xpl, no registran actividad en la red Zcash desde las 05:27 UTC del 3 de junio, cuando habría sido minado presuntamente el último bloque. Al cierre de esta nota, la cadena, según esos sitios, lleva más de 5 horas sin producir bloques nuevos.

Los datos del explorador Zcash Explorer muestran 97 transacciones sin confirmar en el mempool (la lista de operaciones pendientes que esperan ser incluidas en un bloque), algunas de ellas enviadas minutos antes de la publicación de esta nota. Mientras la cadena no procese bloques, esas transacciones no se acreditan.

Sin embargo, Mert Mumtaz, CEO y cofundador de Helius (una empresa de infraestructura de Solana), en respuesta a un usuario en X que reclamaba por la paralización de Zcash, explicó que la red no está paralizada: «No nos dimos cuenta porque es completamente falso. La red no está caída, el explorador está usando un nodo de mierda. Está funcionando perfectamente».

Los exploradores de bloques dependen de nodos para leer y mostrar el estado de la cadena, por lo que un nodo desactualizado o mal sincronizado podría mostrar la red detenida aunque el resto siga operando con normalidad. El fundador de Helius basó su afirmación en los datos del pool de minería Zecmining Pool, que reflejan que Zcash está operativa, como se ve en la siguiente imagen con bloques procesados recientemente:

Una actualización de Zcash del día anterior, en el fondo

El 2 de junio, el equipo de Zcash Open Development, mantenedor de la red, reconoció una vulnerabilidad en el pool Orchard (la capa de transacciones privadas más moderna de Zcash) y aplicó una actualización de emergencia a nivel del protocolo, como lo notificó CriptoNoticias.

Según un analista de criptomonedas conocido en X como Railgoon, lo ocurrido hoy 3 de junio en los exploradores que reflejan la red detenida tiene una explicación directa en esa secuencia: mineros y desarrolladores habrían congelado el pool Orchard (que concentra cerca del 31% del suministro total de ZEC, unos 4,5 millones de los 16,7 millones de monedas en circulación) para evitar que la vulnerabilidad fuera explotada antes de que la corrección estuviera lista, y luego ejecutaron una bifurcación dura del protocolo.

Railgoon sostuvo que Zcash estuvo «parcialmente detenida de forma intencional» y que al momento de su publicación ya se había recuperado.

La desincronización que muestran múltiples exploradores podría ser un efecto residual de ese proceso, según Railgoon. El usuario señaló que varias wallets, entre ellas Cake Wallet y Zodl Wallet, también habrían quedado fuera de sincronía durante la bifurcación.

La actualización de Zcash produjo una desincronización en su ecosistema

Dos comunicados publicados el 3 de junio por Zcash Open Development y la Fundación Zcash confirmaron que la detención registrada por múltiples exploradores no fue una falla independiente, sino que correspondía a la ventana de activación de la actualización identificada con el nombre ‘NU6.2’ (que corregía el circuito de pruebas de Orchard).

Tras la actualización, los exploradores y wallets que no habían actualizado sus nodos antes de ese bloque quedaron en la cadena anterior y mostraron la red paralizada, aunque la cadena principal siguió operando.

Ambos comunicados confirmaron que no hay evidencia de que la vulnerabilidad encontrada en el pool Orchard haya sido explotada, que los fondos permanecieron seguros durante todo el proceso y que el suministro total de ZEC no registró alteraciones. NU6.2 restauró por completo las transacciones Orchard con el circuito corregido y cerró de forma definitiva la vulnerabilidad que el parche de emergencia del 2 de junio había contenido de forma provisoria.