Доказательства с нулевым разглашением: применение в Solana

Введение

Это вторая статья из вводной серии о доказательствах с нулевым разглашением. Перед ее прочтением настоятельно рекомендую ознакомиться со статьей «Доказательства с нулевым разглашением: введение в основы». В ней изложен необходимый контекст: базовая теория, математика и криптография, на которых строится анализ в этой статье. Предполагается, что читатель знаком с этими темами. Поэтому, если вы ничего не знаете о доказательствах с нулевым разглашением, настоятельно рекомендую сначала прочитать предыдущую статью. Цель этой статьи — дать вам знания, необходимые для участия в обсуждении доказательств с нулевым разглашением в Solana и даже для разработки новых инновационных примитивов с нулевым разглашением.

Теперь, обладая этими знаниями, мы наконец можем спросить: что такое доказательства с нулевым разглашением? Как их используют в Solana?

Что такое доказательства с нулевым разглашением?

Теперь, когда мы наконец разобрались в необходимой теории, математике и криптографии, пора спросить: что именно представляет собой доказательство с нулевым разглашением?

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

Существует два типа утверждений, которые можно доказывать с нулевым разглашением. На высоком уровне это:

• Утверждения о фактах (например, этот конкретный граф допускает трехцветную раскраску)
• Утверждения о знаниях (например, я знаю разложение N на множители)

Первое утверждение в конечном счете касается некоторого неотъемлемого свойства Вселенной — чего-то фундаментально истинного, например 1 + 1 = 2. Второй тип называется доказательством знания. Оно выходит за рамки простого доказательства истинности и опирается на то, что известно Доказывающей стороне.

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

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

 zk-SNARK и схемы

zk-SNARK — это краткий неинтерактивный аргумент знания. Такие доказательства с нулевым разглашением особенно эффективны и компактны, то есть кратки. Доказательство считается кратким, если и его размер, и время проверки растут медленнее, чем объем проверяемых вычислений. Поэтому для получения краткого доказательства нельзя заставлять проверяющую сторону выполнять работу на каждом раунде хеширования, иначе время проверки будет пропорционально объему вычислений. Краткие доказательства возможны благодаря многочленам и эвристике Фиата — Шамира.

Независимо от сложности доказываемого утверждения, zk-SNARK сохраняют небольшой размер доказательства и позволяют проверять его относительно быстро. Именно поэтому zk-SNARK так привлекательны для роллапов: они позволяют доказать действительность всех транзакций определенного L2, причем доказательство достаточно мало для проверки на L1. Такие протоколы, как Mina, идут еще дальше и используют рекурсивные доказательства. Это позволяет проверять всю историю блокчейна с помощью доказательства постоянного размера. Pickles — новая система доказательств Mina и связанный набор инструментов. Это первая развернутая система zk-SNARK, поддерживающая рекурсивную композицию без доверенной установки. Под рекурсивной композицией здесь подразумеваются схемы.

Схемы описывают вычисление, которое требуется доказать. Это последовательность математических операций, принимающая входные данные и создающая выходные. В доказательствах с нулевым разглашением схемы позволяют представить вычисления, выполненные корректно, не раскрывая их входные данные. Общий рабочий процесс выглядит так:

• Написание и компиляция схемы — Схему необходимо написать и скомпилировать. В простейшем случае можно создать арифметическую схему над конечным полем, заданным простым числом p = 7, с вычислением x * y = z. Общая идея состоит в том, чтобы представить доказываемое вычисление как набор ограничений между переменными, свести эти ограничения к полиномиальным уравнениям и написать код, отображающий все значения определенным образом в новую алгебраическую структуру (то есть реализующий гомоморфизм). Компиляция создаст несколько артефактов, включая набор заданных схемой ограничений и скрипт или исполняемый файл для последующих этапов
• Церемония доверенной установки — В зависимости от типа zk-SNARK может потребоваться церемония для создания ключей доказательства и проверки
• Выполнение схемы — Схема выполняется как программа с помощью скрипта или исполняемого файла, созданного при компиляции. Пользователь вводит публичные и приватные входные данные, после чего вычисляются значения всех промежуточных и выходных переменных. Запись всех этапов вычисления называется свидетелем или трассой
• Создание доказательства — Используя ключ доказательства со второго этапа и свидетельство с третьего, доказывающая сторона может создать доказательство с нулевым разглашением того, что все заданные схемой ограничения соблюдены, раскрыв только выходное значение. Это доказательство отправляется проверяющей стороне
• Проверка доказательства — Проверяющая сторона использует отправленное доказательство и ключ проверки, чтобы проверить его корректность для публичного результата

