Le manque de protection de la vie privée est le péché originel de toutes les blockchains publiques – depuis le livre blanc Bitcoin original de Satoshi jusqu'au réseau le plus avancé, modulaire et parallélisé qui effectue 100 millions de transactions par seconde avec un temps de finalité de zeptoseconde.

D’une manière générale, la confidentialité des utilisateurs va à l’encontre de la nature des blockchains publiques : pour qu’un registre public fonctionne, certaines données de transaction doivent être partagées avec les nœuds et les participants du réseau. Le raccourci pour mettre rapidement ces systèmes en ligne consiste simplement à tout rendre public par défaut.

Cependant, cette transparence ultime expose les utilisateurs à la surveillance, à la coercition et à des conséquences involontaires telles que la fuite de signaux commerciaux. Ceci est commercialement non viable et corrosif pour le droit de chacun à déterminer son destin. Une véritable garde de soi ne peut exister si les utilisateurs ne contrôlent pas leurs données ; la confidentialité consiste à rétablir la liberté des utilisateurs de choisir ce qu'ils font et de ne pas révéler au monde extérieur.

Voici sept failles fatales courantes dans les outils de confidentialité cryptographique :

Péché 1 – Systèmes centralisés

Dans un monde décentralisé, la centralisation est la paresse. Il est plus facile (plus rapide et moins cher) de gérer un grand livre sur la base de données SQL interne d'une banque que d'envoyer des transactions, même sur les blockchains les plus performantes. 

Cependant, décentralisation est synonyme de résilience. C’est la raison pour laquelle la crypto a une valeur marchande. Sans cela, les utilisateurs bénéficieraient de la rapidité et des économies de coûts des institutions centralisées.

Ceci est encore plus important pour les protocoles de confidentialité, où la centralisation signifie que les développeurs s'accordent un accès privilégié aux données des utilisateurs.

Les créateurs de protocoles devraient n'allons jamais se donnent des clés d'administrateur qui peuvent geler ou désanonymiser les utilisateurs. (RAILGUN utilise des mécanismes comme Affichage des clés pour fournir une transparence non discriminatoire et contrôlée par l'utilisateur lorsque cela est nécessaire.) 

Un autre vecteur de centralisation est celui des multi-signatures à seuil, en particulier pour les protocoles cherchant à contourner les ponts non sécurisés. Même lorsqu'il est configuré « correctement », un multi-sig 3 sur 5 est sans doute pire en termes d'hypothèses de confiance que votre banque de quartier.

Et quand le multi-sig n'est pas configuré correctement….  

Péché 2 – Désir d’exploitation forestière

Les outils de confidentialité doivent prendre toutes les mesures nécessaires pour garantir l’absence de suivi de l’activité des utilisateurs, en particulier des données personnellement identifiables telles que les adresses IP et l’activité de navigation.

Les protocoles de confidentialité doivent être conçus selon une philosophie globale qui n’utilise qu’un manque de jugement momentané pour désanonymiser les utilisateurs.

Par exemple, Railway Wallet (qui a intégré la technologie de confidentialité RAILGUN) proxy les appels RPC par défaut pour tous les utilisateurs afin que même si quelqu'un n'utilise pas de VPN (ce qu'il devrait 🙁), son adresse IP ne soit pas divulguée aux nœuds RPC.

Péché 3 – État crypté

Pourquoi ne pas rendre l'ensemble du système privé ? C'est tentant… mais avoir un État entièrement crypté est aussi indésirable, à certains égards, que d'être entièrement public.

L'état de cryptage crée une boîte noire dans laquelle les utilisateurs et les observateurs ne savent pas ce que fait la dApp. Il élimine la fonctionnalité de sécurité la plus importante des blockchains : l’auditabilité publique.

Si la dApp est privée, comment vérifier que les économiques et les acteurs agissent correctement ? Comment réagir correctement à un exploit ou à une tentative malveillante si vous ne savez pas si quelque chose s'est produit ?

La confidentialité des utilisateurs est bonne, tout comme la transparence du protocole.

Péché 4 – Dépendance à l’égard de fabricants spécifiques

Être « sans confiance » signifie que vous n'avez pas besoin de faire confiance à un tiers (c'est-à-dire une entreprise, un agent ou un caissier de banque) pour garantir le bon fonctionnement d'un protocole. L’un des points forts du chiffrement basé sur la connaissance zéro est qu’il crée moins de dépendances, y compris vis-à-vis des fabricants.

Considérez, par exemple, si vous créez un système de confidentialité qui s'appuie sur les extensions Software Guard intégrées par Intel dans leurs processeurs. La sécurité de votre système dépend d'un point de défaillance potentiel unique : faire confiance à Intel pour avoir correctement mis en œuvre son produit.

Les incitations d'Intel sont d'agir de manière appropriée, mais s'appuyer sur SGX crée une vulnérabilité constante et une hypothèse de confiance inutile. Il existe également des considérations de contrôle d'accès dès la conception, car SGX nécessite un matériel spécialisé relativement coûteux, obscur et difficile à entretenir. En revanche, un validateur de preuve de participation peut être exécuté sur un Raspberry Pi.

Péché 5 – Devenir voyou

La confidentialité des crypto-monnaies est un argument convaincant, mais ce n'est pas une proposition de valeur suffisamment forte pour justifier la création d'une toute nouvelle blockchain ou d'un nouveau rollup (à moins que la chaîne spécialisée n'apporte une innovation technique stricte).

