@Dusk осознавал, что модульность — это не просто про наличие большего числа компонентов. $DUSK на самом деле разделяет, где происходит расчет (settlement), и где происходит выполнение (execution), и это меняет то, как я думаю о цепочке.

Проверяя последние документы Dusk, я постоянно проводил параллель между DuskDS и DuskEVM. DuskDS занимается консенсусом, финальностью и доступностью данных, тогда как DuskEVM — это слой выполнения EVM, который рассчитывается через него.

DuskVM — это еще одна среда выполнения напрямую поверх L1. Самое интересное в том, что они все могут опираться на одну и ту же базу для расчетов, а не заставлять каждое приложение вписываться в одну модель выполнения.

Сначала я прочитал это как обычный язык про модульную архитектуру и почти пропустил. Потом я присмотрелся к тому, как Dusk обрабатывает реальные транзакции: Moonlight и Phoenix оба рассчитываются через DuskDS, в то время как выполнение смарт-контрактов может находиться в другом месте. Из-за этого разделение стало ощущаться гораздо более практичным, чем предполагает схема.

Тем не менее, мне интересно, в чем компромисс. Когда приложения начинают перемещаться между этими средами выполнения, модульность действительно снижает сложность для разработчиков или просто переносит эту сложность в интерфейсы между ними…

@Dusk $DUSK #dusk