Ethereum Portal Network — это проект по созданию новой, лёгкой P2P-сети данных для Ethereum (ETH), ориентированной на «ультралёгкие» клиенты: мобильные кошельки, браузерные расширения, встраиваемые устройства. В отличие от классической p2p-сети узлов, Portal Network строится как набор тематических «портальных» сетей (history, state, транзакции), где каждый узел хранит лишь небольшой фрагмент данных, но при этом сеть в целом остаётся способной обслуживать запросы любого клиента.
Portal Network тесно связан с задачами масштабирования доступа к данным, переходом к stateless-клиентам и идеями «исторического экспайри» (EIP-4444) в дорожной карте архитектуры Ethereum.
Зачем Ethereum нужен Portal Network
Классический full-node Ethereum:
- хранит полную историю блоков и значительную часть состояния;
- обслуживает RPC-запросы кошельков и dApp;
- требует десятки/сотни гигабайт диска и постоянную синхронизацию.
Это создаёт несколько проблем:
- запуск и поддержка полного узла становится слишком тяжёлой задачей для обычных пользователей;
- мобильные и браузерные кошельки вынуждены доверять централизованным RPC-провайдерам;
- в дорожной карте (EIP-4444 и далее) предполагается, что многие узлы перестанут хранить старую историю локально.
Portal Network отвечает на эти вызовы:
- децентрализованно распределяет историю и части состояния между множеством лёгких узлов;
- даёт возможность кошелькам и приложениям получать проверяемые данные напрямую из p2p-сети;
- готовит инфраструктуру для эпохи stateless-клиентов и новых подходов к доступности данных.
Общая архитектура Portal Network
Portal Network — это не одна сеть, а набор перекрывающихся overlay-сетей, каждая из которых отвечает за свой тип данных:
- History Network.
Распределённое хранение заголовков блоков, тел блоков и другой исторической информации.
- State Network.
Доступ к частям состояния (accounts/storage), доказательствам Merkle/Verkle и свидетелям, необходимым для stateless-исполнения.
- Transaction / Gossip Network.
Пересылка транзакций и связанной информации между лёгкими клиентами.
- (Дополнительно могут рассматриваться специальные сети для индексов, light-header-цепочек и т.п.)
Общий принцип:
- каждый узел хранит небольшой подмножество ключей/фрагментов данных (content);
- адресация идёт по контент-ключам, а не по IP/узлам;
- поиск и маршрутизация запросов строятся поверх протокола discovery v5 (discv5).
Таким образом, Portal Network — это слой, который превращает множество «маленьких» узлов с ограниченным диском в коллективный распределённый «архивный» ресурс.
Ключевые идеи и технологии
Основные технические идеи Portal Network:
- discv5 и overlay-сети.
Сеть использует протокол обнаружения узлов discv5 как базу для построения DHT-подобных overlay-сетей. Разные «порталы» (history, state, tx) реализуются как отдельные оверлеи с собственной логикой и пространством ключей.
- Контент-адресация.
Данные идентифицируются по хэш-ключу (content key / content ID). Узлы объявляют, какой контент (какие ключи) они хранят, и по этому ключу их можно найти.
- Фрагментация и репликация.
Вместо полного дублирования истории и состояния на каждом узле, данные фрагментируются и реплицируются по сети. Конкретная политика репликации и retention может отличаться в разных порталах.
- Минимальные требования к ресурсу.
Узел Portal Network можно запускать на слабых устройствах: небольшая база данных, ограниченный трафик, отсутствие необходимости держать весь Merkle Patricia Trie или крупные индексы локально.
- Верифицируемость данных.
Клиент должен иметь возможность проверить корректность полученных данных (через заголовки, Merkle/Verkle-доказательства и т.д.), опираясь на корни состояния и цепочку, зафиксированную в «нормальной» сети Ethereum.
Историческая сеть (History Network)
History Network предназначена для хранения:
- заголовков блоков (headers);
- тел блоков (bodies, транзакции);
- вспомогательных структур (например, индексов).
Контекст:
- в рамках EIP-4444 и похожих инициатив обсуждается «исторический экспайри» — возможность для полноценных узлов удалять старую историю после заданного периода;
- при этом исследователям, индексерам и кошелькам всё равно нужен доступ к старым данным.
Задача History Network:
- распределить старые блоки и связанные данные по множеству узлов Portal Network;
- позволить лёгкому клиенту по запросу получать нужные части истории и проверять их на корректность.
Это снижает нагрузку на «основную» p2p-сеть Ethereum и делает доступ к истории более устойчивым и децентрализованным.
Сетевая для состояния (State Network) и stateless-клиенты
State Network — наиболее амбициозный компонент Portal Network:
- она должна предоставлять доступ к фрагментам состояния (аккаунты, storage-слоты) и соответствующим доказательствам;
- цель — позволить клиентам, не хранящим состояние (stateless-клиентам), выполнять транзакции, имея только свидетели состояния.
Связь с дорожной картой Ethereum:
- переход от Merkle Patricia Trie к новым структурам (Verkle-деревья, коммитменты — см. Verkle-деревья и KZG-коммитменты);
- планы по stateless execution и снижению требований к диску у валидаторов и пользователей.
State Network должна стать распределённым источником свидетелей, чтобы:
- лёгкий клиент мог запросить состояние конкретного аккаунта/контракта;
- получить компактное доказательство корректности;
- проверить его относительно корня состояния из цепочки заголовков.
Транзакционная и вспомогательные сети
В дополнение к history/state Portal Network проектирует транзакционные и другие оверлеи:
- Transaction / Gossip Network.
Распространение транзакций между лёгкими клиентами и узлами, без необходимости подключаться к «тяжёлым» full-nodes.
- Header / Light-chain сети.
Специализированные оверлеи для быстрой синхронизации по заголовкам блоков и light-цепочкам.
Такие сети:
- снижают нагрузку на базовый p2p-уровень;
- дают кошелькам возможность «видеть» mempool и цепочку без привязки к одному RPC-провайдеру;
- готовят инфраструктуру для более гибких и частично оффчейн-решений.
Реализации и статус проекта
Portal Network — это не один клиент, а семейство реализаций и спецификаций. В экосистеме развиваются:
- отдельные реализации портальных узлов (на Rust, Go, других языках);
- спецификации overlay-сетей, типов контента, форматов ключей;
- инструменты для интеграции с кошельками и лёгкими клиентами.
С точки зрения дорожной карты Ethereum Portal Network:
- не заменяет существующие full-nodes и архивные узлы;
- создаёт дополнительный слой для массовых лёгких клиентов и будущих stateless-решений;
- связан с направлениями «The Verge / The Purge / The Splurge» в долгосрочной эволюции протокола.
Значение Portal Network для децентрализации Ethereum
Portal Network важен сразу на нескольких уровнях:
- Децентрализация доступа к данным.
Кошельки и приложения смогут получать данные напрямую из p2p-сети, не полагаясь только на крупные RPC-сервисы.
- Снижение барьеров для запуска узлов.
Пользователи с ограниченными ресурсами смогут участвовать в хранении и распространении данных, не поднимая full-node.
- Подготовка к stateless-будущему.
Для реализации stateless-клиентов и агрессивного уменьшения нагрузки на диски валидаторов нужен распределённый источник свидетелей — Portal Network претендует на эту роль.
- Устойчивость к цензуре и сбоям инфраструктуры.
Чем больше разных способов получить корректные данные об Ethereum (через Portal, full-nodes, архивные сервисы), тем лучше сеть переносит локальные сбои и атаки.