Des adresses réutilisables pour IOTA

IOTA a été longuement critiqué sur certains choix de design. Un de ceux-ci est l’utilisation de méthodes cryptographiques entrainant l’impossibilité de réutiliser les adresses après avoir effectué une transaction sortante. Pour répondre à ce problème, la fondation propose dans une suite d’articles une solution innovante qui permettrait la réutilisation d’adresses, sans pour autant décroître leur sécurité. 

Le problème des adresses IOTA 

Les développeurs de IOTA ont toujours réalisé des choix de design très audacieux. Ceux-ci ont à chaque fois été faits en anticipation des besoins futurs et en gardant à l’esprit que les appareils de l’internet des objets ne pourront pas toujours facilement être adaptés au gré des modifications de software. 

Ainsi, pour se prémunir de la future menace que constituent les ordinateurs quantiques, les développeurs ont implémenté une méthode de signature originale, à contre-courant de celle employée par les autres cryptos. Cet algorithme possède l’avantage d’être totalement résistant aux ordinateurs quantiques, mais s’accompagne aussi d’un défaut majeur. En effet, lors de la signature d’une transaction, une partie de la clé privée de l’adresse utilisée est dévoilée publiquement. Cet élément rend la réutilisation d’une même adresse très risquée, car chaque signature dévoilera un peu plus la clé privée qui sécurise les fonds qui y sont stockés. C’est pour ça qu’il ne faut JAMAIS réutiliser une adresse avec IOTA.
En plus de cela, bon nombre de facilités qui découleraient d’une adresse fixe sont interdites actuellement avec IOTA. Il est par exemple impossible de tenir un carnet d’adresses à jour vu qu’on ne sait pas si l’adresse du destinataire est toujours valide ou non. Il est également impossible de renvoyer une transaction à l’expéditeur, étant donné que l’adresse du premier envoi est automatiquement invalidée par cet envoi. Finalement, il est également très difficile d’effectuer des paiements réguliers (salaires, dons, contrats, …) vu que l’adresse du destinataire est susceptible d’évoluer au fil du temps.
De par ce fait, l’utilisation de IOTA par des humains s’avère en général plus complexe que pour les autres cryptos. Et même si à la base IOTA est conçu dans l’optique d’une économie de machines, l’adoption ne pourra se faire qu’au départ d’un soutien du grand public. 

Plusieurs solutions ont déjà été suggérées par la communauté comme les chèques IOTA  ou MAIA. Bien qu’elles permettent de solutionner (ou plutôt contourner) le problème des adresses non réutilisables, ces solutions s’accompagnent aussi de plusieurs inconvénients. Elles sont en outre dépendantes d’une seconde couche comme la Messagerie Authentifiée Masquée (MAM), ou nécessitent que les deux parties de la transaction soient en ligne simultanément. Certaines autres requièrent également que les serveurs retiennent constamment en mémoire toutes les adresses utilisées pour pouvoir assurer le suivi des transactions (incompatible avec les snapshots, …). 

La fondation a donc décidé de prendre le problème à bras-le-corps et de s’y attaquer à la racine. La solution envisagée actuellement est décrite dans une série de trois articles que vous pouvez retrouver ici : article 1, article 2 et article 3. 

Le système actuel

Avant toute chose, passons en revue brièvement le système actuel. Vous pouvez également consulter notre page sur le principe du Wallet et la FAQ pour des informations plus détaillées. 

Lorsque l’on envoie une transaction depuis une de nos adresses, nous devons signer le message avec la clé privée appartenant à cette adresse (la clé publique n’étant autre que l’adresse elle-même). Les serveurs du Tangle peuvent alors vérifier que la transaction est légitime et a été autorisée par le vrai possesseur des fonds en comparant la signature et la clé publique (ou adresse) de la transaction. Comme expliquée au point précédent, la méthode de signature utilisée (les signatures de Winternitz) nécessite de révéler la moitié de la clé privée lors de chaque transaction. Lors d’une transaction il est donc absolument nécessaire que le wallet déplace les fonds restant de l’adresse de départ vers une nouvelle adresse. Cette procédure est réalisée automatiquement sans que vous vous en rendiez compte et sert à assurer que le reste du solde de la transaction est bien en sécurité. L’illustration ci-dessous représente ce mécanisme avec des tirelires à la place des adresses. Si ce procédé n’était pas mis en place, le solde de la transaction resterait sur l’adresse de départ et à chaque transactions suivante une partie supplémentaire de la clé privée protégeant ces fonds serait révélée. En peu de temps un pirate serait alors à même de reconstruire la clé privée entièrement et vider l’adresse du reste de son contenu. La solution actuelle est donc parfaitement sécurisée vu que le portefeuille gère tout de son côté. 

