3. Шифрование и Проксирование: Envoy Proxy, Web3-mTLS и E2EE-изоляция
Разделение логики обнаружения и соединения (Control Plane: объявления, таблица Kademlia супер-узлов и встреча документа 02) и передачи данных (Data Plane) — это классический паттерн высоконагруженных систем. В эталонной реализации роль Data Plane выполняет интегрированный инстанс Envoy Proxy; его место может занять любая программа, дающая шифрованный канал документа 19. Это обеспечивает микросекундные задержки (latency), балансировку нагрузки L4/L7 и аппаратное ускорение шифрования, оставляя Супер-Узлам исключительно функцию «слепых маршрутизаторов».
3.1 Envoy Proxy в роли Data Plane (Sidecar Pattern)
В эталонной реализации каждый ИИ-агент (и клиент, и провайдер) разворачивается вместе с легковесным sidecar-контейнером Envoy.
Функции Envoy: Управление таймаутами, повторные попытки (retries), прерывание цепи (circuit breaking) при падении узла и поддержание persistent-соединений (keep-alive HTTP/2 и gRPC).
Динамическая конфигурация (xDS API): Envoy не использует статические конфигурационные файлы. Локальный клиент Lagrix (Control Plane) хранит адреса, которые узнаёт, — из объявлений (документ 17), при встрече и от ретрансляторов (документ 02). Как только он узнаёт новый адрес нужного Исполнителя или запасного Relay-моста, клиент по gRPC (через протоколы EDS/CDS) отправляет эти данные прямо в оперативную память Envoy. Прокси перестраивает маршруты на лету, без перезагрузки, обеспечивая нулевой downtime (Zero Downtime Routing).
3.2 Web3-Native mTLS (Взаимная аутентификация)
В корпоративных сетях (Zero Trust) стандартом безопасности является Mutual TLS (mTLS), где сервер и клиент проверяют сертификаты друг друга. В децентрализованной Web3-сети нет центральных удостоверяющих центров (Certificate Authorities, таких как Verisign). Lagrix решает это через криптографию эллиптических кривых (secp256k1).
Генерация эфемерных ключей: При запуске сессии Envoy генерирует временный TLS-сертификат (x509).
Web3-подпись: Локальный агент берет этот сертификат и подписывает его ключом кошелька своего узла — единственного кошелька, через который элементы узла платят и получают деньги (журнал, записи 22 и 39).
Криптографическое рукопожатие (Handshake):
Агент А подключается к Агенту Б.
Они обмениваются сертификатами и Web3-подписями.
Каждый извлекает публичный адрес (Ethereum Address) из подписи и проверяет, что он совпадает с кошельком узла другой стороны, записанным в сделке эскроу (документ 04, раздел 4.1).
Итог: Агенты математически доказывают свою идентичность (Identity) на транспортном уровне. Атака Man-in-the-Middle (MitM) невозможна: даже если злоумышленник перехватит IP, он не сможет подделать криптографическую подпись кошелька.
3.3 E2EE и Изоляция полезной нагрузки (Payload Blindness)
Это самый важный пункт для поддержания юридического статуса «Mere Conduit» (Нейтрального провайдера). Инфраструктура (Супер-Узлы/Relays) физически не должна иметь возможности прочитать контекст ИИ-запроса (Prompt) или ответ (Inference Result).
Используется многослойная архитектура конверта (Onion-lite routing):
Внешний слой (Транспорт): Envoy инкапсулирует пакеты в стандартный TLS 1.3 туннель до Супер-Узла. Супер-Узел видит только заголовки: IP отправителя, IP получателя, Размер пакета — ровно столько, сколько нужно, чтобы доставить пакет.
Внутренний слой (Payload E2EE): Сами данные (например, JSON с системным промптом) шифруются симметричным ключом (AES-256-GCM или ChaCha20-Poly1305). Этот ключ генерируется через протокол Диффи-Хеллмана (ECDH) исключительно между Заказчиком и Исполнителем на этапе рукопожатия.
Юридический щит: Супер-Узел, пропуская через себя трафик, оперирует зашифрованным Blob-объектом (черным ящиком). Если внутри передается незаконный или токсичный контент, владелец Супер-Узла защищен криптографией: он математически докажет в любом суде, что у него не было ключей дешифрования, а значит, он не мог осуществлять модерацию (DPI).
3.4 Обфускация метаданных (Защита от Traffic Analysis)
Даже если Супер-Узел не видит контент, злоумышленники могут анализировать размеры пакетов (Traffic Pattern Analysis). Например, короткий запрос и длинный ответ — типичный паттерн генерации текста LLM. Чтобы защитить конфиденциальность корпоративных клиентов:
Padding (Дополнение): Envoy автоматически добивает (pad) зашифрованные E2EE-пакеты случайными байтами до фиксированных размеров (например, 4KB, 16KB, 64KB).
Эффект: Для внешнего наблюдателя (и для Супер-Узла) весь проходящий трафик выглядит как абсолютно однородный поток бинарных блоков одинакового размера. Идентифицировать характер задачи (генерация видео, поиск кода или транзакционный запрос) становится невозможным.
3.5 Ключи разговоров H2H и сделок A2A (журнал, запись 33)
H2H — MLS (IETF RFC 9420). Разговоры людей шифруются по открытому стандарту MLS: ключ меняется с каждым сообщением, поэтому ключ, украденный сегодня, не открывает вчерашнюю переписку, а после следующего обновления ключей — и будущую. Публичный ключевой пакет узла подписан кошельком узла: собеседник проверяет подпись и знает, с владельцем какого кошелька говорит. Супер-узел служит службой доставки: хранит только публичные ключевые пакеты, пересылает и держит зашифрованные сообщения — текст до 64 КБ, для адресата не в сети до 30 дней и не больше 1 МБ на адресата; закрытых ключей у него нет. Переписка не пишется в блокчейн никогда.
Вложения (журнал, запись 52). Файл через супер-узел не идёт никогда. Отправитель шифрует его случайным ключом, хранит на своём узле или в хранилище, которое выбрал, и кладёт в сообщение MLS имя, размер и тип файла, адрес для скачивания, который нельзя угадать и у которого есть срок, ключ и хэш файла. Открыть файл может только получатель, а хэш показывает, что файл не меняли после отправки.
A2A — одноразовый ключ сессии. Ключ сделки создаётся при рукопожатии (ECDH, раздел 3.3) и удаляется, когда сессия кончилась.