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

Узлы и клиенты

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

Предварительные требования

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

Если вы новичок в теме узлов, мы рекомендуем сначала ознакомиться с нашим понятным введением о запуске узла Эфириума.

Что такое узлы и клиенты?

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

  • Клиент исполнения (также известный как механизм исполнения, клиент EL или ранее клиент Eth1) прослушивает новые транзакции, транслируемые в сети, выполняет их в EVM и хранит последнее состояние и базу данных всех текущих данных Эфириума.
  • Клиент консенсуса (также известный как сигнальный узел, клиент CL или ранее клиент Eth2) реализует алгоритм консенсуса доказательство доли владения, который позволяет сети достигать соглашения на основе проверенных данных от клиента исполнения. Существует также третья часть программного обеспечения, известная как «валидатор», которая может быть добавлена к клиенту консенсуса, позволяя узлу участвовать в обеспечении безопасности сети.

Эти клиенты работают вместе, чтобы отслеживать начало цепи Эфириума и позволять пользователям взаимодействовать с сетью Эфириума. Модульная конструкция, в которой несколько программ работают вместе, называется инкапсулированной сложностью (opens in a new tab). Этот подход позволил легко осуществить Слияние, упрощает обслуживание и разработку клиентского программного обеспечения, а также позволяет повторно использовать отдельные клиенты, например, в экосистеме уровня 2 (l2).

Coupled execution and consensus clients Упрощенная схема связанного клиента исполнения и консенсуса.

Разнообразие клиентов

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

Множественные реализации клиентов могут сделать сеть сильнее, уменьшив ее зависимость от единой кодовой базы. Идеальная цель — достичь разнообразия без доминирования какого-либо клиента в сети, тем самым устраняя потенциальную единую точку отказа. Разнообразие языков также привлекает более широкое сообщество разработчиков и позволяет им создавать интеграции на предпочитаемом ими языке.

Узнайте больше о разнообразии клиентов.

Общим для этих реализаций является то, что все они следуют единой спецификации. Спецификации диктуют, как функционируют сеть Эфириума и блокчейн. Каждая техническая деталь определена, и спецификации можно найти в виде:

Отслеживание узлов в сети

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

Типы узлов

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

Полный узел

Полные узлы выполняют валидацию блокчейна блок за блоком, включая загрузку и проверку тела блока и данных состояния для каждого блока. Существуют разные классы полных узлов — некоторые начинают с генезис-блока и проверяют каждый отдельный блок за всю историю блокчейна. Другие начинают свою проверку с более позднего блока, который они считают действительным (например, «snap sync» в Geth). Независимо от того, где начинается проверка, полные узлы хранят только локальную копию относительно недавних данных (обычно последние 128 блоков), что позволяет удалять старые данные для экономии места на диске. Старые данные могут быть восстановлены при необходимости.

  • Хранит полные данные блокчейна (хотя они периодически обрезаются, поэтому полный узел не хранит все данные состояния вплоть до генезис-блока).
  • Участвует в валидации блоков, проверяет все блоки и состояния.
  • Все состояния могут быть либо извлечены из локального хранилища, либо восстановлены из «снимков» полным узлом.
  • Обслуживает сеть и предоставляет данные по запросу.

Архивная нода

Архивные ноды — это полные узлы, которые проверяют каждый блок начиная с генезис-блока и никогда не удаляют загруженные данные.

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

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

Узнайте больше об архивных нодах.

Легкая нода

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

Легкие клиенты — это область активной разработки для Эфириума, и мы ожидаем вскоре увидеть новые легкие клиенты для уровня консенсуса и уровня исполнения. Существуют также потенциальные пути предоставления данных легкого клиента через gossip-сеть (opens in a new tab). Это выгодно, поскольку gossip-сеть могла бы поддерживать сеть легких нод, не требуя от полных узлов обслуживания запросов.

Эфириум пока не поддерживает большое количество легких нод, но поддержка легких нод — это область, которая, как ожидается, будет быстро развиваться в ближайшем будущем. В частности, такие клиенты, как Нимбус (opens in a new tab), Helios (opens in a new tab) и Лодстар (opens in a new tab), в настоящее время в значительной степени ориентированы на легкие ноды.

Зачем мне запускать узел Эфириума?

Запуск узла позволяет вам напрямую, приватно и не требуя доверия использовать Эфириум, одновременно поддерживая сеть, делая ее более надежной и децентрализованной.

