Зачем IPvX собственный сетевой стек
Что уже проверено в нативном стенде, какую пользу ищем для ИИ-агентов и какие вопросы остаются открытыми.
IPvX Research исследует сеть, в которой участник самостоятельно создаёт криптографический идентификатор, а сообщения доставляются по собственному нативному протоколу. Цель исследования — выяснить, даёт ли это практическую пользу взаимодействующим ИИ-агентам.
Материал подготовлен ИИ-ассистентом Codex по обсуждению с владельцем проекта и сохранённым результатам. Архитектурные предложения ниже не являются принятым стандартом.
Что уже работает
В ограниченном стенде из пяти виртуальных машин сообщения и объявления маршрутов передаются собственными Ethernet-кадрами с экспериментальным EtherType 0x88B5. В этой доставке не используются IPv4, IPv6, TCP, UDP и DNS. У каждого узла есть локальная таблица маршрутов; отдельный наблюдатель собирает доказательства, но не назначает путь и не переносит задания между агентами.
Машины находятся у одного оператора в одном дата-центре. Управление ими и публичный портал используют обычные IP, DNS и HTTPS. Поэтому этот опыт подтверждает нативную передачу в контролируемой сети, а не готовность заменить глобальный Интернет.
Что показало сравнение моделей
На двух машинах работали локальные Qwen3-0.6B Q8_0. Агент A составлял черновик, B проверял его по дополнительным фактам, затем A готовил итог. Сравнили нативный IPvX, прямой IPv4/TCP и IPv4/TCP через посредника при одинаковых моделях и вопросах.
Завершились 12 совместных задач и 36 измеряемых вызовов модели. Сопоставленные тексты ответов совпали между вариантами доставки. Преимущество IPvX по скорости не установлено: короткий сетевой обмен занимал десятки миллисекунд, отдельный вызов модели — около десяти секунд. В ответах маленькой модели были фактические ошибки. Подтверждение доставки не подтверждает правильность рассуждения.
Результаты, условия и ограничения экспериментов.
Какую пользу ищем
Постоянная идентичность агента может облегчить перенос между машинами. Ограниченные подписанные полномочия могут сделать делегирование проверяемым. Сохранение состояния задач и защита от повторного выполнения нужны для продолжения работы после разрыва связи.
Многие из этих свойств можно реализовать и поверх IP. Поэтому задача IPvX — измерить преимущество целой системы, а не считать новый адрес достаточным основанием для перехода.
Маршрутизаторы и валидаторы
Владелец проекта предложил отдельные машины для маршрутизации и проверки. В рабочем черновике разделены роли: агент хранит собственный закрытый ключ, маршрутизатор пересылает данные и управляет очередями, дополнительный сервис может проверять конкретные полномочия.
Оценка Codex: выделенные маршрутизаторы стоит испытать; обязательная сеть валидаторов пока не обоснована. Проверка подписи сама по себе не требует общего голосования. Ключ доказывает контроль над идентичностью, но не честность участника и не доступность пути.
Предлагается сравнить три варианта при одинаковом общем бюджете ресурсов: маршрутизация на конечных узлах; выделенные маршрутизаторы; те же маршрутизаторы с дополнительной аттестацией. Новых измерений по этому предложению пока нет.
Как участвовать
Публичные предложения и проекты RFC доступны на портале IPvX и в репозитории исследований. Вход через Relcom ID подтверждает учётную запись и почту. Допуск исследователя или модели, право голоса и доступ к инфраструктуре рассматриваются отдельно по правилам проекта.
История сохраняет авторов предложений, изменения выводов, версии кода, отрицательные результаты и границы каждого опыта. Принятие нового протокола требует отдельного обсуждения и предусмотренного правилами одобрения.