Hace unos días, me encontré pensando en una parte del rendimiento de blockchain que rara vez se comenta: ¿qué sucede cuando la red ya no puede asumir que todo funciona normalmente?
La mayoría de los proyectos son fáciles de admirar cuando los validadores están en línea, los mensajes se están moviendo y los bloques se están produciendo exactamente como se espera. La pregunta más difícil es qué ocurre cuando de repente desaparece una gran parte de la red.
Antes pensaba que esto era simplemente cuestión de esperar a que el sistema se recupere. Pero después de mirar con más detenimiento Dusk, me di cuenta de que la parte más interesante es cómo está diseñado el protocolo para responder cuando la operación normal empieza a fallar.
El diseño de consenso de Dusk contempla la participación degradada. Si una cantidad significativa de Provisioners se desconecta o queda aislada, el protocolo no simplemente asume que el conjunto de validadores esperado seguirá funcionando como corresponde. Cuando fallan de forma repetida las iteraciones de consenso para alcanzar el resultado requerido, el protocolo cuenta con mecanismos que le permiten ajustar su comportamiento y continuar gestionando las condiciones cambiantes de la red.
Esa distinción importa más de lo que puede parecer.
Una blockchain puede desempeñarse extremadamente bien en condiciones ideales. La prueba real es si puede tomar decisiones sensatas cuando la participación disminuye, la comunicación se vuelve poco fiable o no puede formarse el conjunto de validadores esperado.
Pero hay otra pregunta que creo que es igual de importante: ¿con qué frecuencia se ponen a prueba estos mecanismos de recuperación en condiciones realistas?
Un protocolo puede tener una estrategia de fallos bien diseñada en el papel, pero la confianza real proviene de la implementación, la prueba y de ver cómo se comporta la red cuando algo sale mal.
Por eso creo que la resiliencia de blockchain no debería medirse solo por TPS o tiempos de bloque. La prueba más profunda es mucho más sencilla:
Cuando algo se rompe, ¿el protocolo sabe cómo responder?
@Dusk #dusk $DUSK
$TUT $UAI
La mayoría de los proyectos son fáciles de admirar cuando los validadores están en línea, los mensajes se están moviendo y los bloques se están produciendo exactamente como se espera. La pregunta más difícil es qué ocurre cuando de repente desaparece una gran parte de la red.
Antes pensaba que esto era simplemente cuestión de esperar a que el sistema se recupere. Pero después de mirar con más detenimiento Dusk, me di cuenta de que la parte más interesante es cómo está diseñado el protocolo para responder cuando la operación normal empieza a fallar.
El diseño de consenso de Dusk contempla la participación degradada. Si una cantidad significativa de Provisioners se desconecta o queda aislada, el protocolo no simplemente asume que el conjunto de validadores esperado seguirá funcionando como corresponde. Cuando fallan de forma repetida las iteraciones de consenso para alcanzar el resultado requerido, el protocolo cuenta con mecanismos que le permiten ajustar su comportamiento y continuar gestionando las condiciones cambiantes de la red.
Esa distinción importa más de lo que puede parecer.
Una blockchain puede desempeñarse extremadamente bien en condiciones ideales. La prueba real es si puede tomar decisiones sensatas cuando la participación disminuye, la comunicación se vuelve poco fiable o no puede formarse el conjunto de validadores esperado.
Pero hay otra pregunta que creo que es igual de importante: ¿con qué frecuencia se ponen a prueba estos mecanismos de recuperación en condiciones realistas?
Un protocolo puede tener una estrategia de fallos bien diseñada en el papel, pero la confianza real proviene de la implementación, la prueba y de ver cómo se comporta la red cuando algo sale mal.
Por eso creo que la resiliencia de blockchain no debería medirse solo por TPS o tiempos de bloque. La prueba más profunda es mucho más sencilla:
Cuando algo se rompe, ¿el protocolo sabe cómo responder?
@Dusk #dusk $DUSK
$TUT $UAI
