#dusk $DUSK @Dusk
Я вернулся к документации Dusk’s DuskEVM после того, как увидел последний результат нагрузочного теста, и понял, что сделал простое предположение: быстрый блок EVM означает, что DuskDS должен выполнить те же транзакции снова.

Описанный процесс отличается. Транзакция поступает в секвенсор DuskEVM, попадает в L2-блок, а батчер публикует свои данные в DuskDS. Затем коммиты состояния и fault proof’ы связывают получившееся состояние с расчетами (settlement) в DuskDS. В описанном тесте примерно 10 000 транзакций в одном блоке DuskEVM за две секунды сгенерировали восемь BLOB’ов, распределённых по двум транзакциям DuskDS, при этом DuskDS продолжал обработку своей нативной нагрузки.

Это заставило меня взглянуть на всё иначе.

Моё толкование: важен не только подсчёт транзакций. Важнее то, что EVM-исполнение и settlement в DuskDS обрабатывали смешанную работу через отдельные модели состояния, и в примере не показано, что одна нагрузка блокирует другую.

Моё сомнение в том, что происходит вне «чистого» сценария. При устойчивом смешанном спросе каковы худшие (worst-case) границы между включением в EVM, публикацией данных и settlement в DuskDS? Если секвенсор или батчер «зависают» (stall), кто может инициировать восстановление, и что препятствует тому, чтобы это полномочие переупорядочивало или задерживало ожидающие финансовые транзакции?

Я хочу посмотреть это в практике.