Прискорте ваш власний Ethereum вузол
Останні оновлення сторінки: 26 лютого 2026 р.
Створення власного вузла надає вам різні переваги, відкриває нові можливості та допомагає підтримувати екосистему. Ця сторінка допоможе вам підготувати ваш власний вузол та взяти участь в затвердженні транзакцій Ethereum.
Зверніть увагу, що після The Merge для запуску вузла Ethereum потрібні два клієнти: клієнт виконавчого рівня (EL) і клієнт рівня консенсусу (CL). На цій сторінці буде показано, як установити, налаштувати та підключити ці два клієнти для запуску вузла Ethereum.
Передумови
Ви повинні розуміти, що таке вузол Ethereum і чому можете бути краще запустити клієнт. Це описано в розділі Вузли та клієнти.
Якщо ви не знайомі з темою запуску вузла або шукаєте менш технічний шлях, ми рекомендуємо спочатку ознайомитися з нашим зручним вступом про запуск вузла Ethereum.
Вибір підходу
Перший крок в налаштуванні вашого вузла - вибір вашого підходу. Виходячи з вимог і різноманітних можливостей, ви повинні вибрати реалізацію клієнта (як клієнта виконання, так і клієнта консенсусу), середовище (апаратне забезпечення, система) та параметри для налаштувань клієнта.
Ця сторінка допоможе вам прийняти ці рішення та знайти найбільш підходящий спосіб запуску вашого екземпляра Ethereum.
Щоб вибрати з реалізацій клієнтів, перегляньте всі доступні, готові для Mainnet клієнти виконання, клієнти консенсусу та дізнайтеся про різноманітність клієнтів.
Вирішіть, чи запускати програмне забезпечення на власному апаратному забезпеченні чи в хмарі, враховуючи вимоги клієнтів.
Після підготовки середовища встановіть вибрані клієнти або за допомогою зручного для початківців інтерфейсу, або вручну за допомогою терміналу з розширеними опціями.
Коли вузол запущений і синхронізується, ви готові використовувати його, але не забувайте стежити за його обслуговуванням.
Середовище та апаратне забезпечення
Локально чи в хмарі
Клієнти Ethereum можуть працювати на комп’ютерах споживчого класу і не потребують спеціального обладнання, як, наприклад, машини для майнінгу. Тому у вас є різні варіанти розгортання вузла залежно від ваших потреб. Для спрощення розглянемо запуск вузла як і на локальному фізичному пристрої, так і на хмарному сервері:
- Хмарне сховище
- Провайдери пропонують високий час безвідмовної роботи сервера та статичні загальнодоступні IP-адреси
- Отримання виділеного або віртуального сервера може бути зручніше, ніж створення власного сервера
- Компроміс довіряє третій особі - постачальнику сервера
- Через необхідний обсяг сховища для повного вузла ціна орендованого сервера може бути високою
- Власне обладнання
- Більш надійний та незалежний підхід
- Інвестувати треба лише раз
- Можливість придбання попередньо налаштованих машин
- Ви повинні фізично готувати, обслуговувати та потенційно усувати несправності машини та мережі
Обидва варіанти мають різні переваги, які були підсумовані вище. Якщо ви шукаєте хмарне рішення, окрім багатьох традиційних постачальників хмарних обчислень, є також послуги, орієнтовані на запуск вузлів. Перегляньте вузли як послугу, щоб дізнатися більше про варіанти розміщених вузлів.
Апаратне забезпечення
Однак резистентна до цензури, децентралізована мережа не повинна покладатися на постачальників хмарного забезпечення. Натомість запуск вузла на власному локальному обладнанні є кращим для екосистеми. Оцінки (opens in a new tab) показують, що значна частина вузлів працює в хмарі, що може стати єдиною точкою відмови.
Клієнти Ethereum можуть працювати на вашому комп’ютері, ноутбуці, сервері або навіть на одноплатному комп’ютері. Хоча запускати клієнти на персональному комп’ютері можливо, наявність виділеної машини лише для вашого вузла може значно підвищити його продуктивність і безпеку, мінімізуючи вплив на ваш основний комп’ютер.
Використовувати власне обладнання може бути дуже легко. Існує багато простих варіантів, а також розширені налаштування для більш технічно підкованих людей. Тож давайте розглянемо вимоги та засоби для запуску клієнтів Ethereum на вашій машині.
Вимоги
Вимоги до апаратного забезпечення розрізняються залежно від клієнта, але зазвичай не такі високі, оскільки вузол просто повинен залишатися синхронізованим. Не плутайте це з майнінгом, який вимагає набагато більшої обчислювальної потужності. Однак час синхронізації і продуктивність поліпшуються з більш потужним апаратним забезпеченням.
Перед встановленням будь-якого клієнта переконайтеся, що на вашому комп'ютері достатньо ресурсів для його запуску. Нижче ви можете знайти мінімальні та рекомендовані вимоги.
Вузьким місцем для вашого апаратного забезпечення є переважно дисковий простір. Синхронізація блокчейну Ethereum дуже інтенсивна щодо операцій введення/виведення та вимагає багато місця. Найкраще мати твердотільний накопичувач (SSD) із сотнями ГБ вільного місця навіть після синхронізації.
Розмір бази даних і швидкість початкової синхронізації залежать від вибраного клієнта, його конфігурації та стратегії синхронізації.
Також переконайтеся, що ваше інтернет-з’єднання не обмежене лімітом пропускної здатності (opens in a new tab). Рекомендується використовувати необмежене підключення, оскільки початкова синхронізація та дані, що передаються в мережу, можуть перевищити ваш ліміт.
Операційна система
Усі клієнти підтримують основні операційні системи - Linux, MacOS, Windows. Це означає, що ви можете запускати вузли на звичайних настільних комп’ютерах або серверах з операційною системою (ОС), яка найкраще підходить для вас. Переконайтеся, що ваша операційна система оновлена, щоб уникнути потенційних проблем і вразливостей безпеки.
Мінімальні вимоги
- Центральний процесор з 2+ ядрами
- 8 ГБ ОЗП
- 2 ТБ SSD
- 10+ Мбіт/с пропускної здатності
Рекомендовані характеристики
- Швидкий центральний процесор з 4+ ядрами
- 16 гб + оперативна пам'ять
- Швидкий SSD на 2+ ТБ
- 25+ Мбіт/с пропускної здатності
Режим синхронізації та клієнт, які ви виберете, вплинуть на вимоги до простору, але ми оцінили дисковий простір, який вам знадобиться для кожного клієнта, нижче.
| Клієнт | Розмір диска (snap-синхронізація) | Розмір диску (повний архів) |
|---|---|---|
| Besu | 800 ГБ+ | 12 ТБ+ |
| Erigon | Недоступно | 2,5 ТБ+ |
| Geth | 500 ГБ+ | 12 ТБ+ |
| Nethermind | 500 ГБ+ | 12 ТБ+ |
| Reth | Недоступно | 2,2 ТБ+ |
- Примітка: Erigon і Reth не пропонують snap-синхронізацію, але можливе повне очищення (Full Pruning) (~2 ТБ для Erigon, ~1,2 ТБ для Reth)
Для клієнтів консенсусу вимога до простору також залежить від реалізації клієнта та ввімкнених функцій (наприклад, слешер валідатора), але зазвичай розраховуйте на ще 200 ГБ, необхідних для даних маяка. З великою кількістю валідаторів навантаження на пропускну здатність також зростає. Ви можете знайти деталі щодо вимог до клієнта консенсусу в цьому аналізі (opens in a new tab).
Рішення «підключи й працюй»
Найпростіший варіант запуску вузла на власному обладнанні – це використання пристроїв «підключи й працюй». Попередньо налаштовані машини від постачальників пропонують найпростіший досвід: замовте, підключіть, запустіть. Усе попередньо налаштовано та працює автоматично з інтуїтивно зрозумілим посібником та інформаційною панеллю для моніторингу та керування програмним забезпеченням.
Ethereum на одноплатному комп’ютері
Простий і дешевий спосіб запустити вузол Ethereum — це використовувати одноплатний комп’ютер, навіть з архітектурою ARM, як-от Raspberry Pi. Ethereum on ARM (opens in a new tab) надає прості в запуску образи кількох клієнтів виконання та консенсусу для Raspberry Pi та інших плат ARM.
Такі невеликі, доступні та ефективні пристрої ідеально підходять для запуску вузла вдома, але пам’ятайте про їх обмежену продуктивність.
Запуск вузла
Фактичне налаштування клієнта можна виконати або за допомогою автоматизованих засобів запуску, або вручну, налаштувавши клієнтське програмне забезпечення безпосередньо.
Для менш досвідчених користувачів рекомендований підхід — це використання програми запуску, програмного забезпечення, яке проведе вас через установку та автоматизує процес налаштування клієнта. Однак, якщо у вас є досвід роботи з терміналом, кроки для ручного налаштування будуть простими.
Налаштування з посібником
Кілька зручних для користувача проєктів спрямовані на покращення досвіду налаштування клієнта. Ці програми запуску забезпечують автоматичне встановлення та налаштування клієнтів, а деякі навіть пропонують графічний інтерфейс для керованого налаштування та моніторингу клієнтів.
Нижче наведено кілька проєктів, які допоможуть вам установити та керувати клієнтами лише кількома клацаннями:
- DappNode (opens in a new tab) - DappNode — це не лише машина від постачальника. Програмне забезпечення, фактичний засіб запуску вузла та центр керування з багатьма функціями можна використовувати на будь-якому обладнанні.
- EthPillar (opens in a new tab) – найшвидший і найпростіший спосіб налаштувати повний вузол. Однорядковий інструмент налаштування та TUI для керування вузлом. Безкоштовно. Відкрите джерело коду. Суспільні блага для Ethereum від соло-стейкерів. Підтримка ARM64 та AMD64.
- eth-docker (opens in a new tab) — автоматизоване налаштування за допомогою Docker, орієнтоване на простий і безпечний стейкінг, вимагає базових знань терміналу та Docker, рекомендовано для трохи більш просунутих користувачів.
- Stereum (opens in a new tab) — програма запуску для встановлення клієнтів на віддалений сервер через SSH-з’єднання з посібником із налаштування графічного інтерфейсу, центром керування та багатьма іншими функціями.
- NiceNode (opens in a new tab) — програма запуску з простим користувацьким інтерфейсом для запуску вузла на вашому комп’ютері. Просто виберіть клієнти та запустіть їх кількома клацаннями. Ще в розробці.
- Sedge (opens in a new tab) — інструмент налаштування вузла, який автоматично генерує конфігурацію Docker за допомогою майстра CLI. Написано на Go компанією Nethermind.
Ручне налаштування клієнтів
Інший варіант — завантажити, перевірити та налаштувати клієнтське програмне забезпечення вручну. Навіть якщо деякі клієнти пропонують графічний інтерфейс, ручне налаштування все одно вимагає базових навичок роботи з терміналом, але пропонує набагато більшу універсальність.
Як пояснювалося раніше, налаштування власного вузла Ethereum вимагатиме запуску пари клієнтів консенсусу та виконання. Деякі клієнти можуть містити легкий клієнт іншого типу та синхронізуватися без будь-якого іншого програмного забезпечення. Однак повна бездовірна перевірка вимагає обох реалізацій.
Отримання клієнтського програмного забезпечення
Спочатку вам потрібно отримати бажане програмне забезпечення клієнта виконання та клієнта консенсусу.
Ви можете просто завантажити виконуваний застосунок або інсталяційний пакет, який підходить для вашої операційної системи та архітектури. Завжди перевіряйте підписи та контрольні суми завантажених пакетів. Деякі клієнти також пропонують репозиторії або образи Docker для полегшення встановлення та оновлення. Усі клієнти мають відкритий вихідний код, тому ви також можете зібрати їх із вихідного коду. Це більш просунутий метод, але в деяких випадках він може знадобитися.
Інструкції зі встановлення кожного клієнта наведено в документації, посилання на яку є в списках клієнтів вище.
Ось сторінки випусків клієнтів, де ви можете знайти їхні попередньо зібрані двійкові файли або інструкції зі встановлення:
Клієнти виконання
- Besu (opens in a new tab)
- Erigon (opens in a new tab)
- Geth (opens in a new tab)
- Nethermind (opens in a new tab)
- Reth (opens in a new tab)
Варто також зазначити, що різноманітність клієнтів є проблемою на рівні виконання. Читачам рекомендується розглянути можливість запуску клієнта виконання, що є в меншості.
Клієнти консенсусу
- Lighthouse (opens in a new tab)
- Lodestar (opens in a new tab) (Не надає попередньо зібраний двійковий файл, лише образ Docker або для збирання з вихідного коду)
- Nimbus (opens in a new tab)
- Prysm (opens in a new tab)
- Teku (opens in a new tab)
Різноманітність клієнтів має вирішальне значення для вузлів консенсусу, що запускають валідаторів. Якщо більшість валідаторів використовують одну реалізацію клієнта, безпека мережі під загрозою. Тому рекомендується розглянути можливість вибору клієнта, що є в меншості.
Перегляньте останнє використання мережевих клієнтів (opens in a new tab) та дізнайтеся більше про різноманітність клієнтів.
Перевірка програмного забезпечення
Під час завантаження програмного забезпечення з Інтернету рекомендується перевіряти його цілісність. Цей крок є необов'язковим, але особливо з таким важливим елементом інфраструктури, як клієнт Ethereum, важливо знати про потенційні вектори атак і уникати їх. Якщо ви завантажили попередньо зібраний двійковий файл, ви повинні довіряти йому і ризикувати тим, що зловмисник може замінити виконуваний файл на шкідливий.
Розробники підписують випущені двійкові файли своїми PGP-ключами, щоб ви могли криптографічно перевірити, що ви запускаєте саме те програмне забезпечення, яке вони створили. Вам просто потрібно отримати відкриті ключі, які використовуються розробниками, їх можна знайти на сторінках випусків клієнтів або в документації. Після завантаження випуску клієнта та його підпису ви можете використовувати реалізацію PGP, наприклад, GnuPG (opens in a new tab), щоб легко їх перевірити. Ознайомтеся з посібником із перевірки програмного забезпечення з відкритим кодом за допомогою gpg на linux (opens in a new tab) або Windows/MacOS (opens in a new tab).
Інша форма перевірки — переконатися, що хеш, унікальний криптографічний відбиток програмного забезпечення, яке ви завантажили, збігається з тим, що надали розробники. Це навіть простіше, ніж використання PGP, і деякі клієнти пропонують лише цей варіант. Просто запустіть хеш-функцію для завантаженого програмного забезпечення та порівняйте результат із тим, що на сторінці випуску. Наприклад:
1sha256sum teku-22.6.1.tar.gz239b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767ddeНалаштування клієнта
Після встановлення, завантаження або компіляції клієнтського програмного забезпечення ви готові його запустити. Це лише означає, що його потрібно виконувати з належною конфігурацією. Клієнти пропонують багаті параметри конфігурації, які можуть увімкнути різні функції.
Почнемо з опцій, які можуть значно вплинути на продуктивність клієнта та використання даних. Режими синхронізації представляють різні методи завантаження та перевірки даних блокчейну. Перед запуском вузла вам слід вирішити, яку мережу і режим синхронізації використовувати. Найважливіше, що слід враховувати, — це дисковий простір і час синхронізації, який знадобиться клієнту. Зверніть увагу на документацію клієнта, щоб визначити, який режим синхронізації є стандартним. Якщо це вам не підходить, виберіть інший, виходячи з рівня безпеки, доступних даних і вартості. Крім алгоритму синхронізації, ви також можете налаштувати обрізання різних видів старих даних. Очищення (pruning) дозволяє видаляти застарілі дані, тобто видаляти вузли дерева станів (state trie), недоступні з останніх блоків.
Інші основні параметри конфігурації — це, наприклад, вибір мережі (Mainnet або тестові мережі), увімкнення кінцевої точки HTTP для RPC або WebSockets тощо. Ви можете знайти всі функції та параметри в документації клієнта. Різні конфігурації клієнта можна встановити, виконавши клієнт із відповідними прапорцями безпосередньо в CLI або файлі конфігурації. Кожен клієнт дещо відрізняється; будь ласка, завжди звертайтеся до його офіційної документації або сторінки довідки для отримання детальної інформації про параметри конфігурації.
Для тестування ви можете віддати перевагу запуску клієнта в одній із тестових мереж. Переглянути огляд підтримуваних мереж.
Приклади запуску клієнтів виконання з базовою конфігурацією можна знайти в наступному розділі.
Запуск клієнта виконання
Перед запуском клієнтського програмного забезпечення Ethereum виконайте останню перевірку готовності вашого середовища. Наприклад, переконайтеся:
- Достатньо дискового простору з огляду на обрану мережу та режим синхронізації.
- Пам'ять і ЦП не зупиняються іншими програмами.
- Операційну систему оновлено до останньої версії.
- Система має правильний час і дату.
- Ваш маршрутизатор і брандмауер приймають підключення до портів прослуховування. За замовчуванням клієнти Ethereum використовують порт прослуховування (TCP) і порт виявлення (UDP), обидва за замовчуванням 30303.
Спочатку запустіть клієнта в тестовій мережі, щоб переконатися, що все працює правильно.
На початку вам потрібно оголосити будь-які налаштування клієнта, які не є стандартними. Ви можете використовувати прапорці або файл конфігурації, щоб оголосити бажану конфігурацію. Набір функцій і синтаксис конфігурації кожного клієнта відрізняються. Перегляньте документацію вашого клієнта для отримання детальної інформації.
Клієнти виконання та консенсусу взаємодіють через автентифіковану кінцеву точку, зазначену в Engine API (opens in a new tab). Щоб підключитися до клієнта консенсусу, клієнт виконання повинен згенерувати jwtsecret (opens in a new tab) за відомим шляхом. З міркувань безпеки та стабільності клієнти повинні працювати на одній машині, і обидва клієнти повинні знати цей шлях, оскільки він використовується для автентифікації локального з’єднання RPC між ними. Клієнт виконання також повинен визначити порт прослуховування для автентифікованих API.
Цей токен генерується автоматично клієнтським програмним забезпеченням, але в деяких випадках вам може знадобитися зробити це самостійно. Ви можете згенерувати його за допомогою OpenSSL (opens in a new tab):
1openssl rand -hex 32 > jwtsecretЗапуск клієнта виконання
У цьому розділі ви дізнаєтеся, як запускати клієнти виконання. Він служить лише прикладом базової конфігурації, яка запустить клієнт із такими налаштуваннями:
- Вказує мережу для підключення, у наших прикладах — Mainnet
- Натомість ви можете вибрати одну з тестових мереж для попереднього тестування вашого налаштування
- Визначає каталог даних, де зберігатимуться всі дані, включно з блокчейном
- Переконайтеся, що ви замінили шлях на реальний, наприклад, що вказує на ваш зовнішній диск
- Вмикає інтерфейси для зв’язку з клієнтом
- Включно з JSON-RPC та Engine API для зв’язку з клієнтом консенсусу
- Визначає шлях до
jwtsecretдля автентифікованого API- Обов’язково замініть приклад шляху на реальний, доступний для клієнтів, наприклад,
/tmp/jwtsecret
- Обов’язково замініть приклад шляху на реальний, доступний для клієнтів, наприклад,
Зверніть увагу, що це лише базовий приклад, усі інші налаштування будуть встановлені за замовчуванням. Зверніть увагу на документацію кожного клієнта, щоб дізнатися про стандартні значення, налаштування та функції. Для отримання додаткових функцій, наприклад, для запуску валідаторів, моніторингу тощо, зверніться до документації конкретного клієнта.
Зауважте, що зворотні косі риски `` у прикладах призначені лише для форматування; прапорці конфігурації можна визначити в одному рядку.
Запуск Besu
Цей приклад запускає Besu в мережі Mainnet, зберігає дані блокчейну у форматі за замовчуванням у /data/ethereum, вмикає JSON-RPC та Engine RPC для підключення клієнта консенсусу. Engine API автентифікується за допомогою токена jwtsecret, і дозволені лише виклики з localhost.
1besu --network=mainnet \2 --data-path=/data/ethereum \3 --rpc-http-enabled=true \4 --engine-rpc-enabled=true \5 --engine-host-allowlist="*" \6 --engine-jwt-enabled=true \7 --engine-jwt-secret=/path/to/jwtsecretBesu також має опцію запуску, яка поставить низку запитань і згенерує файл конфігурації. Запустіть інтерактивний засіб запуску за допомогою:
1besu --XlauncherДокументація Besu (opens in a new tab) містить додаткові параметри та деталі конфігурації.
Запуск Erigon
Цей приклад запускає Erigon в мережі Mainnet, зберігає дані блокчейну в /data/ethereum, вмикає JSON-RPC, визначає, які простори імен дозволені, і вмикає автентифікацію для підключення клієнта консенсусу, що визначається шляхом до jwtsecret.
1erigon --chain mainnet \2 --datadir /data/ethereum \3 --http --http.api=engine,eth,web3,net \4 --authrpc.jwtsecret=/path/to/jwtsecretErigon за замовчуванням виконує повну синхронізацію з 8 ГБ жорсткого диска, що призведе до більш ніж 2 ТБ архівних даних. Переконайтеся, що datadir вказує на диск із достатнім вільним місцем, або зверніть увагу на прапорець --prune, який може обрізати різні види даних. Перевірте --help Erigon, щоб дізнатися більше.
Запуск Geth
Цей приклад запускає Geth у мережі Mainnet, зберігає дані блокчейну в /data/ethereum, вмикає JSON-RPC та визначає дозволені простори імен. Він також вмикає автентифікацію для підключення клієнта консенсусу, що вимагає шлях до jwtsecret, а також опцію, що визначає дозволені з'єднання, у нашому прикладі — лише з localhost.
1geth --mainnet \2 --datadir "/data/ethereum" \3 --http --authrpc.addr localhost \4 --authrpc.vhosts="localhost" \5 --authrpc.port 85516 --authrpc.jwtsecret=/path/to/jwtsecretПерегляньте документацію для всіх параметрів конфігурації (opens in a new tab) та дізнайтеся більше про запуск Geth з клієнтом консенсусу (opens in a new tab).
Запуск Nethermind
Nethermind пропонує різні варіанти встановлення (opens in a new tab). Пакет містить різні двійкові файли, включно з програмою запуску з керованим налаштуванням, яка допоможе вам інтерактивно створити конфігурацію. Крім того, ви знайдете Runner, який є самим виконуваним файлом, і ви можете просто запустити його з прапорцями конфігурації. JSON-RPC увімкнено за замовчуванням.
1Nethermind.Runner --config mainnet \2 --datadir /data/ethereum \3 --JsonRpc.JwtSecretFile=/path/to/jwtsecretДокументація Nethermind пропонує повний посібник (opens in a new tab) із запуску Nethermind з клієнтом консенсусу.
Клієнт виконання ініціює свої основні функції, обрані кінцеві точки та почне шукати пірів. Після успішного виявлення однорангових партнерів клієнт починає синхронізацію. Клієнт виконання очікуватиме з'єднання від клієнта консенсусу. Поточні дані блокчейну будуть доступні після успішної синхронізації клієнта з поточним станом.
Запуск Reth
Цей приклад запускає Reth у мережі Mainnet, використовуючи розташування даних за замовчуванням. Вмикає автентифікацію JSON-RPC та Engine RPC для підключення клієнта консенсусу, що визначається шляхом до jwtsecret, при цьому дозволені лише виклики з localhost.
1reth node \2 --authrpc.jwtsecret /path/to/jwtsecret \3 --authrpc.addr 127.0.0.1 \4 --authrpc.port 8551Див. Налаштування Reth (opens in a new tab), щоб дізнатися більше про каталоги даних за замовчуванням. Документація Reth (opens in a new tab) містить додаткові опції та деталі конфігурації.
Запуск клієнта консенсусу
Клієнт консенсусу повинен бути запущений із правильною конфігурацією порту для встановлення локального з'єднання RPC з клієнтом виконання. Клієнти консенсусу повинні запускатися з відкритим портом клієнта виконання як аргумент конфігурації.
Клієнту консенсусу також потрібен шлях до jwt-secret клієнта виконання для автентифікації з'єднання RPC між ними. Подібно до наведених вище прикладів виконання, кожен клієнт консенсусу має прапорець конфігурації, який приймає шлях до файлу токена jwt як аргумент. Це має відповідати шляху jwtsecret, наданому клієнту виконання.
Якщо ви плануєте запустити валідатор, обов'язково додайте прапорець конфігурації, що вказує адресу Ethereum одержувача комісії. Саме тут накопичуються винагороди в етері для вашого валідатора. Кожен клієнт консенсусу має опцію, наприклад, --suggested-fee-recipient=0xabcd1, яка приймає адресу Ethereum як аргумент.
При запуску вузла Beacon у тестовій мережі ви можете значно заощадити час синхронізації, використовуючи загальнодоступну кінцеву точку для синхронізації за контрольними точками (opens in a new tab).
Запуск клієнта консенсусу
Запуск Lighthouse
Перш ніж запускати Lighthouse, дізнайтеся більше про те, як його встановити та налаштувати, у книзі Lighthouse (opens in a new tab).
1lighthouse beacon_node \2 --network mainnet \3 --datadir /data/ethereum \4 --http \5 --execution-endpoint http://127.0.0.1:8551 \6 --execution-jwt /path/to/jwtsecretЗапуск Lodestar
Встановіть програмне забезпечення Lodestar, скомпілювавши його або завантаживши образ Docker. Дізнайтеся більше в документації (opens in a new tab) та більш повному посібнику з налаштування (opens in a new tab).
1lodestar beacon \2 --dataDir="/data/ethereum" \3 --network=mainnet \4 --eth1.enabled=true \5 --execution.urls="http://127.0.0.1:8551" \6 --jwt-secret="/path/to/jwtsecret"Запуск Nimbus
Nimbus постачається з клієнтами як консенсусу, так і виконання. Його можна запускати на різних пристроях, навіть з дуже скромною обчислювальною потужністю. Після встановлення залежностей і самого Nimbus (opens in a new tab), ви можете запустити його клієнт консенсусу:
1nimbus_beacon_node \2 --network=mainnet \3 --web3-url=http://127.0.0.1:8551 \4 --rest \5 --jwt-secret="/path/to/jwtsecret"Запуск Prysm
Prysm постачається зі скриптом, який дозволяє легко автоматично встановити його. Деталі можна знайти в документації Prysm (opens in a new tab).
1./prysm.sh beacon-chain \2 --mainnet \3 --datadir /data/ethereum \4 --execution-endpoint=http://localhost:8551 \5 --jwt-secret=/path/to/jwtsecretЗапуск Teku
1teku --network mainnet \2 --data-path "/data/ethereum" \3 --ee-endpoint http://localhost:8551 \4 --ee-jwt-secret-file "/path/to/jwtsecret"Коли клієнт консенсусу підключається до клієнта виконання для читання депозитного контракту та ідентифікації валідаторів, він також підключається до інших пірів вузла Beacon і починає синхронізувати слоти консенсусу з генезису. Як тільки вузол Beacon досягне поточної епохи, API Beacon стане доступним для ваших валідаторів. Дізнайтеся більше про API вузла Beacon (opens in a new tab).
Додавання валідаторів
Клієнт консенсусу служить вузлом Beacon для підключення валідаторів. Кожен клієнт консенсусу має власне програмне забезпечення валідатора, докладно описане у відповідній документації.
Запуск власного валідатора дозволяє соло-стейкінг — найефективніший і найнадійніший метод підтримки мережі Ethereum. Однак це вимагає депозиту в 32 ETH. Щоб запустити валідатор на власному вузлі з меншою сумою, вас може зацікавити децентралізований пул з операторами вузлів без дозволу, наприклад, Rocket Pool (opens in a new tab).
Найпростіший спосіб розпочати стейкінг та генерацію ключів валідатора — це скористатися стартовою платформою для стейкінгу в тестовій мережі Hoodi (opens in a new tab), яка дозволяє протестувати ваше налаштування, запустивши вузли в мережі Hoodi (opens in a new tab). Коли ви будете готові до Mainnet, ви можете повторити ці кроки, використовуючи стартову платформу для стейкінгу в Mainnet (opens in a new tab).
Перегляньте сторінку про стейкінг, щоб отримати огляд варіантів стейкінгу.
Використання вузла
Клієнти виконання пропонують кінцеві точки RPC API, які ви можете використовувати для надсилання транзакцій, взаємодії з або розгортання смартконтрактів у мережі Ethereum різними способами:
- Вручну викликаючи їх за допомогою відповідного протоколу (наприклад, використовуючи
curl) - Підключення наданої консолі (наприклад,
geth attach) - Впровадження їх у застосунки за допомогою бібліотек web3, наприклад, web3.py (opens in a new tab), ethers (opens in a new tab)
Різні клієнти мають різні реалізації кінцевих точок RPC. Але існує стандартний JSON-RPC, який ви можете використовувати з кожним клієнтом. Для огляду прочитайте документацію JSON-RPC. Програми, яким потрібна інформація з мережі Ethereum, можуть використовувати цей RPC. Наприклад, популярний гаманець MetaMask дозволяє вам підключатися до власної кінцевої точки RPC (opens in a new tab), що має значні переваги для конфіденційності та безпеки.
Усі клієнти консенсусу надають Beacon API (opens in a new tab), який можна використовувати для перевірки стану клієнта консенсусу або завантаження блоків і даних консенсусу, надсилаючи запити за допомогою таких інструментів, як Curl (opens in a new tab). Більше інформації про це можна знайти в документації для кожного клієнта консенсусу.
Доступ до RPC
Порт за замовчуванням для JSON-RPC клієнта виконання — 8545, але ви можете змінити порти локальних кінцевих точок у конфігурації. За замовчуванням інтерфейс RPC доступний лише на локальному хості вашого комп’ютера. Щоб зробити його доступним віддалено, ви можете відкрити його для загального доступу, змінивши адресу на 0.0.0.0. Це зробить його доступним через локальну мережу та загальнодоступні IP-адреси. У більшості випадків потрібно буде налаштувати порт з перенаправленням на маршрутизатор.
Підходьте до відкриття портів для Інтернету з обережністю, оскільки це дозволить будь-кому в Інтернеті керувати вашим вузлом. Зловмисники можуть отримати доступ до вашого вузла, щоб атакувати вашу систему або вкрасти ваші кошти, якщо ви використовуєте клієнт як гаманець.
Способом обійти це є запобігання зміні потенційно шкідливих методів RPC. Наприклад, у Geth ви можете оголосити методи, що підлягають зміні, за допомогою прапорця: --http.api web3,eth,txpool.
Доступ до інтерфейсу RPC можна розширити шляхом розробки API граничного рівня або застосунків вебсервера, як-от Nginx, і підключення їх до локальної адреси та порту вашого клієнта. Використання проміжного рівня також може надати розробникам можливість налаштувати сертифікат для безпечних з'єднань https з інтерфейсом RPC.
Налаштування вебсервера, проксі або зовнішнього Rest API — це не єдиний спосіб надати доступ до кінцевої точки RPC вашого вузла. Ще один спосіб налаштувати загальнодоступну кінцеву точку, що зберігає конфіденційність, — це розмістити вузол у вашій власній службі-цибулині Tor (opens in a new tab). Це дозволить вам отримати доступ до RPC за межами вашої локальної мережі без статичної загальнодоступної IP-адреси або відкритих портів. Однак використання цієї конфігурації може дозволити доступ до кінцевої точки RPC лише через мережу Tor, яка підтримується не всіма застосунками та може призвести до проблем зі з’єднанням.
Для цього вам потрібно створити власну службу-цибулину (opens in a new tab). Ознайомтеся з документацією (opens in a new tab) щодо налаштування служби-цибулини, щоб розмістити власну. Ви можете спрямувати його на вебсервер із проксі до порту RPC або просто безпосередньо до RPC.
Нарешті, одним із найпопулярніших способів надання доступу до внутрішніх мереж є з'єднання через VPN. Залежно від вашого випадку використання та кількості користувачів, яким потрібен доступ до вашого вузла, безпечне з'єднання VPN може бути варіантом. OpenVPN (opens in a new tab) — це повнофункціональний SSL VPN, який реалізує безпечне розширення мережі на рівні 2 або 3 OSI з використанням стандартного протоколу SSL/TLS, підтримує гнучкі методи автентифікації клієнтів на основі сертифікатів, смарт-карт та/або облікових даних імені користувача/пароля, і дозволяє використовувати політики контролю доступу для конкретних користувачів або груп за допомогою правил брандмауера, застосованих до віртуального інтерфейсу VPN.
Експлуатація вузла
Ви повинні регулярно контролювати свій вузол, щоб переконатися, що він працює належним чином. Можливо, вам доведеться періодично проводити технічне обслуговування.
Підтримання вузла в мережі
Ваш вузол не повинен бути в мережі постійно, але ви повинні тримати його онлайн якомога довше, щоб він залишався синхронізованим з мережею. Ви можете вимкнути його для перезапуску, але пам’ятайте, що:
- Вимкнення може зайняти кілька хвилин, якщо останній стан все ще записується на диск.
- Примусове вимкнення може пошкодити базу даних, що вимагатиме повторної синхронізації всього вузла.
- Ваш клієнт не буде синхронізуватися з мережею, і його доведеться повторно синхронізувати, коли ви його перезавантажите. Хоча вузол може почати синхронізацію з місця останнього вимкнення, процес може зайняти час залежно від того, як довго він був офлайн.
Це не стосується вузлів-валідаторів рівня консенсусу. Вимкнення вашого вузла вплине на всі залежні від нього служби. Якщо ви запускаєте вузол для стейкінгу, ви повинні намагатися мінімізувати час простою якомога більше.
Створення служб клієнта
Розгляньте можливість створення служби для автоматичного запуску ваших клієнтів під час завантаження. Наприклад, на серверах Linux гарною практикою буде створення служби, наприклад, за допомогою systemd, яка виконує клієнт із належною конфігурацією під користувачем з обмеженими привілеями та автоматично перезапускається.
Оновлення клієнтів
Вам потрібно підтримувати ваше клієнтське програмне забезпечення в актуальному стані з останніми виправленнями безпеки, функціями та EIP. Особливо перед хардфорками переконайтеся, що ви використовуєте правильні версії клієнта.
Перед важливими оновленнями мережі EF публікує допис у своєму блозі (opens in a new tab). Ви можете підписатися на ці оголошення (opens in a new tab), щоб отримувати сповіщення на свою пошту, коли ваш вузол потребує оновлення.
Оновлення клієнтів дуже просте. Кожен клієнт має конкретні інструкції у своїй документації, але процес, як правило, полягає лише в тому, щоб завантажити останню версію та перезапустити клієнт з новим виконуваним файлом. Клієнт повинен продовжити роботу з того місця, де зупинився, але із застосованими оновленнями.
Кожна реалізація клієнта має читабельний рядок версії, який використовується в протоколі peer-to-peer, але також доступний з командного рядка. Цей рядок версії дозволяє користувачам перевіряти, чи працює коректно версія, а також дозволяє перевіряти це дослідникам блоків та іншим аналітичним інструментам, зацікавленим у кількісній оцінці розподілу конкретних клієнтів у мережі. Будь ласка, зверніться до документації цього клієнта для отримання додаткової інформації про рядки версій.
Запуск додаткових служб
Запуск власного вузла дозволяє використовувати послуги, які потребують прямого доступу до клієнта Ethereum RCP. Це служби, побудовані на основі Ethereum, як-от рішення рівня 2, бекенд для гаманців, оглядачі блоків, інструменти для розробників та інша інфраструктура Ethereum.
Моніторинг вузла
Щоб належним чином контролювати свій вузол, подумайте про збір показників. Клієнти надають кінцеві точки метрики, щоб ви могли отримати всебічні дані про свій вузол. Використовуйте такі інструменти, як InfluxDB (opens in a new tab) або Prometheus (opens in a new tab), щоб створювати бази даних, які ви можете перетворити на візуалізації та діаграми в програмному забезпеченні, як-от Grafana (opens in a new tab). Існує багато конфігурацій для використання цього програмного забезпечення та різних панелей Grafana для візуалізації вашого вузла та мережі в цілому. Наприклад, перегляньте посібник з моніторингу Geth.
У рамках моніторингу не забудьте слідкувати за продуктивністю ваших машин. Під час первинної синхронізації вашого вузла клієнтське програмне забезпечення може сильно завантажувати ЦП та оперативну пам’ять. На додаток до Grafana, ви можете використовувати інструменти, які пропонує ваша ОС, як-от htop або uptime, щоб зробити це.
Для подальшого читання
- Посібники зі стейкінгу Ethereum (opens in a new tab) - Сомер Есат, часто оновлюється
- Посібник | Як налаштувати валідатор для стейкінгу Ethereum в основній мережі (opens in a new tab) – CoinCashew, часто оновлюється
- Посібники ETHStaker із запуску валідаторів у тестових мережах (opens in a new tab) – ETHStaker, регулярно оновлюється
- Приклад застосунку AWS Blockchain Node Runner для вузлів Ethereum (opens in a new tab) - AWS, часто оновлюється
- Поширені запитання про The Merge для операторів вузлів (opens in a new tab) - липень 2022 р.
- Аналіз апаратних вимог для того, щоб бути повним валідованим вузлом Ethereum (opens in a new tab) – Альберт Палау, 24 вересня 2018 р.
- Запуск повних вузлів Ethereum: посібник для ледь мотивованих (opens in a new tab) – Justin Leroux, 7 листопада 2019 р.
- Розгортання вузла Hyperledger Besu в основній мережі Ethereum: переваги, вимоги та налаштування (opens in a new tab) – Феліпе Фараггі, 7 травня 2020 р.
- Розгортання клієнта Nethermind Ethereum зі стеком моніторингу (opens in a new tab) – Nethermind.eth, 8 липня 2020 р.
