#dusk $DUSK @Dusk
Je suis retourné dans la documentation de Dusk’s DuskEVM après avoir vu le dernier résultat de test de charge, et j’ai réalisé que j’avais fait une hypothèse simple : un bloc EVM rapide signifiait que DuskDS devait exécuter à nouveau les mêmes transactions.
Le flux documenté est différent. Une transaction est envoyée au séquenceur DuskEVM, entre dans un bloc L2, et le batcher publie ses données à DuskDS. Les engagements d’état et les preuves de faute relient ensuite l’état obtenu au règlement sur DuskDS. Dans le test rapporté, environ 10 000 transactions dans un bloc DuskEVM de deux secondes ont produit huit blobs, répartis entre deux transactions DuskDS, tandis que DuskDS continuait à traiter sa charge de travail native.
Cela m’a amené à l’examiner autrement.
Mon interprétation : le résultat important n’est pas seulement le nombre de transactions. C’est le fait que l’exécution EVM et le règlement DuskDS aient géré un travail mixte via des modèles d’état distincts, sans que l’exemple ne montre qu’une charge de travail bloque l’autre.
Mon incertitude concerne ce qui se passe en dehors du cas « propre ». En cas de demande mixte soutenue, quelles sont les bornes en pire cas entre l’inclusion EVM, la publication des données et le règlement sur DuskDS ? Si le séquenceur ou le batcher se bloque, qui peut initier la récupération, et qu’est-ce qui empêche cette autorité de réordonner ou de retarder des transactions financières en attente ?
Je veux le voir en pratique.
Je suis retourné dans la documentation de Dusk’s DuskEVM après avoir vu le dernier résultat de test de charge, et j’ai réalisé que j’avais fait une hypothèse simple : un bloc EVM rapide signifiait que DuskDS devait exécuter à nouveau les mêmes transactions.
Le flux documenté est différent. Une transaction est envoyée au séquenceur DuskEVM, entre dans un bloc L2, et le batcher publie ses données à DuskDS. Les engagements d’état et les preuves de faute relient ensuite l’état obtenu au règlement sur DuskDS. Dans le test rapporté, environ 10 000 transactions dans un bloc DuskEVM de deux secondes ont produit huit blobs, répartis entre deux transactions DuskDS, tandis que DuskDS continuait à traiter sa charge de travail native.
Cela m’a amené à l’examiner autrement.
Mon interprétation : le résultat important n’est pas seulement le nombre de transactions. C’est le fait que l’exécution EVM et le règlement DuskDS aient géré un travail mixte via des modèles d’état distincts, sans que l’exemple ne montre qu’une charge de travail bloque l’autre.
Mon incertitude concerne ce qui se passe en dehors du cas « propre ». En cas de demande mixte soutenue, quelles sont les bornes en pire cas entre l’inclusion EVM, la publication des données et le règlement sur DuskDS ? Si le séquenceur ou le batcher se bloque, qui peut initier la récupération, et qu’est-ce qui empêche cette autorité de réordonner ou de retarder des transactions financières en attente ?
Je veux le voir en pratique.
