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

Одноранговая сеть

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

Обновлено

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

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

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

После Слияния Ethereum использует две отдельные одноранговые сети. Клиенты уровня исполнения применяют обнаружение, RLPx и версионируемую возможность eth для синхронизации и обмена транзакциями. Клиенты уровня консенсуса используют discv5 для обнаружения, а gossip-рассылку libp2p и протоколы запрос-ответ — для блоков Beacon Chain, аттестаций и других объектов консенсуса. Оба клиента координируются локально через аутентифицированный Engine API; кошелек обычно отправляет данные через JSON-RPC и от этого не становится узлом gossip-рассылки.

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

  1. Зафиксируйте цепь, сеть, генезис и конфигурацию форка, версии клиентов исполнения и консенсуса, идентификаторы узлов и время наблюдения. Отдельно обозначьте клиент исполнения, клиент консенсуса, необязательный валидатор, локальный Engine API и пользовательский RPC.
  2. Проверьте каждый путь обнаружения: встроенные загрузочные узлы, списки DNS, статические или доверенные пиры, идентификатор ENR или enode, объявленную конечную точку и ее последовательность, совместимость сети, NAT и доступность входящих соединений. Подписанный ENR связывает запись с ключом, но не доказывает честность, синхронизацию или текущую доступность.
  3. Учитывайте соединение и согласование протоколов отдельно. Пиры исполнения создают сеансы RLPx и согласуют возможности, например eth; пиры консенсуса после обнаружения discv5 согласуют транспорт libp2p, защиту и идентификаторы протоколов. Обнаружение конечной точки не означает совместимость приложения.
  4. Отслеживайте фактический путь каждого объекта. Транзакция может пройти от отправки по RPC к локальной проверке и мемпулу исполнения, а затем к объявлениям и запросам eth. Объекты консенсуса проходят проверку gossip-сообщений по теме, а недостающие блоки можно получить через запрос-ответ.
  5. До локального приема или пересылки применяйте ограниченное декодирование, дедупликацию, лимиты частоты, проверку подписи, синтаксиса и состояния. Записывайте недействительные, проигнорированные, недоступные и ограниченные ресурсами результаты; оценка пира и политика отключения являются локальными решениями реализации, а не репутацией в консенсусе.
  6. Разделяйте получение, проверку, пересылку, включение транзакции, результат исполнения, выбор форка, обоснование и финальность как отдельные состояния и временные шкалы. Сравнивайте несколько пиров или узлов, если ответ локального пула, головы или истории неполон, противоречив или устарел.
  7. Отслеживайте разнообразие входящих и исходящих пиров, операторов, префиксов IP и концентрацию ASN, сменяемость, задержку, потерю пакетов, пропускную способность, очереди, недействительный трафик, состояние часов и зависимости RPC. Отрабатывайте потерю загрузочных узлов, сбой NAT, разделение, eclipse-атаку, перегрузку и восстановление, не заявляя об абсолютной устойчивости.

Обнаружение пиров, защита транспорта и действительность приложения решают разные задачи. Загрузочные узлы знакомят с кандидатами, но не передают обычный трафик и не выбирают каноническую цепь. Шифрование защищает содержимое и аутентификацию сеанса, но пиры все равно узнают сетевые точки и время; удаленный провайдер RPC может дополнительно наблюдать запросы, адреса и отправленные транзакции.

Распространение идет параллельно и зависит от топологии. Разветвление, дублирующие пути, сериализация пропускной способности, процессорная проверка, очереди, потеря пакетов, повторная передача, оценка пиров и правила для каждого объекта определяют распределение и хвост времени доставки. Формула delay = hops * perHopTime — лишь явно заданная последовательная учебная модель, а не гарантия сети.