Преимущества для вас

Запуск собственного узла позволяет вам использовать Эфириум приватно, самодостаточно и не требуя доверия. Вам не нужно доверять сети, потому что вы можете проверить данные самостоятельно с помощью своего клиента. «Не доверяй, проверяй» — популярная мантра блокчейна.

  • Ваш узел самостоятельно проверяет все транзакции и блоки на соответствие правилам консенсуса. Это означает, что вам не нужно полагаться на какие-либо другие узлы в сети или полностью им доверять.
  • Вы можете использовать кошелек Эфириума с собственным узлом. Вы можете использовать децентрализованные приложения (dapp) более безопасно и приватно, потому что вам не придется раскрывать свои адреса и балансы посредникам. Все можно проверить с помощью собственного клиента. МетаМаск (opens in a new tab), Frame (opens in a new tab) и многие другие кошельки предлагают импорт RPC, что позволяет им использовать ваш узел.
  • Вы можете запускать и самостоятельно размещать другие сервисы, которые зависят от данных из Эфириума. Например, это может быть валидатор сигнальной цепочки, программное обеспечение вроде уровня 2 (l2), инфраструктура, обозреватели блоков, платежные системы и т. д.
  • Вы можете предоставить свои собственные пользовательские конечные точки RPC. Вы даже можете предложить эти конечные точки публично сообществу, чтобы помочь им избежать крупных централизованных провайдеров.
  • Вы можете подключиться к своему узлу с помощью межпроцессного взаимодействия (IPC) или переписать узел, чтобы загрузить вашу программу как плагин. Это обеспечивает низкую задержку, что очень помогает, например, при обработке большого количества данных с использованием библиотек Web3 или когда вам нужно заменить свои транзакции как можно быстрее (т. е. фронтраннинг).
  • Вы можете напрямую стейкать ETH для обеспечения безопасности сети и получения вознаграждений. См. соло-стейкинг, чтобы начать.

How you access Ethereum via your application and nodes

Преимущества для сети

Разнообразный набор узлов важен для здоровья, безопасности и операционной устойчивости Эфириума.

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

Если вы запускаете полный узел, от этого выигрывает вся сеть Эфириума, даже если вы не запускаете валидатор.

Запуск собственного узла

Заинтересованы в запуске собственного клиента Эфириума?

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

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

Альтернативы

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

Если кто-то в вашем сообществе запускает узел Эфириума с публичным API, вы можете направить свои кошельки на узел сообщества через пользовательский RPC и получить больше приватности, чем с какой-то случайной доверенной третьей стороной.

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

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

Сообщество Эфириума поддерживает несколько клиентов исполнения с открытым исходным кодом (ранее известных как «клиенты Eth1» или просто «клиенты Эфириума»), разработанных разными командами с использованием разных языков программирования. Это делает сеть сильнее и более разнообразной. Идеальная цель — достичь разнообразия без доминирования какого-либо клиента, чтобы уменьшить количество единых точек отказа.

В этой таблице приведены различные клиенты. Все они проходят тесты клиентов (opens in a new tab) и активно поддерживаются, чтобы оставаться в курсе обновлений сети.

КлиентЯзыкОперационные системыСетиСтратегии синхронизацииОбрезка состояния
Geth (opens in a new tab)GoLinux, Windows, macOSМейннет, Sepolia, HoodiSnap, ПолнаяАрхивная, Обрезанная
Незермайнд (opens in a new tab)C#, .NETLinux, Windows, macOSМейннет, Sepolia, HoodiSnap, Быстрая, ПолнаяАрхивная, Обрезанная
Бесу (opens in a new tab)JavaLinux, Windows, macOSМейннет, Sepolia, HoodiSnap, Быстрая, ПолнаяАрхивная, Обрезанная
Эригон (opens in a new tab)GoLinux, Windows, macOSМейннет, Sepolia, HoodiПолнаяАрхивная, Обрезанная
Рет (opens in a new tab)RustLinux, Windows, macOSМейннет, Sepolia, HoodiПолнаяАрхивная, Обрезанная
EthereumJS (opens in a new tab) (бета)TypeScriptLinux, Windows, macOSSepolia, HoodiПолнаяОбрезанная

Для получения дополнительной информации о поддерживаемых сетях прочитайте о сетях Эфириума.

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

