Операційні вимоги для «Як працюють ledger та snapshots у Solana» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Леджер і снапшоти — це два фундаментальні механізми зберігання стану в Solana. Без розуміння їхньої взаємодії неможливо ефективно керувати дисковим простором валідатора, планувати відновлення після збоїв або передбачати час синхронізації вузла. Цей матеріал розкриває внутрішню логіку обох механізмів із практичною перспективою оператора інфраструктури.

Що таке ledger: структура та призначення

Ledger у Solana — це послідовний, лише для додавання (append-only) журнал усіх транзакцій, які коли-небудь були оброблені кластером. Кожен запис у леджері містить підписану транзакцію, результат її виконання та метадані (слот, часова мітка, комісії, статус помилок).

На диску леджер зберігається у вигляді бінарних файлів слотів. Один файл відповідає одному слоту (або групі слотів залежно від конфігурації). Файли організовані в ієрархію каталогів за номерами епох і слотів, що дозволяє файловій системі ефективно працювати з великою кількістю невеликих файлів.

Призначення леджера — забезпечити повну історію блокчейна від генезис-блоку до поточного моменту. Валідатор використовує леджер для:

  • Відтворення стану (replay) з будь-якої історичної точки;
  • Відповідей на RPC-запити, що вимагають історичних даних (getConfirmedTransaction, getBlock);
  • Сервісу Archive (History) для інших вузлів кластера;
  • Аудиту та післямортем-аналізу.

Ключова властивість леджера — він ніколи не змінюється. Записаний слот є фінальним, і єдиний спосіб його видалити — фізичне стирання файлу.

Як Solana зберігає стан блокчейну

Стан блокчейну в Solana — це сукупність усіх акаунтів у певний слот. На відміну від леджера, який є логом транзакцій, стан — це миттєвий знімок (snapshot) усіх балансів, даних програм, лічильників та прав власності.

Solana не зберігає стан як єдиний файл. Натомість використовується гібридна модель:

  • Accounts Database (AccountsDb) — in-memory структура (з доповненням на диск через mmap), що містить поточний стан усіх акаунтів. Це основне робоче сховище валідатора під час виконання транзакцій.
  • Snapshot — серіалізований дамп AccountsDb у певному слоті, який можна завантажити з диска без повного відтворення всього леджера.
  • Append Vecs (Write-ahead) — файли, куди спочатку записуються оновлення акаунтів перед застосуванням до основної структури. Це забезпечує цілісність при збої.

Під час нормальної роботи валідатор читає транзакції з леджера, застосовує їх до AccountsDb і періодично створює snapshot поточного стану. Якщо валідатор перезапускається, він може відновити стан із останнього snapshot і відтворити (replay) лише ті слоти, які пішли після нього, замість того, щоб проходити весь леджер від початку.

Snapshots: що це та навіщо потрібні

Snapshot у Solana — це стиснений дамп повного стану AccountsDb у конкретному слоті. Він містить усі акаунти, їхні баланси, дані, власників та стан виконання програм на момент створення.

Навіщо snapshots є критично важливими:

  • Швидкий старт валідатора. Без snapshot новий вузол повинен відтворити мільярди транзакцій від генезису, що займає дні або тижні. Зі snapshot — години.
  • Аварійне відновлення. При пошкодженні AccountsDb валідатор може завантажити останній коректний snapshot і синхронізувати лише відсутні слоти.
  • Економія ресурсів. Replay вимагає інтенсивного використання CPU та мережі. Snapshot — переважно дискова операція з подальшою короткою синхронізацією.
  • Розподіл стану. Snapshots можна завантажити з зовнішніх джерел (генезис-архів, інші валідатори), що знижує навантаження на кластер.

Snapshots створюються періодично самим валідатором. Типовий інтервал — кожні N слотів (значення конфігурується). Старі snapshots автоматично видаляються, залишається лише кілька останніх.

Повні та інкрементальні snapshots

Solana підтримує два типи snapshots, які працюють разом:

Повний snapshot (Full Snapshot) містить повний дамп усіх акаунтів у певному слоті. Це самодостатній файл: з нього можна відновити стан без будь-яких додаткових даних. Розмір повного snapshot значний, оскільки він містить усі акаунти кластера.

Інкрементальний snapshot (Incremental Snapshot) містить лише зміни акаунтів, що відбулися від моменту останнього повного snapshot до поточного слоту. Він значно менший за обсягом і створюється частіше.

Відновлення стану працює так: спочатку завантажується повний snapshot, потім послідовно накладається один або кілька інкрементальних snapshots. Це зменшує час створення snapshot і знижує дискове навантаження, оскільки замість повного дампа кожні кілька слотів валідатор пише лише дельту.

На диску структура виглядає приблизно так:

  • snapshot-123456789-full.tar.bz2 — повний snapshot у слоті 123456789;
  • snapshot-123457000-incremental.tar.bz2 — інкрементальний від 123456789 до 123457000;
  • snapshot-123457100-incremental.tar.bz2 — наступний інкрементальний.

Для відновлення до слота 123457100 валідатор розпакує повний snapshot і накладе обидва інкрементальні.

Як валідатор завантажує snapshot при старті

Процес завантаження snapshot при старті валідатора відбувається автоматично, але розуміння його етапів корисне для діагностики проблем.