Некоторые типы zk-SNARK, например Groth16, требуют отдельной доверенной установки для каждой схемы. Это создает трудности, поскольку для каждой новой программы приходится проводить новую церемонию. Другим zk-SNARK, например PlonK, достаточно одной универсальной доверенной установки, что упрощает весь процесс. А некоторые другие типы доказательств с нулевым разглашением, например zk-STARK, вообще не требуют доверенной установки.

zk-STARK

zk-STARK — это масштабируемый прозрачный аргумент знания. zk-STARK были изобретены StarkWare и впервые предложены в этой статье 2018 года как альтернатива zk-SNARK. По сути, они позволяют блокчейнам передавать вычисления единой внеблокчейновой доказывающей стороне STARK и проверять целостность этих вычислений с помощью ончейн-проверки STARK. 

zk-STARK считаются доказательствами с нулевым разглашением, поскольку блокчейн не получает входные данные, используемые внеблокчейновой доказывающей стороной, что сохраняет конфиденциальность пользователя. zk-STARK масштабируемы, поскольку перенос вычислений за пределы блокчейна значительно снижает расходы на проверку в L1. Размер их доказательств также растет линейно, тогда как у zk-SNARK — квазилинейно. Кроме того, zk-STARK не зависят от сложных церемоний доверенной установки, которые, по мнению их создателей, подвержены риску токсичных отходов: если церемония проведена неправильно, проверяющие стороны могут принять недействительные доказательства. Вместо этого zk-STARK используют публично проверяемую случайность для настройки взаимодействия между доказывающими и проверяющими сторонами. Такие доказательства может создать только внеблокчейновая доказывающая сторона, фактически выполнившая вычисление вместе с необходимыми вспомогательными входными данными.

zk-STARK устраняют ограничения zk-SNARK благодаря масштабируемости и прозрачности аргументов знания. Они также основаны на гораздо более простых криптографических предположениях и полностью обходятся без таких элементов, как эллиптические кривые. Вместо этого они полагаются исключительно на хеши и теорию информации, что обеспечивает им устойчивость к квантовым вычислениям. Однако размер доказательства составляет несколько сотен килобайт. Это может ограничить применимость zk-STARK в средах с ограниченной пропускной способностью или объемом хранилища, например в блокчейнах. Обратите внимание, что некоторые более сложные конфигурации доказательств и zkVM используют рекурсивное доказательство zk-STARK внутри zk-SNARK только на заключительном этапе проверки.

ZK Compression

Проблема роста состояния

Одна из самых острых проблем Solana — рост состояния. Для понимания проблемы: состояние Solana хранится на дисках полных нод в Accounts DB. Это хранилище «ключ — значение», где каждая запись базы данных называется аккаунтом. Адрес каждого аккаунта занимает 32 байта, а объем хранимых в нем данных может составлять от 0 до 10 МБ. Сейчас хранение 10 МБ данных стоит примерно 70 SOL независимо от того, размещены ли они в одном аккаунте размером 10 МБ или в тысяче аккаунтов по 10 КБ. Ежедневно в блокчейн добавляется около одного миллиона новых аккаунтов. Согласно публикации Toly о проблеме роста состояния, их общее число уже превышает 500 миллионов. По мере роста Solana это создаст несколько проблем: неограниченный размер снимков, ограничения пропускной способности PCI, индексация аккаунтов и дорогостоящее управление оперативной памятью и дисками. 