Бесу

Hyperledger Besu — это клиент Эфириума корпоративного уровня для публичных сетей и сетей с разрешенным доступом. Он выполняет все функции основной сети Ethereum, от трассировки до GraphQL, имеет обширный мониторинг и поддерживается ConsenSys как в открытых каналах сообщества, так и через коммерческие SLA для предприятий. Он написан на Java и лицензирован под Apache 2.0.

Обширная документация (opens in a new tab) Бесу проведет вас через все детали его функций и настроек.

Эригон

Эригон, ранее известный как Turbo-Geth, начинался как форк Go Ethereum, ориентированный на скорость и эффективность использования дискового пространства. Эригон — это полностью переработанная реализация Эфириума, в настоящее время написанная на Go, но с реализациями на других языках, находящимися в разработке. Цель Эригона — предоставить более быструю, модульную и оптимизированную реализацию Эфириума. Он может выполнить полную синхронизацию архивной ноды, используя около 2 ТБ дискового пространства, менее чем за 3 дня.

Go Ethereum

Go Ethereum (сокращенно Geth) — одна из оригинальных реализаций протокола Эфириума. В настоящее время это самый распространенный клиент с самой большой базой пользователей и разнообразием инструментов для пользователей и разработчиков. Он написан на Go, имеет полностью открытый исходный код и лицензирован под GNU LGPL v3.

Узнайте больше о Geth в его документации (opens in a new tab).

Незермайнд

Незермайнд — это реализация Эфириума, созданная с использованием технологического стека C# .NET, лицензированная под LGPL-3.0, работающая на всех основных платформах, включая ARM. Он предлагает отличную производительность с:

  • оптимизированной виртуальной машиной
  • доступом к состоянию
  • сетью и богатыми функциями, такими как панели управления Prometheus/Grafana, поддержка корпоративного логирования seq, трассировка JSON-RPC и плагины аналитики.

Незермайнд также имеет подробную документацию (opens in a new tab), сильную поддержку разработчиков, онлайн-сообщество и круглосуточную поддержку, доступную для премиум-пользователей.

Рет

Рет (сокращение от Rust Ethereum) — это реализация полного узла Эфириума, которая ориентирована на удобство для пользователя, высокую модульность, скорость и эффективность. Рет был изначально создан и продвигался Paradigm, и лицензирован под лицензиями Apache и MIT.

Рет готов к производству и подходит для использования в критически важных средах, таких как стейкинг или сервисы с высоким временем безотказной работы. Хорошо работает в случаях использования, где требуется высокая производительность с большим запасом, таких как RPC, MEV, индексирование, симуляции и P2P-активности.

Узнайте больше, ознакомившись с книгой Рет (opens in a new tab) или репозиторием Рет на GitHub (opens in a new tab).

В разработке

Эти клиенты все еще находятся на ранних стадиях разработки и пока не рекомендуются для использования в производстве.

EthereumJS

Клиент исполнения EthereumJS (EthereumJS) написан на TypeScript и состоит из ряда пакетов, включая основные примитивы Эфириума, представленные классами Block, Transaction и Merkle-Patricia Trie, а также основные компоненты клиента, включая реализацию виртуальной машины Эфириума (EVM), класс блокчейна и сетевой стек devp2p.

Узнайте больше об этом, прочитав его документацию (opens in a new tab)

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

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

КлиентЯзыкОперационные системыСети
Лайтхаус (opens in a new tab)RustLinux, Windows, macOSСигнальная цепочка, Hoodi, Pyrmont, Sepolia и другие
Лодстар (opens in a new tab)TypeScriptLinux, Windows, macOSСигнальная цепочка, Hoodi, Sepolia и другие
Нимбус (opens in a new tab)NimLinux, Windows, macOSСигнальная цепочка, Hoodi, Sepolia и другие
Призм (opens in a new tab)GoLinux, Windows, macOSСигнальная цепочка, Gnosis, Hoodi, Pyrmont, Sepolia и другие
Теку (opens in a new tab)JavaLinux, Windows, macOSСигнальная цепочка, Gnosis, Hoodi, Sepolia и другие
Grandine (opens in a new tab)RustLinux, Windows, macOSСигнальная цепочка, Hoodi, Sepolia и другие

Лайтхаус

