Недавно, в пятницу, 12 августа, мы имели удовольствие провести панель для обсуждения различных приложений ZKP. Мы пригласили шесть замечательных докладчиков из Slush SDK, Neptune, Aztec и o(1) Labs.

Запись доступна на нашем YouTube-канале здесь: https://youtu.be/m5WiIOC3xcM. Вы можете присоединиться к нашему групповому чату Telegram для обсуждения ZKP здесь: delendum.xyz/telegram.

Аго Лайко и Калман Лайко: ZK Rollups для масштабирования приложений

Основная идея продукта заключается в том, что накопительные пакеты для конкретных приложений будут иметь решающее значение для фрактального масштабирования. Команда прогнозирует, что будет много L2, и на этих L2 будут размещаться L3, и большая часть этих L3 будет специфичной для приложений, в том смысле, что будет одна виртуальная машина, на которой работает одно приложение, имеющее значительный контроль. над ВМ.

Здесь в игру вступает Slush SDK. Slush SDK — это приложение с открытым исходным кодом, которое позволяет запускать L3 по запросу. Первоначально начав с внедрения механизма консенсуса Tendermint для работы в StarkNet, чтобы раскручиваемые L3 были децентрализованы. Здесь ключевыми проблемами, которые пытается решить команда, являются создание работающего клиента, работающего на виртуальной машине StarkNet, который может читать Tendermint, а также адаптация Tendermint для работы с подписями STARK.

Однако в этой ситуации будет отсутствовать связь между различными накопительными пакетами для конкретных приложений.

Для решения этой коммуникационной проблемы предлагается реализовать механизм недоверительного моста. Это делается для того, чтобы, когда транзакция происходит на L3, можно было доказать, что эта транзакция произошла на любом из L2, L3 и L1. Это можно сделать, передав ветвь Меркла вне цепочки к различным узлам в L2, L1, которые проверяются путем сравнения с хэшем ветви Меркла, отправленным по цепочке.

Фердинанд Зауэр: Могут ли машины учиться с нулевыми знаниями?

Вообще говоря, для запуска виртуальной машины (ВМ) требуются два входа: программа и вход программы. Запуск виртуальной машины затем производит некоторый вывод. Zk-VM, которая прикрепила к этому доказательству STARK, также производит доказательство. Если вы возьмете эти четыре элемента: (ввод, программа, вывод, доказательство) как четыре кортежа, вы можете использовать верификатор, чтобы гарантировать, что четыре кортежа являются целыми. Zk-VM также имеют третий интерфейс для ввода, обычно называемый «свидетелем» или секретным вводом, который не используется совместно с верификатором.

В машинном обучении термин оценка модели относится к процессу запроса модели с использованием запроса, что приводит к классификации. Использование zk-VM для оценки модели гарантирует, что результат классификации был вычислен честно, гарантируя справедливость для всех входных данных. К сожалению, это предоставляет верификатору доступ к модели, что может быть нежелательно. Используя метод, известный как аттестация программы, модель может оставаться скрытой, в то время как правильное выполнение все еще может быть подтверждено. Один из способов (из нескольких) добиться аттестации программы — предоставить фактическую программу в качестве свидетеля виртуальной машине, публично раскрывая только хеш-дайджест программы.

При обучении модели поток обычно представляет собой ввод данных в алгоритм обучения для получения модели. Мы можем использовать zk-VM и использовать данные в качестве свидетеля, чтобы скрыть данные, но доказать, что алгоритм обучения был применен правильно и не внес смещения. Чтобы расширить это и скрыть модель, вы должны хешировать модель и выводить только дайджест. Затем вы можете получить модель в качестве секретного вывода.

Для уточнения модели, если у вас есть работающая модель, но теперь есть больше новых данных, идеальным будет использовать старую модель и улучшить ее с помощью новых данных. Здесь в игру вступает рекурсия: предоставляя в качестве входных данных доказательство старой модели, можно использовать рекурсивный верификатор для подтверждения правильности старой модели, создавая в результате доказательство для новой модели. Рекурсивная проверка также может использоваться для реализации федеративного машинного обучения: путем распределения обучения по нескольким экземплярам zk-VM, затем объединения всех их моделей и пакетной проверки связанных доказательств новая модель может быть вычислена проверяемым образом.

