Я снова читал архитектуру Dusk и застрял на том, почему поселение (settlement) рассматривается как отдельная задача от выполнения.

DuskDS — это уровень поселения и доступности данных L1. Он занимается консенсусом и финальностью, тогда как DuskVM выполняет контракты Rust/WASM напрямую в L1. DuskEVM выбирает другой путь: предоставляет инструментарий Solidity и EVM, но при этом использует DuskDS для поселения и доступности данных.

Такое разделение становится более логичным, когда перестаёшь думать о выполнении как о всей транзакции целиком.

Контракт может вычислить, что должно произойти. Но кто-то всё равно должен зафиксировать, что получившееся состояние теперь является частью общей цепочки и достигло финальности. Dusk сохраняет эти обязанности раздельными, не превращая их в независимые системы, которые существуют сами по себе.

Это особенно актуально для финансовой инфраструктуры. Приложению может понадобиться привычное выполнение в стиле EVM, но лежащий под ним уровень поселения всё равно должен обеспечивать консенсус и финальность, на которые опирается рабочий процесс. DuskEVM может менять среду выполнения, не меняя того, откуда берётся поселение.

Однако есть часть, с которой я всё ещё не до конца согласен. С точки зрения архитектуры разделение звучит аккуратно, но путь выполнения и DuskDS всё равно должны двигаться как единая система. Бóльшая модульность не означает меньшую координацию.

И я пока недостаточно вижу публичных данных по бенчмаркам, чтобы уверенно сказать, где практическое ограничение проявится первым при длительной нагрузке.

Я бы хотел измерить одну вещь, прежде чем делать более громкие заявления: когда выполнение DuskEVM начинают сильно «толкать», как именно эта нагрузка влияет на задержки поселения и финальности в DuskDS?

#dusk $DUSK @Dusk $PORTAL $GPS