Red de Características de Crosslink: Reflexiones sobre las Primeras Seis Semanas

Ha pasado poco más de seis semanas desde que lanzamos la red de características incentivada de Crosslink, donde los participantes pueden unirse a la red como mineros o finalizadores y hacer staking para ganar recompensas. Queríamos proporcionar una actualización sobre cómo ha progresado la red, los problemas que hemos encontrado hasta ahora, lo que hemos aprendido de ellos y en qué nos estamos enfocando actualmente para mejorar. Tal como se esperaba en esta etapa, la red sigue siendo inmadura y ha sido sumamente tosca. Los participantes han encontrado bloqueos, problemas de sincronización, finalidad estancada y una variedad de otros errores y casos límite a través de múltiples iteraciones de la red, particularmente en torno a la producción de bloques, el comportamiento de sincronización y la recuperación de la red. Si bien eso ha sido comprensiblemente frustrante en ocasiones para algunos participantes, otros han abrazado el desafío ayudando a diagnosticar problemas, coordinar esfuerzos de recuperación y comprender mejor cómo se comporta el sistema en la práctica. Como resultado, la red de características ya ha proporcionado información valiosa sobre el comportamiento de la red en el mundo real, y en general nos sentimos alentados por el progreso que se está logrando. En lugar de reiniciar repetidamente la red cada vez que ocurre un problema grave y solo practicar bajo condiciones ideales, nuestro objetivo es resolver estos problemas en un entorno activo siempre que sea posible. El tipo de fallas, interrupciones y desafíos de coordinación que estamos encontrando son precisamente el tipo de situaciones que una red de producción debe ser capaz de sobrevivir. Creemos que trabajarlos ahora conducirá en última instancia a una red más fuerte. BFT estancado El problema más significativo que enfrenta actualmente la red es una capa de finalidad estancada. Las paralizaciones (stalls) son quizás el aspecto más controvertido de los sistemas BFT. En lugar de arriesgarse a reversiones de transacciones, un protocolo detendrá la finalización si ya no puede alcanzar consenso de manera segura, eligiendo la seguridad sobre la disponibilidad. Este es el lado opuesto de la concesión (tradeoff) que hace el PoW de Nakamoto que Zcash utiliza actualmente, que prioriza la disponibilidad y la producción continua de bloques incluso bajo condiciones adversas, pero acepta la posibilidad de reversiones de transacciones a través de reorganizaciones de cadena. En pocas palabras, cuando las condiciones de la red se vuelven desfavorables, el PoW tiende a producir reversiones mientras que los sistemas BFT tienden a producir paralizaciones. En Crosslink, una paralización del BFT hace que la finalidad deje de progresar mientras que el PoW continúa produciendo bloques. Esto puede ocurrir si suficiente stake se desconecta. En esta etapa, aún no está claro si la red se recuperará de forma natural a medida que los finalizadores vuelvan a conectarse o si los participantes decidirán en última instancia que alguna forma de acción de recuperación coordinada es necesaria. Como desarrolladores, a menudo es tentador simplemente reiniciar la red cuando encuentra un estado difícil, muy parecido a reiniciar una laptop cuando algo sale mal. Sin embargo, debido a que las paralizaciones son un comportamiento conocido y esperado de los sistemas BFT, y porque la red de características está diseñada para exponer desafíos operativos del mundo real, creemos que hay un mayor valor en comprender y trabajar a través de estas situaciones. Nuestro enfoque está en mejorar la robustez del software y proporcionar mejores herramientas de análisis, monitoreo y diagnóstico. En última instancia, nuestro objetivo es dar a los participantes la capacidad de detectar, analizar, coordinar y recuperarse ellos mismos de este tipo de escenarios, para garantizar que cualquier despliegue futuro sea más resiliente bajo condiciones del mundo real. Para ayudar a los participantes a comprender mejor el estado de la red, recientemente lanzamos nuevas herramientas de visualización y diagnóstico enfocadas en la actividad de los finalizadores y la salud de la red. Las herramientas permiten a los usuarios identificar qué finalizadores parecen estar en línea o fuera de línea basándose en la actividad de votación reciente, ver el stake agregado en línea y fuera de línea, inspeccionar el estado individual de cada finalizador e interpretar mejor el estado actual de la red BFT. Las actualizaciones recientes también introdujeron filtros adicionales y la visualización del estado de conexión directa de los finalizadores, posibilitada por mejoras en la topología de par a par. Un objetivo principal de este trabajo es asegurar que los participantes tengan la información necesaria para tomar decisiones informadas por sí mismos, en lugar de depender de Shielded Labs para dictar los resultados. Una de las ideas centrales detrás de la arquitectura de Crosslink es que diferentes participantes en el sistema tienen diferentes responsabilidades:

• Las billeteras protegen a los usuarios.
• Los mineros incluyen transacciones y producen bloques.
• Los finalizadores hacen cumplir la finalidad.
• Los stakers seleccionan buenos finalizadores.
• Los usuarios hacen slash a los stakers si no hacen su trabajo.