Fonctionnement actuel des adresses

Plusieurs soucis mineurs peuvent cependant toujours arriver. C’est par exemple le cas si Vincent envoie de l’argent à Thomas (transaction 1) et que Thomas en envoie simultanément à Alexis (transaction 2). Dans le cas où la transaction 2 serait confirmée par le Tangle avant la transaction 1, les fonds envoyés par Vincent se retrouveraient sur l’adresse de Thomas censée ne plus être utilisée. Le wallet de Thomas lui indiquera alors qu’il y a un souci de réutilisation d’adresse et interdira la dépense de ces fonds. Des systèmes alternatifs existent toutefois pour récupérer ces fonds malgré tout, mais ils sont assez fastidieux.  

Une nouvelle proposition 

Il n’est bien entendu pas envisageable ici de modifier la façon dont les transactions sont signées, étant donné qu’il s’agit d’un point clé de IOTA (la résistance quantique). Pour pallier aux différents problèmes et complications causés par ce système d’adresses uniques, la fondation propose une solution innovante basée sur la création de nouvelles paires de clés publiques/privées pour une même adresse. 

Avec ce système, il est nécessaire de séparer l’adresse de la clé publique (actuellement la clé publique est utilisée directement en tant qu’adresse). Il convient également de trouver un moyen de changer la clé publique associée à cette adresse à chaque nouvel envoi. 

La proposition est donc la suivante : 

1. Introduction d’un nouveau champ dans les métadonnées des transactions. Ce champ permettra la mise à jour de la clé publique correspondant à l’adresse et ainsi d’informer le réseau de ce changement. 
2. La signature de la prochaine dépense devra maintenant être vérifiée par rapport à cette clé publique et non par rapport à l’adresse en elle-même. 

Ainsi, à chaque nouvel envoi le portefeuille générera une nouvelle paire publique/privée qui sera utilisée pour vérifier la prochaine dépense depuis cette adresse. Il indiquera ensuite dans la transaction la nouvelle clé publique à utiliser lors de la vérification de l’envoi suivant. 

Pour être en mesure de traiter ces transactions, les serveurs devront donc simplement ajouter un champ supplémentaire par adresse et mettre à jour la clé publique à utiliser quand ils voudront valider un nouvel envoi. 

Perspectives et limitations 

À première vue, le système proposé semble résoudre parfaitement le problème des adresses. Il est relativement simple à mettre en place, élégant dans sa formulation et ne nécessite qu’un léger accroissement de la taille d’une transaction. Mais tout n’est jamais parfait. En y regardant de plus près, la solution envisagée présente aussi certaines limitations.  

Avantages de ce système

• Le récipiendaire ne doit plus communiquer sans cesse une adresse valide, et il peut se contenter de suivre une seule adresse pour savoir si les fonds sont arrivés. 
• Cela réduit directement la possibilité de faire une attaque de type DOS qui inonderait un appareil de requête de paiements, le forçant à générer un nombre élevé de nouvelles adresses. 
• Moins de ressources seront requises chez l’envoyeur, étant donné que celui-ci ne doit plus constamment s’assurer de la validité des adresses auxquelles il envoie des fonds. 
• Les portefeuilles peuvent implémenter des carnets d’adresses. Il devient également possible d’effectuer des paiements récurrents (salaires, contrats, etc) en sauvegardant les données des destinataires. 
• Un système similaire au DNS pourrait être mis en place, liant les adresses à des caractères plus usuels et mémorisables pour des humains (comme pour les emails par exemple). Ce qui ferait de IOTA un système aussi facile à utiliser que PayPal ou les systèmes bancaires traditionnels. 
• La validation de ces alias par le wallet pourra immédiatement déterminer si l’adresse a été encodée correctement (dans le cas où un alias ne serait lié à aucune adresse).  
• Les fonds reçus seront toujours 100% surs et ne pourront jamais être sur une adresse non-réutilisable. 
• La fonction qui force les serveurs à retenir toutes les adresses utilisées par le passé pourrait être retirée. Celle-ci entraine l’expansion constante d’un fichier d’adresses inutilisables, ce qui a pour effet de limiter l’extensibilité du projet. 
• Les paquets de transactions seraient plus petits, car le solde d’une transaction ne devrait plus nécessairement être déplacé vers une nouvelle adresse.   

