State Compression на Solana — это прикладной паттерн и набор инструментов, позволяющих представлять «тяжёлые» наборы объектов через криптографические коммиты (корни Merkle-деревьев) с хранением «полных байтов» вне цепочки. На цепи остаётся небольшой якорь состояния (корень/индекс), а принадлежность конкретного объекта доказывается Merkle-доказательством (proof). Такое разделение радикально уменьшает on-chain объём и комиссии при массовых сценариях (миллионы объектов), сохраняя проверяемость на уровне протокола.
Базовые концепции сети см. в обзоре Архитектура Solana: Объяснение Высокой Производительности, PoH, Sealevel, устройство параллельного исполнения — Sealevel (Solana): параллельное исполнение, рантайм и планировщик, модель данных и прав — Solana: модель аккаунтов — PDAs, read/write-локи, rent-exempt, ALTs, терминологию — Сжатие состояния (State Compression) в Solana: как работает, cNFT и экономия комиссий.
Зачем Solana понадобилась компрессия состояния
- Масштаб без взрывных комиссий. Миллионные коллекции (cNFT), билеты/пропуска, купоны, чеки — всё это требует проверяемости, но не обязано храниться целиком on-chain.
- Стабильный UX при пиках. Меньше записей в «горячие» аккаунты → меньше write-конфликтов и локальных очередей; см. Local Fee Market (Solana): локальные рынки комиссий и priority fees.
- Предсказуемая финализация. Короткие ончейн-апдейты (обновление корня) упрощают работу конвейера и планировщика (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик).
Архитектура на пальцах
- Вне цепочки формируется Merkle-дерево из элементов (объектов). Считается Merkle root.
- На цепи публикуется/обновляется коммит (корень и служебные параметры).
- Для верификации конкретного элемента клиент/программа передают Merkle-proof; на узле пересчёт пути сверяется с ончейн-корнем.
- Любое изменение набора элементов приводит к новому корню и небольшому ончейн-обновлению.
Ключевая идея: цепь хранит якорь, а не «все байты». Этого достаточно, чтобы независимо проверить правду об объекте.
Что именно лежит on-chain, а что — off-chain
| Слой | Что хранится | Кто отвечает |
|---|---|---|
| On-chain | Корень (root), версии/метаданные коммита, мини-индексы | Программа в сети Solana (и её владельцы) |
| Off-chain | Полные записи объектов/метаданные, индексы/снапшоты | Поставщики хранения (CDN/архивы), издатель набора, зеркала сообщества |
Безопасность опирается на криптографию: несовпадение off-chain данных с ончейн-корнем обнаруживается верификацией proof.
Как компрессия «вписывается» в модель Solana
- Аккаунтная модель. Ончейн-коммиты и служебные индексы живут в аккаунтах, права и режимы доступа объявляются в инструкции (см. Solana: модель аккаунтов — PDAs, read/write-локи, rent-exempt, ALTs).
- Параллелизм Sealevel. Проверка proofs — короткие вычисления; обновления корней можно батчировать/планировать, чтобы снижать write-конфликты (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик).
- Локальные рынки комиссий. Если корни часто обновляются в одних и тех же аккаунтах, образуется локальная очередь; остальные операции сети это не удорожает (см. Local Fee Market (Solana): локальные рынки комиссий и priority fees и Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору).
Где это уже применимо
- Compressed NFTs (cNFT). Массовые «карты участника», пропуска, чеки о посещении, коллекционные сеты.
- Билеты/купоны/сертификаты. Выдача и погашение через проверку proofs вместо записи всего объекта.
- Снимки и списки. Криптографически зафиксированные «снапшоты» списков (участники, результаты, реестры), сопоставимые с on-chain корнем.
Проектирование дерева и индексов
- Схема адресации листа. По ключу пользователя, по порядку эмиссии, по «идентификатору выпуска».
- Версионирование. Каждый релиз/батч меняет root. Сохраняйте историю корней и связывайте её с внешними снапшотами.
- Стабильность формата. Фиксированные структуры, предсказуемые смещения — меньше ошибок и экономнее по CU.
- Индексы. Быстрый поиск листа по ключу/ID уменьшает нагрузку на клиента и упрощает сбор proof.
Плюсы и компромиссы
| Аспект | Что выигрываем | На что подписываемся |
|---|---|---|
| Комиссии | Радикально меньше on-chain байтов | Ответственность за off-chain доступность и зеркала |
| Масштаб | Миллионы элементов реальны | Процедуры версионирования/отката корней |
| Проверяемость | Независимая верификация через proof | Требует продуманной схемы индексации и хранения истории |
| UX | Ровнее p95/p99 задержек вне «очагов» | Локальные пики при частых обновлениях одного и того же корня |
Интеграция в dApp: пошаговая схема
- Определите модель данных (что является «листом» дерева).
- Спроектируйте индексы и адресацию (ID пользователя/выпуска/пула).
- Выберите режим обновлений (батчи по расписанию vs события).
- Определите источники хранения: минимум два независимых провайдера + архивное зеркало.
- Опишите SLA восстановления: как собрать набор из архивов и сверить с историей корней.
- Реализуйте верификацию на клиенте: быстрый пересчёт proof перед сабмитом транзакции.
- Настройте телеметрию: доля успешных проверок, ошибки proofs, латентность.
Анти-паттерны
- Один бэкенд «на всё». Единая точка отказа; делайте зеркала и архивы.
- Частые мелкие обновления корня. Увеличивают локальные очереди; лучше батчи/расписание.
- Динамические форматы. Частые realloc и миграции усложняют проверку и повышают CU.
- Секретные зависимости. Любые ресурсы должны быть заранее объявлены в инструкции; скрытые вызовы через CPI ломают предсказуемость (см. Sealevel (Solana): параллельное исполнение, рантайм и планировщик).
Производительность и комиссии
- Верификация proof — дешёвое вычисление, хорошо параллелится.
- Обновление корня — короткая запись; планируйте окна так, чтобы не создавать write-конфликты.
- Приоритетная доплата уместна только при явной локальной очереди на аккаунт корня (см. Priority Fee (Solana): приоритетная комиссия за compute units (CU) и «чаевые» валидатору). Вне очага повышать приоритет бессмысленно.
Наблюдаемость и метрики
| Метрика | Что говорит | Как реагировать |
|---|---|---|
| Доля ошибок верификации proof | Качество индексов/реплик | Проверить сериализацию/версионирование, здоровье зеркал |
| Время отдачи proof с хранилища | Доступность off-chain слоя | Кеш/репликация ближе к пользователю |
| p95/p99 подтверждений апдейта корня | Локальные очереди/конфликты | Перевести на батчи, развести аккаунты по ключам |
| Расхождение корней и снапшотов | Риски целостности | Создать процедуру «rebuild & compare», сигнализировать при алерт-порогах |
Безопасность и процедуры восстановления
- Храните историю корней (и подписи/маркеры времени).
- Делайте периодические «снапшоты» набора с привязкой к конкретному корню.
- Проверяйте зеркала: регулярные выборочные сверки proofs с ончейн-корнем.
- Определите правила обновления: кто и при каких условиях имеет право публиковать новый корень (роль, мультисиг, временные локи).
Часто задаваемые вопросы (FAQ)
Можно ли использовать компрессию для быстро меняющихся DeFi-состояний? Редко уместно: такие состояния требуют мгновенной ончейн-целостности без внешних зависимостей.
Что будет, если off-chain провайдер «упал»? Должны существовать независимые зеркала и архивы. История корней в сети позволяет восстановить набор и заново «привязать» реплики.
Компрессия делает всё «бесплатным»? Нет. Вы экономите on-chain, но платите организацией хранения, индексов, версионирования и мониторинга.
Proof достаточно для полного аудита? Proof отвечает на вопрос «этот элемент соответствует корню?». Корректность бизнес-логики (дубликаты, права, лимиты) — ответственность программы/протокола.
Мини-глоссарий
- Merkle root — корневой хэш дерева, коммитящий набор.
- Merkle proof — путь хэшей от листа к корню.
- Коммит корня — ончейн-фиксация текущей версии набора.
- Снапшот — полная копия набора на момент корня.
- cNFT — класс объектов, выпускаемых с компрессией состояния.
См. также
Сжатие состояния (State Compression) в Solana: как работает, cNFT и экономия комиссий Sealevel (Solana): параллельное исполнение, рантайм и планировщик Архитектура Solana: Объяснение Высокой Производительности, PoH, Sealevel Solana: модель аккаунтов — PDAs, read/write-локи, rent-exempt, ALTs