Light client позволяет приложению проверять часть данных блокчейна, не загружая и не храня все блоки и состояния локально. Он обычно получает компактные заголовки и запрашивает необходимые сведения у других участников сети, после чего проверяет их по криптографическим обязательствам в заголовках. Такой подход снижает требования к устройству, но не превращает кошелёк автоматически в независимый full node: важны способ получения заголовков, доказательства, клиентская реализация и возможность обнаружить недоступного или недобросовестного поставщика данных.
Что хранит лёгкий клиент
Полный узел хранит больше данных и самостоятельно проверяет блоки по правилам сети. Лёгкий клиент ограничивает локальную копию: например, держит заголовки блоков, в которых содержатся сводные сведения и криптографические обязательства относительно транзакций и состояния. Если приложению нужен баланс или подтверждение включения транзакции, оно запрашивает соответствующие данные у полного узла и проверяет доказательство относительно заголовка. Вместо загрузки всей цепочки клиенту достаточно небольшого набора информации, который можно обновлять по мере продвижения сети.
Слово light описывает объём работы и данных, а не уровень важности кошелька. Лёгкий клиент всё равно должен проверять правила своей сети и обрабатывать ошибки. В разных протоколах содержание заголовка, способ распространения и тип доказательства отличаются. Поэтому нельзя считать, что все кошельки, которые называют себя лёгкими, используют одинаковую архитектуру или одинаковую модель доверия. Иногда интерфейс приложения получает данные через сервер компании и не показывает, какие именно проверки выполняются на устройстве.
Как проверка использует заголовки и доказательства
Заголовок блока содержит корни данных, полученные из структур, которые фиксируют транзакции или состояние. Полный узел знает, как строить и проверять эти структуры из блока. Лёгкий клиент может получить от него фрагмент дерева или другое доказательство включения, а затем самостоятельно проверить, что данные соответствуют корню в заголовке. Если доказательство не сходится, клиент должен отклонить ответ. Таким образом сервер помогает получить сведения, но криптографическая проверка ограничивает его возможность незаметно подменить конкретное значение.
Доказательство включения не подтверждает автоматически всё, что пользователь может увидеть в интерфейсе. Например, ответ может относиться к неверной сети или старому заголовку, если приложение не проверило контекст и актуальность. Для корректного вывода кошелёк должен связать запрос с нужной цепочкой, следить за обновлением заголовков, учитывать финальность или требуемое число подтверждений, а также разбирать реорганизации. Статус транзакции и обновление состояния рассматриваются в материале о receipt транзакции и состоянии сети.
Почему кошельку не нужна полная история
Большинство пользовательских действий касается актуального состояния: показать баланс, получить детали недавней операции или подготовить новую транзакцию. Хранить на телефоне все блоки и каждое историческое состояние для этого неудобно и требует существенно больше диска и пропускной способности. Light client сокращает начальную синхронизацию и позволяет использовать кошелёк на устройстве с ограниченными ресурсами. Пользователь всё же должен понимать, что запросы могут обслуживаться другим узлом, который способен задерживать ответы или отказывать в отдельных данных.
Для тех, кому нужна максимальная самостоятельность и постоянное обслуживание чужих запросов, подходит собственный full node. Архивный узел нужен для быстрого доступа к состояниям на старых высотах. Это разные режимы, между ними нет обязательного перехода для каждого пользователя. О том, как различаются full node и archive node, рассказывает отдельное объяснение типов узлов Ethereum. Лёгкий клиент выбирает экономию локальных данных и делегирует получение полного контекста другим узлам, сохраняя самостоятельную проверку части ответа.
Границы доверия и типовые риски
Лёгкий клиент должен достоверно получить цепочку заголовков и знать, что они соответствуют консенсусу. Если обновления заголовков приходят только из одного источника, этот источник может скрыть события или подсовывать устаревшие данные. Криптографические доказательства проверяют согласованность ответа с выбранным заголовком, но не гарантируют доступность данных и не исправляют неверную начальную точку доверия. Клиенту нужны правила выбора источника, проверки финальности, защиты от eclipse-атак и обнаружения пропусков в последовательности обновлений.
Надёжность зависит от конкретной сети и реализации. Ethereum.org отмечает, что поддержка light nodes в основной сети развивалась постепенно и возможности разных слоёв клиента не обязательно совпадают. В одном случае лёгкий режим может проверять данные консенсуса, а за деталями исполнения обращаться к удалённому RPC. В другом кошелёк использует собственный протокол запросов. Пользователю полезно смотреть документацию кошелька, параметры приватности и возможность подключить собственный RPC, если это поддерживается.
Как оценить light client в кошельке
Проверьте, какая часть данных проверяется локально и откуда клиент берёт заголовки. Уточните, передаются ли запросы стороннему API, может ли провайдер видеть адреса, и что происходит при недоступности сервиса. Важно установить, как приложение показывает неподтверждённую операцию, сколько подтверждений считает достаточными и как реагирует на реорганизацию. Не отправляйте средства только на основании одного зелёного индикатора, если сумма или адрес назначения отличаются от ожидаемых.
Если кошелёк открыт и допускает выбор RPC, сравните ответ с независимым источником или собственным узлом. Это не обязательно для каждого небольшого действия, но полезно для крупных переводов и операций со смарт-контрактами. Проверяйте chain ID перед подписью, особенно после добавления пользовательской сети. Защита от повторного воспроизведения транзакций и привязка подписи к сети описаны в статье о Chain ID и replay protection.
В итоге light client экономит место и ресурсы, сохраняя проверку части получаемых данных с помощью заголовков и доказательств. Его гарантии зависят от реализации и источника заголовков, а полный узел остаётся полезным для независимой проверки и обслуживания сети. При выборе кошелька имеет смысл выяснить не только, сколько данных он скачивает, но и кто сообщает ему текущую вершину цепи и как обрабатываются сбои.
