Доклад о ZK-компрессии: Breakpoint 2024

ZK-компрессия: сводим к нулю

Разработчики быстро обнаруживают, что вычисления в Solana относительно недороги, но хранение данных обходится дорого. Например, при цене SOL в $150 создание 1 000 токен-аккаунтов стоит около $300, а миллиона аккаунтов — $300 000. Это делает масштабирование приложений для большой пользовательской базы финансово нецелесообразным, поскольку расходы растут вместе с ценой SOL. Кроме того, рост состояния — проблема для всех блокчейнов с отслеживанием состояния. При создании новых аккаунтов необходимо платить ренту за их хранение, что обходится дорого. Сейчас в Solana более 500 миллионов аккаунтов, и ежедневно добавляется примерно миллион новых.

ZK-компрессия решает эти проблемы благодаря следующим возможностям:

• Аккаунты в тысячу раз дешевле
• Решение проблемы роста состояния
• Основа для ZK-вычислений в Solana

Компрессия состояния + ZK

Чтобы понять ZK-компрессию, сначала разберём компрессию состояния, которая включает пять ключевых этапов:

1. Миллионы аккаунтов → «отпечаток»
2. Хранение отпечатка ончейн
3. Хранение истории аккаунтов в реестре Solana
4. Кеширование последнего состояния аккаунта с помощью индексатора
5. Проверка состояния сжатого аккаунта через ончейн-«отпечаток»

Сначала мы сжимаем миллионы аккаунтов Solana и хешируем их в компактный «отпечаток». Этот отпечаток хранится в ончейн-аккаунте, а все исходные данные аккаунтов остаются доступными в реестре Solana. Чтобы подтвердить действительность этих офчейн-аккаунтов, мы используем механизм доказательства, который проверяет их целостность по ончейн-отпечатку. На последнем этапе применяются SNARK с нулевым разглашением. Они лежат в основе системы доказательств, которая проверяет целостность этих аккаунтов.

Почему ZK-компрессия?

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

‍API индексатора почти полностью повторяет существующие RPC-вызовы. Например, метод getAccountInfo напрямую соответствует getCompressedAccount. Такое взаимно однозначное соответствие действует во всём RPC API. Благодаря этому ZK-компрессию проще интегрировать с существующими инструментами и рабочими процессами Solana.

Сжатые PDA

Ключевая особенность этой системы — поддержка сжатых адресов, производных от программы (PDA). PDA — это детерминированные адреса аккаунтов, которые можно последовательно получать из заданного адреса программы и начального значения. Сжатые PDA помогают исключить состояния гонки, коллизии адресов и случайное создание нескольких аккаунтов для одной комбинации адреса программы и начального значения. Это улучшение — одна из главных причин перехода от существующей системы компрессии аккаунтов SPL к ZK-компрессии.

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

Улучшение компонуемости

Всё работает непосредственно в Solana — это не L2 и не validium. Доступность данных автоматически обеспечивает реестр Solana, поэтому исполнение можно проверить и полностью компоновать.

‍Доказательства с нулевым разглашением сокращают размер доказательства до постоянных 128 байт. Это освобождает в каждой транзакции больше места для других операций, упрощает компонуемость и даёт больше гибкости для дополнительных действий. Размер доказательства остаётся неизменным независимо от числа аккаунтов, которые обновляются, читаются или записываются в одной транзакции, а также от количества включений или исключений, которые требуется доказать. Это важно, поскольку транзакции Solana изначально имеют небольшой размер — 1,2 килобайта. Для быстрого формирования доказательств потребовалась другая хеш-функция для деревьев Меркла состояния, поэтому мы не могли использовать исходную программу компрессии аккаунтов SPL.

Декомпрессия

Ещё одна ключевая функция — декомпрессия. Она предотвращает зависимость от одного решения и обеспечивает беспрепятственное взаимодействие между «обычными» и сжатыми аккаунтами. Любой аккаунт Solana можно сжать и вернуть затраты на ренту. Сжатый аккаунт также можно в любой момент декомпрессировать, поэтому переходить между двумя формами очень просто. Например, если сжатый токен нужно обменять, достаточно декомпрессировать его и выполнить обмен через Jupiter.

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

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

Сжатые токены

