Я просматривал недавние инженерные работы Dusk и ожидал, что самое интересное окажется очередным улучшением системы верификации.
Вместо этого я застрял на куда менее захватывающем:
как система обрабатывает некорректные данные от проверяющего до того, как они углубятся в конвейер..
Недавнее изменение, связанное с Plonk, было сосредоточено на более раннем отклонении некорректно сформированных данных.
На первый взгляд это звучит как рутинная инженерная работа.
Но здесь есть важное различие.
Криптографическое доказательство может быть математически корректным, тогда как данные, несущие это доказательство, либо окружение вокруг него, могут быть неправильно сериализованы или просто не соответствовать тому, что реализация ожидает.
Если такие данные зайдут слишком далеко в процесс построения доказательства, сбои становится сложнее изолировать и, возможно, дороже устранять.
Поэтому улучшение не обязательно связано с усилением криптографии.
Речь о том, чтобы система меньше слепо доверяла входным данным.
Это особенно важно, когда система доказательств работает как производственная инфраструктура, а не просто демонстрирует, что лежащая в основе математика действительно работает.
Реальным системам приходится иметь дело с сериализацией, декодированием, управлением памятью, путями выполнения и неожиданными входами.
Математика может быть правильной, а окружающее ее программное обеспечение — всё ещё опираться на слабые предположения.
Именно поэтому эти небольшие инженерные изменения привлекают мое внимание.
Анонсы функций показывают, что протокол хочет построить…
Подобные изменения показывают, чему команда учится в том, что действительно может пойти не так.
Для Dusk то, что они раньше «выталкивают» невалидные данные, ощущается как небольшое изменение с гораздо более значительным последствием:
production grade ZK-инфраструктура — это не только про то, чтобы правильно доказывать корректные утверждения.
Это также про то, чтобы невалидные вещи терпели неудачу безопасно, предсказуемо и как можно раньше.
#dusk @Dusk $DUSK
$TUT
$UAI
Вместо этого я застрял на куда менее захватывающем:
как система обрабатывает некорректные данные от проверяющего до того, как они углубятся в конвейер..
Недавнее изменение, связанное с Plonk, было сосредоточено на более раннем отклонении некорректно сформированных данных.
На первый взгляд это звучит как рутинная инженерная работа.
Но здесь есть важное различие.
Криптографическое доказательство может быть математически корректным, тогда как данные, несущие это доказательство, либо окружение вокруг него, могут быть неправильно сериализованы или просто не соответствовать тому, что реализация ожидает.
Если такие данные зайдут слишком далеко в процесс построения доказательства, сбои становится сложнее изолировать и, возможно, дороже устранять.
Поэтому улучшение не обязательно связано с усилением криптографии.
Речь о том, чтобы система меньше слепо доверяла входным данным.
Это особенно важно, когда система доказательств работает как производственная инфраструктура, а не просто демонстрирует, что лежащая в основе математика действительно работает.
Реальным системам приходится иметь дело с сериализацией, декодированием, управлением памятью, путями выполнения и неожиданными входами.
Математика может быть правильной, а окружающее ее программное обеспечение — всё ещё опираться на слабые предположения.
Именно поэтому эти небольшие инженерные изменения привлекают мое внимание.
Анонсы функций показывают, что протокол хочет построить…
Подобные изменения показывают, чему команда учится в том, что действительно может пойти не так.
Для Dusk то, что они раньше «выталкивают» невалидные данные, ощущается как небольшое изменение с гораздо более значительным последствием:
production grade ZK-инфраструктура — это не только про то, чтобы правильно доказывать корректные утверждения.
Это также про то, чтобы невалидные вещи терпели неудачу безопасно, предсказуемо и как можно раньше.
#dusk @Dusk $DUSK
$TUT
$UAI