---
title: "Одноранговая сеть"
description: "Одноранговая сеть предоставляет каждому узлу ограниченный, меняющийся набор прямых пиров для обнаружения, gossip-рассылки и обмена запросами и ответами; она не создает единого глобального представления и не превращает принятие сообщения в консенсус."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Одноранговая сеть
> Только в образовательных целях; не является инвестиционным советом или инвестиционной рекомендацией. Инвестиции могут привести к убыткам.
## Краткий ответ
Одноранговая сеть позволяет каждому узлу находить и поддерживать ограниченный набор прямых пиров, обмениваться аутентифицированными протокольными сообщениями и формировать собственное локальное представление, не направляя все данные через один центральный сервер. Это не полный граф, не глобальный мемпул и не самостоятельный источник истины. Получение, проверка или пересылка объекта одним пиром не доказывает, что его увидели все узлы, что он включен в блок или что консенсус придал ему финальность.
После Слияния 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 все равно могут сопоставлять конечные точки, время и активность.
## Похожие темы
- [Полный узел](/ru/crypto/full-node/)
- [Мемпул](/ru/crypto/mempool/)
- [Устойчивость к цензуре](/ru/crypto/censorship-resistance/)
## Источники
- [Networking layer](https://ethereum.org/developers/docs/networking-layer) - Ethereum.org (дата обращения: 2026-08-13)
- [Ethereum Wire Protocol (ETH)](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) - Ethereum devp2p (дата обращения: 2026-08-13)
- [The RLPx Transport Protocol](https://github.com/ethereum/devp2p/blob/master/rlpx.md) - Ethereum devp2p (дата обращения: 2026-08-13)
- [Node Discovery Protocol v5 - Wire Protocol](https://github.com/ethereum/devp2p/blob/master/discv5/discv5-wire.md) - Ethereum devp2p (дата обращения: 2026-08-13)
- [Phase 0 -- Networking](https://github.com/ethereum/consensus-specs/blob/master/specs/phase0/p2p-interface.md) - Ethereum Consensus Specs (дата обращения: 2026-08-13)
- [gossipsub v1.1: Security extensions to improve on attack resilience and bootstrapping](https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.1.md) - libp2p (дата обращения: 2026-08-13)
- [Connecting To The Network](https://geth.ethereum.org/docs/fundamentals/peer-to-peer) - go-ethereum (дата обращения: 2026-08-13)
- [Spin up your own Ethereum node](https://ethereum.org/developers/docs/nodes-and-clients/run-a-node/) - Ethereum.org (дата обращения: 2026-08-13)
Source: https://wiki.fcontext.com/ru/crypto/peer-to-peer-network/index.mdx