Перейти до основного контенту
Change page

Архівна нода Ethereum

Останні оновлення сторінки: 23 лютого 2026 р.

pete-vielhaberp (opens in a new tab)
nhszn (opens in a new tab)
corwintinesc (opens in a new tab)
+5

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

Передумови

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

Що таке архівна нода

Щоб зрозуміти важливість архівної ноди, прояснімо поняття "стан". Ethereum можна назвати транзакційною машиною стану. Він складається з облікових записів і додатків, які виконують транзакції і змінюють свій стан. Глобальні дані з інформацією про кожен обліковий запис і контракт зберігаються в тривимірній базі даних, яка називається state. За ці процеси відповідає клієнт рівня виконання (execution layer, EL), який включає в себе:

  • Залишки на рахунках і нецільові кошти
  • Код договору та зберігання
  • Дані, пов’язані з консенсусом, наприклад, контракт депозиту для стейкінгу (Staking Deposit Contract).

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

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

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

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

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

Способи застосування

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

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

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

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

  • Постачальників послуг, таких як блокчейн-експлорери
  • Дослідників
  • Аналітиків безпеки
  • Розробників Dapp
  • Аудиту та відповідності

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

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

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

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

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

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

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

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

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

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

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

Для подальшого читання

Пов'язані теми

Чи була ця стаття корисною?