ZK-rollup: доказательство перехода состояния
В optimistic-модели мы рассматривали оспаривание утверждения о состоянии. Теперь изучим rollup, который использует доказательство корректности перехода. Учебная библиотека по-прежнему публикует отпечаток курса 17; меняется основание проверки слоя, а не значение самого CourseCatalog.
Результат урока — схема validity proof с явными публичными данными и ограничениями. Мы не строим схему, не генерируем доказательство и не выбираем реальную сеть. Название ZK-rollup не будем превращать в обещание анонимности читателя или мгновенного завершения любой операции.
Какое утверждение проверяется
Исполняющий слой получает набор операций и новое состояние. Доказывающая сторона формирует доказательство, относящееся к предусмотренному переходу. Проверяющая программа принимает доказательство вместе с необходимыми публичными входами. При успешной проверке устанавливается определённое отношение, заданное системой, а не любое утверждение на веб-странице оператора.
Для нашего примера смысл перехода связан с исполнением контрактного состояния. Вызов без полномочия publisher не должен обновлять запись курса, если именно это требуется исходным кодом и правилами вычисления. Проверка доказательства не является голосованием о качестве урока. Она относится к вычислительной корректности объявленного перехода в согласованной модели.
операции и прежнее состояние → вычисление B
→ новое состояние + доказательство
публичные входы + доказательство → verifier в предусмотренном слоеПубличные входы связывают проверку с конкретным утверждением. Если доказательство относится к другой версии правил или другому контексту, оно не подтверждает наш переход автоматически. Поэтому важны проверяющая программа, параметры системы и способ связывания данных.
Доказательство и доступность
Участник может получить подтверждение корректности перехода, не получив весь учебный HTML. Это закономерно: данные приложения находятся вне реестра. Более того, доказательство корректности не восстанавливает все входы состояния из короткой записи. Доступность необходимых протокольных данных рассматривается отдельно, как в предыдущем уроке.
Если система использует внешнюю модель доступности, её зависимость входит в досье. Наличие validity proof не делает такую архитектуру автоматически идентичной rollup с другой публикацией данных. Для библиотеки нужно исследовать, способен ли независимый участник восстановить нужное состояние и действовать при отказе оператора.
Не смешиваем три результата: доказательство принято, сведения доступны для требуемой процедуры, материалы курса получены. Все они полезны, но каждый подтверждается своим маршрутом. Общая зелёная отметка без объяснения скрыла бы отказ хранения или неизвестную свежесть объявления.
Почему ZK не означает скрытый сайт
Zero knowledge описывает определённое свойство доказательственной системы относительно скрытых данных. Но конкретный rollup может публиковать операции и состояние, необходимые его участникам. Пользовательский адрес, действия и сетевые обращения не исчезают по одному названию технологии. Для приватного приложения нужно отдельно определить, какие сведения публичны и что скрывается.
Учебная библиотека пока открыто объявляет манифест и courseId. Проверка перехода не скрывает факт публикации. Если читатель получает файл через шлюз, наблюдение этого запроса имеет собственную модель приватности. Она не решается доказательством корректности сетевого состояния.
Позже рассмотрим скрытый witness для конкретного учебного права. Это другое прикладное отношение и другой набор публичных входов. Нельзя обещать, что использование одного ZK-rollup уже предоставило такое право или анонимность. Термины похожи, а проверяемые утверждения различаются.
Время получения результата
Операция может быстро появиться в исполняющем слое, а подготовка и принятие доказательства происходят позже. Далее важны подтверждение соответствующего базового слоя и правила конкретного выхода. Поэтому нет универсального вывода «доказательства значит ждать не нужно». Досье сохраняет фактические стадии выбранной системы.
Для карточки курса приложение может показать наблюдённое состояние B с отдельной меткой. Если требуется более сильное основание для необратимого действия, политика ждёт предусмотренного этапа. Срок определяется текущим протоколом и назначением операции, а не временем анимации в интерфейсе.
При задержке доказывающего процесса некоторые стадии остаются незавершёнными. Это не обязательно означает неверные байты публикации. Оператор должен различать отсутствие доказательства, отрицательную проверку и отсутствие свежего наблюдения. Для каждого случая продукт формулирует понятное действие, не исправляя прежний манифест ради смены статуса.
Проверяющие программы тоже имеют версии
Verifier является частью доверенной конфигурации. Если он обновляется, приложение исследует полномочия и правила перехода между версиями. Доказательство, созданное для одной схемы, не обязано приниматься другой. Нельзя сохранить только красивое название сети и забыть о действующих параметрах проверки.
В некоторых системах важны дополнительные предпосылки подготовки параметров; в других конструкциях они устроены иначе. Учебный курс не выбирает одну гарантию для всех ZK-систем. Досье фиксирует конкретную конструкцию, источники параметров и границы её применения. Это техническое основание уверенности, а не рекламная характеристика.
Ошибочный verifier способен изменить практический смысл успешной проверки. Поэтому проверка переходов не отменяет анализа самого протокола и обновлений. Для собственного приложения сохраняется также ревизия ABI и контрактной логики, с которой связывается выпуск библиотеки.
Для отдельного события публикации следует учитывать также границу доказанного набора. Правильное доказательство перехода одной группы операций не подтверждает произвольный более поздний ответ RPC. Если браузер отображает уже последующее состояние, оно имеет свой контекст и этап. Досье связывает наблюдение с определённым состоянием, а не распространяет однажды полученную гарантию на весь будущий поток. Такая точность особенно полезна после остановки оператора: приложение может знать последнее подтверждённое основание и одновременно не знать результат новой отправки. Эти два знания сохраняются рядом без ложного противоречия.
Изменённый пример библиотеки
Допустим, в новой редакции смарт-контракта ошибочно разрешили любому адресу вызвать публикацию. Доказательство корректного исполнения такого кода может успешно подтверждать нежелательное обновление. Оно не знает организационного намерения редакции, если оно не выражено правилами. Исправление требует новой правильной логики и управляемого перехода, а не требования «более сильного доказательства» той же ошибки.
Во втором случае код правильный, но браузер читает чужой экземпляр с таким же ABI. Проверка уровня сети не удостоверяет, что приложение выбрало наш адрес. Конфигурационная принадлежность остаётся отдельным условием. Именно поэтому исходное досье содержит сеть, адрес и издательское полномочие.
Для учебного результата записываем, какой переход доказывается, какие данные публичны, где находятся нужные входы, как выбирается verifier и какие стадии наблюдает клиент. Основания описаны в первичной документации ZK-rollups. Доказательства и проверки в текущей работе не исполнялись; следующая глава уточнит язык финальности пользовательских действий.