#dusk $DUSK @Dusk
Четырёх чисел оказалось достаточно. Путь «Phoenix» в закрытой оболочке Dusk — та часть, которая несёт весь приватностный питч — подтвердил доказательства одним вызовом, и этот вызов никогда не сверял четыре значения селекторов с обязательствами, которые прямо там сидят в ключе верификатора. $DUSK #dusk @Dusk уже прошла три отдельных аудита до того, как это нашли в феврале.
Что меня поразило — форма «промаха» (miss). Селекторы должны быть публичными, фиксированными данными на стороне верификатора в стандартном PLONK. Пользовательские виджеты dusk-plonk заставили их стать числами, предоставляемыми прувером вместо этого, и никто не обновил мысленную модель того, что именно должно быть криптографически связано (binding). Сама логика схемы была в порядке от начала до конца — «разрыв» находился на слой ниже, в проверочном подключении.
Что изменилось для меня — это понимание того, что «аудитировали три раза» не то же самое, что «аудитировали против правильной модели угроз». Рецензент, проверяющий логику ограничений, может спокойно пройти мимо структурного допущения, которое незаметно перестало выполняться. Это сложнее поймать, чем обычную ошибку в коде, и это не уникально для Dusk — тот же паттерн всплыл независимо в Jellyfish у Espresso.
Следующее, что я бы проверил: действительно ли Dusk продвигает стандартизированную спецификацию верификации PLONK и выпускает её, или это так и остаётся тредом для обсуждений.
Четырёх чисел оказалось достаточно. Путь «Phoenix» в закрытой оболочке Dusk — та часть, которая несёт весь приватностный питч — подтвердил доказательства одним вызовом, и этот вызов никогда не сверял четыре значения селекторов с обязательствами, которые прямо там сидят в ключе верификатора. $DUSK #dusk @Dusk уже прошла три отдельных аудита до того, как это нашли в феврале.
Что меня поразило — форма «промаха» (miss). Селекторы должны быть публичными, фиксированными данными на стороне верификатора в стандартном PLONK. Пользовательские виджеты dusk-plonk заставили их стать числами, предоставляемыми прувером вместо этого, и никто не обновил мысленную модель того, что именно должно быть криптографически связано (binding). Сама логика схемы была в порядке от начала до конца — «разрыв» находился на слой ниже, в проверочном подключении.
Что изменилось для меня — это понимание того, что «аудитировали три раза» не то же самое, что «аудитировали против правильной модели угроз». Рецензент, проверяющий логику ограничений, может спокойно пройти мимо структурного допущения, которое незаметно перестало выполняться. Это сложнее поймать, чем обычную ошибку в коде, и это не уникально для Dusk — тот же паттерн всплыл независимо в Jellyfish у Espresso.
Следующее, что я бы проверил: действительно ли Dusk продвигает стандартизированную спецификацию верификации PLONK и выпускает её, или это так и остаётся тредом для обсуждений.