Одна небольшая правка в Rusk многое говорит о том, как Dusk относится к криптографической проверке при обновлениях протокола.
Кэшированный результат больше не привязан только к доказательству и его входным данным. Dusk также связывает этот результат с правилами валидации, которые были активны во время выполнения проверки.
Это важно, потому что одинаковые данные доказательства не всегда означают одинаковый контекст проверки. Обновление протокола может изменить верификатор или политику исполнения, не меняя сами байты доказательства.
Для сети Dusk это становится особенно актуальным, поскольку она строит программируемую приватность для регулируемых рынков — там криптографические доказательства должны оставаться надежными на протяжении обновлений протокола.
Чего я пока не знаю, так это того, достаточно ли Dusk изолировал версионно-специфичные правила, чтобы кэшированный результат никогда не мог пережить семантику, при которой он был признан корректным.
На что стоит обратить внимание: контекст политики исполнения, включенный в ключи кэша; изменения в верификаторе, такие как активация PLONK V3; и что происходит, когда будущие обновления снова изменяют поведение проверки.
Совпадающие байты доказательства — это полезное свидетельство того, что две проверки выглядят одинаково. Но это более слабое доказательство того, что один и тот же кэшированный результат безопасно использовать повторно.
Мне было бы важнее, совпадает ли активный контекст верификатора, а не то, сколько именно работы по проверке Dusk удается кэшировать.
Более глубокий момент в том, что детерминированная проверка зависит не только от фиксации входных данных. Необходимо также зафиксировать правила, по которым эти входные данные интерпретируются.
Вопрос в том, сможет ли Dusk продолжать оптимизировать проверку, не допуская переноса старых семантик протокола через границу обновления в рамках кэша.
Я слежу за тем, как будущие изменения верификатора отражаются в этом контексте политики исполнения.
#dusk $DUSK @Dusk
Кэшированный результат больше не привязан только к доказательству и его входным данным. Dusk также связывает этот результат с правилами валидации, которые были активны во время выполнения проверки.
Это важно, потому что одинаковые данные доказательства не всегда означают одинаковый контекст проверки. Обновление протокола может изменить верификатор или политику исполнения, не меняя сами байты доказательства.
Для сети Dusk это становится особенно актуальным, поскольку она строит программируемую приватность для регулируемых рынков — там криптографические доказательства должны оставаться надежными на протяжении обновлений протокола.
Чего я пока не знаю, так это того, достаточно ли Dusk изолировал версионно-специфичные правила, чтобы кэшированный результат никогда не мог пережить семантику, при которой он был признан корректным.
На что стоит обратить внимание: контекст политики исполнения, включенный в ключи кэша; изменения в верификаторе, такие как активация PLONK V3; и что происходит, когда будущие обновления снова изменяют поведение проверки.
Совпадающие байты доказательства — это полезное свидетельство того, что две проверки выглядят одинаково. Но это более слабое доказательство того, что один и тот же кэшированный результат безопасно использовать повторно.
Мне было бы важнее, совпадает ли активный контекст верификатора, а не то, сколько именно работы по проверке Dusk удается кэшировать.
Более глубокий момент в том, что детерминированная проверка зависит не только от фиксации входных данных. Необходимо также зафиксировать правила, по которым эти входные данные интерпретируются.
Вопрос в том, сможет ли Dusk продолжать оптимизировать проверку, не допуская переноса старых семантик протокола через границу обновления в рамках кэша.
Я слежу за тем, как будущие изменения верификатора отражаются в этом контексте политики исполнения.
#dusk $DUSK @Dusk