Лайтхаус — это реализация клиента консенсуса, написанная на Rust под лицензией Apache-2.0. Он поддерживается Sigma Prime и является стабильным и готовым к производству с момента создания сигнальной цепочки. На него полагаются различные предприятия, пулы для стейкинга и частные лица. Он стремится быть безопасным, производительным и интероперабельным в широком спектре сред, от настольных ПК до сложных автоматизированных развертываний.

Документацию можно найти в книге Лайтхаус (opens in a new tab)

Лодстар

Лодстар — это готовая к производству реализация клиента консенсуса, написанная на TypeScript под лицензией LGPL-3.0. Он поддерживается ChainSafe Systems и является новейшим из клиентов консенсуса для соло-стейкеров, разработчиков и исследователей. Лодстар состоит из сигнального узла и клиента валидатора, работающих на реализациях протоколов Эфириума на JavaScript. Лодстар стремится улучшить удобство использования Эфириума с помощью легких клиентов, расширить доступность для более широкой группы разработчиков и внести дальнейший вклад в разнообразие экосистемы.

Дополнительную информацию можно найти на веб-сайте Лодстар (opens in a new tab)

Нимбус

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

Узнайте больше в документации Нимбус (opens in a new tab)

Призм

Призм — это полнофункциональный клиент консенсуса с открытым исходным кодом, написанный на Go под лицензией GPL-3.0. Он имеет дополнительный пользовательский интерфейс веб-приложения и отдает приоритет пользовательскому опыту, документации и возможности настройки как для домашних стейкеров, так и для институциональных пользователей.

Посетите документацию Призм (opens in a new tab), чтобы узнать больше.

Теку

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

Теку предлагает очень гибкие варианты развертывания. Сигнальный узел и клиент валидатора могут быть запущены вместе как единый процесс, что чрезвычайно удобно для соло-стейкеров, или узлы могут быть запущены отдельно для сложных операций стейкинга. Кроме того, Теку полностью интероперабелен с Web3Signer (opens in a new tab) для безопасности ключей подписания и защиты от слэшинга.

Теку написан на Java и лицензирован под Apache 2.0. Он разработан командой Protocols в ConsenSys, которая также отвечает за Бесу и Web3Signer. Узнайте больше в документации Теку (opens in a new tab).

Grandine

Grandine — это реализация клиента консенсуса, написанная на Rust под лицензией GPL-3.0. Он поддерживается основной командой Grandine и является быстрым, высокопроизводительным и легким. Он подходит для широкого круга стейкеров: от соло-стейкеров, работающих на устройствах с низкими ресурсами, таких как Raspberry Pi, до крупных институциональных стейкеров, запускающих десятки тысяч валидаторов.

Документацию можно найти в книге Grandine (opens in a new tab)

Режимы синхронизации

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

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

Режимы синхронизации уровня исполнения

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

Полная синхронизация

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

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

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

Быстрая синхронизация

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

  • Стратегия быстрой синхронизации.
  • Снижает потребность в обработке в пользу использования пропускной способности.

Snap-синхронизация

Snap-синхронизация также проверяет цепь блок за блоком. Однако вместо того, чтобы начинать с генезис-блока, snap-синхронизация начинается с более недавней «доверенной» контрольной точки, которая, как известно, является частью истинного блокчейна. Узел периодически сохраняет контрольные точки, удаляя данные старше определенного возраста. Эти снимки используются для восстановления данных состояния по мере необходимости, а не для их вечного хранения.

  • Самая быстрая стратегия синхронизации, в настоящее время используемая по умолчанию в основной сети Ethereum.
  • Значительно экономит использование диска и пропускную способность сети без ущерба для безопасности.

Подробнее о snap-синхронизации (opens in a new tab).

Легкая синхронизация

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

  • Получает только последнее состояние, полагаясь на доверие к разработчикам и механизму консенсуса.
  • Клиент готов к использованию с текущим состоянием сети через несколько минут.

Примечание: Легкая синхронизация пока не работает с Эфириумом на доказательстве доли владения — новые версии легкой синхронизации должны появиться в ближайшее время!

Подробнее о легких клиентах

Режимы синхронизации уровня консенсуса

Оптимистичная синхронизация

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

Подробнее об оптимистичной синхронизации (opens in a new tab)

Синхронизация контрольных точек

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

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

Подробнее о синхронизации контрольных точек (opens in a new tab)

Дополнительная литература