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-опыт
Вопросы и идеи по BCP
Обсуждение BCP идёт на форуме участников; предложения изменить документ — через RFC и GitHub.
Открыть раздел BCP на форуме