Текущий размер полного снимка составляет около 70 ГБ, что приемлемо для современного оборудования. Однако непрерывный рост неизбежно приведет к неэффективному управлению состоянием и потенциальным узким местам. По мере увеличения снимка значительно возрастает время, необходимое для холодной загрузки новой системы после аппаратного сбоя. Это может иметь серьезные последствия при перезапуске сети. 

Пропускная способность Peripheral Component Interconnect (PCI) — это скорость передачи данных между CPU и периферийными устройствами, например видеокартами, сетевыми картами и накопителями. PCI Express (PCIe) — стандарт высокоскоростного интерфейса, созданный для замены устаревшего PCI и повышения скорости передачи данных. Пропускная способность новейшей версии PCI может достигать 1 ТБ, или 128 ГБ/с. Это кажется большим значением, но не в контексте Solana. Если транзакция считывает или записывает 128 МБ, то пропускная способность PCI в 128 ГБ/с ограничит Solana 1000 транзакций в секунду (TPS). Однако большинство транзакций обращаются к недавно использованным данным, уже загруженным и кешированным в оперативной памяти валидатора. Тем не менее эффективное хранение состояния в памяти критически важно для сохранения высокой пропускной способности по мере масштабирования Solana. Иначе пропускная способность PCI быстро станет ограничивающим фактором.

Каждый валидатор должен поддерживать индекс всех существующих аккаунтов. Это необходимо потому, что при создании нового аккаунта требуется доказать, что он еще не существует. При общем состоянии свыше 500 миллионов аккаунтов даже минимальный индекс — 32-байтовый ключ и 32-байтовый хеш данных для каждой записи — потребует около 32 ГБ оперативной памяти. Такое хранение состояния обходится дорого, поэтому им нужно тщательно управлять во избежание снижения производительности. По мере роста состояния Solana критически важным становится разделение операций между быстрой и дорогой памятью (оперативной) и более медленной и дешевой (дисковой).

Транзакции и рост состояния

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

• Заголовок (3 байта)
• Подписи (по 64 байта)
• Адреса аккаунтов (по 32 байта)
• Данные инструкции (произвольного размера)
• Недавний хеш блока (32 байта)

При выполнении транзакции происходит следующее:

• Базовые проверки — Действительными считаются только недавние транзакции. Выполняются дедупликация, проверка структуры, комиссий и подписей транзакции
• Загрузка программы — Байт-код программы загружается по ее адресу, после чего создается экземпляр Solana Virtual Machine (SVM)
• Загрузка аккаунтов — Все указанные в транзакции аккаунты проверяются, загружаются из хранилища в память и передаются SVM
• Выполнение — Выполняется байт-код программы
• Синхронизация — Все измененные аккаунты синхронизируются обратно с хранилищем

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

Упрощение управления состоянием с помощью ZK Compression

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

Хотя такие доказательства безопасны, они могут быть довольно большими. Например, для дерева со 100 тысячами аккаунтов размер доказательства составит 544 байта. Доказательства для нескольких аккаунтов могут быстро превысить лимит транзакции в 1232 байта. К счастью, это ограничение можно обойти с помощью более эффективных систем доказательств. Обязательства с постоянным размером доказательства, например KZG или обязательства Педерсена, уменьшат доказательство и позволят легче уложиться в ограничение размера транзакции.

ZK Compression — это просто механизм решения проблемы размера доказательства Меркла. Он позволяет доказать корректность определенного вычисления без сопутствующих расходов на ончейн-хранение, используя реестр Solana.

Что такое ZK Compression?

ZK Compression — новый примитив, который позволяет разработчикам сжимать ончейн-состояние и на несколько порядков сокращать расходы на него, сохраняя безопасность, производительность и компонуемость. Например, сейчас создание 100 токен-аккаунтов стоит ~0,2 SOL, а с ZK Compression стоимость снижается в 5000 раз — до ~0,00004 SOL. 

