---
title: Запустите свой собственный узел Эфириума
description: Общее введение в запуск собственного экземпляра клиента Эфириума.
lang: ru
sidebarDepth: 2
---

Запуск собственного узла дает вам различные преимущества, открывает новые возможности и помогает поддерживать экосистему. Эта страница поможет вам запустить собственный узел и принять участие в проверке транзакций [Эфириума](/).

Обратите внимание, что после [Слияния](/roadmap/merge) для запуска узла Эфириума требуются два клиента: клиент **уровня исполнения (EL)** и клиент **уровня консенсуса (CL)**. На этой странице будет показано, как установить, настроить и подключить эти два клиента для запуска узла Эфириума.

## Предварительные требования {#prerequisites}

Вы должны понимать, что такое узел Эфириума и зачем вам может понадобиться запускать клиент. Это описано в разделе [Узлы и клиенты](/developers/docs/nodes-and-clients/).

Если вы новичок в теме запуска узла или ищете менее технический путь, мы рекомендуем сначала ознакомиться с нашим удобным для пользователя введением в [запуск узла Эфириума](/run-a-node).

## Выбор подхода {#choosing-approach}

Первым шагом в запуске вашего узла является выбор подхода. Основываясь на требованиях и различных возможностях, вы должны выбрать реализацию клиента (как клиента исполнения, так и клиента консенсуса), среду (оборудование, система) и параметры для настроек клиента.

Эта страница проведет вас через эти решения и поможет найти наиболее подходящий способ запуска вашего экземпляра Эфириума.

