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

Легкие клиенты

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

Обновлено

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

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

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

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

Как это работает

  1. Зафиксируйте сеть и корни доверия: идентификатор цепи, корень и время генезисных валидаторов, расписание форков и пресеты, текущее время, версию клиента и недавнюю доверенную финализированную контрольную точку слабой субъективности. Сверяйте ее по независимым аутентифицированным источникам: согласие пиров не исправляет злонамеренный начальный корень.
  2. Получите LightClientBootstrap для доверенного корня блока. Проверьте заголовок начальной синхронизации, текущий комитет синхронизации и его ветвь Меркла, затем инициализируйте LightClientStore. Отклоняйте цепь, дайджест форка, обобщенный индекс или схему сериализации, не соответствующие настроенному форку.
  3. Обрабатывайте объекты LightClientUpdate по периодам комитетов синхронизации. До смены комитетов проверяйте слоты, биты участия, агрегированную подпись BLS и домен, ветви текущего и следующего комитетов, ветвь финальности и монотонность. Обновления форков могут менять поля объектов и обобщенные индексы, поэтому константы Altair не являются вечными универсальными значениями.
  4. Ведите отдельные политики для optimistic_header и finalized_header. Оптимистическое обновление может давать более свежие сведения с большим риском реорганизации или удержания данных; финализированное имеет более сильный статус консенсуса, но отстает. Приложение должно явно выбирать нужный заголовок, а не называть финальным самый новый ответ.
  5. Привяжите данные исполнения. Проверьте заголовок полезной нагрузки исполнения и ветвь в аутентифицированном заголовке легкого клиента, затем привяжите каждый запрос счета или хранилища к соответствующим stateRoot, хешу блока и статусу финальности. В Ethereum eth_getProof может вернуть доказательство счета и запрошенных ячеек хранилища; локально проверяйте узлы, пути, значения и доказательство отсутствия.
  6. Учтите каждую непроверенную поверхность. Доказательство баланса не удостоверяет квитанцию, запрос журналов, трассировку, симуляцию вызова, мемпул, метку токена, оракул, blob, исторический диапазон или заявление провайдера об отсутствии пропущенных результатов. Для каждого требуемого объекта задайте доказательство, независимую реконструкцию, резервный полный узел либо явное допущение доверия.
  7. Работайте с отказом в безопасное состояние. Записывайте контрольную точку, форк, оптимистический и финализированный корни, блок исполнения и корень состояния, узлы доказательства, провайдера и время. Ограничивайте устаревание, диверсифицируйте провайдеров и сетевые пути, защищайте приватность запросов, проверяйте восстановление после изоляции и сбоев и переходите к полному узлу или иной системе проверки, если поверхности доказательств легкого клиента недостаточно.

Разобранные примеры

  • Целочисленная граница комитета. Для комитета из 512 участников тест сверхбольшинства в спецификации имеет вид participants * 3 >= 512 * 2. При 341 участнике 341 / 512 = 66.6015625%, а 1,023 < 1,024, поэтому тест не пройден. При 342 получаем 342 / 512 = 66.796875% и 1,026 >= 1,024, поэтому тест пройден. Это проверяет настроенное правило обновления, но не честность каждого участника или реализации.
  • Время заголовков. Учебная контрольная точка находится в слоте 10,000, аттестованный заголовок — в 10,064, а его финализированный заголовок — в 10,032. При 12 seconds/slot аттестованный заголовок следует через 64 * 12 = 768 seconds = 12 minutes 48 seconds, а финальность отстает от него на 32 * 12 = 384 seconds = 6 minutes 24 seconds. Длительность слота не гарантирует доставку или финальность в фиксированный срок по часам.
  • Компактная ветвь, узкое утверждение. В идеальном сбалансированном дереве с 2^20 листьями ветвь одного листа содержит 20 соседних хешей. При 32 bytes/hash это 640 bytes; относительно объекта 8 MiB = 8,388,608 bytes ветвь занимает 0.00762939453125%, то есть сокращение равно 99.99237060546875%. Ветвь доказывает только связь листа с корнем, но не доступность остальных байтов.
  • Доказательство и простой RPC. Для финализированного stateRoot исполнения проверенное доказательство счета дает 3.25 ETH, а ответ RPC без доказательства — 3.30 ETH. Расхождение равно 0.05 ETH, причем простой ответ выше на 0.05 / 3.30 = 1.5151515152%. Принимайте значение, доказанное под выбранным корнем, но не выводите из него последующий баланс, квитанцию, исторический результат или идентичность токена.

Риски

  • Неверная цепь, корень генезисных валидаторов, время генезиса или пресет.
  • Начальная синхронизация от вредоносной, устаревшей или нефинализированной точки.
  • Единственный неаутентифицированный источник точки или принятие дальней альтернативной истории.
  • Сдвиг локальных часов, искажающий слоты, периоды, домены или оценку свежести.
  • Устаревшее расписание форков, схема объектов или обобщенный индекс.
  • Отсутствие проверки участия комитета, подписей BLS или доменов.
  • Пропущенная смена комитета либо неверный текущий или следующий комитет.
  • Оптимистический заголовок принят за финализированный.
  • Связан неверный Beacon-заголовок, payload исполнения или хеш блока.
  • Доказательство счета или хранилища проверено против неверного stateRoot.
  • Приняты поврежденные узлы trie, пути, кодировки или доказательства отсутствия.
  • Неподдерживаемый или лишенный доказательства метод RPC считается проверенным.
  • Провайдер возвращает устаревшие, цензурированные, неполные или вымышленные данные.
  • Eclipse-, Sybil-атака либо общий контроль над внешне разными провайдерами.
  • Потеря доступности, когда обслуживающие доказательства полные узлы удаляют данные или прекращают обслуживание.
  • Смешение корректности консенсуса с повторным исполнением или корректностью приложения.
  • Смешение корректного доказательства с доступностью или вечной извлекаемостью данных.
  • Отсутствие нужных приложению квитанций, журналов, трасс, тел блоков или истории.
  • Ошибка реализации клиента, зависимости, бинарного файла или обновления форка.
  • Утечка запросов, IP-адреса, счетов и транзакций провайдерам или пирам.

Распространенные заблуждения

  • Легкий клиент — всего лишь уменьшенный полный узел или другое название удаленного RPC.
  • Проверенный заголовок комитета синхронизации делает надежным каждый ответ RPC.
  • Самый свежий оптимистический заголовок равнозначен финализированному.
  • Доказательство Меркла или подпись консенсуса доказывает доступность данных и полноту истории.
  • Легкий клиент автоматически дает приватность, доступность и устойчивость к цензуре полного узла.

Похожие темы

Источники

Навигация

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