honnêtement ? J'ai réfléchi au problème d'identité persistante sur Midnight ces derniers jours et plus je m'y attarde, plus je pense que c'est l'un de ces défis de conception où chaque solution crée une nouvelle version du problème exact qu'elle essayait de résoudre et je ne sais vraiment pas si quelqu'un a trouvé un moyen propre de sortir de cette boucle encore 😂
laisse-moi expliquer ce que je veux dire car celui-ci nécessite une préparation minutieuse avant que la partie intéressante n'arrive.
l'identité est partout dans les applications sérieuses. pas seulement dans les applications financières. les applications de santé doivent savoir que la personne accédant à un dossier médical aujourd'hui est la même personne qui l'a créé il y a six mois. les applications juridiques doivent savoir que la partie signant un contrat confidentiel est la même partie qui a négocié ses termes. les systèmes de credentials privés doivent savoir que la personne présentant un credential est la personne à qui il a été délivré. les systèmes de contrôle d'accès doivent savoir qu'un utilisateur revenant a les permissions qui lui ont été précédemment accordées.
l'identité persistante — la capacité à reconnaître de manière fiable un utilisateur revenant à travers plusieurs interactions dans le temps — n'est pas une fonctionnalité accessoire pour des applications sérieuses. c'est une exigence fondamentale. sans cela, l'application ne peut pas maintenir un état qui soit significatif à travers les sessions. elle ne peut pas accorder des permissions qui persistent. elle ne peut pas construire le genre de relation continue entre l'utilisateur et l'application qui rend possible des fonctionnalités complexes.
sur une blockchain transparente, l'identité persistante est simple au point d'être triviale. votre adresse de portefeuille est votre identité. chaque transaction que vous effectuez est signée avec votre clé privée et liée à votre adresse publique. la chaîne enregistre l'historique complet des interactions de votre identité avec chaque application que vous avez jamais touchée. l'identité persistante est automatique et universelle et ne nécessite aucune infrastructure supplémentaire.
c'est aussi un enregistrement de surveillance complet de tout ce que vous avez jamais fait sur la chaîne.
cet enregistrement de surveillance est le coût de l'identité transparente sur la chaîne. chaque application que vous avez utilisée. chaque transaction que vous avez effectuée. chaque protocole avec lequel vous avez interagi. tout cela est lié de manière permanente à un seul identifiant que quiconque peut interroger à tout moment.
Midnight est censé résoudre ce problème. la couche de confidentialité est censée vous permettre d'interagir avec des applications sans créer le genre d'enregistrement d'identité lié permanent que les chaînes transparentes produisent automatiquement.
et c'est ici que le problème d'identité commence réellement.
si vous éliminez l'enregistrement d'identité transparent, vous éliminez également l'identité persistante dont les applications dépendent pour fonctionner. le même mécanisme qui crée le problème de surveillance est le mécanisme qui rend possible une identité persistante fiable. ce ne sont pas deux choses distinctes qui peuvent être résolues indépendamment. ce sont deux conséquences de la même conception sous-jacente.
le défi d'identité de Midnight est de fournir une identité persistante sur laquelle les applications peuvent compter sans créer l'enregistrement d'interaction lié qui fait de l'identité un mécanisme de surveillance.
ce défi n'a pas de solution évidente. et les approches qui ont été proposées échangent chacune un problème contre un autre de manière à mon avis méritent un examen beaucoup plus sérieux qu'elles ne le reçoivent actuellement.
la première approche est l'identité basée sur le portefeuille avec non-liaison. au lieu d'utiliser une seule adresse de portefeuille persistante pour toutes les interactions, vous utilisez une adresse dérivée différente pour chaque application ou chaque session. le même matériel clé sous-jacent génère toutes les adresses mais les adresses ne sont pas liées entre elles sans accès à la clé racine. un observateur regardant la chaîne voit de nombreuses adresses différentes sans connexion visible. ils ne peuvent pas reconstruire le fait que toutes ces adresses appartiennent à la même personne.
cela semble résoudre le problème de surveillance proprement. et dans le sens étroit de prévenir le lien d'adresse on-chain, cela le fait.
mais les adresses non liées créent un nouveau problème pour les applications qui ont besoin d'une identité persistante à travers les sessions.
si vous utilisez une adresse dérivée différente chaque fois que vous ouvrez une application, comment l'application sait-elle que vous êtes la même personne qui l'a utilisée la semaine dernière. l'application voit une nouvelle adresse qu'elle n'a jamais rencontrée auparavant. elle n'a aucune base pour connecter cette nouvelle adresse à l'historique que vous avez construit sous une adresse précédente. vos autorisations sont parties. l'état de votre application est inaccessible. votre relation avec l'application doit recommencer de zéro.
vous avez préservé votre confidentialité vis-à-vis des observateurs extérieurs mais vous avez détruit votre identité persistante du point de vue de l'application dans le processus.
l'application doit soit stocker un lien entre vos différentes adresses quelque part — ce qui recrée l'enregistrement de surveillance que l'adressage non lié était censé éliminer — soit elle doit traiter chaque session comme un nouvel utilisateur — ce qui la rend fonctionnellement inutile pour toute application qui dépend de relations continues avec des utilisateurs récurrents.
la deuxième approche est les preuves d'identité ZK. au lieu de révéler une adresse qui lie votre histoire, vous prouvez des faits spécifiques concernant votre identité en utilisant des preuves à connaissance zéro. vous prouvez que vous êtes la même personne qui a interagi avec cette application auparavant sans révéler l'adresse ou le matériel clé qui établit cette connexion. la preuve est vérifiable. l'information d'identité sous-jacente est privée.
c'est la réponse élégante et c'est celle qui est le plus souvent citée dans les discussions théoriques sur l'identité préservant la confidentialité.
mais les preuves d'identité ZK nécessitent quelque chose contre quoi prouver. vous prouvez que vous êtes la personne qui a précédemment interagi avec cette application. cette preuve nécessite que votre interaction précédente ait laissé une trace vérifiable à laquelle votre interaction actuelle peut être liée à travers la preuve sans révéler le lien directement.
qu'est-ce que cette trace. où vit-elle. qui y a accès.
si la trace vit dans l'état public sur la chaîne, elle est observable. un observateur qui voit la trace et voit la preuve ZK être générée contre elle sait que quelqu'un revendique la continuité avec une interaction précédente. il ne sait peut-être pas qui. mais il connaît le schéma de la revendication.
si la trace vit dans un état privé sur l'application, cela nécessite que l'application stocke des informations de liaison sur les utilisateurs. l'application devient un dépositaire des données de continuité d'identité. ce qui rend l'application un risque de surveillance même si la chaîne elle-même ne l'est pas. une application assignée qui détient le lien entre les sessions d'un utilisateur est un enregistrement d'identité complet indépendamment de ce que montre la chaîne.
si la trace vit dans un état privé sur le dispositif de l'utilisateur, cela nécessite que l'utilisateur gère et maintienne cet état de manière fiable à travers les transitions de dispositifs et les mises à jour d'applications et les types d'événements de la vie normale qui rendent la gestion de l'état côté client peu fiable pour les utilisateurs ordinaires.
chaque emplacement où l'information de continuité d'identité peut vivre crée une version différente du problème de surveillance ou de garde que la preuve ZK était censée éliminer.
la troisième approche est l'identité biométrique ou liée au matériel. votre identité persistante est ancrée à quelque chose de physique — vos caractéristiques biométriques ou un dispositif de sécurité matériel — plutôt qu'à une clé cryptographique qui vit dans le logiciel. l'ancre physique fournit une continuité à travers les sessions sans créer un enregistrement on-chain parce que la vérification de l'identité se fait localement sans produire un événement de chaîne lié.
l'identité biométrique a des propriétés qui sont utiles ici. elle est intrinsèquement persistante — votre empreinte digitale est la même à chaque session sans que vous ayez besoin de gérer ou de maintenir quoi que ce soit. il est difficile de transférer ou de déléguer — quelqu'un d'autre ne peut pas utiliser votre identité biométrique sans votre présence physique. elle ne dépend pas d'un état côté client qui peut être perdu ou corrompu.
il a également des propriétés qui sont profondément préoccupantes dans un contexte de confidentialité.
les données biométriques sont la forme d'information d'identité la plus personnelle et la moins révocable qui existe. si une clé cryptographique est compromise, vous pouvez en générer une nouvelle. si vos caractéristiques biométriques sont compromises — si le modèle utilisé pour vérifier votre identité est divulgué ou volé — vous ne pouvez pas générer de nouvelles empreintes digitales. la compromission est permanente.
ancrer une identité préservant la confidentialité aux biométriques échange le risque de surveillance des enregistrements d'identité on-chain contre le risque catastrophique de compromission des données biométriques. pour les utilisateurs dans des environnements à haut risque — exactement les utilisateurs pour lesquels les garanties de confidentialité de Midnight sont les plus précieuses — l'identité biométrique n'est pas une amélioration de la sécurité. c'est une forme différente et potentiellement pire du même problème d'exposition sous-jacent.
l'approche du dispositif de sécurité matériel est légèrement meilleure sur la dimension de révocabilité — vous pouvez obtenir un nouvel appareil matériel si le vôtre est compromis — mais elle introduit les problèmes de disponibilité et de dépendance que je continue de revenir à travers différentes parties de cette analyse. que se passe-t-il avec votre identité persistante lorsque le dispositif matériel échoue ou est volé ou est indisponible à un moment critique.
Je continue de penser à l'interaction entre le problème d'identité et la diversité des applications que Midnight est conçu pour prendre en charge.
une application de paiement simple pourrait fonctionner avec des garanties d'identité persistante plus faibles. si vous perdez la continuité entre les sessions, la principale conséquence est que vous perdez l'accès à votre historique de paiements et peut-être à votre carnet d'adresses. ennuyeux mais pas catastrophique.
une application de santé ne peut pas fonctionner de cette manière. le dossier médical qui a été construit au cours de six mois d'interactions doit être accessible à la même personne lors de la septième session. la continuité de l'identité n'est pas une fonctionnalité de commodité. c'est une exigence clinique. la mauvaise personne accédant à un dossier médical est un sérieux échec de sécurité. la bonne personne perdant l'accès à son propre dossier médical est également un sérieux échec.
une application de contrat légal est encore plus exigeante. l'exigence de continuité d'identité pour une partie à un contrat confidentiel de plusieurs années n'est pas seulement technique. elle a une signification légale. le système doit être capable de prouver que la personne signant le contrat final est la même personne qui a négocié ses termes. cette preuve doit être robuste contre les contestations légales. elle doit tenir non seulement sur le plan cryptographique, mais aussi sur le plan probatoire.
les exigences en matière d'identité varient énormément selon les types d'application que Midnight est conçu pour prendre en charge. et les solutions qui fonctionnent pour des applications simples ne sont pas adéquates pour des applications complexes. une approche d'identité basée sur des sessions légères qui fonctionne bien pour une application de paiement privée serait complètement inadéquate pour un système de santé ou une plateforme juridique.
cela signifie que l'écosystème Midnight a besoin d'une gamme de solutions d'identité calibrées pour différentes exigences d'application. pas un seul primitive d'identité que tout le monde utilise. un spectre de mécanismes d'identité avec différents profils de force et de compromis de confidentialité que les développeurs d'applications peuvent choisir en fonction de leurs exigences spécifiques.
ce spectre n'existe actuellement pas sous la forme d'une infrastructure cohérente de l'écosystème. les applications individuelles résoudront leurs exigences en matière d'identité de manière individuelle. certaines feront de bons choix. certaines feront des choix qui semblent raisonnables à l'étape de conception et s'avéreront avoir des modes d'échec graves à grande échelle ou dans des conditions adversariales.
et parce que l'identité est fondamentale, chaque application qui se trompe dans son architecture d'identité est une application où toute la garantie de confidentialité est potentiellement compromise au niveau de l'identité, peu importe la solidité de l'architecture ZK sous-jacente.
vous pouvez avoir des preuves de connaissance zéro parfaites protégeant chaque transaction dans une application alors que le mécanisme d'identité qui contrôle l'accès à ces transactions fuit des informations utilisateur à cause d'un défaut de conception auquel personne n'a pensé assez soigneusement à l'étape d'architecture.
les preuves sont solides. la couche d'identité est l'exposition.
l'écosystème Midnight doit traiter l'architecture d'identité comme un problème d'infrastructure de première classe avec la même sérieux qu'il traite l'architecture cryptographique. pas comme quelque chose que chaque développeur d'application doit résoudre par lui-même. comme quelque chose qui doit être conçu soigneusement au niveau de l'écosystème avec une reconnaissance honnête des compromis impliqués dans chaque approche.
parce que les utilisateurs faisant confiance aux applications Midnight avec leurs dossiers médicaux privés et leurs accords juridiques confidentiels et leurs historiques financiers sensibles font confiance non seulement aux preuves ZK mais aussi au système d'identité qui détermine qui peut accéder à ces preuves.
et ce système d'identité est actuellement la partie la moins examinée et la moins standardisée de l'ensemble de la pile.
la garantie de confidentialité n'est aussi forte que la couche la plus faible sur laquelle elle dépend.
en ce moment, l'identité est cette couche. 🤔
#NIGHT @MidnightNetwork $NIGHT 
Le problème d'identité présidentiel est un défi difficile pour la blockchain préservant la vie privée de Midnight.