Регистрация устройств на основе учетных данных в DePIN с использованием доказательств с нулевым разглашением

2.1 Проблема доверия в DePIN

DePIN полагаются на оффчейн-данные устройств (например, показания датчиков, доказательство местоположения) для запуска ончейн-токенных вознаграждений. Это создает пропасть верифицируемости. Блокчейн не может автономно проверить, действительно ли устройство, сообщающее о "пропускной способности 50 Мбит/с", обладает ею, или откалиброван ли датчик и находится ли он в заявленном месте. Текущее состояние часто предполагает слепое доверие оракулам или владельцам устройств, что является центральной точкой отказа.

2.2 Дилемма ончейн- и оффчейн-верификации

Предыдущие решения представляют собой компромисс:

• Ончейн-верификация: Хранение и проверка учетных данных устройства (например, подписанного сертификата от производителя) непосредственно в блокчейне прозрачны, но раскрывают потенциально конфиденциальные коммерческие или персональные данные (например, точные аппаратные спецификации, серийные номера, личность владельца).
• Оффчейн-верификация: Хранение логики верификации вне блокчейна (например, в доверенном оракуле) сохраняет конфиденциальность, но вновь вводит ту самую централизацию и допущения о доверии, которые DePIN стремятся устранить.

В работе это определяется как ключевая проблема: Как выполнить бездоверительную, децентрализованную верификацию учетных данных устройства, сохраняя при этом конфиденциальность атрибутов учетных данных?

3.1 Модель системы и архитектура

Фреймворк CDR вводит логический поток с участием четырех ключевых участников:

1. Эмитент (Issuer): Доверенная сторона (например, производитель устройства, сертификационный орган), которая выпускает верифицируемые учетные данные, подтверждающие атрибуты устройства.
2. Устройство/Доказывающая сторона (Device/Prover): Физическое устройство (или его владелец), которое хранит VC и должно доказать действительность учетных данных во время регистрации.
3. Смарт-контракт/Верификатор (Smart Contract/Verifier): Ончейн-логика, определяющая политики регистрации (например, "устройство должно иметь ≥8 ГБ ОЗУ") и проверяющая ZK-доказательства.
4. Сеть DePIN (DePIN Network): Более широкое приложение, которое принимает устройство после успешной регистрации.

3.2 Роль доказательств с нулевым разглашением (ZKPs)

ZKPs — это криптографический механизм, разрешающий дилемму. Устройство может сгенерировать доказательство $\pi$, которое убеждает смарт-контракт в истинности следующего утверждения: "Я обладаю действительными учетными данными от Эмитента X, и атрибуты в этих учетных данных удовлетворяют политике Y (например, ОЗУ > 8 ГБ), без раскрытия самих учетных данных или конкретных значений атрибутов." Это позволяет применять политики с полной конфиденциальностью.

4.1 Выбор системы доказательств: Groth16 vs. Marlin

В работе оцениваются две известные системы zkSNARK:

• Groth16: Высокоэффективная система доказательств на основе спариваний, известная своим малым размером доказательства и быстрой верификацией. Однако она требует доверенной настройки для каждой схемы (circuit).
• Marlin: Более новая универсальная и обновляемая SNARK. Она использует универсальную структурированную строку ссылок (SRS), позволяя выполнить единую доверенную настройку для многих различных схем, что обеспечивает большую гибкость.

4.2 Экспериментальные результаты и компромиссы производительности

Эксперименты выявляют критический инженерный компромисс, визуализированный на концептуальной диаграмме ниже:

6.1 Математическая формулировка

Ключевое ZK-утверждение для CDR можно формализовать. Пусть:

• $C$ — учетные данные устройства, подписанная структура данных от Эмитента $I$: $C = \{attr_1, attr_2, ..., sig_I\}$.
• $\Phi$ — открытый ключ верификации для эмитента $I$.
• $\mathcal{P}$ — публичная политика регистрации (например, $attr_{ram} > 8$).
• $w = (C, private\_attrs)$ — приватный свидетель доказывающей стороны.

Устройство генерирует zkSNARK-доказательство $\pi$ для отношения $R$:

$R = \{ (\Phi, \mathcal{P}; w) : \text{VerifySig}(\Phi, C) = 1 \ \wedge \ \text{CheckPolicy}(\mathcal{P}, C) = 1 \}$

Смарт-контракт, зная только $\Phi$ и $\mathcal{P}$, может проверить $\pi$, чтобы убедиться в истинности утверждения, не узнавая $w$.

6.2 Аналитическая структура: Гипотетический сценарий использования DePIN

Сценарий: Децентрализованная беспроводная сеть (например, Helium 5G) требует от провайдеров хот-спотов доказать, что их оборудование имеет минимальное усиление антенны и не расположено в географически насыщенной ячейке, чтобы получать полные вознаграждения.

Применение CDR:

1. Выпуск (Issuance): Одобренный производитель антенн выпускает VC в защищенный элемент устройства, подписывая атрибуты, такие как `model: ABC-123`, `gain: 5dBi`, `serial: XYZ789`.
2. Доказательство регистрации (Registration Proof): Программное обеспечение устройства строит ZK-доказательство, демонстрирующее: "Мой VC действителен и подписан Производителем M, И атрибут `gain` > 3dBi, И серийный номер `serial` не находится в публичном списке отзыва (доказательство непринадлежности к дереву Меркла), БЕЗ раскрытия точного серийного номера или усиления." Отдельное доказательство местоположения (например, через доверенное оборудование) может быть объединено.
3. Ончейн-политика (On-Chain Policy): Смарт-контракт сети содержит политику $\mathcal{P}_{5G} = (gain > 3, location\_cell \not\_saturated)$. Он проверяет единое компактное доказательство $\pi$.
4. Результат (Outcome): Устройство регистрируется со статусом "верифицировано", что дает ему право на более высокие уровни вознаграждения, при этом его точные аппаратные спецификации и серийный номер остаются конфиденциальными между владельцем и производителем.