Архівний вузол Етеріуму

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

Передумови

Ви повинні розуміти концепцію вузла Етеріуму, його архітектуру, стратегії синхронізації, а також практики їх запуску та використання.

Що таке архівний вузол

Щоб зрозуміти важливість архівного вузла, давайте прояснимо концепцію «стану». Етеріум можна назвати машиною станів на основі транзакцій. Він складається з акаунтів і застосунків, що виконують транзакції, які змінюють їхній стан. Глобальні дані з інформацією про кожен акаунт і контракт зберігаються в базі даних у вигляді префіксного дерева (trie), яка називається станом. За це відповідає клієнт рівня виконання (EL), і сюди входять:

Баланси акаунтів та їхні nonce
Код і сховище контрактів
Дані, пов'язані з консенсусом, наприклад, контракт стейкінгового депозиту (Staking Deposit Contract)

Щоб взаємодіяти з мережею, перевіряти та створювати нові блоки, клієнти Етеріуму повинні встигати за останніми змінами (вершиною ланцюга), а отже, і за поточним станом. Клієнт рівня виконання, налаштований як повний вузол, перевіряє та відстежує останній стан мережі, але кешує лише кілька попередніх станів, наприклад, стан, пов'язаний з останніми 128 блоками, щоб він міг обробляти реорганізації ланцюга та забезпечувати швидкий доступ до недавніх даних. Недавній стан — це те, що потрібно всім клієнтам для перевірки вхідних транзакцій і використання мережі.

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

Історичні стани можна безпечно видаляти (prune), оскільки вони не потрібні для роботи мережі, і для клієнта було б марно зберігати всі застарілі дані. Стани, які існували до певного недавнього блоку (наприклад, за 128 блоків до вершини), фактично відкидаються. Повні вузли зберігають лише історичні дані блокчейну (блоки та транзакції) і періодичні історичні знімки, які вони можуть використовувати для відновлення старих станів за запитом. Вони роблять це шляхом повторного виконання минулих транзакцій в EVM, що може бути обчислювально складним, коли бажаний стан знаходиться далеко від найближчого знімка.

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

Важливо зазначити, що мережа не залежить від архівних вузлів для збереження та надання всіх історичних даних. Як зазначалося вище, усі історичні проміжні стани можна отримати на повному вузлі. Транзакції зберігаються будь-яким повним вузлом (наразі це менше 400 ГБ) і можуть бути відтворені для створення всього архіву.

Випадки використання

Регулярне використання Етеріуму, як-от надсилання транзакцій, розгортання контрактів, перевірка консенсусу тощо, не вимагає доступу до історичних станів. Користувачам ніколи не потрібен архівний вузол для стандартної взаємодії з мережею.

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

Яким був баланс ETH акаунта 0x1337... на блоці 15537393?
Який баланс токена 0x у контракті 0x на блоці 1920000?

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

Постачальники послуг, як-от оглядачі блоків
Дослідники
Аналітики з безпеки
Розробники децентралізованих застосунків (dapp)
Аудит і дотримання нормативних вимог

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

Реалізації та використання

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

Перш ніж запускати власний архівний вузол, дізнайтеся про відмінності між клієнтами та особливо про різні вимоги до апаратного забезпечення. Більшість клієнтів не оптимізовані для цієї функції, і їхні архіви потребують понад 12 ТБ простору. Натомість такі реалізації, як Ерігон, можуть зберігати ті самі дані в обсязі менше 3 ТБ, що робить їх найефективнішим способом запуску архівного вузла.

Рекомендовані практики

Окрім загальних рекомендацій щодо запуску вузла, архівний вузол може бути більш вимогливим до апаратного забезпечення та обслуговування. Враховуючи ключові особливості (opens in a new tab) Ерігон, найпрактичнішим підходом є використання реалізації клієнта Ерігон.

Апаратне забезпечення

Завжди перевіряйте вимоги до апаратного забезпечення для певного режиму в документації клієнта. Найбільшою вимогою для архівних вузлів є дисковий простір. Залежно від клієнта, він варіюється від 3 ТБ до 12 ТБ. Навіть якщо HDD може вважатися кращим рішенням для великих обсягів даних, для його синхронізації та постійного оновлення вершини ланцюга знадобляться SSD-накопичувачі. Накопичувачі SATA (opens in a new tab) цілком підходять, але вони мають бути надійної якості, принаймні TLC (opens in a new tab). Диски можна встановити в настільний комп'ютер або сервер із достатньою кількістю слотів. Такі виділені пристрої ідеально підходять для запуску вузла з високим часом безвідмовної роботи (uptime). Його цілком можливо запустити на ноутбуці, але портативність обійдеться додатковими витратами.

Усі дані повинні поміститися на одному томі, тому диски потрібно об'єднати, наприклад, за допомогою RAID0 (opens in a new tab) або LVM. Також варто розглянути використання ZFS (opens in a new tab), оскільки вона підтримує функцію «копіювання під час запису» (Copy-on-write), яка гарантує правильний запис даних на диск без будь-яких низькорівневих помилок.

Для більшої стабільності та безпеки в запобіганні випадковому пошкодженню бази даних, особливо в професійному середовищі, розгляньте можливість використання пам'яті ECC (opens in a new tab), якщо ваша система її підтримує. Обсяг оперативної пам'яті зазвичай рекомендується такий самий, як і для повного вузла, але більший обсяг оперативної пам'яті може допомогти прискорити синхронізацію.

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