Архитектура Системы Доказательства с Нулевым Разглашением, а также ее цикл.
1. Конструкция ZKP
Давайте вернёмся к определению zk-SNARK. Цель состоит в том, чтобы позволить доказывающей стороне доказать, что она знает секретный ввод, w, не раскрывая w. Для этого мы пишем программу, которая принимает секретный ввод вместе с другими параметрами и затем генерирует выходные данные, которые мы можем проверить с нашим ожидаемым результатом.
Вкратце, мы должны иметь возможность проверить выходные данные программы, не раскрывая ничего о секретном вводе. Первым шагом в создании системы доказательств является определение этой программы. В нашем случае мы предполагаем очень простой сценарий:
Доказывающая сторона хочет доказать проверяющей стороне, что она знает некоторое значение w, которое, будучи возведенным в квадрат и умноженным на два, равно 50. Мы можем преобразовать этот сценарий в программу:
2 * (w²) == 50;
Программа возвращает истину, если 2 * (w²) равно 50.
Теперь, эта программа отличная, но мы не можем с ней много сделать в её текущем состоянии. Чтобы сгенерировать “доказательство”, нам нужно преобразовать эту программу в что-то, что поддается математическому анализу. В конце концов, доказательство является математическим объектом, как мы обсуждали в предыдущем посте. Это приводит нас к следующему шагу: аритметизация.
2. Арифметизация
Арифметизация — это процесс преобразования программы, которая может содержать произвольно сложные утверждения и выражения, в последовательность утверждений, принимающих одну из двух форм:
x = y
x = y[оператор]z
Оператор может быть сложением или умножением. Таким образом, мы фактически преобразуем программу и “сплющиваем” её в серию утверждений.
Вы можете представить каждое утверждение как логические элементы в физической схеме.
Каждый элемент имеет два входа и один выход. В зависимости от типа элемента, два входа будут преобразованы в некоторый выход. Например, для элемента “И” с двумя входами 1 и 0 выход будет 0.
Точно так же мы берем первоначальную программу, которую мы определили на этапе вычисления, и превращаем ее в серию последовательных “элементов”. Это называется “сплющиванием”, потому что вы буквально сплющиваете первоначальную программу в логические элементы.
Но зачем это? Это позволяет нам превратить нашу программу в серию “ограничений”, которые должны быть выполнены. В конце концов, элемент — это просто объект, который позволяет нам определить два входа и ожидаемый выход. Таким образом, каждый “элемент” представляет собой ограничение, а серия элементов — это “схема”.
Давайте воплотим это в действие. Используя наш пример выше, мы можем представить элементы следующим образом:
out1 = w * w
out2 = out1 * 2
output = out2–50
Как только мы преобразуем нашу программу в ограничения, мы можем сформулировать “Проблему Удовлетворения Схемы”, которую мы опишем далее!
3. Проблема Выполнимости Схемы
Итак, мы только что выяснили, как определить набор ограничений. Теперь нам нужно убедиться, что эти ограничения соблюдаются. Это позволит нам проверить, соответствует ли выход тому, что утверждает доказывающая сторона.
Представьте это как математический объект, состояние которого должно удовлетворять нескольким ограничениям. Мы просто проверяем, что ограничения соблюдаются, превращая нашу схему в математическую проблему.
Как это работает? Ну, чтобы создать CSP, мы просто берем схему, которую мы определили на последнем шаге, и превращаем ее в полином. Используя полиномы, мы можем проверить, соблюдаются ли все ограничения — независимо от того, сколько их! Это становится возможным благодаря своду их к полиномиальному уравнению, так что мы можем проверить, соблюдаются ли они все сразу.
4. Информационно-теоретический протокол
Теперь, когда у нас есть математический подход к верификации решения, следующим шагом является определение того, как доказывающая сторона и проверяющая сторона могут взаимодействовать для создания и проверки доказательства. Это называется “Информационно-теоретический протокол”.
Это тот шаг, на котором мы решаем, какие предположения сделать, когда доказывающая сторона и проверяющая сторона взаимодействуют. Как только у нас будет система доказательств с информационно-теоретической базой, всё, что нам осталось сделать, — это использовать крипто-компилятор для преобразования его в систему доказательств реального мира.
5. Криптографический Компилятор
Криптографический компилятор устраняет необходимость идеализированных свойств, которые создает информационно-теоретический протокол. Это довольно просто — криптографические компиляторы используют криптографию, чтобы “заставить” доказывающую сторону и проверяющую сторону вести себя ограниченным образом. Поскольку доказывающая сторона и проверяющая сторона действуют ограниченно (и, следовательно, предсказуемо), нам больше не нужно предполагать идеальные сценарии, такие как наличие неограниченных ресурсов.
Результатом работы криптографического компилятора является система доказательств со всеми искомыми нами свойствами, такими как нулевое разглашение, краткость и неинтерактивность.
Давайте рассмотрим конкретные примеры
Пример 1
Информационно-теоретический протокол может предполагать, что доказывающая сторона и проверяющая сторона взаимодействуют туда и обратно. В этом случае доказывающая сторона отправляет “обязательство” к некоторому полиному, проверяющая сторона отправляет случайно сгенерированное “значение вызова” доказывающей стороне, а затем доказывающая сторона вычисляет окончательное доказательство на основе обоих: обязательства и вызова.
Вместо того чтобы проверяющая сторона случайным образом генерировала и отправляла значение вызова доказывающей стороне, мы можем использовать альтернативу, такую как трансформация Фиата-Шамира, которая позволяет доказывающей стороне вычислять значение самостоятельно, используя случайную функцию (например, криптографическую хеш-функцию). Просто имейте в виду, что определение входных данных для хеш-функции так, чтобы доказательство не могло быть подделано, может быть сложным на практике.
Пример 2
Давайте рассмотрим еще один пример того, как криптографический компилятор устраняет идеализированные предположения. Информационно-теоретический протокол может предполагать, что мы можем доверять доказывающей стороне, что она никогда не изменит свое доказательство на основе вопросов от проверяющей стороны. Конечно, в реальных условиях это идеальное предположение не работает. Здесь в игру вступает криптографическое понятие “схемы обязательств”.
Схема обязательств позволяет человеку “обязаться” выбранным значением или утверждением, сохраняя его в тайне от других, с возможностью позже раскрыть принятое значение. Человек не может изменить значение или утверждение после того, как он к нему обязался. Это означает, что схема обязательств скрывает (то есть скрывает значение) и связывает (то есть значение не может быть изменено).
Таким образом, криптографический компилятор использует схему обязательств для устранения предположения, которое делает Информационно-теоретический протокол, о наличии доверенной доказывающей стороны.
Пример 3
Давайте рассмотрим последний пример. Информационно-теоретический протокол может предполагать, что у нас есть доступ к некоторому случайному оракулу, который позволяет нам генерировать абсолютно случайные значения, которые проверяющая сторона может использовать для вызова доказывающей стороны. Однако доступ к случайному оракулу не практичен в реальных условиях, поэтому криптографический компилятор может вместо этого добавить фазу “настройки”, где эти случайные значения генерируются заранее.
6. Система Доказательств
После того как информационно-теоретический протокол трансформирован с использованием криптографического компилятора, у нас есть система доказательств.
7. Фронтенд и бэкенд
За фронтенд принято считать первые три пункта этой статьи, а за бэкенд — пункты 4–6. Различие между ними становится действительно важным, как только вы осознаете, что различные инструменты и подходы созданы специально для каждого пункта.
Оставайтесь любознательными, продолжайте учиться и углубляйтесь в экосистему Aleo — путешествие только начинается. Присоединяйтесь к сообществу здесь:
