Я начал сомневаться в нарративе DUSK о количестве затворов, когда смоделированный 8-битный XOR снизился с 31 затвора до одного поиска PlonKup. Компрессия выглядит впечатляюще — 96,8%. Но это отражает арифметику схемы, а не реальную скорость доказательства.

Поиск всё равно влечёт обработку таблиц, сортировку коммитментов и нагрузку на память. Поэтому 31× меньше затворов не означает 31× быстрее доказательства. Стоимость может просто переместиться в RAM.

Это важно, потому что рекомендации DUSK для операторов закладывают около 1 ГБ на worker доказательств и 8 ГБ для минимального сервера. Это оценочные цифры, а не измеренный пиковый расход памяти. Недостающий показатель — доказательства на 1 ГБ при нагрузке P50 и P99, особенно при одновременной работе нескольких worker.

Затем — доступность. Что происходит на среднебюджетном телефоне после нагрева, фоновых приложений и повторных доказательств? Если P50 приемлем, но P99 «подвисает», то это становится трением для пользователя, а не просто победой в криптографии.

Я также слежу за некорректными (malformed) доказательствами. Сколько CPU может потребить недопустимый ввод до отказа и насколько ранняя фильтрация экономит ресурсы? Некоторый оверхед нормален. Но неконтролируемое усиление — нет.

DUSK может добиться успеха, если компрессия через lookup улучшит реальную пропускную способность без концентрации доказательств на высокопроизводительном (по памяти) железе. Пока DUSK не опубликует пиковое время доказательства, потребление энергии/памяти и бенчмарки отказа для некорректных доказательств, всё остаётся неполным.

#dusk $DUSK @Dusk