Я нашёл одно техническое изменение, которое было объединено в основную ветку PLONK в Dusk. Оно касается процесса десериализации сжатых цепей: после разбора основного текста, если остаются лишние байты, compile_with_compressed возвращает InvalidCompressedCircuit. Официальные регрессионные тесты специально добавили корректное завершающее значение в формате MessagePack, чтобы подтвердить: до исправления оно принималось, а после — будет отклонено.
Одна и та же сжатая цепь, основной текст идентичен, отличается только тем, что в конец добавлен один посторонний байт. Любая система контроля рисков или кэширования, которая считает хеш по исходным байтам, воспримет это как другой файл; при этом старый PLONK может читать его как обычно.
Увидев это, я, честно говоря, немного обеспокоился. Файл явно изменился, а инструмент утверждает, что «ничего не изменилось». Для финансовых систем это даже хуже, чем прямой сбой: одна и та же сущность получает две «карты личности».
Сначала уточню объект. На этот раз изменяется файл сжатой цепи, который используется для генерации доказательств; доказательства, уже сгенерированные on-chain, в этот диапазон не входят. Последняя сборка Dusk обработала это довольно жёстко: после чтения тела цепи, если дальше остаются лишние байты, весь файл сразу считается недействительным.
Скажу прямо: поначалу мне казалось, что она излишне придирчива. Старые инструменты работают — зачем рубить совместимость из‑за нескольких хвостовых байтов? Но если перенести это в транзакционные системы, всё выглядит иначе. Если исходный файл проходит аудит, кэширование или хранение в репозитории по байтам, то компилятор обрабатывает две разные версии файла как одну и ту же совокупность правил — и потом очень трудно объяснить, какую именно версию использовали.
Это подсказывает мне весьма практичный критерий: после обновления некоторые ZK‑приложения внезапно начинают падать — сначала проверьте InvalidCompressedCircuit, версию инструмента и сможет ли восстановиться работа после повторного экспорта файла. Если старый файл падает, а новый работает — это больше похоже на проблему миграции формата. А если «нормативный» файл массово не проходит, тогда уже стоит глубже копать в логику доказательств или сетевые сбои. Не смешивайте эти два типа рисков на одной линии.
Для $DUSK : такое ужесточение в краткосрочной перспективе может снизить число успешных вызовов и даже временно остановить старые инструменты. Долгосрочная ценность зависит от того, уменьшатся ли после миграции издержки по сбоям доказательств, спорам по версиям и стоимости повторных проверок со стороны организаций. Парсер напрямую не создаёт «покупочный спрос». Его роль — сделать так, чтобы каждая цепь имела только одну «карточку личности».
В транзакциях я не буду считать «хотя бы читается» признаком дружелюбия. Я считаю, что финансовым бухгалтерским книгам нужна законная и однозначная идентичность. DYOR!
#dusk $DUSK @Dusk
Одна и та же сжатая цепь, основной текст идентичен, отличается только тем, что в конец добавлен один посторонний байт. Любая система контроля рисков или кэширования, которая считает хеш по исходным байтам, воспримет это как другой файл; при этом старый PLONK может читать его как обычно.
Увидев это, я, честно говоря, немного обеспокоился. Файл явно изменился, а инструмент утверждает, что «ничего не изменилось». Для финансовых систем это даже хуже, чем прямой сбой: одна и та же сущность получает две «карты личности».
Сначала уточню объект. На этот раз изменяется файл сжатой цепи, который используется для генерации доказательств; доказательства, уже сгенерированные on-chain, в этот диапазон не входят. Последняя сборка Dusk обработала это довольно жёстко: после чтения тела цепи, если дальше остаются лишние байты, весь файл сразу считается недействительным.
Скажу прямо: поначалу мне казалось, что она излишне придирчива. Старые инструменты работают — зачем рубить совместимость из‑за нескольких хвостовых байтов? Но если перенести это в транзакционные системы, всё выглядит иначе. Если исходный файл проходит аудит, кэширование или хранение в репозитории по байтам, то компилятор обрабатывает две разные версии файла как одну и ту же совокупность правил — и потом очень трудно объяснить, какую именно версию использовали.
Это подсказывает мне весьма практичный критерий: после обновления некоторые ZK‑приложения внезапно начинают падать — сначала проверьте InvalidCompressedCircuit, версию инструмента и сможет ли восстановиться работа после повторного экспорта файла. Если старый файл падает, а новый работает — это больше похоже на проблему миграции формата. А если «нормативный» файл массово не проходит, тогда уже стоит глубже копать в логику доказательств или сетевые сбои. Не смешивайте эти два типа рисков на одной линии.
Для $DUSK : такое ужесточение в краткосрочной перспективе может снизить число успешных вызовов и даже временно остановить старые инструменты. Долгосрочная ценность зависит от того, уменьшатся ли после миграции издержки по сбоям доказательств, спорам по версиям и стоимости повторных проверок со стороны организаций. Парсер напрямую не создаёт «покупочный спрос». Его роль — сделать так, чтобы каждая цепь имела только одну «карточку личности».
В транзакциях я не буду считать «хотя бы читается» признаком дружелюбия. Я считаю, что финансовым бухгалтерским книгам нужна законная и однозначная идентичность. DYOR!
#dusk $DUSK @Dusk