Налаштування архівної ноди Ethereum: Erigon, Reth, Arbitrum

Чому архівна нода Ethereum перестає відповідати на запити

Архівна нода Ethereum відповідає на історичні запити до блокчейну за будь-який блок — стан на конкретній висоті, баланс адреси до першого руху, результат виклику контракту, якого вже немає. На цьому будується аудит, аналітика й звірка транзакцій.

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

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

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

Друга причина — диск. Архівна конфігурація перетворює навантаження на потік випадкових читань за ключами стану, і деградація дискового вводу-виводу проявляється раніше, ніж закінчується місце.

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

Третя — планування: історії виявляється більше, ніж закладали, диск уходить у нуль, і сервіс падає саме тоді, коли переіндексація займає дні.

Розбираємо, як це закривається: який профіль зберігання вибрати для Erigon і Reth, як відокремити архівний вузол від звичайного і що моніторити, щоб відмова була видна заздалегідь, а не за скаргою аналітиків.

Що змінюється після коректної синхронізації архіву

Архівний вузол відрізняється від повної ноди не обсягом диска, а тим, що стан зберігається для кожного блоку. Якщо синхронізація пройшла неправильно, запити до старих блоків ідуть через відкат і повторне виконання замість читання з диска.

Звідси десятки секунд на один виклик, відвали за тайм-аутом в індексатора й черга, яка зростає швидше, ніж надходить трафік.

Після коректного складання архіву змінюються три вимірювані речі. Швидкість відповіді на історичні запити виходить у одиниці секунд на першому прогріві й частки секунди на повторних зверненнях — стан читається напряму.

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

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

Повнота історії транзакцій — окремий результат: трасування, квитанції й внутрішні перекази доступні за весь період, без пропусків у діапазонах блоків. Саме на цьому будуються звіти, аудит і відновлення балансів на довільну дату.

Режими зберігання даних: архівний, повний і полегшений

Режим зберігання визначає, яку частину історії станів нода віддає на запит. Архівний режим зберігає стан на кожній висоті блоку, повна нода тримає поточний стан та історію блоків, полегшена — лише заголовки й докази.

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

Різниця помітна не на «останньому блоці», а на глибині запиту. Розрахунок історичних балансів, звірка подій за контрактом, аудит транзакцій і переіндексація потребують стану на конкретній висоті — повна нода на такий запит відповідає помилкою, а не застарілими даними.

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

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

Етапи розгортання й синхронізації ноди

Розгортання архівної ноди — це не «завантажити клієнт і запустити», а послідовність, де помилка на ранньому кроці коштує тижнів повторної синхронізації. Нижче — порядок робіт, за яким ми ведемо проєкт від обстеження до передачі в експлуатацію.

1. Обстеження. Фіксуємо мережі й глибину архіву: потрібен повний історичний state, лише логи чи ще й трасування. Рахуємо профіль навантаження — частка запитів eth_getLogs і debug_trace* за історичними блоками, цільова кількість одночасних підключень. Це визначає і клієнт, і вимоги до диска.
2. Проєктування. Вибираємо клієнт виконання під задачу: Erigon — коли важливіше компактне зберігання й глибока історія, Reth — коли пріоритет швидкість догону й чутливість RPC. Окремо проєктуємо Arbitrum-ноду, якщо потрібен доступ до L2-історії. Тут же — схема розділення дисків під дані, журнали й снапшоти.
3. Підготовка сховища. Розмітка й монтування з потрібним розміром блоку й запасом на зростання, налаштування лімітів дескрипторів, файлу підкачки й політики стиснення. Сховище проєктуємо так, щоб реєстр не зростав лавиноподібно й залишався запас під майбутні блоки.
4. Встановлення й первинне завантаження. Розгортаємо клієнт в ізольованому середовищі, підключаємо снапшот замість синхронізації з нуля — це скорочує вихід на актуальну висоту з тижнів до годин.
5. Синхронізація архіву. Ведемо догін до голови мережі, контролюючи швидкість обробки блоків і відставання. На цьому етапі видно, чи впирається конфігурація в диск або в мережу, — параметри правляться до фінального стану.
6. Перевірка цілісності. Звіряємо кореневий стан із публічним джерелом, виконуємо тестові запити до історичних блоків, порівнюємо відповіді на кількох висотах. Перевіряємо й поведінку при перезапуску: нода повинна підніматися без повторної синхронізації.
7. Моніторинг і передача. Підключаємо збір метрик та алерти щодо відставання й помилок RPC, обмежуємо доступ до важких методів. Передаємо доступи, регламент оновлення клієнта й інструкцію відновлення зі снапшота.

Конфігурації, схеми й регламенти супроводу

Архівна нода не повинна залишатися «чорною скринькою», яку обслуговує лише той, хто її зібрав. Ми передаємо замовнику комплект артефактів, за яким вузол можна підняти з нуля, перевірити коректність синхронізації й віддати на супровід іншій команді — без переказів із пам’яті.

