RPC Reth с наименьшей задержкой для MEV…

Краткий ответ — установка Reth RPC с минимальной задержкой для Ethereum MEV в 2026 году требует запуска автономного узла Paradigm Reth на «голом железе» (NVMe Gen4/5, 64 ГБ DDR5), расположенном рядом со сборщиками первичных блоков в AWS us-east-1 или эквивалентных объектах Equinix. Подключение агента FRB напрямую к локальной конечной точке Reth WebSocket (ws://127.0.0.1:8546) полностью устраняет время прохождения через Интернет, обеспечивая внутреннюю задержку менее 1 мс для доставки событий мемпула. В этом руководстве рассказывается, почему Reth, как его настроить и как интегрировать с FRB для выполнения производственного MEV.

Путь освоения темы: мастерство по Layer 2

• Задержка MEV на Arbitrum
• Стратегии MEV на Base
• Плейбук по Optimism
• Мастерство Reth RPC (текущая статья)
• Лучшие WSS-эндпоинты по сетям

Почему Reth с собственным размещением превосходит общих поставщиков RPC

Конкурентное преимущество в MEV измеряется миллисекундами. Каждая миллисекунда между тем, как прибыльная ожидающая транзакция поступает в сеть Ethereum, и тем, когда ваш бот обнаруживает ее, является окном для более быстрого конкурента, чтобы вместо этого воспользоваться этой возможностью.

Поставщики общих RPC (Alchemy, QuickNode, Infura) обслуживают тысячи одновременных пользователей. Они применяют ограничение скорости, ставят запросы в очередь и используют балансировщики нагрузки, которые добавляют 20–150 мс накладных расходов в зависимости от перегрузки. Эти накладные расходы невидимы при обычном использовании — они имеют значение только в узких окнах, когда возможности MEV активны.

Автономный Reth полностью исключает общую очередь. Ваш узел получает и обрабатывает ожидающие транзакции от узлов без посредников. Задержка между одноранговой сетью и вашим приложением ограничена только временем распространения по сети и скоростью локальной обработки.

Количественная разница: общие конечные точки RPC для подписок на мемпул Ethereum обычно доставляют события eth_subscribe через 30–200 мс после того, как узел увидит их во время умеренной нагрузки. Локальный узел Reth с WSS, подключенным к локальному хосту, доставляет те же события менее чем за 2 мс.

Почему Reth лучше Geth, Erigon и Nethermind

Reth — это клиент исполнения Ethereum на базе Rust, разработанный Paradigm и изначально спроектированный с учетом производительности и модульности. По сравнению с альтернативами:

Reth vs Geth:

• Reth синхронизируется с генезиса быстрее, чем Geth, во всех опубликованных тестах
• Reth использует MDBX (B-дерево с отображением в памяти) вместо LevelDB — значительно быстрее для паттерна случайного чтения при поиске состояний во время симуляции мемпула
• Реализация WebSocket в Reth имеет меньшие издержки сериализации, что дает задержку доставки событий ниже на 5–15 мс для высокочастотных подписок

Reth vs Erigon:

• Erigon также использует MDBX и обладает отличной производительностью чтения исторических данных
• Высокий темп разработки Reth и вклад Paradigm, ориентированный на MEV, делают его более отзывчивым к специфическим потребностям поисковиков в оптимизации
• У Reth более стабильный WebSocket API с лучшим поведением при высоком объеме подписок

Reth vs Nethermind:

• Nethermind основан на .NET; Reth — на Rust. Модель управления памятью Rust обеспечивает более предсказуемую задержку в сценариях с нагрузкой на сборщик мусора, с которыми .NET сталкивается в периоды высокой загрузки
• Пространство имен debug в Reth более полное, что важно для рабочих процессов симуляции

Для выполнения MEV в 2026 году Reth является эталонным клиентом.

Требования к оборудованию (спецификации 2026 г.)

Накопитель — здесь компромиссы недопустимы: По состоянию на 2026 год состояние архива Ethereum превышает 2 ТБ. Требованием к производительности хранилища является не пропускная способность (МБ/с), а IOPS — случайные операции чтения/записи в секунду, которые определяют, насколько быстро Reth может отвечать на запросы состояния во время моделирования пакета.

• Минимум: Твердотельный накопитель NVMe Gen4 емкостью 4 ТБ (Samsung 990 Pro, эквивалент WD Black SN850)
• Рекомендуется: Твердотельный накопитель NVMe Gen5 емкостью 4 ТБ — примерно в 2 раза больше операций ввода-вывода в секунду, чем Gen4, что напрямую снижает задержку моделирования для сложной многоскачковой проверки пакетов.
• Не используйте твердотельные накопители SATA — SATA III ограничен скоростью ~550 МБ/с при последовательном режиме и ~100 000 операций ввода-вывода в секунду. NVMe Gen4 обеспечивает скорость ~7000 МБ/с и ~1 млн+ операций ввода-вывода в секунду. Разница измеряется временем моделирования пакета.

Оперативная память:

• Минимум: 32 ГБ DDR4
• Рекомендуется: 64 ГБ DDR5 — реализация MDBX в Reth значительно выигрывает от большого страничного кэша ОС; больше оперативной памяти означает, что большая часть дерева состояний остается в кэше, что снижает число обращений к SSD во время пиковой нагрузки при симуляции.

Процессор:

• Минимум: 8 ядер, современная архитектура (Intel Core i7 12-го поколения или AMD Ryzen 7)
• Рекомендуется: AMD EPYC (серверного класса) или Intel Core i9 с высокой однопоточной производительностью — путь симуляции в Reth частично однопоточный, поэтому тактовая частота важнее количества ядер для критического по задержке пути.

Сеть:

• Минимум симметричное выделенное соединение со скоростью 1 Гбит/с
• 10 Гбит/с предпочтительнее для центров обработки данных с большим количеством одноранговых узлов.
• Маршрутизация с малой задержкой к точкам Equinix IX (NY4, FR2), где осуществляется обмен данными между основными сборщиками блоков и валидаторами.

Физическое расположение: co-location

Физическое расстояние между вашим узлом и строителями блоков — это минимальный уровень задержки, который вы не можете спроектировать. Скорость света в оптоволокне составляет примерно 200 000 км/с, что означает задержку 1 мс на 200 км оптоволоконного пути.

Основные целевые центры обработки данных:

• AWS us-east-1 / Equinix NY4 (Эшберн, Вирджиния) — самая большая концентрация инфраструктуры для создания блоков Ethereum в Северной Америке.
• Equinix FR2 (Франкфурт) — основной европейский строительный центр; охватывает Flashbots и большинство европейских операторов ретрансляции
• Equinix TY3 (Токио) — актуально для поисковых операций в Азии, менее критично для первичной конкуренции MEV.

Запуск вашего узла Reth в одном из этих центров обработки данных и подключение агента FRB на том же сервере полностью устраняет задержку в Интернете. Соединение WSS между FRB и Reth проходит только через петлю — фактически с нулевой задержкой.

Конфигурация узла Reth

Установите Reth из официальных бинарных выпусков по адресу github.com/paradigmxyz/reth. Проверьте контрольную сумму перед запуском.

Оптимизированная конфигурация запуска для MEV:

reth node \
  --chain mainnet \
  --http \
  --http.api "eth,net,web3,debug,txpool" \
  --ws \
  --ws.api "eth,net,web3,debug,txpool" \
  --ws.origins "*" \
  --db.map-size 4000000000000 \
  --discovery.v4 \
  --max-outbound-peers 100 \
  --max-inbound-peers 30 \
  --log.file.filter info
Copy

Описание ключевых флагов:

--http.api и --ws.api — включают txpool для подписки на события ожидающих транзакций. Это пространство имен API, которое доставляет данные мемпула. Без него вы можете запросить только состояние фиксации.

--db.map-size 4000000000000 — устанавливает размер карты памяти MDBX равным 4 ТБ в соответствии с распределением вашего диска. Это предотвращает необходимость изменения размера карты MDBX (что вызывает короткие паузы) и позволяет адресовать весь набор данных.

--max-outbound-peers 100 — больше пиров означает более быстрое распространение ожидающих транзакций из сети. Ваш узел узнает о записях мемпула быстрее, когда он подключен к большему количеству узлов.

--max-inbound-peers 30 — разрешите некоторые входящие соединения для поддержания работоспособности сети, но ограничьте их, чтобы предотвратить истощение ресурсов из-за запросов одноранговых узлов.

Подключение агента FRB к вашему узлу Reth

После полной синхронизации Reth (что занимает 6–24 часа с нуля при быстрой синхронизации архива с аппаратным обеспечением) настройте FRB для использования его в качестве основного узла.

1. В FRB Agent перейдите в Settings → Networks → Ethereum → RPC Configuration.
2. Установите для Тип узла значение Custom / Localhost.
3. Установите для Конечная точка WSS значение ws://127.0.0.1:8546.
4. Установите для Конечная точка HTTP значение http://127.0.0.1:8545.
5. Запустите встроенный тест задержки — результат должен составлять менее 2 мс для локального WSS.

Если агент FRB работает на том же сервере, что и Reth (рекомендуется для рабочей среды), весь трафик остается в режиме обратной связи. Моделирование пакетов, события подписки на мемпул и запросы состояния являются локальными — на критическом пути нет обратного прохождения через Интернет.

Если агент FRB работает на отдельном сервере в том же центре обработки данных, подключайтесь через интерфейс частной сети, а не через общедоступный IP-адрес. Благодаря этому трафик сохраняется во внутренней сети центра обработки данных (обычно 0,1–1 мс), а не маршрутизируется через общедоступный Интернет.

Брандмауэр и контроль доступа

Публично доступный узел Reth — это угроза безопасности. Настройте брандмауэр так, чтобы полностью заблокировать внешний доступ к портам 8545 и 8546:

## Allow only localhost access to RPC ports
iptables -A INPUT -s 127.0.0.1 -p tcp --dport 8545 -j ACCEPT
iptables -A INPUT -s 127.0.0.1 -p tcp --dport 8546 -j ACCEPT
iptables -A INPUT -p tcp --dport 8545 -j DROP
iptables -A INPUT -p tcp --dport 8546 -j DROP

## Keep P2P port (30303) accessible for peer discovery
iptables -A INPUT -p tcp --dport 30303 -j ACCEPT
iptables -A INPUT -p udp --dport 30303 -j ACCEPT
Copy

Также ограничьте доступ к API txpool. Подписка на мемпул — это ценный канал данных: его публичное раскрытие приглашает конкурентов использовать вашу инфраструктуру.

Мониторинг и обслуживание

Состояние синхронизации: Отслеживайте eth_syncing через конечную точку HTTP. Узел полностью работоспособен только тогда, когда он возвращает false.

Количество пиров. Всегда следите за тем, чтобы количество пиров было выше 20. Низкое количество пиров означает задержку распространения ожидающих транзакций. Если количество одноранговых узлов падает, проверьте правила брандмауэра для порта P2P 30303.

Использование диска: Проверяйте еженедельно. Состояние Ethereum растет примерно на 50–100 ГБ в месяц. При общем объеме 4 ТБ у вас есть примерно 24–36 месяцев запаса — планируйте расширение хранилища до того, как оно закончится.

Reth-версия. Обновляйте Reth, когда новые выпуски включают улучшения производительности. Проверяйте журнал изменений по адресу github.com/paradigmxyz/reth/releases ежемесячно.

Заключение

Самостоятельно размещенный узел Reth, работающий на физическом (bare-metal) оборудовании в режиме co-location, — это базовая инфраструктура для операций уровня tier-1 в Ethereum MEV в 2026 году. Сочетание производительности Reth на основе Rust, хранения состояния через MDBX и co-location рядом с крупными block builder'ами создает конфигурацию, которую общие провайдеры RPC структурно не способны повторить по задержке для критичных к скорости операций.

Агент FRB, напрямую интегрирующийся с локальной конечной точкой Reth WSS, устраняет все внешние сетевые переходы на пути выполнения MEV — от обнаружения событий до моделирования пакета и ретрансляционной отправки. См. Руководство по частному RPC Flashbots для настройки ретрансляции после запуска узла.