Одна невелика зміна в Rusk багато що каже про те, як Dusk ставиться до криптографічної верифікації під час оновлень протоколу.
Кешований результат більше не прив’язаний лише до доказу та його вхідних даних. Dusk також прив’язує цей результат до правил верифікації, які були активними на момент виконання перевірки.
Це важливо, тому що ідентичні дані доказу не завжди означають ідентичний контекст верифікації. Оновлення протоколу може змінити верифікатор або політику виконання, не змінюючи самі байти доказу.
Для мережі Dusk це стає особливо актуальним, оскільки вона створює програмовану приватність для регульованих ринків, де криптографічні докази мають залишатися надійними через оновлення протоколу.
Чого я поки що не знаю, так це чи ізолювала Dusk ці специфічні для версій правила настільки жорстко, щоб кешований результат ніколи не пережив семантику, яка зробила його дійсним.
Деталі, за якими варто стежити, — це контекст політики виконання, включений у ключі кешу, зміни верифікатора, такі як активація PLONK V3, і те, що станеться, коли майбутні оновлення знову змінять поведінку верифікації.
Збіг байтів доказу — це корисний доказ того, що дві перевірки виглядають однаково. Але це слабший доказ того, що один і той самий кешований результат безпечно повторно використовувати.
Мене більше цікавило б, чи досі активний контекст верифікатора збігається, ніж те, скільки роботи з верифікації Dusk вдається кешувати.
Глибша думка полягає в тому, що детермінована верифікація залежить не лише від фіксації вхідних даних. Правила, які використовуються для інтерпретації цих даних, теж мають бути фіксованими.
Питання в тому, чи може Dusk продовжувати оптимізувати верифікацію, не дозволяючи старій семантиці протоколу перетнути межу оновлення через кеш.
Я стежу за тим, як майбутні зміни верифікатора відображаються в цьому контексті політики виконання.
#dusk $DUSK @Dusk
Кешований результат більше не прив’язаний лише до доказу та його вхідних даних. Dusk також прив’язує цей результат до правил верифікації, які були активними на момент виконання перевірки.
Це важливо, тому що ідентичні дані доказу не завжди означають ідентичний контекст верифікації. Оновлення протоколу може змінити верифікатор або політику виконання, не змінюючи самі байти доказу.
Для мережі Dusk це стає особливо актуальним, оскільки вона створює програмовану приватність для регульованих ринків, де криптографічні докази мають залишатися надійними через оновлення протоколу.
Чого я поки що не знаю, так це чи ізолювала Dusk ці специфічні для версій правила настільки жорстко, щоб кешований результат ніколи не пережив семантику, яка зробила його дійсним.
Деталі, за якими варто стежити, — це контекст політики виконання, включений у ключі кешу, зміни верифікатора, такі як активація PLONK V3, і те, що станеться, коли майбутні оновлення знову змінять поведінку верифікації.
Збіг байтів доказу — це корисний доказ того, що дві перевірки виглядають однаково. Але це слабший доказ того, що один і той самий кешований результат безпечно повторно використовувати.
Мене більше цікавило б, чи досі активний контекст верифікатора збігається, ніж те, скільки роботи з верифікації Dusk вдається кешувати.
Глибша думка полягає в тому, що детермінована верифікація залежить не лише від фіксації вхідних даних. Правила, які використовуються для інтерпретації цих даних, теж мають бути фіксованими.
Питання в тому, чи може Dusk продовжувати оптимізувати верифікацію, не дозволяючи старій семантиці протоколу перетнути межу оновлення через кеш.
Я стежу за тим, як майбутні зміни верифікатора відображаються в цьому контексті політики виконання.
#dusk $DUSK @Dusk