Сжатые токены не совместимы напрямую с биржами и платформами DeFi, если те их не поддерживают. Однако это легко решить: сжатый токен можно декомпрессировать в стандартный токен SPL, а затем использовать в DeFi и на биржах как любой обычный токен. Такая гибкость исключает зависимость от одного решения. Пользователи могут по мере необходимости переходить между сжатыми и обычными токенами. Сжатые токены идеально подходят для холодных приложений с редкими взаимодействиями, а обычные токен-аккаунты — для горячего состояния и часто используемых активов. Одно из главных преимуществ системы — возможность решить проблему роста состояния. Данные холодного состояния перемещаются в сжатое хранилище, сохраняя все преимущества и повышая эффективность управления состоянием.‍

‍В первом выпуске мы представили сжатые токены, созданные с помощью тех же инструментов, которые используются для любого приложения с поддержкой компрессии. Программа сжатых токенов идентична токен-программе Solana. Она обеспечивает тот же пользовательский опыт, но сокращает расходы в тысячу раз. Запуск расширений токенов ожидается в начале 2025 года.

Благодаря таким функциям, как декомпрессия, вы можете проводить эирдропы больших объёмов токенов и быстро декомпрессировать их при необходимости для операций DeFi. Доказательства с нулевым разглашением (ZK) часто считают идеальным решением для затратных вычислений. Мы оптимизировали процесс так, чтобы переводы были похожи на стандартные переводы токенов SPL, сократив время формирования доказательств до миллисекунд. Это выводит пользовательские ZK-решения промышленного уровня на передний план и значительно снижает расходы на управление токен-аккаунтами.

Как работает ZK-компрессия?

В общей системе пять основных компонентов: 

• Лес деревьев состояния
• Light System Program
• Compressed Token Program
• Ноды Forester
• Индексаторы (Photon)

Лес деревьев состояния

Первый компонент — деревья Меркла состояния, которые мы называем «лесом деревьев Меркла состояния». Эта структура создаёт уникальный криптографический отпечаток набора аккаунтов, который можно хранить ончейн. Например, четыре аккаунта можно рекурсивно хешировать в структуру дерева Меркла.

Итоговый 32-байтовый хеш на вершине криптографически гарантирует целостность исходных данных всех аккаунтов. Состояние любого аккаунта в составе дерева Меркла можно легко проверить, сравнив его с корнем состояния. Мы используем термин «лес», потому что существует несколько деревьев Меркла, каждое со своим корнем.

Сравнение с существующей компрессией аккаунтов SPL

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

При постоянном размере доказательства в 128 байт можно доказать M аккаунтов для N деревьев. Поэтому доказательства хорошо укладываются в ограничение Solana на размер транзакции в 1,2 КБ. Формирование доказательств происходит офчейн и обходится дороже, чем в существующей программе компрессии аккаунтов SPL. Однако проверка доказательств выполняется ончейн, имеет постоянную стоимость и в большинстве случаев обходится дешевле, чем в существующей программе компрессии.

Light System Program и Compressed Token Program

Протокол включает две ключевые программы. Light System Program — ончейн-контракт, повторяющий Solana System Program. Он взаимодействует с деревом Меркла, обеспечивает соблюдение стандартной модели аккаунтов Solana и проверяет уникальность PDA. Compressed Token Program воспроизводит токен-программу SPL и обеспечивает соблюдение структуры данных SPL в модели сжатых аккаунтов.

Ноды Forester

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

У этого подхода два важных следствия. Во-первых, любое обновление состояния изменяет корень, поскольку изменения распространяются вверх по перевёрнутому дереву Меркла до самой вершины. Во-вторых, деревья постепенно заполняются и в итоге достигают предельной ёмкости. Здесь и применяется лес деревьев Light.

Ноды Forester отвечают за поддержку корня состояния. Они асинхронно обновляют его и выполняют ротацию заполненных деревьев состояния. Для запуска ноды Forester для собственных деревьев состояния не требуется разрешение. Процесс похож на запуск RPC, поэтому любой может управлять собственными обновлениями состояния. Разработчик приложения заинтересован в поддержке своего сжатого состояния. Это создаёт естественный стимул правильно управлять деревьями состояния. Вы можете самостоятельно запустить ноду в своей инфраструктуре или заплатить провайдеру, который будет управлять ею за вас.

