#dusk $DUSK @Dusk
Я читал недавние инженерные изменения Dusk и ожидал, что интересная часть будет очередным улучшением в системе доказательств.
Вместо этого я снова и снова возвращался к чему‑то гораздо менее гламурному: что происходит еще до того, как доказательство вообще будет обработано..
Один из недавних Plonk‑связанных изменений был сфокусирован на более раннем отклонении некорректных данных от провера. Сначала это звучит как обычная рутина.
Но чем больше я об этом думал, тем важнее это становилось.
Есть разница между тем, чтобы «сломать» криптографию, и тем, чтобы подать плохие данные в криптографическую инфраструктуру.
Доказательство может быть математически корректным, но данные вокруг него оказываются сформированы неправильно: некорректно сериализованы или структурированы так, как система не ожидала. Если такие входные данные позволить пройти глубже по цепочке доказательств, то последующий сбой становится труднее локализовать и потенциально дороже в обработке.
Так что реальное улучшение — не обязательно в более сильной математике.
Оно в том, чтобы точка отклонения находилась ближе к источнику.
Это важно операционно.
В работающей сети инфраструктура доказательств не функционирует в изоляции. Ей приходится иметь дело с сериализацией/декодированием входных данных, путями выполнения, памятью и всеми странными пограничными случаями, которые возникают, когда программное обеспечение сталкивается с данными реального мира.
Криптография может быть надежной, но окружающая реализация при этом может опираться на слабые допущения.
Именно поэтому я считаю эти небольшие изменения более показательными, чем анонсы функций.
Они показывают, на чем инженерная команда тратит время, чтобы сократить число вещей, которые система готова обрабатывать вслепую.
Для Dusk я думаю, что это важное направление: не просто доказывать, что валидные данные работают, но заставлять невалидные данные падать раньше — чище и ближе к тому месту, где начинается ошибка.
Скучный слой валидации может в итоге рассказать нам больше о производственной готовности, чем когда-либо сможет рассказать эффектная криптография.
Я читал недавние инженерные изменения Dusk и ожидал, что интересная часть будет очередным улучшением в системе доказательств.
Вместо этого я снова и снова возвращался к чему‑то гораздо менее гламурному: что происходит еще до того, как доказательство вообще будет обработано..
Один из недавних Plonk‑связанных изменений был сфокусирован на более раннем отклонении некорректных данных от провера. Сначала это звучит как обычная рутина.
Но чем больше я об этом думал, тем важнее это становилось.
Есть разница между тем, чтобы «сломать» криптографию, и тем, чтобы подать плохие данные в криптографическую инфраструктуру.
Доказательство может быть математически корректным, но данные вокруг него оказываются сформированы неправильно: некорректно сериализованы или структурированы так, как система не ожидала. Если такие входные данные позволить пройти глубже по цепочке доказательств, то последующий сбой становится труднее локализовать и потенциально дороже в обработке.
Так что реальное улучшение — не обязательно в более сильной математике.
Оно в том, чтобы точка отклонения находилась ближе к источнику.
Это важно операционно.
В работающей сети инфраструктура доказательств не функционирует в изоляции. Ей приходится иметь дело с сериализацией/декодированием входных данных, путями выполнения, памятью и всеми странными пограничными случаями, которые возникают, когда программное обеспечение сталкивается с данными реального мира.
Криптография может быть надежной, но окружающая реализация при этом может опираться на слабые допущения.
Именно поэтому я считаю эти небольшие изменения более показательными, чем анонсы функций.
Они показывают, на чем инженерная команда тратит время, чтобы сократить число вещей, которые система готова обрабатывать вслепую.
Для Dusk я думаю, что это важное направление: не просто доказывать, что валидные данные работают, но заставлять невалидные данные падать раньше — чище и ближе к тому месту, где начинается ошибка.
Скучный слой валидации может в итоге рассказать нам больше о производственной готовности, чем когда-либо сможет рассказать эффектная криптография.
