BCP 0.2
Идентичность узла, разрешённый путь и пакет — из проверяемого состояния реестра.
Состояние разработки
BCP 0.2 — пакетный слой и реестр IPvX. Контракты реестра проверены на живой цепочке Sepolia: REG-001 шёл в режиме чтения Q, а R1 закрыт 2026-11-06 чтением REG-001-LC через лёгкий клиент — по заменённому критерию, текущему состоянию; значения S1–S3 остаются наблюдениями режима Q. Доставка пакетов по реестру прошла на тестовом состоянии реестра (NET-001-F, PASS 2026-11-08); на живом состоянии (NET-001-L) она ещё не запускалась.
Снимок состояния:
Реализовано в коде
Формат пакетов, NodeRegistry, TransitPolicy, ConnectionPolicy, EL/CL-адаптер и связь с ядром. Чтения контрактов привязаны к одному финализированному blockHash.
Проверено офлайн
93 теста runner и 14 проверок плана. Временные ключи, EVM в памяти, синтетические заголовки и memory ports; это не измерение сети или финальности цепочки.
Следующий сетевой опыт
NET-001-F прошёл 2026-11-08 на отдельной ВМ стенда: прогон bcp-net001-run-0003 по подписанному владельцем разрешению дал PASS во всех 14 вариантах проверок, независимый верификатор подтвердил итог. Это доставка кадров Ethernet между тремя узлами на настоящем ядре Linux при синтетическом состоянии реестра: финальность цепочки, физическая линия и независимые операторы этим не проверены. Следующий опыт — NET-001-L на живом состоянии реестра. Он читает реестр через лёгкий клиент Helios: режим LC заменил режим V 2026-11-05, собственный узел Sepolia не нужен. Helios на стенде пока не работает, а правило обновления снимка в NET-001-L остаётся открытым условием. Допуск к новому запуску закрыт: каждый прогон требует отдельного подписанного разрешения владельца.
Что меняет BCP
Идентичность
NodeRegistry связывает NFT-идентификатор узла с владельцем и ключами. Самостоятельно созданный ключ ещё не даёт права участвовать.
Разрешённый путь
TransitPolicy и ConnectionPolicy задают допустимые переходы и соединения. Узел проверяет путь по закреплённому состоянию; блокчейн не заменяет канал передачи кадров.
Формирование пакета
Идентификаторы, checkpoint, путь, подписи и зашифрованные данные получают точный двоичный формат. MAC указывает ближайшего соседа, идентификатор — конечный узел.
Данные до допуска
Набор данных готовится отдельно. Подписанный допуск закрепляет его хеш, хеш всего пакета, run ID, время создания и срок свежести. Runner не создаёт новый набор после разрешения.
Свежесть — не более 30 минут; фактический срок ограничен самым ранним свежим checkpoint. Истёкший набор нельзя продлить копированием или повторным запуском.
Формат допуска и ограничения
dataset_sha256 · bundle_sha256 · run_id · created_at · expires_at
Границы доказательств
Первый опыт, NET-001-F, прошёл на одной Linux-ВМ: пространства имён A–R–B и два veth-канала. Живой блокчейн, открытое присоединение, физическая Ethernet-подложка и преимущество над IP этим не подтверждены.
Mesh — отдельный эксперимент
Исторический стенд проверяет подписанную доставку и смену маршрута у заранее допущенных узлов. Это не реализация блокчейн-реестра BCP. Все его журналы, захваты и прежние выводы сохраняются.
Открыть Mesh и его доказательства · Записанный strict-LLM-опыт
Mesh: Ethernet-обмен
Заранее допущенные узлы выбирают следующий переход. Задания и маршруты передаются в Ethernet-кадрах.
- Стенд
- живой mesh, 5 ВМ на 3 физических хостах
- Кадры
EtherType 0x88B5- Агенты
- синтетические, без LLM
- Оператор
- один
- Управление
- по административному IP
- Связь с BCP
- отдельный прототип · BCP 0.2 и его допуск →
Подключаемся к подписанным журналам…
Отключать узлы могут только операторы стенда. Здесь показана ограниченная выборка подписанных записей, а не полный журнал сети.
Ожидаем сообщения
Путь появится после сверки журналов отправителя, получателя и посредников.
Хронология сети
Хронология собирается в этой вкладке; локальная история хранится не более 15 минут.
Каждая точка — сообщение, сверенное по подписанным журналам всех узлов пути. Время взято из журналов самих узлов. Наблюдатель отдаёт последние 24 доставки. Вкладка сохраняет увиденные записи не более 15 минут; на графике видны последние 3 минуты. Закрытие вкладки теряет эту локальную историю. Подписи проверяют показанные переходы, но не полноту журнала. Нажмите на точку, чтобы разобрать сообщение.
Что вызвало что
Цепочка последнего отключения из подписанных записей. Нажмите на шаг, чтобы открыть запись или сообщение. Время — от записи об отключении, по часам самих узлов.
Доставленные сообщения
Кто выбирает маршрут
Каждая строка — решение самого узла из его подписанного журнала. Общего диспетчера нет.
Как сеть пережила сбой
Что проверено на настоящих машинах
Чем этот эксперимент отличается от обычного интернета?
получается из публичного ключа. Его не выдаёт регистратор; получатель остаётся тем же на всём пути.
Соседи обмениваются подписанными объявлениями: это . Узел выбирает самый короткий доступный путь; старые сведения о пропавшем соседе истекают.
Собственные кадры с типом 0x88B5 передаются через Ethernet. В данных и объявлениях маршрутов нет IPv4, IPv6, TCP, UDP и DNS. указывает только следующего соседа.
ОС этих ВМ сохраняют административный IP. SSH и страница наблюдения используют IP. Они нужны оператору; агенты продолжают обмен при отключённой панели.
Это пять заранее допущенных ВМ на трёх физических хостах, у одного оператора и в одном дата-центре. В гостях наблюдаются кадры Ethernet; конфигурация подложки между гипервизорами отдельно не подтверждена. Блокчейн-реестр и политики BCP в этом Mesh не реализованы. Это отдельный режим: записанный strict-LLM-опыт использует три гостя на трёх хостах, две локальные модели и ядра гостей без INET/IPv6. Здесь работают синтетические агенты без LLM. Версия живого стенда указана в подвале страницы; дата сохранённой приёмки — в разделе «Что проверено на настоящих машинах». Мы проверяем собственную доставку и маршрутизацию, но пока не глобальную сеть, автоматический допуск незнакомых узлов или устойчивость к перегрузке.
A и B сохраняют ключи предыдущего этапа. R1 отключает настоящий канал передачи на 60 секунд; служебное управление остаётся доступным, затем канал включается автоматически. Прямой путь A↔B запрещён правилами гостевых машин.
Задачи в большой сети
Что уже доставлено настоящими кадрами — и где текущая архитектура упирается в масштаб.
- Документы
- реальные
- Агенты
- программные, без языковой модели
- Оператор
- один
- Где измерено
- отдельный опыт на VM проекта Relcom
- Измерение и расчёт
- показаны раздельно
- Данные
- сохранённые результаты · пять действующих машин — в живом стенде
Загружаем отчёты выполненных испытаний…
16 агентов выполняют вашу задачу Измерено
Каждый круг — отдельный процесс с собственным ключом и таблицей маршрутов. 16 процессов работают на одной физической машине в изолированной сети без IP. Выделенная линия — подтверждённый путь задания. Одинаковые метки Г… или В… на противоположных краях обозначают один переход между крайними соседями, минуя промежуточные узлы.
Сколько ждали задания
Источник графика: измеренный запуск на VM Relcom; обработка двух публичных статей. Каждая точка — число полученных правильных результатов.
Внесены задержка 4 ± 1 мс, потеря 0,02% кадров и отключение настоящего канала N05 примерно на 10 секунд. Первый запуск выявил автоматический IPv6-адрес на мосту и не прошёл проверку. Он сохранён отдельно. Второй опыт выявил служебный моста и два отказа из-за ошибки срока задания. После исправлений проведён новый запуск; оба предыдущих результата сохранены.
До 2 048 агентов: расчёт возможной сети Моделирование
Это симуляция, а не 2 048 запущенных агентов. За каждым модельным маршрутизатором находятся восемь логических агентов. Нагрузка, потери, полоса и очереди заданы явно; результаты не обещают такую же скорость в реальной сети.
Все 36 расчётов
Доля выполненных заданий со временем: строка — условия, столбец — размер сети, три линии — три . Пунктир — лимит 60 секунд. Нажмите на клетку, чтобы открыть расчёт ниже. Сейчас протокол работает максимум на 16 узлах и 7 переходах, поэтому 64 и 256 — расчёт для версии, которой ещё нет.
Каждый узел принимает следующее решение по своей таблице. Таблицы получены обменом соседей; центральный сервис маршрутов не используется. Выделенный путь взят из завершённого расчёта. Одинаковые метки Г… или В… у противоположных краёв — один переход между крайними соседями.
Самый важный вывод: простое расширение списка ключевых ID не делает протокол глобальным. Нужны компактные маршрутные объявления, отдельное обнаружение сервисов, управление перегрузкой и проверка на независимых сетях. Симуляция показывает цену этих ограничений, а не устраняет их.
А другие агенты уже перешли? Обзор источников
Внешних операторов опрошено: 0. Получены два отдельных заключения изолированных агентов Codex в том же сервисе. Они не видят транспорт своего исполнения и не могут подтвердить переход на IPvX. Доступного внешнего узла с проверяемой телеметрией не найдено.
Ниже — проверенные первичные документы на 27 октября 2026 года. Это обзор протоколов, не статистика внедрений. Подтверждений массового перехода ИИ на native-сеть без IP в этом обзоре нет.
Подписанные доказательства
Каждый этап — бандл. Бандлы подписаны ключом лаборатории и записаны в журнал Меркла.
- Бандл
- файлы отчётов с SHA-256, коммит релиза и ассеты GitHub
- Подпись
- ключ лаборатории
- Журнал
- дерево Меркла
- Кто проверяет
- ваш браузер, а не сервер
Загружаем журнал и проверяем подписи…
Что это доказывает и чего нет
Доказывает целостность и порядок: бандл нельзя изменить, убрать или переставить, не сломав подпись или доказательство согласованности. Тот, кто сохранил прежнюю вершину журнала, увидит любую переписанную историю.
Не доказывает независимое время и независимого свидетеля: ключ и журнал в руках одной лаборатории, даты — её собственное заявление. Следующий шаг — фиксировать вершины там, где лаборатория ничего не контролирует; это же сравнение журнала с блокчейном для H11.
Проверить файлы самостоятельно
Браузер не скачивает сами отчёты. Команда в клоне репозитория проверяет подписи, дерево и SHA-256 каждого файла:
python -m ipvx_agent_lab.evidence verify
Два агента. Прямой обмен.
Каждый агент живёт на своей машине и сам отправляет сообщения собеседнику. ID остаётся прежним при смене IP.
- Этап
- 2 · закрыт: на этих машинах работает следующий этап · открыть сеть без IP
- Сеть
- реальный TCP/IP · внутренняя сеть стенда
- Имена
- DNS выключен у агентов
- Данные
- синтетические
- Агенты
- программные, без языковой модели
- Машины
- две VM на разных физических хостах · один оператор
Агенты и доставка
Ожидаем подтверждение доставкиПрямое соединение по TCP · внутренняя сеть стенда · коммутируемый участок
Наблюдатель на третьем физическом хосте читает подписанные журналы обеих VM. Сообщения между агентами через него не проходят.
Доставленные сообщения
Показаны сообщения с совпавшими записями обеих сторон. Выберите строку для проверки пути.
Адреса и события
Проверки на двух машинах
Кто прокладывает маршрут, если агентов много?
ID отвечает на вопрос «кто», IP — «где»
В этом эксперименте A заранее знает публичный ID и первый адрес B. Когда B меняет адрес, он подписывает новую запись и сам отправляет её A. A проверяет подпись и версию, сохраняет новый адрес и открывает прямое соединение.
На большом масштабе начальный поиск можно распределить между многими узлами. Они хранят части каталога ID → адреса с копиями и кешами. Поиск нужен перед соединением или после потери адреса, а не для каждого сообщения. Такая система поиска пока не реализована в этом прямом пилоте.
Пакеты доставляет существующая IP-сеть. Её маршрутизаторы работают с префиксами сетей; им не нужна отдельная запись для каждого агента. Очереди, лимиты запросов и реплики агентов решают другую задачу — перегрузку вычислений.
Отказ от IP означал бы разработку собственной сети маршрутизации. Сейчас мы проверяем независимый ID и прямой обмен поверх TCP/IP. Если оба агента одновременно потеряют все известные адреса друг друга, восстановление в этом этапе не предусмотрено.
Границы опыта
Две VM на разных физических хостах · один оператор и дата-центр. Переезд переключает слушающий IP внутри одной VM; управление остаётся на прежнем адресе. Кнопка запускает только смену адреса, уведомление собеседника выполняет сам агент.
Интернет для агентов
Агент находит данные, получает ограниченные права и передаёт задачу аналитику. Наблюдайте ход задачи и причины решений.
- Этап
- 1 · в архиве этапов · текущая работа: BCP 0.2
- Данные
- синтетические
- Оператор
- один
- Агенты
- программные, без языковой модели
- Запуск
- только операторы стенда · показан последний сохранённый
Путь задачи
События реального запуска
Владелец задачи
Личный агент
Три резолвера
Источник данных · MCP
Аналитик · A2A
Новая точка подключения
ID отвечает на вопрос «кто?». Резолвер — «где сейчас?». Разрешение — «что ему можно?».
Журнал событий
0 событийСобытия появятся после запуска. Каждая строка открывает объяснение и наблюдаемые данные.
Что проверяем
Сохранение ID при переезде, проверку подписей, границы прав и поведение при сбоях.
Гипотезы и доказательства
Вердикт относится к конкретному запуску. Частичный результат оставляет открытые вопросы.
- Этап
- 1 · в архиве этапов · текущая работа: BCP 0.2
- Источник
- последний сохранённый запуск стенда /1
- Адрес гипотезы
#hypotheses/H5
Итог запуска
Все гипотезы
Подключить своего агента
Клиентская библиотека Python разрешает подписанный ID через три резолвера, проверяет запись и сохраняет известную версию. Доступ к данным требует отдельного разрешения владельца.
- Этап
- 1 · в архиве этапов · текущая работа: BCP 0.2
- Язык
- Python
- Доверие
- задаёт оператор, не библиотека
Локальный запуск
git clone https://github.com/relcom-technologies/ipvx-agent-lab cd ipvx-agent-lab python3 -m venv .venv source .venv/bin/activate pip install -e '.[test]' ipvx-lab local
Откройте http://127.0.0.1:8080. Команда поднимает семь отдельных процессов. Установка из закрытого репозитория требует доступа к GitHub.
Вызов из Python
from ipvx_agent_lab import AgentClient, invocation
with AgentClient(
resolver_urls, # три адреса резолверов
checkpoints={agent_id: (2, 3)},
state_file=".state/known-versions.json",
allowed_origins={"https://your-agent.example"},
) as client:
profile = client.resolve(agent_id)
result = client.invoke(
profile,
invocation(permission_chain, subject_key, "read"),
)Адреса резолверов, доверенная начальная версия, разрешённые узлы и цепочка прав задаются оператором. Библиотека не решает за владельца, кому доверять.
Проверить автоматически
ipvx-lab run --scenario full --output reports/full.json pytest -q
Экспериментальный протокол
Версия 1 · утверждён владельцем проекта 26 октября 2026 года.
- Этап
- 1 · в архиве этапов · текущая работа: BCP 0.2
- Основа IPvX
218bf93
Что работает на стенде
Локальная генерация ID, подписанный профиль, поиск по способности, двух из трёх резолверов, узкие разрешения и защита от повторного выполнения. Переезд меняет точку подключения и сохраняет идентичность.
Что считается доказательством
Сценарии отправляют HTTP-запросы отдельным процессам. Каждая проверка сохраняет условие, наблюдаемый результат и время. Записи SQLite и выгружаемые отчёты сохраняются после перезапуска.
Границы эксперимента
- Один физический хост и один оператор. Отдельные процессы не доказывают независимость операторов.
- Агенты выполняют заданные правила на синтетических данных. Языковая модель не подключена.
- MCP 2025-06-18 и A2A 0.3.0: проверяются ограниченные адаптеры. Совместимость с внешними реализациями ещё не сертифицирована.
- Первый контакт требует свежей точки доверия. Подпись сама по себе не гарантирует свежесть и качество результата.
- При недоступности источника отзыва разрешено окно кэша до 3 секунд; затем отказ. Изменение часов — явно внедряемый логический сбой.
- Блокчейн и внедрение внешними командами пока не проверены.
Зафиксированная основа IPvX
218bf93acb842604167c93144e5bc967b70ecb6aПравило кворума взято из этой версии. Профили агентов и разрешения — новый экспериментальный протокол.
Прочитать полный протокол ↗