Канонический стандарт сети STN™

1. Предмет и область применения

1.1. Назначение стандарта

Настоящий стандарт устанавливает:

• Единые требования к архитектуре сети распределенного доверия STN.
• Протоколы криптографической верификации узлов и активов.
• Правила идентификации участников сети через децентрализованные идентификаторы (DID).
• Регламенты признания верифицированных цифровых активов в качестве Нематериальных Активов (НМА) по ФСБУ 14/2022 и IAS 38.
• Порядок взаимодействия между участниками сети (Лицензиарами, Лицензиатами, Мета-узлами).

1.2. Область применения

Стандарт обязателен для исполнения всеми участниками сети STN:

• Корневым узлом (Root Authority).
• Головным Лицензиаром (Head Licensor, DAT-H).
• Мастер-Лицензиарами (Master Licensors, DAT-M).
• Уполномоченными Лицензиарами (Authorized Licensors, DAT-A).
• Операторами Мета-узлов.
• Лицензиатами (владельцами Базовых узлов и Т-узлов).
• Внешними партнёрами, использующими реестр анкоров.

1.3. Нормативные ссылки

Настоящий стандарт разработан в соответствии со следующими документами:

1. Спецификация SOLPDT 1.0 (E-E-A-T 2.0) — https://solpdt.com/specification-v1-0-1.
2. Спецификация SOLPDT 1.1 (Agentic Trust Layer Extension) — https://solpdt.com/specification-v1-1.
3. Приложение O (Иерархия ролей и типы DAT) — https://solpdt.com/appendix-o-v1-1.
4. Приложение P (Гибридная архитектура реестров и ZKP) — https://solpdt.com/appendix-p-v1-1.
5. Глоссарий SOL Trust Network — https://solpdt.com/glossary.
6. W3C DID Core 1.0 — https://www.w3.org/TR/did-core/.
7. RFC 8785 (JSON Canonicalization Scheme, JCS).
8. ФСБУ 14/2022 «Нематериальные активы».
9. IAS 38 «Intangible Assets».

2. Термины и определения (Глоссарий)

Все термины, используемые в настоящем стандарте, имеют формальные определения, приведённые в глоссарии https://sol-trust.net/glossary. Ниже приведены ключевые определения для целей стандарта.

Архитектурный Уровень (Level): Иерархический ранг узла в глобальной сети STN, определяющий его методологические, юридические и эмиссионные полномочия. Уровни от 0 до 3.

Базовый узел (Base Node): Сайт или раздел, не имеющий Т-слоёв (страниц с экспертным контентом). Содержит только базовую верификацию (TrustGraphAnchor на главной странице). Не является НМА. Соответствует Архитектурному Уровню 3.

Головной Лицензиар (Head Licensor, DAT-H): Юридическое лицо, обладающее DAT-H. Является операционным и юридическим центром сети. Выдаёт DAT-M и DAT-A. Несёт экономическую ответственность за аккредитацию узлов. Соответствует Архитектурному Уровню 1.

Децентрализованный идентификатор (DID): Уникальный криптографический идентификатор, соответствующий стандарту W3C DID Core 1.0. Формат: did:web:[domain]. Обеспечивает идентификацию и верификацию участника сети.

Контур I (Infrastructure): Операционный контур сети. Отвечает за вычислительную среду, криптографический консенсус, хэширование SHA3-256, подписание Ed25519, обеспечение SLA и инфраструктурный комплаенс.

Контур V (Verification): Валидационный контур сети. Отвечает за семантическую экспертизу, аудит E-E-A-T 2.0, выпуск Цифровых паспортов активов и экономическую оценку. Валидация осуществляется децентрализованно — каждым Лицензиаром для своих Лицензиатов.

Корневой узел (Root Authority): Автор методологии FEBA/SOL. Выдаёт DAT-H Головному Лицензиару. Ведёт корневой реестр аккредитаций. Не участвует в операционной верификации. Соответствует Архитектурному Уровню 0.

Мастер-Лицензиар (Master Licensor, DAT-M): Лицензиар, уполномоченный заверять только SOL-Активы (.solpdt) юридических лиц в рамках стандарта v1.0. Не имеет права выдавать sig.a для ИИ-агентов. Соответствует Архитектурному Уровню 2.

