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