• Файли конфігурації — параметри клієнта (Erigon, Reth): режим зберігання стану, ліміти кешу й з’єднань, глибина архіву. Кожне значення прокоментовано, щоб правку можна було внести без нас.
• Схема інфраструктури — карта сервісів, сховищ і мережевих зон, точки відмови й залежності між ними, розподіл ролей за вузлами.
• Політики доступу — хто і за яким ключем звертається до JSON-RPC, що відкрито назовні, як видаються й відкликаються ключі, де логуються запити.
• Регламент обслуговування — періодичність оновлень клієнта, перевірка цілісності бази, порядок пересинхронізації в разі розходження стану, вікна робіт.
• Моніторинг і оповіщення — метрики відставання від мережі, глибини архіву й вільного місця, пороги, за яких піднімається черговий.
• Інструкції з типових операцій — зняття снапшота сховища, перемикання на резервний вузол, відкат на попередню версію клієнта.
• Документація по вузлу — журнал змін, відповідальні, історія інцидентів і ухвалених рішень.

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

Далі напрям можна розвивати власними силами або передати іншому підряднику — поріг входу буде низьким.

Міграція архіву без зупинки сервісу: що змінилося

Робочий вузол тримав лише актуальні стани: обрізання історії було ввімкнено, тому запити глибше останніх блоків ішли до зовнішніх джерел або падали за тайм-аутом.

Аналітика за старими контрактами й звірка операцій чекали відповіді секундами, а на піках вузол переставав встигати за потоком. Частина перевірок просто не запускалася — у звітності залишалися прогалини.

Міграцію блокчейн-вузла побудували без вікна простою. Розгорнули Erigon в архівному режимі на окремому сервері: він догнав мережу й зібрав знімки станів, поки робочий вузол продовжував обслуговувати трафік. Перемикання робили на балансувальнику — спочатку перевели читання історії, потім решту запитів.

Метрики до і після

Доступність під час робіт зберегли: перерва в обслуговуванні — нуль, а відкат на попередній вузол залишався можливим до кінця перемикання. Час відповіді на історичний запит скоротився до часток секунди, глибина історії зросла з останніх блоків до всього ланцюга. Зовнішні джерела більше не беруть участі у відповідях — архів відповідає власний вузол.

Що робити, якщо синхронізація вже триває тижнями?

Тижні синхронізації — це майже завжди не «повільний інтернет», а конкретне вузьке місце. Процес варто розділити на етапи: догін блоків, відновлення стану, побудова індексів, перевірка цілісності. Застрягти можна на будь-якому, і лікується кожен по-своєму.

Найчастіше впирається в диск. Архівна нода Ethereum одночасно дописує свіжий стан і читає історичні зрізи, тому навантаження на накопичувач зростає разом із висотою ланцюга.

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

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

Erigon і Reth поводяться по-різному, тому параметри підбираються під вибрану реалізацію, а не копіюються з чужого конфігу.

Пересобирати архів варто при пошкодженому стані, незбіжних індексах або відставанні в епохи — тоді швидше підняти стан зі зліпка довіреного джерела й догнати залишок мережею.

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

Ми починаємо з діагностики: знімаємо метрики за етапами, знаходимо вузьке місце і лише потім пропонуємо пересборку або зміну режиму. Так дні простою не йдуть на повторні спроби синхронізації.

Технічні сумніви: сховище, відмовостійкість, доступ

Архівна нода зберігає стан на всіх висотах, тому диск зростає разом із ланцюгом і обганяє звичайний вузол-спостерігач у рази. Клієнти на кшталт Erigon і Reth розходяться в моделі зберігання: одна база більша, зате дешевша за дисковими операціями, інша компактніша. Запас рахуємо від поточного темпу наповнення блоків, а не за середніми цифрами з документації.

Що відбувається з вузлом при збої?

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

Як обмежити доступ до вузла?

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

Як влаштовано резервне копіювання?

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

Обговоримо задачу: оцінка, план і порядок робіт

Оцінка за архівною нодою не рахується «на око»: повний архів від генезису й вузол з обмеженим вікном історії — це різні вимоги до дисків, часу первинної синхронізації й схеми резервування.

Щоб повернутися з планом, а не з вилкою навмання, нам потрібні ввідні щодо навантаження й інфраструктури.

• Профіль навантаження: які методи RPC викликаються, скільки паралельних клієнтів, потрібна історія від генезису чи вистачить вікна за останні блоки.
• Де розгортаємо: власні сервери, хмара або гібрид, доступний обсяг сховища й тип дисків, смуга мережі.
• Клієнт і режим синхронізації: Erigon або Reth під ваш профіль, старт зі снапшота або з генезису, допустиме вікно недоступності.
• Доступи й периметр: ключі, приватна мережа, окремий вузол під RPC-трафік, обмеження за адресами.
• Технічне завдання: склад робіт і критерії приймання — відставання від голови ланцюга, час відповіді на запит, поведінка при відмові диска.
• План впровадження: розгортання, репетиція на тестовій мережі, вікно перемикання, перевірений сценарій відкату.
• Супровід вузла: моніторинг з алертами, оновлення клієнта без простою, снапшоти з перевіркою відновлюваності, чергування за інцидентами.

Опишіть задачу й поточну схему — повернемося з оцінкою за етапами, планом впровадження й варіантом супроводу після запуску.