Мета-узел (Meta-Node): Частный случай Т-узла, который дополнительно содержит локальный словарь (/ns) и реестр анкоров (/anchor-registry). Может создаваться Лицензиаром или Лицензиатом. Соответствует Архитектурному Уровню 2.

Пакет комплаенса SOL-1/SOL-2/SOL-3: Уровень глубины верификации узла. Определяет набор обязательных маркеров, права на капитализацию как НМА и стоимость обслуживания.

Семантический круг (Круг 1, 2, 3): Уровень глубины пользовательского запроса, который закрывает узел. Определяет стратегическую роль узла и требования к контенту.

Т-узел (Trust Triad Node): Сайт или раздел, имеющий хотя бы один Т-слой (страницу с экспертным контентом). Содержит TrustGraphAnchor и sol:assetId. Подлежит капитализации как НМА. Соответствует Архитектурному Уровню 2.

Технический Слой (Layer): Глубина периферии (иерархия URL) в рамках архитектуры «Звезда» конкретного веб-ресурса. Слои от 0 (главная страница) до 3 (периферийные Т-страницы).

Уполномоченный Лицензиар (Authorized Licensor, DAT-A): Лицензиар, уполномоченный выдавать только Authoritative Attestation (sig.a) для ИИ-агентов в рамках стандарта v1.1. Не имеет права заверять бизнес-активы. Соответствует Архитектурному Уровню 2.

Цифровой допуск (DAT-H, DAT-M, DAT-A): Непередаваемый токен аккредитации, подтверждающий полномочия участника сети. Эмитируется вышестоящим узлом. Классификация и права держателей описаны в Приложении O.

Цифровой паспорт актива (Digital Asset Passport): Набор свойств в TrustGraphAnchor (sol:assetId, sol:complianceStatus, sol:febaScore, sol:expertiseLevel, sol:ownerDid), однозначно идентифицирующий узел и подтверждающий его статус.

3. Архитектурная топология сети

Подробное описание архитектурных уровней, ролей и правил симметрии графа приведено в Приложении 1 (Топология сети STN). Ниже приведены основные положения.

3.1. Иерархия узлов

Сеть STN представляет собой четырёхуровневую иерархическую структуру, построенную по принципу делегированного доверия (как в PKI/SSL).

Уровень 0: Корневой авторский контур (Root Authority)

• Субъект: Юрий Соколов (Создатель стандарта).
• Идентификация: did:web:sokolov-risk.com.
• Ключевое право: Выдача DAT-H Головному Лицензиару. Ведение корневого реестра аккредитаций.
• Ограничения: Не участвует в операционной верификации.
• Контрольная точка: Self-Signed Root Certificate. DID предустановлен в Trust Store всех валидаторов.

Уровень 1: Главный сетевой хаб (Global Network Hub)

• Субъект: Головной Лицензиар (держатель DAT-H).
• Идентификация: did:web:skylinerisk.ru (Юридический центр), did:web:sol-trust.net (Технический центр).
• Ключевое право: Полный спектр прав по v1.0 и v1.1. Выдача DAT-M и DAT-A. Ведение реестра статусов (TRL).
• Ограничения: DAT-H выдается исключительно Корневым узлом. Подлежит отзыву при нарушении методологии.
• Контрольная точка: Поле controller: did:web:sokolov-risk.com. Наличие записи в реестре sol-trust.net/authority.

Уровень 2: Т-узлы (Trust Triad Nodes) и Мета-узлы

Т-узел: Сайт или раздел, имеющий хотя бы один Т-слой (страницу с экспертным контентом).

• Субъект: Лицензиат (юридическое лицо).
• Идентификация: did:web:[domain.clinic] для бизнеса. sol:assetId для конкретного актива.
• Ключевое право: Капитализация экспертного контента как НМА.
• Контрольная точка: Наличие TrustGraphAnchor и sol:assetId на Т-странице. Валидная DID-цепочка до Уровня 0. Статус Active в TRL.

Мета-узел: Частный случай Т-узла.

• Субъект: Лицензиар (DAT-M) или Лицензиат.
• Идентификация: did:web:[domain] (опционально) с controller на владельца.
• Ключевое право: Публикация локального словаря (/ns) и реестра анкоров (/anchor-registry).
• Контрольная точка: Наличие файлов /ns и /anchor-registry на сайте.

Уровень 3: Базовые узлы (Base Nodes)