ZK Compression использует доказательства с нулевым разглашением для проверки переходов состояния без раскрытия базовых данных. Для этого несколько аккаунтов объединяются в один проверяемый корень Меркла, который хранится ончейн, а базовые данные размещаются в реестре. Доказательства действительности — это краткие доказательства с нулевым разглашением, подтверждающие существование n аккаунтов в качестве листьев в m деревьях состояния при постоянном размере доказательства в 128 байт. Эти доказательства создаются вне блокчейна и проверяются ончейн, снижая общую вычислительную нагрузку на Solana. В системе доказательств ZK Compression используется Groth16 — известный zk-SNARK на основе спариваний.

Однако эти аккаунты не являются обычными аккаунтами Solana. Это сжатые аккаунты.

Модель сжатых аккаунтов

Сжатое состояние ZK хранится в сжатых аккаунтах. Они похожи на обычные аккаунты Solana, но имеют несколько важных отличий, повышающих эффективность и масштабируемость:

• Идентификация по хешу — Каждый сжатый аккаунт можно идентифицировать по его хешу
• Изменение хеша при записи — Любая операция записи в сжатый аккаунт изменяет его хеш
• Необязательный адрес — В качестве постоянного уникального идентификатора сжатого аккаунта можно дополнительно задать адрес. Это полезно в некоторых сценариях, например для NFT. Поле необязательно, чтобы избежать вычислительных накладных расходов, поскольку на сжатые аккаунты можно ссылаться по хешу
• Разреженные деревья состояния — Все сжатые аккаунты хранятся в деревьях Меркла, а в пространстве ончейн-аккаунтов хранится только корень состояния дерева (то есть корень Меркла). В частности, дерево состояния представляет собой конкурентное дерево Меркла на основе хеша Poseidon

Сжатые адреса, производные от программы (PDA), можно идентифицировать по уникальному постоянному адресу. Их структура похожа на обычные PDA-аккаунты с полями Data, Lamports, Owner и Address. Однако, в отличие от обычных PDA, поле Data содержит структуру AccountData с полями Discriminator, Data и DataHash.

Ноды

Различные типы нод играют ключевую роль в поддержке ZK Compression. Любой может запустить ноду Photon RPC, ноду Prover или ноду Light Forester для подключения к Devnet и Mainnet-Beta. Для локальной разработки команда ZK Compression CLI test-validator запускает однонодовый кластер Solana со всеми соответствующими нодами (то есть Photon RPC и Prover), а также системными программами, аккаунтами и функциями среды выполнения.

Ноды Photon RPC индексируют программы сжатия. Это позволяет клиентам читать и создавать транзакции, взаимодействующие со сжатым состоянием. Канонический индексатор сжатия называется Photon и предоставляется Helius. Такую ноду можно запустить локально с минимальной настройкой, указав ей существующий RPC. 

Ноды Prover создают доказательства действительности для включения состояния. Для получения доказательств можно использовать эндпоинт getValidityProof из спецификации ZK Compression RPC API. Ноды Prover могут работать отдельно или в связке с другим RPC. Обратите внимание, что каноническая реализация Photon RPC включает ноду Prover.

Ноды Light Forester управляют созданием, переносом и обновлением общих и принадлежащих программам деревьев состояния. Они предназначены для разработчиков, которые хотят обслуживать собственные деревья состояния программ через сеть нод Light Forester.

Предположения о доверии

Любой может запустить одну из упомянутых нод, хранить исходные данные, необходимые для создания доказательств, и отправлять транзакции. Это вводит предположение о доверии, влияющее на доступность сжатого состояния. Если данные будут потеряны или задержаны, отправка транзакций станет невозможной, если только пользователь не хранит эти данные самостоятельно. Поскольку для предоставления данных достаточно одной честной ноды, а доказательства можно проверять независимо, проблема связана с доступностью и потенциальной цензурой, а не с безопасностью.

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

