#dusk Несколько дней назад я изучил опубликованные Dusk записи об исправлении уязвимостей на низком уровне, а заодно собрал и отладил в локальной среде их последнюю версию кода узла. Выяснилось, что в ходе этой технической проверки действительно затронули самое уязвимое место.
Когда люди следят за проектом, они обычно сосредоточены на колебаниях рынка, а меня больше волнует механизм изоляции памяти в базовой виртуальной машине. Ведь если в процесс хоста проникнут с помощью небезопасной десериализации, внешняя вредоносная нагрузка может напрямую получить несанкционированный контроль над узлом-валидатором. Масштаб такого ущерба несравним с обычной уязвимостью смарт-контракта.$DUSK
Если рассматривать базовые механизмы, прежняя архитектура, жёстко связывавшая возврат комиссии с состоянием пула транзакций, в условиях экстремально высокой параллельной нагрузки могла легко привести к нарушению целостности глобального состояния и даже остановке узла. Ещё сложнее была скрытая проблема в конструкции раннего пути подписи: если уровень консенсуса не может гарантировать уникальность вычислений валидации, под угрозой оказывается окончательная достоверность всего реестра. К счастью, команда переработала проверку подписей, внедрив стандартизированную схему hash-to-curve, и добавила фильтрацию уже на этапе мемпула.$BTC
Однако, на мой взгляд, исправление известных логических уязвимостей и полное устранение структурных рисков на уровне протокола — совершенно разные вещи.
Какими бы тщательно проработанными ни были патчи в кодовой базе, охват обновлениями всех узлов сети и регрессионное тестирование всё равно остаются серьёзным испытанием. Особенно это касается миграции исторических состояний: на стыке старой и новой логики легче всего проявляются непредвиденные пограничные случаи.$ETH
Наблюдая за развитием подобных базовых публичных блокчейнов, я не воспринимаю исправления уязвимостей постфактум как повод слепо ожидать роста. Переработка базового протокола обычно сопровождается поиском динамического баланса между эффективностью исполнения и стабильностью системы.
То, что команда решилась открыто заявить о критических проблемах в базовом коде, безусловно, говорит о строгости инженерного подхода. Но действительно ли сеть выдержит проверку, покажут лишь будущие испытания под высокой нагрузкой в основной сети. Разумнее сохранять сдержанность и не делать поспешных выводов.@Dusk
Когда люди следят за проектом, они обычно сосредоточены на колебаниях рынка, а меня больше волнует механизм изоляции памяти в базовой виртуальной машине. Ведь если в процесс хоста проникнут с помощью небезопасной десериализации, внешняя вредоносная нагрузка может напрямую получить несанкционированный контроль над узлом-валидатором. Масштаб такого ущерба несравним с обычной уязвимостью смарт-контракта.$DUSK
Если рассматривать базовые механизмы, прежняя архитектура, жёстко связывавшая возврат комиссии с состоянием пула транзакций, в условиях экстремально высокой параллельной нагрузки могла легко привести к нарушению целостности глобального состояния и даже остановке узла. Ещё сложнее была скрытая проблема в конструкции раннего пути подписи: если уровень консенсуса не может гарантировать уникальность вычислений валидации, под угрозой оказывается окончательная достоверность всего реестра. К счастью, команда переработала проверку подписей, внедрив стандартизированную схему hash-to-curve, и добавила фильтрацию уже на этапе мемпула.$BTC
Однако, на мой взгляд, исправление известных логических уязвимостей и полное устранение структурных рисков на уровне протокола — совершенно разные вещи.
Какими бы тщательно проработанными ни были патчи в кодовой базе, охват обновлениями всех узлов сети и регрессионное тестирование всё равно остаются серьёзным испытанием. Особенно это касается миграции исторических состояний: на стыке старой и новой логики легче всего проявляются непредвиденные пограничные случаи.$ETH
Наблюдая за развитием подобных базовых публичных блокчейнов, я не воспринимаю исправления уязвимостей постфактум как повод слепо ожидать роста. Переработка базового протокола обычно сопровождается поиском динамического баланса между эффективностью исполнения и стабильностью системы.
То, что команда решилась открыто заявить о критических проблемах в базовом коде, безусловно, говорит о строгости инженерного подхода. Но действительно ли сеть выдержит проверку, покажут лишь будущие испытания под высокой нагрузкой в основной сети. Разумнее сохранять сдержанность и не делать поспешных выводов.@Dusk