Пример

  • Последовательный путь и конвейер. На учебном пути из 4 hops каждый переход занимает 80 ms сетевого времени и 20 ms проверки. Полностью последовательная обработка дает 4 * (80 + 20) = 400 ms. Если проверка перекрывается со следующей передачей, упрощенная нижняя граница равна 4 * 80 + 20 = 340 ms. Ни одно значение не является временем распространения по всей сети.
  • Объявление и получение транзакций. Узел получает 20 хешей транзакций, из которых уже имеет 6, поэтому отсутствуют тела 20 - 6 = 14. Если учебный запрос вмещает не более 8, нужны ceil(14 / 8) = 2 batches. При времени кругового обмена 120 ms и проверке 30 ms на пакет последовательное завершение занимает 2 * (120 + 30) = 300 ms, идеальное параллельное — 150 ms. Фактические пределы зависят от согласованной версии eth и клиента.
  • Упрощенная вероятность eclipse-атаки. Если каждый из 8 исходящих пиров выбирается независимо, а доля вредоносных кандидатов составляет 25%, вероятность выбрать только вредоносных равна 0.25^8 = 0.0000152587890625 = 0.00152587890625%. Смещение обнаружения, Sybil-идентификаторы, корреляция IP и ASN и удержание пиров нарушают предположение независимости, поэтому это не гарантия безопасности.
  • Перегрузка проверки. Входящий gossip-трафик равен 900 messages/s; 4 обработчика проверяют по 250 messages/s, создавая емкость 1,000 messages/s, запас 100 messages/s и загрузку 90%. Атака на 1,400 messages/s создает очередь со скоростью 400 messages/s и 6,000 messages за 15 seconds. Очередь размером 5,000-message заполнится за 5,000 / 400 = 12.5 seconds до отбрасывания или ограничения частоты без учета разброса времени обслуживания.

Риски

  • Неверная конфигурация цепи, генезиса или форка
  • Несовместимость клиента исполнения, клиента консенсуса или Engine API
  • Концентрация или перехват обнаружения через загрузочные узлы и DNS
  • Устаревшие, поддельные или недоступные метаданные конечной точки
  • NAT, межсетевой экран или настройка порта блокирует ожидаемую доступность
  • Eclipse-атака фильтрует локальное представление узла
  • Sybil-идентификаторы и концентрация IP, ASN, операторов или облаков
  • Чрезмерная зависимость от статических или доверенных пиров
  • Цензура транзакций или избирательная пересылка
  • Различие публичного и частного потока заявок
  • Различие локальных правил приема, замены и вытеснения мемпула
  • Недействительные gossip-сообщения истощают ресурсы процессора
  • Крупные запросы, декомпрессия, полоса, память или диск истощают ресурсы
  • Манипуляция оценкой пиров или ложные штрафы
  • Обратное давление очереди отбрасывает чувствительные ко времени сообщения
  • Задержка, потери или смещение часов вызывают временное расхождение головы
  • Несовместимость версии протокола или дайджеста форка
  • Обрезанная история или ответ о недоступности ресурса ошибочно трактуется как отсутствие
  • Утечка конфиденциальности IP, времени, запросов и источника транзакций
  • Централизованный или открытый RPC приводит к отслеживанию, устаревшему представлению, цензуре или компрометации

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

  • Каждый узел напрямую соединен со всеми остальными. У каждого узла есть конечный меняющийся локальный набор пиров, и разные узлы временно могут видеть разные сообщения и головы.
  • Загрузочный узел — доверенный источник блоков или участник консенсуса. Его обычная роль — первоначальное знакомство с пирами; действительность цепи и выбор форка проверяются отдельно.
  • Транзакция, принятая одним пиром, разослана глобально и гарантированно включена. Прием и пересылка локальны, а построитель или предложивший блок может ее исключить.
  • Проверка gossip-сообщения означает консенсус и финальность. Это ранний локальный сетевой фильтр; выбор форка, обоснование и финальность — отдельные автоматы состояний.
  • Большее число пиров или шифрование транспорта автоматически дает анонимность и защиту от eclipse-атак. Важны разнообразие и выбор, а пиры и провайдеры RPC все равно могут сопоставлять конечные точки, время и активность.

Похожие темы

Источники

Навигация

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