Использование нод Forester вводит еще одно предположение о доверии, связанное с доступностью. Эти ноды обеспечивают продвижение корней состояния и управляют очередями нуллификаторов, опустошая их и асинхронно продвигая корни состояния. При этом хеши аккаунтов заменяются нулями для их аннулирования. Разделение продвижения и аннулирования обеспечивает мгновенную финализацию переходов сжатого состояния и позволяет транзакциям укладываться в ограничения размера Solana. Поскольку очереди нуллификаторов имеют постоянный размер, ноды Forester необходимы для доступности протокола. Переполнение очереди приведет к отказу доступности связанного дерева состояния. Ноды Forester предотвращают это, опустошая очереди. Однако для обеспечения целостности и доступности протокола эти ноды необходимо запускать. Без них ZK Compression могла бы поддерживать лишь около двух тысяч аккаунтов или адресов.

Ограничения 

Даже если ничего скрывать не требуется, доказательства с нулевым разглашением превращают задачи с несколькими вычислительными этапами в задачу проверки одного доказательства корректности вычислений. При этом речь не обязательно идет о проверке принадлежности конкретного листа заданному дереву — вычисление может быть произвольным. Однако у этого есть своя цена.

Перед использованием ZK Compression учтите следующее:

• Больший размер транзакции — ZK Compression требует 128 байт для доказательства действительности, а также места для данных, отправляемых для чтения или записи ончейн
• Повышенный расход вычислительных единиц — ZK Compression значительно увеличивает расход вычислительных единиц (CU): ~100 тысяч CU требуется для проверки доказательства действительности, ~100 тысяч CU — для системных нужд и ~6 тысяч CU — на каждое чтение или запись сжатого аккаунта
• Расходы на состояние для каждой транзакции — Каждая операция записи несет небольшие сетевые расходы, поскольку необходимо аннулировать предыдущее состояние сжатого аккаунта и добавить новое в дерево состояния. Поэтому совокупная стоимость одного сжатого аккаунта за весь срок существования может превысить стоимость несжатого аналога, если состояние обновляется много раз

Обычный аккаунт может быть предпочтительнее, если:

• Аккаунт часто обновляется
• Общее число операций записи в аккаунт за весь срок его существования будет большим (то есть >1000)
• В аккаунте хранится большой объем данных, к которым необходимо обращаться в ончейн-транзакциях

Преимущества

ZK Compression — масштабируемый, безопасный, эффективный и гибкий примитив, который напрямую решает проблему роста состояния Solana и поддерживает множество приложений и сценариев. Пожалуй, его самое заметное преимущество — снижение расходов на состояние. ZK Compression позволяет приложениям легко масштабироваться до миллионов пользователей: состояние безопасно хранится в более дешевом пространстве реестра, а ончейн-хранение минимизируется с помощью отпечатков состояния. Например, выпуск 10 000 токен-аккаунтов при цене SOL в 130 долларов США обойдется примерно в 2600 долларов. ZK Compression снижает эту сумму до менее чем пятидесяти центов.

ZK Compression также хорошо сочетается с текущими спецификациями Solana. Например, структура сжатых аккаунтов почти идентична структуре обычных аккаунтов Solana. Поддерживаются и характерные для Solana инновации, такие как параллелизм. Любые две транзакции в одном дереве состояния (то есть обязательстве), обращающиеся к разным сжатым аккаунтам, могут выполняться параллельно. Кроме того, ZK Compression укрепляет синхронную атомарную компонуемость. Например, транзакция с n сжатыми и m обычными аккаунтами является полностью допустимой конфигурацией. Инструкция, ссылающаяся на сжатый аккаунт, может вызвать другую инструкцию или программу, ссылающуюся на обычный аккаунт. Это верно, даже если аккаунты сжаты в разных деревьях состояния. При сбое одной инструкции вся транзакция откатывается, а изменения каждой инструкции видны следующей. Это отличается от ZK-роллапов, которые не могут вызывать друг друга синхронно или атомарно без блокировок. Поэтому естественно сравнить ZK Compression с роллапами.