Les systèmes de confidentialité ont plus d’impact lorsqu’ils sont disponibles sur des chaînes où existent des utilisateurs et des activités financières. Pour le meilleur ou pour le pire, DeFi s'est rassemblé autour Ethereum, EVM, et quelques autres environnements comme Solana. La solidité est reine et a donc bénéficié du plus grand nombre de recherches en matière de sécurité.

Créer un nouvel environnement d'exécution et attirer les développeurs et les utilisateurs prend du temps et des incitations souvent non durables. Pendant ce temps, des milliards de dollars en valeur reposent déjà sur des chaînes publiques qui ont désespérément besoin de confidentialité.

Les chaînes dédiées à la confidentialité soulèvent également des questions de sécurité supplémentaires, telles que l’exigence de ponts – qui se sont révélés à maintes reprises comme étant le composant le moins sécurisé des réseaux blockchain. D'autres préoccupations incluent la centralisation du consensus, de la validation et des séquenceurs.

Péché 6 – Complexité du constructeur

Les développeurs sont souvent considérés comme des génies (et certains le sont). Cependant, la cryptographie est suffisamment complexe pour qu’obliger les constructeurs à apprendre et à utiliser un langage, une chaîne d’outils ou un écosystème propriétaire soit inutilement complexe et contre-productif. 

Les contrats rédigés dans des langages comme Solidity ou Vyper sont portables entre les réseaux prenant en charge EVM. Ce n'est pas le cas pour Rust et les autres chaînes WebAssembly. Ils ont tous leurs propres normes d'exécution. Du point de vue du constructeur, cela signifie que des bases de code contractuelles distinctes doivent être conservées pour chaque chaîne même si elles utilisent le même langage.

De ce fait, le produit est moins accessible.

Péché 7 – Technologie immature

« Magic Internet Money » est un mème vraiment excellent. Cependant, les développeurs de cryptographie développent une technologie financière qui a des conséquences concrètes et gère de l’argent réel.

Les technologies de confidentialité ont le double devoir de prendre en compte la « réalité de l’argent » et la « vie privée » elle-même – c’est-à-dire qu’elles doivent être protégées contre les exploits financiers ET tout ce qui pourrait désanonymiser les utilisateurs. Le corpus important de recherches universitaires existantes sur cette technologie existe pour une raison.

De peur que tu finisses comme IOTA, un axiome éprouvé est « ne lancez jamais votre cryptographie ».

Les technologies de confidentialité, en particulier, devraient être testées et réfléchies, avec des audits approfondis réalisés par des sociétés de sécurité, des évaluations de défenseurs de la vie privée, des tests d'intrusion par des chapeaux blancs, etc.

Sinon, comment pouvez-vous vous attendre à ce que les gens – en particulier les nouveaux utilisateurs grand public espérés – risquent leur identité et leur argent sur une plate-forme technologique complexe ?

Conclusion

Les blockchains publiques sont « dox-by-design ». Il n’est pas facile de créer des systèmes de confidentialité en chaîne tout en préservant les raisons d’utiliser la cryptographie en premier lieu, telles que l’auditabilité et la décentralisation.

Une excellente ressource pour évaluer les niveaux de confidentialité de l'outil de confidentialité que vous avez choisi est le Confidentialité Web3 Maintenant initiative qui ont catégorisé et noté divers outils de confidentialité cryptographique. Découvrez-le comme une excellente première étape vers la protection de votre identité en ligne et de vos finances.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://cryptoslate.com/the-seven-deadly-sins-of-crypto-privacy/