1. Сетевая топология: Kademlia DHT, Node ID и Алгоритмы Маршрутизации
В основе децентрализованного транспортного движка Lagrix лежит модифицированный протокол Kademlia. Стандартная реализация Kademlia уязвима к атакам Сивиллы, поэтому наша архитектура жестко связывает P2P-идентификаторы с зарегистрированными местами супер-узлов. Место стоит года оплаченной работы, и это создает настоящий барьер для входа в таблицу маршрутизации.
1.1 Генерация Node ID и Криптоэкономическая привязка
В классических P2P-сетях (например, BitTorrent) узлы генерируют случайные 160-битные или 256-битные идентификаторы. В Lagrix это строго запрещено.
Идентификатор Супер-Узла (NodeID) детерминированно вычисляется из публичного ключа кошелька (Ethereum/EVM-совместимого), с которого место зарегистрировано в смарт-контракте SuperNodeRegistry.sol.
Формула: $NodeID = \text{SHA3-256}(PublicKey_{EVM})$
Валидация при рукопожатии (Handshake): Когда Узел А пытается подключиться к Узлу Б, он отправляет свой NodeID и криптографическую подпись, доказывающую владение приватным ключом. Узел Б берет публичный ключ, делает запрос к RPC ноде блокчейна и проверяет, что этот адрес — действующий супер-узел: он вошёл по документу 05, раздел 5.6 (место, полученное случайным выбором и зарегистрированное в контракте), и не несёт отметки «доказанное нарушение» (документ 06): isActiveSuperNode(PublicKey) == true.
Итог: Если адрес не действующий супер-узел, соединение мгновенно сбрасывается на уровне сокета. Злоумышленник не может наполнить сеть миллионом фейковых NodeID, так как для каждого нужен настоящий вход: место, полученное случайным выбором среди владельцев агентов-исполнителей с годом оплаченной работы, и сервер, прошедший проверку.
1.2 Математика маршрутизации (XOR-метрика)
Маршрутизация между супер-узлами опирается на вычисление логического исключающего ИЛИ (XOR) между идентификаторами. Это позволяет определить «расстояние» между узлами в виртуальном 256-битном пространстве.
Дистанция: $d(x, y) = x \oplus y$
Свойства: XOR-метрика симметрична ($d(x,y) = d(y,x)$) и отвечает неравенству треугольника. Это означает, что поиск среди супер-узлов всегда сходится за логарифмическое время $\mathcal{O}(\log N)$, где $N$ — количество Супер-Узлов в сети.
Практика: Если супер-узлу нужно найти узел с ID 0xABCD..., он ищет в своей локальной таблице узлы, чей XOR с целью минимален, и перенаправляет запрос им.
1.3 Таблицы маршрутизации (K-Buckets)
Каждый Супер-Узел поддерживает локальную таблицу маршрутизации, разделенную на корзины (k-buckets). В 256-битном пространстве существует 256 корзин.
Параметр $k$: Каждая корзина хранит максимум $k=20$ активных узлов. Это обеспечивает достаточную избыточность (если 19 узлов упадут, 1 останется доступен).
Политика вытеснения (Eviction): Kademlia отдает предпочтение «старым» узлам. Если корзина заполнена, новый узел помещается в буфер ожидания. Существующим узлам отправляется PING. Если кто-то не ответил (тайм-аут 500 мс), он удаляется, а новый узел занимает его место. Это защищает топологию от DDoS-атак, направленных на вытеснение честных узлов из таблиц.
1.4 Жизненный цикл P2P-сообщений (RPC методы)
Взаимодействие внутри транспортного кольца строится на 4 базовых бинарных UDP-сообщениях:
| RPC Метод | Назначение в архитектуре Lagrix |
|---|---|
| PING | Проверка жизнеспособности узла. Используется для поддержки актуальности k-buckets. |
| STORE | Запись на $k$ ближайших супер-узлах — записи собственной маршрутизации супер-узлов. Адрес, карточка и ключ шифрования агента в DHT не хранятся: они идут в его подписанном объявлении (документ 17, раздел 17.1). |
| FIND_NODE | Запрос списка из $k$ узлов, наиболее близких к искомому ID. Используется для построения карты сети. |
| FIND_VALUE | Чтение такой записи. Агента находят по его объявлению и индексу супер-узлов, а не через DHT (документ 17). |
1.5 Интеграция с локальным Data Plane (Envoy)
В эталонной реализации роль Control Plane выполняют модуль Kademlia и код обнаружения клиента. Он не гоняет сами гигабайты данных между ИИ-агентами.
Как только клиент знает адрес целевого агента — из его объявления (документ 17), а за роутером ещё и при встрече через супер-узел (документ 02), — эта информация мгновенно передается по локальному gRPC-каналу (xDS API) в Envoy Proxy, который уже открывает высокоскоростной mTLS туннель для передачи полезной нагрузки. Это разделение логики (Discovery отдельно, Data Streaming отдельно) позволяет достичь микросекундных задержек, сопоставимых с лучшими Web2-балансировщиками. Узел может использовать любой другой транспорт, дающий шифрованный канал документа 19.