ZK Compression — не роллап

ZK Compression — не роллап. Хотя обе технологии используют одинаковую основу, их реализации различаются. Существует два типа роллапов:

• Оптимистические роллапы — В течение определенного периода все транзакции считаются действительными, а доказательства мошенничества позволяют выявлять ложные транзакции в этом временном интервале
• Роллапы с нулевым разглашением — Действительность или недействительность транзакций мгновенно доказывается с помощью доказательств действительности

Все состояние роллапа с нулевым разглашением представлено в виде единого корня на базовом уровне (то есть в Ethereum). Это породило множество утверждений о том, что ZK Compression фактически является роллапом. Однако между ними есть несколько принципиальных различий.

Рассмотрим сценарий с 500 транзакциями в ZK-роллапе. В этом случае весь роллап рассматривается как единая схема. Все 500 транзакций проверяются вместе, в результате чего создается одно доказательство перехода корня состояния из A в B. После проверки доказательства смарт-контракт, управляющий взаимодействием между L1 и L2, соответствующим образом обновляет корень состояния. В ZK Compression, напротив, каждая из 500 транзакций создает собственное доказательство корректности данных аккаунта. Эти транзакции выполняются самой SVM, а после проверки каждого доказательства аккаунты обрабатываются как «обычные».

Если считать ZK Compression роллапом, то любой корень Меркла, хранящийся в Solana, можно считать роллапом на основе доказательств действительности. Если посмотреть на все корни сжатых cNFT, находящиеся сейчас в Solana, получится около 4–5 тысяч роллапов на основе доказательств действительности — в зависимости от того, учитываем ли мы деревья Меркла с нулевым числом выпусков.

Таким образом, становится ясно, что ZK Compression — уникальное решение, адаптированное к архитектуре Solana. Это новый примитив, отличный от ZK-роллапов. Он повышает масштабируемость и эффективность без сложности и изолированности, присущих роллапам.

Будущее ZK в Solana и совместимость

Текущее состояние ZK в Solana

Одной из моих первых задач в Helius было описание обновления Solana v1.16. Меня очень воодушевила улучшенная поддержка доказательств с нулевым разглашением в среде выполнения, и я рассказал о ней в статье. Однако эти улучшения отложили. Я допустил ошибку, снова и более подробно описав их в статье об обновлении v1.17, поскольку их снова отложили. В статье об обновлении v1.18 я уже даже не стал о них упоминать. Разумеется, я был разочарован, и другие также выражали недовольство. 

Несмотря на это, в Solana формируется пока небольшое сообщество ZK-разработчиков. Изначально Light Protocol был сосредоточен на приватном выполнении программ в форме PSP (Private Solana Programs), а затем переключился на ZK Compression. Dark protocol — еще один футархический протокол конфиденциальности на базе Solana. У него нет центральной команды, а вклад в разработку вносится через предложения. Arcium, ранее известный как Elusiv, использует среды исполнения многосторонних вычислений (MXE) для работы собственной параллельной сети конфиденциальных вычислений. Bonsol — «сопроцессор» с нулевым разглашением, который позволяет разработчикам запускать любой образ risc0 и проверять его в Solana, то есть выполнять проверяемые внеблокчейновые вычисления. Также распространяются руководства и подборки ссылок о доказательствах с нулевым разглашением.