Con ese fin, estamos desarrollando herramientas de recuperación que podrían permitir a los usuarios coordinar una actualización de emergencia de la red si la red en general concluye que la acción es necesaria, incluyendo mecanismos que podrían reducir socialmente (slash) el stake delegado a finalizadores persistentemente inactivos. Los desafíos operativos y de coordinación involucrados aquí son exactamente el tipo de problemas que la red de características está destinada a revelar antes de que se considere cualquier despliegue en producción. Qué sigue Cuando presentamos originalmente la red de características incentivada, el plan era que el desarrollo progresara a través de una serie de “temporadas”, donde cada nueva temporada operaría efectivamente como una nueva red con software actualizado, historial de consenso fresco y funcionalidad mejorada. La idea era que los participantes pudieran seguir ganando recompensas mientras portaban sus identidades de finalizador y hacían la transición entre redes progresivamente más maduras. Sin embargo, basándonos en los problemas que hemos encontrado hasta ahora, hemos decidido abandonar la idea de reiniciar regularmente la red y lanzar temporadas completamente nuevas en un cronograma predeterminado. Como se mencionó anteriormente en esta publicación, creemos que hay un valor significativo en trabajar a través de escenarios de fallas y recuperación en un entorno activo en lugar de reiniciar repetidamente la red y comenzar de nuevo. Si bien ese enfoque puede ser más lento y más doloroso a corto plazo, creemos que producirá una red más fuerte y nos dará una comprensión mucho más profunda de cómo se comporta el sistema bajo condiciones del mundo real. De aquí en adelante, el plan es continuar iterando en la red existente a través de actualizaciones de software regulares que mejoren la estabilidad, corrijan errores, expandan las herramientas e introduzcan funcionalidad más madura con el tiempo, reiniciando la red solo cuando se considere esencial para el desarrollo [1]. Continuaremos proporcionando actualizaciones regulares sobre el progreso de la red, problemas importantes, nuevas herramientas y cambios en la red de características a medida que el desarrollo continúe. Distribución de recompensas En lugar de vincular los incentivos a “temporadas” discretas, las recompensas se distribuirán en una cadencia continua de seis semanas. Antes de que comience cada período de pago, anunciaremos cuánto ZEC ha sido asignado para ese período de seis semanas. También anunciaremos próximamente el proceso de pago para las primeras seis semanas. Debido a que este es el período de distribución inicial, es probable que haya un breve retraso antes de que las recompensas sean procesadas mientras finalizamos las herramientas y el flujo de trabajo operativo. El plan actual es que los participantes envíen una clave de visualización (viewing key) de la billetera de la red de características junto con una dirección Orchard de mainnet donde deban enviarse las recompensas. Como se especificó originalmente, las recompensas se basarán en cTAZ ganados a través de la actividad de minería y staking durante el período de pago, y no en las tenencias totales de cTAZ. Los participantes tendrán una ventana de reclamo limitada para enviar la información requerida y recibir las recompensas. Cualquier ZEC no reclamado que permanezca después de ese período puede usarse como recompensas discrecionales para los contribuyentes que fueron más allá en las pruebas, depuración, reporte de problemas o de otra forma ayudaron a mejorar la red. Como se mencionó previamente, Shielded Labs no será receptora de recompensas basadas en ZEC de la red de características incentivada. Conclusión Apreciamos a todos los que han seguido participando a pesar de la inestabilidad y las frustraciones inevitables que vienen con probar software en esta etapa de desarrollo. La retroalimentación, las fallas y los casos límite encontrados durante las últimas seis semanas ya han mejorado significativamente nuestra comprensión del sistema y ayudarán a guiar la siguiente fase de desarrollo. A pesar de los desafíos, muchos participantes han seguido proporcionando retroalimentación valiosa, probando casos límite, reportando errores, desarrollando herramientas y ayudando a mejorar la red de maneras significativas. Especialmente queremos agradecer a @Zk_nd3r y @k6nb4k por estar consistentemente comprometidos e ir más allá al construir exploradores de bloques y contribuir infraestructura importante. También nos gustaría reconocer a @dismad8, @thecodebuffet, Orchard Guardian y @TomZarebczan por su valiosa retroalimentación y contribuciones a lo largo de las primeras seis semanas de la red de características. También entendemos que el estado actual de la red puede hacer que la participación sea difícil o frustrante para algunos usuarios. No hay absolutamente ninguna expectativa de que todos participen en esta etapa temprana. Los participantes son libres de alejarse y volver a unirse más adelante a medida que la red se vuelva más estable y madura. Como se mencionó previamente, se espera que la cantidad de ZEC asignada a la red de características incentivada aumente con el tiempo a medida que la red y las herramientas continúen mejorando. También esperamos que la red continúe ejecutándose por un período extendido de tiempo, probablemente a través de 2026 y hasta 2027. Además, planeamos continuar organizando talleres y llamadas comunitarias de manera regular, aproximadamente una vez cada seis semanas, y seguirá habiendo muchas oportunidades para que los participantes se involucren. [1] Nota: Si bien nos estamos alejando de los reinicios estacionales planificados, aún podríamos reiniciar la red cuando hacerlo nos permita simplificar la base de código o realizar mejoras de diseño significativas que de otro modo romperían la compatibilidad. La compatibilidad hacia atrás no es un objetivo principal en esta etapa, pero se volverá cada vez más importante a medida que nos acerquemos a la preparación para producción. Gracias a @nate_zec, @zooko, @azmreece y Phillip Trudeau-Tavara por sus útiles ideas y retroalimentación sobre esta publicación. Traducción del original en inglés de la aquietinvestor.

Si quieres aprender más sobre privacidad en la economía digital descentralizada, te puedes unir a la comunidad de Zcash en Español en Telegram. Para conectar con el ecosistema digital de Zcash Español, visita nuestro Privacidad.me.