Приложение P: Гибридная архитектура реестров и протокол доказательств с нулевым разглашением (ZKP)
Hybrid Registry Architecture and Zero-Knowledge Proof (ZKP) Protocol

Стандарт SOLPDT 1.1 оперирует данными двух принципиально разных классов:

• Публичные доказательства (статус верификации, PDT-Score, хэши манифестов), которые должны быть доступны глобально и проверяемы любым участником сети Solana.
• Чувствительные юридические данные (ИНН, ОГРН, полные имена владельцев, сканы уставных документов), хранение которых в публичных блокчейнах не рекомендуется в силу требований законодательства о защите персональных данных.

Для разрешения этого противоречия стандарт предусматривает гибридную архитектуру реестров.

В качестве рекомендуемого глобального источника истины для статусов sig.a, PDT-Score и валидности DAT рассматривается основная сеть Solana с применением технологии State Compression (cNFT).

Обоснование выбора Solana:

• Экономическая эффективность хранения данных вне основного состояния блокчейна.
• Прямая техническая совместимость с Solana Agent Registry (SAR) и кошельками экосистемы.
• Криптографическая защита от подделки статуса верификации.

Данные, рекомендуемые к публикации в Solana:

• sig.a (Authoritative Attestation) в виде хэша или сжатого сертификата.
• PDT-Score (метрика производительности агента).
• tx_id последней верификации.
• Хэш юридического пакета документов из Локального слоя (опционально).

Данные, исключенные из публикации в Solana:

• Персональные данные (ФИО, паспорт).
• Идентификаторы налогоплательщика (ИНН, ОГРН).
• Ссылки на внутренние документы Локального слоя.

Локальный слой представляет собой блокчейн-реестр или защищенную базу данных, развернутую в юрисдикции оператора стандарта и соответствующую требованиям применимого законодательства (например, ФСБУ 14/2022 и 152-ФЗ).

Технологическая основа:

Архитектура стандарта не накладывает ограничений на выбор конкретной платформы. Возможно использование как специализированных блокчейн-решений (Masterchain, Waves Enterprise), так и сертифицированных систем управления базами данных.

Управление:

Осуществляется Головным Лицензиаром (Head Licensor).

Данные, хранимые в Локальном слое:

• Полное досье владельца агента или SOL-Актива (Initial-Dossier).
• Юридически значимые акты верификации (Приложение J).
• Привязка к tx_id транзакции в сети Solana (обратная ссылка).

Для обеспечения целостности данных между Глобальным и Локальным слоями рекомендуется процедура атомарной записи, реализуемая через программный интерфейс Compliance-Gateway (CGW).

Рекомендуемый алгоритм:

1. CGW получает запрос на выдачу sig.a.
2. CGW формирует и записывает юридический пакет в Локальный реестр.
3. CGW отправляет транзакцию в сеть Solana, содержащую Payload-V2. Получает tx_id.
4. CGW обновляет запись в Локальном реестре, вписывая фактический tx_id транзакции Solana.

Для подтверждения юридической чистоты агента перед глобальными партнерами без раскрытия чувствительных данных (например, ИНН) архитектура стандарта предусматривает возможность использования протокола ZKP.

Цель: Предоставить математическое подтверждение того, что владелец агента прошел верификацию в Локальном реестре, не передавая при этом идентификационные данные в публичную сеть Solana.

Рекомендуемый технологический подход:

• Схема доказательства: Использование одной из признанных в индустрии схем (например, Groth16 на кривой BN254).
• Среда исполнения: Использование SDK, совместимых с экосистемой Solana (например, Light Protocol).

Общий процесс:

1. Лицензиар генерирует ZK-доказательство на стороне клиента (off-chain), используя данные из Локального реестра.
2. Доказательство включается в транзакцию Payload-V2.
3. Проверяющая сторона (Верификатор) выполняет проверку доказательства в сети Solana.

В случае внедрения протокола ZKP безопасность системы зависит от параметров начальной генерации ключей (Trusted Setup). Для минимизации рисков административного контроля и обеспечения максимального доверия к системе, стандарт SOLPDT ориентируется на следующие принципы:

Приоритет использования существующих публичных церемоний:

В качестве источника параметров для ZK-схем рекомендуется использовать результаты глобальных, общепризнанных церемоний (таких как Perpetual Powers of Tau). Это позволяет исключить зависимость от единственного центра генерации ключей без дополнительных затрат со стороны оператора стандарта.

Прозрачность реализации:

В соответствии с планом развития экосистемы, на последующих этапах (после завершения пилотных проектов и внутреннего тестирования) будет рассмотрен вопрос о публикации исходного кода схем верификации для возможности независимого аудита сообществом.