---
title: "Полный узел"
description: "Руководство с акцентом на проверке: полные узлы, клиенты исполнения и консенсуса Ethereum, контрольные точки синхронизации, текущее и историческое состояние, обрезка, конфиденциальность RPC, финальность и расчет эксплуатационных ресурсов."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Полный узел
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Полный узел загружает необходимые его протоколу данные, проверяет блоки и переходы состояния по локальным правилам консенсуса и исполнения, следует выбранной этими правилами цепочке и может отклонять неверные данные пиров, не передавая это решение RPC-провайдеру. «Полный» означает ответственность за проверку, а не постоянное хранение всех исторических состояний, производство блоков, стейкинг, предоставление публичного API или неуязвимость для ошибок программного обеспечения и конфигурации.
В Ethereum с доказательством доли работоспособный полный узел сочетает клиент исполнения и клиент консенсуса. Клиент исполнения проверяет транзакции и полезные нагрузки исполнения, поддерживает текущее состояние исполнения и предоставляет JSON-RPC; клиент консенсуса проверяет объекты консенсуса, применяет правило выбора ветви и отслеживает обоснование и финализацию. Клиент валидатора необязателен и нужен лишь для предложения блоков и аттестаций валидаторами со стейком.
## Как это работает
1. Определите цель проверки и снимок сети: протокол, идентичность сети и генезиса, расписание форков, ожидаемый `chainId`, хеши текущего и финализированного блоков, версии клиентов, режим синхронизации, источник контрольной точки, режим обрезки, методы RPC, горизонт исторического состояния и требуемую доступность. Требования к полному узлу зависят от конкретной сети.
2. Установите независимо полученные и проверенные выпуски клиентов и соедините требуемые компоненты. В современном Ethereum соедините один клиент исполнения с одним клиентом консенсуса через аутентифицированный локальный Engine API; добавляйте валидатор только для стейкинга. Разделите каталоги данных, P2P-порты, доступ к RPC и ключи подписанта или валидатора.
3. Начните синхронизацию с предусмотренного якоря доверия. Полная синхронизация от генезиса проверяет цепочку вперед; стратегия snap или контрольной точки начинает с более нового аутентифицированного состояния либо контрольной точки слабой субъективности и затем проверяет последующие блоки. До доверия базе данных сверьте генезис, корень контрольной точки, идентификатор сети, дайджест форка и финализированную вершину по независимым каналам.
4. Контролируйте оба конвейера. Проверяйте пиров исполнения и консенсуса, отставание вершины и финализированного блока, состояние Engine API, совпадение корней состояния, синхронизацию часов, рост диска, ввод-вывод, память, процессор, ошибки базы данных и готовность к форку. Статус «синхронизирован» должен означать, что необходимые клиенты согласны относительно нужной сети и продолжают импортировать действительные данные.
5. Согласуйте хранение с запросами. Обрезанный полный узел хранит текущее состояние и достаточно данных блоков, квитанций и снимков для проверки, но может восстанавливать или отклонять запросы старого состояния. Архивная конфигурация материализует исторические состояния для быстрых запросов на момент времени. Легкий клиент проверяет более узкий путь обязательств и запрашивает дополнительные данные; это не просто маленький полный узел.
6. Открывайте минимально необходимую поверхность RPC. Привязывайте административный и Engine API к локальному интерфейсу, аутентифицируйте клиентов, защищайте хост межсетевым экраном, ограничивайте частоту прикладных RPC-запросов и не публикуйте без контроля методы debug, trace, учетных записей и пула транзакций. Проверьте теги `latest`, `safe` и `finalized`, исторические вызовы, журналы и отправку транзакций на нужном узле, а переключайтесь только на независимо проверенные резервные точки.
7. Сверяйте и восстанавливайте. Сопоставляйте хеши блоков, корни состояния и финализированные контрольные точки со вторым клиентом или независимым узлом; отработайте корректную остановку, снимок и восстановление, перестроение базы, обновление клиента, активацию форка, замену диска, потерю пиров и резервирование RPC. Сохраняйте журналы и конфигурацию, отделяя проверенный узлом результат от заявлений интерфейса, оракула, моста и приложения.
## Разобранные примеры
- **Модель пропускной способности.** Допустим, сеть выпускает блок каждые `12 seconds`, а средний загруженный размер тела блока вместе с требуемыми сопутствующими данными составляет `150 kB`. Узел обрабатывает `86,400 / 12 = 7,200 blocks/day` и загружает `7,200 * 150 kB = 1,080,000 kB = 1.08 GB/day` в десятичных единицах без учета накладных расходов P2P, повторных попыток, трафика консенсуса, снимков и исходящего трафика. Это допущения для планирования, а не актуальные константы Ethereum.
- **Резерв дискового пространства.** Обрезанный узел начинает с `1.20 TB`, а измеренный рост базы составляет `18 GB/month`. За `30 months` расчетный объем равен `1,200 + 18 * 30 = 1,740 GB`. Резерв `25%` сверх прогноза требует `1,740 * 1.25 = 2,175 GB`, или `2.175 TB` в десятичных единицах. Изменения клиента, обрезка и форки способны нарушить линейную модель.
- **Эксплуатационная доступность.** За `30 days = 720 hours` обслуживание клиента исполнения занимает `2 hours`, сбой клиента консенсуса — `3 hours`, а общий сбой питания — `1 hour`, без пересечений. Простой составляет `6 hours`; наблюдаемая доступность равна `(720 - 6) / 720 = 99.1666666667%`. Процесс узла может работать, когда узел отстает, изолирован или находится в неверной сети, поэтому одного времени работы недостаточно.
- **Восстановление исторического состояния.** Обрезанный клиент имеет пригодный снимок на блоке `18,000,000`, а состояние нужно на блоке `18,250,000`. Он должен повторно исполнить `250,000 blocks`. При измеренной скорости `500 blocks/second` идеальное время вычисления равно `250,000 / 500 = 500 seconds = 8.3333333333 minutes`, без учета чтения состояния, квитанций, обработки реорганизаций и промахов кеша. Архивный узел обменивает дополнительное хранилище на более быстрый прямой доступ к историческим состояниям.
## Риски
- Подключение к неверной сети, генезису, расписанию форков или `chainId`.
- Доверие вредоносной, устаревшей или недостаточно проверенной контрольной точке синхронизации.
- Использование устаревшего клиента во время обновления сети.
- Расхождение клиентов консенсуса и исполнения либо потеря связи Engine API.
- Ошибка реализации клиента, принимающего, отвергающего или выдающего неверные данные.
- Монокультура клиентов, создающая коррелированные сбои узла и сети.
- Слишком малое число, изоляция, злонамеренность или слабое разнообразие пиров.
- Нарушение обязанностей консенсуса, меток времени или поведения пиров из-за ухода часов.
- Переполнение диска, медленное хранилище, отказ файловой системы или повреждение базы.
- Принятие времени работы процесса за синхронизированную, каноническую и финализированную работу.
- Смешение состояний вершины, безопасного и финализированного во время реорганизации.
- Ожидание, что обрезанный полный узел мгновенно ответит на любой запрос исторического состояния.
- Ожидание, что архивный узел хранит любой внесетевой индекс, трассу или метку приложения.
- Публикация без аутентификации Engine, admin, debug, trace или API пула транзакций.
- Утечка адресов кошельков, запросов, метаданных или намерения транзакции через журналы RPC.
- Истощение ресурсов проверки блоков перегрузкой RPC, неограниченными запросами или отказом в обслуживании.
- Восстановление резервной копии или снимка в устаревшее либо внутренне несогласованное состояние.
- Потеря ключей валидатора или подписанта из-за неосторожного совместного размещения со службами узла.
- Принятие локально проверенных данных сети за доказательство честности интерфейса, оракула или моста.
- Перенос модели Ethereum с двумя клиентами, обрезкой или слабой субъективностью на другую сеть.
## Распространенные заблуждения
- Каждый полный узел является архивным и навсегда хранит все исторические состояния.
- Запуск полного узла автоматически делает оператора валидатором или производителем блоков.
- Узел со статусом «синхронизирован» обязательно находится в нужной канонической и финализированной сети.
- Самостоятельный RPC устраняет все риски доверия, конфиденциальности, программного обеспечения и эксплуатации.
- Больше диска, пиров или времени работы само по себе доказывает правильность проверки и безопасность сети.
## Связанные темы
- [Легкий клиент](/ru/crypto/light-client/)
- [RPC-узел](/ru/crypto/rpc-node/)
- [Корень состояния](/ru/crypto/state-root/)
## Источники
- [Nodes and clients](https://ethereum.org/developers/docs/nodes-and-clients/) - Ethereum.org (дата обращения: 2026-08-12)
- [Node architecture](https://ethereum.org/developers/docs/nodes-and-clients/node-architecture/) - Ethereum.org (дата обращения: 2026-08-12)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (дата обращения: 2026-08-12)
- [Ethereum Archive Node](https://ethereum.org/developers/docs/nodes-and-clients/archive-nodes/) - Ethereum.org (дата обращения: 2026-08-12)
- [Client diversity](https://ethereum.org/developers/docs/nodes-and-clients/client-diversity/) - Ethereum.org (дата обращения: 2026-08-12)
- [Sync modes](https://geth.ethereum.org/docs/fundamentals/sync-modes) - go-ethereum (дата обращения: 2026-08-12)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - Ethereum.org (дата обращения: 2026-08-12)
- [Weak subjectivity](https://ethereum.org/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) - Ethereum.org (дата обращения: 2026-08-12)
Source: https://wiki.fcontext.com/ru/crypto/full-node/index.mdx