Enregistrement d'Appareils par Justificatifs pour les DePINs avec Preuves à Divulgation Nulle de Connaissance

2.1 Le fossé de confiance des DePINs

Les DePINs s'appuient sur des données d'appareils off-chain (par exemple, relevés de capteurs, preuve de localisation) pour déclencher des récompenses de tokens on-chain. Cela crée un gouffre de vérifiabilité. La blockchain ne peut pas vérifier de manière autonome si un appareil signalant une « bande passante de 50 Mbps » la possède réellement, ou si un capteur est calibré et placé à l'emplacement déclaré. L'état actuel implique souvent une confiance aveugle dans des oracles ou les propriétaires d'appareils, un point de défaillance central.

2.2 Le dilemme de la vérification On-Chain vs Off-Chain

Les solutions antérieures présentent un compromis :

• Vérification On-Chain : Stocker et vérifier les justificatifs des appareils (par exemple, un certificat signé par le fabricant) directement sur la chaîne est transparent mais expose des données commerciales ou personnelles potentiellement confidentielles (par exemple, spécifications matérielles exactes, numéros de série, identité du propriétaire).
• Vérification Off-Chain : Garder la logique de vérification hors chaîne (par exemple, dans un oracle de confiance) préserve la vie privée mais réintroduit précisément la centralisation et les hypothèses de confiance que les DePINs visent à éliminer.

L'article identifie cela comme le problème central : Comment effectuer une vérification décentralisée et sans confiance des justificatifs des appareils tout en maintenant la confidentialité des attributs de ces justificatifs ?

3.1 Modèle système & Architecture

Le cadre CDR introduit un flux logique impliquant quatre acteurs clés :

1. Émetteur : Une entité de confiance (par exemple, fabricant d'appareils, organisme de certification) qui émet des Justificatifs Vérifiables attestant des attributs de l'appareil.
2. Appareil / Prouveur : L'appareil physique (ou son propriétaire) qui détient le VC et doit prouver la validité du justificatif lors de l'enregistrement.
3. Contrat intelligent / Vérificateur : La logique on-chain qui définit les politiques d'enregistrement (par exemple, « l'appareil doit avoir ≥8 Go de RAM ») et vérifie les preuves ZK.
4. Réseau DePIN : L'application plus large qui admet l'appareil après un enregistrement réussi.

3.2 Rôle des Preuves à Divulgation Nulle de Connaissance (ZKPs)

Les ZKPs sont le moteur cryptographique qui résout le dilemme. Un appareil peut générer une preuve $\pi$ qui convainc le contrat intelligent de l'énoncé suivant : « Je possède un justificatif valide de l'Émetteur X, et les attributs de ce justificatif satisfont à la politique Y (par exemple, RAM > 8 Go), sans révéler le justificatif réel ni les valeurs spécifiques des attributs. » Cela permet l'application de politiques avec une confidentialité parfaite.

4.1 Choix du système de preuve : Groth16 vs Marlin

L'article évalue deux systèmes zkSNARKs majeurs :

• Groth16 : Un système de preuve basé sur l'appariement très efficace, connu pour sa petite taille de preuve et sa vérification rapide. Cependant, il nécessite une configuration de confiance pour chaque circuit.
• Marlin : Un SNARK universel et actualisable plus récent. Il utilise une chaîne de référence structurée universelle (SRS), permettant une seule configuration de confiance pour de nombreux circuits différents, offrant une plus grande flexibilité.

4.2 Résultats expérimentaux & Compromis de performance

Les expériences révèlent un compromis d'ingénierie critique, visualisé dans le graphique conceptuel ci-dessous :

6.1 Formalisation mathématique

L'énoncé ZK central pour le CDR peut être formalisé. Soit :

• $C$ le justificatif de l'appareil, une structure de données signée par l'Émetteur $I$ : $C = \{attr_1, attr_2, ..., sig_I\}$.
• $\Phi$ la clé publique de vérification pour l'émetteur $I$.
• $\mathcal{P}$ la politique d'enregistrement publique (par exemple, $attr_{ram} > 8$).
• $w = (C, private\_attrs)$ le témoin privé du prouveur.

L'appareil génère une preuve zkSNARK $\pi$ pour la relation $R$ :

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

Le contrat intelligent, ne connaissant que $\Phi$ et $\mathcal{P}$, peut vérifier $\pi$ pour être convaincu de la véracité de l'énoncé sans apprendre $w$.

6.2 Cadre d'analyse : Un cas d'usage hypothétique de DePIN

Scénario : Un réseau sans fil décentralisé (comme Helium 5G) exige que les fournisseurs de points d'accès prouvent que leur équipement a un gain d'antenne minimum et n'est pas situé dans une cellule géographiquement saturée pour recevoir des récompenses complètes.

Application du CDR :

1. Émission : Un fabricant d'antennes approuvé émet un VC vers l'élément sécurisé de l'appareil, signant des attributs comme `model: ABC-123`, `gain: 5dBi`, `serial: XYZ789`.
2. Preuve d'enregistrement : Le logiciel de l'appareil construit une preuve ZK démontrant : « Mon VC est valablement signé par le Fabricant M, ET l'attribut `gain` > 3dBi, ET le numéro de `série` n'est pas sur une liste de révocation publique (une preuve de non-appartenance à un arbre de Merkle), SANS révéler le numéro de série exact ou le gain. » Une preuve de localisation séparée (par exemple, via du matériel de confiance) pourrait être combinée.
3. Politique On-Chain : Le contrat intelligent du réseau détient la politique $\mathcal{P}_{5G} = (gain > 3, location\_cell \not\_saturated)$. Il vérifie la preuve unique et compacte $\pi$.
4. Résultat : L'appareil est enregistré avec un statut « vérifié », le qualifiant pour des niveaux de récompense plus élevés, le tout tandis que ses spécifications matérielles précises et son numéro de série restent confidentiels entre le propriétaire et le fabricant.