Чтобы выбрать из реализаций клиентов, просмотрите все доступные готовые к работе в Мейннете [клиенты исполнения](/developers/docs/nodes-and-clients/#execution-clients), [клиенты консенсуса](/developers/docs/nodes-and-clients/#consensus-clients) и узнайте о [разнообразии клиентов](/developers/docs/nodes-and-clients/client-diversity).

Решите, запускать ли программное обеспечение на собственном [оборудовании или в облаке](#local-vs-cloud), учитывая [требования](#requirements) клиентов.

После подготовки среды установите выбранные клиенты либо с помощью [интерфейса для начинающих](#automatized-setup), либо [вручную](#manual-setup) с использованием терминала с расширенными параметрами.

Когда узел запущен и синхронизируется, вы готовы [использовать его](#using-the-node), но не забывайте следить за его [обслуживанием](#operating-the-node).

![Настройка клиента](./diagram.png)

### Среда и оборудование {#environment-and-hardware}

#### Локально или в облаке {#local-vs-cloud}

Клиенты Эфириума могут работать на компьютерах потребительского класса и не требуют специального оборудования, например, машин для майнинга. Поэтому у вас есть различные варианты развертывания узла в зависимости от ваших потребностей.
Для простоты давайте рассмотрим запуск узла как на локальной физической машине, так и на облачном сервере:

- Облако
  - Провайдеры предлагают высокое время безотказной работы серверов и статические публичные IP-адреса
  - Аренда выделенного или виртуального сервера может быть удобнее, чем сборка собственного
  - Компромисс заключается в доверии третьей стороне — провайдеру сервера
  - Из-за требуемого объема хранилища для полного узла цена арендованного сервера может быть высокой
- Собственное оборудование
  - Более суверенный и не требующий доверия подход
  - Единовременная инвестиция
  - Возможность купить предварительно настроенные машины
  - Вам придется физически подготовить, обслуживать и, возможно, устранять неполадки машины и сети

Оба варианта имеют различные преимущества, обобщенные выше. Если вы ищете облачное решение, в дополнение ко многим традиционным провайдерам облачных вычислений существуют также сервисы, ориентированные на развертывание узлов. Ознакомьтесь с [узлами как услугой](/developers/docs/nodes-and-clients/nodes-as-a-service/) для получения дополнительных вариантов размещенных узлов.

#### Оборудование {#hardware}

Однако устойчивая к цензуре децентрализованная сеть не должна полагаться на облачных провайдеров. Вместо этого запуск вашего узла на собственном локальном оборудовании полезнее для экосистемы. [Оценки](https://www.ethernodes.org/networkType/cl/Hosting) показывают, что большая часть узлов работает в облаке, что может стать единой точкой отказа.

Клиенты Эфириума могут работать на вашем компьютере, ноутбуке, сервере или даже на одноплатном компьютере. Хотя запуск клиентов на вашем персональном компьютере возможен, наличие выделенной машины только для вашего узла может значительно повысить его производительность и безопасность, сводя к минимуму влияние на ваш основной компьютер.

Использовать собственное оборудование может быть очень просто. Существует множество простых вариантов, а также расширенных настроек для более технически подкованных людей. Итак, давайте рассмотрим требования и средства для запуска клиентов Эфириума на вашей машине.

#### Требования {#requirements}

Требования к оборудованию различаются в зависимости от клиента, но, как правило, они не так высоки, поскольку узлу просто нужно оставаться синхронизированным. Не путайте это с майнингом, который требует гораздо большей вычислительной мощности. Однако время синхронизации и производительность улучшаются при использовании более мощного оборудования.

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

Узким местом для вашего оборудования в основном является дисковое пространство. Синхронизация Блокчейна Эфириума очень интенсивно использует ввод/вывод и требует много места. Лучше всего иметь **твердотельный накопитель (SSD)** с сотнями гигабайт свободного места в запасе даже после синхронизации.

Размер базы данных и скорость начальной синхронизации зависят от выбранного клиента, его конфигурации и [стратегии синхронизации](/developers/docs/nodes-and-clients/#sync-modes).

Также убедитесь, что ваше интернет-соединение не ограничено [лимитом пропускной способности](https://wikipedia.org/wiki/Data_cap). Рекомендуется использовать безлимитное соединение, так как начальная синхронизация и данные, транслируемые в сеть, могут превысить ваш лимит.

##### Операционная система

Все клиенты поддерживают основные операционные системы — Linux, macOS, Windows. Это означает, что вы можете запускать узлы на обычных настольных или серверных машинах с операционной системой (ОС), которая вам больше всего подходит. Убедитесь, что ваша ОС обновлена, чтобы избежать потенциальных проблем и уязвимостей безопасности.

##### Минимальные требования

- Процессор с 2+ ядрами
- 16 ГБ ОЗУ (32 ГБ рекомендуется для стабильности)
- 2 ТБ NVMe SSD (вероятно, будет превышено к 2027 году, подробнее читайте в статье [Отличные и не очень SSD для узлов Эфириума](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038))
- Пропускная способность 25+ Мбит/с

##### Рекомендуемые характеристики

Текущие рекомендации по оборудованию для операторов узлов определены в [EIP-7870](https://eips.ethereum.org/EIPS/eip-7870). Для полного узла рекомендуется:

- Быстрый процессор с 4+ ядрами (8+ ядер при валидации)
- 32 ГБ ОЗУ (64 ГБ рекомендуется при валидации для обеспечения стабильности)
- 4 ТБ NVMe SSD (накопители без DRAM и QLC не рекомендуются)
- Пропускная способность 50 Мбит/с на скачивание / 15+ Мбит/с на загрузку (25+ Мбит/с на загрузку при валидации)

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

| Клиент     | Размер диска (snap-синхронизация) | Размер диска (полный архив) |
| ---------- | --------------------- | ------------------------ |
| Бесу       | 800 ГБ+                | 12 ТБ+                    |
| Эригон     | Н/Д                   | 2,5 ТБ+                   |
| Geth       | 500 ГБ+                | 12 ТБ+                    |
| Незермайнд | 500 ГБ+                | 12 ТБ+                    |
| Рет        | Н/Д                   | 2,2 ТБ+                   |

- Примечание: Эригон и Рет не предлагают snap-синхронизацию, но возможна полная обрезка (Full Pruning) (~2 ТБ для Эригона, ~1,2 ТБ для Рета)

Для клиентов консенсуса требования к пространству также зависят от реализации клиента и включенных функций (например, слэшера валидатора), но в целом рассчитывайте еще на 200 ГБ, необходимых для данных сигнального узла. При большом количестве валидаторов возрастает и нагрузка на пропускную способность. Вы можете найти [подробности о требованиях к клиентам консенсуса в этом анализе](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc).

#### Решения Plug-and-play {#plug-and-play}

Самый простой вариант запуска узла на собственном оборудовании — использование готовых решений (plug-and-play). Предварительно настроенные машины от поставщиков предлагают самый простой опыт: заказал, подключил, запустил. Все предварительно настроено и работает автоматически с интуитивно понятным руководством и панелью управления для мониторинга и контроля программного обеспечения.

- [DAppNode](https://dappnode.io/)
- [Avado](https://ava.do/)

#### Эфириум на одноплатном компьютере {#ethereum-on-a-single-board-computer}

Простой и дешевый способ запуска узла Эфириума — использовать одноплатный компьютер, даже с архитектурой ARM, такой как Raspberry Pi. [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) предоставляет простые в запуске образы нескольких клиентов исполнения и консенсуса для Raspberry Pi и других плат ARM.

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

## Запуск узла {#spinning-up-node}

Фактическая настройка клиента может быть выполнена либо с помощью автоматизированных лаунчеров, либо вручную, путем прямой настройки клиентского программного обеспечения.

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

### Управляемая настройка {#automatized-setup}

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

Ниже приведены несколько проектов, которые могут помочь вам установить и управлять клиентами всего в несколько кликов:

- [DAppNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) — DAppNode поставляется не только с машиной от поставщика. Программное обеспечение, сам лаунчер узла и центр управления со множеством функций могут использоваться на произвольном оборудовании.
- [EthPillar](https://www.coincashew.com/coins/overview-eth/ethpillar) — Самый быстрый и простой способ настроить полный узел. Инструмент настройки в одну строку и TUI для управления узлом. Бесплатно. Открытый исходный код. Общественные блага для Эфириума от соло-стейкеров. Поддержка ARM64 и AMD64.
- [eth-docker](https://eth-docker.net/) — Автоматизированная настройка с использованием Docker, ориентированная на простой и безопасный стейкинг, требует базовых знаний терминала и Docker, рекомендуется для чуть более продвинутых пользователей.
- [Stereum](https://stereum-dev.github.io/ethereum-node-web-docs) — Лаунчер для установки клиентов на удаленный сервер через SSH-соединение с руководством по настройке с графическим интерфейсом, центром управления и множеством других функций.
- [Sedge](https://docs.sedge.nethermind.io/docs/intro) — Инструмент настройки узла, который автоматически генерирует конфигурацию Docker с помощью мастера CLI. Написан на Go командой Незермайнд.
- [Chainstack Self-Hosted](https://docs.chainstack.com/docs/self-hosted/introduction) — Веб-интерфейс и CLI для развертывания клиентов исполнения и консенсуса в Kubernetes. Включает загрузку снимков (snapshot bootstrap) и встроенный мониторинг. Бесплатно. Учетная запись Chainstack не требуется. Создано Chainstack.

### Ручная настройка клиентов {#manual-setup}

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

Как объяснялось ранее, настройка собственного узла Эфириума потребует запуска пары клиентов консенсуса и исполнения. Некоторые клиенты могут включать легкий клиент другого типа и синхронизироваться без необходимости в каком-либо другом программном обеспечении. Однако полная проверка, не требующая доверия, требует обеих реализаций.

#### Получение клиентского программного обеспечения {#getting-the-client}

Сначала вам нужно получить предпочитаемое программное обеспечение [клиента исполнения](/developers/docs/nodes-and-clients/#execution-clients) и [клиента консенсуса](/developers/docs/nodes-and-clients/#consensus-clients).

Вы можете просто загрузить исполняемое приложение или установочный пакет, который подходит для вашей операционной системы и архитектуры. Всегда проверяйте подписи и контрольные суммы загруженных пакетов. Некоторые клиенты также предлагают репозитории или образы Docker для более простой установки и обновлений. Все клиенты имеют открытый исходный код, поэтому вы также можете собрать их из исходного кода. Это более продвинутый метод, но в некоторых случаях он может потребоваться.

Инструкции по установке каждого клиента приведены в документации, ссылки на которую есть в списках клиентов выше.

Вот страницы релизов клиентов, где вы можете найти их предварительно скомпилированные бинарные файлы или инструкции по установке:

##### Клиенты исполнения

- [Бесу](https://github.com/hyperledger/besu/releases)
- [Эригон](https://github.com/ledgerwatch/erigon/releases)
- [Geth](https://geth.ethereum.org/downloads)
- [Незермайнд](https://downloads.nethermind.io/)
- [Рет](https://reth.rs/installation/installation.html)

Также стоит отметить, что разнообразие клиентов является [проблемой на уровне исполнения](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). Читателям рекомендуется рассмотреть возможность запуска клиента исполнения, находящегося в меньшинстве.

##### Клиенты консенсуса

- [Лайтхаус](https://github.com/sigp/lighthouse/releases/latest)
- [Лодстар](https://chainsafe.github.io/lodestar/run/getting-started/installation#build-from-source/) (Не предоставляет предварительно скомпилированный бинарный файл, только образ Docker или сборку из исходного кода)
- [Нимбус](https://github.com/status-im/nimbus-eth2/releases/latest)
- [Призм](https://github.com/prysmaticlabs/prysm/releases/latest)
- [Теку](https://github.com/ConsenSys/teku/releases)

[Разнообразие клиентов](/developers/docs/nodes-and-clients/client-diversity/) имеет решающее значение для узлов консенсуса, запускающих валидаторы. Если большинство валидаторов используют одну реализацию клиента, безопасность сети находится под угрозой. Поэтому рекомендуется рассмотреть возможность выбора клиента, находящегося в меньшинстве.

[Посмотрите последнее использование клиентов в сети](https://clientdiversity.org/) и узнайте больше о [разнообразии клиентов](/developers/docs/nodes-and-clients/client-diversity).

##### Проверка программного обеспечения

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

Разработчики подписывают выпущенные бинарные файлы своими ключами PGP, чтобы вы могли криптографически проверить, что запускаете именно то программное обеспечение, которое они создали. Вам просто нужно получить открытые ключи, используемые разработчиками, которые можно найти на страницах релизов клиентов или в документации. После загрузки релиза клиента и его подписи вы можете использовать реализацию PGP, например, [GnuPG](https://gnupg.org/download/index.html), чтобы легко их проверить. Ознакомьтесь с руководством по проверке программного обеспечения с открытым исходным кодом с использованием `gpg` в [Linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) или [Windows/macOS](https://freedom.press/training/verifying-open-source-software/).

Другая форма проверки — убедиться, что хеш, уникальный криптографический отпечаток загруженного вами программного обеспечения, совпадает с тем, который предоставили разработчики. Это даже проще, чем использование PGP, и некоторые клиенты предлагают только этот вариант. Просто запустите хеш-функцию для загруженного программного обеспечения и сравните ее с той, что указана на странице релиза. Например:

```sh
sha256sum teku-22.6.1.tar.gz

9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde
```

#### Настройка клиента {#client-setup}

После установки, загрузки или компиляции клиентского программного обеспечения вы готовы к его запуску. Это означает лишь то, что оно должно быть выполнено с правильной конфигурацией. Клиенты предлагают богатые возможности настройки, которые могут включать различные функции.

Давайте начнем с параметров, которые могут существенно повлиять на производительность клиента и использование данных. [Режимы синхронизации](/developers/docs/nodes-and-clients/#sync-modes) представляют собой различные методы загрузки и проверки данных блокчейна. Перед запуском узла вы должны решить, какую сеть и режим синхронизации использовать. Самое важное, что нужно учитывать, — это дисковое пространство и время синхронизации, которые потребуются клиенту. Обратите внимание на документацию клиента, чтобы определить, какой режим синхронизации используется по умолчанию. Если он вам не подходит, выберите другой, исходя из уровня безопасности, доступных данных и стоимости. Помимо алгоритма синхронизации, вы также можете настроить обрезку (pruning) различных видов старых данных. Обрезка позволяет удалять устаревшие данные, т. е. удалять узлы дерева состояний, которые недоступны из последних блоков.

Другие базовые параметры конфигурации — это, например, выбор сети (Мейннет или тестовые сети), включение конечной точки HTTP для RPC или WebSockets и т. д. Вы можете найти все функции и параметры в документации клиента. Различные конфигурации клиента могут быть установлены путем выполнения клиента с соответствующими флагами непосредственно в CLI или файле конфигурации. Каждый клиент немного отличается; пожалуйста, всегда обращайтесь к его официальной документации или странице справки для получения подробной информации о параметрах конфигурации.

В целях тестирования вы можете предпочесть запустить клиент в одной из тестовых сетей. [Смотрите обзор поддерживаемых сетей](/developers/docs/nodes-and-clients/#execution-clients).

Примеры запуска клиентов исполнения с базовой конфигурацией можно найти в следующем разделе.

#### Запуск клиента исполнения {#starting-the-execution-client}

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

- Достаточно дискового пространства с учетом выбранной сети и режима синхронизации.
- Память и процессор не перегружены другими программами.
- Операционная система обновлена до последней версии.
- В системе установлены правильные время и дата.
- Ваш маршрутизатор и брандмауэр принимают соединения на прослушиваемых портах. По умолчанию клиенты Эфириума используют порт прослушивания (TCP) и порт обнаружения (UDP), оба по умолчанию на 30303.

Сначала запустите свой клиент в тестовой сети, чтобы убедиться, что все работает правильно.

Вам нужно объявить любые настройки клиента, которые не являются настройками по умолчанию при запуске. Вы можете использовать флаги или файл конфигурации, чтобы объявить предпочитаемую конфигурацию. Набор функций и синтаксис конфигурации каждого клиента отличаются. Ознакомьтесь с документацией вашего клиента для получения подробной информации.

Клиенты исполнения и консенсуса обмениваются данными через аутентифицированную конечную точку, указанную в [Engine API](https://github.com/ethereum/execution-apis/tree/main/src/engine). Чтобы подключиться к клиенту консенсуса, клиент исполнения должен сгенерировать [`jwtsecret`](https://jwt.io/) по известному пути. Из соображений безопасности и стабильности клиенты должны работать на одной машине, и оба клиента должны знать этот путь, так как он используется для аутентификации локального RPC-соединения между ними. Клиент исполнения также должен определить порт прослушивания для аутентифицированных API.

Этот токен генерируется автоматически клиентским программным обеспечением, но в некоторых случаях вам может потребоваться сделать это самостоятельно. Вы можете сгенерировать его с помощью [OpenSSL](https://www.openssl.org/):

```sh
openssl rand -hex 32 > jwtsecret
```

#### Запуск клиента исполнения {#running-an-execution-client}

В этом разделе рассказывается о запуске клиентов исполнения. Он служит лишь примером базовой конфигурации, которая запустит клиент со следующими настройками:

- Указывает сеть для подключения, в наших примерах это Мейннет
  - Вместо этого вы можете выбрать [одну из тестовых сетей](/developers/docs/networks/) для предварительного тестирования вашей настройки
- Определяет каталог данных, где будут храниться все данные, включая блокчейн
  - Обязательно замените путь на реальный, например, указывающий на ваш внешний диск
- Включает интерфейсы для связи с клиентом
  - Включая JSON-RPC и Engine API для связи с клиентом консенсуса
- Определяет путь к `jwtsecret` для аутентифицированного API
  - Обязательно замените пример пути на реальный, к которому могут получить доступ клиенты, например, `/tmp/jwtsecret`

Пожалуйста, имейте в виду, что это всего лишь базовый пример, все остальные настройки будут установлены по умолчанию. Обратите внимание на документацию каждого клиента, чтобы узнать о значениях по умолчанию, настройках и функциях. Для получения дополнительных функций, например, для запуска валидаторов, мониторинга и т. д., пожалуйста, обратитесь к документации конкретного клиента.

> Обратите внимание, что обратные косые черты `\` в примерах предназначены только для форматирования; флаги конфигурации могут быть определены в одну строку.

##### Запуск Бесу

Этот пример запускает Бесу в Мейннете, сохраняет данные блокчейна в формате по умолчанию в `/data/ethereum`, включает JSON-RPC и Engine RPC для подключения клиента консенсуса. Engine API аутентифицируется с помощью токена `jwtsecret`, и разрешены только вызовы с `localhost`.

```sh
besu --network=mainnet \
    --data-path=/data/ethereum \
    --rpc-http-enabled=true \
    --engine-rpc-enabled=true \
    --engine-host-allowlist="*" \
    --engine-jwt-enabled=true \
    --engine-jwt-secret=/path/to/jwtsecret
```

Бесу также поставляется с опцией лаунчера, который задаст ряд вопросов и сгенерирует файл конфигурации. Запустите интерактивный лаунчер с помощью:

```sh
besu --Xlauncher
```

[Документация Бесу](https://besu.hyperledger.org/public-networks/get-started/start-node/) содержит дополнительные параметры и сведения о конфигурации.

##### Запуск Эригона

Этот пример запускает Эригон в Мейннете, сохраняет данные блокчейна в `/data/ethereum`, включает JSON-RPC, определяет, какие пространства имен разрешены, и включает аутентификацию для подключения клиента консенсуса, который определяется путем `jwtsecret`.

```sh
erigon --chain mainnet \
    --datadir /data/ethereum  \
    --http --http.api=engine,eth,web3,net \
    --authrpc.jwtsecret=/path/to/jwtsecret
```

Эригон по умолчанию выполняет полную синхронизацию с 8 ГБ HDD, что приведет к более чем 2 ТБ архивных данных. Убедитесь, что `datadir` указывает на диск с достаточным количеством свободного места, или обратите внимание на флаг `--prune`, который может обрезать различные виды данных. Ознакомьтесь с `--help` Эригона, чтобы узнать больше.

##### Запуск Geth

Этот пример запускает Geth в Мейннете, сохраняет данные блокчейна в `/data/ethereum`, включает JSON-RPC и определяет, какие пространства имен разрешены. Он также включает аутентификацию для подключения клиента консенсуса, для чего требуется путь к `jwtsecret`, а также параметр, определяющий, какие подключения разрешены, в нашем примере только с `localhost`.

```sh
geth --mainnet \
    --datadir "/data/ethereum" \
    --http --authrpc.addr localhost \
    --authrpc.vhosts="localhost" \
    --authrpc.port 8551
    --authrpc.jwtsecret=/path/to/jwtsecret
```

Ознакомьтесь с [документацией по всем параметрам конфигурации](https://geth.ethereum.org/docs/fundamentals/command-line-options) и узнайте больше о [запуске Geth с клиентом консенсуса](https://geth.ethereum.org/docs/getting-started/consensus-clients).

##### Запуск Незермайнда

Незермайнд предлагает различные [варианты установки](https://docs.nethermind.io/get-started/installing-nethermind). Пакет поставляется с различными бинарными файлами, включая лаунчер с управляемой настройкой, который поможет вам создать конфигурацию в интерактивном режиме. В качестве альтернативы вы найдете Runner, который является самим исполняемым файлом, и вы можете просто запустить его с флагами конфигурации. JSON-RPC включен по умолчанию.

```sh
Nethermind.Runner --config mainnet \
    --datadir /data/ethereum \
    --JsonRpc.JwtSecretFile=/path/to/jwtsecret
```

Документация Незермайнда предлагает [полное руководство](https://docs.nethermind.io/get-started/running-node/) по запуску Незермайнда с клиентом консенсуса.

Клиент исполнения инициирует свои основные функции, выбранные конечные точки и начнет поиск пиров. После успешного обнаружения пиров клиент начинает синхронизацию. Клиент исполнения будет ожидать подключения от клиента консенсуса. Текущие данные блокчейна будут доступны после успешной синхронизации клиента с текущим состоянием.

##### Запуск Рета

Этот пример запускает Рет в Мейннете, используя расположение данных по умолчанию. Включает аутентификацию JSON-RPC и Engine RPC для подключения клиента консенсуса, который определяется путем `jwtsecret`, при этом разрешены только вызовы с `localhost`.

```sh
reth node \
    --authrpc.jwtsecret /path/to/jwtsecret \
    --authrpc.addr 127.0.0.1 \
    --authrpc.port 8551
```

Смотрите [Настройка Рета](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth), чтобы узнать больше о каталогах данных по умолчанию. [Документация Рета](https://reth.rs/run/mainnet.html) содержит дополнительные параметры и сведения о конфигурации.

#### Запуск клиента консенсуса {#starting-the-consensus-client}

Клиент консенсуса должен быть запущен с правильной конфигурацией портов для установления локального RPC-соединения с клиентом исполнения. Клиенты консенсуса должны запускаться с открытым портом клиента исполнения в качестве аргумента конфигурации.

Клиенту консенсуса также нужен путь к `jwt-secret` клиента исполнения для аутентификации RPC-соединения между ними. Подобно примерам исполнения выше, каждый клиент консенсуса имеет флаг конфигурации, который принимает путь к файлу jwt-токена в качестве аргумента. Это должно соответствовать пути `jwtsecret`, предоставленному клиенту исполнения.

Если вы планируете запустить валидатор, обязательно добавьте флаг конфигурации, указывающий адрес Эфириума получателя комиссии. Именно здесь накапливаются вознаграждения в эфире для вашего валидатора. У каждого клиента консенсуса есть опция, например, `--suggested-fee-recipient=0xabcd1`, которая принимает адрес Эфириума в качестве аргумента.

При запуске сигнального узла в тестовой сети вы можете значительно сэкономить время синхронизации, используя публичную конечную точку для [синхронизации контрольной точки](https://notes.ethereum.org/@launchpad/checkpoint-sync).

#### Запуск клиента консенсуса {#running-a-consensus-client}

##### Запуск Лайтхауса

Перед запуском Лайтхауса узнайте больше о том, как его установить и настроить, в [Lighthouse Book](https://lighthouse-book.sigmaprime.io/installation.html).

```sh
lighthouse beacon_node \
    --network mainnet \
    --datadir /data/ethereum \
    --http \
    --execution-endpoint http://127.0.0.1:8551 \
    --execution-jwt /path/to/jwtsecret
```

##### Запуск Лодстара

Установите программное обеспечение Лодстар, скомпилировав его или загрузив образ Docker. Узнайте больше в [документации](https://chainsafe.github.io/lodestar/) и более подробном [руководстве по настройке](https://hackmd.io/@philknows/rk5cDvKmK).

```sh
lodestar beacon \
    --dataDir="/data/ethereum" \
    --network=mainnet \
    --eth1.enabled=true \
    --execution.urls="http://127.0.0.1:8551" \
    --jwt-secret="/path/to/jwtsecret"
```

##### Запуск Нимбуса

Нимбус поставляется как с клиентом консенсуса, так и с клиентом исполнения. Его можно запускать на различных устройствах даже с очень скромной вычислительной мощностью.
После [установки зависимостей и самого Нимбуса](https://nimbus.guide/quick-start.html) вы можете запустить его клиент консенсуса:

```sh
nimbus_beacon_node \
    --network=mainnet \
    --web3-url=http://127.0.0.1:8551 \
    --rest \
    --jwt-secret="/path/to/jwtsecret"
```

##### Запуск Призма

Призм поставляется со скриптом, который обеспечивает простую автоматическую установку. Подробности можно найти в [документации Призма](https://prysm.offchainlabs.com/docs/install-prysm/install-with-script/).

```sh
./prysm.sh beacon-chain \
    --mainnet \
    --datadir /data/ethereum  \
    --execution-endpoint=http://localhost:8551  \
    --jwt-secret=/path/to/jwtsecret
```

##### Запуск Теку

```sh
teku --network mainnet \
    --data-path "/data/ethereum" \
    --ee-endpoint http://localhost:8551 \
    --ee-jwt-secret-file "/path/to/jwtsecret"
```

Когда клиент консенсуса подключается к клиенту исполнения для чтения депозитного контракта и идентификации валидаторов, он также подключается к другим пирам сигнального узла и начинает синхронизацию слотов консенсуса с генезиса. Как только сигнальный узел достигает текущей эпохи, Beacon API становится доступным для ваших валидаторов. Узнайте больше об [API сигнального узла](https://ethereum.github.io/beacon-APIs).

### Добавление валидаторов {#adding-validators}

Клиент консенсуса служит сигнальным узлом для подключения валидаторов. У каждого клиента консенсуса есть собственное программное обеспечение валидатора, подробно описанное в соответствующей документации.

Запуск собственного валидатора позволяет осуществлять [соло-стейкинг](/staking/solo/) — наиболее эффективный и не требующий доверия метод поддержки сети Эфириума. Однако для этого требуется депозит в размере 32 ETH. Чтобы запустить валидатор на собственном узле с меньшей суммой, вас может заинтересовать децентрализованный пул с общедоступными операторами узлов, такой как [Rocket Pool](https://rocketpool.net/node-operators).

Самый простой способ начать работу со стейкингом и генерацией ключей валидатора — использовать [Hoodi Testnet Staking Launchpad](https://hoodi.launchpad.ethereum.org/), который позволяет протестировать вашу настройку путем [запуска узлов в Hoodi](https://notes.ethereum.org/@launchpad/hoodi). Когда вы будете готовы к Мейннету, вы можете повторить эти шаги, используя [Mainnet Staking Launchpad](https://launchpad.ethereum.org/).

Загляните на [страницу стейкинга](/staking) для обзора вариантов стейкинга.

### Использование узла {#using-the-node}

Клиенты исполнения предлагают [конечные точки RPC API](/developers/docs/apis/json-rpc/), которые вы можете использовать для отправки транзакций, взаимодействия со смарт-контрактами или их развертывания в сети Эфириума различными способами:

- Вызывая их вручную с помощью подходящего протокола (например, используя `curl`)
- Подключая предоставленную консоль (например, `geth attach`)
- Реализуя их в приложениях с использованием библиотек Web3, например, [Web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/)

Разные клиенты имеют разные реализации конечных точек RPC. Но существует стандартный JSON-RPC, который вы можете использовать с каждым клиентом. Для обзора [прочитайте документацию по JSON-RPC](/developers/docs/apis/json-rpc/). Приложения, которым нужна информация из сети Эфириума, могут использовать этот RPC. Например, популярный Кошелек МетаМаск позволяет вам [подключиться к вашей собственной конечной точке RPC](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), что дает значительные преимущества в плане приватности и безопасности.

Все клиенты консенсуса предоставляют [Beacon API](https://ethereum.github.io/beacon-APIs), который можно использовать для проверки статуса клиента консенсуса или загрузки блоков и данных консенсуса путем отправки запросов с использованием таких инструментов, как [Curl](https://curl.se). Дополнительную информацию об этом можно найти в документации для каждого клиента консенсуса.

#### Доступ к RPC {#reaching-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 вашего узла. Другой способ настройки публично доступной конечной точки с сохранением приватности — разместить узел на собственном onion-сервисе [Tor](https://www.torproject.org/). Это позволит вам получить доступ к RPC за пределами вашей локальной сети без статического публичного IP-адреса или открытых портов. Однако использование этой конфигурации может позволить доступ к конечной точке RPC только через сеть Tor, которая поддерживается не всеми приложениями и может привести к проблемам с подключением.

Для этого вам нужно создать свой собственный [onion-сервис](https://community.torproject.org/onion-services/). Ознакомьтесь с [документацией](https://community.torproject.org/onion-services/setup/) по настройке onion-сервиса, чтобы разместить свой собственный. Вы можете направить его на веб-сервер с прокси-сервером к порту RPC или просто напрямую к RPC.

Наконец, один из самых популярных способов предоставления доступа к внутренним сетям — через VPN-соединение. В зависимости от вашего варианта использования и количества пользователей, которым нужен доступ к вашему узлу, безопасное VPN-соединение может быть хорошим вариантом. [OpenVPN](https://openvpn.net/) — это полнофункциональный SSL VPN, который реализует безопасное расширение сети уровня 2 или 3 OSI с использованием стандартного отраслевого протокола SSL/TLS, поддерживает гибкие методы аутентификации клиентов на основе сертификатов, смарт-карт и/или учетных данных (имя пользователя/пароль) и позволяет применять политики управления доступом для конкретных пользователей или групп с использованием правил брандмауэра, применяемых к виртуальному интерфейсу VPN.

### Эксплуатация узла {#operating-the-node}

Вы должны регулярно контролировать свой узел, чтобы убедиться, что он работает правильно. Вам может потребоваться периодическое обслуживание.

#### Поддержание узла в сети {#keeping-node-online}

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

- Выключение может занять несколько минут, если недавнее состояние все еще записывается на диск.
- Принудительное выключение может повредить базу данных, что потребует повторной синхронизации всего узла.
- Ваш клиент рассинхронизируется с сетью и потребует повторной синхронизации при перезапуске. Хотя узел может начать синхронизацию с того места, где он был в последний раз выключен, этот процесс может занять время в зависимости от того, как долго он был в автономном режиме.

_Это не относится к узлам валидаторов уровня консенсуса._ Отключение вашего узла повлияет на все зависящие от него сервисы. Если вы запускаете узел для целей _стейкинга_, вам следует постараться свести время простоя к минимуму.

#### Создание клиентских сервисов {#creating-client-services}

Рассмотрите возможность создания сервиса для автоматического запуска ваших клиентов при запуске системы. Например, на серверах Linux хорошей практикой будет создание сервиса, например, с помощью `systemd`, который выполняет клиент с правильной конфигурацией от имени пользователя с ограниченными привилегиями и автоматически перезапускается.

#### Обновление клиентов {#updating-clients}

Вам необходимо поддерживать клиентское программное обеспечение в актуальном состоянии с последними исправлениями безопасности, функциями и [EIP](/eips/). Особенно перед [хардфорками](/ethereum-forks/) убедитесь, что вы используете правильные версии клиентов.

> Перед важными обновлениями сети EF публикует пост в своем [блоге](https://blog.ethereum.org). Вы можете [подписаться на эти объявления](https://blog.ethereum.org/category/protocol#subscribe), чтобы получать уведомления на почту, когда вашему узлу потребуется обновление.

Обновление клиентов очень простое. У каждого клиента есть конкретные инструкции в документации, но процесс, как правило, заключается просто в загрузке последней версии и перезапуске клиента с новым исполняемым файлом. Клиент должен продолжить с того места, где остановился, но с примененными обновлениями.

Каждая реализация клиента имеет удобочитаемую строку версии, используемую в одноранговом протоколе, но также доступную из командной строки. Эта строка версии позволяет пользователям проверять, что они используют правильную версию, и позволяет обозревателям блоков и другим аналитическим инструментам, заинтересованным в количественной оценке распределения конкретных клиентов по сети. Пожалуйста, обратитесь к документации отдельного клиента для получения дополнительной информации о строках версий.

#### Запуск дополнительных сервисов {#running-additional-services}

Запуск собственного узла позволяет вам использовать сервисы, требующие прямого доступа к RPC клиента Эфириума. Это сервисы, созданные поверх Эфириума, такие как [решения уровня 2 (l2)](/developers/docs/scaling/#layer-2-scaling), бэкенд для Кошельков, обозреватели блоков, инструменты разработчика и другая инфраструктура Эфириума.

#### Мониторинг узла {#monitoring-the-node}

Для правильного мониторинга вашего узла рассмотрите возможность сбора метрик. Клиенты предоставляют конечные точки метрик, чтобы вы могли получать исчерпывающие данные о своем узле. Используйте такие инструменты, как [InfluxDB](https://www.influxdata.com/get-influxdb/) или [Prometheus](https://prometheus.io/), для создания баз данных, которые вы можете превратить в визуализации и диаграммы в таком программном обеспечении, как [Grafana](https://grafana.com/). Существует множество настроек для использования этого программного обеспечения и различных панелей управления Grafana для визуализации вашего узла и сети в целом. Например, ознакомьтесь с [руководством по мониторингу Geth](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/).

В рамках мониторинга обязательно следите за производительностью вашей машины. Во время начальной синхронизации вашего узла клиентское программное обеспечение может сильно нагружать процессор и оперативную память. В дополнение к Grafana вы можете использовать инструменты, предлагаемые вашей ОС, такие как `htop` или `uptime`, для этого.

## Дополнительная литература {#further-reading}

- [Руководства по стейкингу Эфириума](https://github.com/SomerEsat/ethereum-staking-guides) — _Сомер Эсат (Somer Esat), часто обновляется_
- [Руководство | Как настроить валидатор для стейкинга Эфириума в Мейннете](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _— CoinCashew, часто обновляется_
- [Руководства EthStaker по запуску валидаторов в тестовых сетях](https://github.com/remyroy/ethstaker#guides) — _EthStaker, регулярно обновляется_
- [Пример приложения AWS Blockchain Node Runner для узлов Эфириума](https://aws-samples.github.io/aws-blockchain-node-runners/docs/blueprints/ethereum) — _AWS, часто обновляется_
- [Часто задаваемые вопросы о Слиянии для операторов узлов](https://notes.ethereum.org/@launchpad/node-faq-merge) — _Июль 2022 г._
- [Анализ требований к оборудованию для полного валидирующего узла Эфириума](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _— Альберт Палау (Albert Palau), 24 сентября 2018 г._
- [Запуск полных узлов Эфириума: руководство для слабо мотивированных](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _— Джастин Леру (Justin Leroux), 7 ноября 2019 г._
- [Запуск узла Hyperledger Besu в Мейннете Эфириума: преимущества, требования и настройка](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _— Фелипе Фараджи (Felipe Faraggi), 7 мая 2020 г._
- [Развертывание клиента Эфириума Незермайнд со стеком мониторинга](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _— Nethermind.eth, 8 июля 2020 г._

## Связанные темы {#related-topics}

- [Узлы и клиенты](/developers/docs/nodes-and-clients/)
- [Блоки](/developers/docs/blocks/)
- [Сети](/developers/docs/networks/)