#dusk $DUSK @Dusk
Volví a revisar la documentación de DuskEVM después de ver el último resultado de la prueba de carga, y me di cuenta de que había hecho una suposición sencilla: un bloque EVM rápido significaba que DuskDS tenía que ejecutar las mismas transacciones de nuevo.
El flujo documentado es diferente. Una transacción va al secuenciador de DuskEVM, entra en un bloque L2 y el paginador publica sus datos en DuskDS. Luego, los compromisos de estado y las pruebas de fallas conectan el estado resultante con la liquidación en DuskDS. En la prueba reportada, aproximadamente 10.000 transacciones en un bloque de DuskEVM de dos segundos produjeron ocho blobs, divididos en dos transacciones de DuskDS, mientras DuskDS continuaba procesando su carga de trabajo nativa.
Eso me hizo verlo de otra manera.
Mi interpretación: el resultado importante no es solo el conteo de transacciones. Es que la ejecución de EVM y la liquidación de DuskDS manejaron trabajo mixto a través de modelos de estado separados, sin que el ejemplo mostrara que una carga de trabajo bloquee a la otra.
Lo que me genera incertidumbre es qué sucede fuera del caso “limpio”. Bajo demanda mixta sostenida, ¿cuáles son los límites de peor caso entre la inclusión en EVM, la publicación de datos y la liquidación en DuskDS? Si el secuenciador o el paginador se atascan, ¿quién puede iniciar la recuperación y qué impide que esa autoridad reordene o retrase transacciones financieras pendientes?
Quiero verlo en la práctica.
Volví a revisar la documentación de DuskEVM después de ver el último resultado de la prueba de carga, y me di cuenta de que había hecho una suposición sencilla: un bloque EVM rápido significaba que DuskDS tenía que ejecutar las mismas transacciones de nuevo.
El flujo documentado es diferente. Una transacción va al secuenciador de DuskEVM, entra en un bloque L2 y el paginador publica sus datos en DuskDS. Luego, los compromisos de estado y las pruebas de fallas conectan el estado resultante con la liquidación en DuskDS. En la prueba reportada, aproximadamente 10.000 transacciones en un bloque de DuskEVM de dos segundos produjeron ocho blobs, divididos en dos transacciones de DuskDS, mientras DuskDS continuaba procesando su carga de trabajo nativa.
Eso me hizo verlo de otra manera.
Mi interpretación: el resultado importante no es solo el conteo de transacciones. Es que la ejecución de EVM y la liquidación de DuskDS manejaron trabajo mixto a través de modelos de estado separados, sin que el ejemplo mostrara que una carga de trabajo bloquee a la otra.
Lo que me genera incertidumbre es qué sucede fuera del caso “limpio”. Bajo demanda mixta sostenida, ¿cuáles son los límites de peor caso entre la inclusión en EVM, la publicación de datos y la liquidación en DuskDS? Si el secuenciador o el paginador se atascan, ¿quién puede iniciar la recuperación y qué impide que esa autoridad reordene o retrase transacciones financieras pendientes?
Quiero verlo en la práctica.
