Перейти к содержанию
Financial Context Wiki

Полный узел

Руководство с акцентом на проверке: полные узлы, клиенты исполнения и консенсуса Ethereum, контрольные точки синхронизации, текущее и историческое состояние, обрезка, конфиденциальность RPC, финальность и расчет эксплуатационных ресурсов.

Обновлено

Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.

Краткий ответ

Полный узел загружает необходимые его протоколу данные, проверяет блоки и переходы состояния по локальным правилам консенсуса и исполнения, следует выбранной этими правилами цепочке и может отклонять неверные данные пиров, не передавая это решение 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 устраняет все риски доверия, конфиденциальности, программного обеспечения и эксплуатации.
  • Больше диска, пиров или времени работы само по себе доказывает правильность проверки и безопасность сети.

Связанные темы

Источники

Навигация

Поиск по вики...