Потенциал частных смарт-контрактов: Майкл Коннор

В настоящее время в Эфириуме вся информация, такая как переменные состояния, входные данные и вычисления, общедоступна. Кроме того, транзакции в основной сети Ethereum обходятся очень дорого из-за платы за газ и перегрузки сети.

Первой итерацией Aztec были zk-money, которые просто сделали функцию передачи контракта ERC-20 частной, однако это все еще было дорого, как и в основной сети. Затем был изобретен Aztec L2, который представлял собой пакет, позволяющий получать дешевые частные деньги.

Aztec Connect — это самый последний выпуск, в котором реализованы две новые функции, помимо функции передачи ERC-20: депозиты DeFi и требования DeFi. Это позволило пользователям взаимодействовать с большим количеством смарт-контрактов в частном порядке. Это работает через установленный пул частных контрактов и развернутый промежуточный контракт. Таким образом, анонимность сохраняется, но суммы являются общедоступными. Существует также дозирование для оптимизации газа. Тем не менее, много информации по-прежнему остается общедоступной: входные данные L1, состояния, вычисления и контракты.

Следующая итерация также будет поддерживать частные функции и частные состояния, которые недоступны в основной сети или на каком-либо L2. Следовательно, структура будет состоять из трех слоев, как показано ниже:

Вместо традиционных цепочек блоков или накопительных пакетов, в которых вычисления выполняются лидером блока или секвенсором, изменение частного состояния вычислений должно выполняться на устройстве пользователя, чтобы сохранить конфиденциальность и предотвратить утечки.

Кроме того, в настоящее время у нас есть компонуемость в функциях, где функции могут вызывать другие функции, и компонуемость в смарт-контрактах. Чтобы также включить компонуемость с цепями, необходима схема проверки, чтобы убедиться, что вы придерживаетесь всех правил платформы смарт-контрактов. Затем это позволяет схемам вызывать другие схемы, что приводит к рекурсии! Это помогает разрабатывать и оптимизировать доказательства с нулевым разглашением на окончательном частном уровне 2.

Фил Келли и Брэндон Кейс: сканирование новых дел

Пробежимся по некоторым новым способам использования ZKP. Во-первых, это частные транзакции, которые включают защищенные протоколом учетные записи и транзакции. А также приватная транзакция на уровне D-App, аналогичная миксерам.

Во-вторых, это идентичность, захватывающая горячая область прямо сейчас. Множество новых стартапов в индивидуальной привязке идентификатора реального мира к уникальной/связанной группе адресов в цепочке (PoH). Подтвержденные учетные данные без доксинга в виде непередаваемых NFT или доказательств вне сети также потребуются в пространстве, которое помогает в борьбе со спамом, голосовании и других формах закрытого взаимодействия.

Использование ZKP в оракулах может помочь вам замаскировать наборы данных и сохранить некоторую конфиденциальность в отношении специфики, например, кредитные рейтинги. Наконец, мосты с функциями сохранения конфиденциальности, подобные мосту Mina-ETH Mina, построенному nil-Foundation, являются очень интересной областью, в которой, как ожидается, будет гораздо больше инноваций.

Нынешний ландшафт вычислений ZK с блокчейнами можно разделить на следующие три категории:

  1. Ончейн-вычисления на типичных платформах смарт-контрактов. (не включает расчет ZK).
  2. Самостоятельный ZK: (по крайней мере, один рекурсивный уровень) - Доказательства произошли на стороне клиента, утечка личных данных контрагенту.
  3. Типичные свертки ZK: вычисления вне (основной) цепи, выполняемые контрагентом.

Использование рекурсии, которое ранее не изучалось, может быть классифицировано как многопартийная самостоятельная рекурсия ZK. Это когда рекурсивная композиция происходит на стороне клиента на разных этапах вычислений. Это интересная и растущая область для обсуждения и практики в области ZKP — в будущем будет больше!

Мы проводим ежемесячные панельные дискуссии и публикуем исследовательские блоги. Если вы хотите поделиться своими идеями или обратиться за советом, обзором или совместной публикацией, не стесняйтесь обращаться к нам по адресу [email protected].