Самый опасный результат не обязательно в том, что узлы дерутся друг с другом, а в том, что все узлы вызывают один и тот же набор проверочного кода — и при этом проверяют неверно аккуратно, «по расписанию».
Я сверил исторический white paper для @Dusk с текущей документацией. В старых материалах эту Rust/WASM-рантайм среду называли Piecrust, а в актуальной документации используется DuskVM. Название менялось, но ключевая архитектура осталась прежней: контракт может передавать криптографические проверки — например, PLONK, Groth16, BLS и др. — на уровень хоста через публичные точки входа, не реализуя всё это по отдельности.
Преимущества вполне практичны. Разработчикам не нужно писать отдельный комплект криптографического кода, который легко ошибочно реализовать; узлам также не требуется повторять базовые вычисления внутри WASM-песочницы, а приложения становятся легче, а правила валидации — проще и легче унифицировать.
Плата за это тоже сосредоточена в одном месте. Ошибка в контракте обычно прежде всего бьёт по самому контракту; если же общий валидатор ошибётся в разборе ввода, выборе версии или граничных условиях, то от него могут пострадать все контракты, которые от него зависят. На весь мир распространяется единообразие: можно доказать лишь, что все выполняли одни и те же правила.
На апгрейде Aegis в марте 2026 года Dusk включил PLONK V3 и обновлённое поведение BLS, а запрос BLS хоста, который используют контракты, переключается по высоте блока. Исторические блоки вызывают старый валидатор, а новые данные — уже новую версию; если высоту выбрать неправильно, то по транзакциям можно получить разные выводы по валидности.
Поэтому я не ограничусь чтением отчётов о аудите: я буду следить за версиями валидатора, высотами обновлений, тестовыми векторами, невалидностью кэша и тренировками по откату. $DUSK отвечает за Gas и безопасность консенсуса, но удерживают финансовые приложения на плаву также эти публичные точки входа для валидации. Скорость определяет, насколько быстро сможет работать система, а валидатор определяет, будет ли он так же быстро исполнять и ошибки.
#dusk
Я сверил исторический white paper для @Dusk с текущей документацией. В старых материалах эту Rust/WASM-рантайм среду называли Piecrust, а в актуальной документации используется DuskVM. Название менялось, но ключевая архитектура осталась прежней: контракт может передавать криптографические проверки — например, PLONK, Groth16, BLS и др. — на уровень хоста через публичные точки входа, не реализуя всё это по отдельности.
Преимущества вполне практичны. Разработчикам не нужно писать отдельный комплект криптографического кода, который легко ошибочно реализовать; узлам также не требуется повторять базовые вычисления внутри WASM-песочницы, а приложения становятся легче, а правила валидации — проще и легче унифицировать.
Плата за это тоже сосредоточена в одном месте. Ошибка в контракте обычно прежде всего бьёт по самому контракту; если же общий валидатор ошибётся в разборе ввода, выборе версии или граничных условиях, то от него могут пострадать все контракты, которые от него зависят. На весь мир распространяется единообразие: можно доказать лишь, что все выполняли одни и те же правила.
На апгрейде Aegis в марте 2026 года Dusk включил PLONK V3 и обновлённое поведение BLS, а запрос BLS хоста, который используют контракты, переключается по высоте блока. Исторические блоки вызывают старый валидатор, а новые данные — уже новую версию; если высоту выбрать неправильно, то по транзакциям можно получить разные выводы по валидности.
Поэтому я не ограничусь чтением отчётов о аудите: я буду следить за версиями валидатора, высотами обновлений, тестовыми векторами, невалидностью кэша и тренировками по откату. $DUSK отвечает за Gas и безопасность консенсуса, но удерживают финансовые приложения на плаву также эти публичные точки входа для валидации. Скорость определяет, насколько быстро сможет работать система, а валидатор определяет, будет ли он так же быстро исполнять и ошибки.
#dusk
