Hoy estaba revisando el flujo de consenso de Dusk y me quedé atascado en un detalle que es fácil de pasar por alto cuando solo miras la arquitectura del titular.
La parte interesante no es realmente quién propone un bloque.
Lo que tiene que ocurrir antes de que ese bloque se convierta en algo sobre lo que el resto de la red pueda confiar y construir con certeza.
Dusk utiliza certificados como parte de su proceso de consenso.
Eso suena bastante estándar hasta que piensas en lo que realmente representa un certificado.
No es solo otra pieza de metadatos adjunta a un bloque.
Es, de hecho, evidencia de que una cantidad suficiente de la red ha completado un paso en particular del protocolo.
Eso crea una dependencia interesante.
La producción de bloques puede ser rápida.
Los validadores individuales pueden responder con rapidez.
Pero la red todavía tiene que esperar el estado colectivo representado por el certificado.
Así que la pregunta de rendimiento se vuelve ligeramente diferente del debate habitual sobre TPS.
No es solo:
¿Qué tan rápido puede un nodo procesar algo...?
Es:
¿Qué tan rápido pueden suficientes participantes independientes producir la evidencia necesaria para que todos los demás avancen?
Eso cambia la forma en que miro la latencia del consenso.
Un motor de ejecución más rápido es útil.
El procesamiento en paralelo es útil.
Pero si la formación del certificado se convierte en la parte más lenta bajo condiciones reales de red, entonces la velocidad teórica de todo lo que está debajo importa mucho menos de lo esperado.
Este es uno de esos detalles arquitectónicos que no parece emocionante en una página de benchmarks.
Pero durante congestión o un rendimiento desigual de los validadores, sospecho que se vuelve mucho más importante.
Cuanto más leo Dusk, más pienso que la historia real del rendimiento no trata sobre un componente rápido.
Se trata de qué componente es el que toda la red se ve obligada a esperar.
#dusk $DUSK @Dusk