ZEC se dispara un 42 %, cofundador de ZODL explica la actualización de emergencia en dos fases de Zcash

Zcash lanza una actualización de emergencia en dos fases: primero una bifurcación suave para detener temporalmente las transacciones Orchard, luego una bifurcación dura NU6.2 para reparar vulnerabilidades en la capa base. Josh Swihart, fundador de ZODL, explica en detalle todo el proceso de reparación.
（Resumen previo: ¡Zcash resuelve la crisis de doble gasto! Se activa urgentemente una bifurcación dura para arreglar la vulnerabilidad en las pruebas de conocimiento cero, confirmando que no hubo pérdida de fondos）
（Información adicional: Zcash publica la propuesta "Ironwood": ¿Permitir que cualquiera verifique la circulación de ZEC, puede recuperar la confianza?）

Índice de este artículo

Alternar

• Primera fase: bifurcación suave para detener transacciones Orchard
• Segunda fase: bifurcación dura NU6.2 para arreglar la capa base
• Organización independiente ShieldedLabs actúa proactivamente
• Colaboración con pools mineros y revisión de código

El cofundador de la moneda privada Zcash y de ZODL, Josh Swihart, explicó en detalle en la plataforma X el 8 de junio cómo el equipo de Zcash reparó una grave vulnerabilidad en la piscina de privacidad Orchard. Zcash ha lanzado un plan de actualización de emergencia en dos fases, la primera una bifurcación suave para detener transacciones Orchard, y la segunda una bifurcación dura NU6.2 para arreglar la vulnerabilidad en la capa base.

Primera fase: bifurcación suave para detener transacciones Orchard

Swihart indicó que el equipo de ZODL primero utilizó una bifurcación suave (SoftFork) para desactivar temporalmente las transacciones Orchard, asegurando que la vulnerabilidad no pudiera ser explotada antes de ser reparada. La ventaja de la bifurcación suave es que no requiere que las pools mineras y los nodos realicen una actualización masiva, además de mantener todas las funciones nuevas.

Durante esta primera fase, la piscina de privacidad Orchard de Zcash enfrentaba dos problemas: uno, que los nuevos ZEC podrían tener un "cero" invisible pero válido adicional, y dos, que el cambio en las transacciones podría ser ligeramente menor de lo esperado. La medida de pausa mediante bifurcación suave permitió al equipo tener suficiente tiempo para completar la verificación y reparación.

Segunda fase: bifurcación dura NU6.2 para arreglar la capa base

El 3 de junio, el equipo activó con éxito la bifurcación dura NU6.2. Esta actualización corrigió la lógica de cálculo en la circuitería de Orchard en la capa base, haciendo que todas las transacciones ZEC vuelvan a pasar por la ruta de validación correcta.

Además, NU6.2 reactivó la función de transacciones Orchard, permitiendo que las transacciones privadas de Zcash vuelvan a funcionar normalmente. Swihart señaló que Orchard es actualmente la piscina de transacciones privadas central en Zcash, responsable de verificar que cada transacción que entra en el sistema sea legítima.

Organización independiente ShieldedLabs actúa proactivamente

La vulnerabilidad fue divulgada inicialmente por la organización técnica independiente ShieldedLabs. La organización afirmó que la piscina de privacidad Orchard tenía una vulnerabilidad grave, que en teoría podría permitir a un atacante crear una cantidad ilimitada de tokens ZEC falsificados.

ShieldedLabs confirmó que la vulnerabilidad ya fue reparada y que actualmente no hay evidencia de que haya sido explotada en la práctica. La red de Zcash mantiene un estado sin pérdidas tras la reparación.

Colaboración con pools mineros y revisión de código

Swihart reveló que, durante el proceso, el equipo de ZODL respondió activamente a las solicitudes de revisión de código de pools mineros y exchanges, para demostrar la fiabilidad de la solución de reparación. Entre ellos, los pools ViaBTC y Foundry jugaron un papel clave en la coordinación de respuestas de emergencia.

Este incidente destacó el mecanismo de control de calidad en la cadena de bloques de privacidad Zcash: mediante un proceso de divulgación previa, reparación y verificación, se asegura que la red principal mantenga su estabilidad antes de completar la actualización.