Photon

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

‍Готовый к эксплуатации индексатор Photon содержит значительные улучшения, основанные на опыте работы с предыдущими версиями компрессии. Его цель — обеспечить удобство и доступность для индивидуальных разработчиков, предприятий и RPC-провайдеров.

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

Photon ежедневно создаёт снимки, ускоряя разработку и развёртывание. Вместо повторной индексации с генезис-блока разработчики могут начать со снимка, сократив время загрузки и запуска до 15 минут или меньше. Снимки также упрощают репликацию. Если RPC-провайдер прекратит поддержку компрессии, вы сможете легко получить снимок и самостоятельно запустить индексатор. Снимки минимизируют риск потери данных. Их можно хранить в децентрализованных решениях, таких как FileCoin.

Photon позволяет индексировать только часть данных. Это значительно снижает требования к оборудованию и уменьшает размер базы данных. Для этого достаточно SQLite и одной команды CLI. RPC-провайдеры также могут индексировать весь набор данных. Photon доступен на любом тарифе Helius. Вы также можете запустить его самостоятельно или запросить эту услугу у другого провайдера.

Разработчиками для разработчиков

Мы полностью сосредоточены на разработчиках и активно работаем над тремя крупными улучшениями, специально предназначенными для повышения удобства разработки.

Web3.js для компрессии

SDK работает аналогично Solana web3.js, но полностью поддерживает компрессию. Чтобы инициировать перевод сжатых токенов, сначала получите свои сжатые токен-аккаунты. Затем используйте их, чтобы получить доказательство действительности через RPC или выделенную ноду формирования доказательств. После этого сформируйте инструкции так же, как в токен-программе SPL: укажите, что и в каком количестве нужно отправить, адрес выпуска и получателя. В результате будет создана обычная транзакция Solana.

‍Полная среда локальной разработки

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

Макросы Anchor

Наша цель — сделать работу со сжатыми аккаунтами такой же удобной, как с обычными, для разработчиков, знакомых с созданием программ Solana с помощью Anchor. Если вы уже создавали программу Anchor, то сразу узнаете знакомый процесс разработки. Макросы Anchor пока находятся в разработке.

Airship

Airship позволяет разработчикам уже сегодня использовать ZK-компрессию для массовых эирдропов токенов — просто и с низкими затратами. Доступны пользовательский интерфейс и CLI. Проект имеет полностью открытый исходный код, поэтому разработчики могут создать форк и изменить его под свои потребности. По мере того как всё больше разработчиков будут проводить эирдропы сжатых токенов, экосистема начнёт внедрять их в различных приложениях. Если требуется немедленное преобразование, разработчики могут сразу декомпрессировать токены. Поэтому уже сегодня Airship можно использовать как готовый инструмент для эирдропа обычных токенов.

‍Инструмент автоматически поддерживает эирдропы владельцам устройств Solana mobile, определённых токенов или NFT из заданных коллекций. Если у вас есть заранее сформированный список получателей, можно импортировать CSV-файл и указать токен и объём эирдропа. И CLI, и интерфейс позволяют возобновить эирдроп с последнего сохранённого состояния при возникновении проблем, например при потере подключения к интернету. Это особенно полезно для крупных эирдропов, которые при распределении токенов по большому списку адресов могут занимать от 30 до 45 минут.

Новое пространство для проектирования приложений

ZK-компрессия решает проблему роста состояния, сохраняя в памяти активного валидатора только итоговый корневой хеш всех аккаунтов. Такой подход эффективно снижает влияние роста состояния. Кроме того, ZK-компрессия открывает новые возможности для проектирования приложений. Вот лишь несколько потенциальных сценариев использования:

• Компрессоры токенов SPL
• Один миллиард мемкоинов
• Рынки прогнозов для публикаций в Twitter
• Идентификационные PDA для нод в сетях DePin
• Проверяемый расчёт и распределение вознаграждений
• Мосты с минимизированным доверием
• ZK-протоколы идентификации

В документации приведены другие идеи.

ZK-компрессия уже работает в mainnet и devnet! Чтобы начать работу, ознакомьтесь с нашей документацией и изучите примеры. Кроме того, мы проводим хакатон с призовым фондом до $45 000.

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

‍