• Субъект: Лицензиат (юридическое лицо).
• Идентификация: did:web:[domain.clinic].
• Ключевое право: Базовая верификация. Защита от алгоритмического дефолта.
• Ограничения: Не имеет Т-слоёв. Не является НМА.
• Контрольная точка: Наличие TrustGraphAnchor на главной странице. Статус BasicVerified.

3.2. Аксиомы графа

1. Принцип иерархического доверия (Trust Hierarchy): Доверие передаётся нисходящим потоком от Уровня 0 к Уровню 3.
2. Принцип симметрии графа (Graph Symmetry): Каждое ребро definesStandardFor от родителя к потомку должно иметь зеркальное ребро parentNode в дочернем узле.
3. Принцип единства идентификации (Single Source of Truth): Каждый узел имеет уникальный @id и, для Уровней 0-3, DID.

3.3. Модель делегированного доверия (по PKI)

1. Self-Signed Root (Уровень 0): Корневой DID (did:web:sokolov-risk.com) подписан собственным ключом. Доверие к нему обеспечивается предустановкой (Trust Store) во всех валидаторах сети.
2. Промежуточные узлы (Уровни 1-2): DID-документы подписаны вышестоящим узлом. Цепочка controller ведёт к Корневому узлу.
3. Проверка цепочки: Валидатор строит цепочку от DID узла до Корневого DID. Если корневой DID совпадает с предустановленным, цепочка считается доверенной.

4. Двухконтурная модель управления

4.1. Контур I (Infrastructure — Операционный контур)

Зона ответственности: Вычислительная среда, криптографический консенсус, транспортный слой, SLA.

Требования:

• Развертывание на выделенных серверах (Bare-Metal Nodes). Использование публичных облачных хостингов запрещено.
• Хэширование данных по стандарту SHA3-256.
• Подписание транзакций по схеме Ed25519.
• Обеспечение глобального аптайма не ниже 99.99%.

Контрольные точки:

• Наличие PAH-хэша (Payload Authorization Hash) в публичном реестре.
• Валидность подписи Ed25519.

4.2. Контур V (Verification — Валидационный контур)

Зона ответственности: Семантическая экспертиза, аудит, выпуск Цифровых паспортов, экономическая оценка.

Требования:

• Аудит факторов E-E-A-T 2.0 и выпуск Цифрового паспорта актива осуществляется Лицензиаром (держателем DAT-M или DAT-A), который аккредитовал данного Лицензиата.
• Каждый Лицензиар несёт экономическую ответственность (Slashing) за достоверность выданных им статусов.
• Головной Лицензиар (DAT-H) не участвует в операционной валидации. Он аккредитует Лицензиаров, ведёт реестр статусов (TRL) и обеспечивает юридическую чистоту методологии.
• Ведение реестра статусов (TRL) с тремя состояниями: Active, Cooldown, Revoked.

Контрольные точки:

• Наличие sol:complianceStatus не ниже VerifiedLicenseeRay для Т-узлов.
• Статус узла в TRL: Active для всех операций.

5. Идентификация и верификация (DID)

Подробный протокол DID, формат документов, алгоритм проверки цепочки и описание Trust Store приведены в Приложении 2 (DID и верификация).

5.1. Основные принципы

1. Каждый участник сети (Уровни 0-3) должен иметь DID-документ, размещённый по адресу https://[domain]/.well-known/did.json.
2. DID-документ должен содержать поле controller, указывающее на DID вышестоящего узла (для Уровней 1-3).
3. Корневой DID (did:web:sokolov-risk.com) является самоподписанным и предустановлен в Trust Store всех валидаторов.

5.2. Алгоритм верификации цепочки доверия

1. Извлечь issuer.id из SOL-актива или sol:ownerDid из TrustGraphAnchor.
2. Загрузить DID-документ эмитента.
3. Извлечь поле controller. Повторять рекурсивно до достижения Уровня 0.
4. На каждом шаге проверить наличие ключа дочернего узла в assertionMethod родителя.
5. Если на любом шаге связь отсутствует — цепочка разорвана. Актив невалиден.

5.3. Гибридная архитектура реестров (Приложение P)

Глобальный слой (Solana State Compression): Хранит публичные доказательства: хэши манифестов, статусы TRL, sig.a (для ИИ-агентов).