Особого внимания заслуживает ZK Token Proof Program, которая проверяет несколько доказательств с нулевым разглашением, предназначенных для работы с обязательствами Педерсена и шифрованием Twisted ElGamal над curve25519. Она обеспечивает работу Confidential Transfers, где доказательства с нулевым разглашением используются для шифрования балансов и сумм транзакций SPL-токенов. Цель здесь — конфиденциальность, а не анонимность. Гомоморфное шифрование позволяет выполнять вычисления над зашифрованными данными без их расшифровки. Для этого Confidential Transfers используют Twisted ElGamal Encryption для скрытых математических операций над шифротекстом и протоколы Sigma для проверки переводов без раскрытия конфиденциальной информации. Зашифрованный баланс может видеть только владелец аккаунта с ключом расшифровки. Однако Global Auditor System предоставляет избирательный доступ на чтение для обеспечения нормативного соответствия и аудита с помощью отдельных ключей расшифровки. 

Сейчас ZK Token Proof Program является заблокированной функцией из-за принятия SIMD-0153: ZK ElGamal Proof Program. Новый SIMD призван вывести из эксплуатации существующую ZK Token Proof Program, специально разработанную для программы SPL Token, и заменить ее более универсальной программой доказательств с нулевым разглашением, не зависящей от конкретного приложения. SIMD уже объединен с поддержкой Anza и команды Firedancer.

Однако ситуация начинает меняться. Solana превращается в гиганта ZK, поскольку эти улучшения наконец появляются в Devnet и Mainnet-Beta. Теперь в Solana работают три системных вызова ZK.

Системные вызовы Poseidon

Poseidon — семейство хеш-функций, специально разработанных для доказательств с нулевым разглашением и используемых в таких проектах, как Zcash, Mina и Light Protocol. Для доказательств с нулевым разглашением Poseidon вычислительно эффективнее традиционных универсальных хеш-функций, например SHA-256. 

Хеш-функции Poseidon удобны для нулевого разглашения, поскольку они:

• Эффективно выполняют арифметические операции
• Требуют меньше этапов для создания доказательств (то есть имеют меньшую сложность схемы) благодаря структуре, удобной для арифметических операций, оптимизированному S-блоку и небольшому числу раундов
• Используют алгоритмы, обрабатывающие последовательности битов любой длины, что делает их чрезвычайно универсальными

Раньше вычислять хеши Poseidon в одной транзакции было слишком дорого. Ситуация меняется с эпохой 644 и активацией системного вызова Poseidon, то есть системного вызова, который принимает двумерный байтовый срез и возвращает соответствующий хеш Poseidon. Это важное событие, поскольку ZK Compression использует хеширование Poseidon для деревьев состояния.

Системный вызов Poseidon вычисляет хеши с помощью кривой BN254 со следующими параметрами:

• S-блоки — Блоки подстановки x5
• Входы — 1 ≤ n ≤ 12
• Ширина — 2 ≤ t ≤ 13
• Раунды — 8 полных раундов и частичные раунды в зависимости от t: [56, 57, 56, 60, 60, 63, 64, 63, 60, 66, 60, 65]

Результатом будет хеш Poseidon, закодированный в виде 32 байт с указанным порядком байтов.

Обратите внимание, что в системном вызове используется конкретный вариант Poseidon с S-блоком x5 и параметрами, адаптированными к кривой BN254. Крейт light-poseidon упростит вычисление этих хешей. Сам крейт прошел аудит и совместим с Circom.

Системные вызовы alt_bn128

alt_bn128 — реализация эллиптической кривой Баррето — Нерига (BN-128), удобной для спариваний и обеспечивающей эффективные доказательства и вычисления zk-SNARK. Эта кривая играет важную роль в различных системах доказательств с нулевым разглашением, включая Groth16, которую ZK Compression использует для проверки переходов состояния. Этот системный вызов значительно сокращает пространство, необходимое для каждого доказательства, и обеспечивает важную оптимизацию пространства и времени для эффективных ончейн-доказательств. 

Системные вызовы sol_alt_bn128_group_op выполняют операции на кривой alt_bn128, включая сложение точек в G1 (под G1 здесь подразумевается группа точек на заданной эллиптической кривой), скалярное умножение в G1 и спаривание:

• Входы — Сериализованные точки и скаляры в формате с прямым порядком байтов
• Операции — Сложение точек в G1, скалярное умножение в G1, спаривание (1 точка в G1 и 1 точка в G2)
• Выходы — Точки в G1 или результаты спаривания, сериализованные как 256-битное целое число

Системные вызовы sol_alt_bn128_compression сжимают или распаковывают точки в группах G1 или G2 на кривой alt_bn128 и возвращают точки в стандартном формате с прямым порядком байтов.

Эти системные вызовы уже работают в testnet и, по всей видимости, появятся в Devnet после устранения ошибок на этапе повторной компиляции загруженных программ, согласно SIMD-0075: Secp256r1 Precompile. Предложение призвано унифицировать коды ошибок системных вызовов alt_bn128 и Poseidon, обеспечив согласованность и снизив риск сбоев консенсуса из-за разных кодов ошибок, возвращаемых валидаторами.

Системные вызовы alt_bn128 можно использовать для обычных векторных обязательств с постоянным размером доказательства, например обязательств KZG. Таким образом, они будут работать с любой кривой, удобной для спариваний, и не потребуют схемы ZK-доказательства. 

Совместимость

Solana — это ZK-блокчейн. Это высокопроизводительный блокчейн уровня 1 с низкими комиссиями и поддержкой операций на эллиптических кривых в среде выполнения. Реализация и поддержка системных вызовов для доказательств с нулевым разглашением стимулируют инновации и позволяют создавать на базе Solana новые примитивы и приложения, например ZK Compression.

Появление системных вызовов alt_bn128 сокращает разрыв в компонуемости между Solana и контрактами на базе Solidity, которые используют предварительно скомпилированные контракты для операций на эллиптических кривых, описанных в EIP-196, EIP-197 и EIP-198. Эти операции позволяют проверять доказательства zk-SNARK в пределах лимитов газа Ethereum. Поэтому контрактам Solidity, использующим такие операции на эллиптических кривых, теперь может быть проще перейти в Solana или даже взаимодействовать с ней.

SIMD-0075 крайне важен для решений совместимости. После полной реализации этот SIMD позволит таким проектам, как готовящийся blobsream-solana, который передает DA из Celestia в Solana, создавать доказательства вне блокчейна и проверять их ончейн для хранения обязательств Меркла. Без этих системных вызовов проверка доказательств Groth16 в Solana была бы невозможна. Кроме того, они улучшают мосты с минимизированным доверием и совместимость, позволяя другим блокчейнам беспрепятственно и безопасно взаимодействовать с Solana.  

Toly прав: со всеми этими улучшениями среды выполнения Solana представляет собой L2 для Ethereum. Скоро ничто не помешает вам отправлять все блоки Solana в контракт моста для проверки данных в Ethereum. И наоборот, ничто не помешает отправлять все блоки Ethereum в программу моста для проверки данных в Solana. Двусторонняя совместимость, ускоренная доказательствами с нулевым разглашением вместо устаревших мостов, открывает перед Solana светлое и многообещающее будущее.

Заключение

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

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

Solana превращается в гиганта ZK. Значение событий от выпуска ZK Compression до скорой активации различных системных вызовов трудно переоценить. Такие примитивы, как ZK Compression, скрывают от рядового разработчика все сложности доказательств с нулевым разглашением. Однако понимание основ бесценно для развития дискуссии и дальнейшей разработки этой технологии в Solana. 

Если вы дочитали до этого места, спасибо, анон! Обязательно укажите свой адрес электронной почты ниже, чтобы не пропускать новости Solana. Готовы погрузиться глубже? Изучите свежие статьи в блоге Helius и продолжите знакомство с Solana уже сегодня.

Дополнительные материалы

• Приблизительное введение в принципы работы zk-SNARK от Vitalik
• POSEIDON: новая хеш-функция для систем доказательств с нулевым разглашением (обновленная версия)
• SIMD-0075: предварительная компиляция Secp256r1
• Различия между zk-SNARK и zk-STARK
• Документация ZK Compression