#dusk $DUSK @Dusk
Запуская генерацию доказательства локально, чтобы оценить производительность схемы, я заметил кое-что, из-за чего мне пришлось вернуться и прочитать собственные материалы криптографической команды, а не маркетинговые страницы.
Реальные цифры PLONK — это то, что делает обоснование соответствия работоспособным, а не только «приватность» как таковая. Время верификации держится примерно на уровне 6–9 миллисекунд независимо от размера схемы — время генерации растёт в зависимости от сложности схемы (примерно 5,46 секунды для схемы на 2^16 гейтов на относительно скромном железе), но со стороны верификатора всё остаётся быстрым и константным. Эта асимметрия важнее для регулируемых финансов, чем многие думают: аудитору или контрагенту, проверяющему доказательство, не приходится каждый раз тратить значимые вычисления, даже когда логика базовой транзакции становится сложнее.
Чего я не ожидал, так это того, что у самого PLONK была реально раскрытая уязвимость, а не только теоретический риск. Исследовательская команда Dusk нашла критическую проблему в том, как была реализована трансформация Fiat–Shamir — тот элемент, который превращает интерактивное доказательство в неинтерактивное: вместо того, чтобы отправлять ему проверки «на лету», оно получает хэшируемые вызовы. В исходной реализации публичные входные данные хэшировались недостаточно рано, из-за чего ослаблялась гарантия корректности (soundness). Trail of Bits координировала раскрытие, Dusk успела исправить до мейннета и опубликовала исправление публично, а не оставила его «под сукном».
Эта деталь меня не отпускает — цепочка, ориентированная на соответствие требованиям и построенная на криптографической системе доказательств, в продакшн- или близком к нему коде которой был реальный баг по корректности. Его обнаружили и исправили до того, как это стало по-настоящему важно. Я не знаю, сколько ещё реализаций, использующих PLONK где-то в других проектах, оставались уязвимыми, когда это стало публичным, и как долго длился разрыв между раскрытием и тем, как другие команды закрывали патчами свои форки.
Запуская генерацию доказательства локально, чтобы оценить производительность схемы, я заметил кое-что, из-за чего мне пришлось вернуться и прочитать собственные материалы криптографической команды, а не маркетинговые страницы.
Реальные цифры PLONK — это то, что делает обоснование соответствия работоспособным, а не только «приватность» как таковая. Время верификации держится примерно на уровне 6–9 миллисекунд независимо от размера схемы — время генерации растёт в зависимости от сложности схемы (примерно 5,46 секунды для схемы на 2^16 гейтов на относительно скромном железе), но со стороны верификатора всё остаётся быстрым и константным. Эта асимметрия важнее для регулируемых финансов, чем многие думают: аудитору или контрагенту, проверяющему доказательство, не приходится каждый раз тратить значимые вычисления, даже когда логика базовой транзакции становится сложнее.
Чего я не ожидал, так это того, что у самого PLONK была реально раскрытая уязвимость, а не только теоретический риск. Исследовательская команда Dusk нашла критическую проблему в том, как была реализована трансформация Fiat–Shamir — тот элемент, который превращает интерактивное доказательство в неинтерактивное: вместо того, чтобы отправлять ему проверки «на лету», оно получает хэшируемые вызовы. В исходной реализации публичные входные данные хэшировались недостаточно рано, из-за чего ослаблялась гарантия корректности (soundness). Trail of Bits координировала раскрытие, Dusk успела исправить до мейннета и опубликовала исправление публично, а не оставила его «под сукном».
Эта деталь меня не отпускает — цепочка, ориентированная на соответствие требованиям и построенная на криптографической системе доказательств, в продакшн- или близком к нему коде которой был реальный баг по корректности. Его обнаружили и исправили до того, как это стало по-настоящему важно. Я не знаю, сколько ещё реализаций, использующих PLONK где-то в других проектах, оставались уязвимыми, когда это стало публичным, и как долго длился разрыв между раскрытием и тем, как другие команды закрывали патчами свои форки.