Limitations

• L’ordre des transactions est important :  une transaction ne pourra être validée que si la transaction précédente a été confirmée et acceptée par le réseau. En effet, sans cela il serait impossible de connaitre la nouvelle valeur de la clé publique pour valider la transaction la plus récente. Du coup, si on réalise 10 transactions à la chaine et que la première n’est pas validée, les 9 suivantes ne pourront pas l’être non plus. Il faudra alors rattacher la 1, puis une fois celle-ci confirmée, rattacher la 2, et ainsi de suite.
  Une solution envisagée à ce problème est de faire en sorte que les transactions réfèrent les précédentes si elles sont toujours en attente de validation. Ainsi les nœuds pourront remonter la liste et toujours connaître les clés publiques dans le bon ordre. 
• Moins d’anonymat : Si l’argent ne bouge plus spécialement des adresses, n’importe qui pourra checker le solde de votre compte. Ce sera d’autant plus le cas quand des systèmes d’alias seront implémentés.
  La solution ici est de permettre d’envoyer des fonds de cette adresse fixe vers des adresses anonymes fonctionnant sous l’ancien système (celui en place actuellement). L’anonymat peut ensuite encore être augmenté par l’utilisation d’un service de mixage. 
• Augmentation des besoins de stockage pour les serveurs : Vu qu’on ajoute un nouveau champ à la base de données pour retenir la nouvelle clé publique de chaque adresse, les serveurs auront besoin de plus d’espace de stockage (243 trits en plus par adresse). En plus de cela, les adresses vides ne pourront plus être retirées de la base de données lors des snapshots comme il faudra garder en mémoire la dernière clé publique y correspondant.
  La solution est de ne garder une adresse fixe dans la base de données des serveurs que si elle contient des iotas. Il suffira alors que le wallet laisse un iota (pas Miota, juste iota) pour indiquer que l’adresse ne doit pas être effacée. Lorsque ce iota sera bougé de l’adresse, cela indiquera aux serveurs qu’elle ne sera plus utilisée et ils pourront la retirer de la base de données. Si cette solution est implémentée, il est même probable que les besoins de stockage soient réduis à terme vu que les fonds seront plutôt répartis sur quelques adresses réutilisables que sur une multitude d’adresses à usage unique. 
• Problème de connexion aux groupements économiques : Même si les groupements économiques ne sont pas encore développés, il est primordial de concevoir le système pour s’accommoder aux changements à venir. Comme expliqué dans notre article sur ces groupements, le concept tout entier repose sur le fait que des tangles pourront être séparés des uns des autres et opérer en toute indépendance. Il ne sera donc pas possible pour un cluster B de connaître la clé publique d’une adresse utilisée dans le cluster A vu que la transaction détenant cette clé publique n’apparaîtra pas dans le cluster B. Le moyen simple de contourner ce problème est de transférer les fonds d’un cluster à l’autre par le biais d’une adresse non-réutilisable, comme cela aurait été possible en gardant l’ancien système. 

Conclusion 

Le nouveau système d’adresse proposé par la fondation semble être tout à fait en mesure de répondre au défi posé par le mode de signature rendant IOTA quantum-résistant. Nous avons cependant vu qu’il s’accompagne de plusieurs contreparties incommodantes. Cette nouvelle solution n’est donc pas à même de totalement remplacer le système actuel. Les deux solutions sont en fait complémentaires et seront donc amenées à cohabiter en parallèle.  

Dans une optique de compromis entre les avantages et inconvénients, la fondation propose un système ou chaque wallet aurait une seule adresse fixe. Cette adresse servirait de point de contact unique pour les paiements arrivants. Une fonction permettant de déplacer les fonds vers une adresse réutilisable sera implémentée en parallèle afin d’assurer la discrétion quant à la valeur détenue sur les comptes. Les transactions sortantes pourraient être réalisées au départ des deux types d’adresses. Dans l’absolu, les adresses non réutilisables seront à privilégier pour effectuer un grand nombre de transactions consécutives afin d’éviter de devoir dépendre des clés publiées par les transactions précédentes. 

En rendant ce passage au nouveau type d’adresse optionnel, la fondation laisse le choix total a l’utilisateur. Il sera possible de ne pas choisir d’adresse fixe si l’on ne veut pas et ainsi poursuivre avec le système actuel. Cette option est cependant très importante pour atteindre une réelle adoption de IOTA comme méthode de paiement par les humains (et les machines également) et promet déjà de faciliter grandement l’utilisation de IOTA par le grand public.