Nunca he encontrado que TPS, por sí solo, sea muy útil para evaluar una cadena como DUSK.
Parece impresionante en un gráfico.
Luego llegan las cargas de trabajo reales.
Privacidad. Generación de pruebas. Ejecución de contratos. Crecimiento del estado. Nodos que intentan mantenerse sincronizados.
Ahí es donde las cosas se ponen interesantes.
DUSK parece entender esto mejor que la mayoría.
En lugar de hacer que una sola capa lo haga todo, la red divide el trabajo.
DuskDS se encarga del consenso, la liquidación y la disponibilidad de datos.
DuskVM se encarga de los contratos nativos.
DuskEVM proporciona un entorno de ejecución familiar para aplicaciones basadas en Solidity.
Suena a charla de arquitectura.
Pero importa porque cada carga de trabajo tiene una forma distinta de volverse lenta.
Y hay otra pieza silenciosa: Kadcast.
En lugar de difundir bloques de forma interminable por pares aleatorios, usa una red estructurada para la propagación. Menos tráfico duplicado, más entrega predecible.
Eso quizá no sea un gran gráfico para marketing.
Pero cuando una red se pone ajetreada, el ancho de banda desperdiciado se vuelve muy real.
Luego viene la parte que la gente normalmente pasa por alto:
la privacidad tiene un costo computacional.
Las pruebas de conocimiento cero son un trabajo real. Puedes tener un consenso rápido y aun así toparte con un muro si generar pruebas se convierte en el cuello de botella.
Así que no creo que la verdadera pregunta de escalabilidad de DUSK sea:
“¿Puede procesar una cantidad enorme de transacciones?”
Es:
¿Qué pasa cuando esas transacciones se vuelven caras?
¿Puede la finalidad (finality) mantenerse predecible?
¿Pueden los nodos mantenerse al ritmo?
¿Las transacciones privadas pueden coexistir con la actividad normal de contratos inteligentes?
Esa es la prueba más difícil.
Y honestamente, las pequeñas decisiones de ingeniería me dicen más que los grandes números.
Cómo se mueven los datos. Cómo se accede al estado. Cómo se sincronizan los nodos. Cómo se producen las pruebas. Cómo la ejecución se separa de la liquidación.
Nada de eso suena emocionante.
Pero normalmente es ahí donde vive la escalabilidad real.
Una cadena duradera no es la que hace que cada componente sea ridículamente rápido.
Es una donde el trabajo costoso sabe cómo mantenerse en su carril.
Esa es la parte de DUSK que sigo observando.
#dusk $DUSK @Dusk
Parece impresionante en un gráfico.
Luego llegan las cargas de trabajo reales.
Privacidad. Generación de pruebas. Ejecución de contratos. Crecimiento del estado. Nodos que intentan mantenerse sincronizados.
Ahí es donde las cosas se ponen interesantes.
DUSK parece entender esto mejor que la mayoría.
En lugar de hacer que una sola capa lo haga todo, la red divide el trabajo.
DuskDS se encarga del consenso, la liquidación y la disponibilidad de datos.
DuskVM se encarga de los contratos nativos.
DuskEVM proporciona un entorno de ejecución familiar para aplicaciones basadas en Solidity.
Suena a charla de arquitectura.
Pero importa porque cada carga de trabajo tiene una forma distinta de volverse lenta.
Y hay otra pieza silenciosa: Kadcast.
En lugar de difundir bloques de forma interminable por pares aleatorios, usa una red estructurada para la propagación. Menos tráfico duplicado, más entrega predecible.
Eso quizá no sea un gran gráfico para marketing.
Pero cuando una red se pone ajetreada, el ancho de banda desperdiciado se vuelve muy real.
Luego viene la parte que la gente normalmente pasa por alto:
la privacidad tiene un costo computacional.
Las pruebas de conocimiento cero son un trabajo real. Puedes tener un consenso rápido y aun así toparte con un muro si generar pruebas se convierte en el cuello de botella.
Así que no creo que la verdadera pregunta de escalabilidad de DUSK sea:
“¿Puede procesar una cantidad enorme de transacciones?”
Es:
¿Qué pasa cuando esas transacciones se vuelven caras?
¿Puede la finalidad (finality) mantenerse predecible?
¿Pueden los nodos mantenerse al ritmo?
¿Las transacciones privadas pueden coexistir con la actividad normal de contratos inteligentes?
Esa es la prueba más difícil.
Y honestamente, las pequeñas decisiones de ingeniería me dicen más que los grandes números.
Cómo se mueven los datos. Cómo se accede al estado. Cómo se sincronizan los nodos. Cómo se producen las pruebas. Cómo la ejecución se separa de la liquidación.
Nada de eso suena emocionante.
Pero normalmente es ahí donde vive la escalabilidad real.
Una cadena duradera no es la que hace que cada componente sea ridículamente rápido.
Es una donde el trabajo costoso sabe cómo mantenerse en su carril.
Esa es la parte de DUSK que sigo observando.
#dusk $DUSK @Dusk