Локальный слой (Jurisdictional Registry): Хранит чувствительные юридические данные (ИНН, ОГРН, сканы документов) в защищённой базе данных.

Связь слоёв: Локальная запись содержит tx_id транзакции в глобальном слое. Глобальная запись содержит хэш юридического пакета.

6. Семантическая архитектура

6.1. Три семантических круга

Круг 1 (Ядерные запросы): Идентификация бренда, локации, контактов.

• Маркеры: name, url, address в JSON-LD.
• Статус: Закрывается Базовым узлом.

Круг 2 (Отраслевые запросы): Типовые проблемы и решения в отрасли.

• Маркеры: Структурированные данные о специализации, услугах.
• Статус: Закрывается Т-узлом (SOL-2).

Круг 3 (Уникальные экспертные маркеры): Уникальные методики, авторские разработки.

• Маркеры: author с sameAs, citation, isBasedOn.
• Статус: Закрывается Т-узлом (SOL-3). Является основанием для статуса VerifiedAcademicAsset.

6.2. Требования к Т-узлу

Для получения статуса VerifiedAcademicAsset Т-узел должен содержать:

1. Три блока JSON-LD: BreadcrumbList (навигация), WebPage + Article/Product (контентная сущность), TrustGraphAnchor (криптографический паспорт).
2. sol:assetId — уникальный идентификатор актива.
3. sol:ownerDid — DID владельца бизнеса.
4. sol:febaScore и sol:expertiseLevel — не ниже A.
5. sol:visibleManifestation — привязка к видимым заголовкам H1-H3.
6. Валидную DID-цепочку до Корневого узла.
7. Статус Active в TRL.

7. Юридический контур и капитализация в НМА

7.1. Основания для признания НМА

Т-узел признаётся Нематериальным Активом по ФСБУ 14/2022 и IAS 38 при выполнении следующих условий:

1. Идентифицируемость: Наличие sol:assetId и DID-цепочки до Корневого узла.
2. Контроль: Владение приватным ключом, подписывающим TrustGraphAnchor и SOL-актив.
3. Будущие экономические выгоды: Подтверждённая способность генерировать лидогенерацию или защищённый трафик. Оценивается через DCF-модель.
4. Отчуждаемость: Техническая возможность изолировать Т-узел и передать его другому лицу вместе с sol:assetId и DID.
5. Статус комплаенса: sol:complianceStatus = VerifiedLicenseeRay или VerifiedAcademicAsset.

7.2. Протокол списания

При наступлении триггеров обесценения (внесение в TRL, падение febaScore ниже порога, компрометация DID) инициируется процедура:

1. Фиксация события в глобальном реестре (Solana).
2. Публикация в Списке Отзыва Траста (CRL).
3. Проведение внеплановой инвентаризации объекта НМА (согласно п. 11 ФСБУ 14/2022) в течение 30 календарных дней.
4. Уценка или списание актива по итогам инвентаризации.

Контрольная точка: Наличие записи в CRL и внутреннего акта предприятия.

8. Стратегия децентрализации и управления рисками

8.1. Принцип дуалистической архитектуры

Сеть STN стартует с централизованной моделью управления (Self-Signed Root + Head Licensor) для обеспечения быстрого запуска и юридической определённости. Одновременно в архитектуру закладываются точки расширения для эволюционного перехода к децентрализованному консорциуму по достижении индикаторов развития.

8.2. Индикаторы активации механизмов децентрализации

8.3. Регламенты аварийного восстановления (BCP/DR)

8.4. Семена децентрализации (закладываются в архитектуру сейчас)

8.5. Обратная совместимость

Все изменения вносятся через расширение пространства имён (@context в JSON-LD) и не затрагивают ядро валидации для версий 1.0 и 1.1. Валидаторы старых версий продолжают работать по прежней логике.

9. Заключительные положения

9.1. Статус документа

Настоящий Канонический стандарт является официальным нормативным документом сети STN.

9.2. Обязательность исполнения

Все участники сети обязаны следовать настоящему стандарту. Нарушение аксиом графа, требований к DID или процедур верификации является основанием для внесения узла в TRL.

9.3. Изменения

Изменения вносятся по согласованию с Архитектурным комитетом SOL Trust Network и утверждаются Головным Лицензиаром.

9.4. Действие

Стандарт вступает в силу с 12 августа 2026 года и действует до принятия новой редакции.