Veuillez préciser si vous souhaitez une traduction de ce texte ou un développement sur le sujet mentionné. Pour l'instant, voici la traduction en français : Détailler les principes de fonctionnement des infrastructures telles que IoTeX, DePHY et peaq.
TechFlow SélectionTechFlow Sélection
Veuillez préciser si vous souhaitez une traduction de ce texte ou un développement sur le sujet mentionné. Pour l'instant, voici la traduction en français : Détailler les principes de fonctionnement des infrastructures telles que IoTeX, DePHY et peaq.
Comprendre le fonctionnement des projets DePIN et de l'Internet des objets Web3 du point de vue de la conception des protocoles.
Dédié à des analyses Web3 approfondiesRédaction : Pika, ambassadeur de la blockchain Sui, chercheur DePIN
Édition : Faust, geek web3
Introduction : Bien que le secteur DePIN soit très en vogue actuellement, l’intégration à grande échelle des appareils IoT (Internet des objets) liés à DePIN dans les blockchains fait toujours face à des obstacles techniques. Généralement, pour connecter un matériel IoT à une blockchain, trois étapes clés doivent être franchies :
1. L’exécution fiable du matériel ;
2. La collecte, la vérification et la fourniture des données ;
3. La distribution des données vers différentes applications.
Chacune de ces étapes comporte différents scénarios d’attaques et contre-mesures nécessitant divers mécanismes de conception. Cet article analyse, du point de vue du flux de travail et de la conception du protocole, l'ensemble du processus par lequel les dispositifs IoT produisent des données de manière fiable, les vérifient et les stockent, génèrent des preuves via des calculs, puis remontent (rollup) les données vers la blockchain. Si vous êtes un entrepreneur dans le domaine DePIN, nous espérons que cet article vous aidera méthodologiquement et techniquement dans le développement de votre projet.
Dans ce qui suit, nous prendrons comme exemple le cas du contrôle de la qualité de l'air, en analysant conjointement trois infrastructures DePIN — IoTeX, DePHY et peaq — afin d’expliquer comment fonctionnent ces plateformes d’infrastructure. Ces plateformes peuvent relier des dispositifs IoT aux infrastructures blockchain/Web3, aidant ainsi les projets à démarrer rapidement leurs applications DePIN.
Fonctionnement fiable du matériel
La fiabilité du matériel inclut la confiance en l'identité de l'appareil et celle en l'exécution vérifiable et inviolable du programme.
Mode de fonctionnement fondamental de DePIN
Dans la plupart des schémas incitatifs DePIN, l’opérateur d’un appareil matériel fournit un service externe, qu’il utilise comme monnaie d’échange pour réclamer une récompense auprès du système incitatif. Par exemple, dans Helium, les hotspots réseau obtiennent des récompenses HNT en offrant une couverture de signal. Toutefois, avant de recevoir une incitation du système, les dispositifs DePIN doivent d’abord présenter une preuve qu’ils ont bien fourni un certain « effort » conforme aux exigences.
Cette preuve attestant qu’un service ou certaines activités ont été réalisés dans le monde réel est appelée « Preuve de Travail Physique » (Proof of Physical Work, PoPW). Dans la conception des protocoles DePIN, la preuve de travail physique joue un rôle central, accompagnée de divers scénarios d’attaque et de contre-mesures correspondantes.
Les projets DePIN s’appuient sur la blockchain pour distribuer les incitations et allouer les jetons. De manière analogue au système de clés publiques/privées des blockchains traditionnelles, le processus de vérification d’identité des dispositifs DePIN nécessite également l’utilisation de clés publiques et privées : la clé privée sert à générer et signer la « preuve de travail physique », tandis que la clé publique permet à l’extérieur de valider cette preuve ou sert d’étiquette d’identité du dispositif (Device ID).
En outre, il n’est pas pratique de recevoir directement les incitations en jetons sur l’adresse blockchain du dispositif physique. Les projets DePIN déployent donc souvent un contrat intelligent sur la chaîne, qui enregistre les adresses de comptes blockchain des différents détenteurs d’appareils, similaire à une relation un-à-un ou plusieurs-à-un dans une base de données. Ainsi, les récompenses en jetons dues au dispositif hors chaîne peuvent être directement transférées sur le compte blockchain du détenteur.
Attaque Sybil
La plupart des plateformes offrant des incitations sont confrontées à l’« attaque Sybil », où une personne peut contrôler de nombreux comptes ou dispositifs, ou générer différentes preuves d’identité, se faisant passer pour plusieurs individus afin d’obtenir plusieurs récompenses. Prenons l’exemple du contrôle de la qualité de l’air mentionné précédemment : plus il y a de dispositifs fournissant ce service, plus le système distribue de récompenses. Quelqu’un pourrait utiliser des moyens techniques pour générer rapidement de nombreuses données de contrôle de l’air et signatures d’appareils correspondantes, créant massivement des preuves de travail physique pour en tirer profit, provoquant ainsi une forte inflation des jetons du projet DePIN, ce qu’il faut empêcher.
Pour lutter contre Sybil sans recourir à des méthodes telles que la KYC qui compromettent la confidentialité, les mesures les plus courantes sont POW et POS. Dans le protocole Bitcoin, les mineurs doivent consacrer d’importantes ressources en puissance de calcul pour obtenir des récompenses minières, tandis que dans les blockchains POS, les participants verrouillent directement de gros actifs.
Dans le domaine DePIN, l’anti-Sybil revient à « augmenter le coût de génération de la preuve de travail physique ». Étant donné que la génération de cette preuve dépend d’informations d’identité valides du dispositif (clé privée), il suffit d’en augmenter le coût d’acquisition pour empêcher les tricheurs de produire facilement de nombreuses preuves de travail.
À cet effet, une solution relativement efficace consiste à faire que les fabricants de dispositifs DePIN monopolisent la génération des identifiants, en personnalisant les dispositifs et en inscrivant une étiquette d’identité unique sur chaque unité. C’est comme si l’état civil centralisait toutes les informations d’identité des citoyens : seul celui dont l’identité figure dans la base de données officielle peut prétendre aux aides gouvernementales.
(Source : DigKey)
Lors de la fabrication, les fabricants de dispositifs DePIN utilisent un programme pour générer une clé racine pendant une période suffisamment longue, puis sélectionnent aléatoirement cette clé racine pour l’écrire dans la puce via la technologie eFuse. Précisons ici que l’eFuse (fusible électronique programmable) est une technique électronique utilisée dans les circuits intégrés pour stocker des informations. Une fois écrites, ces informations ne peuvent généralement ni être modifiées ni effacées, offrant ainsi une sécurité élevée.
Avec ce procédé, ni le propriétaire du dispositif ni le fabricant ne peuvent connaître la clé privée ou la clé racine du dispositif. Le matériel peut, dans un environnement isolé TEE, dériver et utiliser des clés de travail à partir de la clé racine, notamment la clé privée utilisée pour signer les messages, et la clé publique transmise à l’extérieur pour vérifier l’identité du dispositif. Ni les personnes ni les programmes extérieurs au TEE ne peuvent accéder aux détails des clés.
Avec ce modèle, pour recevoir des incitations en jetons, il faut acheter l’appareil auprès du fabricant agréé. Pour contourner ce fabricant et générer à faible coût de nombreuses preuves de travail, un attaquant Sybil devrait pirater le système de sécurité du fabricant afin d’enregistrer sa propre clé publique dans les dispositifs autorisés du réseau. L’attaquant Sybil ne peut agir à bas coût, sauf si le fabricant complice commet une malversation.
Dès lors que des soupçons de mauvaise conduite du fabricant apparaissent, la communauté peut le dénoncer via un consensus social, ce qui nuit souvent gravement au projet DePIN lui-même. Mais dans la plupart des cas, le fabricant du dispositif, étant un bénéficiaire principal du protocole réseau DePIN, n’a guère de motivation à tricher, car il gagne davantage en vendant des équipements qu’en minant DePIN, et préfère donc généralement rester honnête.
(Source : Pintu Academy)
Si le matériel n’est pas fourni uniformément par un fabricant centralisé, alors lorsque tout dispositif rejoint le réseau DePIN, le système doit d’abord confirmer qu’il possède les caractéristiques requises par le protocole. Par exemple, le système vérifie si ces nouveaux dispositifs disposent d’un module matériel spécifique ; ceux qui n’en ont pas ne peuvent généralement pas être certifiés. Obtenir un tel module matériel implique un certain coût, ce qui augmente le coût d’une attaque Sybil et atteint ainsi l’objectif anti-Sybil. Dans ce cas, il est plus judicieux et sûr de faire fonctionner normalement le dispositif plutôt que de tenter une attaque Sybil.
Attaque par altération des données
Imaginons un instant que plus les données de contrôle de la qualité de l’air collectées par un dispositif présentent de fluctuations, plus le système considère ces données précieuses et attribue davantage de récompenses. Dans ce cas, tout dispositif aurait un fort incitant à falsifier ses données pour simuler une forte volatilité. Même un dispositif certifié par un fabricant centralisé pourrait « glisser » des modifications dans le traitement des données brutes.
Comment garantir que les dispositifs DePIN sont honnêtes et ne modifient pas arbitrairement les données collectées ? On fait alors appel à la technologie du micrologiciel de confiance (Trusted Firmware), dont les exemples célèbres sont TEE (Trusted Execution Environment) et SPE (Secure Processing Environment). Ces technologies matérielles garantissent que les données soient traitées conformément à un programme préalablement validé, sans « manipulation cachée » durant le calcul.
(Source : Trustonic)
Précisons brièvement que le TEE (environnement d’exécution de confiance) est généralement implémenté dans un processeur ou un cœur de processeur, afin de protéger les données sensibles et exécuter des opérations critiques. Le TEE fournit un environnement d’exécution de confiance où le code et les données bénéficient d’une sécurité au niveau matériel, empêchant les logiciels malveillants, les attaques ou les accès non autorisés. Par exemple, les portefeuilles matériels Ledger et Keystone utilisent tous deux la technologie TEE.
La majorité des puces modernes supportent le TEE, en particulier celles destinées aux appareils mobiles, aux objets IoT et aux services cloud. En général, les processeurs haute performance, les puces de sécurité, les SoC (System-on-Chip) pour smartphones et les puces de serveurs cloud intègrent la technologie TEE, car ces matériels concernent des cas d’usage exigeants en termes de sécurité.
Toutefois, tous les matériels ne supportent pas le micrologiciel de confiance. Certains microcontrôleurs bas de gamme, capteurs ou puces embarquées personnalisées peuvent ne pas supporter le TEE. Pour ces puces à faible coût, des attaques par sondes peuvent extraire les informations d’identité stockées, permettant ainsi de falsifier l’identité et le comportement du dispositif. Par exemple, en récupérant la clé privée sauvegardée sur la puce, on peut l'utiliser pour signer des données altérées ou fabriquées, les faisant passer pour des données générées légitimement par le dispositif.
Mais les attaques par sondes nécessitent des équipements spécialisés, des manipulations précises et une analyse de données complexe, rendant leur coût très élevé, bien supérieur au coût d’achat direct de ces puces bon marché. Plutôt que de falsifier l’identité de dispositifs bas de gamme via des attaques par sondes, un attaquant préférera généralement acheter directement davantage de dispositifs à faible coût.
Scénarios d’attaque sur la source des données
Comme mentionné ci-dessus, le TEE peut garantir que le matériel génère correctement les résultats des données, c’est-à-dire qu’il prouve que les données, une fois entrées dans le dispositif, n’ont pas été traitées malicieusement. Mais il ne peut pas assurer que la source d’entrée des données était digne de confiance avant leur traitement, ce qui rappelle les défis auxquels sont confrontés les protocoles d’oracle.
Par exemple, un capteur de qualité de l’air placé près d’une usine émettant des gaz d’échappement pourrait être recouvert la nuit par un bocal hermétique en verre. Les données collectées seraient alors nécessairement fausses. Mais de tels scénarios d’attaque sont rarement rentables, et les attaquants n’ont généralement aucun intérêt à les mener, car ils demandent des efforts sans retour. Pour un protocole réseau DePIN, tant que le dispositif respecte un processus de calcul honnête et a fourni l’effort requis par le protocole incitatif, il devrait théoriquement recevoir une récompense.
Présentation des solutions
IoTeX
IoTeX propose l’outil de développement W3bStream pour connecter les dispositifs IoT à la blockchain et au Web3. Dans le SDK côté IoT de W3bStream, on trouve des composants fondamentaux tels que communication et transmission de messages, services d’identité et de certification, et services cryptographiques.
Le SDK IoT de W3bStream offre un développement très complet des fonctions cryptographiques, incluant divers algorithmes comme PSA Crypto API, primitives cryptographiques, services cryptographiques, HAL, outils, Root of Trust, etc.
Avec ces modules, il est possible de signer de façon sécurisée ou moins sécurisée les données produites par différents matériels, puis de les transmettre via le réseau vers la couche de données suivante pour validation.
DePHY
DePHY propose un service d’authentification DID (Device ID) côté IoT. Le DID est émis par le fabricant, chaque dispositif possédant un et un seul DID associé. Les métadonnées du DID sont personnalisables : numéro de série, modèle, informations de garantie, etc.
Pour les dispositifs matériels supportant le TEE, le fabricant génère initialement une paire de clés et écrit la clé dans la puce via eFuse. Le service DID de DePHY aide ensuite le fabricant à générer le DID à partir de la clé publique du dispositif. Outre son écriture dans le dispositif IoT, la clé privée générée n’est détenue que par le fabricant.
Étant donné que le micrologiciel de confiance permet une signature de message sécurisée et confidentielle ainsi qu’une protection de la clé privée matérielle, si l’on découvre dans le réseau des comportements frauduleux de génération de clés privées de dispositifs, on peut presque affirmer que le fabricant est malhonnête, permettant ainsi de remonter jusqu’au fabricant responsable et d’assurer une traçabilité de confiance.
Après avoir acheté un dispositif, l’utilisateur DePHY peut obtenir les informations d’activation, appeler ensuite le contrat d’activation sur la chaîne pour associer le DID du dispositif à son adresse blockchain, et ainsi se connecter au protocole réseau DePHY. Après configuration du DID, un flux bidirectionnel de données entre l’utilisateur et le dispositif devient possible.
Lorsqu’un utilisateur envoie une commande de contrôle à un dispositif via son compte blockchain, le processus est le suivant :
1. Vérifier que l’utilisateur dispose des droits d’accès. Comme les droits de contrôle d’accès sont inscrits sous forme de métadonnées dans le DID, on peut confirmer ces droits en examinant le DID ;
2. Autoriser l’établissement d’un canal privé entre l’utilisateur et le dispositif, permettant le contrôle. Le relais DePHY, outre NoStr relay, inclut aussi des nœuds pair-à-pair pouvant prendre en charge des canaux directs, avec d’autres nœuds du réseau servant de relais. Cela permet un contrôle en temps réel hors chaîne du dispositif.
Lorsqu’un dispositif IoT envoie des données à la blockchain, la couche de données ultérieure lit l’état d’autorisation du dispositif depuis le DID. Seuls les dispositifs enregistrés et autorisés peuvent télécharger des données, par exemple ceux enregistrés par le fabricant.
Une autre fonction intéressante du service DID est l’authentification des caractéristiques fonctionnelles (trait) du dispositif IoT. Cette certification permet d’identifier si un matériel IoT possède certaines fonctionnalités spécifiques, et donc s’il est éligible à participer à des activités incitatives sur une blockchain donnée. Par exemple, un émetteur WiFi doté de la fonction LoRaWAN (trait) peut être considéré comme apte à fournir une connexion sans fil, et ainsi participer au réseau Helium. De même, on parle de traits GPS, TEE, etc.
Sur le plan des services étendus, le DID DePHY prend également en charge la mise en gage, la connexion à des portefeuilles programmables, facilitant la participation aux activités sur chaîne.
peaq
La solution peaq est assez particulière, structurée en trois niveaux : authentification issue du dispositif, vérification par reconnaissance de motifs, authentification basée sur oracle.
1. Authentification issue du dispositif. peaq propose également de générer une paire de clés, d’utiliser la clé privée pour signer des informations sur le dispositif, et de lier l’adresse du dispositif (peaq ID) à l’adresse utilisateur. Toutefois, son code open source ne contient aucune implémentation de micrologiciel de confiance. La simple méthode de signature par clé privée employée par peaq ne garantit ni l’intégrité du fonctionnement du dispositif ni l’absence de modification des données. peaq ressemble davantage à un Rollup optimiste, supposant par défaut que le dispositif ne triche pas, puis vérifiant a posteriori la crédibilité des données.
2. Vérification par reconnaissance de motifs. La deuxième approche combine apprentissage machine et reconnaissance de motifs. Un modèle est formé sur les données historiques, puis les nouvelles données sont comparées à ce modèle pour juger de leur crédibilité. Mais un modèle statistique ne peut identifier que des données anormales, pas déterminer si le dispositif IoT fonctionne honnêtement.
Par exemple, un capteur de qualité de l’air en ville A, placé en sous-sol, produit des données différentes des autres capteurs, mais cela ne signifie pas qu’elles sont falsifiées : le dispositif fonctionne encore honnêtement. D’un autre côté, si les gains sont suffisants, les pirates peuvent utiliser des méthodes telles que les GAN pour générer des données indiscernables par l’apprentissage machine, surtout si le modèle de détection est public.
3. Authentification basée sur oracle. La troisième solution consiste à choisir certaines sources de données plus fiables comme oracles, puis comparer et valider les données collectées par d’autres dispositifs DePIN. Par exemple, si le projet déploie à la ville A un capteur de qualité de l’air précis, les données d’autres capteurs trop divergentes seront jugées non fiables.
Cette méthode introduit une dépendance à l’autorité dans la blockchain, et pourrait, en cas de biais d’échantillonnage de la source oracle, entraîner un biais global du réseau.
Selon les documents disponibles actuellement, l’infrastructure peaq ne garantit pas la fiabilité du dispositif et des données côté IoT. (Note : l’auteur a consulté le site officiel de peaq, la documentation technique, le dépôt Github, ainsi qu’un brouillon de livre blanc datant de 2018. Même après avoir envoyé un courriel à l’équipe de développement, aucune information complémentaire n’a été reçue avant publication.)
Production et diffusion des données (DA)
La deuxième étape du workflow DePIN consiste principalement à collecter et valider les données transmises par les dispositifs IoT, à les stocker et à les fournir aux étapes suivantes. Il faut garantir que les données soient transmises intégralement, sans erreur et restaurables à un destinataire spécifique : c’est ce qu’on appelle la couche Disponibilité des Données (couche DA).
Les dispositifs IoT diffusent généralement leurs données et informations d’authentification via des protocoles comme HTTP ou MQTT. Lorsque la couche données de l’infrastructure DePIN reçoit ces informations, elle doit vérifier leur crédibilité et rassembler les données validées pour stockage.
MQTT (MQ Telemetry Transport) est un protocole de transmission de messages léger, ouvert et basé sur le modèle publication/abonnement, conçu pour connecter des dispositifs limités comme des capteurs ou des systèmes embarqués, et communiquer efficacement dans des environnements à faible bande passante ou réseau instable, idéal pour les applications IoT.
La validation des messages IoT comprend l’authentification de l’exécution fiable du dispositif et celle du message lui-même.
L’authentification de l’exécution fiable peut s’appuyer sur le TEE. Le TEE isole le code de collecte des données dans une zone protégée du dispositif, assurant ainsi une collecte sécurisée.
Une autre méthode est la preuve à divulgation nulle de connaissance (ZKP), qui permet au dispositif de prouver l’exactitude de la collecte des données sans révéler les détails sous-jacents. Cette solution varie selon les dispositifs : les appareils performants peuvent générer localement le ZKP, tandis que les dispositifs limités peuvent le faire à distance.
Une fois la confiance du dispositif établie, la validation de la signature du message via le DID permet de confirmer que le message provient bien de ce dispositif.
Présentation des solutions
IoTeX
Dans W3bStream, on distingue trois parties : collecte et vérification fiable des données, nettoyage des données, et stockage des données.
-
La collecte et vérification des données fiables utilisent le TEE et les preuves à divulgation nulle.
-
Le nettoyage des données consiste à uniformiser et standardiser les formats de données provenant de différents types de dispositifs, facilitant leur stockage et traitement.
-
Pour le stockage, différents projets applicatifs peuvent configurer des adaptateurs pour choisir différents systèmes de stockage.
Dans l’implémentation actuelle de W3bStream, les différents dispositifs IoT peuvent envoyer directement leurs données au terminal de service W3bStream, ou les transmettre d’abord à un serveur intermédiaire avant de les envoyer au terminal W3bStream.
À la réception des données entrantes, W3bStream agit comme un centre de routage, distribuant les données entrantes à différents programmes pour traitement. Les projets DePIN au sein de l’écosystème W3bStream s’enregistrent sur W3bStream et définissent une stratégie d’événements (Event Strategy) et des programmes de traitement (Applet).
Chaque dispositif IoT possède un compte (device account), appartenant à un projet W3bStream et à un seul. Ainsi, lorsqu’un message IoT parvient au port du serveur W3bStream, il peut d’abord être redirigé vers un projet selon les informations d’enregistrement, puis la crédibilité des données est vérifiée.
Concernant la stratégie d’événements mentionnée plus haut, on peut définir les types d’événements déclencheurs (Event triggers), tels que les données reçues via une API HTTP, les sujets MQTT, ou la détection d’événements sur la blockchain, hauteur de bloc, etc., et associer à chacun un programme de traitement.
Un programme de traitement (Applet) contient une ou plusieurs fonctions exécutables, compilées au format WASM. Le nettoyage et la mise en forme des données sont effectués via l’Applet. Les données traitées sont ensuite stockées dans une base de données key-value définie par le projet.
DePHY
Le projet DePHY adopte une approche plus décentralisée pour traiter et fournir les données, qu’il appelle le Réseau de Messages DePHY (DePHY Message Network).
Le Réseau de Messages DePHY est constitué de nœuds relais DePHY sans permission (permissionless). Un dispositif IoT peut transmettre ses données via le port RPC de n’importe quel nœud relais DePHY. Les données entrantes appellent d’abord un middleware, qui valide la crédibilité des données en s’appuyant sur le DID.
Les données validées doivent être synchronisées entre différents nœuds relais pour former un consensus. Le Réseau de Messages DePHY utilise le protocole NoStr pour y parvenir. Initialement conçu pour les médias sociaux décentralisés, rappelez-vous quand certains ont utilisé NoStr à la place de Twitter ? Son utilisation dans la synchronisation des données DePIN s’avère également astucieuse.
Dans le
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@godrealmx
