#dusk $DUSK провёл прошлой ночью повторное чтение раздела «Dusk whitepaper» про plonk, и кое-что щёлкнуло, что я упустил...
первые два раза я прошёл мимо.
схема доказательства не просто скрывает значения — она разделяет то, что доказывается, от того, что раскрывается. общедоступные входные данные идут в одну сторону, а приватные остаются.
запертое же, и верификатор узнаёт только, верно ли утверждение.
чтобы это имело смысл, должны выполняться три свойства: полнота. надёжность. нулевое знание.
осведомлённость (knowledge-ness). пропусти одно — и вся заявка на приватность рушится.
интересно, что это не «прикручено» к функции перехода состояний постфактум.
это нативно для rusk vm. каждый путь выполнения может нести
доказательство корректности, не раскрывая саму вычислительную часть.
я не могу до конца понять, как затраты на генерацию доказательства масштабируются, когда логика контракта становится более сложной.
сложно, но да — вот к чему я постоянно возвращаюсь.
любопытно, кто-нибудь ещё копался в настройке ключа верификатора здесь??
#dusk @Dusk $DUSK
первые два раза я прошёл мимо.
схема доказательства не просто скрывает значения — она разделяет то, что доказывается, от того, что раскрывается. общедоступные входные данные идут в одну сторону, а приватные остаются.
запертое же, и верификатор узнаёт только, верно ли утверждение.
чтобы это имело смысл, должны выполняться три свойства: полнота. надёжность. нулевое знание.
осведомлённость (knowledge-ness). пропусти одно — и вся заявка на приватность рушится.
интересно, что это не «прикручено» к функции перехода состояний постфактум.
это нативно для rusk vm. каждый путь выполнения может нести
доказательство корректности, не раскрывая саму вычислительную часть.
я не могу до конца понять, как затраты на генерацию доказательства масштабируются, когда логика контракта становится более сложной.
сложно, но да — вот к чему я постоянно возвращаюсь.
любопытно, кто-нибудь ещё копался в настройке ключа верификатора здесь??
#dusk @Dusk $DUSK