Я потратил некоторое время на изучение раздела 6 технической документации @Dusk и ушёл с большим количеством вопросов, чем ответов.

Что интересно, я думаю, это хороший знак.

Меня привлекло внимание не только PVM или модель исполнения на основе WASM. Важнее было то, насколько поведение основной сети Dusk, судя по всему, вынесено в контракты.

Transfer обрабатывает $DUSK transfers, комиссионные за валидацию и исполнение. Stake управляет заблокированными DUSK, состоянием стейкинга и выводами. Такие будущие компоненты, как Zedger и Clock, ещё сильнее добавляют логики в контракты.

Это заставило меня пересмотреть одно предположение.

Сначала я в первую очередь рассматривал PVM как лёгкий модульный способ запускать смарт-контракты. Но более глубокий вопрос может быть не в том, насколько аккуратно VM их выполняет.

Вопрос в том, кто контролирует контракты, от которых всё больше зависит сеть.

Если важный контракт становится узким местом безопасности, как он обновляется или заменяется?

Кто на самом деле имеет полномочия это изменить?

И насколько децентрализован такой контроль на практике?

Эти вопросы теперь значат для меня больше, чем просто знание того, что #Dusk имеет WASM-ориентированную VM.

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

Мой следующий шаг — глубже разобраться в том, как управляются, обновляются и защищаются эти генезис-контракты и будущие системные контракты.

У меня есть ощущение, что именно там моё текущее понимание Dusk либо подтвердится — либо изменится довольно сильно.
$TMX $XRP #KazakhstanCutsOilOutputForecastTo96MTons #JapanNoAdditionalOilReserveReleaseInSepOct #SamsungSKHynixLeveragedETFsPostFirstMonthlyOutflow #ThailandToExpandSECDigitalAssetProbePowers