Mientras Electric Coin Co. (ECC) y la comunidad Zcash se preparan para las retrospectivas públicas de la Actualización de Red 5 (NU5) y lo que se ha conocido como el ataque sandblasting, esta entrada de blog detalla las motivaciones, desafíos y logros de ECC con respecto a cada una.
La actualización NU5 fue una ambiciosa empresa para eliminar la necesidad de configuraciones de confianza, aumentar la confianza de los usuarios y mejorar la seguridad y escalabilidad de Zcash.
La implementación de Halo, un gran avance criptográfico, en Zcash hizo posible por primera vez en los teléfonos móviles transacciones de dinero digital privadas y fiables.
Un ataque malicioso tras la actualización provocó importantes problemas de rendimiento en el monedero, lo que llevó a ECC a entrar en modo de emergencia. Nuestra respuesta incluyó múltiples actualizaciones técnicas, mejoras de rendimiento y la publicación de nuevos SDK para monederos móviles.
A pesar de los retos y retrasos, ECC consiguió mejorar la seguridad y resistencia de Zcash.
¿Qué es el FUD?
La misión de ECC es potenciar la libertad económica, y la mayoría de las organizaciones que trabajan en proyectos relacionados con Zcash, como la Zcash Foundation (ZF) y Zcash Community Grants (ZCG), tienen objetivos comunitarios similares para la mejora de la humanidad.
Sin embargo, desde que Zcash llegó al mundo en 2016, ha circulado una corriente de desinformación (y algo de propaganda coordinada) en las redes sociales, foros y otras plataformas comunitarias destinadas a incitar FUD (miedo, incertidumbre y duda).
Los rumores afirmaban que Zcash estaba comprometido, o que era vulnerable a la falsificación, o que había una puerta trasera que permitiría a terceros acceder a la información de las transacciones de un usuario sin su consentimiento.
Y por desgracia, hasta que se lanzó NU5, había un obstáculo importante para hacer frente a estos ataques: la configuración de confianza. Cuando se lanzó Zcash, sus pruebas de conocimiento-cero requerían una Ceremonia, o fase de configuración de confianza, para producir parámetros públicos que permitieran a los usuarios construir y verificar transacciones privadas.
Esta técnica fue iniciada por ECC, y requería múltiples partes en diferentes lugares utilizando complejas medidas de seguridad.
A pesar de la cuidadosa planificación y ejecución, además de la seguridad redundante, los usuarios y observadores de Zcash tenían que confiar en el hecho histórico de que los participantes en la ceremonia no estaban conspirando para engañar al público. Los montajes de confianza no permiten un suministro verificable matemáticamente, y mientras se requirieran estos complicados procedimientos para las grandes actualizaciones de Zcash, siempre habría escépticos y detractores. Y los escépticos tendrían razón: las matemáticas son verificables, pero la historia no. La reputación y la integridad de Zcash estaban en entredicho y, en opinión de ECC, era un problema que la comunidad no podía permitirse ignorar.
NU5: una llamada a la acción
En 2019, los ingenieros de ECC Sean Bowe, Daira Emma Hopwood y Jack Grigg habían estado trabajando en el diseño de escalabilidad y experimentando con una solución para la recursividad eficiente cuando Bowe hizo un descubrimiento.
"Me topé con una técnica para construir pruebas de conocimiento cero en curvas elípticas completamente normales", explica Bowe. Y así, en el transcurso de unas 24 horas, pasé de 'Oh, eso es realmente emocionante, sería genial si pudiéramos hacerlo' a 'Santo cielo, ahora que no tenemos configuraciones de confianza ni nada, todo es realmente sencillo'". Fue una serie de pasos que pasaron de ser una bonita idea a un cambio de paradigma total".
Halo, como llegaría a conocerse, es un sistema de prueba de conocimiento cero que permite la recursividad sin una configuración de confianza de forma eficiente.
El descubrimiento de Bowe fue un avance criptográfico anunciado por la industria, y en 2021 ECC se comprometió a implementar Halo en Zcash.
Halo en Zcash haría posible por primera vez en los teléfonos móviles transacciones de dinero digital privadas y de confianza. Serviría como catalizador para la confianza de los usuarios de Zcash y proporcionaría un camino hacia una escalabilidad mucho mayor, al tiempo que haría que el protocolo fuera más atractivo, más rápido y menos costoso para que otros se basaran en él.
Del blog de ECC:
Halo en Zcash permitiría actualizaciones de circuitos sin necesidad de configuraciones de confianza, haciendo que el protocolo blindado Zcash sea más ágil para futuras mejoras, como el soporte de activos adicionales como [Zcash Shielded Assets, o ZSAs]. Queremos facilitar que otros proyectos y tokens se beneficien de las características de Zcash, como la privacidad a través del cifrado. La configuración de confianza se convertirá en un vestigio del pasado.
Además, esta actualización allanaría el camino para la escalabilidad blindada de Zcash a través de la agregación de pruebas y la sucesión de blockchain, dos mejoras de escalabilidad. Esto mejoraría la experiencia del usuario al eliminar el frustrante tiempo de sincronización que plaga todas las blockchains hoy en día, reduciendo la hinchazón tradicional de la blockchain y permitiendo tarifas no escalables a medida que aumenta el uso. En conversaciones con grandes plataformas sociales que expresaron su interés en la compatibilidad nativa con Zcash, se planteó como requisito a corto plazo un camino viable hacia la escalabilidad.
En enero de 2021, tras más de un año de I+D sobre Halo, ECC llegó a la conclusión de que los beneficios de Halo en Zcash superaban otras prioridades de protocolo, y propusimos implementarlo en NU5.
Mira el vídeo de Zcash Media sobre la Ceremonia original, sus participantes (incluido Edward Snowden) y cómo Halo hace obsoletas las configuraciones de confianza.
Objetivos y obstáculos de NU5
Nuestros objetivos NU5 desde el principio fueron (1) hacer Zcash más seguro, (2) dar confianza a los usuarios de Zcash haciendo el suministro matemáticamente verificable, (3) hacer futuras actualizaciones más fáciles, y (4) permitir que futuras actualizaciones se beneficien de pruebas recursivas para mejoras de escalabilidad y programabilidad.
Nuestra estimación inicial de entre 6 y 7 meses resultó ser demasiado optimista (a medida que se hacían nuevos descubrimientos, se revelaban oportunidades en el proceso y surgían complejidades técnicas) y al final el viaje duró casi un año y medio.
Por el camino, nos enfrentamos a una serie de retos técnicos. Por ejemplo, la complejidad de incluir la compatibilidad con Orchard en el monedero integrado zcashd no se tuvo debidamente en cuenta en las estimaciones originales de los plazos de NU5.
ECC se enfrentó a obstáculos de ingeniería que requerían mucho tiempo, como la construcción de un complicado circuito para que Halo-plus-Orchard funcionara en dispositivos móviles. Y a mitad de camino, tomamos la decisión de implantar direcciones unificadas (UA) para permitir el blindaje por defecto en los monederos compatibles. El diseño y la construcción de las UA fueron difíciles, y si ECC hubiera estado practicando una planificación y un desarrollo orientados al producto en aquel momento (como hacemos ahora) creemos que habríamos identificado antes la necesidad de las UA y su implantación habría sido más fluida.
Además de luchar contra obstáculos técnicos como estos, más algunos errores sorpresa, ECC dedicó mucho tiempo y recursos a defender nuestras decisiones de hoja de ruta frente a las críticas recibidas por: nuestra justificación (deshacerse de la configuración de confianza no merecía la pena, las ZSA eran más importantes), nuestra planificación (iniciamos el debate públicamente antes de planificar lo suficiente y planificamos demasiado antes de empezar el trabajo), la decisión de licenciar Orchard bajo la Bootstrap Open Source Licence (BOSL), la decisión de implementar Direcciones Unificadas (UA), y nuestro enfoque general de las actualizaciones de la red (nuestras prioridades eran arbitrarias y estaban fuera de lugar).
También es importante reconocer que hemos contado con un importante apoyo de la comunidad durante el proceso. En general, la opinión de la comunidad fue positiva. Recibimos valiosas opiniones y comentarios de nuestro Consejo Asesor Científico y auditorías de seguridad cruciales de Qedit y el grupo NCC.
Cronología y logros de NU5
Sin incluir la investigación y el desarrollo previos a la implementación, NU5 fue un esfuerzo de 17 meses que aportó una tecnología novedosa y mejoró la experiencia del usuario de Zcash.
Cronología
Septiembre de 2019: se anuncia el descubrimiento de Halo
Enero de 2021: ZIP 224 propone el protocolo blindado Orchard, que define un nuevo pool blindado con claves de gasto y direcciones de pago susceptibles de futuras mejoras de escalabilidad (en enero, esperábamos lanzar NU5 en verano de 2021)
Febrero de 2021: el calendario original preveía el lanzamiento de NU5 (con Halo) en octubre de 2021.
Marzo de 2021: se publican las características propuestas para NU5.
Abril de 2021: la fecha de lanzamiento de NU5 se retrasó a enero de 2022 debido a nuevos descubrimientos que facilitarían una mejor interoperabilidad y para asignar más tiempo a nuestro ciclo de auditoría de implementación por terceros.
Abril de 2021: se introducen las direcciones unificadas
Agosto de 2021: introducción de Shielded by Default
Septiembre de 2021: errores corregidos en 4.5.1
Noviembre de 2021: se completan las evaluaciones de seguridad
Diciembre de 2021: la fecha de lanzamiento de NU5 se retrasa hasta abril de 2022 para un desarrollo adicional y para centrarse en la divulgación y los preparativos del ecosistema
Marzo de 2022: la activación de NU5 y el lanzamiento de Halo Arc se retrasan hasta mayo de 2022 para solucionar un error de consenso en testnet.
31 de mayo de 2022: NU5 se activa en la red principal, eliminando la configuración de confianza para el nuevo Orchard pool y lanzando una nueva era para Zcash.
Cuando Zcash NU5 se activó en mainnet el 31 de mayo de 2022, fue uno de los hitos más importantes para Zcash desde que la criptomoneda se lanzó en 2016. Como dijo el CEO de ECC, Zooko Wilcox, "un paso histórico para la sociedad humana".
Al lanzar el protocolo de pago blindado Orchard utilizando Halo, eliminamos la configuración de confianza para mejorar la seguridad y la sostenibilidad de Zcash. Hicimos el suministro matemáticamente verificable, mejoramos la escalabilidad, porque las futuras actualizaciones de la red no requerirán una complicada ceremonia de configuración. Allanamos el camino para una mayor interoperabilidad al proporcionar un sistema que podría desbloquear pruebas privadas de cadena cruzada a escala, e introdujimos BOSL que ha devuelto valor a la comunidad Zcash (por ejemplo, subvenciones de la Fundación Filecoin y la Fundación Ethereum a Brave y Edge).
Fue un esfuerzo enorme, y después de casi un año y medio de construcción y lucha con los desafíos técnicos de NU5, el equipo de ECC Core estaba listo para descansar. Pero casi de inmediato, Zcash se encontró con otro problema que no podíamos ignorar.
El ataque sandblasting
En junio de 2022, casi inmediatamente después de que ECC lanzara NU5, surgió un grave problema. La red Zcash comenzó a experimentar un enorme aumento en el tamaño y la actividad de las transacciones blindadas. Esta carga adicional de la red causó un "apilamiento de datos" que impidió que algunas billeteras (Nighthawk, Edge y Unstoppable) pudieran sincronizarse en un tiempo razonable. Los monederos no se sincronizaban y algunos usuarios no podían acceder a sus fondos.
Este era un problema que ECC, como principal mantenedor de zcashd y proveedor de SDK para monederos móviles, estaba en la mejor posición para afrontar.
Ataque con sandblasting: una llamada a la acción
Al principio, algunos miembros de ECC no querían suponer que esta inusual carga de transacciones fuera obra de un actor malicioso. Con el tiempo, sin embargo, la evidencia de que se trataba de un actor malicioso se hizo abrumadora; y tenemos razones para creer que incluso puede haber sido coordinado por el mismo actor o grupo de actores que difundieron Zcash FUD, y que pueden haber sido pagados para hacerlo.
Pero resolver ese misterio era menos importante que solucionar el problema.
Ataque con sandblasting: objetivos y obstáculos
Nuestra principal prioridad era garantizar que los usuarios pudieran recuperar el acceso a sus monedas ZEC y gastarlas. Esto es fundamental para nuestra misión de libertad económica y un requisito para el efectivo digital privado del mundo real.
Como primera línea de defensa, lanzamos mejoras de rendimiento en zcashd 5.1.0 y 5.2.0 para reducir el tiempo de verificación hasta en un 80%. También empezamos a trabajar en mejoras de rendimiento para nuestros SDK de monederos móviles.
En agosto de 2022, con mucho trabajo pendiente para resolver estos problemas de rendimiento de los monederos, ECC entró en Modo Emergencia. Este fue nuestro criterio para salir del Modo de Emergencia:
Los usuarios de Edge, Nighthawk e Unstoppable pueden gastar sus fondos actuales (fondos que ya están sincronizados cuando abren su monedero).
Los usuarios de estos monederos pueden recibir y gastar nuevos fondos entrantes a un ritmo de un mes de transacciones en 1 hora.
Los usuarios de esos monederos ven actualizaciones de sincronización que son mínimamente confusas sobre el progreso.
Ninguno de estos monederos se ve afectado por caídas frecuentes o comportamientos incoherentes (como la falta de visualización de algunas transacciones ya sincronizadas), ni requieren comportamientos alternativos debido al SDK de ECC.
Los problemas de rendimiento de los monederos planteaban una serie de retos complicados de abordar, y requerían el desarrollo y la aplicación de (1) un algoritmo más rápido que no requiriera una sincronización lineal de todos los bloques de la cadena y (2) modificaciones en las herramientas que permitieran a los usuarios gastar fondos sin tener una cadena totalmente sincronizada. La solución requería cambios en todos los componentes de la pila de monederos móviles blindados: zcashd, lightwalletd, los SDK de monederos ECC y el monedero prototipo ECC.
Internamente, los cambios en las tarifas se debatieron desde el principio, pero durante los primeros meses, el equipo de ECC se centró en mejoras adicionales del rendimiento y trabajó para resolver el problema sin cambios en las tarifas. Más tarde, decidimos introducir cambios en las tarifas para frenar el ataque de spam.
A medida que los usuarios se frustraban con su experiencia de uso, algunos miembros de la comunidad se hicieron oír y criticaron públicamente a ECC por no estar preparada para el ataque y por su lentitud a la hora de responder.
En febrero de 2023, la empresa de seguridad de blockchain Halborn nos notificó vulnerabilidades heredadas de Bitcoin Core que podrían haber afectado a más de 280 cadenas, incluida Zcash. Se trataba de otra emergencia de manos a la obra que se sumaba a los problemas de rendimiento de los monederos, y como ECC era el único equipo al que se había notificado la vulnerabilidad, éramos los únicos que podíamos hacer las correcciones necesarias. La coordinación de la divulgación y la reparación consumió aproximadamente un mes de nuestro tiempo.
Para empeorar las cosas, ECC como organización de ingeniería estaba intentando hacer demasiadas cosas a la vez: mantenimiento del nodo central, soporte a CEXs como Coinbase, Binance y Gemini, backports de Bitcoin, SDKs móviles, aplicaciones de monedero móvil y futuras mejoras del protocolo. ECC se reestructuró en mayo de 2023, lo que sobrecargó aún más los recursos temporalmente.
Retos adicionales
En aquel momento, la comunicación interna y las prácticas de gestión de proyectos de ECC no estaban organizadas para una situación de emergencia. Esto afectó a nuestra comprensión de las prioridades y el flujo de trabajo entre los equipos.
Antes del ataque, la estrategia de producto de ECC se centraba primero en la adopción, en lugar del rendimiento y la escalabilidad. Los usuarios quieren nuevas funciones, y trabajar en mejorar el rendimiento ralentiza el lanzamiento de funciones. Pero el ataque llevó a Zcash UX al límite inmediatamente.
Deuda técnica: habíamos implementado actualizaciones de red previas con mejoras de rendimiento limitadas.
ECC subestimó enormemente el tiempo que llevaría solucionar los problemas de rendimiento pendientes del monedero.
Surgieron otros problemas técnicos que causaron retrasos, como cuando speed.z.cash se estropeó y luego se eliminó mientras ECC estaba sin un gestor de desarrollo.
El equipo de ECC Core tuvo tres gestores diferentes durante el Modo de Emergencia.
El modo de emergencia ralentizó el desarrollo de nuestro monedero, ahora conocido como Zashi. Sin embargo, pudimos aprovechar el prototipo internamente para validar y probar las mejoras del SDK.
ECC tuvo la suerte de contar con socios proactivos (Edge, Nighthawk y Unstoppable) que trabajaron con nosotros para probar las versiones y enviar errores, y fueron rápidos a la hora de implementar los SDKs 2.0 cuando estuvieron listos.
Sandblasting: cronología y logros
En total, la respuesta al sandblasting de ECC y la implementación por parte de monederos de terceros consumió unos 16 meses. En noviembre de 2023, Edge, Nighthawk yUnstoppable volvían a funcionar (mejor que nunca) y anunciamos el fin del Modo Emergencia.
Cronología
Junio de 2022: comenzó el spam en la red; las salidas blindadas pasaron de una media mensual de 42.600 a 21.622.590 solo en junio
Julio de 2022: implementamos mejoras de rendimiento en zcashd 5.1.0 y 5.2.0 para reducir el tiempo de verificación hasta en un 80% y empezamos a trabajar en mejoras de rendimiento para nuestros SDK de monedero móvil
Agosto de 2022: ECC entra oficialmente en modo de emergencia, aunque no utilizamos ese término en comunicaciones públicas escritas hasta marzo de 2023; comenzamos a investigar Spend Before Sync
Septiembre de 2022: mientras trabajábamos en zcashd y mejorábamos la experiencia de sincronización móvil, reabrimos la investigación sobre posibles mecanismos de cambio de tarifas (ZIP 317) y eficiencias de sincronización (DAGSync/Spend Before Sync)
Octubre de 2022: lanzamiento de zcashd 5.3.0 con mejoras de rendimiento adicionales para reducir la utilización de memoria concurrente durante la exploración entre otras optimizaciones relacionadas con la memoria y el rendimiento en el nodo zcashd
Octubre de 2022: reafirmamos nuestros objetivos inmediatos en relación con los problemas de sincronización con nuestros SDK de monedero y comunicamos nuestros criterios para salir del modo de emergencia
Octubre de 2022: comunicamos nuestra intención de resolver los problemas de rendimiento de los monederos a finales de febrero de 2023
Octubre de 2022: los cambios en zcashd aumentaron su solidez frente al ataque
Noviembre de 2022: identificamos y solucionamos los últimos errores conocidos que bloqueaban la primera fase de las versiones del SDK, continuamos avanzando en Spend Before Sync y comenzamos a preparar los monederos zcashd y móviles para ZIP 317; eliminamos los últimos errores conocidos de librustzcash que bloqueaban la versión del monedero y completamos la integración de los SDK de Android e iOS
Diciembre de 2022: finalizada la implementación de las optimizaciones de zcashd que se espera ahorren memoria y reduzcan las tasas de huérfanos para los mineros
Febrero de 2023: lanzamiento de zcashd 5.4.0 para introducir una serie de mejoras de rendimiento, una actualización para corregir los informes de suministro y una limpieza de las características heredadas y la funcionalidad de soporte para mejorar el mantenimiento continuo de la base de código
Marzo de 2023: publicación de un calendario de actualizaciones y lanzamientos que prevé el fin del modo de emergencia para finales de mayo
Abril de 2023: ECC publica la versión 5.5.0 con el cambio completo de la estructura de tarifas de transacción (ZIP 317) y las mejoras de infraestructura que sientan las bases para la versión 5.6.0.
Mayo 2023: (reestructuración en ECC) se retrasa la fecha de lanzamiento de zcashd 5.6.0, lightwalletd, y SDKs a mediados de junio. A medida que zcashd 5.5.0 empezó a ser adoptado por los mineros de la red, los cambios en la estructura de tarifas empezaron a mitigar la eficacia del ataque sandblasting, reduciendo la tasa de crecimiento del blockchain y la carga de escaneo de carteras
Junio de 2023: lanzamiento de zcashd 5.6.0, que introduce la funcionalidad necesaria para que los monederos ligeros accedan a los fondos gastables sin escanear completamente la blockchain; incluye actualizaciones para abordar problemas relacionados con la implementación de ZIP-317 y las características de la política de privacidad
Julio de 2023: se publicó Lightwalletd 0.4.14, lo que significaba que el SDK para monederos móviles era la única pieza pendiente en el plan de ECC para resolver los problemas de rendimiento de los monederos y salir del Modo de Emergencia. En ese momento, esperábamos publicar los SDK a mediados de julio
Agosto de 2023: a finales de julio, la adopción de zcashd 5.5.0 por parte de la red se había completado, y la carga de transacciones de la red había vuelto a los niveles anteriores al NU5. Sin embargo, los datos de cadena acumulados hasta ese momento seguían representando un problema para el escaneo de monederos, por lo que para mitigar este problema ECC anunció la disponibilidad previa al lanzamiento de la capacidad Spend Before Sync en nuestros SDK móviles y puso esta funcionalidad a disposición de los desarrolladores de monederos para que la probaran. Se descubrieron varios errores y problemas de UX. El calendario para el lanzamiento de los SDK se trasladó a mediados de septiembre
Septiembre de 2023: surgieron nuevos errores, problemas de UX y dependencias que retrasaron la fecha de lanzamiento de los SDK hasta finales de septiembre
26 de septiembre de 2023: ECC lanzó el SDK 2.0 para móviles actualizado para desarrolladores de iOS y Android. Este fue el producto final para salir del Modo de Emergencia
de noviembre de 2023: después de un mes en producción, no se informó de ningún problema importante relacionado con el monedero y ECC declaró la salida del Modo de Emergencia
La culminación de nuestra respuesta de sandblasting fue que los monederos Zcash de terceros volvían a funcionar, y los futuros atacantes se vieron aún más perjudicados.
Durante este tiempo, ECC lanzó múltiples actualizaciones de zcashd y lightwalletd, además de nuevos SDK móviles que, en conjunto, introdujeron nuevas innovaciones (y aprendizaje) en el mundo de la criptografía y el dinero descentralizado. Estos lanzamientos proporcionan mejoras masivas a la privacidad, escalabilidad y experiencia de usuario en Zcash, y tienen implicaciones para todos los proyectos criptográficos centrados en la privacidad.
El trabajo continúa
NU5 y el ataque con sandblasting consumieron casi tres años. Pero ante la adversidad organizada, las emergencias concurrentes y las críticas de la comunidad (algunas de ellas justificadas), ECC no se desvió de su compromiso de construir. Con aliados en el camino, la comunidad superó retos técnicos sin precedentes y limitaciones de recursos para hacer Zcash más resistente, fiable y seguro.
Hemos aprendido mucho y, aunque nos encantaría dar un paso atrás y tomarnos un descanso, sabemos que el trabajo es ahora más importante que nunca. Esperamos destilar las lecciones de estas experiencias en la próxima retrospectiva, y nos sentimos honrados de continuar el esfuerzo para construir la libertad económica y una experiencia de usuario Zcash de clase mundial.
Traducción del original en inglés de Electric Coin Co.
Si quieres aprender más sobre privacidad en la economía digital descentralizada, te puedes unir a la comunidad de Zcash Español en Telegram. Para conectar con el ecosistema digital de Zcash Español, visita nuestro Linktree.
