Я неправильно смотрел на архитектуру Dusk

Я думал, что старая архитектура @Dusk просто нуждается в оптимизации.

Но мое восприятие оказалось неверным.

Я понял: проблема была не только в движке. Проблема была в чертеже вокруг него.

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

Это напомнило мне однополосный мост. При невысоком трафике всё работает нормально. Но когда поток растет, иногда мост приходится перестраивать.

Тогда я задумался: если старая архитектура работала, зачем ее переделывать?

Новая архитектура разделяет обязанности: DuskDS занимается расчетами и доступностью данных, а DuskVM и DuskEVM предоставляют среды выполнения.

И вот что щелкнуло: конечно, дело было не просто в улучшении старой архитектуры. Дело было в том, чтобы подогнать её под то, во что Dusk превращается.

Я видел обновление как настройку движка. Теперь я вижу переработку чертежа.

Система может перерасти дизайн, который ее создал.

Растущим системам нужна новая архитектура, а не просто лучшая производительность?

$DUSK #dusk

Когда система растет, что важнее всего?