Етап 1. Пошук локальних snapshots. Валідатор сканує каталог ledger у пошуках найсвіжішого доступного набору (повний + інкрементальні). Якщо знайдено коректний набір, він використовується.

Етап 2. Завантаження знешні. Якщо локальних snapshots немає (наприклад, свіжий вузол) або вони занадто старі, валідатор звертається до зовнішніх джерел. Джерела визначаються конфігурацією (параметр snapshots у файлі ledger/validator-infos.json або аргументи CLI). Типові джерела — генезис-архіви та інші валідатори кластера.

Етап 3. Верифікація. Завантажений snapshot перевіряється на цілісність (хеш-сума) та відповідність очікуваному слоту.

Етап 4. Розпакування та завантаження в AccountsDb. Повний snapshot розпаковується першим, потім послідовно накладається інкрементальні. Цей етап є найбільш ресурсомістким з точки зору дискового вводу-виводу та оперативної пам'яті.

Етап 5. Replay. Після завантаження snapshot валідатор відтворює слоти від моменту snapshot до поточного слота кластера, завантажуючи їх з леджера (локального або з мережі).

Типова проблема при старті — невідповідність версії формату snapshot версії клієнта. Solana періодично змінює формат snapshot. Якщо валідатор оновився, але намагається завантажити snapshot старого формату, він відмовить і спробує завантажити новий. Це нормальна поведінка, але вона подовжує час старту.

Розмір ledger та стратегії управління місцем

Ledger росте безперервно. Швидкість залежить від активності кластера: кількості транзакцій на слот, розміру транзакцій та кількості створюваних акаунтів. Точні цифри змінюються з часом, тому оператор повинен моніторити реальне зростання на своєму вузлі, а не покладатися на застарілі оцінки.

Для оцінки поточного розміру ledger на диску:

Середовище: Ubuntu 24.04 LTS, клієнт Agave, mainnet-beta.
Команда: du -sh /mnt/ledger/
Очікуваний результат: розмір каталогу ledger у людському форматі.
Ризики: відсутні, команда лише читає.

Стратегії управління дисковим простором ledger:

  • Обмеження глибини зберігання (limit-ledger-size). Валідатор можна налаштувати на автоматичне видалення старих слотів після досягнення певного розміру. Це основний інструмент для вузлів, які не надають історичні RPC-запити.
  • Роздільне зберігання ledger та snapshots. Монтаж ledger на швидкий NVMe-диск, а snapshots — на окремий том. Це дозволяє налаштувати різні політики резервного копіювання та моніторингу.
  • Archive-режим. Якщо вузол повинен зберігати повну історію (для RPC-сервісу або інших вузлів), параметр limit-ledger-size не використовується, і оператор повинен планувати ємність диска з значним запасом.

Попередження: Видалення файлів ledger вручну (через rm) під час роботи валідатора може призвести до пошкодження стану та неможливості відповісти на запити. Якщо потрібно звільнити місце терміново, зупиніть валідатор, видаліть старі слоти та перезапустіть. Безпечний відкат — відновити видалені файли з резервної копії перед перезапуском.

Налаштування зберігання snapshots

Конфігурація snapshots здійснюється через аргументи командного рядка валідатора або через файл конфігурації. Основні параметри:

  • --snapshots /путь/до/каталогу — вказує каталог для зберігання snapshots. Якщо не вказано, snapshots зберігаються всередині каталогу ledger. Винос snapshots на окремий диск дозволяє налаштувати різні рівні RAID або резервного копіювання.
  • --full-snapshot-interval-slots — інтервал між створенням повних snapshots у слотах. Збільшення значення зменшує дискове навантаження, але подовжує час відновлення при збої.
  • --incremental-snapshot-interval-slots — інтервал між інкрементальними snapshots. Типово значення менше, ніж для повних.
  • --maximum-snapshots-to-retain — кількість наборів snapshots, які зберігаються на диску. Старі набори видаляються автоматично. Збільшення цього значення дає більше точок для відновлення, але збільшує споживання місця.
  • --snapshot-packager-type — формат пакування snapshot (за замовчуванням tar.bz2, доступні інші варіанти залежно від версії клієнта).

Приклад перевірки поточних snapshot на диску:

Середовище: Ubuntu 24.04 LTS, клієнт Agave, mainnet-beta.
Команда: ls -lh /mnt/snapshots/
Очікуваний результат: список файлів snapshot із розмірами та часовими мітками.
Ризики: відсутні, команда лише читає.

Практична рекомендація: для валідаторів, що не надають історичні дані, достатньо зберігати 2–3 набори snapshots. Для RPC-вузлів або вузлів з нестабільним живленням варто збільшити це значення до 4–6, щоб мати більше точок відновлення при повторних збоях.

При зміні каталогу snapshots на вже працюючому вузлі необхідно зупинити валідатор, перенести існуючі файли snapshot у новий каталог, змінити конфігурацію та перезапустити. Якщо цього не зробити, валідатор не знайде локальні snapshots і завантажуватиме їх з мережі, що значно подовжить час старту.

Наступний крок у налаштуванні інфраструктури — як налаштувати systemd service для валідатора, де snapshot та ledger каталоги будуть прописані в параметрах запуску сервісу.

Джерела